Re: slapd ACL - limit bind to employeeType=<various>

[Tim Watts <tim.j.watts@kcl.ac.uk>]

Hi Michael,


On 11/04/16 07:31, Michael Ströder wrote:
> Tim Watts wrote:

> # some entries matching filter
> access to
>    attrs=userPassword
>    filter=(!(employeeType=Archive)(employeeType=Delete))
>      by ..some who clauses for setting password
>      by * auth
>
> # all other entries
> access to
>    attrs=userPassword
>      by * none
>
> The second ACL is important!

OK - I'm going to have to get my head around that :) On a test 
platform... Am I right in thinking the job of the 2nd ACL is because if 
employeeType is Archive|Delete, the first ACL will simple fall through - 
so the second ACL is semantically a "Deny All"?


One other thing - I did not mention, which is retrospect might be important:

I don't let slapd store password hashes - it passes through to Kerberos 
via saslauthd. So the attribute is of this form:

userPassword: {SASL}someuser@MY.KERB.REALM


I presume that blocking access to userPassword will still cause 
authentication to fail in this case as it won't be able to do that lookup?

> > Current ACLs are fairly simple:
> >
> > access to dn.base="" by * read
> >
> > access to attrs=userPassword
> >          by peername.path="/var/run/slapd/ldapi" manage
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This is somewhat dangerous because it gives any process which has write access
> to the LDAPI socket *manage* rights. I'd recommend not to do that. Rather use
> authz-regexp mappings to explicitly map certain OS accounts to real LDAP entries.

I thought you'd say that :) I'm OK with limiting access to the parent 
directory (in this case to the slapd user and root). For me, it feels 
simpler. You may disagree, but I just wanted to say it wasn't an oversight.

> >          by set="user/uid &
> > [cn=sysadmin,ou=groups,dc=dighum,dc=kcl,dc=ac,dc=uk]/memberUid" manage
>
> Set-ACLs are slow. I'd recommend to use groupOfNames entries to achieve this.

OK - I will have to study that - thanks for pointing it out.

Off to clone a test server off the production one....

I could have done with getting a bit more of this right the first time, 
but it was sadly a rush job at the time. Now seems like  a good time to 
put some polish on it.

All that best!

Tim


--
Tim Watts                               Tel (VOIP): +44 (0)1580 848360
Systems Manager         Kings Digital Lab (KDL), King's College London
Systems Messages and Notifications: https://systemsblog.cch.kcl.ac.uk/