Configure AD Authentication for AnyConnect Clients

Introduction

This document describes how to configure Active Directory (AD) authentication for AnyConnect clients that connect to Firepower Threat Defense (FTD).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• RA Virtual Private Network (VPN) configuration on Firepower Manage Center (FMC)
• Lightweight Directory Access Protocol (LDAP) server configuration on FMC
• Active Directory (AD)
• Fully Qualified Domain Name (FQDN)
• Intersight Infrastructure Services (IIS)
• Remote Desktop Protoco (RDP)

Components Used

The information in this document is based on these software and hardware versions:

• Microsoft 2016 Server
• FMCv running 6.5.0
• FTDv running 6.5.0

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

This document describes how to configure Active Directory (AD) authentication for AnyConnect clients that connect to Firepower Threat Defense (FTD), managed by Firepower Management Center (FMC).

User identity is used in the access policies to restrict AnyConnect users to specific IP addresses and ports.

Configure

Network Diagram and Scenario

Windows server is pre-configured with IIS and RDP in order to test user identity. In this configuration guide, three user accounts and two groups are created.

User Accounts:

• FTD Admin: This is used as the directory account to allow the FTD to bind to the Active Directory server.
• IT Admin: A test administrator account used to demonstrate user identity.
• Test User: A test user account used to demonstrate user identity.

Groups:

• AnyConnect Admins: A test group that IT Admin is added to demonstrate user identity. This group only has RDP access to the Windows Server.
• AnyConnect Users: A test group that Test User is added to demonstrate user identity. This group only has HTTP access to the Windows Server.

Active Directory Configurations

In order to appropriately configure AD authentication and user identity on FTD, a few values are required.

All these details must be created or collected on the Microsoft Server before configuration can be done on FMC. The main values are:

• Domain Name:

This is the domain name of the server. In this configuration guide, example.com is the domain name.

• Server IP/FQDN Address:

The IP address or the FQDN used to reach the Microsoft server. If an FQDN is used, a DNS server must be configured within FMC and FTD to resolve the FQDN.

In this configuration guide, this value is win2016.example.com (which resolves to 192.168.1.1).

• Server port:

The port used by the LDAP service. By default, LDAP and STARTTLS uses TCP port 389 for LDAP, and LDAP over SSL (LDAPS) uses TCP port 636.

• Root CA:

If LDAPS or STARTTLS is used, the root CA used to sign the SSL certificate used by LDAPS is required.

• Directory Username and Password:

This is the account used by FMC and FTD to bind to the LDAP server and authenticate users and search for users and groups.

An account named FTD Admin is created for this purpose.

• Base and Group Distinguished Name (DN):

The Base DN is the starting point FMC and the FTD tells the Active Directory to begin the search for and authenticate users.

Similarly, the Group DN is the starting point FMC tells the Active Directory where to begin to search for groups for user identity.

In this configuration guide, the root domain example.com is used as the Base DN and Group DN.

However, for a production environment, using a Base DN and Group DN further within the LDAP hierarchy is better.

For example, this LDAP hierarchy:

If an administrator wants users within the Marketing organizational unit to be able to authenticate the base DN can be set to the root (example.com).

However, this also allows User1 under the Finance organizational unit to also log in since the user search begins at the root and go down to Finance, Marketing, and Research.

Base DN set to example.com

In order to restrict the log in to the only user in the Marketing organizational unit and below, the admin can instead set the Base DN to Marketing.

Now only User2 and User3 are able to authenticate because the search starts at Marketing.

Base DN set to Marketing

Note that for more granular control within the FTD for which users are allowed to connect or assigning users different authorization based on their AD attributes, an LDAP authorization map needs to be configured.

More information on this can be found here: Configure AnyConnect LDAP mapping on Firepower Threat Defense (FTD).

This simplified LDAP hierarchy is used in this configuration guide and the DN for the root example.com is used for both the Base DN and the Group DN.

Determine LDAP Base DN and Group DN

1. Open Active Directory Users and Computers.

2. Click root domain (to open the container), next, right-click the root domain, then under View, click Advanced Features.

3. This enables the view of additional properties under the AD objects. For example, to find the DN for the root example.com, right-click example.com then choose Properties.

4. Under Properties, select the Attribute Editor tab. Find distinguishedName under the Attributes, then click View.

5. This opens a new window where the DN can be copied and pasted into FMC later. In this example, the root DN is DC=example,DC=com.

Copy the value and save it for later. Click OK to exit the String Attribute Editor window and click OK again to exit the Properties.

This can be done for multiple objects within Active Directory. For example, these steps are used to find the DN of the User container:

6. The Advanced Features view can be removed by right-clicking the root DN again, then under View, click Advanced Features once more.

Create an FTD Account

This user account allows FMC and the FTD to bind with the active directory in order to search for users and groups and authenticate users.

The purpose of creating a separate FTD account is to prevent unauthorized access elsewhere within the network if the credentials used for binding are compromised.

This account does not need to be within the scope of the Base DN or Group DN.

1. In Active Directory User and Computers, right-click the container/organizational the FTD account is added to.

In this configuration, the FTD account is added under the Users container under the username ftd.admin@example.com.

Right-click Users, then navigate to New > User.

2. Go through the New Object - User Wizard.

3. Verify that the FTD account is created. Two additional accounts are created; IT Admin and Test User.

Create AD Groups and Add users to AD Groups (Optional)

While not required for authentication, groups can be used to make it easier to apply access policies to multiple users as well as LDAP authorization.

In this configuration guide, groups are used to apply access control policy settings later through user identity within FMC.

1. In Active Directory User and Computers, right-click the container or organizational unit the new group is added to.

In this example, the group AnyConnect Admins are added under the Users container. Right-click Users, then navigate to New > Group.

2. Go through the New Object - Group Wizard.

3. Verify that the group is created. The AnyConnect Users group is also created.

4. Right-click the group the user(s) and then choose Properties. In this configuration, the user IT Admin is added to the group AnyConnect Admins and the user Test User is added to the group AnyConnect Users.

5. Under Members tab, click Add.

Enter the user in the field and click Check Names to verify that the user is found. Once verified, click OK.

Verify that the correct user is added then click OK. The user Test User is also added to group AnyConnect Users using the same steps.

Copy the LDAPS SSL Certificate Root (Only Required for LDAPS or STARTTLS)

1. Press Win+R and enter mmc.exe. Then click OK.

2. Navigate to File > Add/Remove Snap-in.

3. Under Available snap-ins, select Certificates then click Add.

4. Select Computer account then click Next.

Click Finish.

5. Click OK.

6. Expand the Personal folder, then click Certificates. The certificate used by LDAPS is issued to the Fully Qualified Domain Name (FQDN) of the windows server. On this server, there are 3 certificates listed.

• A CA Certificate issued to and by example-WIN2016-CA.
• An identity certificate issued to WIN2016 by example-WIN2016-CA.
• An identity certificate issued to win2016.example.com by example-WIN2016-CA.

In this configuration guide, the FQDN is win2016.example.com and so the first 2 certificates are not valid for use as the LDAPS SSL certificate. The identity certificate issued to win2016.example.com is a certificate that was automatically issued by the Windows Server CA service. Double Click the certificate to check the details.

7. To be used as the LDAPS SSL Certificate, the certificate must meet these requirements:

• The common name or DNS Subject Alternate Name matches the FQDN of the Windows Server.
• The Certificate has Server Authentication under the Enhanced Key Usage field.

Under Details tab for the certificate, select Subject and Subject Alternative Name, the FQDN win2016.example.com is present.

Under Enhanced Key Usage, Server Authentication is present.

8. Once that is confirmed, under the Certification Path tab, select the top certificate which is the root CA certificate then click View Certificate.

9. This opens the Certificates details for the root CA certificate.

Under the Details tab, click Copy to File.

10. Go through the Certificate Export Wizard. The Wizard exports the root CA in PEM format.

Select Base-64 encoded X.509.

Select the name of the file and where it is exported to.

Now click Finish.

11. Navigate to the location and open the certificate with a notepad or some other text editor. This shows the PEM format certificate. Save this for later.

-----BEGIN CERTIFICATE-----
MIIDCDCCAfCgAwIBAgIQE4ZG5Z1wT6lONTjooEQyMTANBgkqhkiG9w0BAQsFADAd
MRswGQYDVQQDExJleGFtcGxlLVdJTjIwMTYtQ0EwIBcNMjAwNDI3MTQ1MDU5WhgP
MjA2MDA0MTkxNDUwNTlaMB0xGzAZBgNVBAMTEmV4YW1wbGUtV0lOMjAxNi1DQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI8ghT719NzSQpoQPh0YT67b
Ya+PngsxMyvkewP33QLTAWw1HW1Tb9Mk5BDWOItTaVsgHwPBfd++M+bLn3AiZnHV
OO+k6dVVY/E5qVkEKSGoY+v940S2316lzdwReMOFhgbc2qMertIoficrRhihonuU
Cjyeub3CO+meJUuKom2R47C0D35TUvo/FEHGgXJFaJS1se2UrpNO7KEMkfA1LPuM
aob4XE/OzxYQpPa18djsNnskfcFqD/HOTFQN4+SrOhHWlRnUIQBUaLdQaabhipD/
sVs5PneYJX8YKma821uYI6j90YuytmsHBtCieyC062a8BKqOL7N86HFPFkMA3u8C
AwEAAaNCMEAwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0O
BBYEFD2fJjf7ER9EM/HCxCVFN5QzqEdvMA0GCSqGSIb3DQEBCwUAA4IBAQB31ZJo
vzwVD3c5Q1nrNP+6Mq62OFpYH91k4Ch9S5g/CEOemhcwg8MDIoxW2dTsjenAEt7r
phFIHZoCoSyjBjMgK3xybmoSeg8vBjCXseYNGEmOc9KW1oFmTOvdNVIb7Xpl1IVa
6tALTt3ANRNgREtxPA6yQbthKGavW0Anfsojk9IcDr2vp0MTjlBCxsTscbubRl+D
dLEFKQqmMeYvkVf+a7a64mqPZsG3Uxo0rd6cZxAPkq/ylcdwNSJFfQV3DgZg+R96
9WLCR3Obig6xyo9Zu+lixcWpdrbADO6zMhbEYEhkhOOjBrUEBBI6Cy83iTZ9ejsk
KgwBJXEu33PplW6E
-----END CERTIFICATE-----

12. (Optional) In the situation that there are multiple identity certificates that can be used by LDAPS and there is uncertainty as to which is used, or there is no access to the LDAPS server, it is possible to extract the root ca from a packet capture done on the Windows server or FTD after.

FMC Configurations

Verify Licensing

In order to deploy AnyConnect configuration, the FTD needs to be registered with the smart licensing server, and a valid Plus, Apex, or VPN Only license must be applied to the device.

1. Navigate to System > Licenses > Smart Licensing.

2. Verify that the devices are in compliance and registered successfully. Ensure that the device is registered with an AnyConnect Apex, Plus, or VPN Only License.

Setup Realm

1. Navigate to System > Integration.

2. Under Realms, then click New realm.

3. Fill out the appropriate fields based on the information collected from the Microsoft server. Then click OK.

4. In the new window, select Directory if not already chosen, click Add directory.

Fill out the details for the AD server. Note that if the FQDN is used, FMC and FTD are unable to successfully bind unless DNS is configured to resolve the FQDN.

To setup DNS for FMC, navigate to System > Configuration and select Management Interfaces.

In order to set up DNS for the FTD, navigate to Devices > Platform Settings, create a new policy, or edit a current one then go to DNS.

If LDAPS or STARTTLS is used, click the green + (plus) symbol, give the certificate a name and copy the PEM format root CA certificate. Then click Save.

Select the newly added root CA from the dropdown menu next to SSL Certificate and click STARTTLS or LDAPS.

Click Test to make sure FMC can successfully bind with the Directory Username and password provided in the previous step.

Because these tests are initiated from the FMC and not through one of the routable interfaces configured on the FTD (such as inside, outside, dmz), a successful (or failed) connection does not guarantee the same result for AnyConnect authentication because AnyConnect LDAP authentication requests are initiated from one of the FTD routable interfaces.

For more information about testing LDAP connections from the FTD, review the Test AAA and Packet Capture sections in the Troubleshooting area.

5. Under User Download, download the groups that are used for user identity in later steps.

Check the box for Download users and groups and the column for Available Groups populates with the groups configured within Active Directory.

Groups can be Included or Excluded, however by default all groups found under the Group DN are included.

Specific users can be included or excluded as well. Any included groups and users are available to be selected for user identity later on.

When finished, click Save.

6. Enable the new realm.

7. If LDAPS or STARTTLS is used, the root CA also needs to be trusted by the FTD. In order to do this first navigate to Devices > Certificates.

Click Add in the top right.

Select the FTD, the LDAP configuration is added to then click the + (plus) symbol.

Give the trustpoint a Name then choose Manual enrollment from the Enrollment Type dropdown menu. Paste the PEM root ca certificate here, then click Save.

Verify that the created trustpoint is selected then click Add.

The new trustpoint appears under the FTD. Although it mentions that Identity certificate import is required, it is not required for the FTD to authenticate the SSL certificate sent by the LDAPS server. So, this message can be ignored.

Configure AnyConnect for AD authentication

1. These steps assume no remote access VPN policy has been created already. If one has been created click the edit button for that policy and skip to step 3.

Navigate to Devices > VPN > Remote Access.

Click Add to create a new Remote Access VPN Policy

2. Complete the Remote Access VPN Policy Wizard. Under Policy Assignment, specify a name for the policy and the devices the policy is applied to.

Under Connection Profile, specify the name of Connection Profile which is also used as the group alias that AnyConnect users see when they get connected.

Specify the realm previously created under Authentication Server.

Specify method AnyConnect clients are assigned IP addresses.

Specify the default group policy that is used for this connection profile.

Under AnyConnect, upload and specify the AnyConnect packages that is used.

Under Access & Certificate, specify the interface that AnyConnect users access for AnyConnect.

Create and/or specify the certificate that is used by the FTD during the SSL handshake.

Ensure that the checkbox for Bypass Access Control policy for decrypted traffic (sysopt permit-vpn) is unchecked so that the user identity created later takes effect for RAVPN connections.

Under Summary, review the configuration the click Finish.

3. Under the VPN > Remote Access policy, click Edit icon (pencil) for the appropriate Connection Profile.

Ensure that the Authentication Server is set to the realm created earlier.

Under Advanced Settings, Enable Password Management can be checked to allow users to change their password when or before it expires.

This setting requires that the realm use LDAPS, however. If any changes were made, click Save.

When finished, click Save.

Enable Identity Policy and Configure Security Policies for User Identity

1. Navigate to Policies > Access Control > Identity.

Create a new Identity Policy.

Specify a Name for the new Identity Policy.

2. Click Add Rule.

3. Specify a Name for the new rule. Ensure that it is enabled and the action is set to Passive Authentication.

Click the Realm & Settings tab and select the realm created earlier. Click Add when finished.

4. Click Save.

5. Navigate to Policies > Access Control > Access Control.

6. Edit the Access Control Policy the FTD is configured under.

7. Click the value next to Identity Policy.

Select the Identity Policy created earlier then click OK.

8. Click Add Rule to create an new ACP rule. These steps create a rule to allow the user within the AnyConnect Admins group to connect to devices within the inside network using RDP.

Specify a name for the rule. Ensure that the rule is Enabled and has the appropriate Action.

Under the Zones tab, specify the appropriate zones for the interesting traffic.

RDP traffic initiated by users come in to the FTD sourced from the outside-zone interface and egress the inside-zone.

Under Networks, define the source and destination networks.

Object AnyConnect_Pool includes the IP addresses that is assigned to AnyConnect clients.

Object Inside_Net include the inside network subnet.

Under Users, click the realm created earlier under Available Realms, click the appropriate group/user under Available Users, then click Add to Rule.

If no users or groups are available under the Available Users section, ensure that FMC downloaded the Users and Groups under the realm section and that the appropriate Groups/User are included.

The users/group specified here is checked from the source perspective.

For example, with what has been defined in this rule so far, the FTD  evaluates that the traffic is sourced from the outside-zone and destined to the inside-zone, sourced from the network in the AnyConnect_Pools object and destined to the network in the Inside_Net object, and the traffic is sourced from a user in the AnyConnect Admins group.

Under Ports, custom RDP objects were created and added to allow TCP and UDP port 3389. Notice that RDP could have been added under the Applications section but for simplicity, only the ports are checked.

Finally, ensure that under Logging, Log at End of Connection is checked for additional verification later on. Click Add when done.

9. An additional rule is created for HTTP access to allow users within the group AnyConnect User access to the Windows Server IIS website. Click Save.

Configure NAT Exemption

If there are NAT rules that affect AnyConnect traffic, such as Internet PAT rules, it is important to configure NAT Exemption rules so that AnyConnect traffic is not NAT-affected.

1. Navigate to Devices > NAT.

Select the NAT Policy applied to the FTD.

2. In this NAT Policy, there is a Dynamic PAT at the end which PAT-affects all traffic (including AnyConnect traffic) that egresses the outside interface to the outside interface.

To prevent AnyConnect traffic from being NAT-affected, click Add Rule.

3. Configure a NAT exemption rule, make sure that the rule is a Manual NAT Rule with Type Static. This is a bidirectional NAT rule that applies to AnyConnect traffic.

With these settings, when the FTD detects traffic sourced from Inside_Net and destined to AnyConnect IP address (defined by AnyConnect_Pool), the source is translated to the same value (Inside_Net) and the destination is translated to the same value (AnyConnect_Pool) when traffic ingresses the inside_zone and egresses the outside_zone. This essentially bypasses NAT when these conditions are met.

Additionally, the FTD is set to perform a route lookup on this traffic and not proxy ARP. Click OK when done.

4. Click Save.

Deploy

1. When the configuration is finished, click Deploy.

2. Click the checkbox next to the FTD the configuration is applied to it and then click Deploy.

Verify

Final Configuration

AAA Configuration

> show running-configuration aaa-server
aaa-server LAB-AD protocol ldap
 max-failed-attempts 4
 realm-id 5
aaa-server LAB-AD host win2016.example.com
 server-port 389
 ldap-base-dn DC=example,DC=com
 ldap-group-base-dn DC=example,DC=com
 ldap-scope subtree
 ldap-naming-attribute samaccountname
 ldap-login-password *****
 ldap-login-dn ftd.admin@example.com
 server-type microsoft

AnyConnect Configuration

> show running-config webvpn
webvpn
 enable Outside
 anyconnect image disk0:/csm/anyconnect-linux64-4.7.03052-webdeploy-k9.pkg 1 regex "Linux"
 anyconnect image disk0:/csm/anyconnect-win-4.7.00136-webdeploy-k9.pkg 2 regex "Windows"
 anyconnect profiles Lab disk0:/csm/lab.xml
 anyconnect enable
 tunnel-group-list enable
 cache
  no disable
 error-recovery disable

> show running-config tunnel-group
tunnel-group General type remote-access
tunnel-group General general-attributes
 address-pool AnyConnect-Pool
 authentication-server-group LAB-AD
tunnel-group General webvpn-attributes
 group-alias General enable

> show running-config group-policy
group-policy DfltGrpPolicy attributes
 vpn-simultaneous-logins 10
 vpn-tunnel-protocol ikev2 ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value Lab
 user-authentication-idle-timeout none
 webvpn
  anyconnect keep-installer none
  anyconnect modules value dart
  anyconnect ask none default anyconnect
  http-comp none
  activex-relay disable
  file-entry disable
  file-browsing disable
  url-entry disable
  deny-message none
  anyconnect ssl df-bit-ignore enable

> show running-config ssl
ssl trust-point FTD-2-SelfSigned outside

Connect with AnyConnect and Verify Access Control Policy Rules

User IT Admin is in the group AnyConnect Admins which has RDP access to the Windows Server. However it does not have access to HTTP.

Opening an RDP and Firefox session to this server verifies that this user can only access the server via RDP.

If logged in with user Test User who is in the group AnyConnect Users which as HTTP access but not RDP access, you are able to verify that the access control policy rules are taking effect.

Verify with FMC Connection Events

Since logging was enabled in the Access Control Policy rules, the connection events can be checked for any traffic that matches those rules.

Navigate to Analysis > Connections > Events.

Under the Table View of Connection Events, the logs are filtered to only show connection events for IT Admin.

Here, you can verify that RDP traffic to the server (TCP and UDP 3389) is allowed, however, port 80 traffic is blocked.

For user Test User, you can verify that RDP traffic to the server is blocked and port 80 traffic is allowed.

Troubleshoot

Debugs

This debug can be run in diagnostic CLI to troubleshoot LDAP authentication-related issues: debug ldap 255.

To troubleshoot user identity Access Control Policy issues, the system support firewall-engine-debug can be run in clish to determine why traffic is being allowed or blocked unexpectedly.

Working LDAP Debugs

[53] Session Start
[53] New request Session, context 0x00002b1d13f4bbf0, reqType = Authentication
[53] Fiber started
[53] Creating LDAP context with uri=ldap://192.168.1.1:389
[53] Connect to LDAP server: ldap://192.168.1.1:389, status = Successful
[53] supportedLDAPVersion: value = 3
[53] supportedLDAPVersion: value = 2
[53] LDAP server 192.168.1.1 is Active directory
[53] Binding as ftd.admin@example.com
[53] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1
[53] LDAP Search:
        Base DN = [DC=example,DC=com]
        Filter  = [sAMAccountName=it.admin]
        Scope   = [SUBTREE]
[53] User DN = [CN=IT Admin,CN=Users,DC=example,DC=com]
[53] Talking to Active Directory server 192.168.1.1
[53] Reading password policy for it.admin, dn:CN=IT Admin,CN=Users,DC=example,DC=com
[53] Read bad password count 6
[53] Binding as it.admin
[53] Performing Simple authentication for it.admin to 192.168.1.1
[53] Processing LDAP response for user it.admin
[53] Message (it.admin):
[53] Authentication successful for it.admin to 192.168.1.1
[53] Retrieved User Attributes:
[53]    objectClass: value = top
[53]    objectClass: value = person
[53]    objectClass: value = organizationalPerson
[53]    objectClass: value = user
[53]    cn: value = IT Admin
[53]    sn: value = Admin
[53]    givenName: value = IT
[53]    distinguishedName: value = CN=IT Admin,CN=Users,DC=example,DC=com
[53]    instanceType: value = 4
[53]    whenCreated: value = 20200421025811.0Z
[53]    whenChanged: value = 20200421204622.0Z
[53]    displayName: value = IT Admin
[53]    uSNCreated: value = 25896
[53]    memberOf: value = CN=AnyConnect Admins,CN=Users,DC=example,DC=com
[53]    uSNChanged: value = 26119
[53]    name: value = IT Admin
[53]    objectGUID: value = &...J..O..2w...c
[53]    userAccountControl: value = 512
[53]    badPwdCount: value = 6
[53]    codePage: value = 0
[53]    countryCode: value = 0
[53]    badPasswordTime: value = 132320354378176394
[53]    lastLogoff: value = 0
[53]    lastLogon: value = 0
[53]    pwdLastSet: value = 132319114917186142
[53]    primaryGroupID: value = 513
[53]    objectSid: value = .............{I...;.....j...
[53]    accountExpires: value = 9223372036854775807
[53]    logonCount: value = 0
[53]    sAMAccountName: value = it.admin
[53]    sAMAccountType: value = 805306368
[53]    userPrincipalName: value = it.admin@example.com
[53]    objectCategory: value = CN=Person,CN=Schema,CN=Configuration,DC=example,DC=com
[53]    dSCorePropagationData: value = 16010101000000.0Z
[53]    lastLogonTimestamp: value = 132319755825875876
[53] Fiber exit Tx=515 bytes Rx=2659 bytes, status=1
[53] Session End

Unable to Establish a Connection with LDAP Server

[-2147483611] Session Start
[-2147483611] New request Session, context 0x00007f9e65ccdc40, reqType = Authentication
[-2147483611] Fiber started
[-2147483611] Creating LDAP context with uri=ldap://171.16.1.1:389
[-2147483611] Connect to LDAP server: ldap://172.16.1.1:389, status = Failed
[-2147483611] Unable to read rootDSE. Can't contact LDAP server.
[-2147483611] Fiber exit Tx=0 bytes Rx=0 bytes, status=-2
[-2147483611] Session End

Potential Solutions:

• Check routing and ensure the FTD is receiving a response from the LDAP server.
• If LDAPS or STARTTLS is used, make sure that the correct root CA certificate is trusted so that the SSL handshake can complete successfully.
• Verify that the correct IP address and port are used. If a hostname is used, verify that DNS is able to resolve it to the correct IP address.

Binding Log in DN and/or Password Incorrect

[-2147483615] Session Start
[-2147483615] New request Session, context 0x00007f9e65ccdc40, reqType = Authentication
[-2147483615] Fiber started
[-2147483615] Creating LDAP context with uri=ldap://192.168.1.1:389
[-2147483615] Connect to LDAP server: ldap://192.168.1.1:389, status = Successful
[-2147483615] defaultNamingContext: value = DC=example,DC=com
[-2147483615] supportedLDAPVersion: value = 3
[-2147483615] supportedLDAPVersion: value = 2
[-2147483615] LDAP server 192.168.1.1 is Active directory
[-2147483615] supportedSASLMechanisms: value = GSSAPI
[-2147483615] supportedSASLMechanisms: value = GSS-SPNEGO
[-2147483615] supportedSASLMechanisms: value = EXTERNAL
[-2147483615] supportedSASLMechanisms: value = DIGEST-MD5
[-2147483615] Binding as ftd.admin@example.com
[-2147483615] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1
[-2147483615] Simple authentication for ftd.admin@example.com returned code (49) Invalid credentials
[-2147483615] Failed to bind as administrator returned code (-1) Can't contact LDAP server
[-2147483615] Fiber exit Tx=186 bytes Rx=744 bytes, status=-2
[-2147483615] Session End

Potential Solution: Verify that the Log in DN and Log in password are configured appropriately. This can be verified on the AD server with ldp.exe. In order to verify that an account can successfully bind using ldp, go through these steps:

1. On the AD server, press Win+R and search for ldp.exe

2. Under Connection, select Connect.

3. Specify localhost for server and the appropriate port then click OK.

4. The right column shows text indicating a successful connection. Navigate to Connection > Bind.

5. Select Simple Bind then specify the Directory Account User and Password. Click OK.

With a successful bind, ldp shows Authenticated as: DOMAIN\username

An attempt to bind with an invalid username or password results in a failure such as the two seen here.

LDAP Server Unable to Find the Username

[-2147483612] Session Start
[-2147483612] New request Session, context 0x00007f9e65ccdc40, reqType = Authentication
[-2147483612] Fiber started
[-2147483612] Creating LDAP context with uri=ldap://192.168.1.1:389
[-2147483612] Connect to LDAP server: ldap://192.168.1.1:389, status = Successful
[-2147483612] supportedLDAPVersion: value = 3
[-2147483612] supportedLDAPVersion: value = 2
[-2147483612] LDAP server 192.168.1.1 is Active directory
[-2147483612] Binding as ftd.admin@example.com
[-2147483612] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1
[-2147483612] LDAP Search:
        Base DN = [dc=example,dc=com]
        Filter  = [samaccountname=it.admi]
        Scope   = [SUBTREE]
[-2147483612] Search result parsing returned failure status
[-2147483612] Talking to Active Directory server 192.168.1.1
[-2147483612] Reading password policy for it.admi, dn:
[-2147483612] Binding as ftd.admin@example.com
[-2147483612] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1
[-2147483612] Fiber exit Tx=456 bytes Rx=1082 bytes, status=-1
[-2147483612] Session End

Potential Solution: Verify that AD can find the user with the search done by the FTD. This can be done with ldp.exe as well.

1. After successfully binding as seen above, navigate to View > Tree.

2. Specify the Base DN configured on the FTD then click OK

3. Right-click the Base DN then click Search.

4. Specify the same Base DN, Filter, and Scope values as seen in the debugs.

In this example, these are:

• Base DN: dc=example,dc=com
• Filter: samaccountname=it.admi
• Scope:SUBTREE

ldp finds 0 entries because there is no user account with the sAMAccountname it.admi under the Base DN dc=example,dc=com.

Another attempt with the correct sAMAccountname it.admin shows a different result. ldp finds 1 entry under the Base DN dc=example,dc=com and prints that user DN.

Incorrect Password for the Username

[-2147483613] Session Start
[-2147483613] New request Session, context 0x00007f9e65ccdc40, reqType = Authentication
[-2147483613] Fiber started
[-2147483613] Creating LDAP context with uri=ldap://192.168.1.1:389
[-2147483613] Connect to LDAP server: ldap://192.168.1.1:389, status = Successful
[-2147483613] supportedLDAPVersion: value = 3
[-2147483613] supportedLDAPVersion: value = 2
[-2147483613] LDAP server 192.168.1.1 is Active directory
[-2147483613] Binding as ftd.admin@example.com
[-2147483613] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1
[-2147483613] LDAP Search:
        Base DN = [dc=example,dc=com]
        Filter  = [samaccountname=it.admin]
        Scope   = [SUBTREE]
[-2147483613] User DN = [CN=IT Admin,CN=Users,DC=example,DC=com]
[-2147483613] Talking to Active Directory server 192.168.1.1
[-2147483613] Reading password policy for it.admin, dn:CN=IT Admin,CN=Users,DC=example,DC=com
[-2147483613] Read bad password count 0
[-2147483613] Binding as it.admin
[-2147483613] Performing Simple authentication for it.admin to 192.168.1.1
[-2147483613] Simple authentication for it.admin returned code (49) Invalid credentials
[-2147483613] Message (it.admin): 80090308: LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e, v3839
[-2147483613] Invalid password for it.admin
[-2147483613] Fiber exit Tx=514 bytes Rx=2764 bytes, status=-1
[-2147483613] Session End

Potential Solution: Verify that the user password is configured appropriately and that it is not expired. Similar to the Log in DN, the FTD does a bind against AD with the user credentials.

This bind can also be done in ldp to verify that the AD is able to recognize the same username and password credentials. The steps in ldp are shown in  the section Binding Login DN and/or password incorrect.

Additionally, the Microsoft server Event Viewer logs can be reviewed for a potential failure reason.

Test AAA

The test aaa-server command can be used to simulate an authentication attempt from the FTD with a specific username and password. This can be used to test for connection or authentication failures. The command is test aaa-server authentication [AAA-server] host [AD IP/hostname].

> show running-configuration aaa-server
aaa-server LAB-AD protocol ldap
 realm-id 7
aaa-server LAB-AD host win2016.example.com
 server-port 389
 ldap-base-dn DC=example,DC=com
 ldap-scope subtree
 ldap-login-password *****
 ldap-login-dn ftd.admin@example.com
 server-type auto-detect

> test aaa-server authentication LAB-AD host win2016.example.com
Username: it.admin
Password: ********
INFO: Attempting Authentication test to IP address (192.168.1.1) (timeout: 12 seconds)
INFO: Authentication Successful

Packet Captures

Packet captures can be used to verify reachability to the AD server. If LDAP packets leave the FTD, but there is no response, this could indicate a routing issue.

Capture shows the bidirectional LDAP traffic.

> show route 192.168.1.1

Routing entry for 192.168.1.0 255.255.255.0
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via inside
      Route metric is 0, traffic share count is 1

> capture AD interface inside match tcp any host 192.168.1.1 eq 389

> show capture
capture AD type raw-data interface inside [Capturing - 0 bytes]
  match tcp any host 192.168.1.1 eq ldap

> test aaa-server authentication LAB-AD host win2016.example.com username it.admin password ******
INFO: Attempting Authentication test to IP address (192.168.1.1) (timeout: 12 seconds)
INFO: Authentication Successful

> show capture
capture AD type raw-data interface inside [Capturing - 10905 bytes]
  match tcp any host 192.168.1.1 eq ldap

> show capture AD

54 packets captured

   1: 23:02:16.770712       192.168.1.17.61960 > 192.168.1.1.389: S 3681912834:3681912834(0) win 32768 <mss 1460,nop,nop,timestamp 1061373057 0>
   2: 23:02:16.772009       192.168.1.1.389 > 192.168.1.17.61960: S 491521506:491521506(0) ack 3681912835 win 8192 <mss 1460,nop,nop,timestamp 762393884 1061373057>
   3: 23:02:16.772039       192.168.1.17.61960 > 192.168.1.1.389: . ack 491521507 win 32768 <nop,nop,timestamp 1061373058 762393884>
   4: 23:02:16.772482       192.168.1.17.61960 > 192.168.1.1.389: P 3681912835:3681912980(145) ack 491521507 win 32768 <nop,nop,timestamp 1061373059 0>
   5: 23:02:16.772924       192.168.1.1.389 > 192.168.1.17.61960: P 491521507:491522141(634) ack 3681912980 win 65160 <nop,nop,timestamp 762393885 1061373059>
   6: 23:02:16.772955       192.168.1.17.61960 > 192.168.1.1.389: . ack 491522141 win 32768 <nop,nop,timestamp 1061373059 762393885>
   7: 23:02:16.773428       192.168.1.17.61960 > 192.168.1.1.389: P 3681912980:3681913024(44) ack 491522141 win 32768 <nop,nop,timestamp 1061373060 0>
   8: 23:02:16.775030       192.168.1.1.389 > 192.168.1.17.61960: P 491522141:491522163(22) ack 3681913024 win 65116 <nop,nop,timestamp 762393887 1061373060>
   9: 23:02:16.775075       192.168.1.17.61960 > 192.168.1.1.389: . ack 491522163 win 32768 <nop,nop,timestamp 1061373061 762393887>
[...]
54 packets shown

Windows Server Event Viewer Logs

The Event Viewer logs on the AD server can provide more detailed information as to why a failure occurred.

1. Search for and open Event Viewer.

2. Expand Windows Logs and click Security. Search for Audit Failures with the user account name and review the Failure Information.

An account failed to log on.

Subject:
	Security ID:		SYSTEM
	Account Name:		WIN2016$
	Account Domain:		EXAMPLE
	Logon ID:		0x3E7

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		it.admin
	Account Domain:		EXAMPLE

Failure Information:
	Failure Reason:		The specified user account has expired.
	Status:			0xC0000193
	Sub Status:		0x0

Process Information:
	Caller Process ID:	0x25c
	Caller Process Name:	C:\Windows\System32\lsass.exe

Network Information:
	Workstation Name:	WIN2016
	Source Network Address:	192.168.1.17
	Source Port:		56321