On 12/04/2013 12:43 PM, Исаев Виталий Анатольевич wrote:
> Thank you for your responses!
> In terms of IdM "lock" state and "disable" state are different: when user
> becomes locked after several failed login attempts, he is still enabled. The
> locked state is not shown neither in "ipa user-show" or "ipa user-find --all"
> commands output, nor in Web GUI...
> Locked user is brought up to life with "ipa user-unlock" command, but not
> with "ipa user-enable" command.
This is correct.
> So the lockout duration set to 0 could be a deal for us (we are using v.
> 3.0.0). But can we receive a notification in the case of lockout event? How
> can we check if the user is locked? Can we see this event in any IdM log?
"Lockout status" is not an attribute on it's own (as compared to
user-lock/user-unlock locking). It is rather a state of a KDC which based on
the password policy (ipa pwpolicy-show) and user attributes krbloginfailedcount
and krblastpwdchange can decide if the user is locked out or not.
We have prepared a "user-status" command to at least help gathering this all
this information from all KDCs. See help in "ipa help user-status".
If you want to search for all disabled users, could you base it on an
ldapsearch like the following one?
ldapsearch -h $IPA_SERVER -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com'
It could give you the list of users who already hit the lockout count leading
to the permanent lockout.
Note that there are RFEs already filed that improve the situation in this area:
https://fedorahosted.org/freeipa/ticket/3700 : [RFE] Failed login replication
https://fedorahosted.org/freeipa/ticket/2792 : [RFE] Allow quering user lock
status and unlocking user in UI
> Thanks a lot,
> Виталий Исаев
> Группа разработки и внедрения ПСЗИ
> Департамент информационной безопасности
> ОАО «Финтех»
> -----Original Message-----
> From: freeipa-users-boun...@redhat.com
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Martin Kosek
> Sent: Wednesday, December 04, 2013 3:07 PM
> To: Natxo Asenjo; firstname.lastname@example.org
> Subject: Re: [Freeipa-users] How to disable user automatically when he
> becomes locked
> On 12/04/2013 11:53 AM, Natxo Asenjo wrote:
>> On Wed, Dec 4, 2013 at 11:44 AM, Natxo Asenjo <natxo.ase...@gmail.com> wrote:
>>> On Wed, Dec 4, 2013 at 10:59 AM, Исаев Виталий Анатольевич
>>> <is...@fintech.ru> wrote:
>>>> Dear Freeipa users and developers,
>>>> We need to alter the default behavior of the IdM server in the
>>>> situation when user exceeds the limit of incorrect password login attempts.
>>>> By default the user is getting locked in this case, but we need to
>>>> disable him fully.
>>> As in, delete the user? Because locking the account is disabling it
>>> unless I misunderstand it. I cannot log in, my cron jobs will fail, I
>>> cannot use any ldap/kerberos service because my account is disabled.
>>> What do you need exactly? Or maybe you refer to the fact that the
>>> lock is temporary (standard 600 seconds, after which you may try
>>> logging in again? In that case, change that in the password policies
>>> (in the web interface, policy tab, then password policy, then open
>>> the global_policy, then edit the lockout duration field and update it.
>> for completeness, the same in the cli as an admin user:
>> To get the values:
>> $ ipa pwpolicy-show
>> Group: global_policy
>> Max lifetime (days): 90
>> Min lifetime (hours): 1
>> History size: 0
>> Character classes: 0
>> Min length: 8
>> Max failures: 6
>> Failure reset interval: 60
>> Lockout duration: 600
>> To change a value:
>> $ ipa pwpolicy-mod global_policy --lockouttime=INT
>> (where INT is the number of seconds you want the lock to be
>> implemented, set it to a huge number, like 946080000 in practice 30 (
>> 3600 secs * 24 hours * 365 days * 30 years ) years is like a life
>> sentence ;-) - the accounts).
> Right, though I am not sure if it would not hit Kerberos limitation for too
> large timestamps.
> Alternatively, you can set the Lockout Duration to 0, this should lock out
> the account permanently after the number of tries was breached. Note that
> there is a related bug fix in FreeIPA 3.2.0:
> Freeipa-users mailing list
Freeipa-users mailing list