I85PREP
⌘ K
Cisco 300-715 SISE study materials
Cisco 300-715 SISE study resources

EMEA Forest Trust and Machine-to-User Authentication on ISE

Cisco 300-715 SISE · Put your knowledge to work in context.

All case studies

EMEA Forest Trust and Machine-to-User Authentication on ISE

Northwind Components runs Cisco ISE 3.1 with one PAN, one MnT, and two PSNs. The primary AD forest is corp.northwind.local; a two-way forest trust connects it to emea.northwind.local. Managed Windows laptops use 802.1X EAP-TLS with certificates from an internal Microsoft CA, and the supplicant is configured for machine and user authentication. EMEA users sign in with [email protected]. Symptoms: EMEA user authentication intermittently fails with '24408 User authentication against Active Directory failed'; some laptops fail TLS with '12522 EAP-TLS failed SSL handshake'; machine authentication succeeds but the follow-up user authentication fails, leaving the port in the machine-auth authorization result. Certificates on 30 laptops have only the hostname in the Subject CN and no SAN. ISE is joined only to corp.northwind.local, and DNS forwarding for the EMEA domain was recently restricted. The EMEA helpdesk reports 40-60 tickets per day.

1. Why do EMEA users fail authentication even though a two-way forest trust exists, and what should you verify or change in ISE and AD?

Read the worked answer

The trust is necessary but not sufficient. ISE must be able to resolve and reach the EMEA domain controllers, and the user must be looked up in an identity source that covers that domain.

Check in this order:

  1. DNS and routing from the PSNs: resolve _ldap._tcp.emea.northwind.local SRV records and reach EMEA DCs on Kerberos/LDAP ports. The recent DNS restriction is the most likely cause of intermittent 24408 events.
  2. Trust health: confirm the forest trust is two-way and that selective authentication is not blocking the ISE computer account.
  3. Identity source coverage: ISE is joined to corp.northwind.local. Add emea.northwind.local as an AD identity source, or use a trusted-domain lookup if supported by the deployment, and confirm group retrieval from the trusted domain.
  4. UPN handling: the user logs in as [email protected]; make sure the identity source sequence uses the UPN identity store and that the suffix matches the EMEA UPN suffix.
  5. Sequence order: place the EMEA source before the local store for the EMEA SSID so the lookup does not stop at the joined domain.

After fixing DNS, retest with one EMEA account and read the authentication detail report to see which identity store was actually queried.

2. Why do the 30 CN-only certificates fail EAP-TLS, and how do you fix the issue without weakening certificate validation?

Read the worked answer

EAP-TLS fails when the certificate presented by the client does not satisfy the certificate authentication profile used by ISE, or when the chain cannot be validated.

The CN-only certificates are not automatically invalid, but they fail if the profile expects a SAN identity. Check the certificate authentication profile: if it uses Subject Alternative Name as the identity, CN-only certificates cannot match and the handshake fails with 12522. Either change the profile to use the Subject CN for those devices, or reissue the certificates with a SAN. Also verify:

  • The client certificate has the clientAuth EKU.
  • The Microsoft CA chain is imported into ISE Trusted Certificates.
  • CRL or OCSP is reachable from the PSNs.
  • The supplicant sends the full chain and selects the correct certificate.

Intermittent 12522 can also come from the supplicant choosing a different certificate or a TLS version mismatch. Standardize the template with SAN equal to the DNS hostname, update the GPO, and re-enroll the 30 laptops. Do not disable certificate validation just to make the test pass; that hides the identity mismatch and weakens the policy.

3. How should the authorization policy handle machine authentication followed by user authentication, and why does the port stay in the machine result?

Read the worked answer

Machine authentication and user authentication are separate sessions. The port stays in the machine result because the user session never completed or no CoA moved the port to the user policy.

Design the policy as two explicit rules:

  • Machine rule: condition AD-Machine-Authenticated = true and EAP-TLS, returning a restricted machine VLAN or dACL that allows only what the computer needs before login.
  • User rule: condition AD-User-Authenticated = true, returning the normal user VLAN, SGT, or dACL. The user rule must be evaluated after the user session starts.

Then verify:

  1. The supplicant is set to perform user authentication after Windows login.
  2. The switch port allows reauthentication and CoA.
  3. ISE live sessions show a machine session and a separate user session; if only the machine session exists, the user credential or user certificate is failing.
  4. For EAP-TLS user auth, the user certificate must exist in the user store; for PEAP, the password must be valid.

If the requirement is to block access until user auth, add a machine access restriction or posture condition. Otherwise, the machine result is expected until the user session succeeds and CoA is applied.