Problem Definition
Access Gateway Enterprise Edition 8.x build 45.4 can use Lightweight Directory Access Protocol (LDAP) to change users' passwords. However, secure LDAP is required for this to take place. Note that global catalog port 3268 or secure global catalog port 3269 do not support changing passwords.
Environment
• Access Gateway Enterprise Edition 8.x build 45.4
Note: Secure LDAP and LDAP secure are equivalent.
Troubleshooting Methodology
1. Use PuTTY to create a secure connection to your Access Gateway system.
2. Once authenticated you will be in the CLI. Type shell and press the ENTER key.
3. Type cd /tmp/ and then type cat aaad.debug to view the entries that go through when authentication takes place.
4. From the Access Gateway Enterprise Edition configuration utility console, expand the SSL VPN node to get to the policies.
5. On the right side, make sure that you can create a server and a policy to identify that is a secure LDAP policy.
• Plaintext does not require a server-side certificate and it communicates over port 389
• Transport Layer Security (TLS) does require a LDAP server-side certificate and communicates over port 389
• SSL does require a LDAP server-side certificate and communicates over port 636
6. Once the server and policy are created, you can bind the policy to your virtual server in the section right below the SSL VPN node.
7. Make sure that you click the SAVE and REFRESH ALL buttons after main changes to the virtual server (or essentially any time you see the exclamation point).
8. Now you can proceed to test this policy on that new virtual server. As an example, the following screen shot shows what aaad.debug shows on a successful logon. Because this is setup for LDAP secure, port 636 is used.
9. Lets change the policy to a non-secure LDAP connection and use plaintext. Also, mark the user to change the password at next logon.
10. The following screen shot is an example of the aaad.debug log page you see when LDAP fails to change the user’s password. Note the message toward the bottom that says "Server is unwilling to perform." This is plaintext LDAP and an attempt to change the password.
11. The following screen shot shows a log created when the new password does not match the Active Directory policies. Note the “Constraint violation message” below. LDAP secure is active for this log.
12. The following screen shot shows what a successful aaad.debug log looks like when it works. Note the “Password modified success, authenticated” message below. LDAPS is active on this log capture.
Resolution
To get LDAP secure in your Active Directory domain, you have two options:
• Have a Certificate Authority (CA) in your domain. If you have a CA in your domain it usually creates the appropriate server certificates on the domain controller servers. Refer to How To Enable Secure Socket Layer (SSL) Communication over LDAP for Windows 2000 Domain Controllers.
-Or-
• Use a third-party CA. Complete the following procedure to do so:
1. Use a third party CA to create a certificate for your LDAP server. Refer to How to enable LDAP over SSL with a third-party certification authority for information on how to do so.
2. In the INF file, make sure you have the fully qualified domain name (FQDN) of your domain controller that hosts LDAP secure.
3. Issue the certreq –new request.inf request.req command on the domain controller hosting secure LDAP.
4. Open the request.req file in Notepad, highlight it and press CTRL+C.
5. You must have a CA somewhere to get a certificate (it can be any Windows CA). The path is usually http://server/certsrv. The following screen shot shows the main page that needs the above text. To get to this page you must click the request certificate link and then click the base 64-encoded link.
6. Click Submit to get the certnew.cert file.
7. The following screen shot shows what appears after clicking Submit. Make sure you select the Base 64 encoded option button before you clicking the Download certificate link.
8. Click Save and save the file in the root directory (c:\).
9. Open the command prompt and issue the certreq –accept certnew.cer command.
10. You should now see the certificate in your local system's certificate store.
11. Install the root certificate of the CA in the local system's trusted root CA. Pick Base 64 when installing the root certificate.
Additional Information
Unable to Connect to a Domain Controller by Using LDAP Connection over SSL
