ISE behaviour difference in identity being sent from ISE to AD.

[Avinash N.]

Hi experts,

   We have a customer who is moving from ISE 2.1 to 2.4. They have identity rewrite configured for their ADs. When a user logs in with their ID and EAP-TLS has performed the identity sent from ISE is 'host/hostname'. ISE looks for 'host/hostname' when checking all three ADs that they have configured in version 2.1. In 2.4 ISE looks for 'host\hostname' only the first time it looks into an AD Realm. The second time it looks for just hostname. Because of this and the rewrite rules configured the hostname is treated as a username and it fails lookup. 

Has this behavior changed in 2.4 can someone confirm?

Thanks

Avinash

[howon]

We had some changes to AD connector but don't believe there were changes to the identity rewrite. However, I suggest having the customer test it out in the lab to eliminate any surprises.

[Avinash N.]

We did do a lot of testing for this. Apparently, when using an IDentity source sequence the first one always takes the machine auth format 'host\hostname' and all subsequent ones ISE identifies them as a user without this format. We tried multiple combinations and its the exact same behavior. We've opened a TAC case as well- 688036298 to investigate the behavior change. Hoping to find something there.

[hslai]

CSCvc55106 might be related.

I glanced through the TAC case and found your case P3 and reassigned at least once. Re-queuing a TAC case could lead to in-efficiency of case handling, so please avoid that if possible. The assigned TAC still analyzing it so please continue working with TAC and you may ask for ESC if needed.

I am not clear why re-write needed. ISE should be able to detect host/ as computers without re-writing. Also, I would suggest to try recreating it in a lab setup so to ease debug log gathering, etc.

[Avinash N.]

Hi Hsing-Tsu,

   Thanks for the reply. I agree it's not really necessary but its a necessity for this customer since they have a complex AD structure. They have 3 AD entry points out of which one is not trusted by the other. For them to look into their AD and find the end device the format for the hostname needs to have a $ at the end so device ABC needs to be queried as ABC$ to search in domain computers. On the other hand, service accounts don't need this hence identity needs to be retained.

Thing is irrespective of whether its necessary ISE is extracting and using identity in a different format in the same identity store. The rewrite is just the symptom that allowed us to see this behavior which I am sure would have passed unnoticed if we did not rewrite. Hence the bigger concern the customer has now is why is the identity being misinterpreted when checking the second AD in the sequence.

The bug you mentioned is an enhancement and does look accurate but unfortunately is only confirming that ISE is not accurately able to identify machine auth forcing workarounds like a rewrite.

I already have an ISE cluster but its all VM. Please note that this ISE is restored from a 2.1 Backup so I'm not even sure if reproing this on a 2.4 will make a difference so if we are reproing this it will need to be done along the same path taken at the customer's device. I'm waiting for TAC to give their analysis of this problem and take a call after that.

Thanks

Avinash

[hslai]

If TAC not getting back to you in a timely fashion, you may contact his manager. FYI.

[Avinash N.]

Well, it's not about responding in a timely manner. TAC is on it and attempting the repro. I mentioned the case so that anyone interested can have a look. I started the thread to see if anyone else has seen the behavior or if someone from the BU can confirm if there has been a behavior change. If this has been seen already it could greatly help us and TAC. If this is reproduced locally then I believe most likely this should be a bug?

[hslai]

It seems TAC working on the recreate.

Please note that our process is CU -> TAC -> ESC -> DE