Bad Password Lockout Problems

[John H Terpstra]

On Thursday 23 June 2005 01:40, Simo Sorce wrote:
> On Wed, 2005-06-22 at 21:26 -0600, John H Terpstra wrote:
> > Observations:
> > ----------------
> > 1. We may have a bug (not proven) in the bad password handling code.
>
> what kind of bug?
> do you mean that the password history was indeed present ?

The password history was not being updated in the LDAP user account record 
(the user had entered the correct password) but the bad password count was 
being incremented. Even if set to a higher number the bad count threshold 
would trigger account locking.

The problem appears to be (I could not prove it yet) an LDAP timing issue, 
because if the BDCs were shutdown (forcing the PDC to do all auth) the user 
would get a successful login once in every 4 or 5 attempts. Every failed 
attempt would report in the logs the error message:

	init_sam_ldap: Blah blah blah

At the bad password threshold the user account is locked. So setting this to a 
higher number only defers the lockout problem.

I did check what happens when the user enters a bad password - in that case 
the bad password history is updated.

Right now, the site has disabled all account ageing and bad password lockout, 
but will need to reactivate it to meet Sarbanes-Oxley laws.

> > 2. Use of the NT4 Domain User Manager does NOT allow selection of a BDC -
> > all operations and rights settings are affected only on the PDC. The only
> > entity that can be selected in the domain selection panel is the domain
> > name. All attempts to enter the name of the PDC or the DBC fails with a
> > message that the domain controller could not be found.
>
> Yes no way to address a specific DC, usrmgr.exe will always try to
> contact the PDC and attach to a BDC only in case the PDC is unavailable.
>
> > The fact that we store NT4 Global policy settings in the
> > account_policy.tdb only on the PDC leads to inconsistencies in domain
> > operation since we appear to not replicate this information to BDCs. This
> > is possibly a bad thing.
>
> It is a bad thing, but a known bad thing, we should document that.

That is a significant issue. I will document that the NT4 Domain User Manager 
must not be used for security policy management.

> > 3. The pdbedit command can be used to set password aging settings and the
> > bad password lockout settings - I will document the pdbedit tool before
> > the book goes to print.
>
> Thanks.
>
> > 4. Turning off all bad password lock-out settings, and reverting to no
> > password time limits, settled the site down completely.
> >
> >
> > Please can someone recommend HOW we can maintain consistent domain-wide
> > security policies where the NT4 Domain User Manager is used?
>
> The only way is to move policies into ldap (for ldap setups), I think I
> already talk with Jerry about that, but I can't remember the outcome.
>
> Jerry, is that ok with you?
> I'm available to write a patch to address this problem if you're ok with
> it.

I believe that this should have been in LDAP from the outset, although I am 
sure this was discussed and that there were good reasons for the choice to 
put this info into the account_policy.tdb file instead.

> >  I'd like to
> > document that before the HOWTO gets locked off for printing. I may help
> > someone to avoid significant lost productivity. If necessary, I will put
> > a warning in the documentation regarding the consequences of using the
> > NT4 Domain User Manager.
>
> You should warn that account policies currently are NOT replicated, and
> so must be kept synchronized by pdbedit.

He? How does pdbedit synchronize account policies? I think you mean that every 
machine must be individually managed.

- John T.