ISE- TACACS Device Admin- AD Group Membership as Condition not working

[klanard]

We have a working ISE deployment with AD Integration. Authentication works correctly, however the AD!- ExternalGroups-EQUALS-XXXXXX Is not matching on the policies in the TACACS policies.  It was a migrated configuration which worked correctly in ACS 5.6 deployment.  The configuation is right along the lines of the documentation and clearly correctly (such as example in Configure ISE 2.0: IOS TACACS+ Authentication and Command Authorization based on AD group membership - Cisco) , however it is just skipping the AD Checks. With a condition removed of AD External Group EQUALS, all other attributes of the policy matches and authorizes users correctly. Is this a known bug? The details page lists :

	24420	User's Attributes retrieval from Active Directory succeeded
	24100	Some of the expected attributes are not found on the subject record. The default values, if configured, will be used for these attributes

Its not working to check  a group membership as a condition of a policy match.  Its ISE  versoin 2.2.0.470 patch 1

Thanks!

[hslai]

No, this is not a known issue. Best to engage Cisco TAC.

Is "Test User" working ok in your AD configuration page to retrieve groups and attributes?

[klanard]

Yes Test User works fine shows all the groups.

[paul]

Did you verify the AD groups got correctly mapped over on the External Identities screen?  I don't use the migration utility for my ACS to ISE work so not sure how reliable it is in restoring the group mappings.

[klanard]

Ill re-check this but yes. I ire-mported manually all the groups from AD as part of troubleshooting. I will do a few test case rules before I open a TAC case just thought id ask here in case it was a known issue. Thanks!

[nikhilcherian]

can you change from "ExternalGroups-EQUALS-XXXXXX " to "ExternalGroups-CONTAINS-XXXXXX "  & try

Regards

[klanard · Accepted solution]

I manually deleted all the AD Groups that were migrated from the ACS and manually re-added them. I went through each policy and reassigned the groups in the rules with AD groups in them. Each time saving in between. Afterwards things started working. looking at the polices the syntax was correct to the letter on visual inspection but something internally wasn't matching. When I manually remapped each AD Group after re-importing them they all started working. Thanks all for your helpful feedback, you saved me from having to open a TAC case.

[seanmcgartland]

I had this issue when upgrading from ACS5.5 go ACS5.8. AD-based authorization started failing after the upgrade. Authentications were good, just not authorization. I found that the way ACS had the AD groups stored differed in case from what it retrieved from AD after the upgrade. I had to remove the old groups from the policy, delete them from the AD configuration page, then re-add the exact same group. After that the case matched what was fetched, and authorizations succeeded after I added back the group matching look-ups in the policies.

For example:

mydomain.local/management/groups/router-admins

had to be changed to:

MYDOMAIN.LOCAL/Management/Groups/router-admins

[klanard]

yes basically the same thing happened with ISE. Appeared to be a formatting/syntax issue etc.

[hslai]

I've asked our engineering team to take a look. Do you have a reliable procedure to recreate this? Has this been always happening with some particular version of ACS (e.g. 5.5) as the source? Both ISE 2.0+ and ACS 5.8+ would be storing SIDs of the groups. Were you getting warnings or errors if clicking on the button [ Update SID Values ]?

[klanard]

I did run the check SIDs and those all either updated or were ok. I didnt write down the response from the server when I clicked it.  However  even after doing so  the problem was there. I ran the current  migration utility from ACS 5.6 to ISE 2.2 to import the users,, devices, and policies. They all looked  ok visually but no  AD matching External Groups policies were matching rules on authorization. After some frustration I deleted all the  AD Groups, re-imported them manually, and manually reassigned them to each policy afterward and then they worked correctly. Thanks!

[levi.ilyes]

I can confirm that this is still an issue. I have used the migration tool to migrate from ACS 5.8.0.32.9 to ISE 2.4.0.357 and all my rules and object have been successfully migrated, no warnings and no errors. After the migration tool completed, I joined the AD domain successfully and all the groups I am using in Policy Sets were successfully pulled but they needed the SID update. I ran it and it was also successful however when I tried to save the updated SIDs I got an error message that it cannot be done because the groups are used in the policy sets. I had to remove the AD Group matching rule from each of my policies and only then did ISE allow me to save the updated SID values. Once I saved them and re-added the AD Group match to each policy set rule, Conditions started being matched by ISE.

So to sum up the issue, you need to update SIDs for the ACS migrated conditions for them to match but you cannot update SIDs if any of the groups are used in a policy match condition which of course they are. This needs fixing since it creates major extra work for admins to delete than re-add all AD match conditions to all policy sets configured.

[paul]

As I have said on other posts, the moral of this story is don't use the ACS to ISE migration utility.  Unless you are completely new to ISE and ACS, manually migrating from ACS to ISE is pretty quick and you have total control of the process vs. pushing a button on some utility and hoping it works and living with the object names and policy setup it comes up with.

[levi.ilyes]

I do not agree with you on this. The migration tool is super helpful to migrate large amounts of settings, and policy rules. If all you have is 5-10 rules and a couple policies, manually re-creating them is not a big issue but think of several policies with dozens if not hundreds of complex rules in them. Re-creating them from scratch is a huge effort and is extremely error-prone. The right thing to do is fix the migration tool since other than this small glitch, it works really well and speeds up the deployment of a new ISE deployment from several days to several hours with minimal risk of lost or misconfigured policy rules.

[paul]

I have done 20-30 ACS to ISE migrations some with 100s of rules all manually. It is probably me being more particular with naming conventions and what exactly I want to bring from ACS to ISE. Most times you don't want to bring everything or want to rearchitect.