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

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

Post Views: 3

Introduction

Multi-tenant policy sets in Cisco ISE allow logical separation of policy, devices, and authentication/authorization flows for multiple tenants, departments, or business units within the same ISE deployment. Each tenant can have its own policy sets, identity sources, authentication rules, authorization profiles, and NAD assignments.

Why this matters:

  • Supports managed service environments and enterprise multi-department networks.
  • Avoids policy conflicts between tenants.
  • Simplifies auditing, logging, and troubleshooting per tenant.
  • Enables role-based delegation without giving admin rights globally.

This Article moves beyond theory into a full lab implementation, showing how to create, validate, and troubleshoot tenant-specific policies for multiple organizations.

Problem Statement

Organizations face challenges when multiple tenants or business units share the same ISE deployment:

  • Flat ISE deployment can result in policy collisions (one tenant’s authorization rules affecting another).
  • Shared network devices require careful policy segmentation.
  • Difficulty providing tenant-specific logging, auditing, and endpoint management.
  • Scalability issues when trying to maintain separate policy sets for each group.

Without proper multi-tenant segmentation, you risk unauthorized access, operational conflicts, and administrative overhead.

Solution Overview

Cisco ISE solves this with Policy Sets:

  • Multiple Policy Sets per tenant: Each policy set can have its own:
    • Authentication rules
    • Authorization rules
    • NAD (Network Access Device) assignments
    • Identity sources
  • Priority order: Policy sets are processed top-down. ISE evaluates a session against the first matching policy set based on conditions like NAD, IP, or SSID.
  • Isolation: No tenant’s rules affect another tenant’s endpoints.
  • Logging & Monitoring per tenant: Live Logs and Reports can be filtered by Policy Set.

Sample Lab Topology

Platform: VMware or EVE-NG (ISE OVA + Windows AD + NADs + endpoints)

Lab components:

DeviceIPRole
ISE PAN + PSN10.10.10.11Multi-Tenant Policy Engine
Active Directory Tenant A10.10.20.10Identity Source for Tenant A
Active Directory Tenant B10.10.20.11Identity Source for Tenant B
TrustSec Switch Tenant A10.10.30.10Enforcement Point for Tenant A
TrustSec Switch Tenant B10.10.30.11Enforcement Point for Tenant B
WLC (optional)10.10.30.20Wireless Tenant Access
Clients172.16.110.101, 172.16.110.150Tenant-specific endpoints
Servers10.10.200.50, 10.10.200.60Tenant applications
Lab host10.10.99.50Capture / testing host

Diagram:

Step-by-Step GUI Configuration Guide

5.1 — Step 1: Create Policy Sets for Each Tenant

  1. ISE GUI: Policy > Policy Sets → click Add Policy Set.
  2. Tenant A:
    • Name: Tenant_A_PolicySet
    • Condition: NAD IP = 10.10.30.10 OR SSID = TenantA_WIFI
    • Add Identity Source: AD Tenant A
    • Save
    • [Screenshot placeholder: Policy Set Tenant A]
  1. Tenant B:
    • Name: Tenant_B_PolicySet
    • Condition: NAD IP = 10.10.30.11 OR SSID = TenantB_WIFI
    • Add Identity Source: AD Tenant B
    • Save
    • [Screenshot placeholder: Policy Set Tenant B]

Validation: Policy sets appear in top-down order. Ensure Tenant A and Tenant B conditions do not overlap.

5.2 — Step 2: Configure Authentication Rules per Policy Set

  1. Policy > Policy Sets > Tenant_A_PolicySet > Authentication
    • Wired: EAP-PEAP + AD Tenant A
    • MAB fallback: Enabled
    • [Screenshot: Authentication Rule Tenant A]
  2. Repeat for Tenant B → AD Tenant B + MAB

Validation: Policy Tester → input AD username → expected Authentication Profile selected.

5.3 — Step 3: Configure Authorization Profiles per Tenant

  1. Policy > Policy Elements > Results > Authorization > Add
    • Tenant A → AP_TenantA_Finance → dACL + SGT (101)
    • Tenant B → AP_TenantB_Engineering → dACL + SGT (201)
    • [Screenshot placeholder: Authorization Profile Creation]

Validation: Check SGT assignment and dACL payload.

5.4 — Step 4: Map Authorization Rules per Tenant Policy Set

  1. Policy > Policy Sets > Tenant_A_PolicySet > Authorization
    • Rule: AD Group = Finance → Profile = AP_TenantA_Finance
    • Guest Group → AP_TenantA_Guest
    • [Screenshot: Tenant A Authorization Mapping]
  2. Repeat for Tenant B → Engineering / Guest

Validation: Policy Tester → username → correct Authorization Profile.

5.5 — Step 5: Add NADs per Tenant & enable CoA/SXP

  1. Administration > Network Resources > Network Devices > Add
    • Tenant A Switch → IP 10.10.30.10 → Shared Secret
    • Tenant B Switch → IP 10.10.30.11 → Shared Secret
    • Enable Dynamic Authorization (CoA)
    • [Screenshot: Add NADs]

Validation: Test RADIUS from switch: test aaa radius.

5.6 — Step 6: Configure Switch Interfaces (CLI examples)

Tenant A Switch (IOS-XE):

interface Gi1/0/10
 switchport mode access
 authentication host-mode multi-auth
 authentication order dot1x mab
 dot1x pae authenticator
 cts role-based enforcement

Tenant B Switch (IOS-XE):

interface Gi1/0/11
 switchport mode access
 authentication host-mode multi-auth
 authentication order dot1x mab
 dot1x pae authenticator
 cts role-based enforcement

Validation CLI: show authentication sessions interface Gi1/0/10 → shows tenant SGT.

5.7 — Step 7: Test Tenant Isolation

  • Connect Tenant A client → authenticate → assigned AP_TenantA_Finance
  • Connect Tenant B client → authenticate → assigned AP_TenantB_Engineering
  • Verify: Tenant A cannot reach Tenant B servers; Tenant B cannot reach Tenant A servers.
  • Use tcpdump / ping / curl to validate.

Troubleshooting & Diagnostics

Objective: Quickly identify and resolve issues with tenant-specific policies.

Step 1: Verify Policy Set Matching

  • GUI: Policy > Policy Sets > Live Logs → filter by tenant NAD or client IP.
  • CLI:
show logging application ise
show radius server statistics
  • Validation: Ensure sessions hit the correct tenant policy set. Look for Policy Set Name in Live Logs.

Step 2: Authentication Issues

  • Check AD Binding per Tenant:
    • GUI: Administration > Identity Management > External Identity Sources > Test Connection.
    • CLI (ISE CLI):
application stop ise
application start ise
show running-config | include identity
  • Validation: Users authenticate successfully, correct domain returned.

Step 3: Authorization Profile Assignment

  • GUI: Live Logs → verify Authorization Profile applied per tenant.
  • CLI:
show authentication sessions interface Gi1/0/10
show cts role-based sgt-map
  • Validation: Ensure SGT and dACL match the tenant’s policy.

Step 4: CoA / Dynamic Policy Validation

  • Trigger CoA from GUI: Operations > RADIUS > Re-authenticate
  • CLI verification on switch:
show radius server
show authentication sessions interface Gi1/0/X
  • Expected Result: Tenant profile updates applied, session re-authorization succeeds.

Step 5: Cross-Tenant Isolation Check

  • Ping/TCP Test: Tenant A → Tenant B server → should fail.
  • Capture Traffic: Use Wireshark/tcpdump to confirm no cross-tenant traffic leaks.

Lab Walkthroughs with Step-by-Step Validation

Lab 1: Tenant A Finance Users

  1. Connect Tenant A client → SSID/VLAN assigned to Tenant A.
  2. Authenticate via PEAP → AD Tenant A.
  3. GUI: Confirm Live Logs shows Tenant_A_PolicySet.
  4. CLI:
show authentication sessions interface Gi1/0/10
  • Check: SGT 101, dACL applied.
  • Validation: Ping Tenant A servers successful, Tenant B servers fail.

Lab 2: Tenant B Engineering Users

  1. Connect Tenant B client → VLAN 200.
  2. MAB fallback authentication → AD Tenant B.
  3. GUI: Confirm Tenant_B_PolicySet.
  4. CLI: Verify SGT 201, correct dACL.
  5. Validation: Tenant B access works, cross-tenant blocked.

Lab 3: Guest Access per Tenant

  1. Guest client → Tenant A SSID → Guest Authorization Profile.
  2. GUI/CLI Validation: Ensure limited access only to allowed resources.
  3. Repeat for Tenant B.

Expert Level Use Cases (Step-by-Step Mapping + Validation)

Use Case 1 — MSSP Multi-Customer Environment

  • Goal: Isolate 3 customers on same ISE deployment.
  • Implementation:
    • Create 3 Policy Sets, each mapped to NAD IP range or VLAN.
    • Configure AD/RADIUS per customer.
    • Assign Authorization Profiles with SGT/dACL for isolation.
  • Validation: Test Live Logs and ping across customers.

Use Case 2 — Department Segmentation

  • Finance, HR, IT → separate policy sets
  • Map SSID/VLAN per department → Authorization Profile → SGT.
  • Validate via switch CLI: show authentication sessions for each VLAN.

Use Case 3 — Hybrid Authentication

  • Tenant A uses AD, Tenant B uses RADIUS fallback for legacy devices.
  • Mapping: Policy Set → Authentication Rules → Authorization Profile.
  • Validate authentication path using Live Logs → ensure correct profile assignment.

Use Case 4 — Guest Portal Customization per Tenant

  • Assign Policy Set → Tenant SSID → Portal Branding → Authorization Profile.
  • Validation: Connect tenant guest client → verify branded portal → restricted access per tenant.

Use Case 5 — CoA for Dynamic Role Changes

  • Tenant A user role changes → trigger CoA → Authorization Profile updated.
  • Validation: CLI: show cts role-based sgt-map → confirms new SGT.

Pro Tip:

  • Always maintain policy set top-down order to avoid conflicts.
  • Use Live Logs + Policy Tester + CLI checks to fully validate end-to-end.
  • Document NAD IPs, VLANs, and tenant mappings in a lab runbook for reproducibility.

FAQs

1. Can a single NAD belong to multiple tenants?

  • Answer: Ideally no. Each NAD IP or VLAN should map to a single tenant to avoid policy conflicts. If shared, ensure top-down order resolves ambiguities.

2. How does ISE evaluate overlapping Policy Sets?

  • Answer: ISE evaluates Policy Sets top-down. The first match based on NAD IP, VLAN, SSID, or device identity is applied. Order carefully.

3. Can each tenant use a separate identity source?

  • Answer: Yes. Each Policy Set can reference a different AD domain, LDAP, or RADIUS server for authentication.

4. How do I debug cross-tenant access issues?

  • Answer:
    1. Check Policy Set conditions (NAD IP, VLAN, SSID).
    2. Verify Live Logs for tenant selection.
    3. Confirm Authorization Profile and SGT/dACL assignments.
    4. Use CLI (show authentication sessions) to check session mapping.

5. Can SGTs/dACLs be unique per tenant?

  • Answer: Yes. Each Policy Set can apply unique Security Group Tags (SGT) and dynamic ACLs for tenant isolation.

6. Does CoA work for individual tenants?

  • Answer: Yes. CoA applies per session. Triggering CoA on a tenant’s user updates the Authorization Profile without affecting other tenants.

7. How can I implement tenant-specific guest portals?

  • Answer: Map tenant Policy Set → SSID/VLAN → portal customization → assign Authorization Profile. Validate with Live Logs and endpoint test.

8. Can endpoints be shared across tenants?

  • Answer: Not recommended. Shared endpoints can cause authentication conflicts. If unavoidable, use MAC/IP filters and prioritize Policy Sets to resolve.

9. Can multi-tenancy be audited separately?

  • Answer: Yes. Use Live Logs filters, generate tenant-specific reports, and monitor SGT/dACL logs per Policy Set.

10. What are best practices for scaling multi-tenancy?

  • Answer:
    1. Maintain unique NAD IPs, VLANs, and SSIDs per tenant.
    2. Order Policy Sets top-down by specificity.
    3. Use clear Authorization Profiles per tenant.
    4. Pilot in lab before production rollout.
    5. Document tenant mappings and session behaviors for troubleshooting.

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

  • Multi-tenant Policy Sets allow logical isolation without multiple ISE nodes.
  • Ensure NAD/IP/SSID conditions are unique to avoid collisions.
  • Use authorization profiles with SGT/dACL per tenant for enforcement.
  • Validate using Live Logs, Policy Tester, switch/firewall CLI, and endpoint testing.
  • Rollout in stages for safety.

Upgrade Your Skills — Start Today

For in-depth Cisco ISE Mastery with labs, Live Troubleshooting, and CCIE-grade scenarios, join Fast-Track to Cisco ISE Mastery Pro — a 4-month instructor-led program.

Reserve your seat + lab pack here: Network Journey 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 137 – Cisco ISE Mastery Training: Zero Trust Network Access (ZTNA)

[Day 137] Cisco ISE Mastery Training: Zero Trust Network Access (ZTNA)

  • Posted on
    • [Day 55] Cisco ISE Mastery Training: EAP-TLS Wireless Certificate Authentication

    [Day 55] Cisco ISE Mastery Training: EAP-TLS Wireless Certificate Authentication

  • Posted on
    • Still Using Standard vSwitches? Here's Why DVS Is a Must in 2025 [CCNP ENTERPRISE]

    Still Using Standard vSwitches? Here’s Why DVS Is a Must in 2025 [CCNP ENTERPRISE]

  • Posted on