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
