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