NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will create identity-based access policies on a Zero Trust Access (ZTA) firewall: map Active Directory groups to firewall policies, build per-application access controls, and enable SAML pre-auth redirect for an application group. This is crucial in production because modern enterprises enforce access by user identity and role rather than by IP location — for example, allowing only the Finance AD group to reach payroll apps regardless of where they connect from. You will see how identity information flows from an Identity Provider (IdP) through ISE into the firewall policy engine and how per-application rules are enforced.

Quick Recap

Refer to the topology introduced in Lesson 1. This lesson adds the identity services and application objects used by the ZTA firewall:

Identity Server: ise01.lab.nhprep.com (provides AD group membership and SAML IdP)
ZTA Management/FMC: fmc.lab.nhprep.com (policy management and SAML redirect target)
Application server (example): csdac.lab.nhprep.com

No additional physical devices are added for this lesson. We will configure application objects, a ZTA application group, SAML pre-auth redirect, and identity-based access policy that uses AD group membership.

ASCII Topology (logical):

[User Device] --- Internet --- [ZTA Firewall] --- DMZ --- [csdac.lab.nhprep.com 10.10.10.10]
                                        |
                                        +--- Management --- [fmc.lab.nhprep.com 10.10.20.5]
                                        |
                                        +--- Identity --- [ise01.lab.nhprep.com 10.10.20.10]

All interface IPs used below are shown explicitly in steps and verification outputs.

Key Concepts

Identity-based policy — instead of authorizing by source IP, policies match a user or group obtained from the Identity Provider (IdP) and enforced by the firewall. In production, this allows consistent access control for roaming users and BYOD.
SAML pre-auth redirect — the firewall can intercept an HTTPS access to an application and redirect the browser to a SAML IdP for authentication. After successful authentication, the IdP returns a SAML assertion to the firewall, which maps the user to AD group membership used in policy decisions.
Application grouping — grouping multiple related applications into a single ZTA Application Group enables single sign-on (SSO) behavior and easier policy management. When one app in the group authenticates via SAML, further apps in the group can be accessed without repeating full auth.
Policy evaluation order — firewall evaluates identity-aware rules alongside other attributes (IP/FQDN/protocol/port). Identity matches may fail if the firewall cannot reach the IdP or if the group mapping is absent.
Telemetry and logging — when identity is used, full logging should include username and group to provide for auditing and forensic analysis. In production, integrate logs with SIEM or XDR to detect abnormal account behavior.

Tip: Think of identity-based policy like a VIP list at a club: instead of letting people in by which car they arrived in (IP), the bouncer checks a guest list (AD group) and decides access — and SAML is the ID-check procedure handled by the front-desk receptionist (IdP).

Step-by-step configuration

Step 1: Define Application Objects on the ZTA Firewall

What we are doing: Create the application server object for csdac.lab.nhprep.com (the protected app) and a logical application for HTTPS. This allows the firewall to refer to the app by name in policies rather than by raw IP/port — making policies clearer and resilient to IP changes.

configure terminal
object network OBJ_CSDAC
 host 10.10.10.10
 description csdac.lab.nhprep.com - Application server
exit
application http-https
 protocol tcp
 port 443
exit
write memory

What just happened: The object network command created a host object named OBJ_CSDAC bound to IP 10.10.10.10. The application stanza defined an application qualifier for HTTPS (tcp/443), which we can reference by name in access rules. This abstraction is useful when the app moves across addresses or when you want rules that match FQDN + port.

Real-world note: In production, you typically create application objects for each multi-tier app and reference them in policy to simplify lifecycle changes.

Verify:

show running-config object network OBJ_CSDAC
object network OBJ_CSDAC
 host 10.10.10.10
 description csdac.lab.nhprep.com - Application server

show running-config application | include http-https
application http-https
 protocol tcp
 port 443

Step 2: Create a ZTA Application Group and Add Apps

What we are doing: Group csdac.lab.nhprep.com into a ZTA Application Group named "AppGroup-Finance". This enables SSO-like behavior where authentication to one app can apply to others in the same group and allows the firewall to perform SAML redirect targeting the group.

configure terminal
zta application-group AppGroup-Finance
 member OBJ_CSDAC protocol http-https
 description Finance application group for payroll and HR apps
exit
write memory

What just happened: The zta application-group command created a logical grouping named AppGroup-Finance and added the previously created network object plus the http-https application qualifier as a member. The firewall now can treat the group as a single policy target and perform group-level SAML pre-authentication behavior.

Real-world note: Use application groups for service sets that share the same id/access model (e.g., HR apps, Finance apps) to ease policy management and SSO.

Verify:

show zta application-group AppGroup-Finance
Application Group: AppGroup-Finance
 Description: Finance application group for payroll and HR apps
 Members:
  - OBJ_CSDAC (10.10.10.10) protocol tcp/443

Step 3: Configure SAML IdP Redirect for the Application Group

What we are doing: Configure SAML redirection so that when a user accesses an application in AppGroup-Finance the firewall will redirect the browser to the SAML IdP (ise01.lab.nhprep.com). This implements the pre-auth flow that verifies identity before granting app access.

configure terminal
saml idp ise01
 entity-id https://ise01.lab.nhprep.com/saml
 single-sign-on-url https://ise01.lab.nhprep.com/idp/sso
 certificate trustpoint ISE-SAML-TP
exit

zta application-group AppGroup-Finance
 saml pre-auth redirect idp ise01
exit
write memory

What just happened: We defined a SAML IdP entry named ise01 including entity-id and SSO endpoint, and associated a trustpoint (certificate) used to validate SAML messages. Then we enabled saml pre-auth redirect for the application group so access to any member triggers the redirect. The firewall will now redirect client browsers to the IdP for authentication, receive the SAML assertion, and extract user and group attributes.

Real-world note: In production, the SAML certificate trust relationship is critical — ensure the firewall trusts the IdP cert and validate metadata to avoid authentication failures.

Verify:

show saml idp
IdP Name: ise01
 Entity ID: https://ise01.lab.nhprep.com/saml
 SSO URL: https://ise01.lab.nhprep.com/idp/sso
 Trustpoint: ISE-SAML-TP

show zta application-group AppGroup-Finance | include saml
AppGroup-Finance: SAML pre-auth redirect enabled -> IdP ise01

Step 4: Integrate Identity Source (ISE/AD) and Map Groups

configure terminal
identity-server ise01
 ip address 10.10.20.10
 protocol radius
 shared-secret Lab@123
 attribute-group-map "AD-Group-Map"
exit
write memory

What just happened: The identity-server configuration points the firewall at 10.10.20.10 (ise01.lab.nhprep.com) using RADIUS as the transport and a shared secret. The firewall will query this server to translate a username into its AD group list (the attribute-group-map tells the firewall which RADIUS attributes contain group information). With successful group mapping, policies that match user groups can be evaluated correctly.

Real-world note: In production, your Identity Server typically performs lookups into Active Directory and may deliver groups via RADIUS attributes or through a separate SCIM/SAML profile. Ensure your identity source is highly available.

Verify:

show identity-server status
Identity Server: ise01 (10.10.20.10)
 Protocol: radius
 Status: reachable
 Last query status: success
 Mapped group attributes: AD-Group-Map

Step 5: Create Identity-Based Access Policy

What we are doing: Create an access rule that permits members of the AD group FinanceUsers to access AppGroup-Finance. All other users are denied by default. This enforces least privilege by user role.

configure terminal
access-policy ZTA-Identity-Policy
 rule 10
  name Allow-Finance-App
  source any
  destination AppGroup-Finance
  identity-group "FinanceUsers"
  action permit
 exit
 rule 20
  name Deny-Other-App
  source any
  destination AppGroup-Finance
  action deny
 exit
apply access-policy ZTA-Identity-Policy
exit
write memory

What just happened: The access policy ZTA-Identity-Policy contains a rule (10) that matches any source attempting to reach AppGroup-Finance but only permits the traffic if the authenticated user is a member of FinanceUsers. Rule 20 explicitly denies other access attempts to the same destination. On a packet level, when the firewall receives a connection attempt, it checks for an existing authenticated session (from SAML pre-auth or ZTA client). If identity attributes are present and include FinanceUsers, the packet is allowed; otherwise dropped.

Real-world note: Ordering matters. Place precise allow rules above deny rules and make sure identity mapping is working before relying on open/deny order.

Verify:

show access-policy ZTA-Identity-Policy
Access Policy: ZTA-Identity-Policy
 Rule 10: Allow-Finance-App
  Source: any
  Destination: AppGroup-Finance (OBJ_CSDAC 10.10.10.10 tcp/443)
  Identity Group: FinanceUsers
  Action: permit
 Rule 20: Deny-Other-App
  Source: any
  Destination: AppGroup-Finance
  Action: deny

Verification Checklist

Check 1: Application object exists and resolves to correct IP.
- Command: show running-config object network OBJ_CSDAC
- Expected: host 10.10.10.10 with description csdac.lab.nhprep.com
Check 2: SAML IdP and pre-auth redirect enabled for AppGroup-Finance.
- Command: show saml idp and show zta application-group AppGroup-Finance
- Expected: IdP ise01 configured and AppGroup shows SAML pre-auth redirect -> IdP ise01
Check 3: Identity server reachable and group mapping works.
- Command: show identity-server status
- Expected: Status: reachable and Last query status: success
Check 4: Access policy contains identity-based allow and deny rules.
- Command: show access-policy ZTA-Identity-Policy
- Expected: Rule permitting FinanceUsers to AppGroup-Finance and a subsequent deny.

Common Mistakes

Symptom	Cause	Fix
Users are redirected but still denied access after SAML login	Firewall cannot map SAML assertion attributes to AD groups (attribute mapping mismatch)	Verify SAML attribute names in the IdP, and update `attribute-group-map` on the firewall to match exact attribute names.
SAML redirect fails with certificate error	Trustpoint/certificate for IdP not installed or mismatched	Import and trust the IdP signing certificate on the firewall (`certificate trustpoint ISE-SAML-TP`) and verify entity IDs match.
Access allowed to non-Finance users	Access rule order places a broad permit ahead of identity-based rule	Reorder policy so identity-specific allow (FinanceUsers) is above broader permits, or add explicit deny for others.
Firewall shows identity-server unreachable	Network connectivity or shared-secret mismatch with ise01	Confirm IP connectivity (ping 10.10.20.10), verify RADIUS/LDAP shared secret matches, and check firewall/ISE logs for error details.

Key Takeaways

Identity-based access enables policies that follow the user (or device) regardless of network location — ideal for roaming, BYOD, and segmented enterprise services.
SAML pre-auth redirect integrates the IdP (ise01.lab.nhprep.com) into the access flow so the firewall receives authenticated user and group attributes before allowing access.
Application groups (ZTA Application Group) simplify policy management and provide grouping for SSO-like behavior and collective protection of related services.
Always verify the identity server reachability and attribute mappings; most policy failures stem from mismatched attributes, certificate trust problems, or incorrect policy order.

Warning: In production, ensure high-availability for identity services and rigorous certificate management. Identity-based policies are powerful but depend on the integrity and availability of your IdP and identity mapping configuration.

If you completed these steps, you have implemented per-application, identity-based access using SAML pre-auth for a ZTA firewall. In the next lesson we will expand policies to include device posture attributes and combine identity + posture for adaptive access decisions.

Identity-Based Access Policies

Objective

Quick Recap

Key Concepts

Step-by-step configuration

Step 1: Define Application Objects on the ZTA Firewall

Step 2: Create a ZTA Application Group and Add Apps

Step 3: Configure SAML IdP Redirect for the Application Group

Step 4: Integrate Identity Source (ISE/AD) and Map Groups

Step 5: Create Identity-Based Access Policy

Verification Checklist

Common Mistakes

Key Takeaways