Associating DNs, access groups, and additional bind and directory entry access information with a bound user

After a successful bind request, a bind distinguished name is associated with the bound user. Depending upon the bind method, there can also be a list of alternate DNs associated with the bound user.

For a simple bind, the bind DN is the DN specified in the bind request. There must be an entry in LDAP with that DN. The entry can be in an LDBM, SDBM, CDBM, or TDBM backend, or in a client operation plug-in extension. There are no alternate DNs.
For a CRAM-MD5 bind, the bind request must specify a DN or a user name. If a DN is specified, there must be an entry in LDAP with that DN. If a user name is specified, there must be an entry in LDAP that contains the user name as a uid attribute value. If both a DN and a user name are specified, there must be an entry in LDAP with that DN and the user name must be a uid attribute value in that entry. In all of these cases, the bind DN is the DN of the entry. The entry can be in an LDBM, CDBM, or TDBM backend, or in a client operation plug-in extension. There are no alternate DNs. See CRAM-MD5 and DIGEST-MD5 authentication for more information.
For a DIGEST-MD5 bind, the bind request must specify a user name and may optionally contain an authorization DN. If only a user name is specified, there must be an entry in LDAP that contains the user name as a uid attribute value. If both a user name and an authorization DN are specified, there must be an entry in LDAP with the authorization DN as its DN and the user name must be a uid attribute value in that entry. In both cases, the bind DN is the DN of the entry. The entry can be in an LDBM, CDBM, or TDBM backend or in a client operation plug-in extension. There are no alternate DNs. See CRAM-MD5 and DIGEST-MD5 authentication for more information.
For a Kerberos bind, the bind DN is ibm-kn=principal@REALM where principal@REALM is the Kerberos identity specified in the bind request. There cannot be an entry in an LDBM, CDBM, or TDBM backend or in a client operation plug-in extension corresponding to this DN. Each LDBM, TDBM, CDBM, and SDBM backend that krbIdentityMap on is specified in the LDAP server configuration file is contacted to map the Kerberos identity to alternate DNs in that backend. The client operation plug-in extensions are also contacted if they registered a SLAPI_TYPE_ALT_NAMES callback type routine and can contribute alternate DNs. See Kerberos authentication for more information.
For a certificate (EXTERNAL) bind, the bind DN is usually the subject DN from the certificate specified in the bind request. There cannot be an entry in an LDBM, CDBM, or TDBM backend or in a client operation plug-in extension corresponding to this DN. If there is a RACF® user associated with the certificate and replace is specified for the sslMapCertificate option in the LDAP server configuration file, then an SDBM-style DN based on the RACF user name replaces the subject DN as the bind DN. If add is specified for the sslMapCertificate option, then the bind DN is not changed and the SDBM-style DN based on the RACF user name is added as an alternate DN. See Support of certificate bind for more information.

After the bind DN and alternate DNs (if any) associated with the bound user are determined, the DNs of the groups the bound user belongs to are added to the bind information. If LDAP password policy is active, groups are determined during authentication time. If LDAP password policy is not active, the groups are determined at the beginning of the next non-bind request. The bind DN and group information are used in access control in LDAP operations from the bound user.

Note: Group gathering is not performed if any of the following is true:

The user binds as the adminDN, peerServerDN, or masterServerDN.
The authenticateOnly server control is specified as part of the bind request.

The groups are gathered in the following manner:

The backend or client operation plug-in extension that contains the bind DN is contacted to contribute DNs of any group entries that contain the bind DN or any of the alternate DNs. If the bind DN is not in a backend or a client operation plug-in extension (for example, after a Kerberos bind), this step is skipped.
Each LDBM, CDBM, or TDBM backend that has extendedGroupSearching on specified in the LDAP server configuration file is also contacted to contribute the DNs of any group entries in the backend that contain the bind DN or any of the alternate DNs. The client operation plug-in extensions are also contacted to contribute group DNs if they registered a SLAPI_TYPE_GROUPS callback type routine. Note that SDBM does not support extended group searching.

Besides bind DN, alternate DNs, and groups, additional data are added to the bind information and to the directory entry access information to further distinguish the identity of the bound user. This information is used when matching ACL filters to determine access control for LDAP operations from the bound user. Search size and time limits are also gathered using group search limits from groups to which the bound user belongs. The following additional data are added to the bound user’s bind information:

IP address of the bound user's client connection
Bind mechanism used to bind to the LDAP server
Whether a secure, encrypted SSL connection was used to bind to the LDAP server
Largest size limit and time limit specified in group search limits

The following data is added to the bound user's directory entry access information when accessing an entry:

Time of day the bound user accessed the directory entry
Day of week the bound user accessed the directory entry