Re: smbk5pwd and ppolicy working together

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

Howard and others,

Let me ask two theoretical questions, before I submit my comments
below.  Windows XP/2000/et. al. send their passwords via SMB hashed. 
So, without configuring those workstations to send the passwords
plaintext over the wire, is there any way for ppolicy to act on the
ldapmodify initiated by Samba from Windows clients attempting to change
their passwords? 

Furthermore, if the above change is made so that ppolicy can evaluate
the plaintext password, what exactly will the interaction between LDAP
and the clients be if it fails to clear ppolicy constraints?

Additional comments below....

Howard Chu wrote:
> Ryan Steele wrote:
>> Hey Howard, Adam, and List:
>>
>> I'm not even sure this is the path I ought to be going down.  If
>> smbk5pwd has no knowledge of ppolicy, and password changes from Windows
>> clients won't adhere to those restrictions with any combination of
>> configuration options in any currently known universe, perhaps what I
>> really need is an alternate strategy.  I'm open to suggestion; my only
>> requirements are that password changes from a Windows workstation be
>> subjected to the ppolicy constraints, and that the LDAP and Samba
>> passwords all be in sync.
>>
>> However, here are the logs entries and relevant slapd configuration
>> options - pastings inline below:
>>
>> <snip>
>
> This is syslog output, not debug output. I said to bump up the debug
> level.
>

Maybe I'm misunderstanding.  From the slapd.conf manpage:

loglevel <integer> [...]
              Specify the level at which debugging statements and
operation statistics should be syslogged (currently logged to  the 
syslogd(8)  LOG_LOCAL4  facility).

I thought "debugging statements" is what you wanted?  When I start slapd
with the -d option, I seem to get the same output as when I specify
'loglevel N' in the slapd.conf.

>> <snip>
> As already mentioned, ppolicy doesn't restrict the rootDN. If you want
> your policy constraints to work, you have to bind with some other DN
> to make the changes. That will of course mean that you have to give
> that DN write access to the selected attributes in your ACL.

Ok - I'll create an LDAP user specifically for changing passwords, and
set that as my "ldap admin dn" in the smb.conf, so the change won't be
done by the rootdn, as recommended by Adam and yourself.  I'll then
create an entry in the slapd.conf like the one below and give that a shot.

>>
>> # ACL's
>> access to
>> attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange
>>
>>     by   self    write
>>     by   *       auth
    access to
attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange,pwdChangedTime,pwdHistory
          by dn="cn=pwchanger,dc=example,dc=com" write

>>
>> access to *
>>     by   *       read
>