Showing results for 
Search instead for 
Did you mean: 


ASA5500-X and MS Active Directory LDAPS (LDAP over SSL) Connection Issue

Hello All,


I've been on this for days now and have made a bit of progress but haven't quite gotten it yet. I'm trying to establish an LDAPS connection between an ASA5525-X and Ms AD on Server 2016 for use in authenticating Anyconnect VPN users coming from the internet (outside). There seems to be no proper documentation on it or perhaps the deadline to get this working has made me too tense to find it.



1) Ms Windows Server 2016 with CA and self-signed certificate installed. The installation of the CA a self signed cert is meant to enable LDAPS on the server.


2) ASA ver 9.8 (2), ASDM 7.8(2) with a working LDAP config but which fails when LDAPS is enabled.


After days of troubleshooting from both ends, it turns out that:-


  • The LDAPS server doesn't allow connections initiated to it's IP address except to it's FQDN 
  • The ASA won't allow the connection if it doesn't have a copy of the CA cert in it's truststore. I got this from blogs. So i installed the Server's root cert under 'CA certificates' in device management using ASDM but it still isn't working. Apparently there are other steps!

I've confirmed that the LDAPS server connection is working using other PC hosts and the ldp.exe tool. My questions now are:-

1. Are the assumptions above right?

2. If they are, could anyone kindly provide a detailed process for the installation of the self-signed Root CA cert on the ASA and any other step which may be required for ASA/AD LDAPS connections? Cryptography, SSl and certs still confuse me quite a bit wrt the ASA i'm afraid.

3. If my assumptions are wrong, what am I missing please!?



Hall of Fame Guru

Assuming you have a good LDAPS setup on your server (which you have indicated you confirmed), your aaa-server config should look something like this:

aaa-server AD (outside) host
 server-port 636
 ldap-base-dn dc=ccielab,dc=mrneteng,dc=com
 ldap-group-base-dn dc=ccielab,dc=mrneteng,dc=com
 ldap-scope subtree
 ldap-naming-attribute sAMAccountName
 ldap-login-password *****
 ldap-over-ssl enable
 server-type microsoft

With that in place, turn on ldap debug and try a test as follows:

ccielab-asa(config)debug ldap 255
ccielab-asa(config)# test aaa-server authorization AD username Administrator
Server IP Address or name:
INFO: Attempting Authorization test to IP address ( (timeout: 12 seconds)

[-2147483631] Session Start
[-2147483631] New request Session, context 0x00007f61d9d106c0, reqType = Other
[-2147483631] Fiber started
[-2147483631] Creating LDAP context with uri=ldaps://
[-2147483631] Connect to LDAP server: ldaps://, status = Successful
[-2147483631] supportedLDAPVersion: value = 3
[-2147483631] supportedLDAPVersion: value = 2
[-2147483631] Binding as
[-2147483631] Performing Simple authentication for to
[-2147483631] LDAP Search:
	Base DN = [dc=ccielab,dc=mrneteng,dc=com]
	Filter  = [sAMAccountName=Administrator]
	Scope   = [SUBTREE]
[-2147483631] User DN = [CN=Administrator,CN=Users,DC=ccielab,DC=mrneteng,DC=com]
[-2147483631] Talking to Active Directory server
[-2147483631] Reading password policy for Administrator, dn:CN=Administrator,CN=Users,DC=ccielab,DC=mrneteng,DC=com
[-2147483631] Read bad password count 0
[-2147483631] LDAP Search:
	Base DN = [dc=ccielab,dc=mrneteng,dc=com]
	Filter  = [sAMAccountName=Administrator]
	Scope   = [SUBTREE]
[-2147483631] Retrieved User Attributes:
[-2147483631] 	objectClass: value = top
[-2147483631] 	objectClass: value = person
[-2147483631] 	objectClass: value = organizationalPerson
[-2147483631] 	objectClass: value = user
[-2147483631] 	cn: value = Administrator
[-2147483631] 	description: value = Built-in account for administering the computer/domain
[-2147483631] 	distinguishedName: value = CN=Administrator,CN=Users,DC=ccielab,DC=mrneteng,DC=com
[-2147483631] 	instanceType: value = 4
[-2147483631] 	whenCreated: value = 20170816153636.0Z
[-2147483631] 	whenChanged: value = 20200531000232.0Z
[-2147483631] 	uSNCreated: value = 8244
[-2147483631] 	memberOf: value = CN=IIS_IUSRS,CN=Builtin,DC=ccielab,DC=mrneteng,DC=com
[-2147483631] 	memberOf: value = CN=Group Policy Creator Owners,CN=Users,DC=ccielab,DC=mrneteng,DC=com
[-2147483631] 	memberOf: value = CN=Enterprise Admins,CN=Users,DC=ccielab,DC=mrneteng,DC=com
[-2147483631] 	memberOf: value = CN=Schema Admins,CN=Users,DC=ccielab,DC=mrneteng,DC=com
[-2147483631] 	memberOf: value = CN=Domain Admins,CN=Users,DC=ccielab,DC=mrneteng,DC=com
[-2147483631] 	memberOf: value = CN=Administrators,CN=Builtin,DC=ccielab,DC=mrneteng,DC=com
[-2147483631] 	uSNChanged: value = 116084
[-2147483631] 	name: value = Administrator
[-2147483631] 	objectGUID: value = `U.?.O.K.7^.e.".
[-2147483631] 	userAccountControl: value = 66048
[-2147483631] 	badPwdCount: value = 0
[-2147483631] 	codePage: value = 0
[-2147483631] 	countryCode: value = 0
[-2147483631] 	badPasswordTime: value = 132354433516404270
[-2147483631] 	lastLogon: value = 132354872332428690
[-2147483631] 	pwdLastSet: value = 131473708407122115
[-2147483631] 	primaryGroupID: value = 513
[-2147483631] 	objectSid: value = ............!..A.:.?<.......
[-2147483631] 	adminCount: value = 1
[-2147483631] 	accountExpires: value = 9223372036854775807
[-2147483631] 	logonCount: value = 179
[-2147483631] 	sAMAccountName: value = Administrator
[-2147483631] 	sAMAccountType: value = 805306368
[-2147483631] 	objectCategory: value = CN=Person,CN=Schema,CN=Configuration,DC=ccielab,DC=mrneteng,DC=com
[-2147483631] 	isCriticalSystemObject: value = TRUE
[-2147483631] 	dSCorePropagationData: value = 16010101000000.0Z
[-2147483631] 	lastLogonTimestamp: value = 132353569524989773
[-2147483631] Fiber exit Tx=587 bytes Rx=5184 bytes, status=1
[-2147483631] Session End
INFO: Authorization Successful

As long as you have the server's certificate as a trusted CA certificate, the SSL/TLS handshake should work OK. You can see that happening most easily by doing a packet capture while you do the authentication test. see packets 310, 311, 314 and 315 below:

SSL handshake during LDAPS connectionSSL handshake during LDAPS connection

You import a server certificate as follows (of course using your trustpoint name and server certificate):

ccielab-asa(config)# cry ca trustpoint DCPrime
ccielab-asa(config-ca-trustpoint)# enrollment terminal
ccielab-asa(config-ca-trustpoint)# no ca-check
ccielab-asa(config-ca-trustpoint)# exit
ccielab-asa(config)# cry ca authenticate DCPrime Enter the base 64 encoded CA certificate. End with the word "quit" on a line by itself -----BEGIN CERTIFICATE----- MIIFlTCCBRqgAwIBAgITOAAAAAJxmZ9tThSBEgAAAAAAAjAKBggqhkjOPQQDAjBl MRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbXJuZXRlbmcx FzAVBgoJkiaJk/IsZAEZFgdjY2llbGFiMRswGQYDVQQDExJjY2llbGFiLURDUFJJ TUUtQ0EwHhcNMjAwNjAxMTIxMDQ5WhcNMjEwNjAxMTIxMDQ5WjAnMSUwIwYDVQQD ExxEQ1ByaW1lLmNjaWVsYWIubXJuZXRlbmcuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAmVrY9qn6WrlQH9PAJ/u/b3AvTRpg10h5s9Em0MAbe/kZ ig6ze3caMimXAiwPwwFWoyeKrPIz0xUYLCZV/jceLboSECrLXgxa7RqZDhKxFUcI +JSo8JdjfO8B7iGFF7tgBrD8LBIQUPZbapO6Q63z2pOn4iq6b/CXwAiR4Hlq5wgw TZwZ8PmNToDWicIfV8VvvRzHAcdj9xJYJ2PEBPA8+Zj4KkXjZE4XAadwbsx4aGgx ZuQw2WdyQV3oCfy9Hj/NDdSrbFfZkOnZKvEnNdVXjlau4C8EAoze24YhPZ3hnDlX zsldaxiRqUhb39keNzZAkeL/iNUml3zTEIesKCQsfQIDAQABo4IDGjCCAxYwLwYJ KwYBBAGCNxQCBCIeIABEAG8AbQBhAGkAbgBDAG8AbgB0AHIAbwBsAGwAZQByMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAOBgNVHQ8BAf8EBAMCBaAweAYJ KoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsG CWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQB BTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUFHRUH1HZbU34V71dvLYG ZcYmMHIwHwYDVR0jBBgwFoAUxD0QkeBIIhSiMqtyWiu+Dw7NFQAwgdwGA1UdHwSB 1DCB0TCBzqCBy6CByIaBxWxkYXA6Ly8vQ049Y2NpZWxhYi1EQ1BSSU1FLUNBLENO PURDUHJpbWUsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y2NpZWxhYixEQz1tcm5ldGVuZyxE Qz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNz PWNSTERpc3RyaWJ1dGlvblBvaW50MIHQBggrBgEFBQcBAQSBwzCBwDCBvQYIKwYB BQUHMAKGgbBsZGFwOi8vL0NOPWNjaWVsYWItRENQUklNRS1DQSxDTj1BSUEsQ049 UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJh dGlvbixEQz1jY2llbGFiLERDPW1ybmV0ZW5nLERDPWNvbT9jQUNlcnRpZmljYXRl P2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBIBgNVHREE QTA/oB8GCSsGAQQBgjcZAaASBBBHKkubJoRlSrI6C9lDvmhOghxEQ1ByaW1lLmNj aWVsYWIubXJuZXRlbmcuY29tMAoGCCqGSM49BAMCA2kAMGYCMQCH3h8iAZWklQkh vJPMatl3Cws/q6SN5LJIK9O6h9cXQMumaeIn+WYdjKFtHVxszrMCMQCIIYLox/Yh 2LF/LSG909VxHatngC8Zuum6DSQ96ojZOo3jJ0B78yhv193HGYAzI8A= -----END CERTIFICATE----- quit INFO: Certificate has the following attributes: Fingerprint: 471a87ff 8942a33f b92d85b6 27376502 Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. % Certificate successfully imported ccielab-asa(config)# 





Thank you so very much for such detailed response. I'll implement as advised and respond with findings


Hello once again,


I've tried again as described above but still no luck. As usual if simple LDAP is configured, it works perefectly. Trouble starts when I add config for LDAPS. see output from debug ldap 255 below while using port 389


[-2147483637] Session Start
[-2147483637] New request Session, context 0x00002aaac8ec9b68, reqType = Authentication
[-2147483637] Fiber started
[-2147483637] Creating LDAP context with uri=ldaps://1x.x.x.25:636
[-2147483637] Connect to LDAP server: ldaps://1x.x.x.25:636, status = Failed
[-2147483637] Unable to read rootDSE. Can't contact LDAP server.
[-2147483637] Fiber exit Tx=0 bytes Rx=0 bytes, status=-2
[-2147483637] Session End
ERROR: Authentication Server not responding: AAA Server has been removed


What I noticed however, is the LDAPS server rejects connections that are initiated to its IP address. So i don't know if that's a factor here as the ASA likely sends request to the translated ip address of the LDAPS server. (Not sure if this makes sense).


Secondly, i don't know if I need to create an identity certificate for the ASA in addition to copying the LDAPS server CA 's certificate to its trusted store?







Connecting via the resolved IP address should be fine - note that's how mine did it.

The ASA does need an identity certificate. Self-signed is fine as it's only acting as the client in the transaction.

Are you able to check on the server with a packet capture to verify the packets are received and see the failure (probably during SSL handshake)?

Content for Community-Ad