Summary: Explains the architecture of Cisco Secure Client VPN authentication on FTD when both SAML and Active Directory are involved — how the two identity systems divide responsibility between authenticating users and authorising their access.
When Cisco Secure Client (formerly AnyConnect) connects to an FTD headend, FTD must answer two distinct questions for every connection:
In a SAML and Active Directory deployment, these two questions are typically answered by different systems. SAML handles authentication: the user proves their identity to an Identity Provider (IdP), which asserts that identity back to FTD. Active Directory handles authorisation: group membership in AD determines which VPN Group Policy the user receives, controlling what they can reach through the tunnel.
Understanding which system does what — and where each configuration lives in FMC — is the key to understanding how this architecture works.
| Component | Role |
|---|---|
| Cisco Secure Client | VPN client on the endpoint; initiates the connection and embeds a browser for SAML redirect |
| FTD | SAML Service Provider (SP); terminates the VPN tunnel; enforces Group Policy |
| FMC | Manages all VPN, SAML, LDAP, DAP, and Group Policy configuration on FTD |
| SAML Identity Provider (IdP) | Authenticates the user; issues a signed SAML assertion to FTD |
| Active Directory | Holds user accounts and group membership; acts as the identity store behind the IdP, and optionally as a direct LDAP source for FTD authorisation |
Active Directory participates in this architecture in two distinct ways, and both may be in use simultaneously.
The SAML IdP — whether that is AD FS on-premises, Entra ID in the cloud, or a third-party product like Okta — validates user credentials and enforces authentication policy. Active Directory is the authoritative source of user accounts, but how closely the IdP contacts AD at authentication time depends on the IdP and its configuration:
In all cases AD remains the identity source of record, but with PHS the on-premises AD is not contacted at the moment of login. From FTD's perspective, the distinction is invisible — it receives a signed SAML assertion regardless of which authentication mode the IdP uses.
After SAML authentication succeeds, FTD can optionally query Active Directory directly over LDAP to retrieve group membership. This is used to assign a VPN Group Policy based on which AD groups the user belongs to. In this model, SAML proves who the user is, and a separate LDAP query to AD determines what they are allowed to do. The two queries are independent — FTD trusts the SAML assertion for identity and trusts its own LDAP lookup for authorisation.
Secure Client → FTD (SP) → HTTP redirect → SAML IdP
↓
User authenticates (+ MFA if configured)
[IdP contacts AD in real time for AD FS / Entra PTA;
AD not contacted at auth time for Entra PHS]
↓
Secure Client ← FTD ← SAML assertion (signed) ← IdP
↓
FTD validates assertion signature
↓
FTD extracts identity claims from assertion
↓
[Optional] FTD queries AD over LDAP for group membership
↓
DAP evaluates claims / LDAP attributes → assigns Group Policy
↓
VPN tunnel established with Group Policy applied
The key detail in this flow is step four. FTD does not forward credentials to AD directly — it receives a signed assertion from the IdP and trusts that the IdP has already authenticated the user. LDAP is only used if FTD is configured to perform its own authorisation lookup.
FTD must assign a Group Policy to each VPN session. Group Policies control split tunnelling, DNS, access control, and other per-user settings. There are two ways to drive Group Policy assignment from Active Directory.
The IdP includes AD group membership in the SAML assertion as attribute claims. FTD receives these claims and uses Dynamic Access Policy (DAP) rules to match claim values to Group Policies.
This approach keeps all authorisation logic at the IdP. The IdP queries AD for group membership, includes the relevant groups as claims in the assertion, and FTD maps those claims to policies. No LDAP server needs to be configured on FTD.
The trade-off is that group membership is determined at authentication time and embedded in the assertion. If a user's AD group membership changes, the change is not reflected until their next SAML authentication. Claim values also vary by IdP — Entra ID sends group Object ID GUIDs rather than display names, which requires careful DAP rule configuration.
FTD is configured with an LDAP authentication server pointing at AD. After the SAML assertion is accepted, FTD performs a separate LDAP bind to AD using the username extracted from the assertion. It retrieves the user's group memberships and maps them to Group Policies using LDAP attribute maps configured in FMC.
This approach gives FTD real-time visibility of AD group membership rather than relying on claims embedded in the assertion. It also uses the same LDAP attribute mapping mechanism that non-SAML deployments use, which can simplify management in mixed environments. The trade-off is additional configuration complexity and a dependency on LDAP connectivity from FTD to AD at authentication time.
Dynamic Access Policy (DAP) is the mechanism FTD uses to evaluate multiple attributes simultaneously and produce a single authorisation decision. A DAP record defines match conditions — which can include SAML assertion attributes, LDAP group attributes, endpoint posture checks, or connection profile name — and the resulting Group Policy to apply when those conditions are met.
DAP records are evaluated in priority order for every VPN session. The first record whose conditions are fully satisfied is applied. A default or catch-all record at low priority handles sessions that do not match any specific rule — typically either denying access or applying a minimal Group Policy.
In a SAML and AD deployment, DAP bridges the two systems: it receives the SAML identity claims on one side and the LDAP group attributes on the other, and produces a single Group Policy assignment as its output.
A Connection Profile (tunnel group in IOS/ASA terminology) defines the authentication method for a set of VPN connections. In FMC, each Connection Profile specifies whether authentication is via SAML, RADIUS, LDAP, or a certificate, and which identity server objects to use.
In a SAML deployment, the Connection Profile:
If an organisation has multiple classes of VPN user — for example, corporate staff and contractors — each class typically gets its own Connection Profile. Each Connection Profile may reference the same IdP or different IdPs, and each has its own ACS URL. The IdP must have a corresponding application registration for each ACS URL.
FMC does not perform authentication or authorisation itself. Its role is to translate the configuration — SAML IdP objects, LDAP server objects, Group Policies, DAP records, Connection Profiles — into the FTD running configuration and push it to the managed firewall. Changes made in FMC take effect on FTD only after a deploy.
The key configuration objects in FMC for this architecture are: