+

Search Tips   |   Advanced Search

Authenticating users with LDAP registries in a Microsoft Active Directory forest

Authenticating a user across multiple repositories, or across a distributed LDAP repository, such as a Microsoft Active Directory forest can be challenging. In any search of the whole user registry, if there is more than one match at run time, authentication fails because of ambiguous match results.

In any multiple Microsoft Active Directory domain environment, the WebSphere Application Server administrator must consider that the default unique ID in the Microsoft Active Directory is the sAMAccountName attribute of a user.

User IDs are guaranteed to be unique within a single domain. However they are not guaranteed across a tree or a forest. For example, suppose the user ID, smith, is added in the forest and in each subdomain. The search for sAMAccountName=smith returns three matches. WAS does not authenticate this user when there is more than one possible match in the registry.

Figure 1. Forest search strategy.. Search illustration of a non-unique sAMAccountName across the entire forest.

We can mitigate this condition by changing the user filter to be based on the userPrincipalName attribute of the user, which is unique across the forest, instead of being based on their sAMAccountName attribute. Users must then know to log in using their userPrincipalName, which they might not know.

The specific procedure to establish a user filter on a LDAP user registry depends on the type of LDAP registry. The following examples illustrate a procedure for a stand-alone LDAP registry and a procedure for a federated repository registry.


Tasks

  1. Establish a user filter on a stand-alone LDAP registry: We can set the user filter on the Advance Lightweight Access Protocol (LDAP) user registry settings page to search for userPrincipalName instead of sAMAccountName value.

    For example:

    (&(objectClass=user)(userPrincipalName=%w))
    
  2. Establish a user filter on a federated repositories registry: We can change the log-in property in the LDAP repository to uid;cn, for example, using the administrative console.

    1. Click Security > Global security.

    2. Under Available realm definitions, select Federated repositories, and then Configure. In a multiple security domain environment, click Security domains > domain_name. Under Security Attributes, expand User Realm, and click Customize for this domain. Select the Realm type as Federated repositories and then click Configure.

    3. Under Related items, click Manage repositories.

    4. Click Add > LDAP repository.

    5. Under General Properties, add the following information:

      Repository identifier

      forest

      Directory type

      Microsoft Windows Active Directory

      Primary host name

      forest.acme.net

      Port

      389

      Failover server used when primary is not available

      None

      Bind distinguished name

      cn=wasbind, CN=Users, DC=ib

      Bind password

      ********

      Login properties

      uid;cn

  3. Click OK and Save to save the changes to the master configuration.

  4. On the LDAP repository configuration page, under Additional properties, click LDAP attributes.

  5. Click Add > Supported.

  6. In the Name field, enter userPrincipalName.

  7. In the Property name filed, enter cn.

  8. In the Entity types field, enter PersonAccount.

  9. Click OK and Save to save the changes to the master configuration.
  10. Locate the {WAS_HOME}\profiles\{profileName}\config\cells\{cellName}\wim\config\wimconfig.xml or profile_root/conf/cells/<cell>/wim/config/wimconfig.xml file in the deployment manager configuration.

  11. Edit the wimconfig.xml file.

    1. Find the <config:attributeConfiguration> attribute in the file.

    2. Add the following lines:
      <config:attributes name="userPrincipalName" propertyName="cn">
      <config:entityTypes>PersonAccount</config:entityTypes>
      </config:attributes>
      

    The wimconfig.xml file is overwritten by the processing of the administrative console. The addition of these "3" lines to the wimconfig.xml file may be lost.

  12. Save the wimconfig.xml file.

  13. Run the profile_root/bin/syncNode.bat or profile_root/syncNode.bar/sh script on all of the nodes in the configuration.

When we select any of these scenarios, consult appropriate Microsoft Active Directory information to completely understand any implications the scenarios might have on your configuation planning.


Related:

  • Groups spanning domains with Microsoft Active Directory
  • Microsoft Active Directory Global Catalog
  • Options for finding group membership within a Microsoft Active Directory forest
  • Use Microsoft Active Directory for authentication
  • Locating user group memberships in a LDAP registry
  • Authenticating users with LDAP registries in a Microsoft Active Directory forest