topic Re: FTD - FMC - AD -- Secure LDAP / LDAP Over SSL -- Discovered Identi in Network Security

FTD - FMC - AD -- Secure LDAP / LDAP Over SSL -- Discovered Identity

NA-School — Wed, 22 Nov 2023 16:25:13 GMT

Hello Community,

I'm a little bit out of my depth here in trying to troubleshoot a few issues around my configuration and wondering if anyone has some insight into this for me.

I'm currently trying to set up remote access for vpn, I would like to utilize SAML integration with Cisco Duo - this part works swimmingly, following the guide, the only change I had to make was for Duo to return the username in order for the authorization from AD_Integration to work.

I have the LDAP mapping working successfully, but one issue that I can't seem to conquer is that I am able to use LDAP over SSL directly from the FMC but not the FTD. I have confirmed that the same root ca certificate is installed on both, I confirmed that the FTD can resolve the host name of both domain controllers, when I switch to back to IP connect for the directory on the AD_Integration the FTD can perform the bind and the lookup, the group gets passed back and the appropriate LDAP map to cisco vpn group profile applies. My only thinking here is that because of the need of two CA's on the FTD, it is trying to use the Duo certificate when doing the LDAP over SSL - I am not sure how to associate the correct trustpoint here?

Another issue I am running into, is that with this configuration the identities are showing up as Discovered Identity\username, not MYDOMAIN\Username - when I switch to only the AD integration, the passive identity works and the MYDOMAIN\username shows up in FMC dashboard for user statistics.

I have turned the debug ldap 255, debug aaa common 255, and watched the authentication happen (this is how I discovered I needed cisco duo to pass the username back and not the email), this works. Cool, but why doesn't the FTD believe it's MYDOMAIN\Username when Duo saml is the authentication and AD is the authorization?

I would like to keep my ACLs tight and utilize the user identity so that I am as secure as possible. Is this possible while utilizing duo as authentication and ad as authorization?

-------------------
Solution for my case:

Discovered via my own replies here - the EE Key was too small, which refers to the RSA key, which in my case was 2048 for the CA root, but the Domain Controller's identity certs were only 1048 - my temporary work around was to enable the weak crypto, via GUI Devices - Certificates - Click the device in question - Click the LOCK to send the command
or via CLI just add the line
crypto ca permit-weak-crypto

I gather that the FMC by default doesn't care about the weak key response.

Re: FTD - FMC - AD + DUO for Remote Access VPN assistance

NA-School — Tue, 21 Nov 2023 22:34:44 GMT

Just wanted to update on some additional details -

FMC vers 7.2.5
FTD vers 7.2.4 (Waiting for scheduled downtime)
----

Server Group: AD_Integration
Server Protocol: ldap
Server Hostname: AD1.MyDomain.local
Server Address: 172.16.28.200
Server port: 636
Server status: FAILED, Server disabled at 02:41:08 UTC Thu Nov 16 2023
Number of pending requests 0
Average round trip time 0ms
Number of authentication requests 4
Number of authorization requests 4
Number of accounting requests 0
Number of retransmissions 0
Number of accepts 0
Number of rejects 0
Number of challenges 0
Number of bad authenticators 0
Number of timeouts 8
Number of unrecognized responses 0

Server Group: AD_Integration
Server Protocol: ldap
Server Address: 172.16.28.100
Server port: 389
Server status: FAILED, Server disabled at 02:59:51 UTC Sun Nov 19 2023
Number of pending requests 0
Average round trip time 0ms
Number of authentication requests 1
Number of authorization requests 14
Number of accounting requests 0
Number of retransmissions 0
Number of accepts 11
Number of rejects 0
Number of challenges 0
Number of bad authenticators 0
Number of timeouts 4
Number of unrecognized responses 0

Server Group: AD_Integration
Server Protocol: ldap
Server Address: 172.16.28.200
Server port: 389
Server status: ACTIVE, Last transaction at 22:37:03 UTC Mon Nov 20 2023
Number of pending requests 0
Average round trip time 0ms
Number of authentication requests 0
Number of authorization requests 8
Number of accounting requests 0
Number of retransmissions 0
Number of accepts 6
Number of rejects 2
Number of challenges 0
Number of bad authenticators 0
Number of timeouts 0
Number of unrecognized responses 0

Server Group: AD_Integration
Server Protocol: ldap
Server Hostname: AD2.MyDomain.local
Server Address: 172.16.28.100
Server port: 636
Server status: ACTIVE, Last transaction at 02:44:16 UTC Sat Nov 18 2023
Number of pending requests 0
Average round trip time 0ms
Number of authentication requests 2
Number of authorization requests 0
Number of accounting requests 0
Number of retransmissions 0
Number of accepts 0
Number of rejects 0
Number of challenges 0
Number of bad authenticators 0
Number of timeouts 2
Number of unrecognized responses 0

--------------------------------------------------
show running-config aaa-server
aaa-server AD_Integration protocol ldap
max-failed-attempts 4
realm-id 2
aaa-server AD_Integration host AD2.MYDOMAIN.local
server-port 636
ldap-base-dn DC=MYDOMAIN,DC=local
ldap-group-base-dn DC=MYDOMAIN,DC=local
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn firepower@MYDOMAIN.local
ldap-over-ssl enable
server-type microsoft
ldap-attribute-map AD_Integration
aaa-server AD_Integration host 172.16.28.100
server-port 389
ldap-base-dn DC=MYDOMAIN,DC=local
ldap-group-base-dn DC=MYDOMAIN,DC=local
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn firepower@MYDOMAIN.local
server-type microsoft
ldap-attribute-map AD_Integration
aaa-server AD_Integration host 172.16.28.200
server-port 389
ldap-base-dn DC=MYDOMAIN,DC=local
ldap-group-base-dn DC=MYDOMAIN,DC=local
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn firepower@MYDOMAIN.local
server-type microsoft
ldap-attribute-map AD_Integration
aaa-server AD_Integration (diagnostic) host AD1.MYDOMAIN.local
server-port 636
ldap-base-dn DC=MYDOMAIN,DC=local
ldap-group-base-dn DC=MYDOMAIN,DC=local
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn firepower@MYDOMAIN.local
ldap-over-ssl enable
server-type microsoft
ldap-attribute-map AD_Integration
----------------------------------------------

On domain controller - ran in an elevated powershell -
netsh trace start capture=yes IPv4.Address=x.x.x.x tracefile=c:\temp\FTD-TO-AD1.etl
where x.x.x.x is my management interface IP of the FTD, I then ran
test aaa-server Authentication AD_Integration host AD1.mydomain.local username tactest password ThePassword
test aaa-server Authentication AD_Integration host 172.16.28.100 username tactest password ThePassword

back to powershell, netsh trace stop

I converted the etl to pcap using https://github.com/microsoft/etl2pcapng/ from the official Microsoft Github repo - ( I see now for my purposes I could have just used netsh convert input=C:/temp/FTD-TO-AD1.etl output=C:/temp/FTD-TO-AD1.txt but that's ok)

I did the same thing for AD2, and from the FMC I utilized Integrations - Others - Realm - Edit - Directory Settings - Edit each LDAP server and tested the appropriate one for each trace.

Great, actionable data.

Wrong, this just made me more confused. The same root-ca cert is installed the same way and validation usage on both the FMC and the FTD, yet,

My packet capture results summarized:
FMC to AD1,AD2 are the same
For the LDAP over SSL test:
TCP ACK (FMC->AD), TCP SYN (AD->FMC), TLSv1.2 Client Hello (FMC->AD) two more TCP acks, then TLSv1.2 exchange, bobs your uncle great. LDAP bind performs, no plain text credentials flying around.
For the no encryption test:
Traffic flying TCP/LDAP protocols, all packets fully readable.

FTD to AD1,AD2:
TCP SYN (FTD->AD), TCP ACK (FTD->AD not sure why it sends syn and ack to the same spot), SSL 211 Continuation Data with "objectclass0hsupportedLDAPVersionsupportedSASLMechanismsdefaultNamingContextsupportedLDAPPolicies
vendorName" sitting in the packet.

The unencrypted works exactly the same as the FMC, succesfully bind/authentication etc.

Scratching my head I decided to do a packet capture from FMC GUI - Via Devices - Packet Capture - Select my FTD - run on the inside interface, I tried the diagnostic interface and saw no traffic, protocol TCP, source host my FTD management IP, destination host, AD1 did the same thing and now I can see when it tries to LDAP over SSL that TCP ack, TCP syn, and the SSL continue goes from FTD -> FMC, the ad slaps back a tcp flag 0x014 and resets the connection.

I'm thinking I must have messed up my certificate for the root ca import, but I've done it a thousand different ways. Signing it from the CA, not signing it, importing a fully cooked up pk12 using openssl with subject alternative names, I'm definitely missing something easy here and it's driving me bonkers.

Going to try to remove all of the certificates and leave only the root ca and see how the LDAP over ssl bind goes.

Re: FTD - FMC - AD + DUO for Remote Access VPN assistance

NA-School — Wed, 22 Nov 2023 15:16:19 GMT

Doing some more investigation;
FMC - Device - Platform Settings - Syslog - Logging Destinations

Added Console with an event list,

In the event list tab, created new event list, added CA debugging, and SSL debugging.

Ran a test-aaa server again, below is the relevant output - EE Key too small. The key is rsa 2048, so this is confusing.. going to actually remove all the certificates now and start fresh -

[-2147483575] Creating LDAP context with uri=ldaps://172.16.28.100:636 Nov 22 2023 14:40:58 FTD : %FTD-7-725013: SSL server Inside:172.16.254.254/25301 to 172.16.28.100/636 chooses cipher ECDHE-RSA-AES256-GCM-SHA384 Nov 22 2023 14:40:58 FTD : %FTD-6-725005: SSL server Inside:172.16.254.254/25301 to 172.16.28.100/636 requesting our device certificate for authentication Nov 22 2023 14:40:58 FTD : %FTD-7-717025: Validating certificate chain containing 1 certificate(s). Nov 22 2023 14:40:58 FTD : %FTD-7-717029: Identified client certificate within certificate chain. serial number: 48000000035874656DE2EED1D1000000000003, subject name: CN=AD1.mydomain.local. Nov 22 2023 14:40:58 FTD : %FTD-3-717009: Certificate validation failed. EE key is too small, serial number: 48000000035874656DE2EED1D1000000000003, subject name: CN=AD1.mydomain.local. Nov 22 2023 14:40:58 FTD : %FTD-3-717027: Certificate chain failed validation. Generic validation failure occurred. Nov 22

Re: FTD - FMC - AD + DUO for Remote Access VPN assistance

NA-School — Wed, 22 Nov 2023 16:26:24 GMT

Needed to add to running-config on ftd
crypto ca permit-weak-crypto

the DCs were replying with only 1048 rsa key size, d'oh.

Re: FTD - FMC - AD -- Secure LDAP / LDAP Over SSL -- Discovered Identi

t1m1 — Thu, 03 Jul 2025 09:44:30 GMT

Hey @NA-School
Do you have any solution to the other issue with the "Discovered Identity\username".
My setup uses just LDAP fpr Authorsation and SAML with Azure for Authentication.
Both are working, but the mapping to the domain won't happen.

Any idea what I could do to fix it?