Passowrd policy patch on Samba-3.0.2 for LDAP backend

[Jianliang Lu]

> The issue isn't the set of the bad password count, the issue is the read.
> If we're the only one updating it, ok, it's fine we can keep a count
> internally, I suppose, but we can't just read the directory, because we'd
> be reading the slave's count.  So we'd read a 0, write (through referrals)
> to the master a 1, and then another BDC has the same occur.  He reads 0
> from his slave, and writes a 1.  Ok, not so bad you say?  But now go back
> to the first BDC, do another one (replication has not yet occurred), we
> read a 0 from the slave, write a 1 to the master.
> 
> Or let's say on the PDC, you enter in 4 bad passwords (with lockout at 5).
> Then go to a BDC, enter a bad password, and it will reset the PDC to 1.
> Basically, you've got the window of replication delay to reset the count
> back down to 1, and then 2...etc.  At least with local caching of it, no DC
> can get more than the lockout number of attempts before it locks itself
> out.

I don't think that the window of replication delay is so large to allow such 
operation. In Openldap2.x, for ex. the slurp will check and replicate every 3 
seconds ( G.Carter "LDAP system administration", p.87). So the delay will be 
(3 + network delay) seconds, that would be almost "immediately".

I agree with you that the "consistent" SAM is impossible with replication, 
like the logon time and bad password count, it's also the case of change 
password, that may be done only on PDC (master). After the user has changed 
his password, during the replication delay window (if is so large), he would 
get a logon failure (wrong password) using the newer password on BDC.

Jianliang Lu
TieSse s.p.a.     Ivrea (To) - Italy
j.lu at tiesse.com   luj at libero.it
http://www.tiesse.com