[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
slapd ACL - limit bind to employeeType=<various>
- To: "openldap-technical@openldap.org" <openldap-technical@openldap.org>
- Subject: slapd ACL - limit bind to employeeType=<various>
- From: Tim Watts <tim.j.watts@kcl.ac.uk>
- Date: Sun, 10 Apr 2016 23:02:42 +0100
- Authentication-results: openldap.org; dkim=none (message not signed) header.d=none;openldap.org; dmarc=none action=none header.from=kcl.ac.uk;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
Hi,
Sorry - this is probably very basic, but I cannot get my head around how
to write an ACL that prevents "auth" unless the user's employeeType
attribute is in a particular list (or NOT in a shorter list).
I have a slapd config line:
constraint_attribute employeeType regex
^(Staff|External|MA|PhD|Intern|System|Archive|Delete)$
However, I'd like to limit the ability to bind (auth) to those users
whose employeeType is NOT [regex ^(Archive|Delete)$]
or, less preferable, IS Staff|External|MA|PhD|Intern|System
At the moment I apply the constrain in pam-ldap, but that's not terribly
elegant and of course does not work if apache2's mod_authnz_ldap checks
directly with the LDAP server.
Many thanks for pointers :)
Tim
PS
Current ACLs are fairly simple:
access to dn.base="" by * read
access to attrs=userPassword
by peername.path="/var/run/slapd/ldapi" manage
by set="user/uid &
[cn=sysadmin,ou=groups,dc=dighum,dc=kcl,dc=ac,dc=uk]/memberUid" manage
by self write
by * auth
# Certain attributes that should not be publically readable
access to
attrs=bindTimestamp,modifyTimestamp,modifiersName,creatorsName,c
reateTimestamp
by peername.path="/var/run/slapd/ldapi" manage
by set="user/uid &
[cn=sysadmin,ou=groups,dc=dighum,dc=kcl,dc=ac,dc=uk]/memberUid" manage
by self read
by * none
--
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/