ISE Troubleshooting Patterns

ISE troubleshooting patterns I’ve actually used. Every entry has a date and context.

Entries

2026-04-02: Verify Endpoint Registration via DataConnect

Problem: After iPSK MAC registration, need to verify ISE has the endpoint and correct policy assignment.

Context: P16g deployment. iPSK registration for new device via iPSK Manager. Need to confirm ISE picked up the MAC via secure ODBC and assigned the correct policy set (Domus_MAB) and authorization profile (Domus-IoT-iPSK).

The Fix:

# Endpoint identity and profiler data
netapi ise dc endpoint <P16G-MAC>
Example (P16g MAC: E0:D5:5D:6C:E1:66)
netapi ise dc endpoint E0:D5:5D:6C:E1:66
# Authentication timeline -- confirm iPSK PASSED
netapi ise dc auth-history <P16G-MAC> --hours 1
# Active MnT session
netapi ise mnt session <P16G-MAC>

Raw DataConnect SQL for deeper investigation:

# Endpoint profiler data
netapi ise dc query "
SELECT mac_address, endpoint_profile, identity_group, create_time
FROM endpoints
WHERE mac_address = '<P16G-MAC>'
"
# Auth detail by MAC
netapi ise dc query "
SELECT username, mac_address, authentication_method,
       nas_ip_address, passed, failed, timestamp
FROM radius_authentications
WHERE mac_address = '<P16G-MAC>'
  AND timestamp > SYSDATE - 1
ORDER BY timestamp DESC
"

Rule: Always verify endpoint registration after MAC-based provisioning. Don’t assume — confirm with DataConnect or ERS API. Check both the endpoint table and radius_authentications.

Worklog: WRKLOG-2026-04-02

2026-04-03: Verify EAP-TLS Migration from iPSK

Problem: After migrating from iPSK to EAP-TLS, need to confirm ISE sees dot1x (not mab) as the authentication method.

Context: P16g deployment. Wired and WiFi connections switched from iPSK (MAB) to certificate-based 802.1X EAP-TLS. ISE should now show dot1x as authentication method, EAP-TLS as protocol, and the certificate CN as identity.

The Fix:

WIRED_MAC="a8:2b:dd:8f:23:e6"
WIFI_MAC="e0:d5:5d:6c:e1:66"
# Wired -- should show dot1x/EAP-TLS, not mab
netapi ise mnt session $WIRED_MAC
netapi ise dc auth-history $WIRED_MAC --hours 1
# WiFi -- should show dot1x/EAP-TLS
netapi ise mnt session $WIFI_MAC
netapi ise dc auth-history $WIFI_MAC --hours 1
# Raw SQL -- confirm method changed from mab to dot1x
netapi ise dc query "
SELECT mac_address, authentication_method, passed, timestamp
FROM radius_authentications
WHERE mac_address IN ('$WIRED_MAC', '$WIFI_MAC')
  AND timestamp > SYSDATE - 1
ORDER BY timestamp DESC
"

Rule: After any authentication method migration, verify with ISE DataConnect that the method actually changed. Don’t trust the client side alone — check what ISE recorded.

Worklog: WRKLOG-2026-04-03

2026-04-03: Common EAP-TLS Failure Modes

Problem: Collection of EAP-TLS failure patterns and their fixes from P16g deployment.

Context: P16g deployment, both wired and wireless 802.1X EAP-TLS.

The Patterns:

Issue Fix

"Secrets required but not provided"

Missing private-key-password-flags 4 — add with nmcli connection modify

"TLS handshake failed"

CA chain incomplete — ensure CA chain PEM contains both ISSUING-CA and ROOT-CA

"Authentication rejected"

Certificate CN doesn’t match ISE identity — verify with openssl x509 -noout -subject

WiFi "invalid property identity-flags"

Remove identity-flags — only valid for wired connections

Interface disappeared after disabling iwd

Reload WiFi driver: sudo modprobe -r iwlmvm mac80211 iwlwifi && sudo modprobe iwlwifi

Wrong VLAN assigned

Check ISE authorization policy order — netapi ise get-authz-rules "Corp WIFI"

Live debugging:

# Live logs -- NetworkManager + wpa_supplicant
journalctl -u NetworkManager -t wpa_supplicant -f | grep -iE "eap|tls|auth|fail"
# Certificate chain verification
openssl verify -CAfile /etc/ssl/certs/DOMUS-CA-CHAIN.pem /etc/ssl/certs/$(hostname)-eaptls.pem
# Key/cert match (both hashes must be identical)
openssl x509 -in /etc/ssl/certs/$(hostname)-eaptls.pem -noout -modulus | md5sum
sudo openssl rsa -in /etc/ssl/private/$(hostname)-eaptls.key -noout -modulus | md5sum

Rule: EAP-TLS failures are usually one of: missing password-flags, incomplete CA chain, CN mismatch, or wrong WiFi backend. Check in that order.

Worklog: WRKLOG-2026-04-03

Template