0

I have a FreeIPA server set up with a single replica. The admin account has been locked. Here's the log from a kinit admin:

[root@idm-00 ~]# kinit admin kinit: Client's credentials have been revoked while getting initial credentials Jun 26 13:04:08 idm-00.<REDACTED> krb5kdc[288805](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) <REDACTED>: LOCKED_OUT: admin@<REDACTED> for krbtgt/<REDACTED>@<REDACTED>, Client's credentials have been revoked 

I don't have another admin user on the system, but I do have root access to the server itself.

Is it possible to recover from this?

1 Answer 1

3
+50

If you are completely locked out of all administrator accounts, your next best bet is to use the LDAP directory manager password to unlock the admin account.

If you do not have the directory manager password, but you do have root access to the FreeIPA server, there is a non-trivial process to reset the LDAP directory manager password and then update FreeIPA to utilize the new directory manager password. Once you have the directory manager password, you should be able to unlock the admin account.

Some notes to alleviate this problem in the future:

If you have any FreeIPA bits (UI, LDAP, SSH) publicly accessible for any enrolled server, they are very likely to be probed. Since the admin user is enabled by default, there are usually many brute force attempts to gain access which will lock the account. To avoid fighting to constantly unlock the admin account, it is usually good practice to disable or remove the default admin account and assign non-default users as admins.

You may also want more than one administrator user, or another user that has permissions to modify lockout state. This makes it easier to unlock accounts as long as at least one of the capable users is available.

1
  • 1
    Along with granting admin rights to additional accounts, I took steps to ensure the admin user's password would not expire unexpectedly. In essence, I created a group for the admin user, created a custom password expiration policy and associated it with that group, made the admin user a member of the group, and changed the admin user's password. The sequence of the last two steps made sure the group's policy was applied to the new password, so it wouldn't expire at another, unexpected time. Commented Jul 5, 2023 at 2:33

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.