[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: smbk5pwd and ppolicy working together
Adam Tauno Williams wrote:
>>>> 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.
>>>
>> My 'passwd program' in my smb.conf is "passwd program =
>> /usr/bin/ldappasswd -x -W -S -D uid=%u,ou=Users,dc=example,dc=com" - so
>> it should be using ldappasswd, which is bound by ppolicy, correct?
>>
>
> You shouldn't need a "passwd program" when using an LDAP SAM.
>
>
You're right. In reading the Samba documentation, I see that's only for
updating Unix passwords, not LDAP passwords (though I suppose it's
relevant if PAM is using LDAP and you set 'unix passwd sync = yes';
however, this is not my situation).
>> I've tried 'ldap passwd sync = only', after my failures with 'ldap
>> passwd sync = yes' lead me back to the documentation, however this
>> yielded no success.
>>
>
> I'm pretty sure if you have "ldap passwd sync = yes" that your "passwd
> program" directive is irrelevant since this means Samba is doing an
> ldapmodify to set the NT, LM, and userPassword attributes - your passwd
> program isn't doing anything. If "only" doesn't work then I strongly
> suspect that your smk5pwd module is *not* working, otherwise "only"
> would be the only mode to make any sense. By setting "ldap passwd sync
> = yes" your, at best, doing the work of smbk5pwd twice.
>
>
I realize that 'only' is what I want and that's what I'm using, however
I think smbk5pwd is working. The two snippets below are show the
differences after a Windows user changes his password (from the
ctrl+alt+delete menu):
sambaPwdCanChange: 1207134133
sambaPwdMustChange: 2147483647
userPassword:: e1NTSEF9UkxaOUdIZnVhNkV2ejBzS0JKNVVWQ2pVOHNnR29Ma1Q=
sambaPwdLastSet: 1207134133
sambaLMPassword: d85774cf671a9947aad3b435b51404ee
sambaNTPassword: baac3929fabc9e6dcd32421ba94a84d4
pwdChangedTime: 20080402110213Z
entryCSN: 20080402110213Z#000001#00#000000
modifiersName: cn=admin,dc=example,dc=com
modifyTimestamp: 20080402110213Z
sambaPwdMustChange: 2147483647
sambaPwdCanChange: 1207137250
userPassword:: e1NTSEF9NWMveHkxSkVtZDcvcnZuWFZ4a3dtMVJsUnAzUGdEQW4=
sambaPwdLastSet: 1207137250
sambaLMPassword: 614a6376feed376daad3b435b51404ee
sambaNTPassword: d01b4a346f59e594f299a41a48126188
pwdChangedTime: 20080402115410Z
entryCSN: 20080402115410Z#000001#00#000000
modifiersName: cn=admin,dc=example,dc=com
modifyTimestamp: 20080402115410Z
Unless my test or logic (or both) are fundamentally flawed, it seems
like the NT and LM passwords are being changed, along with the other
attributes listed above. Interestingly enough, however, the
modifiersName is admin (who isn't bound by the ppolicy restrictions) -
perhaps that is what's causing the circumvention of ppolicy? Should I
be investigating a way to force the modifier to be the user themselves?
Thanks as always for advice and constructive criticisms.
Ryan