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
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.
> On Mon, Oct 5, 2015 at 8:19 AM, Rob Crittenden <rcrit...@redhat.com
> <mailto:rcrit...@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
> >>>> 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
> >> 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
> Manage your subscription for the Freeipa-users mailing list:
> Go to http://freeipa.org for more info on the project
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project