Passowrd policy patch on Samba-3.0.2 for LDAP backend

Jim McDonough jmcd at us.ibm.com
Fri Feb 20 13:15:38 GMT 2004






>The LDAP Master-Slave replication could work as well, the BDC will update
the
>bad password count always on PDC ( referrals on master) if we set the
chasing
>REFERRALS on Samba BDC using ldap_set_option(). In this way the BDC using
the
>ldap client api to update the data referraled to ldap master.
Actually, no, the problem is that there is no operation that says
"increment atomically".  We have constructed such by having conditional
modifies with retry, i.e. "if attr==3, attr=4" which errors out if attr
isn't 3.

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.

This just is more evidence that the holy grail of a "consistent" SAM is
impossible if yo'ure going to have replication.  It can't happen...period.
If you want a consistent SAM across DC's, you can't use replication, or you
have to prevent anyone from doing operations until you can guarantee that
replication has occurred.  As long as there is replication (and there needs
to be in many cases) there is going to be the situation where different
replicas have different data.  The issue is minimizing security risks and
other problems caused by the inconsistencies.

Andrew, in fact the setup you mentioned last night, a PDC using an LDAP
slave, which you claim is common (I have no reason to doubt that), you
could make the claim that the PDC inconsistent with itself.  :-)

----------------------------
Jim McDonough
IBM Linux Technology Center
Samba Team
6 Minuteman Drive
Scarborough, ME 04074
USA

jmcd at us.ibm.com
jmcd at samba.org

Phone: (207) 885-5565
IBM tie-line: 776-9984


More information about the samba-technical mailing list