ACLs - allowing a user to add a new attribute

[Matt Ingram]

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

[Guillaume Rousse]

Post by Matt Ingram
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.

Post by Matt Ingram
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.

[Andrew Findlay]

Post by Matt Ingram
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

[Dieter Kluenter]

[...]

Post by Andrew Findlay

Post by Matt Ingram
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}+

Post by Andrew Findlay
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

[Andrew Findlay]

Post by Dieter Kluenter

Post by Andrew Findlay

Post by Matt Ingram
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.

Post by Dieter Kluenter

Post by Andrew Findlay
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

[Andrew Findlay]

Post by Matt Ingram
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.

Post by Matt Ingram

Post by Andrew Findlay
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

[Matt Ingram]

Awesome!!!!

That makes it much more clear.

Thank you.
Matt.

Post by Andrew Findlay

Post by Matt Ingram
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.

Post by Matt Ingram

Post by Andrew Findlay
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

[Matt Ingram]

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.

Post by Andrew Findlay
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.

[Sergiy Stepanenko]

I agree about userPassword
Something like that can restrict access to it

access to attrs=userPassword
by anonymous auth
by * none