Day 140 – Cisco ISE Mastery Training: Policy‑Based Segmentation

[Day 140] Cisco ISE Mastery Training: Policy‑Based Segmentation

Post Views: 4

Introduction

Policy-Based Segmentation is the practice of enforcing network access and micro-segmentation based on identity, device posture, and contextual policy rather than static topology (VLANs). Cisco ISE is the heart of this: it calculates who/what an endpoint is, evaluates device health and contextual signals, and then returns enforcement decisions (VLAN, dACL/Filter-ID, SGTs, SAML claims) to enforcement points. This lets you implement Zero-Trust segmentation across wired, wireless and remote connections with consistency and auditability.

In this Article we move from concepts to an actionable playbook: how to map business roles → policy → enforcement across devices; how to test and validate with Live Logs, CLI, and packet captures; and how to design safe rollout strategies.

Problem Statement

Common operational problems policy-based segmentation solves:

  • Flat networks that allow lateral movement after compromise.
  • VLAN/ACL sprawl — impossible to maintain per-user/per-app VLANs at scale.
  • Lack of context — IP/VLAN cannot represent user role, posture, or device type.
  • Inconsistent enforcement across wired/wireless/VPN/cloud.
  • Slow containment — security teams lack automated ways to quarantine compromised endpoints.

We need a solution that: centralizes identity and posture, expresses fine-grained policies, pushes enforcement consistently to many types of enforcement points, and provides safe rollback/testing.

Solution Overview

Key components and how they fit:

  • Cisco ISE — identity & policy decision point. Produces Authorization Profiles containing enforcement attributes: VLAN, downloadable ACL (dACL)/Filter-ID, Security Group Tag (SGT).
  • Profiler/Posture — ISE uses probes and posture to classify endpoints and determine trust level.
  • Enforcement Points (NADs) — switches, WLCs, firewalls, VPN concentrators enforce ISE decisions.
  • TrustSec / SGT / SXP — identity tags that allow micro-segmentation independent of IP/VLAN. SXP pushes bindings to legacy devices.
  • pxGrid / ERS / REST — integrate ISE with SIEM, orchestration and ZTNA platforms for automation.

Policy-Based Segmentation = define business roles/resources → translate to Policy (ISE Authorization) → map to enforcement attributes (SGT/dACL/VLAN) → validate enforcement at devices.

Sample Lab Topology

Platform: VMware (ISE OVA + Windows AD) or EVE-NG (ISE OVA, IOS-XE/catalyst images, ASA/FTD images).

Lab components (example):

  • ISE PAN + PSN (Profiler & Posture enabled): 10.10.10.11
  • Active Directory: 10.10.20.10
  • TrustSec-capable Switch (Catalyst/IOS-XE): 10.10.30.10
  • Legacy Switch (no TrustSec): 10.10.30.11 (SXP peer)
  • Firewall (ASA/FTD): 10.10.40.10
  • WLC (optional): 10.10.30.20
  • Clients: 172.16.110.101 (finance_user), 172.16.110.150 (guest)
  • Servers: 10.10.200.50 (Finance app), 10.10.200.60 (General)
  • Lab host: 10.10.99.50 (for tcpdump/pcap)

Simple Topology diagram:

Notes: Use a test VLAN and snapshot appliances. Avoid destructive CoA actions on production devices.

Step-by-Step GUI Configuration Guide

Below: exact sequence for a canonical Policy-Based Segmentation use case — Finance users get SGT 101 and a dACL allowing only the Finance app; Guests get SGT 300 and are denied Finance app.

Overview of steps:

  1. Design policy → SGT & ACL matrix
  2. Create SGTs in ISE
  3. Create dACLs / Authorization Profiles
  4. Authentication Policy (AD)
  5. Authorization Policy mapping conditions → Authorization Profiles
  6. Add NADs and enable CoA & SXP (if needed)
  7. Enforcement device config (switch + firewall)
  8. Test & validate

5.1 — Step 1: Design policy matrix

Created a small table to implement:

Role / Source SGTDest SGTAllowed ports
Finance (SGT 101)Servers (SGT 200)TCP 443
Guest (SGT 300)Servers (SGT 200)Deny

Store design doc for validation.

5.2 — Step 2: Create Security Group Tags in ISE (GUI)

  1. ISE GUI → Policy > Policy Elements > Results > Security Group Tags → Add:
    • SGT_FINANCE — 101
    • SGT_SERVERS — 200
    • SGT_GUEST — 300
    • [Screenshot placeholder: ISE > Policy Elements > Security Group Tags]

Validation: Verify tags listed with IDs.

5.3 — Step 3: Create Authorization Profiles that set SGT & dACL (GUI)

A. Create dACL (if firewall accepts payloads)

  1. Policy > Policy Elements > Results > Authorization > Add → Create AP_DACL_FINANCE.
  1. In the profile set Downloadable ACL (or advanced > dACL) with ACL lines (ASA/IOS syntax). Example (ASA style):
access-list ISE_FINANCE_DACL extended permit tcp any host 10.10.200.50 eq 443
access-list ISE_FINANCE_DACL extended deny ip any any
  1. Save. [Screenshot placeholder: Authorization Profile > dACL editor]

B. Create SGT assignment profile

  1. Policy Elements > Results > Authorization > Add → AP_SGT_FINANCE
  2. Set Security Group Tag = SGT_FINANCE (101) (field name varies by ISE release). Optionally also reference the dACL as fallback. Save. [Screenshot placeholder: Authorization Profile > SGT field]

Repeat for AP_SGT_GUEST → SGT_GUEST (300), maybe with quarantine dACL.

Validation: Profile preview shows SGT and/or dACL payload.

5.4 — Step 4: Ensure AD identity source & profiling

  1. Administration > Identity Management > External Identity Sources > Active Directory → add AD domain and bind account. Test connection.
    • [Screenshot: ISE > AD Add Domain]
  1. (Optional) Enable Profiler probes if you plan to use device type in policy: Work Centers > Profiler > Settings → enable DHCP/HTTP/SNMP.

Validation: Test account lookup from ISE or run Test Connectivity.

5.5 — Step 5: Authentication Policy (Policy Sets)

  1. Policy > Policy Sets → choose relevant policy set (Default).
  2. Authentication rules: AD default for wired/wireless/VPN. Put device specific rules above general ones if needed.
    • Example: For 802.1X wired: EAP (PEAP) then fallback to MAB.
    • [Screenshot placeholder: Policy Sets > Authentication rules]

Validation: Attempt AD login from client and confirm Access-Request reaches ISE (Live Logs).

5.6 — Step 6: Authorization Policy — map business rule → Authorization Profile

  1. Policy > Policy Sets → Authorization section. Add top rule:
    • Name: Finance access
    • Condition: Identity Group == AD/Finance AND Device Type == Corporate (or Endpoint: Endpoint Identity Group == Corporate-Laptop)
    • Result: AP_SGT_FINANCE (assign SGT 101, and/or dACL)
    • Move above default rules.
    • Add rule for Guest group → AP_SGT_GUEST.
    • [Screenshot placeholder: Policy Sets > Authorization rule mapping AP_SGT_FINANCE]

Validation: Use the Policy Tester (if available) or use a test user to verify which rule matches in Live Logs. Confirm the Authorization Profile name is the expected one.

5.7 — Step 7: Add Network Devices & enable CoA & SXP in ISE (GUI)

  1. Administration > Network Resources > Network Devices > Add → add switch & firewall entry:
    • IP, Device Profile (Cisco Switch / ASA), Shared Secret.
    • Check: RADIUS Authentication, RADIUS Accounting (optional), Dynamic Authorization (CoA) enabled.
    • If using SXP, ensure you have the SXP peers and allowed IPs configured (SXP is typically configured on network devices; ISE may manage SGTs and pxGrid, but SXP peer config happens on switches).
    • [Screenshot placeholder: Add Network Device]

Validation: ISE shows device entry and you can test RADIUS from the device.

5.8 — Step 8: Configure Enforcement Switch (sample IOS-XE CLI)

These commands are representative; adjust to platform/version.

configure terminal
! Radius server
radius server ISE
 address ipv4 10.10.10.11 auth-port 1812 acct-port 1813
 key ISE_SECRET

aaa new-model
aaa group server radius ISE_GROUP
 server name ISE
aaa authentication dot1x default group ISE_GROUP
aaa authorization network default group ISE_GROUP

! Enable dot1x and MAB
dot1x system-auth-control
authentication mac-move permit

! Enable CTS (TrustSec)
cts role-based enforcement

! Configure interface
interface GigabitEthernet1/0/10
 switchport access vlan 10
 switchport mode access
 authentication host-mode multi-auth
 authentication order dot1x mab
 authentication priority dot1x mab
 mab
 dot1x pae authenticator
 spanning-tree portfast

Validation CLI

  • show authentication sessions interface Gi1/0/10 details — shows authentication method (dot1x/mab), assigned VLAN, and SGT (if supported).
  • show cts role-based sgt-map — shows IP→SGT map.

5.9 — Step 9: Configure Firewall to accept dACL / Filter-ID

ASA (representative)

! define RADIUS server group
aaa-server ISE_Radius protocol radius
aaa-server ISE_Radius (inside) host 10.10.10.11
 key ISE_FIREWALL_SECRET

! If Filter-ID approach: create local ACL named same as Filter-Id
access-list ISE_FINANCE_FILTER extended permit tcp any host 10.10.200.50 eq 443

Validation

  • show running-config aaa-server
  • show access-list to see applied dynamic ACLs
  • For AnyConnect VPN sessions: show vpn-sessiondb detail anyconnect shows applied group-policy or filters.

5.10 — Step 10: Test & Validate (end-to-end)

A. Observe ISE Live Logs

  • Operations > RADIUS > Live Logs → find session for finance_user. Confirm:
    • Authentication succeeded (AD)
    • Authorization Profile = AP_SGT_FINANCE or AP_DACL_FINANCE
    • [Screenshot placeholder: ISE Live Logs showing AP_SGT_FINANCE]

B. Capture RADIUS traffic (lab host / firewall)

sudo tcpdump -i eth0 host 10.10.10.11 and udp port 1812 -w radius_finance.pcap

Open in Wireshark: Inspect Access-Accept for Filter-Id or VSA with ACL payload (vendor specific).

C. Validate enforcement on switch & firewall

  • Switch: show authentication sessions interface Gi1/0/10 details — SGT present (if switch supports) and VLAN/dACL applied.
  • Firewall: show access-lists or show vpn-sessiondb verify applied ACL.
  • Client tests:
    • curl -I https://10.10.200.50 (expected 200 / allowed)
    • curl http://10.10.200.60 (expected fail / blocked)

D. Validate SXP for legacy device

  • On legacy switch: show sxp bindings → entry mapping 172.16.110.101 -> 101.
  • Test traffic path through legacy switch to firewall and observe enforcement.

Troubleshooting & Diagnostics

Triage steps (collect first)

  1. ISE Live Logs — which policy matched? Authorization Profile? RADIUS attributes?
  2. NAD logs / show commands — show authentication sessions, show radius statistics, show cts role-based sgt-map.
  3. pcap — RADIUS (1812), CoA (3799), SXP (tcp 649) captures. Use Wireshark to inspect attributes.

Common issues & fixes

Issue A — Authorization Profile not applied

  • Symptom: ISE Live Logs show Access-Accept but default profile or different profile used.
  • Fix: Check policy order; verify condition matches (AD group exactly spelled, correct endpoint identity). Use Policy Tester or Policy Trace.

Issue B — RADIUS Access-Accept lacks dACL/Filter-Id

  • Symptom: ISE selected AP but Access-Accept attributes do not include dACL.
  • Fix: Verify Authorization Profile contains dACL and was saved/published. Confirm ISE version supports dACL for the NAD vendor and that you used correct field (Downloadable ACL vs Filter-Id).

Issue C — Device receives the attribute but does not apply ACL

  • Symptom: Firewall RADIUS logs show payload but no ACL applied.
  • Fix: Vendor mismatch — ASA expects Filter-Id naming or specific VSA. For ASA often a local ACL must exist with the Filter-Id name. Check firewall vendor docs and map properly.

Issue D — SGT not present on switch

  • Symptom: ISE returned SGT but switch shows none.
  • Fix: Ensure switch TrustSec features are enabled and software supports SGT. Confirm RADIUS attribute format. Use show cts role-based sgt-map and show authentication sessions to verify.

Issue E — CoA fails (updates not applied)

  • Symptom: ISE sends CoA but NAD responds NAK.
  • Fix: Ensure CoA (RFC-3576) is enabled on both sides, shared secrets correct, port reachable (TCP 3799), NAT not interfering. Capture CoA and inspect Error-Cause.

Useful capture filters & show commands

pcap filters

# RADIUS
tcpdump -i eth0 host 10.10.10.11 and udp port 1812 -w radius.pcap
# CoA (RFC-3576, TCP 3799)
tcpdump -i eth0 host 10.10.10.11 and tcp port 3799 -w coa.pcap
# SXP
tcpdump -i eth0 host 10.10.30.11 and tcp port 649 -w sxp.pcap

ISE GUI areas

  • Operations > RADIUS > Live Logs
  • Policy > Policy Sets (Authentication & Authorization)
  • Policy Elements > Results > Authorization (dACL & SGT fields)

Switch CLI

  • show authentication sessions interface Gi1/0/10 details
  • show radius statistics
  • show cts role-based sgt-map
  • show sxp connections / show sxp bindings (platform variant)

Firewall CLI

  • ASA: show vpn-sessiondb detail anyconnect, show access-list, show running-config aaa-server
  • FTD: show managers, show access-control connections

Lab Walkthroughs with Validation

Lab A — Finance laptop gets SGT + dACL and can only reach Finance app

  1. Precondition: AD finance_user in Finance group. ISE authorization mapped to AP_SGT_FINANCE and AP_DACL_FINANCE.
  2. Connect client to switch port Gi1/0/10 and authenticate.
  3. Validate:
    • ISE Live Logs show AP_SGT_FINANCE chosen.
    • tcpdump on firewall shows Access-Accept with Filter-Id or dACL payload.
    • show authentication sessions interface Gi1/0/10 details shows SGT 101 (if supported).
    • Client: curl https://10.10.200.50 → success. curl http://10.10.200.60 → fail.
  4. Collect artifacts for class.

Lab B — SOC triggers quarantine via REST/ERS API → CoA updates ACL

  1. Create AP_QUARANTINE dACL permitting only remediation IPs.
  2. Simulate SOC action: use ERS API call (example below) to change endpoint group or to push new Authorization for endpoint session.
    • Example conceptual ERS call (ISE versions differ — test payload in your ISE lab):
curl -k -u ersadmin:ERSPASS -H "Content-Type: application/json" \
 -X PUT https://10.10.10.11:9060/ers/config/endpoint/<endpoint_id> \
 -d '{"groupId":"QuarantineGroupId"}'
  1. ISE changes Authorization and sends CoA to firewall/switch; enforcement updates to AP_QUARANTINE.
  2. Validate:
    • ISE Live Logs show CoA sent & accepted.
    • Firewall show access-list shows quarantine ACL.
    • Client test: previously allowed apps now blocked except remediation.

Expert Level Use Cases

  1. Micro-segmentation for PCI
    • Map POS devices to SGT_PCI, map POS servers to SGT_POS_SERVERS, create SGT policy allow only required traffic, enforce via firewall/TrustSec.
    • Validate by attempting unauthorized connections from non-PCI device → blocked.
  2. Time-bound admin access
    • Use ISE Authorization Profile to return dACL for admin with expiry; orchestration reverts after window. Validate via logs and scheduled job.
  3. Step-up for sensitive actions
    • Authorization policy requires MFA for sensitive servers; ISE authorizes only after second factor and returns dACL allowing admin ports. Validate MFA logs and final Access-Accept.
  4. Cross-site enforcement via SXP
    • Push IP→SGT from campus switches via SXP to hub firewall cluster; central enforcement implements same policy everywhere. Validate SXP bindings on hub and enforcement hits on firewall.

FAQs

Q1 — dACL vs Filter-Id: which to choose?
A: Use dACL payload when your NAD/firewall supports receiving and installing ACL payloads. Use Filter-Id when the NAD expects a named ACL to exist locally; ISE returns Filter-Id and the NAD applies the local ACL with that name. For scale and vendor compatibility, Filter-Id is often safer.

Validation: Capture Access-Accept — see whether Filter-Id attribute or VSA with ACL lines is present.

Q2 — How do I map business roles to SGTs and keep order?
A: Design a central SGT namespace (document IDs & descriptions). Use ISE Authorization Profiles to assign SGT values to roles. Keep table versioned in CMDB. Avoid reusing SGT numbers.

Validation: Export Policy Elements > Security Group Tags and verify mapping.

Q3 — What RADIUS attribute carries SGT or dACL?
A: SGT is returned as a specific attribute (platform dependent) — ISE exposes a Security Group Tag field in Authorization Profile. dACLs often use vendor-specific attributes or Filter-Id. Inspect Access-Accept in Wireshark.

Validation: tcpdump RADIUS Access-Accept and view attributes.

Q4 — How to prevent disrupting critical devices when applying CoA?
A: Use non-disruptive actions (change VLAN or dACL avoidance for port-shutdown), stage in monitor mode, run small pilots, and enforce change windows with OT/Infra owners. Document rollback steps.

Validation: Perform change in lab replica and validate device behavior.

Q5 — How to debug when firewall doesn’t apply returned ACL?
A: Steps:

  1. Check ISE Live Logs — was the correct AP returned?
  2. Capture RADIUS — does Access-Accept include the expected attribute?
  3. Check firewall logs — parse or vendor parser errors.
  4. Confirm firewall platform compatibility & ACL syntax.

Validation: Walk the three artifacts (ISE Live Logs, pcap, firewall logs).

Q6 — Does granular per-user dACL scale?
A: Per-user dACLs can scale but increase processing on enforcement devices and RADIUS churn. For large deployments, consider SGTs or Filter-Id templates and reduce per-user uniqueness.

Validation: Run load tests measuring firewall CPU and RADIUS throughput.

Q7 — How to integrate cloud ZTNA enforcement with ISE policies?
A: Use ISE pxGrid or REST/ERS to share identity & posture to ZTNA broker, or have ISE return attributes consumed in SAML assertions. Implementation varies by broker.

Validation: Confirm broker receives pxGrid events and enforces mapping.

Q8 — What happens on fail-open vs fail-closed?
A: Fail-open grants limited access if ISE unreachable — may be required for availability. Fail-closed denies. Choose per risk appetite; document and test fallback. ISE exposes offline policies for devices.

Validation: Simulate ISE unreachability and confirm expected fallback behavior.

Q9 — How to audit segmentation effectiveness?
A: Periodically export ISE session logs, firewall hit counters, and pxGrid events. Run internal penetration tests to verify unauthorized access blocked. Use tools to map allowed flows and compare to policy.

Validation: Produce a report showing attempted blocked flows and allowed only approved flows.

Q10 — What are best practices for rollout?
A: Start small (pilot group), use monitor mode, collect telemetry for 2–4 weeks, refine rules, staged enforcement, documented rollback, automation for emergency revert, and training for operators.

Validation: Pilot metrics: number of blocked events, false positives, time-to-revert incidents.

YouTube Link

For more in-depth Cisco ISE Mastery Training, subscribe to my YouTube channel Network Journey and join my instructor-led classes for hands-on, real-world ISE experience

[NEW COURSE ALERT] CISCO ISE (Identity Service Engine) by Sagar Dhawan
CCIE Security v6.1 Training – Ticket#1 Discussed
CCIE Security v6.1 – MAC Authentication Bypass (MAB) in Cisco ISE
CCNP to CCIE SECURITY v6.1 – New Online Batch

Closing Notes (Key takeaways)

  • Policy first: define business roles & required app access, then map to technical SGT/dACL constructs.
  • ISE centralizes decisions and returns enforcement attributes consistently across platforms.
  • Validate using three artifacts: ISE Live Logs, RADIUS pcaps, and enforcement device logs/CLI.
  • Scale & safety: use SGT + Filter-Id combos and monitor device capacity. Always pilot & stage rollouts.

Upgrade Your Skills — Start Today

For full, hands-on Cisco ISE Mastery come join the Fast-Track to Cisco ISE Mastery Pro — 4-month instructor-led program with EVE-NG/VMware labpacks, weekly live debugging, and CCIE-grade scenarios.

Subscribe to Network Journey on YouTube and reserve your seat & labpack: https://course.networkjourney.com/ccie-security/

Enroll Now & Future‑Proof Your Career
Email: info@networkjourney.com
WhatsApp / Call: +91 97395 21088

Trainer Sagar Dhawan
Hi all, Good to see you here. I'm your Trainer for CCIE, CCNP, CCNA, Firewall batches and many more courses coming up! Stay tuned for latest updates! Keep me posted over Whatsapp/Email about your experience learning from us. Thanks for being part of - "Network Journey - A journey towards packet-life!!!"

Related Posts

Day 106 – Cisco ISE Mastery Training: Integrating Cisco DNA Center for SDA

[Day 106] Cisco ISE Mastery Training: Integrating Cisco DNA Center for SDA

  • Posted on
    • Day 138 – Cisco ISE Mastery Training: Mapping Zero Trust Policies with TrustSec

    [Day 138] Cisco ISE Mastery Training: Mapping Zero Trust Policies with TrustSec

  • Posted on
    • Day 141 – Cisco ISE Mastery Training: Multi‑Tenant Policy Sets

    [Day 141] Cisco ISE Mastery Training: Multi‑Tenant Policy Sets

  • Posted on