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