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
The passwd program doesn't matter when using an LDAP SAM. Hopefully it is just ignored. Safe move would be to remove it altogether.
- why there is a sambaPasswordHistory attribute if it's using
ldappasswd (ldappasswd should modify the pwdHistory attribute, no?), and
? sambaPasswordHistory is part of the Samba schema and assumes that Samba is managing password integrity, repeated use, etc... But if you are using ppolicy I'd suspect you just don't care about sambaPasswordHistory.
I'd really like ppolicy & smbk5pwd to play nicely together and theoretically they should but I suspect you will run into one very interesting problem - what happens when Samba tries to change the password and ppolicy says "no"? What kind of meaningless error message will the end-user see?
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.
Is your Samba server binding as your manager/admin DN? Don't do that, ever. Create a bind context for Samba and use ACLs to give that context the access it requires. I don't know if it will fix Samba +ppolicy but it is the correct thing to do either way.