Configure Authentication, Identity, and Access Policies
Domain 3 covers how the appliance learns who a user is and how that identity selects an Access Policy. Authentication realms, sequences, identity profiles, guest handling, and policy evaluation order are all testable.
Realms and sequences
- User authentication options: LDAP (Active Directory or OpenLDAP), NTLMSSP, Kerberos (AD keytab), SAML 2.0, RADIUS, and RSA SecurID.
- An authentication sequence lists realms in order; the WSA tries each and falls through on failure.
- NTLMSSP and Kerberos provide silent SSO when the client can reach the appliance; SAML redirects to an identity provider for browser SSO.
- Authentication caching retains credentials for a configurable period. Surrogate credentials let non-domain-member clients complete NTLM authentication.
- Administrative authentication (GUI/CLI) is separate: local accounts, RADIUS, TACACS+, or LDAP.
Identity profiles and access policies
- Identity profiles match users or groups from a realm, an IP address or subnet, a proxy port, or unauthenticated/guest traffic.
- Access policies evaluate top-down; the first match wins, and the global default policy catches everything remaining.
- Policy membership can also include URL category, web reputation, time range, and user agent.
- Actions include Allow, Monitor, Block, Warn (the user may proceed), and Quarantine (the user must acknowledge before proceeding).
Worked example
Contractors on 10.20.0.0/16 must authenticate and must not reach social media; the Sales AD group should get a warning instead of a block. Reasoning: build an IP-based contractor identity and an access policy above the default that requires authentication and blocks Social Networking. Add an AD-group Sales identity policy above the contractor policy so group membership wins for overlapping addresses. Order matters because the first match wins.
Traps that cost marks
- Placing specific policies beneath the default policy, where they never match.
- Letting IP identity override authenticated identity for the same users.
- Forgetting that unauthenticated users fall to a guest-type identity and may hit a permissive default.
- SAML failures caused by clock skew or an unimported IdP metadata/certificate.
- Kerberos failures from a wrong SPN or keytab, and NTLM failures when clients cannot reach the WSA directly.