Solved: Re: Firepower AnyConnect LDAP/AD Authentication Issue

pncisco216 · ‎03-19-2020

Hello,

We are having issues setting up firepower anyconnect authentication with LDAP/AD. We have a realm setup with our AD servers. We can obtain users/groups from AD with it, and can authenticate into the FMC with AD credentials. However, when it comes to anyconnect VPN authentication, we have issues using this realm. When we try to connect with the anyconnect client, or try to download it, there is an almost instant "login error" message. Also, testing on the command line yields a "no such server" message.

> test aaa-server authentication <server group> host <name or IP> username <username> password <password>
ERROR: No such server <name or IP>

We can ping the authentication server by IP or name from the command line, and the aaa server statistics go up for requests and timeouts, when trying to connect with the anyconnect client.

>show aaa-server <server group>

Number of authentication requests 10

Number of timeouts 10

It appears that the FTD is unable to communicate with the authentication server for VPN authentication, but we cannot figure out why. Any suggestions or additional debugging/logging to check would be appreciated.

Thank you

Rahul Govindan · ‎03-20-2020

Yes, open the .cer file for the CA cert in a text editor and you should see a PEM encoded cert. Something like this:

Copy that manual enrollment into the FMC:

Next, on the FMC, go to Devices>Certificates and click 'Add'. Choose your FTD and the newly created manual cert enrollment object.

Save and Deploy this to your FTD. This essentially creates a new trustpoint on the FTD backend that allows it to trust the cert coming from the LDAPS server.

This behavior changed in 6.5. In previous versions, the FTD did not need to trust the LDAPS certificate. I tried to talk TAC into opening a bug for this, but they did not deem it necessary, even though there is absolutely no documentation of the behavior change or workaround needed. The ASA behavior change is noted here:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa913/release/notes/asarn913.html#id_9545

Beginning with 9.13(1), the ASA establishes an LDAP/SSL connection only if one of the following certification criteria is satisfied:

The LDAP server certificate is trusted (exists in a trustpoint or the ASA trustpool) and is valid.

A CA certificate from servers issuing chain is trusted (exists in a trustpoint or the ASA trustpool) and all subordinate CA certificates in the chain are complete and valid.

View solution in original post

pncisco216 · ‎03-20-2020

Rahul,

Thank you again for your help.

I am going to mark this as solved.

Paul

View solution in original post

Cristian Matei · ‎03-19-2020

Hi,

Run the debugs and post the output. What version are you running, you may hit a bug?

system support diagnostic-cli

debug ldap 250

debug aaa common 250

Regards,

Cristian Matei.

pncisco216 · ‎03-20-2020

Hello Cristian,

Here is the debug output, and we are running version 6.5.0.4. This seems to indicate what I thought, it cannot contact the authentication server for some reason. Would this be using the management interface, or a data interface? Could our access policy be blocking this? What would the source zone be for traffic originating from the box itself? Could it be an issue/bug with ldaps (secure ldap), as opposed to ldap? Let me know what you think.

Thank you,

Paul

> debug ldap 250
debug ldap  enabled at level 250
> debug aaa common 250
debug aaa common enabled at level 250
> system support diagnostic-cli
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.

fw-corp-01-n1# AAA API: In aaa_open
AAA session opened: handle = 32
AAA API: In aaa_process_async
aaa_process_async: sending AAA_MSG_PROCESS
AAA task: aaa_process_msg(0x000000fff0e63dd8) received message type 0
[32] AAA FSM: In AAA_StartAAATransaction
[32] AAA FSM: In AAA_InitTransaction

Initiating authentication to primary server (Svr Grp: tbaytel.local)
------------------------------------------------
[32] AAA FSM: In AAA_BindServer
[32] AAA_BindServer: Using server: 10.1.1.7
[32] AAA FSM: In AAA_SendMsg
User: phn
Resp:

[38] Session Start
[38] New request Session, context 0x000000ffc017d4b0, reqType = Authentication
[38] Fiber started
[38] Creating LDAP context with uri=ldaps://10.1.1.7:636
[38] Connect to LDAP server: ldaps://10.1.1.7:636, status = Failed
[38] Unable to read rootDSE. Can't contact LDAP server.
callback_aaa_task: status = -2, msg =
[32] AAA FSM: In aaa_backend_callback
aaa_backend_callback: Handle = 32, pAcb = 0x000000ff94858ff8
[38] Fiber exit Tx=0 bytes Rx=0 bytes, status=-2
[38] Session End
AAA task: aaa_process_msg(0x000000fff0e63dd8) received message type 1
[32] AAA FSM: In AAA_ProcSvrResp

Back End response:
------------------
Authentication Status: -2 (SERVICE_DOWN)

[32] AAA FSM: In AAA_BindServer
Marking server tb-org-01.tbaytel.local down in servertag tbaytel.local
Marking server tb-org-01.tbaytel.local in server tag tbaytel.local DNS-LOOKUP-PENDING
AAA_BindServer: No server found
[32] AAA FSM: In AAA_Error
ERROR: No error
[32] AAA FSM: In AAA_Callback
user attributes:
None

User Access-Lists:
user_acl[0] = NULL
user_acl[1] = NULL
user policy attributes:
None

User Policy Access-Lists:
user_acl[0] = NULL
user_acl[1] = NULL
tunnel policy attributes:
None

Tunnel Policy Access-Lists:
user_acl[0] = NULL
user_acl[1] = NULL

Auth Status = ERROR
aaai_internal_cb: handle is 32, pAcb is 0x000000ff94858ff8, pAcb->tq.tqh_first is 0x0000000000000000
AAA API: In aaa_close
AAA task: aaa_process_msg(0x000000fff0e63dd8) received message type 2
In aaai_close_session (32)
Marking server tb-org-01.tbaytel.local in server tag tbaytel.local Up
ldap_client_server_add: Add server:10.1.1.7, group=4
ldap_client_server_unlock: Free server:10.1.1.7, group=4


fw-corp-01-n1# ping 10.1.1.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

pncisco216 · ‎03-20-2020

Hello Cristian,

I reconfigured the realm to use LDAP instead of LDAPS, and the AD authentication works now. Perhaps this is a bug with LDAPS and VPN authentication. The debug now shows successful, when contacting the LDAP server.

Thank you,

Paul

[40] Creating LDAP context with uri=ldap://10.1.1.7:389
[40] Connect to LDAP server: ldap://10.1.1.7:389, status = Successful

Rahul Govindan · ‎03-20-2020

For 6.5 and above, you need the FTD to trust the LDAPS certificate. If you run "debug crypto ca 14" when running the test, you will see that the FTD tries to contact the LDAPS server, but fails at the SSL handshake.

You need to push the LDAPS CA certificate via PKI manual enrollment if you are using the FMC to manage the FTD device.

pncisco216 · ‎03-20-2020

Hello Rahul,

I ran the debug cypto ca 14, and I see what you are talking about. I have the CA certificate for the ldaps certificate, but I am not quite sure I follow what I need to do with it. I am in Objects->PKI->Cert Enrollment and I have the window you have shown. Do I just paste in the certificate and save it, or do I need to do something with the other tabs on the page?

Thank you,

Paul

pncisco216 · ‎03-20-2020

Hello Rahul,

I pasted the certificate in the box and saved it. Following that I went to Devices -> Certificates and added the CA certificate. The LDAPS seems to be working now, but there is still a message on the Devices -> Certificates page stating that "Identity certificate import required". If I click on it, it wants to generate a CSR. Is there something else I need to do here?

Thank you,

Paul

Rahul Govindan · ‎03-20-2020

Yes, open the .cer file for the CA cert in a text editor and you should see a PEM encoded cert. Something like this:

Copy that manual enrollment into the FMC:

Next, on the FMC, go to Devices>Certificates and click 'Add'. Choose your FTD and the newly created manual cert enrollment object.

Save and Deploy this to your FTD. This essentially creates a new trustpoint on the FTD backend that allows it to trust the cert coming from the LDAPS server.

This behavior changed in 6.5. In previous versions, the FTD did not need to trust the LDAPS certificate. I tried to talk TAC into opening a bug for this, but they did not deem it necessary, even though there is absolutely no documentation of the behavior change or workaround needed. The ASA behavior change is noted here:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa913/release/notes/asarn913.html#id_9545

Beginning with 9.13(1), the ASA establishes an LDAP/SSL connection only if one of the following certification criteria is satisfied:

The LDAP server certificate is trusted (exists in a trustpoint or the ASA trustpool) and is valid.

A CA certificate from servers issuing chain is trusted (exists in a trustpoint or the ASA trustpool) and all subordinate CA certificates in the chain are complete and valid.

pncisco216 · ‎03-20-2020

Rahul,

Thank you again for your help.

I am going to mark this as solved.

Paul

kapydan88 · ‎03-30-2020

Can you share your expirience, how did you add ldap/ad server for vpn authentication? Because i found two ways - via object group/radius server and via flexconfig.

pncisco216 · ‎03-30-2020

Hello,

I too, found different ways to setup the AD authentication. I think it may have to with changes between different versions. I am using FTD version 6.5.0.4, and in the end I just setup a Realm under System -> Integration -> Realms. Once I had the working and pulling information from AD, I just selected it as my AAA authentication server in the VPN Remote Access configuration.

Paul

kapydan88 · ‎03-30-2020

I use 6.4.0 version fmc.

Maybe im wrong, but i need to create new realm, for example

name=test.ru

type=ad (because we use ms ad)

ad primary domain=test.ru (domain name)

ad join username=firepower1140@test.ru (service user account)

password=password for firepower1140

directory username=firepower1140@test.ru (service account)

directory password=password=password for firepower1140

base dn=domains name (maybe im worng, but there should be a path to the service account here)

group dn=domains name (maybe im worng, but there should be a path to the service account here)

group attribute=member (refers to the service account)

And after i should to create address of domain controller with port 389...

pncisco216 · ‎03-30-2020

Yes, if I remember correctly you are on the right path.

Create a new realm similar to your example.

Then go to Directory -> add Directory and fill in with a connection to your DC.

If all is working, you should be able to go to User Download and pull information from AD.

kapydan88 · ‎09-09-2020

Can anybody tell me pls, is it possible to add second (or third) dc in realm? We have 4 DC, but only one used for authentication.

kpalmer@naturipefarms.com · ‎01-13-2023

I ran into an issue with FTD 7.0.2. FTD is checking for the Enhanced Key Usage Field. It should contain "Server Authentication". I was able to create a new certificate in Windows Certificate Authority for Duo Proxy and install it into both Duo and FTD.

CRYPTO_PKI: bitValue of KEY_USAGE = a0PKI[7]: CRYPTO_PKI:check_key_usage: Checking KU for case VPN peer certs.

PKI[7]: CRYPTO_PKI:check_key_usage: KU bit digitalSignature is ON.

PKI[7]: ExtendedKeyUsage OID = serverAuth acceptable for usage type: AAA Server

PKI[7]: check_key_usage:Extended Key/Key Usage check OK