cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
298
Views
5
Helpful
1
Replies

Admin members of Cloned 'Super Group' Cannot Delete Other Admins

Ty Rost
Cisco Employee
Cisco Employee

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?

 

1 Accepted Solution

Accepted Solutions

hslai
Cisco Employee
Cisco Employee

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.

View solution in original post

1 Reply 1

hslai
Cisco Employee
Cisco Employee

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.