[Freeipa-users] admin loses access?

[Rob Crittenden]

Prasun Gera wrote:
> I was facing similar issues, and ended up changing the username from
> admin to something else since admin is a common name in brute force ssh
> attacks. It was getting locked out in spite of using fail2ban. I guess
> fail2ban can be tweaked to block the host before ipa blocks the admin
> account, but I didn't bother doing that. Changing the username seemed
> easier. 

Right, the power lies in the admins group. The only exception is in the
replica connection checker where the name 'admin' is hardcoded. There is
a ticket open to fix this. Otherwise AFAIK the name shouldn't matter.

rob

> 
> On Mon, Oct 5, 2015 at 8:19 AM, Rob Crittenden <rcritten at redhat.com
> <mailto:rcritten at redhat.com>> wrote:
> 
>     Janelle wrote:
>     > On 10/5/15 7:39 AM, Rob Crittenden wrote:
>     >> Torsten Harenberg wrote:
>     >>> Hi Janelle,
>     >>>
>     >>> Am 04.10.2015 um 19:25 schrieb Janelle:
>     >>>> Just wondering if anyone knows why this happens from time to
>     time on
>     >>>> servers:
>     >>>>
>     >>>> $ kinit admin
>     >>>> kinit: Clients credentials have been revoked while getting initial
>     >>>> credentials
>     >>>>
>     >>>> there are no failed logins to the admin account - not even any
>     login
>     >>>> attempts, so it is not like someone is getting the account
>     locked out.
>     >>>> Just curious if anyone else has seen in. With 16 masters, it occurs
>     >>>> randomly on some hosts, but eventually clears either on its own
>     or with
>     >>>> a restart of IPA. However, I just restarted IPA on this server and
>     >>>> after
>     >>>> about 2-3 minutes it works again.
>     >>>>
>     >>> I am seeing the same, see my mail "kinit admin not working anymore
>     >>> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT.
>     >>> Actually, wasn't it you who wanted to open a ticket?
>     >>>
>     >>> Have a nice evening,
>     >>>
>     >>>    Torsten
>     >>>
>     >> When you see this run `ipa user-status admin` and `ipa pwpolicy-show
>     >> --user=admin` and provide that so we can potentially see what is
>     going
>     >> on.
>     >>
>     >> rob
>     >>
>     > I am curious -- if you have 16 masters, but this only happens once in
>     > awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to
>     > understand the thinking of where you are going?? I will for sure
>     do this
>     > the next time it happens, but I want to understand logic?
> 
>     Lockout is per-master because the failed auth count and successful login
>     date is not replicated due to performance issues.
> 
>     The user-status command will collect the lockout attributes from each
>     server, but it doesn't do the calculations, so the pwpolicy is needed as
>     well in order to figure out whether on a given master the user is locked
>     out.
> 
>     rob
> 
>     --
>     Manage your subscription for the Freeipa-users mailing list:
>     https://www.redhat.com/mailman/listinfo/freeipa-users
>     Go to http://freeipa.org for more info on the project
> 
>