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

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

Post Views: 5

Introduction

Zero Trust requires you to make decisions based on identity, device posture, and context — not on network topology (VLANs). Cisco TrustSec (SGTs + TrustSec enforcement) lets you express who/what can talk to what using Security Group Tags (SGTs) instead of brittle VLANs. Cisco ISE acts as the identity and policy brain: it assigns SGTs to endpoints (via Authorization profiles) and publishes identity bindings so enforcement points (switches, firewalls, WLCs) can enforce least-privilege policies.

This Article teaches you to design ZTNA policies mapped to TrustSec, implement SGT assignment in ISE, configure enforcement (hardware & SXP for legacy gear), validate end-to-end, debug failures, and operationalize TrustSec for real networks. You’ll walk away able to run a lab showing a Finance user gets an SGT and, by policy, only connects to Finance apps — anywhere in the enterprise.

Problem Statement

Traditional segmentation (VLANs, IP ACLs) has three major limitations:

  • Static and brittle — VLANs are tied to ports, not identity.
  • Scale — thousands of devices × many apps → explosion of VLANs/ACLs.
  • Context blindness — VLAN/ACL cannot incorporate device posture, user role, or risk.

We need a way to express who can access what centrally and enforce it everywhere. That’s the problem TrustSec + ISE solves: centralized tag-based policy (SGTs) plus distributed enforcement in network gear and security devices.

Solution Overview

Core architecture & components:

  • ISE — Policy decision point: defines SGTs, policy mapping, assignment in Authorization Profiles, and logs events.
  • Security Group Tags (SGTs) — numeric tags representing identity groups (e.g., Finance = 101, Servers = 200).
  • Enforcement Points (EPs) — switches, WLCs, firewalls, routers that apply SGT-aware policy.
  • SXP (Security Group Tag eXchange Protocol) — protocol to share IP→SGT bindings to devices that cannot read SGT from packet headers (legacy gear).
  • Policy enforcement (CTS) — hardware/ASIC enforcement using SGTs (Access Control based on SGT->SGT rules).

Flow summary: User/device authenticates → ISE evaluates posture + identity → ISE returns Authorization Profile with SGT (and/or VLAN/dACL) → switch/WLC/VPN uses that SGT to enforce traffic policies or distributes the binding via SXP to other enforcement points.

Sample Lab Topology

Platform: VMware (ISE OVA + AD + Enforcement device images) or EVE-NG.

VMs / Devices

  • Cisco ISE PAN + PSN (Profiler + pxGrid enabled) — 10.10.10.11
  • Active Directory (LDAP) — 10.10.20.10
  • Enforcement Switch (IOS-XE/Catalyst/Industrial IE) — 10.10.30.10 (supports TrustSec/SX P)
  • Legacy Switch (no TrustSec) — 10.10.30.11 (receives SXP bindings)
  • Firewall (ASA/FTD or NGFW) — 10.10.40.10 (enforces by SGT or Filter-ID)
  • Wireless Controller (WLC) — 10.10.30.20 (optional)
  • Clients: Corporate laptop (user in Finance AD group), Guest laptop
  • Lab host for packet capture/automation — 10.10.99.50

IP plan & components summary

ISE PSN: 10.10.10.11
AD:      10.10.20.10
Switch:  10.10.30.10  (TrustSec-capable)
Legacy:  10.10.30.11  (non-TrustSec; uses SXP)
FW:      10.10.40.10
ClientA (Finance): 172.16.110.101
ClientB (Guest):   172.16.110.150

Topology:

Step-by-Step GUI Configuration Guide

l will implement a concrete lab scenario: Finance users get SGT 101 and are permitted only to access Finance app servers; Guest users get SGT 300 and are blocked from Finance.

Pre-req checklist

  • ISE admin account with Policy & TrustSec privileges.
  • Enforcement devices reachable from ISE; RADIUS secrets configured.
  • Time (NTP) synced across ISE and network devices.

Step 1 — Plan SGTs & Policy Map (Design)

  1. Decide SGT numeric values & names:
    • 101 → Finance (SGT name: SGT_FINANCE)
    • 200 → Servers (SGT_SERVERS)
    • 300 → Guest (SGT_GUEST)
  2. Draw policy matrix (source SGT → destination SGT → allowed services). Example:
    • SGT_FINANCE → SGT_SERVERS : allow TCP 443, TCP 8443
    • SGT_GUEST → SGT_SERVERS : deny

Deliverable: simple table in class slide.

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

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

Validation: list shows three SGTs with correct IDs.

Step 3 — Create Authorization Profiles that assign SGTs (GUI)

  1. ISE → Policy > Policy Elements > Results > Authorization > Authorization Profiles → Add an Authorization Profile AP_SGT_FINANCE:
    • Access Type: ACCESS_ACCEPT
    • Under SGT field (Security Group Tag) choose SGT_FINANCE (101) (field may be labeled Security Group Tag or Trusted Group ID).
    • Optionally set VLAN or dACL as fallback.
    • Save. [Screenshot: Authorization Profile Add — SGT field]
  2. Similarly create AP_SGT_GUEST assigning SGT_GUEST (300).

Validation: The Authorization Profile preview shows Security Group Tag set.

Step 4 — Configure Authorization Policy to use SGT profiles (GUI)

  1. ISE → Policy > Policy Sets → Edit relevant Policy Set (e.g., Default Network Access) or create TrustSec-PolicySet.
  2. Under Authorization add rule(s):
    • Rule 1: If AD Group == Finance AND Device Type == Corporate → Apply AP_SGT_FINANCE.
    • Rule 2: If AD Group == Guests → Apply AP_SGT_GUEST.
    • [Screenshot: Policy Sets > Authorization rule mapping to AP_SGT_FINANCE]

Validation: Use ISE Policy Tester or create test user and observe which Authorization Profile is selected in Live Logs.

Step 5 — Add network devices & enable TrustSec features (GUI & CLI)

ISE GUI:

  1. Administration > Network Resources > Network Devices > Add your TrustSec switch and firewall. Enable CoA and ensure SNMP credentials are set if needed.
    [Screenshot: Add Network Device]
  1. Add Legacy switch (non-TrustSec) as a network device too.

Switch (sample CLI — IOS-XE style)

Note: exact TrustSec/SXP commands can vary by IOS version. Use vendor docs for production. Below are representative sample commands.

! Configure RADIUS to ISE
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 CTS role-based enforcement
cts role-based enforcement

! (If using SXP to push SGT->IP mappings to legacy devices)
sxp
  domain default
  local-role enforcement
  ip add 10.10.30.11 peer <legacy_switch_ip>
  exit

Validation (CLI):

  • show radius servers
  • show cts role-based sgt-map (to see SGT mappings / cached bindings)
  • show sxp connections or show sxp bindings (verify SXP neighbor and bindings — exact command may vary by platform)

Important: SXP syntax varies across platforms. Check your platform docs and lab version.

Step 6 — Configure Firewall / Enforcement rules by SGT (policy mapping)

  1. On firewall (if it supports TrustSec), create an enforcement policy using SGT names or numbers:
    • Permit SGT_FINANCE (101) → SGT_SERVERS (200) on TCP/443.
    • Deny SGT_GUEST → SGT_SERVERS.
  2. If firewall doesn’t natively support SGT: map SGT->VLAN/Filter-ID and use conventional ACLs (less ideal).

Validation: On firewall, show access-list or show cts role-based permissions to view policy entries.

Step 7 — Test authentication & SGT assignment (GUI + CLI)

  1. On client (Finance user), authenticate (802.1X or VPN) and ensure ISE applies AP_SGT_FINANCE.
  2. ISE Live Logs: Operations > RADIUS > Live Logs — filter by user → you should see Access-Accept and the Authorization Profile with SGT value.
    • [Screenshot: ISE Live Logs showing AP_SGT_FINANCE applied]
  1. On switch, verify the endpoint has SGT assigned or that the mapping exists:
    • show authentication sessions interface Gi1/0/10 details — may display SGT if switch supports SGT in session details.
    • show cts role-based sgt-map — shows IP→SGT mapping.
    • show sxp bindings — on SXP peers, verify the IP→SGT binding is present.

Validation: Client attempts a TCP 443 connection to Finance server; firewall allows. Guest user should be blocked.

Step 8 — Verify SGT propagation to legacy devices using SXP

  1. When the switch learns IP→MAC→SGT binding, it exports the IP→SGT mapping via SXP to SXP neighbors (legacy switches/firewalls).
  2. On legacy device, confirm it has the SXP binding and will enforce per SGT policy.

Validation: show sxp bindings (if available), or on legacy switch verify received bindings, then test traffic from client across the path through legacy switch to firewall.

GUI / CLI validation checklist (quick)

  • ISE: Security Group Tags exist and Authorization Profiles show assigned SGT. (Policy Elements → Security Group Tags; Authorization Profiles)
  • ISE Live Logs: Access-Accept with Security Group Tag attribute present.
  • Switch: show authentication sessions shows SGT or show cts role-based sgt-map shows binding.
  • SXP peers: show sxp connections and show sxp bindings show neighbors and bindings.
  • Firewall: SGT-based rules hit and allow/deny as expected.
  • Packet capture: RADIUS Access-Accept contains SGT attribute when issued; traffic allowed/denied per SGT policy.

Troubleshooting & Diagnostics

When SGTs don’t flow or policy doesn’t enforce, use this prioritized Article.

A — Collect the three artifacts

  1. ISE Live Logs (Operations → RADIUS → Live Logs) — confirm Authorization profile, SGT attribute, and returned RADIUS attributes.
  2. Switch/Firewall logs & CLI — check RADIUS reception, SGT cache, SXP neighbor states.
  3. Packet capture — capture RADIUS traffic and enforcement traffic (tcpdump or span) to inspect Access-Accept attributes and SXP traffic.

B — Common issues & fixes

  1. ISE does not assign SGT (Authorization Profile mismatch)
    • Check Authorization rules order: specific rules must be above default Accept.
    • Validate AD group membership and that the matching condition is met.
    • Live Logs: open the session trace → verify which rule matched.
  2. Switch shows no SGT for endpoint
    • Check that the Authorization Profile returned SGT (Access-Accept); inspect RADIUS Access-Accept in capture for SGT attribute. If Access-Accept lacked it, ISE didn’t send the attribute — fix policy.
    • If Access-Accept contains SGT but switch doesn’t show it, confirm switch TrustSec features and software support (platform must support SGT/CTS).
  3. SXP neighbors not getting bindings
    • Network reachability (TCP 649? SXP uses TCP/649?) — verify TCP connectivity between SXP peers and correct SXP config (domain, key).
    • Validate SXP state: show sxp connections (command name may differ).
  4. ACL rules not enforced on firewall
    • Firewall may require SGT translation—ensure firewall supports SGT or SXP, or that you mapped SGT to VLAN or IP and created ACLs accordingly. Check firewall policy logs.
  5. Policy hits default rule
    • Authorization rule ordering error; also check that endpoint identity is correct (ISE Endpoint groups), not “Unknown”.
  6. CoA / re-tagging not applied
    • If you change an endpoint’s SGT dynamically, ISE typically triggers CoA to update the enforcement point; ensure CoA is enabled on device and ports open (RFC-3576).

C — Useful show/debug commands (examples — adapt by platform)

  • ISE GUI: Operations > RADIUS > Live Logs ; Policy > Policy Sets ; Policy Elements > Security Group Tags
  • Switch CLI examples (platform-dependent):
    • show cts role-based sgt-map
    • show cts role-based permissions
    • show authentication sessions interface Gi1/0/10
    • show sxp connections / show sxp bindings
  • Packet-capture: # capture RADIUS to see Access-Accept attributes tcpdump -i eth0 udp and port 1812 -w radius.pcap # capture SXP (TCP) traffic tcpdump -i eth0 tcp and port 649 -w sxp.pcap

Note: exact show/debug commands and SXP port numbers can vary by vendor and OS version — confirm with platform docs.

Lab Walkthroughs with Validation

Lab Walkthrough 1 — Finance user SGT assigned & enforced (end-to-end)

Goal: Finance user (user1) authenticates, receives SGT 101, allowed to reach Finance servers only.

Steps:

  1. Preconfigure AD user finance_user in CN=Finance group.
  2. ISE Authorization rules map AD Group == Finance → AP_SGT_FINANCE.
  3. On client, authenticate (802.1X or VPN). Observe ISE Live Logs → Access-Accept shows AP_SGT_FINANCE.
  4. On switch: show cts role-based sgt-map or show authentication sessions interface Gi1/0/10 → SGT shown.
  5. On firewall: confirm SGT-based rule allows / denies accordingly.
  6. Test: Finance client connects to Finance app (allowed) and to other servers (blocked).

Validation deliverables: ISE Live Logs screenshot, switch CLI output showing SGT, firewall allow/deny logs, packet captures.

Lab Walkthrough 2 — Legacy switch receives binding via SXP

Goal: Demonstrate SXP distribution of IP→SGT binding to legacy switch.

Steps:

  1. TrustSec switch learns 172.16.110.101 → SGT 101 and exports via SXP.
  2. On legacy switch (SXP peer), verify received binding: show sxp bindings → entry for 172.16.110.101 -> 101.
  3. Send traffic through legacy switch to firewall; firewall uses mapping to enforce SGT policy.
  4. Validate same allow/deny behavior as in TrustSec switch.

Validation deliverables: show sxp bindings output, packet capture of SXP session showing binding exchange, traffic allowed/denied as expected.

Expert Level Use Cases (step-by-step mapping + validation)

Use Case A — Campus → Data Center micro-segmentation

  1. Assign SGTs at campus edge (users, devices).
  2. Map server groups to SGTs in data center (DB servers SGT 210, App servers SGT 200).
  3. Create centralized policy that only App servers (SGT 200) can talk to DB (SGT 210) on DB ports.
    Validation: capture and ensure traffic from any campus user with non-App SGT to DB is blocked irrespective of VLAN/site.

Use Case B — PCI micro-segmentation

  1. Tag POS devices with SGT_PCI. Tag backend POS servers SGT_POS_SERVERS.
  2. Enforce strict ACL: SGT_PCI → SGT_POS_SERVERS only and block everything else.
    Validation: Attempt lateral access from non-PCI device — blocked.

Use Case C — Inter-site SGT propagation

  1. Use SXP between sites to export IP→SGT bindings across WAN to central firewall cluster.
  2. Enforce SGT policies centrally in hub firewalls for multi-site segmentation.
    Validation: Ensure hub firewall shows bindings for remote IPs and enforces policy.

Use Case D — Dynamic quarantine from SOC

  1. SIEM triggers on threat → orchestration calls ISE API to change endpoint Authorization to AP_SGT_QUARANTINE (SGT 999).
  2. ISE issues CoA → SGT updated; SXP ensures all enforcement points receive binding; traffic blocked.
    Validation: CoA logs in ISE & switch, SIEM confirms quarantine action, blocked flows observed.

FAQs

Q1 — What’s the difference between SGT and VLAN? When do I choose one over the other?
Answer: VLANs are location-based segmentation. SGTs are identity-based segmentation. Use VLANs for physical separation and SGTs for identity-centric policy that follows users/devices across the network. In practice use both: VLANs for L2 forwarding and SGTs for policy enforcement.
Validation: Show a client move across ports (different VLAN) and show SGT stays same if identity preserved; policy enforcement follows SGT not VLAN.

Q2 — How does an endpoint get an SGT assigned?
Answer: ISE assigns SGT via Authorization Profile returned in RADIUS Access-Accept. The Authorization Profile contains the SGT attribute; enforcement point applies it to the session.
Validation: Packet capture of RADIUS Access-Accept should include the SGT attribute or inspect ISE Live Logs showing Authorization Profile hit.

Q3 — If a switch doesn’t support TrustSec, can it still enforce SGTs?
Answer: Yes — use SXP to push IP→SGT bindings to that switch or firewall and enforce with SGT-aware firewall. Where SGT is not supported at all, map SGTs to VLANs or Filter-IDs as fallback (less flexible).
Validation: show sxp bindings on the legacy device to confirm bindings.

Q4 — How do I assign SGTs to non-802.1X endpoints (IoT, printers)?
Answer: Use MAB + profiling to identify the device, then apply Authorization Profile that assigns SGT. Alternatively, static SGT mappings (IP->SGT) stored in ISE or via SXP can be used for well-known endpoints.
Validation: Provision static SGT mapping in ISE for test IP and verify show cts role-based sgt-map.

Q5 — What RADIUS attribute contains the SGT assignment?
Answer: ISE can return SGT using vendor attributes or specific SGT attributes (implementation varies). Verify by capturing Access-Accept and inspecting attributes—ISE UI shows the Authorization Profile and the SGT selected.
Validation: Capture RADIUS Access-Accept and check for SGT attribute; consult device docs for exact attribute format.

Q6 — How to roll back TrustSec changes safely?
Answer: 1) Test in a lab; 2) stage in monitor mode (log only); 3) use a maintenance window and ensure manual rollback steps (switch config backups, ISE config export). Keep a script to revert ISE Authorization Profiles to prior state.
Validation: Run rollback steps on lab snapshot to confirm.

Q7 — How do SGTs scale across global sites?
Answer: Use a consistent SGT naming/numbering convention across sites and SXP to distribute IP→SGT bindings where needed. Use central ISE to manage SGT definitions. Avoid duplicate SGT numbering schemes.
Validation: Export SGT list from each ISE (if multi-ISE) and confirm consistency.

Q8 — How do I debug when policies are not enforced despite correct SGT assignments?
Answer: Steps: (1) Confirm ISE returned SGT (Live Logs), (2) Confirm switch shows binding, (3) Confirm SXP peer has binding (for legacy devices), (4) Confirm firewall rules reference the correct SGT, (5) check packet captures for hits/misses.
Validation: Walk through each step and show sample CLI commands/Live Logs.

Q9 — Does TrustSec handle micro-segmentation in multi-vendor environments?
Answer: Yes, but only if the vendor supports SGT or SXP or you provide alternative enforcement (central firewall enforcing based on IP-to-SGT bindings). Multi-vendor orchestration may require pxGrid or SDN controller glue.
Validation: Show binding flowing from ISE via SXP to third-party device and verify enforcement.

Q10 — Is TrustSec deprecated or is Cisco moving to other technologies?
Answer: Cisco continues to support TrustSec as the identity-centric enforcement mechanism in many enterprise environments. However, always review platform roadmaps for your deployment. For labs and practical ZTNA mapping, TrustSec remains a widely used approach.
Validation: Verify your platform’s feature matrix and ensure firmware supports CTS/SGT/SXP.

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)

  • Design first: define SGT namespace and mapping table before touching devices.
  • Policy in ISE: centralize SGT definitions and Authorization Profiles; use Authorization policies to express ZTNA decisions.
  • Enforce everywhere: configure TrustSec switches for native enforcement and use SXP for legacy devices.
  • Validate & monitor: leverage ISE Live Logs, switch show cts/show sxp commands and packet captures to prove end-to-end enforcement.
  • Operate safely: stage changes, use monitor mode, and document rollback steps.

Upgrade Your Skills — Start Today

For hands-on, instructor-led training, subscribe to my YouTube channel Network Journey and join the Fast-Track to Cisco ISE Mastery Pro — a 4-month live lab program.

The course covers TrustSec, pxGrid automation, Zero Trust policy mapping and real lab packs. Learn more & reserve your seat: 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 109 – Cisco ISE Mastery Training: Integration with Cisco ASA VPN

[Day 109] Cisco ISE Mastery Training: Integration with Cisco ASA VPN

  • Posted on
    • Day 45 – Cisco ISE Mastery Training: Wireless Guest Access Flow

    [Day 45] Cisco ISE Mastery Training: Wireless Guest Access Flow

  • Posted on
    • Day 82 – Cisco ISE Mastery Training: Integrating Cisco FMC

    [Day 82] Cisco ISE Mastery Training: Integrating Cisco FMC

  • Posted on