Cisco Secure Firewall FTD uses LDAP attribute maps for authorisation of Remote Access VPN and applying different settings such as Group Policy, IP pool, DHCP network scopes, ACL etc based on LDAP/AD group membership.
In this post, a Remote Access VPN is setup on an FTD using AD as an authentication source. Users in different AD groups require different settings when connected to the VPN. The following group policies will be created: –
- A group policy called SplitTunnel will allow split tunnelling and applied to AD group “SplitTunnelUsers”
- A group policy called NoSplitTunnel will be configured and not allow split tunnelling and applied to AD group “NoSplitTunnelUsers”
- A group policy called NOACCESS will be configured that denies user logins, this will be applied as the default group policy, any user that is not a member of an explicit AD group will receive this group policy and be denied access.
Refer to the previous posts on creating and a Realm and configuring Remote Access VPN on FTD, which are used as a starting point for this post.
Software
The information in this post is based on software versions: –
- Cisco FMC version 7.7
- Cisco FTD version 7.7
Configuration
The following configuration is applied on the Cisco Secure Firewall Management Centre (FMC).
- Login to the FMC
- Navigate to Devices > VPN > Remote Access
- Edit the existing Remote Access VPN Policy
In this example a Connection Profile called RAVPN is already configured using AD as the authentication source.
- Click Advanced > Group Policies
- Click + to create a associate a group policy to this Remote Access VPN configuration
If no existing Group Policies have been created, click + to create a new Group Policy.
- Enter the name as NOACCESS
- Navigate to Advanced > Session Settings
- Change Simultaneous Login Per User to 0
- Click Save
- Click + to add another Group Policy
- Enter an appropriate Name, i.e., SplitTunnel
- Click IP Address Pools and assign the IP pool
- Click Split Tunneling
- From the IPv4 Split Tunneling drop-down list, select Tunnel networks specified below
- Click + next to Standard Access List
- Enter a appropriate name for the ACL, i.e., SplitTunnelACL
- Click Add
- Define the Selected Networks to Allow
- Click Add
- Click Save to complete the ACL configuration
- Click Save to complete the configuration of the Group Policy
- Click + to add another Group Policy
- Enter an appropriate Name, i.e., NoSplitTunnel
- Click IP Address Pools and assign the IP pool
Additional settings can be configured if required.
- Click Save
This should return you back to select the Group Policies to associate with the Remote Access VPN configuration.
- Select the three new group policies
- Click Ok
- Click LDAP Attribute Mapping
- Click + to create a new LDAP Attribute Mapping
- Select the preconfigure Realm from the drop-drop list
- From the LDAP Attribute Name drop-down list, select memberOf
- From the Cisco Attribute Name drop-down list, select Group-Policy
- Click Add Value Map
- Enter the LDAP Attribute Value using the Distinguished Name of the LDAP/AD Group, i.e., CN=SplitTunnelUsers,OU=Company,DC=lab,DC=local
- From the Cisco Attribute Value drop-down list, select SplitTunnel group policy.
- Click Add Value Map to add an additional mapping
- Enter the LDAP Attribute Value using the Distinguished Name of the LDAP/AD Group, i.e., CN=NoSplitTunnelUsers,OU=Company,DC=lab,DC=local
- From the Cisco Attribute Value drop-down list, select NoSplitTunnel group policy.
- Click Ok
The output below confirms the configuration of the LDAP attribute mapping.
- Click the Connection Profile tab
- Edit the Connection Profile
- From the Group Policy drop-down list, select the NOACCESS group policy.
- Click Save
If the authenticating user is not a member of the correct AD groups (as defined in the LDAP attribute mapping) then the NOACCESS group policy will be applied, which only allows 0 logins (denying authentications).
- Click Save to save all the changes
- Deploy the policy to the FTD
Testing/Verification
First test login as a user that is a member of the AD group “NoSplitTunnelUsers”
- From the client computer, connect to the VPN and open the Cisco Secure Client once connected. We can confirm the Tunnel Mode is Tunnel All Traffic (i.e, no split tunnel).
From the FTD CLI run the command show vpn-sessiondb anyconnect. From the output below we can confirm the Group Poicy NoSplitTunnel is applied
> show vpn-sessiondb anyconnect Session Type: AnyConnect Username : user2 Index : 9 Assigned IP : 192.168.21.1 Public IP : 192.168.20.10 Protocol : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel License : AnyConnect Premium Encryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)AES-GCM-128 DTLS-Tunn el: (1)AES-GCM-256 Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA256 DTLS-Tunnel: ( 1)SHA384 Bytes Tx : 14090 Bytes Rx : 26663 Group Policy : NoSplitTunnel Tunnel Group : RAVPN Login Time : 12:02:33 UTC Thu Feb 19 2026 Duration : 0h:08m:50s Inactivity : 0h:00m:00s VLAN Mapping : N/A VLAN : none Audt Sess ID : c0a80a2a000090006996fbd9 Security Grp : none Tunnel Zone : 0
From the client computer, login as a user that is a member of the “SplitTunnelUsers” AD group.
Open the Cisco Secure Client once connected, we can confirm the Tunnel Mode is Split Include
- Click the Route Details tab
The output below confirms the Secure Routes is 192.168.10.0/24 which the network defined in the Standard ACL referenced in the SplitTunnel group policy.
From the FTD CLI run the command show vpn-sessiondb anyconnect, from the output below we can confirm the Group Policy is SplitTunnel.
> show vpn-sessiondb anyconnect Session Type: AnyConnect Username : user1 Index : 13 Public IP : 192.168.20.10 Protocol : AnyConnect-Parent License : AnyConnect Premium Encryption : AnyConnect-Parent: (1)none Hashing : AnyConnect-Parent: (1)none Bytes Tx : 0 Bytes Rx : 0 Group Policy : SplitTunnel Tunnel Group : RAVPN Login Time : 12:20:28 UTC Thu Feb 19 2026 Duration : 0h:00m:16s Inactivity : 0h:00m:00s VLAN Mapping : N/A VLAN : none Audt Sess ID : c0a80a2a0000d0006997000c Security Grp : none Tunnel Zone : 0
Run the command system support diagnostic-cli and enable LDAP debugging using the command debug ldap 255
From the output below we can see the FTD queries LDAP and determines the user is a member of the correct AD group SplitTunnelUsers and mapped the Group Policy to SplitTunnel.
> system support diagnostic-cli FTD77# debug ldap 255 [29] Session Start [29] New request Session, context 0x000014a13c7b8438, reqType = Authentication [29] Fiber started [29] Creating LDAP context with uri=ldap://192.168.10.4:389 [29] Connection to LDAP server: ldap://192.168.10.4:389, status = Successful [29] supportedLDAPVersion: value = 3 [29] supportedLDAPVersion: value = 2 [29] Binding as (svc_ldap@lab.local) [svc_ldap@lab.local] [29] Performing Simple authentication for svc_ldap@lab.local to 192.168.10.4 [29] LDAP Search: Base DN = [dc=lab,dc=local] Filter = [sAMAccountName=user1] Scope = [SUBTREE] [29] User DN = [CN=user1,OU=Company,DC=lab,DC=local] [29] Talking to Active Directory server 192.168.10.4 [29] Reading password policy for user1, dn:CN=user1,OU=Company,DC=lab,DC=local [29] Read bad password count 0 [29] Binding as (user1) [CN=user1,OU=Company,DC=lab,DC=local] [29] Performing Simple authentication for user1 to 192.168.10.4 [29] Processing LDAP response for user user1 [29] Message (user1): [29] Checking password policy [29] Authentication successful for user1 to 192.168.10.4 [29] Retrieved User Attributes: [29] objectClass: value = top [29] objectClass: value = person [29] objectClass: value = organizationalPerson [29] objectClass: value = user [29] cn: value = user1 [29] givenName: value = user1 [29] distinguishedName: value = CN=user1,OU=Company,DC=lab,DC=local [29] instanceType: value = 4 [29] whenCreated: value = 20240104105034.0Z [29] whenChanged: value = 20260219101931.0Z [29] displayName: value = user1 [29] uSNCreated: value = 20527 [29] memberOf: value = CN=SplitTunnelUsers,OU=Company,DC=lab,DC=local [29] mapped to Group-Policy: value = SplitTunnel [29] mapped to LDAP-Class: value = SplitTunnel [29] memberOf: value = CN=Group-1,OU=Company,DC=lab,DC=local [29] mapped to Group-Policy: value = CN=Group-1,OU=Company,DC=lab,DC=local [29] mapped to LDAP-Class: value = CN=Group-1,OU=Company,DC=lab,DC=local [29] uSNChanged: value = 254066 [29] name: value = user1 [29] objectGUID: value = .......@..e...E. [29] userAccountControl: value = 66048 [29] badPwdCount: value = 0 [29] codePage: value = 0 [29] countryCode: value = 0 [29] badPasswordTime: value = 134159779221686080 [29] lastLogoff: value = 0 [29] lastLogon: value = 134159779297551133 [29] pwdLastSet: value = 133488390346210851 [29] primaryGroupID: value = 513 [29] objectSid: value = .............9....[.8sUIW... [29] accountExpires: value = 9223372036854775807 [29] logonCount: value = 0 [29] sAMAccountName: value = user1 [29] sAMAccountType: value = 805306368 [29] userPrincipalName: value = user1@lab.local [29] objectCategory: value = CN=Person,CN=Schema,CN=Configuration,DC=lab,DC=local [29] dSCorePropagationData: value = 20251109104550.0Z [29] dSCorePropagationData: value = 20251109104527.0Z [29] dSCorePropagationData: value = 20240104105034.0Z [29] dSCorePropagationData: value = 16010101000000.0Z [29] lastLogonTimestamp: value = 134159699712934088 [29] Fiber exit Tx=610 bytes Rx=2885 bytes, status=1 [29] Session End
Login as a user that is neither a member of SplitTunnelUsers or NoSplitTunnelUsers and observe the debug output.
The Secure Client will report that “Authentication Failed” and not login the user.
From the FTD CLI ldap debugging information, we can confirm that “38] Authentication successful for administrator to 192.168.10.4” the FTD then checks the group membership and there is no match against either the SplitTunnelUsers or NoSplitTunnelUsers AD groups.
Unfortunately, the output does not explicitly state why user authentication failed (despite valid AD credentials), however we know it failed because the users was not in the correct AD group and was assigned the default group policy which denies authentication.
FTD77# [38] Session Start [38] New request Session, context 0x000014a13c7b8438, reqType = Authentication [38] Fiber started [38] Creating LDAP context with uri=ldap://192.168.10.4:389 [38] Connection to LDAP server: ldap://192.168.10.4:389, status = Successful [38] supportedLDAPVersion: value = 3 [38] supportedLDAPVersion: value = 2 [38] Binding as (svc_ldap@lab.local) [svc_ldap@lab.local] [38] Performing Simple authentication for svc_ldap@lab.local to 192.168.10.4 [38] LDAP Search: Base DN = [dc=lab,dc=local] Filter = [sAMAccountName=administrator] Scope = [SUBTREE] [38] User DN = [CN=Administrator,CN=Users,DC=lab,DC=local] [38] Talking to Active Directory server 192.168.10.4 [38] Reading password policy for administrator, dn:CN=Administrator,CN=Users,DC=lab,DC=local [38] Read bad password count 0 [38] Binding as (administrator) [CN=Administrator,CN=Users,DC=lab,DC=local] [38] Performing Simple authentication for administrator to 192.168.10.4 [38] Processing LDAP response for user administrator [38] Message (administrator): [38] Checking password policy [38] Authentication successful for administrator to 192.168.10.4 [38] Retrieved User Attributes: [38] objectClass: value = top [38] objectClass: value = person [38] objectClass: value = organizationalPerson [38] objectClass: value = user [38] cn: value = Administrator [38] description: value = Built-in account for administering the computer/domain [38] distinguishedName: value = CN=Administrator,CN=Users,DC=lab,DC=local [38] instanceType: value = 4 [38] whenCreated: value = 20240103131306.0Z [38] whenChanged: value = 20260219101249.0Z [38] uSNCreated: value = 8196 [38] memberOf: value = CN=Group Policy Creator Owners,CN=Users,DC=lab,DC=local [38] mapped to Group-Policy: value = CN=Group Policy Creator Owners,CN=Users,DC=lab,DC=local [38] mapped to LDAP-Class: value = CN=Group Policy Creator Owners,CN=Users,DC=lab,DC=local [38] memberOf: value = CN=Domain Admins,CN=Users,DC=lab,DC=local [38] mapped to Group-Policy: value = CN=Domain Admins,CN=Users,DC=lab,DC=local [38] mapped to LDAP-Class: value = CN=Domain Admins,CN=Users,DC=lab,DC=local [38] memberOf: value = CN=Enterprise Admins,CN=Users,DC=lab,DC=local [38] mapped to Group-Policy: value = CN=Enterprise Admins,CN=Users,DC=lab,DC=local [38] mapped to LDAP-Class: value = CN=Enterprise Admins,CN=Users,DC=lab,DC=local [38] memberOf: value = CN=Schema Admins,CN=Users,DC=lab,DC=local [38] mapped to Group-Policy: value = CN=Schema Admins,CN=Users,DC=lab,DC=local [38] mapped to LDAP-Class: value = CN=Schema Admins,CN=Users,DC=lab,DC=local [38] memberOf: value = CN=Administrators,CN=Builtin,DC=lab,DC=local [38] mapped to Group-Policy: value = CN=Administrators,CN=Builtin,DC=lab,DC=local [38] mapped to LDAP-Class: value = CN=Administrators,CN=Builtin,DC=lab,DC=local [38] uSNChanged: value = 254062 [38] name: value = Administrator [38] Session End
Summary
This post demonstrates how simple it is to create an LDAP attribute mapping policy, applying different settings to groups of LDAP/AD users. Multiple settings can be configured within the different group policy such as DHCP network scope, IP pool etc.
One drawback of using LDAP for authorisation is that you cannot configure multiple maps with the same LDAP attribute name. So for example, if you want to use memberOf attribute name to match users you could not create one rule to assign a group policy to AD group 1 and another value map to assign an IP pool or DHCP scope to AD group 2.
Using a RADIUS server would be more flexible than using LDAP attribute map.