Account Lockout Problems with 1.9.1

[Tom Parker]

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 <ghudson at MIT.EDU> 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.