|OpenLDAP Faq-O-Matic : OpenLDAP Software FAQ : Configuration : SLAPD Configuration : Access Control : How do I grant access to a subset of attributes?|
|You can grant access to a set of attributes by specifying
a list of attribute names in the ACL "to" clause. To
be useful, you also need to grant access to the "entry"
itself. Also note how "children" controls the ability
to add, delete, and rename entries.
# mail: self may write, authenticated users may read access to attrs=mail by self write by users read by * none # cn, sn: self my write, all may read access to attrs=cn,sn by self write by * read # immediate children: only self can add/delete entries under this entry access to attrs=children by self write # entry itself: self may write, all may read access to attrs=entry by self write by * read # other attributes: self may write, others have no access access to * by self write by * none
ObjectClass names may also be specified in this list, which will affect all the attributes that are required and/or allowed by that objectClass. Actually, names in attrlist that are prefixed by @ are directly treated as objectClass names. A name prefixed by ! is also treated as an objectClass, but in this case the access rule affects the attributes that are not required nor allowed by that objectClass.
Note that it may be useful to define new objectclasses specifically for use in access lists. This allows the list of controlled attributes to be managed separately from the rules implementing the control.
For example, here are two objectclasses defined for this purpose:
objectclass ( 1.2.8126.96.36.19958854.666.3.1 NAME 'attrsetAnonVisible' DESC 'Attributes visible to anonymous users' AUXILIARY MAY ( objectclass $ cn $ sn $ displayname $ mail $ uniqueIdentifier ) ) # objectclass ( 1.2.8188.8.131.5258854.666.3.2 NAME 'attrsetUserVisible' DESC 'Attributes visible to authenticated users' AUXILIARY MAY ( telephoneNumber ) ) #
They could be used in rules like this:
# Grant permissions for authenticated users # access to filter="(objectclass=person)" attrs="@attrsetAnonVisible,@attrsetUserVisible" by users read by * break # # Grant permissions for anonymous users # access to filter="(objectclass=person)" attrs="@attrsetAnonVisible" by * read access to * by * none
If you're using
I wanted to allow an ironport mail appliance to only have access to a few attributes for the People tree.
I ended up with the following. without the attr
access to dn.subtree="ou=People,dc=example,dc=com" attrs="entry,uid,cn,sn,mail,mailHost" by dn="cn=outsourced_ironport,dc=example,dc=com" read by * break
|[Append to This Answer]|
|Previous:||How do I use groups to manage access control?|
|Next:||How do I allow a user write to all entries below theirs?|