Re: smbk5pwd and ppolicy working together

[Adam Tauno Williams <adamtaunowilliams@gmail.com>]

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

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

-- 
Adam Tauno Williams, Network & Systems Administrator
Consultant - http://www.whitemiceconsulting.com
Developer - http://www.opengroupware.org