ISE Admin User Shadow AD Account Issue

[paul]

Normally on my ISE setups I tie in Admin Access to AD and map Admin groups to AD groups which works perfectly.   The customer I am at now wants to use shadow accounts in ISE (i.e. password set to external) to assign roles.  I have ISE set to authenticate to AD and I setup an account in ISE that matches my AD account.  When I try to log into ISE it fails and the log says:

"Authentication failed due to zero RBAC Groups"

I know that means it can't map my ID to an group in ISE.  I have my ID assigned to SuperAdmin so it should get that RBAC.

Does this feature work?

Thanks.

[Craig Hyps]

Try mapping an AD group you belong to a ISE admin group.

[paul]

I know that works, but that defeats the purpose of the shadow user. They don’t want anyone in the AD group to get that level they want only specific accounts.

[hslai · Accepted solution]

This appears a current limitation that using AD for ISE web UI admin is external authentication and external authorization. If the customer has a case open with Cisco TAC, please ask TAC to file an enhancement request.

Existing bugs are: CSCve99708 and CSCvb64350 (documentation).

[mumustha]

The request corresponds to CSCve99708.

This is working as per design to avoid vulnerabilities defined in https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb10995 and cannot be taken as an Enhancement Request

[Photobox]

With all due respect this needs fixing.  The ISE is less secure now if you have to use an external password store (for reporting and compliance issues).  Any AD users with group access control within AD ( quite often help-desk) can add themselves to the AD group used to control ISE admin access.  This is is in my view just as big a security hole.  

If an external (AD) user account (i.e. a shadow account) is explicitly added as an admin then it is not insecure for a user with that account name and password to get admin access.  It's been explicitly added....

This is not the same as the security issue, authenticating an account that is internally defined against an external AD account with the same name and giving the external account the same access as the internal account is a dumb error to have made...

The fix should be that the external AD group object should only allow access if the user's shadow account is also a member of the ISE external group.  The code is obviously half there as you can add ISE internal accounts to external groups.  Just add an option to allow access only to when the user name also matches the shadow account defined in the membership list.

[KelvinT]

Hello,

Is there a plan to remove the vulnerability and enable this feature?

This feature is important for clients that have a different team who manages the AD account from the team that manages ISE.  This feature give control of creating/deleting admin user account while allowing the admin user to use the same username/password as their AD account. 

It doesn't make sense to allow configuration of this feature that doesn't work.....

Let me know.  Thanks

[sroberts@appriver.com]

Did you find out the best practice, or just any practice that does this?  Some manufactures let us create the list of users, then point that use to local, ldap, tacacs+, radius, etc... for auth. But for the manufactures that don't (like Cisco hardware), we need ISE to check what the network team allows, then check AD.