Re: smbk5pwd and ppolicy working together

[Ryan Steele <rsteele@archer-group.com>]

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.
>