This chapter focuses on pass through authentication, whereby you configure another server to determine the response to an authentication request. A typical use case for pass through authentication involves passing authentication through to Active Directory for users coming from Microsoft Windows systems.

You use LDAP pass through authentication when the credentials for authenticating are stored not in OpenDJ, but instead in a remote directory service. In effect OpenDJ redirects the bind operation against a remote LDAP server. Exactly how OpenDJ redirects the bind depends on how the user entry in OpenDJ maps to the corresponding user entry in the remote directory. OpenDJ provides you several choices to set up the mapping. When both the local entry in OpenDJ and the remote entry in the other server have the same DN, you do not have to set up the mapping at all. By default, OpenDJ redirects the bind with the original DN and password from the client application. When the local entry in OpenDJ has been provisioned with an attribute holding the DN of the remote entry, you can specify which attribute holds the DN, and OpenDJ redirects the bind on the remote server using the DN value. When you cannot get the remote bind DN directly, you need an attribute and value on the OpenDJ entry that corresponds to an identical attribute and value on the remote server in order to map the local entry to the remote entry. In this case you also need the bind credentials for a user who can search for the entry on the remote server. OpenDJ performs a search for the entry using the matching attribute and value, and then redirects the bind with the DN from the remote entry. You configure pass through authentication as an authentication policy that you associate with a user's entry in the same way that you associate a password policy with a user's entry. Either a user has an authentication policy for pass through authentication, or the user has a local password policy.

When setting up pass through authentication, you need to know to which remote server or servers to redirect binds, and you need to know how you map user entries in OpenDJ to user entries in the remote directory. When performing pass through authentication, you no doubt protect communications between OpenDJ and the server providing authentication. If you test using SSL with self-signed certificates, and you do not want the client blindly to trust the server, follow these steps to import the authentication server's certificate into the OpenDJ key store. Export the server certificate from the authentication server. How you perform this step depends on the authentication directory server. With OpenDJ, you can export the certificate as shown here. $ cd /path/to/PTA-Server/config $ keytool -exportcert -rfc -alias server-cert -keystore keystore -storepass `cat keystore.pin` > /tmp/pta-srv-cert.pem Make note of the host name used in the certificate. You use the host name when configuring the SSL connection. With OpenDJ, you can view the certificate details as shown here. $ keytool -list -v -alias server-cert -keystore keystore -storepass `cat keystore.pin` Alias name: server-cert Creation date: Sep 12, 2011 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=opendj.example.com, O=OpenDJ Self-Signed Certificate Issuer: CN=opendj.example.com, O=OpenDJ Self-Signed Certificate Serial number: 4e6dc429 Valid from: Mon Sep 12 10:34:49 CEST 2011 until: Wed Sep 11 10:34:49 CEST 2013 Certificate fingerprints: MD5: B6:EE:1C:A0:71:12:EF:6F:21:24:B9:50:EF:8B:4E:6A SHA1: 7E:A1:C9:07:D2:86:56:31:24:14:F7:07:A8:6B:3E:A1:39:63:F4:0E Signature algorithm name: SHA1withRSA Version: 3 Import the authentication server certificate into OpenDJ's keystore. $ cd /path/to/OpenDJ/config $ keytool -importcert -alias pta-cert -keystore truststore -storepass `cat keystore.pin` -file /tmp/pta-srv-cert.pem Owner: CN=opendj.example.com, O=OpenDJ Self-Signed Certificate Issuer: CN=opendj.example.com, O=OpenDJ Self-Signed Certificate Serial number: 4e6dc429 Valid from: Mon Sep 12 10:34:49 CEST 2011 until: Wed Sep 11 10:34:49 CEST 2013 Certificate fingerprints: MD5: B6:EE:1C:A0:71:12:EF:6F:21:24:B9:50:EF:8B:4E:6A SHA1: 7E:A1:C9:07:D2:86:56:31:24:14:F7:07:A8:6B:3E:A1:39:63:F4:0E Signature algorithm name: SHA1withRSA Version: 3 Trust this certificate? [no]: yes Certificate was added to keystore You configure authentication policies with the dsconfig command. Notice that authentication policies are part of the server configuration, and therefore not replicated. Set up an authentication policy for pass through authentication to the authentication server. $ dsconfig -p 4444 -h `hostname` -D "cn=directory manager" -w password create-password-policy --type ldap-pass-through --policy-name "PTA Policy" --set primary-remote-ldap-server:Mark-Craigs-MacBook-Pro.local:2636 --set mapped-attribute:uid --set mapped-search-base-dn:"dc=PTA Server,dc=com" --set mapping-policy:mapped-search --set use-ssl:true --set trust-manager-provider:JKS -X -n The policy shown here maps identities under dc=example,dc=com to identities under dc=PTA Server,dc=com, where users have the same uid values on both servers. The policy here also uses SSL between OpenDJ and the authentication server. Check that your policy has been added to the list. $ dsconfig -p 4444 -h `hostname` -D "cn=directory manager" -w password list-password-policies --property use-ssl Password Policy : Type : use-ssl ------------------------:-------------------:-------- Default Password Policy : password-policy : - PTA Policy : ldap-pass-through : true Root Password Policy : password-policy : - TODO

You assign authentication policies in the same way as you assign password policies, by using the ds-pwp-password-policy-dn attribute. Although you assign the pass through authentication policy using the same attribute as for password policy, the authentication policy is not in fact a password policy. Therefore, the user with a pass through authentication policy does not have a value for the operational attribute pwdPolicySubentry. $ ldapsearch -p 1389 -b dc=example,dc=com uid=user.0 pwdPolicySubentry dn: uid=user.0,ou=People,dc=example,dc=com Users depending on pass through authentication no longer need a local password policy, as they no longer authenticate locally. Examples in the following procedure work for this user, whose entry on OpenDJ is as shown. Notice that the user has no password set. The user's password on the authentication server is password. dn: uid=user.0,ou=People,dc=example,dc=com cn: Aaccf Amar description: This is the description for Aaccf Amar. employeeNumber: 0 givenName: Aaccf homePhone: +1 225 216 5900 initials: ASA l: Panama City mail: user.0@maildomain.net mobile: +1 010 154 3228 objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: top pager: +1 779 041 6341 postalAddress: Aaccf Amar$01251 Chestnut Street$Panama City, DE 50369 postalCode: 50369 sn: Amar st: DE street: 01251 Chestnut Street telephoneNumber: +1 685 622 6202 uid: user.0 This user's entry on the authentication server also has uid=user.0, and the pass through authentication policy performs the mapping to find the user entry in the authentication server. Prevent users from changing their own password policies. $ cat protect-pta.ldif dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (target ="ldap:///uid=*,ou=People,dc=example,dc=com")(targetattr = "ds-pwp-password-policy-dn")(version 3.0;acl "Cannot choose own pass word policy";deny (write)(userdn = "ldap:///self");) $ ldapmodify -p 1389 -D "cn=Directory Manager" -w password -f protect-pta.ldif Processing MODIFY request for ou=People,dc=example,dc=com MODIFY operation successful for DN ou=People,dc=example,dc=com Update the user's ds-pwp-password-policy-dn attribute. $ ldapmodify -p 1389 -D "cn=Directory Manager" -w password dn: uid=user.0,ou=People,dc=example,dc=com changetype: modify add: ds-pwp-password-policy-dn ds-pwp-password-policy-dn: cn=PTA Policy,cn=Password Policies,cn=config Processing MODIFY request for uid=user.0,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=user.0,ou=People,dc=example,dc=com Check that the user can authenticate through to the authentication server. $ ldapsearch -p 1389 -b dc=example,dc=com -D uid=user.0,ou=People,dc=example,dc=com -w password uid=user.0 cn sn dn: uid=user.0,ou=People,dc=example,dc=com cn: Aaccf Amar sn: Amar Examples in the following steps use the pass through authentication policy as defined above. Kirsten Vaughan's entry has been reproduced on the authentication server under dc=PTA Server,dc=com. Create a subentry to assign a collective attribute that sets the ds-pwp-password-policy-dn attribute for group members' entries. $ cat pta-coll.ldif dn: cn=PTA Policy for Dir Admins,dc=example,dc=com objectClass: collectiveAttributeSubentry objectClass: extensibleObject objectClass: subentry objectClass: top cn: PTA Policy for Dir Admins ds-pwp-password-policy-dn;collective: cn=PTA Policy,cn=Password Policies, cn=config subtreeSpecification: { base "ou=People", specificationFilter "(isMemberOf= cn=Directory Administrators,ou=Groups,dc=example,dc=com)"} $ ldapmodify -p 1389 -D "cn=Directory Manager" -w password -a -f pta-coll.ldif Processing ADD request for cn=PTA Policy for Dir Admins,dc=example,dc=com ADD operation successful for DN cn=PTA Policy for Dir Admins,dc=example,dc=com Check that OpenDJ has applied the policy. Make sure you can bind as the user on the authentication server. $ ldapsearch -p 2389 -D "uid=kvaughan,ou=People,dc=PTA Server,dc=com" -w password -b "dc=PTA Server,dc=com" uid=kvaughan dn: uid=kvaughan,ou=People,dc=PTA Server,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: top givenName: Kirsten uid: kvaughan cn: Kirsten Vaughan sn: Vaughan userPassword: {SSHA}x1BdtrJyRTw63kBSJFDvgvd4guzk66CV8L+t8w== ou: People mail: jvaughan@example.com Check that the user can authenticate through to the authentication server from OpenDJ. $ ldapsearch -p 1389 -D "uid=kvaughan,ou=People,dc=example,dc=com" -w password -b dc=example,dc=com uid=kvaughan cn sn dn: uid=kvaughan,ou=People,dc=example,dc=com cn: Kirsten Vaughan sn: Vaughan