07-05-2019 06:22 AM
In certain early releasess of ISE 2.1 and 2.2, if the Super Admin Group was cloned, members of the new *cloned group* could delete other admins as would be expected. However, after upgrading to 2.3 patch 6 this functionality no longer works. Now, when a member of the cloned Super User group tries to delete another admin, they are told they don't have sufficient privileges. Admins must now be a member of the original Super User group to delete other admins. This has put a real hindrance on operations for a large ISE deployment that has admin users coming and going.
After opening a TAC case (686954441), TAC cited that the documentation for 2.2 specifically calls out "Only the Admin User from the default Super Admin Group can modify or delete other admin users. Even an externally mapped user who is part of an Admin Group cloned with the Menu and Data Access privileges of the Super Admin Group cannot modify or delete an Admin User." Source: https://www.cisco.com/c/en/us/td/docs/security/ise/2-3/admin_guide/b_ise_admin_guide_23/b_ise_admin_guide_23_chapter_011010.html#reference_FF8CD097D1B1441C9F9C2301E3C222E3
I couldn't get a reason why this functionality changed. I wondering if it is due to this vulnerability? https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi44041
If so, this seems like a bad way to fix the underlying issue?
Can anyone explain the rationale behind this?
Solved! Go to Solution.
07-06-2019 01:59 PM
I had a look at the authorization policy in ISE 2.4 Patch 9. The permission to delete another admin user is not a customizable item in term of ISE admin menu access or ISE admin data access. Consequently, such permission can be prone to change between releases and patch levels.
From my understanding, this customer deployment can achieve the same goal by moving the existing internal admin users or external user groups to the built-in "Super Admin" and this is definitely supported.
Cisco Identity Services Engine Privilege Escalation Vulnerability is related. In case the customers would still like a root cause analysis (RCA) on this change, please ask TAC to open an ISE ESC case.
07-06-2019 01:59 PM
I had a look at the authorization policy in ISE 2.4 Patch 9. The permission to delete another admin user is not a customizable item in term of ISE admin menu access or ISE admin data access. Consequently, such permission can be prone to change between releases and patch levels.
From my understanding, this customer deployment can achieve the same goal by moving the existing internal admin users or external user groups to the built-in "Super Admin" and this is definitely supported.
Cisco Identity Services Engine Privilege Escalation Vulnerability is related. In case the customers would still like a root cause analysis (RCA) on this change, please ask TAC to open an ISE ESC case.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: