Hi All.
We're trying to implement acls that will allow our Admins to modify the LDAP directory without using a generic admin account, and using their own credentials within LDAP. Our requirement is that the Admins can modify the mail, uid and userPassword attributes. Which I have working. Part of this also requires that the Admin has the ability to add those attributes. That does not work.
We have our system automated so that HR creates a user and the basics are automatically populated into LDAP, however the mail, uid and userpassword attributes are not created at that time. What kind of an ACL do I need to allow the Admins to create the mail, uid and userPassword attributes ?
Thanks in advance. Matt.
Here's what I have for ACLs
access to dn="cn=Manager,dc=domain,dc=com" by * auth
access to dn="ou=Admins,dc=domain,dc=com" by dn.children="ou=Admins,dc=domain,dc=com" read by * auth
access to attrs=employeeNumber by dn.children="ou=Admins,dc=domain,dc=com" write by self read by * search
#Allow Admins ou and ldappers group to modify ldap's userPassword attribute access to attrs=userPassword by group/groupOfNames/member="cn=ldappers,ou=Apps,ou=Groups,ou=Accounts,dc=domain,dc=com" write by dn.children="ou=Admins,dc=domain,dc=com" write by self write by * auth
#allow Admins ou and ldappers group to modify ldap's mail and uid attributes and cbnActive attribute access to attrs=mail,uid by group/groupOfNames/member="cn=ldappers,ou=Apps,ou=Groups,ou=Accounts,dc=domain,dc=com" write by dn.children="ou=Admins,dc=domain,dc=com" write by self read by * read
access to * by dn.children="ou=Admins,dc=domain,dc=com" write by * read
Le 12/04/2010 19:14, Matt Ingram a écrit :
Hi All.
We're trying to implement acls that will allow our Admins to modify the LDAP directory without using a generic admin account, and using their own credentials within LDAP. Our requirement is that the Admins can modify the mail, uid and userPassword attributes. Which I have working. Part of this also requires that the Admin has the ability to add those attributes. That does not work.
We have our system automated so that HR creates a user and the basics are automatically populated into LDAP, however the mail, uid and userpassword attributes are not created at that time.
They just don't have any value, because they are optional attributes in the schema.
What kind of an ACL do I need to allow the Admins to create the mail, uid and userPassword attributes ?
You can't create them, you just need write perms to set them to some initial value.
On Mon, Apr 12, 2010 at 01:14:40PM -0400, Matt Ingram wrote:
We're trying to implement acls that will allow our Admins to modify the LDAP directory without using a generic admin account, and using their own credentials within LDAP. Our requirement is that the Admins can modify the mail, uid and userPassword attributes. Which I have working. Part of this also requires that the Admin has the ability to add those attributes. That does not work.
From an ACL perspective there is really no difference between adding
an attribute and modifying its value.
One comment I would make about your ACLs is that in several places you are granting read access to userPassword. This is not usually necessary nor is it a good idea. You need 'by * auth' access to permit authentication, but only need to give '=w' access to those who need to change passwords. Remember that the 'write' keyword includes read access.
If your ACLs are not doing what you expect, you may need to turn on 'loglevel ACL' (see slapd.conf(5)). The output is voluminous, but it can help you to understand what is going on.
Andrew
Andrew Findlay andrew.findlay@skills-1st.co.uk writes:
On Mon, Apr 12, 2010 at 01:14:40PM -0400, Matt Ingram wrote:
[...]
From an ACL perspective there is really no difference between adding
an attribute and modifying its value.
No! you have to distinguish between level access model and privilege model, slapd.access(5)
<level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
One comment I would make about your ACLs is that in several places you are granting read access to userPassword. This is not usually necessary nor is it a good idea. You need 'by * auth' access to permit authentication, but only need to give '=w' access to those who need to change passwords. Remember that the 'write' keyword includes read access
'=w' just grants write privilege but no read privilege.
-Dieter
On Tue, Apr 13, 2010 at 09:37:39PM +0200, Dieter Kluenter wrote:
From an ACL perspective there is really no difference between adding
an attribute and modifying its value.
No! you have to distinguish between level access model and privilege model, slapd.access(5)
<level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
The privilege model is more flexible, but in the case that Matt describes I do not see any relevant difference: he wants admins to add certain attributes and also to modify them. Either action requires at least 'add' privilge on the attribute, and changing existing values also requires 'delete' - thus 'write' is a reasonable level to choose.
One comment I would make about your ACLs is that in several places you are granting read access to userPassword. This is not usually necessary nor is it a good idea. You need 'by * auth' access to permit authentication, but only need to give '=w' access to those who need to change passwords. Remember that the 'write' keyword includes read access
'=w' just grants write privilege but no read privilege.
Exactly. Protecting password attributes is a case that the privilege model handles much better than the level model.
Andrew
Could you please clarify this comment for me, I don't understand. the only ACLs I have referring to userPassword is
access to attrs=userPassword by group/groupOfNames/member="cn=ldappers,ou=Apps,ou=Groups,ou=Accounts,dc=domain,dc=com" write by dn.children="ou=Admins,dc=domain,dc=com" write by self write by * auth
trying to achieve write access for the ldappers group, children of the Admins ou and self. by self write should give a user the ability to change their password, correct ? Is there a better ACL for what I'm trying to achieve ?
Thanks, Matt.
One comment I would make about your ACLs is that in several places you are granting read access to userPassword. This is not usually necessary nor is it a good idea. You need 'by * auth' access to permit authentication, but only need to give '=w' access to those who need to change passwords. Remember that the 'write' keyword includes read access.
On Wed, Apr 14, 2010 at 04:00:26PM -0400, Matt Ingram wrote:
access to attrs=userPassword by group/groupOfNames/member="cn=ldappers,ou=Apps,ou=Groups,ou=Accounts,dc=domain,dc=com" write by dn.children="ou=Admins,dc=domain,dc=com" write by self write by * auth
trying to achieve write access for the ldappers group, children of the Admins ou and self. by self write should give a user the ability to change their password, correct ? Is there a better ACL for what I'm trying to achieve ?
You have indeed given those users the ability to change the password. However, you have also given them the ability to *read* it (because 'write' includes 'read' in OpenLDAP ACLs). This is not usually necessary, and even if the password is hashed it is good practice to prevent it being read.
One comment I would make about your ACLs is that in several places you are granting read access to userPassword. This is not usually necessary nor is it a good idea. You need 'by * auth' access to permit authentication, but only need to give '=w' access to those who need to change passwords. Remember that the 'write' keyword includes read access.
If you replace 'write' with '=w' in the access statement above, you will still give those users the ability to change the password but they will not be able to read the existing password.
Andrew
Awesome!!!!
That makes it much more clear.
Thank you. Matt.
Andrew Findlay wrote:
On Wed, Apr 14, 2010 at 04:00:26PM -0400, Matt Ingram wrote:
access to attrs=userPassword by group/groupOfNames/member="cn=ldappers,ou=Apps,ou=Groups,ou=Accounts,dc=domain,dc=com" write by dn.children="ou=Admins,dc=domain,dc=com" write by self write by * auth
trying to achieve write access for the ldappers group, children of the Admins ou and self. by self write should give a user the ability to change their password, correct ? Is there a better ACL for what I'm trying to achieve ?
You have indeed given those users the ability to change the password. However, you have also given them the ability to *read* it (because 'write' includes 'read' in OpenLDAP ACLs). This is not usually necessary, and even if the password is hashed it is good practice to prevent it being read.
One comment I would make about your ACLs is that in several places you are granting read access to userPassword. This is not usually necessary nor is it a good idea. You need 'by * auth' access to permit authentication, but only need to give '=w' access to those who need to change passwords. Remember that the 'write' keyword includes read access.
If you replace 'write' with '=w' in the access statement above, you will still give those users the ability to change the password but they will not be able to read the existing password.
Andrew
openldap-software@openldap.org
-
Andrew Findlay -
Dieter Kluenter -
Guillaume Rousse -
Matt Ingram