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?