Gotchas & Lessons Learned

This appendix documents common pitfalls encountered when deploying Linux 802.1X EAP-TLS authentication with Active Directory Certificate Services and Cisco ISE. These are real-world lessons from production deployments.

1. AD Computer Account Must Exist

ISE returns ERROR_NO_SUCH_USER when performing AD lookup if no computer account exists for the Linux host.

Problem: Unlike Windows machines that automatically create computer accounts when joining AD, Linux machines joined via SSSD/realmd may not always create the expected account format.

Solution: Verify the computer account exists in AD with the correct name format:

# On Linux - verify domain join created computer account
realm list
# Should show: configured: {domain}

# On AD (PowerShell) - verify computer object exists
Get-ADComputer -Identity "RESEARCH-WS01"

Reference: Cisco Community — Linux Machine Account for EAP-TLS

2. AD CS Template Security (ESC1 Vulnerability)

The "Supply in Request" option required for Linux CSRs is a known AD CS vulnerability (ESC1) if not properly secured.

Problem: When "Supply in Request" is enabled, any user with Enroll permission can request a certificate with any Subject Alternative Name, potentially impersonating domain admins.

Mitigations:

  1. Restrict Enroll Permissions — Create a dedicated security group (e.g., Linux-Cert-Enrollers)

  2. Enable Manager Approval — Require CA administrator review before issuance

  3. Separate Template — Create "Linux-Workstation" template (don’t reuse default Computer template)

  4. Audit Logging — Enable certificate issuance logging for forensic review

# PowerShell - Create security group for Linux cert enrollment
New-ADGroup -Name "{ad-group-cert-enrollers}" `
    -GroupScope DomainLocal `
    -Description "Users authorized to enroll Linux workstation certificates"

# Add specific admins to group
Add-ADGroupMember -Identity "{ad-group-cert-enrollers}" -Members "cert-admin"

Reference: PKI Solutions — Request Extension Processing

3. Certificate Identity Field Mismatch

ISE certificate authentication may fail if the identity field in wpa_supplicant or NetworkManager doesn’t match what ISE expects for AD lookup.

Problem: ISE looks up computer accounts using multiple attributes:

  • sAMAccountName (e.g., WORKSTATION$)

  • SPN with host/ prefix (e.g., host/workstation.domain.com)

  • UPN (e.g., WORKSTATION$@domain.com)

  • distinguishedName

Solution: Ensure the identity matches the expected format:

# NetworkManager connection - use machine account format
nmcli connection modify "Wired-802.1X" \
  802-1x.identity "$(hostname -s)\$@inside.domusdigitalis.dev"
# wpa_supplicant.conf - use machine account format with $ suffix
network={
    identity="WORKSTATION$@inside.domusdigitalis.dev"
    # ...
}

Verification: Use ISE "Test User" function in the AD join point to verify lookup works.

4. Certificate Format Conversion

AD CS typically exports certificates in PKCS#12/PFX format, but wpa_supplicant and NetworkManager require PEM format.

Problem: Receiving a .pfx file from AD CS and using it directly will fail.

Solution: Convert using OpenSSL:

# Extract client certificate (no private key)
openssl pkcs12 -in machine.pfx -out /etc/ssl/certs/machine.crt -clcerts -nokeys

# Extract private key (unencrypted for wpa_supplicant)
openssl pkcs12 -in machine.pfx -out /etc/ssl/private/machine.key -nocerts -nodes

# Extract CA certificate chain
openssl pkcs12 -in machine.pfx -out /etc/ssl/certs/ca-chain.crt -cacerts -nokeys

# Set correct permissions
chmod 644 /etc/ssl/certs/machine.crt /etc/ssl/certs/ca-chain.crt
chmod 600 /etc/ssl/private/machine.key

5. EAPOL Version Compatibility

Some older network switches only support EAPOL version 1, while wpa_supplicant defaults to version 2.

Problem: Authentication fails with older switches that reject EAPOL v2 packets.

Solution: Add fallback to wpa_supplicant configuration:

# /etc/wpa_supplicant/wpa_supplicant-eth0.conf

# Try version 1 if experiencing issues with older switches
eapol_version=1

# Default is version 2 (IEEE 802.1X-2004)
# eapol_version=2

Diagnosis: If authentication works on newer switches but fails on older ones, try EAPOL v1.

6. Missing CA Certificate Validation

Omitting ca_cert disables server certificate validation, enabling man-in-the-middle attacks.

Problem: Without the CA certificate, the Linux client cannot verify that it’s talking to the legitimate ISE server.

Solution: Always specify the CA certificate:

# wpa_supplicant
network={
    # REQUIRED for security - validates ISE server identity
    ca_cert="/etc/ssl/certs/HOME-ROOT-CA.pem"

    # Client authentication
    client_cert="/etc/ssl/certs/machine.crt"
    private_key="/etc/ssl/private/machine.key"
}
# NetworkManager
nmcli connection modify "Wired-802.1X" \
  802-1x.ca-cert "/etc/ssl/certs/HOME-ROOT-CA.pem"

Note: Use full absolute paths; relative paths may fail when running as background service.

7. AD CS Template Subject Name Override

Enterprise CA may override the Subject Name from your CSR with values from Active Directory.

Problem: When the certificate template is set to "Build from AD," the CA ignores the Subject Name in your CSR and uses AD attributes instead.

Solution: For Linux workstations, the template must use "Supply in Request":

  1. Open Certificate Templates Console (certtmpl.msc)

  2. Duplicate the "Computer" or "Workstation Authentication" template

  3. Name it "Linux-Workstation-Auth"

  4. Under Subject Name tab:

    • Select "Supply in the request"

  5. Under Security tab:

    • Remove "Domain Computers" Enroll permission

    • Add Linux-Cert-Enrollers with Enroll permission

  6. Under Issuance Requirements tab (optional):

    • Check "CA certificate manager approval"

8. iwd vs wpa_supplicant Conflict (WiFi)

iwd and wpa_supplicant cannot coexist for WiFi management. This is the most common cause of inconsistent WiFi behavior on Linux.

Problem: If both iwd and wpa_supplicant are installed, they compete for control of the WiFi interface, causing:

  • WiFi connects but requires manual DHCP each time

  • Interface state flaps between COMPLETED and DISCONNECTED

  • wpa_state=INTERFACE_DISABLED in wpa_cli status

  • wlan0 interface disappears randomly

Solution: For 802.1X EAP-TLS, disable iwd completely:

# Disable iwd
sudo systemctl stop iwd
sudo systemctl disable iwd
sudo systemctl mask iwd  # Prevent accidental start

# Use wpa_supplicant for WiFi 802.1X
sudo systemctl enable wpa_supplicant@wlan0
sudo systemctl start wpa_supplicant@wlan0

Background:

  • iwd: Modern WiFi daemon, simpler config, good for PSK networks

  • wpa_supplicant: Mature, full 802.1X EAP-TLS support, enterprise-grade

For enterprise 802.1X, wpa_supplicant is the correct choice.

9. DNS Resolution Failure After WiFi Auth

WiFi may authenticate successfully but have no DNS resolution if dhcpcd isn’t running.

Problem: After WiFi 802.1X authentication completes, /etc/resolv.conf is empty:

ping www.google.com
ping: www.google.com: Temporary failure in name resolution

Diagnosis:

# Check if resolv.conf is empty
cat /etc/resolv.conf

# Check if dhcpcd is running
ps aux | grep dhcpcd
# If only "grep" shows, dhcpcd is NOT running

Solution:

# Start dhcpcd for WiFi interface
sudo dhcpcd wlp4s0

# Verify DNS is now configured
cat /etc/resolv.conf

Root Cause: The dhcpcd.service doesn’t automatically start for WiFi after wpa_supplicant authenticates.

Permanent Fix Options:

  1. Run dhcpcd without interface argument (manages all interfaces)

  2. Create wpa_supplicant action script to start dhcpcd on CONNECTED event

  3. Configure systemd dependency between wpa_supplicant and dhcpcd services

10. WiFi Interface Disappears

If wlan0 interface disappears after stopping iwd or during driver issues, reload the WiFi kernel modules.

Problem: ip link shows no wlan0 interface after service changes.

Solution (Intel WiFi):

# Unload and reload Intel WiFi drivers
sudo modprobe -r iwlmvm iwlwifi
sudo modprobe iwlwifi

# Verify interface returns
ip link | grep wlan

# Restart wpa_supplicant
sudo systemctl restart wpa_supplicant@wlan0

11. Certificate Attributes Scope Limitations (CRITICAL)

Certificate:Template Name is NOT available in authorization rule scope. ISE will reject the rule with "Condition attributes are illegal for requested scope."

Problem: When creating authorization rules to differentiate EAP-TLS certificates by template (e.g., Linux workstations vs Windows machines), the intuitive approach of using Certificate:Template Name fails:

netapi ise add-authz-rule "Domus-Wired 802.1X" "Linux_EAPTLS" "Linux_Permit" \
  --and "Certificate:Template Name:equals:Linux-Workstation-Auth"

# ERROR: Condition attributes are illegal for requested scope: [ Certificate : Template Name ]

Root Cause: ISE separates certificate attributes into two dictionaries with different scopes:

Dictionary Scope Available Attributes

Certificate

Authentication rules only

Template Name, Subject, Subject Alternative Name, Issuer

CERTIFICATE

Authorization rules

Issuer - Common Name, Issuer - Organization, Subject - Common Name, Subject - Organization

Solution: Use CERTIFICATE:Issuer - Common Name to differentiate certificates in authorization rules:

# Query available attributes in CERTIFICATE dictionary
curl -sk "https://${ISE_PAN}/api/v1/policy/network-access/dictionaries/CERTIFICATE" \
  -H "Accept: application/json" \
  -H "Authorization: Basic $(echo -n ${ISE_API_USER}:${ISE_API_PASS} | base64)" | \
  jq '.attributes[] | {name, allowedInCondition}'

Working Example:

# Create authorization rule using issuer instead of template name
netapi ise add-authz-rule "Domus-Wired 802.1X" "Linux_EAPTLS_Permit" "Linux_EAPTLS_Permit" \
  --and "Network Access:EapAuthentication:equals:EAP-TLS" \
  --and "CERTIFICATE:Issuer - Common Name:equals:HOME-ROOT-CA" \
  --rank 0

Validation: Confirmed working on Domus ISE (2026-02-05). Auth history shows compound AND condition matching correctly.

Caveat: Using issuer CN is less specific than template name. All certificates from the same CA will match. For tighter control:

  1. Use a dedicated subordinate CA for Linux workstations

  2. Combine with endpoint identity group membership

  3. Add additional conditions (e.g., AD group, device type)

12. Authorization Rule Ordering

ISE evaluates authorization rules top-to-bottom. First match wins. A generic rule at the top shadows more specific rules below.

Problem: Endpoint matches wrong rule, gets wrong VLAN or dACL.

Example: Wrong order (generic shadows specific):

#0: EAP-TLS_AllUsers      <- Matches ALL EAP-TLS (too broad!)
#1: EAP-TLS_Admins        <- Never reached (shadowed)

Correct order (specific before generic):

#0: EAP-TLS_Admins        <- Matches admins first
#1: EAP-TLS_AllUsers      <- Matches remaining users

Solution:

# Check rule order
netapi ise get-authz-rules "Domus-Wired 802.1X"

# Delete or reorder shadowing rules
netapi ise delete-authz-rule "Domus-Wired 802.1X" "Generic_Rule" --force

# Create specific rule at rank 0
netapi ise add-authz-rule "Domus-Wired 802.1X" "Specific_Rule" "Profile" \
  --rank 0 ...

See ISE Troubleshooting for the full modestus-razer resolution case study.

13. VLAN Assignment Uses Names, Not Numbers

ISE VLAN assignment uses VLAN names from the switch, not numeric IDs.

Problem: Setting --vlan 10 in authorization profile results in silent failure; endpoint gets default VLAN.

Solution: Use the VLAN name exactly as configured on the switch:

# Check switch VLAN names
netapi ios exec "show vlan brief"
# Output:
# 10   DATA_VLAN      active
# 40   RESEARCH_VLAN  active

# Use NAME in ISE profile (correct)
netapi ise update-authz-profile "Linux_EAPTLS_Admins" --vlan "DATA_VLAN"

# NOT numeric ID (incorrect)
# netapi ise update-authz-profile "Linux_EAPTLS_Admins" --vlan 10

14. Private Key Permissions

If private key permissions are too open, wpa_supplicant and NetworkManager will refuse to use it.

Problem: Authentication fails with "error loading private key" even though file exists.

Solution:

# Set correct permissions
sudo chmod 600 /etc/ssl/private/machine.key
sudo chown root:root /etc/ssl/private/machine.key

# Verify
ls -la /etc/ssl/private/machine.key
# Must show: -rw------- root root

15. Clock Synchronization Critical

Certificate validation is time-sensitive. If system clock is wrong, certificates appear expired or not yet valid.

Problem: Valid certificate rejected with "certificate not yet valid" or "certificate expired".

Diagnosis:

# Check system time
timedatectl status

# Check certificate validity period
openssl x509 -in /path/to/cert.pem -noout -dates

Solution:

# Sync time via NTP
sudo timedatectl set-ntp true

# Or manually set time
sudo timedatectl set-time "2026-02-05 10:30:00"

# Verify NTP sync
timedatectl show --property=NTPSynchronized

16. Troubleshooting Checklist

Use this checklist when 802.1X authentication fails:

  • AD computer account exists with correct hostname

  • Certificate template has "Supply in Request" enabled

  • Template Enroll permission restricted to authorized group

  • Certificate converted to PEM format

  • Private key permissions set to 600 (root only)

  • CA certificate installed and specified in config

  • Identity field matches AD account format (with $ suffix)

  • ISE has Root CA in trusted certificate store

  • ISE Certificate Authentication Profile configured

  • System clock synchronized via NTP

  • iwd disabled if using wpa_supplicant for WiFi

17. References