k bah wrote:
Hi,
I want to give a certain DN access to userpassword attribute and to be able to delete and add entries from one OU on my LDAP tree.
tree-root ..OU=adm ...."DN I want to give rights", lets call it "webmail-domain-xyz".
..OU=people ....cn=10000000000,ou=people,dc=organization,dc=org
The DN's "webmail-domain-xyz" will have access will always be the form "cn=10000000000,ou=people,dc=organization,dc=org", where the cn will be from 10000000000 to 19999999999.
My question is related to my ACL's processing:
------------ current working ACL's ----- # ACL 0 access to dn.base="cn=Subschema" by * read
# ACL 1 access to attrs=userPKCS12 by self write by * auth
# ACL 2 access to attrs=shadowLastChange by self write by * read
# ACL 3 access to attrs=userPassword by dn="cn=reallysureyouwannauserootdn,dc=organization,dc=org" write by anonymous auth by self write by * none
# ACL 4 access to dn.base="" by * read
# ACL 5, 6 # (So Dovecot won't look where it's not supposed to, and will not complain about duplicated entries) access to dn.subtree="ou=moodle001,ou=moodleusers,ou=people,dc=organization,dc=org" by dn="uid=MoodleLDAPAdmin001,ou=adm,dc=organization,dc=org" write by dn="uid=dovecot-domain-xyz,ou=adm,dc=organization,dc=org" none by * read
access to dn.subtree="ou=moodle001,ou=moodlecourses,dc=organization,dc=org" by dn="uid=MoodleLDAPAdmin001,ou=adm,dc=organization,dc=org" write by dn="uid=dovecot-domain-xyz,ou=adm,dc=organization,dc=org" none by * read
# ACL 7 # So webmail related scripts can add new users to LDAP. access to dn.subtree="ou=people,dc=organization,dc=org" by dn="uid=webmail-domain-xyz,ou=adm,dc=organization,dc=org" write by * read # ACL 8 access to * by dn="cn=reallysureyouwannauserootdn,dc=organization,dc=org" write by * read
------------ current working ACL's -----
Q1) This is the ACL I need to add(?):
----- new acl access to dn.regex="^(.+,)?cn=([^,]+),ou=people,dc=organization,dc=org$" attrs=userPassword by dn="cn=reallysureyouwannauserootdn,dc=organization,dc=org" write by dn="uid=webmail-domain-xyz,ou=adm,dc=organization,dc=org" write by anonymous auth by self write by * none
----- new acl
That looks right to me.
Q2) Since I need these to continue to (co)exist:
- users under OU=people continue to have write access to their userpassword fields
- all other users (that are not under OU=people) to continue to have write access to their userpassword fields.
- the root dn to continue to have write access to everyone's userpassword field
- the webmail-domain-xyz to now have write access to user password fields of the users under OU=people
(QUESTION) this "new acl" needs to go between the current ACL #2 and ACL #3, right?
Right.
Since this "new acl" is a subcase of the current ACL #3, I need to put the "new acl" before the ACL #3, and make sure all cases that are _not_ related to the "new acl" do not make a match when the "new acl" is being processed (so they will fall under ACL #3 or go further to the next ACL's). I analized (since a match means "stop processing"):
- the "what"
- everyone else that do not match the "who"
- all DN's under the OU=people
- the root DN
You don't need to worry about the root DN - it always has write access to everything.
- the webmail DN (new "who" on the scenario)
Q3) If I need to make the regex a little more specific, is this right:
dn.regex="^cn=([^1][0-9]+),ou=people,dc=organization,dc=org$" attrs=userPassword
(to match cn=10000000000,ou=people,dc=organization,dc=org or cn=19999999999,ou=people,dc=organization,dc=org).
Hmmm. I think you mean "^cn=(1[0-9]+),ou=people,dc=organization,dc=org$" Thus including an obligatory "1" - "[^1]" means "everything except 1". But I just got back from holiday, so my regexp syntax may be a bit rusty :)
Q4) Is ACL #7 gonna be affected by the "new acl"? I mean, if the "webmail-domain-xyz" DN wants do add a new user to OU=people, will ACL processing stop on the "new acl", and never get to the ACL #7? Because the "new acl" only mentions the userPassword attribute, not the right to _add entries under OU=people_.
Your new ACL only concerns the userPassword attribute. Therefore, ACL checking will stop at the new ACL if looking for userPassword on an existing entry that matches your regexp, and go on for any other attributes until #7 - in particular creating new entries.
Looks like you have it all worked out, though :)
Regards,