My lockout duration is 0 which should be forever. Like I said in my first post the fail counter stops and successful logins don't result in a reset (they are not logged either. The last login date doesn't change). If I 'unlock' the user then the counters get reset and the dates get updated.
I will try to get you more logs and traces. Tom On 2011-11-19, at 13:04, Greg Hudson <[email protected]> wrote: > On 11/18/2011 04:48 PM, Tom Parker wrote: >> I have my default policy set to 10 password attempts before a lockout. >> When a user hits the 10 attempts, the failed attempt counter stops >> incrementing, the last failed count stops changing however they are >> still able to get a TGT and TGS and log in. > > That's certainly not the expected behavior or the behavior in tests > here. Two guesses: > > 1. The client code has fallback to try the master KDC if it gets a > failure response from the KDC it tries first. Lockout failure counters > are per-KDC. Perhaps the client still had some attempts on one KDC when > it hit the lockout count on the other? > > For various reasons I'm not sure if this explanation is really very > likely, but make sure to check the logs and counters on both KDCs. > > 2. If you have a lockout duration in the policy and the duration has > expired (it's in seconds), the client would be allowed to make more > attempts. A successful attempt should reset the counter to 0. > > If a particular KDC really is issuing tickets in a situation where the > principal should be locked out, I don't really have a clue why; the next > step for me if I could reproduce it here would be stepping through the > KDC code in a debugger, or failing that, adding a lot of temporary > logging code to the KDC. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
