[Date Prev][Date Next]
Re: smbk5pwd and ppolicy working together
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:
> 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.
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.
> But, I cannot seem to get ppolicy and smbk5pwd to operate in conjunction
> with one another - when changed from a Windows client, only smbk5pwd
> seems to work. I was initially thinking this was maybe because Windows
> was sending the passwords already hashed to OpenLDAP, but if I send a
> password such as 'a', I get this message:
> "Your password must be at least 5 characters, cannot
> repeat any of your previous 0 passwords and must be at least 0 days
> old. Please type a different password. Type a password that meets
> these requirements in both text boxes."
I would recommend reading the information at
for an answer to this. It should, by inference explain the questions
you have below as well. Questions on this should be aimed at the samba
> However, I have no idea where it's getting those requirements or that
> text from, though I'm wondering it's a Windows policy. In any case,
> it's certainly not what ppolicy requires, as is the case from a shell on
> the server.
> I also see this in the sambaPasswordHistory attribute, which (possibly?)
> indicates that ppolicy isn't working properly in conjunction with
> smbk5pwd, and possibly explains why isn't not triggering on the
> historical passwords:
> That doesn't explain, though, why the strength and length checks aren't
> working. I've ramped up the debugging on the back end, but all I see is
> Samba happily updating with weak passwords and no mention of password
> lengths (even when that dialog pops up on the Windows client side). I'd
> appreciate any insight anybody might have.