I am attempting to configure my AMS server for LDAP authentication, but users are either unable to login successfully or they do not have the expected permissions to AMS resources. How can I confirm the correct AMS server settings for LDAP authentication?
 

Outlines how to use the ldapsearch utility to determine the correct LDAP authentication settings for AMS.

In the AMS server configuration file (AMS.conf), the LDAP-related configuration properties are:

•   host and portNumber - The hostname and port for the LDAP server
•   userName and password - A known user in LDAP who has LDAP search permissions (typically obtained from your LDAP administrator)
•   principalRoot - The starting location in the LDAP system to search for users
•   principalSearch - The LDAP user-identifying attribute.
•   roleRoot - The starting location in the LDAP system to search for groups.
•   roleSearch The user attribute that links LDAP users to groups.
•   roleAttribute The group attribute that identifies members of that group.

For example:

LDAPAuthenticationRealm = {
   servers = [
      {
         authenticationCredentials = {
            userName = "uid=admin,ou=system"                    
            password = "secret"
         }
         host = "localhost"
         portNumber = 389
         principalRoot = "ou=system"
         principalSearch = "uid={0}"
         roleRoot = "ou=groups,ou=system"
         roleSearch = "distinguishedName={0}"
         roleAttribute = "uniqueMember"
      }
   ]
}

These properties are used to construct LDAP searches performed by the AMS server, as follows:

ldapsearch -vvv -x -H ldap://<host>:<portNumber> -D "<userName>" -w <password> -b "<principalRoot>" "(&(objectclass=*)(<principalSearch>=<LDAP user to serach for>))"

ldapsearch -vvv -x -H ldap://<host>:<portNumber> -D "<userName>" -w <password> -b "<roleRoot>" "(&(objectclass=*)(<roleAttribute>=<the value of the user's roleSearch attribute>))"

These searches may be performed manually using the ldapsearch command-line utlity (which comes standard on most Linux/Mac systems. On Windows, OpenLDAP can be installed, which includes the ldapsearch utility). Using the configuration values from the sample configuration shown above, you should perform the following searches to determine what groups the ldap user "user1" is a member of:

$ ldapsearch -vvv -x -H ldap://localhost:389 -D "uid=admin,ou=system" -w secret -b "ou=system" "(&(objectclass=*)(uid=user1))"
ldap_initialize( ldap://localhost:389/??base )
filter: (&(objectclass=*)(uid=user1))
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <ou=system> with scope subtree
# filter: (&(objectclass=*)(uid=user1))
# requesting: ALL
#

# user1, users, system
dn: uid=user1,ou=users,ou=system
sn: One
cn: User One
objectClass: top
objectClass: inetOrgPerson
objectClass: person
objectClass: organizationalPerson
userPassword:: e1NTSEF9L1RmRFJOVWxhMkNqT3FoNEJVYmpSTXF4SEZkalcrV0hra0wyYlE9PQ=
 =
uid: user1

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

This will return the user's full distinguishedName (dn). In this case, the search returned the value of "uid=user1,ou=users,ou=system". This value may be used to perform the second search on groups:

$ ldapsearch -vvv -x -H ldap://localhost:389 -D "uid=admin,ou=system" -w secret -b "ou=groups,ou=system" "(&(objectclass=*)(uniqueMember=uid=user1,ou=users,ou=system))"
ldap_initialize( ldap://localhost:389/??base )
filter: (&(objectclass=*)(uniqueMember=uid=user1,ou=users,ou=system))
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <ou=groups,ou=system> with scope subtree
# filter: (&(objectclass=*)(uniqueMember=uid=user1,ou=users,ou=system))
# requesting: ALL
#

# Administrators, groups, system
dn: cn=Administrators,ou=groups,ou=system
uniqueMember: uid=admin,ou=system
uniqueMember: uid=user1,ou=users,ou=system
cn: Administrators
objectClass: top
objectClass: groupOfUniqueNames

# Developers, groups, system
dn: cn=Developers,ou=groups,ou=system
uniqueMember: uid=user1,ou=users,ou=system
uniqueMember: uid=user2,ou=users,ou=system
cn: Developers
objectClass: top
objectClass: groupOfUniqueNames

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Here, 2 groups are returned for user1: 'Administrators' and 'Developers'. These LDAP groups can then be used to represent AMS roles for this user. This is configured in AMS.conf under the RoleToPrivilegeMappings section. For example:

RoleToPrivilegeMappings = {
   privileges = {
      "Administrators" = [
         {
            privilege = "*"
         }
      ]
      "Developers" = [
         {
            privilege = "artifact:*"                    
         }
      ]
   }
}

This would grant all AMS privileges to any LDAP users who are a member of the 'Administrators' LDAP group, while members of the 'Developers' LDAP group will only have privileges with respect to artifacts. In the above example, user1 would be granted all AMS privileges (*) because user1 is a member of the 'Administrators' LDAP group.