I find myself needing to implement principal password lockout (standard setup with 1.13.2 w/8 KDCs)
The powers that be want us to implement self-service account unlocking (w/out password changing) We have a password self-service portal and we would like for it to be able to detect if accounts are locked or not. It seems that this can be done by kinit’ing against all the KDCs as the target principal like this and checking the error message: 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? Once I find a (non-kadmind) kdc where the account is locked, I cannot unlock it using a standard kadmin -q “modprinc -unlock princ” The principal state is not propagated via iprop. The documentation says: "An administrative unlock is propagated from the master to the slave KDCs during the next propagation.” But I am not seeing the principal getting unlocked on the slave, so I am not sure what to think here. I’m not even seeing the account getting unlocked when the password is changed, which used to be the case in 1.11.3, according to my testing. jd
smime.p7s
Description: S/MIME cryptographic signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
