AD join point scope mode order of operation

[Madura Malwatte]

What is the order an identity is checked in identity source sequence when a scope is used with two AD join points? I have added both newAD and oldAD to a scope, so is the order the AD is checked from top to bottom (i.e. newAD first then oldAD), if I have only reference All_Scope in an identity source sequence? 

It doesn't look like I can change the order of the join point in scope mode, is that correct? Basically if I have a duplicate user in both the newAD and oldAD, so will it only take the match on the newAD only - meaning any authorization rules with condition for AD group from the oldAD will never get matched?

It looks like going through a radius live log session output, ISE checked the account against both join points in the scope, I see:

"Search for matching accounts at join point - oldAD", and

"Search for matching accounts at join point - newAD", then

"User authentication against Active Directory succeeded - All_Scope". 

However in the authentication details section, ISE has picked Authentication Identity Store as "newAD". I can see the radius messages:

"Looking up user in Active Directory - newAD" and

"User's Groups retrieval from Active Directory succeeded - newAD"

Why did ISE pick newAD instead of oldAD? The issue is we are migrating from oldAD to newAD and our authz policies conditions are still AD groups under oldAD, so because ISE decided to use newAD, none of the authz policies were being hit except for the default policy.

[Mike.Cifelli]

My recommendation would be to build out separate global policies. One to support the old AD and one to support new AD. Then in Authc use separate identity source sequences. One for old and one for new. IMO this will be easier. You could even in the global policies match on device type or some other condition that allows you to identify switches with users that have been migrated already or next up to migrate. HTH!

[Madura Malwatte]

I was thinking about this, but I am not sure if it will work. The way the authc policies work if conditions match one authc policy then it won't match another to use a different identity source sequence. Example an authc policy has condition wireless and SSID, radius session will only ever match the top policy. How would I differentiate my existing users to use the existing policies and new test users to use the new global / authc policies?

[Mike.Cifelli]

In global policy sets you have several options to differentiate between the two. Some examples are:
DEVICE type EQUALS: ###
Network Access IP EQUALS ###
Then you wont have to worry about the authc stuff as much. You would just rely on the global conditions and then use your specific identity source sequence for each one that you build out.
So an example in your case could look like this:
If Wired MAB (or 8021x) AND DEVICE (device type) EQUALS #MigratedDevices then allow your protocols you use. Then under this global policy make your authc conditions how you wish and use identity source NEW AD. In this scenario you would basically be relying on differentiating based on network device types. Depending on your migration strategy this may suffice. However, if you have users on the same NAD that contain old & new then this may not be the best idea. Good luck & HTH!

[Madura Malwatte]

Is anyone able to confirm the order the join points are picked in a scope which contains two join points if user exist in both join points?

[howon · Accepted solution]

In general with AD authentication when there are multiple user accounts with same username with same password, the authentication will fail. But I am not sure what will happen when user exists in a separate join point as you noted. I will try to find the answer for this. However, as others have noted I also suggest crafting policy so as not to go through both join points if possible. Referencing external ID source is taxing in terms of time and best to simplify the flow if possible. You can achieve this by creating two separate authentication rule. Craft one rule that reads if username domain suffix ends with abc.com then use abc.com join point. Create another rule that uses other join point which will also match when the username doesn't include and domain suffix (I.E. using short username format).