6.9. Access Control Usage Examples
The examples provided in this section illustrate how an imaginary ISP company, example.com, would implement its access control policy. All the examples explain how to perform a given task from the Console and using an LDIF file.
example.com's business is to offer a web hosting service and Internet access. Part of example.com's web hosting service is to host the directories of client companies. example.com actually hosts and partially manages the directories of two medium-sized companies, HostedCompany1 and HostedCompany2. It also provides Internet access to a number of individual subscribers.
These are the access control rules that example.com wants to put in place:
Grant anonymous access for read, search, and compare to the entire example.com tree for example.com employees (Section 6.9.1, “Granting Anonymous Access”).
Grant write access to example.com employees for personal information, such as homePhone and homePostalAddress (Section 6.9.2, “Granting Write Access to Personal Entries”).
Grant example.com employees the right to add any role to their entry, except certain critical roles (Section 6.9.3, “Restricting Access to Key Roles”).
Grant the example.com Human Resources group all rights on the entries in the People branch (Section 6.9.4, “Granting a Group Full Access to a Suffix”).
Grant all example.com employees the right to create group entries under the Social Committee branch of the directory and to delete group entries that they own (Section 6.9.5, “Granting Rights to Add and Delete Group Entries”).
Grant all example.com employees the right to add themselves to group entries under the Social Committee branch of the directory (Section 6.9.9, “Allowing Users to Add or Remove Themselves from a Group”).
Grant access to the directory administrator (role) of HostedCompany1 and HostedCompany2 on their respective branches of the directory tree, with certain conditions such as SSL authentication, time and date restrictions, and specified location (Section 6.9.6, “Granting Conditional Access to a Group or Role”).
Deny individual subscribers access to the billing information in their own entries (Section 6.9.7, “Denying Access”).
Grant anonymous access to the world to the individual subscribers subtree, except for subscribers who have specifically requested to be unlisted. (This part of the directory could be a consumer server outside of the firewall and be updated once a day.) See Section 6.9.1, “Granting Anonymous Access” and Section 6.9.8, “Setting a Target Using Filtering”.
Most directories are run such that you can anonymously access at least one suffix for read, search, or compare. For example, you might want to set these permissions if you are running a corporate personnel directory that you want employees to be able to search, such as a phonebook. This is the case at example.com internally and is illustrated in Section 6.9.1.1, “ACI "Anonymous example.com"”.
As an ISP, example.com also wants to advertise the contact information of all of its subscribers by creating a public phonebook accessible to the world. This is illustrated in Section 6.9.1.2, “ACI "Anonymous World"”.
In LDIF, to grant read, search, and compare permissions to the entire example.com tree to example.com employees, write the following statement:
aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous
Example"; allow (read, search, compare) userdn= "ldap:///anyone"
and dns="*.example.com";)
This example assumes that the aci attribute is added to the dc=example,dc=com entry. The userPassword attribute is excluded from the scope of the ACI.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab in the ACI name field, type Anonymous example.com. Check that All Users opens in the list of users granted access permission.
In the Rights tab, select the checkboxes for read, compare, and search rights. Make sure the other checkboxes are clear.
In the Targets tab, click This Entry to display the dc=example,dc=com suffix in the Target directory entry field. In the attribute table, locate the userPassword attribute, and clear the corresponding checkbox.
All other checkboxes should be selected. This task is made easier if you click the Name header to organize the list of attributes alphabetically.
In the Hosts tab, click Add, and in the DNS host filter field, type *.example.com. Click OK to dismiss the dialog box.
Click OK in the Access Control Editor window.
The new ACI is added to the ones listed in the Access Control Manager window.
In LDIF, to grant read and search access of the individual subscribers subtree to the world, while denying access to information on unlisted subscribers, write the following statement:
aci: (targetfilter= "(!(unlistedSubscriber=yes))")
(targetattr="homePostalAddress || homePhone || mail") (version
3.0; acl "Anonymous World"; allow (read, search) userdn="ldap:///anyone";)
This example assumes that the ACI is added to the ou=subscribers,dc=example,dc=com entry. It also assumes that every subscriber entry has an unlistedSubscriber attribute which is set to yes or no. The target definition filters out the unlisted subscribers based on the value of this attribute. For details on the filter definition, see Section 6.9.8, “Setting a Target Using Filtering”.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the Subscribers entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, in the ACI name field, type Anonymous World. Check that All Users opens in the list of users granted access permission.
In the Rights tab, select the checkboxes for read and search rights. Make sure the other checkboxes are clear.
In the Targets tab, click This Entry to display the ou=subscribers, dc=example,dc=com suffix in the Target directory entry field.
In the Filter for subentries field, type the following filter:
(!(unlistedSubscriber=yes))
In the attribute table, select the checkboxes for the homePhone, homePostalAddress, and mail attributes.
All other checkboxes should be clear; if it is easier, click the Check None button to clear the checkboxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
Click OK.
The new ACI is added to the ones listed in the Access Control Manager window.
Many directory administrators want to allow internal users to change some but not all of the attributes in their own entry. The directory administrators at example.com want to allow users to change their own password, home telephone number, and home address, but nothing else. This is illustrated in Section 6.9.2.1, “ACI "Write example.com"”.
It is also example.com's policy to let their subscribers update their own personal information in the example.com tree, provided that they establish an SSL connection to the directory. This is illustrated in Section 6.9.2.2, “ACI "Write Subscribers"”.
By setting this permission, you are also granting users the right to delete attribute values.
Granting example.com employees the right to update their password, home telephone number, and home address has the following statement in LDIF:
aci: (targetattr="userPassword || homePhone ||
homePostalAddress") (version 3.0; acl "Write example.com"; allow
(write) userdn= "ldap:///self" and dns="*.example.com";)
This example assumes that the ACI is added to the ou=example-people,dc=example,dc=com entry.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the example-people entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, in the ACI name field, type Write example.com. In the list of users granted access permission, do the following:
Select and remove All Users, then click Add.
The Add Users and Groups dialog box opens.
Set the Search area to Special Rights, and select Self from the search results list.
Click the Add button to list Self in the list of users who are granted access permission.
Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the checkbox for write right. Make sure the other checkboxes are clear.
In the Targets tab, click This Entry to display the ou=example-people,dc=example,dc=com suffix in the Target directory entry field. In the attribute table, select the checkboxes for the homePhone, homePostalAddress, and userPassword attributes.
All other checkboxes should be clear; if it is easier, click the Check None button to clear the checkboxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
In the Hosts tab, click Add to display the Add Host Filter dialog box. In the DNS host filter field, type *.example.com. Click OK to dismiss the dialog box.
Click OK in the Access Control Editor window.
The new ACI is added to the ones listed in the Access Control Manager window.
By setting this permission, you are also granting users the right to delete attribute values.
In LDIF, to grant example.com subscribers the right to update their password and home telephone number, write the following statement:
aci: (targetattr="userPassword || homePhone") (version 3.0; acl
"Write Subscribers"; allow (write) userdn= "ldap://self" and
authmethod="ssl";)
This example assumes that the aci is added to the ou=subscribers, dc=example,dc=com entry.
example.com subscribers do not have write access to their home address because they might delete the attribute, and example.com needs that information for billing. Therefore, the home address is business-critical information.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the Subscribers entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, in the ACI name field, type Write Subscribers. In the list of users granted access permission, do the following:
Select and remove All Users, then click Add.
The Add Users and Groups dialog box opens.
Set the Search area to Special Rights, and select Self from the search results list.
Click the Add button to list Self in the list of users who are granted access permission.
Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the checkbox for write. Make sure the other checkboxes are clear.
In the Targets tab, click This Entry to display the ou=subscribers, dc=example,dc=com suffix in the Target directory entry field.
In the Filter for subentries field, type the following filter:
(!(unlistedSubscriber=yes))
In the attribute table, select the checkboxes for the homePhone, homePostalAddress, and mail attributes.
All other checkboxes should be clear; if necessary, click the Check None button to clear the checkboxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
Optionally, to require users to authenticate using SSL, switch to manual editing by clicking the Edit Manually button, and add authmethod=ssl to the LDIF statement so that it reads as follows:
(targetattr="homePostalAddress || homePhone || mail")
(version 3.0; acl "Write Subscribers"; allow (write)
(userdn= "ldap:///self") and authmethod="ssl";)
Click OK.
The new ACI is added to the ones listed in the Access Control Manager window.
You can use role definitions in the directory to identify functions that are critical to your business, the administration of your network and directory, or another purpose.
For example, you might create a superAdmin role by identifying a subset of your system administrators that are available at a particular time of day and day of the week at corporate sites worldwide, or you might want to create a First Aid role that includes all members of staff on a particular site that have done first aid training. For information on creating role definitions, see Section 5.1, “Using Roles”.
When a role gives any sort of privileged user rights over critical corporate or business functions, consider restricting access to that role. For example, at example.com, employees can add any role to their own entry except the superAdmin role. This is illustrated in Section 6.9.3.1, “ACI "Roles"”.
In LDIF, to grant example.com employees the right to add any role to their own entry except the superAdmin role, write the following statement:
aci: (targetattr = "nsroledn")
(targattrfilters="add=nsroledn:(nsroledn !=
"cn=superAdmin,dc=example,dc=com")") (version 3.0; acl "Roles";
allow (write) userdn= "ldap:///self" and dns="*.example.com";)
This example assumes that the ACI is added to the ou=example-people,dc=example,dc=com entry.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the example-people entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, in the ACI name field, type Roles. In the list of users granted access permission, do the following:
Select and remove All Users, then click Add.
The Add Users and Groups dialog box opens.
Set the Search area in the Add Users and Groups dialog box to Special Rights, and select Self from the search results list.
Click the Add button to list Self in the list of users who are granted access permission.
Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the checkbox for write. Make sure the other checkboxes are clear.
In the Targets tab, click This Entry to use the ou=example-people,dc=example,dc=com suffix in the Target directory entry field.
In the Hosts tab, click Add to display the Add Host Filter dialog box. In the DNS host filter field, type *.example.com. Click OK to dismiss the dialog box.
To create the value-based filter for roles, switch to manual editing by clicking the Edit Manually button. Add the following to the beginning of the LDIF statement:
(targattrfilters="add=nsroledn:(nsroledn != "cn=superAdmin, dc=example,dc=com")")
The LDIF statement should read as follows:
(targattrfilters="add=nsroledn:(nsroledn != "cn=superAdmin,
dc=example,dc=com")") (targetattr = "*") (target = "ldap:///
ou=example-people,dc=example,dc=com") (version 3.0; acl "Roles";
allow (write) (userdn = "ldap:///self") and (dns="*.example.com");)
Click OK.
The new ACI is added to the ones listed in the Access Control Manager window.
Most directories have a group that is used to identify certain corporate functions. These groups can be given full access to all or part of the directory. By applying the access rights to the group, you can avoid setting the access rights for each member individually. Instead, you grant users these access rights simply by adding them to the group.
For example, when the Directory Server is set up with a typical process, an administrators group with full access to the directory is created by default.
At example.com, the Human Resources group is allowed full access to the ou=example-people branch of the directory so that they can update the employee database. This is illustrated in Section 6.9.4.1, “ACI "HR"”.
In LDIF, to grant the HR group all rights on the employee branch of the directory, use the following statement:
aci: (version 3.0; acl "HR"; allow (all) userdn=
"ldap:///cn=HRgroup,ou=example-people,dc=example,dc=com";)
This example assumes that the ACI is added to the ou=example-people,dc=example,dc=com entry.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the example-people entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, in the ACI name field, type HR. In the list of users granted access permission, do the following:
Select and remove All Users, then click Add.
The Add Users and Groups dialog box opens.
Set the Search area to Users and Groups, and type HRgroup in the Search for field.
This example assumes that you have created an HR group or role. For more information on groups and roles, see Chapter 5, Managing Entries with Roles, Class of Service, and Views.
Click the Add button to list the HR group in the list of users who are granted access permission.
Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, click the Check All button.
All checkboxes are selected, except for proxy rights.
Click OK.
The new ACI is added to the ones listed in the Access Control Manager window.
Some organizations want to allow employees to create entries in the tree if it can increase their efficiency or if it can contribute to the corporate dynamics.
At example.com, there is an active social committee that is organized into various clubs, such as tennis, swimming, and skiing. Any example.com employee can create a group entry representing a new club. This is illustrated in Section 6.9.5.1, “ACI "Create Group"”. Any example.com employee can become a member of one of these groups. This is illustrated in Section 6.9.9.1, “ACI "Group Members"” under Section 6.9.9, “Allowing Users to Add or Remove Themselves from a Group”. Only the group owner can modify or delete a group entry. This is illustrated in Section 6.9.5.2, “ACI "Delete Group"”.
In LDIF, to grant example.com employees the right to create a group entry under the ou=Social Committee branch, write the following statement:
aci: (target="ldap:///ou=social committee,dc=example,dc=com)
(targattrfilters="add=objectClass:(objectClass=groupOfNames)")
(version 3.0; acl "Create Group"; allow (add)
(userdn= "ldap:///uid=*,ou=example-people,dc=example,dc=com")
and dns="*.example.com";)
This ACI does not grant write permission, which means that the entry creator cannot modify the entry.
This example assumes that the ACI is added to the ou=social committee, dc=example,dc=com entry.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the Social Committee entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, in the ACI name field, type Create Group. In the list of users granted access permission, do the following:
Select and remove All Users, then click Add.
The Add Users and Groups dialog box opens.
Set the Search area to Special Rights, and select All Authenticated Users from the search results list.
Click the Add button to list All Authenticated Users in the list of users who are granted access permission.
Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the checkbox for add. Make sure the other checkboxes are clear.
In the Targets tab, click This Entry to display the ou=social committee, dc=example,dc=com suffix in the Target directory entry field.
In the Hosts tab, click Add to display the Add Host Filter dialog box. In the DNS host filter field, type *.example.com. Click OK to dismiss the dialog box.
To create the value-based filter that allows employees to add only group entries to this subtree, click the Edit Manually button. Add the following to the beginning of the LDIF statement:
(targattrfilters="add=objectClass:(objectClass=groupOfNames)")
The LDIF statement should read as follows:
(targattrfilters="add=objectClass:(objectClass=groupOfNames)")
(targetattr = "*") (target="ldap:///ou=social committee,dc=example,dc=com)
(version 3.0; acl "Create Group"; allow (read,search,add)
(userdn= "ldap:///all") and (dns="*.example.com"); )
Click OK.
The new ACI is added to the ones listed in the Access Control Manager window.
In LDIF, to grant example.com employees the right to modify or delete a group entry which they own under the ou=Social Committee branch, write the following statement:
aci: (target="ou=social committee,dc=example,dc=com)
(targattrfilters="del=objectClass:(objectClass=groupOfNames)")
(version 3.0; acl "Delete Group"; allow (delete) userattr=
"owner#GROUPDN";)
This example assumes that the aci is added to the ou=social committee, dc=example,dc=com entry.
Using the Console is not an effective way of creating this ACI because it requires manually editing the ACI to create the target filter and to check group ownership.
In many cases, when you grant a group or role privileged access to the directory, you want to ensure that those privileges are protected from intruders trying to impersonate your privileged users. Therefore, in many cases, access control rules that grant critical access to a group or role are often associated with a number of conditions.
example.com has created a directory administrator role for each of its hosted companies, HostedCompany1 and HostedCompany2. It wants these companies to be able to manage their own data and implement their own access control rules while securing it against intruders. For this reason, HostedCompany1 and HostedCompany2 have full rights on their respective branches of the directory tree, provided the following conditions are fulfilled:
Connection authenticated using SSL
Access requested between 8 a.m. and 6 p.m., Monday through Thursday
Access requested from a specified IP address for each company
These conditions are illustrated in a single ACI for each company, HostedCompany1 and HostedCompany2. Because the content of these ACIs is the same, the examples below illustrate the HostedCompany1 ACI only.
In LDIF, to grant HostedCompany1 full access to their own branch of the directory under the conditions stated above, write the following statement:
aci:(target="ou=HostedCompany1,ou=corporate-clients,dc=example,dc=com")
(targetattr= "*") (version 3.0; acl "HostedCompany1";allow (all)
(roledn="ldap:///cn=DirectoryAdmin,ou=HostedCompany1,
ou=corporate-clients, dc=example,dc=com") and
(authmethod="ssl") and (dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and
timeofday <= "1800") and (ip="255.255.123.234"); )
This example assumes that the ACI is added to the ou=HostedCompany1, ou=corporate-clients,dc=example,dc=com entry.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the HostedCompany1 entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, type HostedCompany1 in the ACI name field. In the list of users granted access permission, do the following:
Select and remove All Users, then click Add.
The Add Users and Groups dialog box opens.
Set the Search area to Users and Groups, and type DirectoryAdmin in the Search For field.
This example assumes that you have created an administrators role with a cn of DirectoryAdmin.
Click the Add button to list the administrators role in the list of users who are granted access permission.
Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, click the Check All button.
In the Targets tab, click This Entry to display the ou=HostedCompany1,ou=corporate-clients,dc=example,dc=com suffix in the Target directory entry field.
In the Hosts tab, click Add to display the Add Host Filter dialog box. In the IP address host filter field, type 255.255.123.234. Click OK.
The IP address must be a valid IP address for the host machine that the HostedCompany1 administrators use to connect to the example.com directory.
In the Times tab, select the block time corresponding to Monday through Thursday and 8 a.m. to 6 p.m.
A message appears below the table that specifies the selected time block.
To enforce SSL authentication from HostedCompany1 administrators, switch to manual editing by clicking the Edit Manually button. Add the following to the end of the LDIF statement:
and (authmethod="ssl")
The LDIF statement should be similar to the following:
aci: (targetattr = "*") (target="ou=HostedCompany1,ou=corporate-clients,dc=example,dc=com")
(version 3.0; acl "HostedCompany1"; allow (all) (roledn=
"ldap:///cn=DirectoryAdmin,ou=HostedCompany1,ou=corporate-clients, dc=example,dc=com") and
(dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and timeofday <= "1800") and
(ip="255.255.123.234") and (authmethod="ssl"); )
Click OK.
The new ACI is added to the ones listed in the Access Control Manager window.
If your directory holds business-critical information, it may be necessary to specifically deny access to it.
For example, example.com wants all subscribers to be able to read billing information such as connection time or account balance under their own entries but explicitly wants to deny write access to that information. This is illustrated in Section 6.9.7.1, “ACI "Billing Info Read"” and Section 6.9.7.2, “ACI "Billing Info Deny"”, respectively.
In LDIF, to grant subscribers permission to read billing information in their own entry, write the following statement:
aci: (targetattr="connectionTime || accountBalance") (version
3.0; acl "Billing Info Read"; allow (search,read) userdn=
"ldap:///self";)
This example assumes that the relevant attributes have been created in the schema and that the ACI is added to the ou=subscribers,dc=example,dc=com entry.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the Subscribers entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, in the ACI name field, type Billing Info Read. In the list of users granted access permission, do the following:
Select and remove All Users, then click Add.
The Add Users and Groups dialog box opens.
Set the Search area in the Add Users and Groups dialog box to Special Rights, and select Self from the search results list.
Click the Add button to list Self in the list of users who are granted access permission.
Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the checkboxes for search and read rights. Make sure the other checkboxes are clear.
In the Targets tab, click This Entry to display the ou=subscribers, dc=example,dc=com suffix in the Target directory entry field. In the attribute table, select the checkboxes for the connectionTime and accountBalance attributes.
All other checkboxes should be clear; if it is made easier, click the Check None button to clear the checkboxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
This example assumes that you have added the connectionTime and accountBalance attributes to the schema.
Click OK.
The new ACI is added to the ones listed in the Access Control Manager window.
In LDIF, to deny subscribers permission to modify billing information in their own entry, write the following statement:
aci: (targetattr="connectionTime || accountBalance") (version
3.0; acl "Billing Info Deny"; deny (write) userdn="ldap:///self";)
This example assumes that the relevant attributes have been created in the schema and that the ACI is added to the ou=subscribers,dc=example,dc=com entry.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the Subscribers entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, in the ACI name field, type Billing Info Deny. In the list of users granted access permission, do the following:
Select and remove All Users, then click Add.
The Add Users and Groups dialog box opens.
Set the Search area in the Add Users and Groups dialog box to Special Rights, and select Self from the search results list.
Click the Add button to list Self in the list of users who are granted access permission.
Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the checkbox for write. Make sure the other checkboxes are clear.
Click the Edit Manually button, and, in the LDIF statement that opens, change the word allow to deny.
In the Targets tab, click This Entry to display the ou=subscribers, dc=example,dc=com suffix in the Target directory entry field. In the attribute table, select the checkboxes for the connectionTime and accountBalance attributes.
All other checkboxes should be clear; if it is easier, click the Check None button to clear the checkboxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
This example assumes that the connectionTime and accountBalance attributes were added to the schema.
Click OK.
The new ACI is added to the ones listed in the Access Control Manager window.
To set access controls that allow access to a number of entries that are spread across the directory, consider using a filter to set the target.
Because search filters do not directly name the object for which you are managing access, it is easy to allow or deny access to the wrong objects unintentionally, especially as your directory becomes more complex. Additionally, filters can make it difficult to troubleshoot access control problems within your directory.
For example, the following ACI grants user bjensen write access to the department number, home phone number, home postal address, and manager attributes for all members of the accounting organization.
aci: (targetattr="departmentNumber || homePhone || homePostalAddress || manager") (targetfilter="(uid=bjensen)") (version 3.0; acl "Filtered ACL"; allow (write) userdn ="ldap:///cn=*,ou=accounting, dc=example,dc=com";)
Before you can set these permissions, you must create the accounting branch point ou=accounting,dc=example,dc=com). You can create organizational unit branch points in the Directory tab on the Directory Server Console.
Many directories set ACIs that allow users to add or remove themselves from groups. This is useful, for example, for allowing users to add and remove themselves from mailing lists.
At example.com, employees can add themselves to any group entry under the ou=social committee subtree. This is illustrated in Section 6.9.9.1, “ACI "Group Members"”.
In LDIF, to grant example.com employees the right to add or delete themselves from a group, write the following statement:
aci: (targettattr="member")(version 3.0; acl "Group Members"; allow (selfwrite)
(userdn= "ldap:///uid=*,ou=example-people,dc=example,dc=com") ;)
This example assumes that the ACI is added to the ou=social committee, dc=example,dc=com entry.
From the Console, set this permission by doing the following:
In the Directory tab, right-click the example-people entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
Click New to display the Access Control Editor.
In the Users/Groups tab, in the ACI name field, type Group Members. In the list of users granted access permission, do the following:
Select and remove All Users, then click Add.
The Add Users and Groups dialog box opens.
Set the Search area in the Add Users and Groups dialog box to Special Rights, and select All Authenticated Users from the search results list.
Click the Add button to list All Authenticated Users in the list of users who are granted access permission.
Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the checkbox for selfwrite. Make sure the other checkboxes are clear.
In the Targets tab, type dc=example,dc=com suffix in the Target directory entry field. In the attribute table, select the checkbox for the member attribute.
All other checkboxes should be clear; if it is easier, click the Check None button to clear the checkboxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
Click OK.
The new ACI is added to the ones listed in the Access Control Manager window.
DNs that contain commas require special treatment within your LDIF ACI statements. In the target and bind rule portions of the ACI statement, commas must be escaped by a single backslash (\). For example:
dn: dc=example.com Bolivia\, S.A.,dc=com
objectClass: top
objectClass: organization
aci: (target="ldap:///dc=example.com Bolivia\,S.A.,dc=com")(targetattr=*)
(version 3.0; acl "aci 2"; allow (all)
groupdn = "ldap:///cn=Directory Administrators,dc=example.com Bolivia\, S.A.,dc=com";)
Proxied authorization allows one user to bind and perform operation as another user. For example, example.com has an accounting program which must be able to bind to the directory as an accounting administrator in order to write data. This authorization assumes three things:
The client application's bind DN is "uid=MoneyWizAcctSoftware, ou=Applications,dc=example,dc=com".
The targeted subtree to which the client application is requesting access is ou=Accounting,dc=example,dc=com.
An accounting administrator with access permissions to the ou=Accounting,dc=example,dc=com subtree exists in the directory.
In order for the client application to gain access to the accounting subtree, using the same access permissions as the accounting administrator, two ACIs must be set:
The accounting administrator must have access permissions to the ou=Accounting,dc=example,dc=com subtree, so the following ACI grants all rights to the accounting administrator entry:
aci: (target="ldap:///ou=Accounting,dc=example,dc=com") (targetattr="*")
(version 3.0; acl "allowAll-AcctAdmin"; allow (all)
userdn="ldap://uid=AcctAdministrator,ou=Administrators,dc=example,dc=com")
There must be an ACI granting proxy rights to the client application in the directory:
aci: (target="ldap:///ou=Accounting,dc=example,dc=com") (targetattr="*")
(version 3.0; acl "allow proxy-accounting software"; allow (proxy)
userdn="ldap://uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com")
With this ACI in place, the MoneyWizAcctSoftware client application can bind to the directory and send an LDAP command such as ldapsearch or ldapmodify that requires the access rights of the proxy DN.
If the client performs an ldapsearch command, the command must include the following controls:
ldapmodify -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w secretpwd
-y "uid=AcctAdministrator,ou=Administrators,dc=example,dc=com"
The client or application (MoneyWizAcctSoftware) binds as itself but is granted the privileges of the proxy entry (AcctAdministrator). The client does not need the password of the proxy entry.
There are some restrictions on binding with proxy authorization. You cannot use the Directory Manager's DN (root DN) as a proxy DN. Additionally, if Directory Server receives more than one proxied authentication control, an error is returned to the client application, and the bind attempt is unsuccessful.