[Freeipa-users] kinit admin not working anymore (LOCKED_OUT: Clients credentials have been revoked)

[Janelle]

Sorry Rob - I beg to differ here. I can replicate this with my replica 
failures.  It happens that a replica simply loses it's mind. Somehow the 
keytab gets mucked up and further connections for replication fail -- it 
shows a failed "admin" login and they add up because the other servers 
continue. It only happens on the failed replica -- AND I am the only one 
with the admin PW and there are ZERO failed attempts over SSH.

As soon as I get another failed replica in this state (about once every 
2-3 weeks) I will post the logs and open a ticket. On one server, I 
simply did a reboot, and when it came back, the keytab was wrong and the 
replica now claimed that it was no longer a member of the replica list.  
Let me get more information and logs to open a ticket.

~J

On 9/3/15 11:11 AM, Rob Crittenden wrote:
> Janelle wrote:
>> You will find, if you check in the ns-slapd "errors" log that this
>> server may no longer be handling replication correctly.
>>
>> Look in /var/log/dirsrv/slapd-INSTANCE..../errors
>
> This probably doesn't have anything to do with replication. Lockout is 
> per-master because failed (and successful) logins are not replicated 
> due to the performance issues that would bring. Image 500 people all 
> logging in at the same time in the morning how busy all the masters 
> would be replicating the successes and failures.
>
> So this is a perfectly reasonable scenario where on one master the 
> admin has violated the password lockout policy and is locked out but 
> can still log in to other masters.
>
> ipa user-status <user> will show the lockout attributes by master. And 
> ipa user-unlock <user> will unlock them.
>
> rob
>
>>
>> Look for errors where replication is not starting correctly because of
>> credential problems.  You may have to re-init this replica.
>> The reason "admin" is locked out is that something gets screwed up with
>> the keytab file that was originally installed (I have not found the
>> cause yet, only experienced the exact same thing)
>>
>> Once the keytab file is messed up, others servers can't authenticate and
>> therefore the ADMIN account gets locked out. If you restart the server,
>> it will clear for a little while, but go rgiht back to being locked out.
>>
>> Solution - delete the replica and recreate.
>>
>> ~J
>>
>> On 9/3/15 2:08 AM, Torsten Harenberg wrote:
>>> Dear all,
>>>
>>> I cannot get an "admin" kerberos token anymore on our main IPA server:
>>>
>>> [root at ipa log]# kinit admin
>>> kinit: Clients credentials have been revoked while getting initial
>>> credentials
>>>
>>> Sep 03 11:02:30 ipa.pleiades.uni-wuppertal.de krb5kdc[1351](info):
>>> AS_REQ (6 etypes {18 17 16 23 25 26}) 132.195.124.12: LOCKED_OUT:
>>> admin at PLEIADES.UNI-WUPPERTAL.DE for
>>> krbtgt/PLEIADES.UNI-WUPPERTAL.DE at PLEIADES.UNI-WUPPERTAL.DE, Clients
>>> credentials have been revoked
>>>
>>> also login via HTTP is not possible anymore:
>>>
>>> Sep 03 11:04:52 ipa.pleiades.uni-wuppertal.de krb5kdc[1351](info):
>>> AS_REQ (6 etypes {18 17 16 23 25 26}) 132.195.124.12: NEEDED_PREAUTH:
>>> HTTP/ipa.pleiades.uni-wuppertal.de at PLEIADES.UNI-WUPPERTAL.DE for
>>> krbtgt/PLEIADES.UNI-WUPPERTAL.DE at PLEIADES.UNI-WUPPERTAL.DE, Additional
>>> pre-authentication required
>>> Sep 03 11:04:52 ipa.pleiades.uni-wuppertal.de krb5kdc[1351](info):
>>> closing down fd 11
>>> Sep 03 11:04:52 ipa.pleiades.uni-wuppertal.de krb5kdc[1351](info):
>>> AS_REQ (6 etypes {18 17 16 23 25 26}) 132.195.124.12: ISSUE: authtime
>>> 1441271092, etypes {rep=18 tkt=18 ses=18},
>>> HTTP/ipa.pleiades.uni-wuppertal.de at PLEIADES.UNI-WUPPERTAL.DE for
>>> krbtgt/PLEIADES.UNI-WUPPERTAL.DE at PLEIADES.UNI-WUPPERTAL.DE
>>> Sep 03 11:04:52 ipa.pleiades.uni-wuppertal.de krb5kdc[1351](info):
>>> closing down fd 11
>>> Sep 03 11:04:52 ipa.pleiades.uni-wuppertal.de krb5kdc[1351](info):
>>> AS_REQ (6 etypes {18 17 16 23 25 26}) 132.195.124.12: LOCKED_OUT:
>>> admin at PLEIADES.UNI-WUPPERTAL.DE for
>>> krbtgt/PLEIADES.UNI-WUPPERTAL.DE at PLEIADES.UNI-WUPPERTAL.DE, Clients
>>> credentials have been revoked
>>>
>>> while the same works on the secondary server.
>>>
>>> I read
>>>
>>> http://web.mit.edu/kerberos/krb5-devel/doc/admin/lockout.html
>>>
>>> but this did not give me a clue how to get out of this.
>>>
>>> I am pretty sure that I never entered a wrong password, but of course
>>> someone could have tried to log in on the Web interface.
>>>
>>> Any idea how this can be resolved?
>>>
>>> Kind regards
>>>
>>>    Torsten
>>>
>>
>