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.