LDAP Configuration

If you installed a Lightweight Directory Access Protocol (LDAP) server or a secure LDAP (LDAPS) server, you can configure the system to use the LDAP user registry to authenticate users.

About this task

Before you configure embedded application login security, you must gather information about your LDAP server and create valid configuration file. The configuration data depends on the type of LDAP product that you use and how it is configured in your environment.

The oneWEX allows user to put Liberty configuration and required files. Passwords in XML files will be AES encoded unless it specified to do not so.

Note: All files will be uploaded to single directory in flat layout. Thus, other file can be referred by its name. Example: Referring another file.<include location="another_settings.xml" />

Procedure

  1. Upload a specific LDAP configuration file, using the /api/v1/usermgmt/config/file/{name} method in the Swagger UI (https://localhost/docs/#/User/uploadConfigFile)
  2. Upload custom_ldap_config.xml with a valid Liberty configuration.
    Note: Make sure that the file name is custom_ldap_config.xml. No other file name will cause a configuration change in WLP.
        <server>
      <ldapRegistry id="ldap" realm="ibm.com"
        host="bluepages.ibm.com" port="389" ignoreCase="true"
        baseDN="ou=bluepages,o=ibm.com"
        bindDN=""
        bindPassword=""
        ldapType="IBM Tivoli Directory Server"
        sslEnabled="false"
        sslRef="">
        <activedFilters
        userFilter="(&amp;(mail=%v)(objectclass=ePerson))"
    groupFilter="(&amp;(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)))"
       userIdMap="*:mail"
        groupIdMap="*:cn"
        groupMemberIdMap="ibm-allGroups:member;ibm-allGroups:uniqueMember" >
        </activedFilters>
      </ldapRegistry>
     
    </server>
  3. Once custom_ldap_config.xml is updated, Liberty will reload, and the configuration will be effective. Users will now need to login with their LDAP user ID and password.
    Example: Configure Active Directory as an LDAP server
    1. Upload the keystore (LdapSSLKeyStore.jks) and trust store (LdapSSLTrustStore.jks) files.
    2. Create the configuration file and upload as custom_ldap_config.xml
      <server>
  <ldapRegistry id="ldap" realm="SampleLdapADRealm" 
    host="ldapserver.mycity.mycompany.com" port="389" ignoreCase="true" 
    baseDN="cn=users,dc=adtest,dc=mycity,dc=mycompany,dc=com" 
    bindDN="cn=testuser,cn=users,dc=adtest,dc=mycity,dc=mycompany,dc=com" 
    bindPassword="testuserpwd"
    ldapType="Microsoft Active Directory" 
    sslEnabled="true" 
    sslRef="LDAPSSLSettings"> 
    <activedFilters
    userFilter="(&amp;(sAMAccountName=%v)(objectcategory=user))"
groupFilter="(&amp;(cn=%v)(objectcategory=group))" 
   userIdMap="user:sAMAccountName" 
    groupIdMap="*:cn" 
    groupMemberIdMap="memberOf:member" >
    </activedFilters>
  </ldapRegistry>

  <ssl id="LDAPSSLSettings" keyStoreRef="LDAPKeyStore" trustStoreRef="LDAPTrustStore" /> 

  <keyStore id="LDAPKeyStore" location="LdapSSLKeyStore.jks" 
          type="JKS" password="plain_store_password" /> 
  <keyStore id="LDAPTrustStore" location="LdapSSLTrustStore.jks" 
          type="JKS" password="plain_trust_password" />  
</server>

How to make LDAP user as Admin

To make LDAP user act as 'Admin' user, set a list of pattern texts from the API:

  • API Path: https://your.server/api/v1/usermgmt/config/admin
  • API Documentation: https://your.server/docs/#/User/getAdminPatterns

For each pattern, each user and group are evaluated. Once the pattern matches, user will be Admin (allow=true) or User (allow=false). Alternatively specify 'Role' from Admin, User, ToolUser and AppUser.

Example:

[
  {
    "pattern": "CN=admingroup,CN=Users,DC=example,DC=org"
  },
  {
    "pattern": "CN=othergroup*,CN=Users,DC=example,DC=org",
    "allow": false
  },
  {
    "pattern": "CN=mygroup,CN=Users,DC=example,DC=org",
    "role": "AppUser"
  }
]
The implication of the above settings are:
  • The first entry means that a user in the group that has CN starting with "admingroup", and matches the remaining part, is given a default access (i.e., "allow" as `true`).
  • The second entry means that a user in the "CN=othergroup*" (e.g., othergroup1, othergroup2, ...) is not allowed an administrative role.
  • The last entry means that a user in the "CN=mygroup" is given the AppUser role.

If none of the patterns matches any of user’s groups, the user’s role is set as “User”.