ISE Machine Authentication Failure

[rmfalconer]

We updated our ISE 2.4 instance to patch 12 over the weekend. After the update, ISE cannot properly authenticate machine accounts in AD. User accounts are unaffected.

Running the 'Test User Authentication' for a machine produces a failed result.

This was working before the patch update. The configuration hasn't changed.

We do have a case open with support but I'm curious if anyone has seen this before.

[paul]

When are doing a test user are you doing the proper format:

host/<computername> or computername.mycompany.com$

If so what does ISE show when you run the test?  Could be something got messed up if you were doing AD rewrites of some sort on the advanced screen.  Also the details of the authentication record should should show any rewrites or what the exact identity ISE is trying to lookup in AD.

[rmfalconer]

Interesting results. I hadn't thought to test with host/name, only the fqdn.

host/name is successful while the fqdn fails. 

There are no re-writes happening.

When it fails, it provides pretty generic output, no user found.

Test Username : host.domain.com
ISE NODE : <node>
Scope : <scope>
Instance : <domain>

Authentication Result : FAILED

Error : No such user, please refer to Test user option to get further information

[paul]

host.domain.com shouldn't work.  That is not a proper computer account lookup.  host.domain.com$ should work.  Is this failing on Windows machines?  The Windows supplicant passes the computer name in host/<computer name> format.

[paul]

Just to show you what the acceptable formats are for AD lookup, you can look on the Advanced tab and enable rewrites to see the defaults:

[HOSTNAME].[DOMAIN] is not in the list.  In my experience I have always had to add a rewrite rule for this:

if [HOSTNAME].[DOMAIN] rewrite as host/[HOSTNAME].[DOMAIN]

or

if [HOSTNAME].[DOMAIN] rewrite as host/[HOSTNAME]

[rmfalconer]

After going through more logs, it looks like the username that's pulled from the endpoint is in the format host/fqdn. When I run the test on this naming format, it is successful.

The failure detail in ISE and the logs output to Splunk both show that format.

[paul]

When you run the tests you get to pick what ISE node to run it from.  Make sure you test it from each PSN to ensure one of the PSNs is not having issues with AD authentication. 

[Marco Noviello]

Can you compare authentication / authorization after and before patch installation?
In my environment I see that bevore patch 12 ISE look up machine in AD for authorization,
after patch 12 ISE look up user instead of machine.

[Marco Noviello]

TAC provide me with this workaround: issue is due to bug CSCvr51940

Or use this Certificate Authentication Profile settings:

I resolved my issue changing the cert.authen. profile.

[jaime.diaz@leidos.com]

The bug tool states this has been fixed.  I am sorry to report that this has not been fixed in 3.7 patch 4.  Our setup was configured using "Only resolve identity ambiguity" and tried chaining it to use "Always perform binary comparison".  We also have the cert profile to use "Subject - Common Name".  Once that change was done, the cert auth failed as it was looking for username@domain.com.  We had to roll back and use "Only resolve identity ambiguity".  Once that was done everything started working again.  Our machine auth is looking for host/fqdn.  Once changed to binary, it wants to look for username@domain.com.

[poongarg]

If you are using certificate based machine authentication with binary comparison enabled under Certificate Authentication profile.

Attach the detailed failed authentication report for the failing machine.

[yasser.aljamil]

Hi,

I had the same issue also when upgraded from ISE 2.4 Patch 11 to Patch 12...Opened a case too, we tried everything including configuring rewrite rule but this didn't help. Had a support case opened and we fell back to patch 11...

[rmfalconer]

Like @yasser.aljamil, TAC has asked me to try the work-arounds and rewrites mentioned in other posts. Nothing has worked to fix the issue. My guess is that we'll have to rollback the patch also. The case is being escalated now and I will update if there's a different outcome.

[Surendra]

This is a known issue in a way.. these changes were introduced by a fix for another bug. You can simply rollback to 11 as you said or whatever patch you were on before. You can ask for a hotfix to see if its possible.

[Damien Miller]

This thread has me concerned about patching customer deployments, I don't see anything noted in the release notes about a change in behavior, but something significant has clearly changed. Also worrying is that I found this issue outlining a patch 12 rollback might not work without TAC/root. So it compounds the impact if you need to back out.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu39890