Home

 

Authenticate with LDAP on IHS using mod_ibm_ldap (Distributed systems)

 

+

Search Tips   |   Advanced Search

If we are using the mod_ibm_ldap module for your LDAP configuration, consider migrating your mod_ibm_ldap directives to use the mod_ldap module. The mod_ibm_ldap module is provided with this release of IHS for compatibility with previous releases, however, migrate existing configurations to use the mod_authnz_ldap and mod_ldap modules to ensure future support for your LDAP configuration.

The LoadModule directive for LDAP is not loaded into IHS by default. Without the LoadModule directive, the LDAP features are not available for use. In order to enable the LDAP function, add a LoadModule directive to the IHS httpd.conf file as follows:

If we have the LDAP client installed on your computer, you can use ldapsearch as a tool to test the values you intend to use for the various settings.

See LDAP directives to obtain detailed descriptions of the LDAP (mod_ibm_ldap) directives.

  1. Edit the httpd.conf IHS configuration file.

  2. Determine the resource you want to limit access to. For example: <Directory "/secure_info">.

  3. Add directives in httpd.conf to the location (container) to be protected with values specific to your environment. For example:

    • LdapConfigFile path_to_ldap.prop

    • AuthType Basic

    • AuthName "Title of your protected Realm"

    • Require valid-user

  4. There are three options for how to use IHS to authenticate with your existing LDAP installation.

    • Authorization based on LDAP group membership. Use LDAP to check user passwords and verify that the user exists in a group defined in LDAP.

      The membership that identifies the user as being able to access the resource is a part of the group, not part of the user's own LDAP entry.

      For example, to restrict access to a group, add the following directive: 

      LDAPRequire group grp1

      For this form of LDAPRequire, have groups configured in your LDAP repository that conform to the following rules (using the example group name grp1):

      • There is an entry in your LDAP repository that matches the following search filter, where the values groupofnames and groupofuniquenames are example values specified in ldap.group.dnattributes.

        The proper value of ldap.group.dnattributes is a list of what objectclasses signify is a group in your LDAP schema. 

        ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
(objectclass=groupofuniquenames)))"

      • As part of the LDAP entry for "grp1," there are a series of attributes that match the following, where the values member and uniquemember are example values of ldap.group.memberAttributes.

        The proper value of ldap.group.memberAttributes is a list of what objectclasses signify is a membership in a group. The values of these entries are the Distinguished Names (DN) of your users. 

        ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
(objectclass=groupofuniquenames)))" member uniquemember

        Example: 

        ldapsearch -x -h myldapserver -D cn=root -w rootpw
"(&(cn=grp1)(|(objectclass=groupofnames)(objectclass=groupofuniquenames)))" 
member uniquemember

        dn: cn=group1,ou=myunit,o=myorg,c=US 
member: cn=user1, ou=otherunit, o=myorg, c=US
member: cn=user12, ou=otherunit, o=myorg, c=US

        If an object of the type listed in ldap.group.dnattributes is a member of the group being searched, then it will be recursively searched in the same fashion, up to a depth of ldap.group.search.depth

      • First IBM HTTP Server uses the ldap.group.name.filter and ldap.user.cert.filter to translate the CN provided for the user and the group into distinguished names (DN). Next, IBM HTTP Server searches using the group DN as a base for entries whose value is the user DN.

        Example: 

        ldapsearch ... -b "cn=grp1,ou=myunit,o=myorg,c=US" 
"|((member=cn=user1,ou=otherunit,o=myorg,c=US) 
(uniquemember=cn=user1,ou=otherunit,o=myorg,c=US))"

    • Authorization based on LDAP attributes of user. Use LDAP to check user passwords and verify that the user matches a set of attributes (the attribute that identifies the user as being able to access the resource is a part of the users own LDAP entry).

      Example: 

      LDAPRequire filter "(&(jobtitle=accountant)(location=newyork))"

      To use this form of LDAPRequire, the IHS must use the ldap.user.cert.filter to translate the CN provided for the user into a DN. IHS must also search using the user DN as a base and use the search filter provided in the LDAPRequire directive. If any results are returned, authorization succeeds.

      Example: 

      ldapsearch ... -b "cn=user1,ou=otherunit,o=myorg,c=US" "(&(jobtitle=accountant)
(location=newyork))"

      Some attributes (sometimes called Dynamic Roles) in LDAP are calculated dynamically by the LDAP server and might have different semantics that are not valid in a search filter. Such values would fail if used in the preceding example and cannot be used for authorization on IBM HTTP Server.

    • Authentication only: Use LDAP to check user passwords only.

      You can use the Require directive to limit to specific users or maintain a flat group file using AuthGroupFile.

  5. Edit the ldap.prop configuration file. If we do not have one yet, you can use the ldap.prop.sample file that ships with IBM HTTP Server. If we have questions about the correct values, check with your LDAP server administrator. Update the following directives with values that are correct for your environment:

    1. Enter the Web server connection information.

    2. When using SSL, or LDAPS, or LDAP over SSL:

      • Change ldap.transport to an SSL value

      • Change ldap.URL to include the LDAPS protocol and the proper port value, for example, 636.

      • Configure the SSL key database to be used, for example: 

        ldap.key.fileName=/path_to/key.kdb


        ldap.key.file.password.stashFile=/path_to/stashfile
        Where stashfile is created by the bin/ldapstash command. 

        ldap.key.label=label
        Where label is the value appearing in ikeyman for the referenced key.kdb.

Searches that use the mod_ibm_ldap directives maintain a pool of server connections that authenticate as the ldap.application.dn user. The first connection is created when the first LDAP-protected request is received. Connections will be held open a specified number of seconds (ldap.idleConnection.timeout) for subsequent searches on that connection or connections for other requests.

If we are reading logs or looking at an IP trace, the following sequence of events should occur:

 

Subtopics

Lightweight Directory Access Protocol
Querying the Lightweight Directory Access Protocol server
SSL and the Lightweight Directory Access Protocol module
SSL certificate revocation list
LDAP directives
Converting your directives from mod_ibm_ldap to mod_ldap