Sir, you are a genius :)
On 11/04/16 07:31, Michael Ströder 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
Very slight tweak to the syntax (with huge thanks - I would not have guessed this was the required technique - I was concentrating on finding an "auth" ACL when I was googling.)
This is the full ACL list for context, should anyone find this useful. The nice thing is that I can add new employeeTypes (eg "BA" for undergrads) without breaking the core logic.
Also, this should be fundamentally more secure as we can now disable accounts in one place.
In case anyone is wondering the difference between "Archive" and "Delete", they are as follows:
"Archive" - keep the user in the libnss lists (eg getent passwd still returns them, so that file UIDs resolve). User cannot log in.
"Delete" - they vanish from libnss and other places, but we still hold their LDAP record for easy resurrection (this happens a lot - we have a class of nomadic users - they work on a project, go away, then come back on another project 2 years later).
===========================================
access to attrs=userPassword filter=(&(!(employeeType=Archive))(!(employeeType=Delete))) 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
access to attrs=userPassword by * none
# Certain attributes that should not be publicly readable access to attrs=bindTimestamp,modifyTimestamp,modifiersName,creatorsName,creat eTimestamp 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
# The admin dn has full write access, everyone else # can read everything. Local unix domain socket (root only) # Can do everything access to * 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 * read ===========================================
I'll do some more testing and have a look at that "set=" inefficiency too.
Thanks very much for your help :)
Tim
On 12/04/16 10:37, Tim Watts wrote:
I'll do some more testing and have a look at that "set=" inefficiency too.
OK - I understand that a bit more - I'll have to leave it alone. We're heavily structured around POSIX groups (memberUID).
But suggestion appreciated :)
Tim Watts wrote:
On 12/04/16 10:37, Tim Watts wrote:
I'll do some more testing and have a look at that "set=" inefficiency too.
OK - I understand that a bit more - I'll have to leave it alone. We're heavily structured around POSIX groups (memberUID).
But suggestion appreciated :)
The solution are hybrid groups:
# This allows mixed group schema # also "dynamic groups" based on groupOfURLs/memberURL objectclass ( ae-dir-oc:1 NAME 'aeGroup' X-ORIGIN 'AE-DIR' DESC 'AE-DIR: Group entry' STRUCTURAL SUP ( groupOfEntries $ posixGroup $ groupOfURLs $ aeObject ) MUST ( description ) )
With constraints you can ensure the alignment of 'member' and 'memberUID' attribute value sets.
Ciao, Michael.
On 2016-04-12 11:37, Tim Watts wrote:
Sir, you are a genius :)
On 11/04/16 07:31, Michael Ströder 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
Very slight tweak to the syntax
Ah yes, filter was wrong.
(with huge thanks - I would not have guessed this was the required technique - I was concentrating on finding an "auth" ACL when I was googling.)
Writing OpenLDAP ACLs is a bit like functional programming - at least to what I vaguely remember from my time at University many years ago.
I'd recommend to look into the OpenLDAP FAQ to find some more not so obvious examples.
Ciao, Michael.
Tim Watts wrote:
"Delete" - they vanish from libnss and other places, but we still hold their LDAP record for easy resurrection (this happens a lot - we have a class of nomadic users - they work on a project, go away, then come back on another project 2 years later).
That state I'd call "inactive" or similar. But that's cosmetic.
In my systems there's always exactly one status "active" for which I allow "auth" on "userPassword".
E.g. in Æ-DIR the attribute 'aeStatus' can have this Integer values:
-1: requested 0: active 1: deactivated 2: archived
I suspect you're overloading the semantics of 'employeeType' by putting two meaning into one attribute.
Ciao, Michael.
openldap-technical@openldap.org