[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kerberos
Subject:    Re: Managing account lockout
From:       Greg Hudson <ghudson () mit ! edu>
Date:       2015-06-21 1:31:21
Message-ID: 558613E9.8070706 () mit ! edu
[Download RAW message or body]

On 06/20/2015 11:15 AM, John Devitofranceschi wrote:

> echo “” | kinit princ 2>&1 | grep revoke => account is locked
> 
> (this is done in a loop and each invocation uses a different krb5.conf with a \
> different kdc) 
> Is this too brittle? is the error message likely to change? Is there a better way \
> to do this?

It's conceivable, but unlikely, that the error message might change in
the future.  I can't think of any current plans which would change it.

The only other approaches I can think of involve using kadmin, which
would require privileged access, or writing a C program, which would
yield minimal gain for the work.

On 06/20/2015 06:43 PM, John Devitofranceschi wrote:
> The test I have (above) cannot tell if a principal is locked or if it has *just* \
> been unlocked, since a null password is not considered a failed attempt and the \
> count is not reset when that is tried.

That doesn't track.  An empty password should behave just like any other
password (modulo issue #7642, which only applies when the password is
supplied via the API and was fixed in 1.12).  So it should count as a
strike if the account wasn't already locked.

"kinit princ </dev/null" would test the lockout status without adding a
strike, since it will cause kinit to give up when it tries to read the
password, before sending a preauthenticated request to the KDC.
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


[prev in list] [next in list] [prev in thread] [next in thread]