Account Lockout Problems with 1.9.1
Tom Parker
tparker at cbnco.com
Sat Nov 19 14:55:45 EST 2011
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.
More information about the Kerberos
mailing list