Howard Chu wrote:
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.
Well, if the 'passwd program' defined in the smb.conf is ldappasswd, then the ldapmodify doesn't come in to play, correct? The two things I'm confused about is
1. why there is a sambaPasswordHistory attribute if it's using ldappasswd (ldappasswd should modify the pwdHistory attribute, no?), and
2. why ppolicy wouldn't come in to play in my situation. I have 'ldap passwd sync = only' set, so smbk5pwd should just set the NT/LM passwords based on what userPassword is, which is set by ldappasswd (the 'passwd program'), which in turn is supposed to be regulated by ppolicy.
The only explanation I can see here is that Windows is sending the passwords already hashed to ldappasswd. However, the Windows clients can change their password from 'foobar' to 'foobar', so the hash shouldn't change and thus ppolicy should complain - but it doesn't.
If Windows encrypting the passwords is the problem, then is my only recourse to edit the Windows registry settings on the intranet machines to send SMB passwords across in plaintext to the domain controller, and edit the Samba configs such that 'encrypt passwords = no' is set, so that ppolicy can act on the plaintext password? I'm open to whatever suggestions make sense.
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.