Today’s article is dedicated to a Cisco bug! 🐞
Once upon a time a huge customer decided to migrate from ACS 5.8 to ISE 2.3. They already had several authorization rules configured in place in ACS therefore the ACS 2 ISE 2.3 migration tool was downloaded from Cisco Hint: If you’ve never used this tool before, it is very easy to use and simplifies the migration.
The most important thing to remember is that you only use it on a fresh install of ISE. I’ve used previous versions and this is the first time I’ve had an issue like this occur.
The export from ACS and subsequent import into ISE appeared to go on a fly. It took less than half an hour to do all the steps using the migration tool. After the import was finished, I had the customer log into the ISE node in order to join it to Active Directory.
The join point was already created because it was imported from ACS. The customer then went to the Groups tab and that’s when we noticed that the SID values for all of the groups were set to the same value as the Group name. No big deal. We’ll just click the “Update SID values” button and clear that up.
Clicking the update button pulled all the right SID values from AD and assigned them to the respective group. When the customer clicked the Save button, they received the following error:
Error: an error occurred trying to save this attribute becasue some allowed values were removed whixh are used in policy: Policy Set: Rule-1, authorization rule: VPNaccess
Yes, the misspelled words are exactly how they were in the error message.
We tried changing a single SID to the correct SID and it would give the same error. We tried various things like resetting the rule and manually configuring the AD group used but nothing worked. The customer even opened a TAC ticket. The TAC engineer suggested editing the policy rule to remove the AD group condition or deleting the rule all together. Either one would in turn allow them to update the SID values successfully.
Panic started across the enterprise and among engineers because the customer was not happy at the thought of having to delete the rules and then have to manually recreate over 50 authorization rules. Editing that many rules to remove the AD group condition and then add them back after updating the SID values wasn’t a good option, either.
After a little bit of meditation a possible solution hit me. They still had the ACS to ISE migration tool on their desktop with the exported data. So we tried the following:
Delete the RADIUS and Device Admin policy sets.
Update the SID values for the AD groups in ISE.
Successfully saved since there were no policy rule conflicts.
Enabled ACS to ISE migration in the ISE node CLI.
Run the ACS to ISE migration tool again.
No export from ACS required because the original export was still there.
Only Policy Elements and Access Policies were checked for import.
Disabled the ACS to ISE migration from the ISE node CLI.
After the technicians checked the AD state the AD group SID values weren’t affected and verified the policy sets imported correctly. We were then able to verify that TACACS+ authentications and authorizations occurred correctly using the imported policy set and a test switch. RADIUS authentications, which only accounted for 2 rules, also worked properly.
Hopefully Cisco published an official workaround for this issue in Bug Search tool:
Symptom: If Active Directory SID for a group changes or if the SIDs need to be populated after ACS to ISE Migration tool, AD settings can't be saved. ISE 2.3 complains that "Some allowed values were removed that are used in a policy". Group name is not changed, only SID Conditions: SID changes on an AD group reference in the policy. AD settings cannot be changed if the group is referenced in any policies. Workaround: Remove all references to the AD group from the policy. Update SIDs. Recreate rules referencing AD groups Further Problem Description: The issue occurs when SID of the group changes and also after ACS to ISE migration.
TRADEMARK LEGAL NOTICE All product names, logos, and brands are property of their respective owners in the Austria or other countries.All company, product and service names used on this website are for identification purposes only. Pheniix is notaffiliated with or an official partner of Cisco, CompTIA,Dimension Data, VMware, Amazon, Microsoft, Certified Ethical Hacker, (ISC)², Juniper, Wireshark, Offensive Security,Google, GNS3, F5, Python, Linux, Java, Openstack, Vagrant, Ansible, Docker, GIT, , Blockchain or other companies.Use of these names, logos, and brands does not imply endorsement.The opinions expressed on pheniix are personal perspectives and not those of Cisco , Dimension Data or any other company. Pheniix runs as an independent blog.