Pat Riehecky wrote:
Here is what I know on this, wiser minds may feel free to correct
everything I have to say.....
replies are inline.
On Tue, 2008-04-01 at 15:46 -0400, Ryan Steele wrote:
Hello,
I've got the smbk5pwd and ppolicy modules working, but I'm not entirely
sure I've got them working together.
I say this because clients joined to the domain (run by a Samba PDC with
an OpenLDAP backend) can change their passwords and it updates the NT/LM
passwords in LDAP, thus verifying the functionality of smk5pwd, but it
does not appear to enforce ppolicy restrictions. On the flip side of
the coin, the user can change their LDAP password by invoking ldappasswd
from a shell on the server, and are bound by the restrictions set forth
by ppolicy (password length, strength, historical passwords, etc.).
The ppolicy overlay is adding extra functionality to the password
extended operation. ldappasswd uses this. The restriction is not
present if you update the password hash via the ldapmodify command. The
key is in the extended operation. As an added tidbit only userPassword
is monitored not any other attribute.
That's not entirely true. The ppolicy overlay also intercepts regular Modify
requests. But the sticking point is that if the incoming password is already
hashed, then most of the policy checks cannot be performed. Typically, clients
that use ldapmodify on the userPassword hash the value before sending it to
the server, and so the overlay can't do anything.
Samba does password changes via an ldapmodify rather than an ldappasswd
(unless you have ldap passwd sync = Only which I have never personally
used so I have no tests to back this up). This would explain why LDAP
has the policy enforcing and Samba does not.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
