[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
smbk5pwd and ppolicy working together
- To: openldap-software@openldap.org
- Subject: smbk5pwd and ppolicy working together
- From: Ryan Steele <rsteele@archer-group.com>
- Date: Tue, 01 Apr 2008 15:46:26 -0400
- In-reply-to: <47F28816.3010504@archer-group.com>
- References: <47F27B2A.5060607@archer-group.com> <47F28040.90304@tranquil-it-systems.fr> <47F28816.3010504@archer-group.com>
- User-agent: Thunderbird 2.0.0.12 (Windows/20080213)
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.).
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."
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:
sambaPasswordHistory:
0000000000000000000000000000000000000000000000000000000000000000
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.
Thanks,
Ryan