How unlock CLI users on ISE (SNS-3695-K9) v.2.6

[Daniel RLL]

I have a few CLI locked users, on the GUI they are ok but on the CLI I get this:

# show users status

USERNAME ROLE DISABLED LOCKED
t1xxxxx Admin *
tyyyyyy Admin *
tzzzzzz Admin *

I have read in other feeds to use the "recovery password" proccedure but I don't see this procedure as a practical way to manage users... because with this method it has an impact on the service.

It would be logical if you try to unlock a user with the "admin" role, without being so, but I understand that there should be some more "administrative" command, from the point that there are more Administrator users.

Thanks

[Marcelo Morais · Accepted solution]

Hi @Daniel RLL ,

 only the 1st CLI-Admin User is copied as the Web-based Admin User, these two accounts are not the same account, the CLI account is specific to each Node, whereas the GUI Admin account is replicated to the other Nodes.

 ISE 2.6+ supports Authentication of CLI Administrators by External Identity Sources, such as AD. (take a look at AD Integration for Cisco ISE GUI and CLI Login).

Hope this helps !!!

[Arne Bier · Accepted solution]

Hi @Daniel RLL 

Are you talking about the Lock/Suspend Settings under the Admin Access menu?

The first thing I do after installing ISE is to ensure that I never lock myself out of a CLI account. There is a feature in ISE that will lock out the CLI such that the only way to unlock the account is to reboot the node. I had this debate with someone once who said that the account lockout was there for ISE's protection against hackers. Which to me makes no sense, since if I knew that, I would deliberately lock every one of your ISE nodes out just to teach you a lesson. A better approach would be to make the CLI admin password very hard to guess and to keep it to locked away for only a small set of admins to access.

You can rather choose the "Suspend" action which will prevent another login attempt for a few minutes.

Password recovery method is only required if you cannot login with ANY of the CLI admin accounts. I have never tried this, but I suspect that even if you had 5 CLI admin accounts, and you locked one of them, that the entire CLI is locked out - thus forcing you to reboot the node to restore access to the CLI login.

Just keep it simple and have one admin user account per CLI. You hardly ever need the CLI anyway. And if you must use AD, then try this in the lab first - there are some caveats with the AD on the CLI.

[Daniel RLL]

Thank you @Marcelo Morais and @Arne Bier for your answers...

In the GUI we have administrator users that are validated by External Identity Sources (LDAP), but the CLI users are local, even though they have the same ID.

Although as you told me, CLI users can be validated in External Identity Sources (DA), in our installation CLI users are local.

That is, the user U12345 in the GUI is not the same as U12345 in the CLI, and this is enough for us at the moment. The problem is that we have users in the CLI, who are locked and cannot access the CLI because they appear as "locked"... and we don't find in the documentation how to unlock them.

We have found a method that is to delete the lock policies, delete the user, add the user again and then apply the policies again.

At the CLI we have this policies:

Based on your comments, what I think I'll do is get rid of the "password-lock-enabled" command...so this way there will be a cooldown and number of retries before disconnecting...but it will never "lock" the user... right?

[Arne Bier]

That’s correct. Some folks might like to have accounts lock out for security. But generally that approach causes more issues in my experience.