Managing account lockout

Greg Hudson ghudson at mit.edu
Sat Jun 20 21:31:21 EDT 2015


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.


More information about the Kerberos mailing list