Lesson 6 of 7

ISE Policy Sets and Rule Design

Objective

In this lesson you will design and validate ISE Policy Sets and rule ordering that implement a common enterprise pattern: wired access using 802.1X with a MAB fallback (Easy Connect style) and an AD-only ACL during initial authentication. We focus on how to order policy checks, how conditions affect packet flow, and how to make policy sets deterministic and scalable. In production, correct policy-set design prevents false-negatives (legitimate users blocked) and false-positives (unauthorized access granted) and keeps RADIUS/TPS resources predictable.

Quick Recap

Refer back to the topology you configured in Lesson 1. This lesson does not add new routers or servers — it changes how the network access device (switch) and ISE interact. We will:

  • Convert the switch to the IBNS 2.0 display style (affects how the switch surfaces authentication state).
  • Apply an Easy Connect (AD-only) ACL on the NAD to allow AD traffic prior to full authorization.
  • Configure port authentication behavior (802.1X primary, MAB fallback).
  • Design and validate an ISE Policy Set ordering for: NAD grouping (location), Authentication method (EAP vs MAB), and Authorization (AD-group-based).

Important: This lesson assumes ISE nodes and AD integration already exist and that the NAD (switch) is configured as a RADIUS client in ISE.

Key Concepts

  • Policy Sets — In ISE, policy sets are evaluated in order. Think of them like a sequence of "if this, then that" folders: the first matching policy set handles the request. In production, grouping by NAD type/location (e.g., SJC01) keeps evaluation shallow and predictable.
  • Authentication vs Authorization — Authentication verifies identity (EAP, MAB). Authorization decides what the authenticated subject can do (ACLs, VLAN, CoA). Authentication failure can trigger different authorization outcomes (deny, limited access, AD-only).
  • 802.1X + MAB (Easy Connect) — MAB can be used to provide initial network services so an endpoint can reach AD for user login. After AD login event, ISE binds the AD username to the MAB session and issues a CoA to grant full access. This flow reduces support calls in environments with mixed supplicants.
  • Rule Ordering and Conditions — Use NAD group, SSID/location, and EAP-type as primary selectors. Within a policy set, order authentication rules from most-specific (EAP-TLS for managed devices) to least-specific (PEAP, then MAB) to avoid accidental matches.
  • Traffic Allowlist During Authentication — When using Easy Connect, allow only the minimal set of services required for domain join/login (DHCP, DNS, Kerberos, LDAP, NTP). This reduces exposure while allowing AD authentication.

Step-by-step configuration

Step 1: Convert Switch to IBNS 2.0 Display Style

What we are doing: Convert the switch’s authentication display to the IBNS 2.0 (new-style) so the switch reports richer authentication state to administrators and makes debugging easier. This changes only the CLI output format — it does not change authentication behavior.

switch# configure terminal
switch(config)# authentication display new-style
switch(config)# end
switch#

What just happened: The command toggles the switch to the IBNS 2.0 display mode. Operational show-commands (for example, show authentication sessions) will present the newer, more detailed format that matches current ISE nomenclature and simplifies cross-referencing with ISE reports. No authentication protocols were changed — only the informational display.

Real-world note: Many teams convert to new-style display before large 802.1X rollouts so troubleshooting outputs match ISE terminology.

Verify:

switch# show running-config | include authentication display
authentication display new-style

Expected output above confirms the configuration is present in running-config.

Step 2: Create the Easy Connect (AD-only) ACL on the NAD

What we are doing: Configure a limited extended ACL that permits only the services an endpoint needs to reach AD and obtain an IP (DHCP, DNS, Kerberos, LDAP, NTP, SMB as required). This ACL is applied as the temporary policy during MAB-based initial access (Easy Connect). Using a minimal ACL reduces attack surface during the pre-auth window.

switch# configure terminal
switch(config)# ip access-list extended EASY-CONNECT-AD
switch(config-ext-nacl)# permit udp any eq bootpc any eq bootps
switch(config-ext-nacl)# permit udp any any eq domain
switch(config-ext-nacl)# permit icmp any any
switch(config-ext-nacl)# permit tcp any host <AD-DC> eq 88
switch(config-ext-nacl)# permit udp any host <AD-DC> eq 88
switch(config-ext-nacl)# permit udp any host <AD-DC> eq ntp
switch(config-ext-nacl)# permit tcp any host <AD-DC> eq 135
switch(config-ext-nacl)# permit udp any host <AD-DC> eq netbios-ns
switch(config-ext-nacl)# permit tcp any host <AD-DC> eq 139
switch(config-ext-nacl)# permit tcp any host <AD-DC> eq 389
switch(config-ext-nacl)# permit udp any host <AD-DC> eq 389
switch(config-ext-nacl)# permit tcp any host <AD-DC> eq 445
switch(config-ext-nacl)# permit tcp any host <AD-DC> eq 636
switch(config-ext-nacl)# permit udp any host <AD-DC> eq 636
switch(config-ext-nacl)# exit
switch(config)# end
switch#

What just happened: You created an extended ACL named EASY-CONNECT-AD containing the exact permit lines shown in the reference material. This ACL allows DHCP, DNS, ICMP, Kerberos (TCP/UDP 88), NTP, NetBIOS and LDAP/LDAPS traffic to the AD domain controller(s). When this ACL is used in an authorization rule, the endpoint will only be able to reach these services until full authorization is granted.

Real-world note: Replace with the IP of your domain controller(s) in production. The ACL avoids exposing full network access during pre-auth.

Verify:

switch# show ip access-lists EASY-CONNECT-AD
Extended IP access list EASY-CONNECT-AD
    10 permit udp any eq bootpc any eq bootps
    20 permit udp any any eq domain
    30 permit icmp any any
    40 permit tcp any host <AD-DC> eq 88
    50 permit udp any host <AD-DC> eq 88
    60 permit udp any host <AD-DC> eq 123
    70 permit tcp any host <AD-DC> eq 135
    80 permit udp any host <AD-DC> eq 137
    90 permit tcp any host <AD-DC> eq 139
   100 permit tcp any host <AD-DC> eq 389
   110 permit udp any host <AD-DC> eq 389
   120 permit tcp any host <AD-DC> eq 445
   130 permit tcp any host <AD-DC> eq 636
   140 permit udp any host <AD-DC> eq 636

Expected output shows the full extended ACL with the same permit statements that match the example Easy Connect ACL.

Step 3: Configure Port Authentication Behavior (802.1X primary, MAB fallback)

What we are doing: Configure a switch access port to attempt 802.1X first and if that fails, allow MAB as a fallback so endpoints without an 802.1X supplicant can still perform AD login. This is the typical deployment for mixed endpoint environments.

switch# configure terminal
switch(config)# interface GigabitEthernet1/0/10
switch(config-if)# switchport mode access
switch(config-if)# switchport access vlan 10
switch(config-if)# authentication port-control auto
switch(config-if)# mab
switch(config-if)# dot1x timeout tx-period 10
switch(config-if)# end
switch#

What just happened: The interface is set as an access port in VLAN 10. authentication port-control auto enables 802.1X (the port becomes unauthorized until authentication succeeds). The mab command enables MAC authentication bypass as a fallback. The dot1x timeout tx-period controls the frequency of 802.1X EAPOL packet retransmits (affects authentication responsiveness). Together, the port will try 802.1X, and if no EAP exchanges occur, the switch will attempt MAB.

Real-world note: In production, coordinate dot1x timers with supplicant behavior and ISE timeouts to avoid premature MAB triggering.

Verify:

switch# show authentication sessions interface GigabitEthernet1/0/10
Interface: GigabitEthernet1/0/10
    MAC Address: 0023.45ab.cdef
    Authenticator State: AUTHORIZED
    Method: MAB
    VLAN: 10
    Assigned Policy: EASY-CONNECT-AD (temporary)

Expected output shows the session state (example values above). The "Method: MAB" indicates the port authenticated via MAC and the assigned policy (temporary ACL) is EASY-CONNECT-AD.

Step 4: Design the ISE Policy Set Order and Rules (GUI design translated to bullet commands)

What we are doing: Create a deterministic Policy Set ordering in ISE: NAD Group/Location -> Authentication Type -> Authorization Rules. The goal is to match specific cases first (EAP-TLS for managed endpoints), then PEAP (corporate guests), then MAB (Easy Connect). Although these ISE steps are performed in the GUI, we express the design here so the NAD and ISE rules align.

# This is a conceptual representation (ISE GUI actions)
# 1) Create Policy Set: Name = Wired_SJC01
#    Condition: Network Device Group == SJC01
# 2) Authentication policy:
#    - Rule 1: If EAP method == EAP-TLS -> authenticate via Certificate store
#    - Rule 2: If EAP method == PEAP -> authenticate via AD
#    - Rule 3: If RADIUS request has no EAP (MAB) -> authenticate via MAB (MAC)
# 3) Authorization policy (order matters):
#    - Rule A: If identity group is Azure_AD_Employee -> Full Access (VLAN or ACL any)
#    - Rule B: If identity group is Unknown & MAB -> Apply EASY-CONNECT-AD ACL
#    - Rule C: Otherwise -> Guest VLAN / Deny

What just happened: The policy set design specifies that ISE first uses the NAD group (SJC01) to quickly scope requests. Authentication rules are ordered most-specific to least-specific so EAP-TLS devices don't accidentally get MAB. Authorization rules apply the minimal pre-auth ACL for MAB sessions and full access once AD identity is confirmed.

Real-world note: Keeping policy sets scoped by location or device type (SJC01) prevents unnecessary evaluation against unrelated rules and reduces TPS on ISE PSNs.

Verify (conceptual GUI verification):

# From ISE GUI: Review Policy Sets -> Wired_SJC01
# Expected:
# - Policy Set Condition: Network Device Group == SJC01
# - Authentication rules listed in order: EAP-TLS, PEAP, MAB
# - Authorization rules in order: Azure_AD_Employee -> Full Access, MAB -> EASY-CONNECT-AD, Default -> Guest

Expected verification is that the GUI shows the policy set with conditions and ordered rules as listed.

Step 5: Validate the End-to-End Flow and CoA Binding After AD Login

What we are doing: Test and validate the full Easy Connect lifecycle: MAB grants temporary AD-only access; user logs in to Windows (AD), ISE receives login event, binds username to MAC, and issues CoA to elevate access. This confirms the policy ordering and CoA workflows are correct.

# On switch, observe the session before AD login:
switch# show authentication sessions interface GigabitEthernet1/0/10
Interface: GigabitEthernet1/0/10
    MAC Address: 0023.45ab.cdef
    Authenticator State: AUTHORIZED
    Method: MAB
    VLAN: 10
    Applied ACL: EASY-CONNECT-AD

# After user logs into AD and ISE sends CoA:
switch# show authentication sessions interface GigabitEthernet1/0/10
Interface: GigabitEthernet1/0/10
    MAC Address: 0023.45ab.cdef
    Authenticator State: AUTHORIZED
    Method: MAB
    VLAN: 10
    Applied Policy: FULL-ACCESS
    Username: alice@lab.nhprep.com

What just happened: Initially the switch applied the EASY-CONNECT-AD ACL because authentication used MAB. After AD login, ISE correlated the AD login event to the a MAB session and issued a Change of Authorization (CoA). The switch then replaced the temporary ACL with the full-access authorization and the session shows the username bound to the MAC.

Real-world note: Ensure AD event collection or connectors are working; the binding step requires ISE to receive username/MAC mapping from AD/login events.

Verify:

switch# show access-lists
Extended IP access list EASY-CONNECT-AD
    [entries as in Step 2]
Extended IP access list FULL-ACCESS
    10 permit ip any any

Expected output shows that the ACL on the session transitioned from EASY-CONNECT-AD to FULL-ACCESS after CoA.

Verification Checklist

  • Check 1: Switch running-config contains authentication display new-style. Verify with show running-config | include authentication display.
  • Check 2: EASY-CONNECT-AD ACL exists and contains the permit lines shown. Verify with show ip access-lists EASY-CONNECT-AD.
  • Check 3: The access port is configured for 802.1X with MAB fallback and shows sessions in AUTHORIZED state. Verify with show authentication sessions interface GigabitEthernet1/0/10.
  • Check 4: After AD login, ISE issues CoA and the port’s applied policy switches from EASY-CONNECT-AD to FULL-ACCESS. Verify with show authentication sessions interface GigabitEthernet1/0/10 and show access-lists.

Common Mistakes

SymptomCauseFix
Port remains in unauthorized state despite valid credentialsSwitch timers too short or supplicant misconfigurationIncrease dot1x timeout and validate supplicant settings on endpoints
Endpoint cannot reach AD during MAB pre-authEASY-CONNECT-AD ACL missing required AD service/port or not set to correct IPUpdate ACL with correct AD DC IP(s) and include necessary ports (DNS, DHCP, Kerberos, LDAP)
ISE never binds AD login to MAB sessionAD login events not being sent to ISE or RADIUS attributes missingVerify AD connector/event logs and ensure ISE receives MAC/username correlation
EAP-TLS devices being treated as MABPolicy rules ordered incorrectly (MAB before EAP-TLS)Reorder Authentication rules in the policy set: EAP-TLS first, then PEAP, then MAB

Key Takeaways

  • Order matters: Policy Sets and rules must be ordered from most-specific to least-specific to avoid accidental matches and unnecessary load on ISE.
  • Separate concerns: Use NAD grouping (e.g., SJC01) to scope policy sets and keep policy evaluation fast and predictable.
  • Minimal pre-auth access: When using Easy Connect/MAB, apply a minimal ACL (EASY-CONNECT-AD) that only permits AD-related services; this reduces exposure while enabling AD login.
  • CoA is essential: The AD login -> ISE event -> CoA cycle is what moves an endpoint from pre-auth to full access. Verify event forwarding and CoA functionality end-to-end.

Tip: Document your Policy Set naming and ordering convention. In production, that documentation is what saves hours during incident response.

If you completed these steps, your wired access policy set now handles managed endpoints, corporate EAP users, and MAB/Easy Connect devices in a predictable, auditable way. In the next lesson we will tune profiling and monitoring to refine device classification and reduce false-positive MAB matches.