Account Lockout Problems with 1.9.1

[Tom Parker]

Hi

Again thanks for looking at this so quickly. 

My two KDCs are using the LDAP db and syncrepl to keep in sync so the fail count on one is automatically replicated on the other. 

I will see If I can get better logs to you as well as some client side 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.