implementing password lockout

Andrew Bartlett abartlet at
Mon Jan 26 00:41:30 GMT 2004

On Mon, 2004-01-26 at 08:24, Jim McDonough wrote:
> As I've been looking into merging the password lockout patch (or rather,
> one of the several) and doing some testing, I've noticed this: the bad
> password count is _not_ replicated as part of sam updates, presumably to
> reduce reaons for replications.  So it seems to me we don't actually want
> to store this in the passdb.  I've verified that other attributes get
> updated from PDC to BDC, such as comments, acct flags (including lockout)
> are replicated.
> Do the IDEALX guys agree with this?  Have you seen the bad passwd count get
> updated?
> If the count is maintained locally only on each DC, it seems we would need
> to store in locally in a tdb, which would create two lookups for each user,
> though this tdb should only contain entries for users who entered wrong
> passwords and did not subsequently enter a correct password.

tdb lookups are cheap.  However, I think we should have the *option* to
create a consistent sam.  That is, we should allow these things (last
login, last bad login, bad password count) to be stored as part of an
extended passdb, but allow the admin to store them elsewhere if they

> Don't get me wrong, if you do a samrqueryuserinfo level 23, the bad
> password count is returned, but I just don't see it getting updated in an
> NT BDC.  Also, there is no field in the SAM for the time that the last bad
> attempt was...
> There is also a knowledgebase article about this:
> So my current thought is to create a new tdb to store the password count
> and a timestamp for each user, as they encounter bad passwords.  This would
> be used for all password backends.  At a successful logon attempt, any
> record for a user is deleted.  I think this will get us closest to what NT
> is doing.  My biggest concern is that it would mean a second lookup for any
> user when the badpasswordcount field is involved.

This sounds reasonable, but I like the idea that we *can* store it in
LDAP, if the admin so desires.

Andrew Bartlett

Andrew Bartlett                                 abartlet at
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the samba-technical mailing list