Scenario 2: Attribute mapping and password migration for the entries in an authentication server

Edit online

You can store passwords for the entries in the authenticating server, if the entries successfully authenticate on the pass-through server. For the subsequent authentication, you do not require to authenticate against the pass-through server.

In this scenario, the entries are present in the authentication server. You can map the unique attribute of an entry in the authentication server to an attribute of an entry in the pass-through server.

After the first successful authentication, the password that the user provides is stored in the userpassword attribute of the user entry in the authentication server. The authentication server encrypts the password with the encryption scheme that is set on the server and then stores it. If password policy is set on the authentication server, the password must adhere to the set password policy. Subsequent authentication requests from the user are authenticated by the authentication server and are not routed to the pass-through server.

You must maintain password consistency between the pass-through server and the authentication server. Inconsistencies between passwords can be a potential security threat. You also must maintain the integrity of passwords in the authentication server and the pass-through server.

If you enable the audit feature on the authentication server, the server records the password modification for the user entries in the audit log. The following example shows the audit record for a user entry when the password migration is set:

AuditV3--2013-06-05-19:17:39.949+5:30--V3 Bind--bindDN: 
 cn=Al Garcia, ou=Home Entertainment, ou=Austin, o=sample
 --client: 127.0.0.1:9111--connectionID: 1--received: 2013-06-05-19:17:39.836+5:30
 --Success
controlType: 1.3.6.1.4.1.42.2.27.8.5.1
criticality: false
passthroughBindDN: cn=Al Garcia, ou=Home Entertainment, ou=Austin, o=sample
passthroughServer: ldap://127.0.0.1:1389
passthroughBindRC: 0
AuditV3--2013-06-05-19:17:39.949+5:30--V3 Bind--bindDN: CN=ROOT--client: 127.0.0.1:9623
 --connectionID: 2--received: 2013-06-05-19:17:39.948+5:30--Success
controlType: 1.3.18.0.2.10.15
criticality: true
controlType: 1.3.6.1.4.1.42.2.27.8.5.1
criticality: false
name: CN=ROOT
authenticationChoice: simple
Admin Acct Status: Not Locked
AuditV3--2013-06-05-19:17:40.029+5:30--V3 Modify--bindDN: CN=ROOT--client: 127.0.0.1:9623
 --connectionID: 2--received: 2013-06-05-19:17:39.949+5:30--Success
controlType: 1.3.18.0.2.10.15
criticality: true
controlType: 1.3.6.1.1.12
criticality: true
object: cn=Al Garcia, ou=Home Entertainment, ou=Austin, o=sample
add: userpassword
AuditV3--2013-06-05-19:17:40.030+5:30--V3 Unbind--bindDN: CN=ROOT--client: 127.0.0.1:9623
 --connectionID: 2--received: 2013-06-05-19:17:40.029+5:30--Success
AuditV3--2013-06-05-19:17:52.101+5:30--V3 Unbind--bindDN: 
 cn=Al Garcia, ou=Home Entertainment, ou=Austin, o=sample--client: 127.0.0.1:9111
 --connectionID: 1--received: 2013-06-05-19:17:52.100+5:30--Success

In the example audit record, the following operations are recorded when the password is updated in the user entry:

  1. After the first successful pass-through authentication by the user, the server binds to the authentication server with the administrator credentials.
  2. The server adds the userpassword attribute in the user entry with the password that the user provides for the successful authentication.
  3. The server unbinds after it adds the userpassword attribute.