[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slapd ACL - limit bind to employeeType=<various>
On 2016-04-11 10:00, Tim Watts wrote:
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"?
Yepp.
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?
Yes, I think so. But I never used saslauthd myself.
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.
Your server, your attack vectors...
Ciao, Michael.