use either UID or email as login credential

This topic has 10 replies, 5 voices, and was last updated 6 years, 2 months ago by [email protected].

  • Author
  • #2213

    OpenAM uses UID as default attribute for autentication. I want to use either UID or email as login credential for authentication. How should enable this feature ?

     Victor Ake

    For this you will need to use the LDAP authentication module in the Realm.

    1. Login in the OpenAM console as the administrator (Amadmin)
    2. Select the “Access Control” tab
    3. Click the realm you want to configure
    4. Once in the realm you want to configure, Click the “Authentication” tab
    5. Once in the Authentication service, click the “LDAP” module under module instances.
    6. Once inside the “LDAP” module browse down to the “Attributes Used to Search for a User to be Authenticated”. You will see that there is an attribute already there: id
    7. Add the additional attribute, in your case: mail
    8. Save
    9. Go back to authentication
    10. You are all set, now that realm can use the LDAP module with both, the uid and the mail attribute to login

    To use the LDAP module using the XUI you need to do:

    The above URL is just an example.

    You can also make the LDAP module the default authentication module in the authentication configuration of the realm. By default DataStore is the default authentication module. Though the way to change the “default” authentication module, is maybe wrongly said, what you can change is the default “Organization Authentication Configuration” (which is actually an authentication chain). The default authentication chain is ldapService, but it is actually using the DataStore module, instead of the LDAP module.

    With the classic UI you will need to type:

    • This reply was modified 7 years, 9 months ago by Victor Ake.

    Hello Victor,

    Your reply did help me a lots. Also I set chaning in ldapService and finally it worked for me now.

    Many thanks,

     Victor Ake

    Great to hear that Taitung.
    I assume after configuring the LDAP module, you changed the DataStore module in the ldapService to LDAP and that did the trick.




     Peter Major

    As a sidenote: usually it is not a good idea to modify the built-in ldapService chain, since that is used for admin login as well by default (and LDAP module can’t authenticate amadmin). Modifying that chain can easily result in locking amadmin out of the admin console.


    Its not working with Multi-Factor authentication.

    LDAP module is able to perform authentication using UID/email.
    But OAUTH module is not. i.e, OAUTH module works based on “LDAP Users Search Attribute” in DataStore.

    If i set “LDAP Users Search Attribute=mail” in DataStore OAUTH module output is success if i input “mail” as username, if i input “uid” OAUTH module fails(LDAP module output is success).
    i.e, I can see Error in debug/Authentication file,
    ERROR: OATH.getIdentity: error searching Identities with username : test
    Message:OATH.getIdentity : User test is not found

    I think OAUTH module is not able to search using “uid” if i set “LDAP Users Search Attribute=mail” in DataStore


    Also its not working with “ForgeRock Authenticator (OATH)” in Multi-Factor Authentication


    Peter, you mention that it’s not a good idea to modify the default ldapService chain since it’s used by amAdmin. Since adAdmin is a well known super-user of OpenAM, I would would like to protect access to it. My original thought was to update the default ldapService chain to include IP restrictions -but your not says we shouldn’t change it. Besides a strong password, what features can we enable to protect the amAmin login?


     Peter Major

    As long as you make sure that amAdmin can still log in with the modified chain, it doesn’t matter how you change it. I just discourage changing ldapService, because people are likely to forget about amadmin login and end up locking themselves out of the system.

    For starters, you should consider renaming amadmin user, see “com.sun.identity.authentication.super.user” advanced server property.


    Thanks for the insight Peter. Given the disclaimer in the documentation:

    it is recommended that you keep the Top Level administrator account name to amadmin.

    I think I’ll keep the default name for the time being.


Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?