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

Revenue_admin · ‎05-31-2020

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.

Setup:

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!?

Regards

Marvin Rhoads · ‎06-01-2020

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 dcprime.ccielab.mrneteng.com
 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-login-dn Administrator@ccielab.mrneteng.com
 ldap-over-ssl enable
 server-type microsoft
ccielab-asa#

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: dcprime.ccielab.mrneteng.com
INFO: Attempting Authorization test to IP address (192.168.0.110) (timeout: 12 seconds)

[-2147483631] Session Start
[-2147483631] New request Session, context 0x00007f61d9d106c0, reqType = Other
[-2147483631] Fiber started
[-2147483631] Creating LDAP context with uri=ldaps://192.168.0.110:636
[-2147483631] Connect to LDAP server: ldaps://192.168.0.110:636, status = Successful
[-2147483631] supportedLDAPVersion: value = 3
[-2147483631] supportedLDAPVersion: value = 2
[-2147483631] Binding as Administrator@ccielab.mrneteng.com
[-2147483631] Performing Simple authentication for Administrator@ccielab.mrneteng.com to 192.168.0.110
[-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 192.168.0.110
[-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
ccielab-asa(config)#

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 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)#

Revenue_admin · ‎06-01-2020

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

Revenue_admin · ‎06-02-2020

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?

Marvin Rhoads · ‎06-02-2020

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)?

j.a.m.e.s · ‎09-17-2021

I just resolved a similar issue after hours of troubleshooting - I was missing the domain controller's CA cert on the ASA, then after that the CRL check contained within this cert was blocked by our internal FW.

These are my tips:

1. If you have OpenSSL on a nearby server, point it at your domain controller to work out the CA which signed the DC's certificate:

openssl s_client -connect <domaincontroller>:636 -showcerts 2>/dev/null | openssl x509 -text

Make sure that CA cert is loaded into a trustpoint on the ASA.

2. The most important debugs for me were:

debug ldap 255 - not that useful. Just showed "Unable to read rootDSE"
debug crypto ca 14 - showed the SSL negotiation, including the CRL checks
capture CAP1 interface inside match tcp any any eq 636 THEN copy /pcap capture CAP1 ... - showed the Domain Controller issuing a ServerHello so presumably it was happy with the ASA ciphers

Revenue_admin · ‎09-17-2021

Hi j.a.m.e.s,

We decided to go another route by authenticating through Cisco ISE to active directory. But I'd still make out time to try out your suggestions and see and se how it works out.

Many thanks!