13.9. Access Control Usage Examples

The examples provided in this section illustrate how an imaginary ISP company, Example Corp., 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 Corp.'s business is to offer a web hosting service and Internet access. Part of Example Corp.'s web hosting service is to host the directories of client companies. Example Corp. 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 Corp. wants to put in place:

Grant anonymous access for read, search, and compare to the entire example tree for Example Corp. employees (Section 13.9.1, “Granting Anonymous Access”).
Grant write access to Example Corp. employees for personal information, such as homePhone and homePostalAddress (Section 13.9.2, “Granting Write Access to Personal Entries”).
Grant Example Corp. employees the right to add any role to their entry, except certain critical roles (Section 13.9.3, “Restricting Access to Key Roles”).
Grant the example.com Human Resources group all rights on the entries in the People branch (Section 13.9.4, “Granting a Group Full Access to a Suffix”).
Grant all Example Corp. employees the right to create group entries under the Social Committee branch of the directory and to delete group entries that they own (Section 13.9.5, “Granting Rights to Add and Delete Group Entries”).
Grant all Example Corp. employees the right to add themselves to group entries under the Social Committee branch of the directory (Section 13.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 13.9.6, “Granting Conditional Access to a Group or Role”).
Deny individual subscribers access to the billing information in their own entries (Section 13.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 13.9.1, “Granting Anonymous Access” and Section 13.9.8, “Setting a Target Using Filtering”.

13.9.1. Granting Anonymous Access

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 Corp. internally and is illustrated in Section 13.9.1.1, “ACI "Anonymous example.com"”.

As an ISP, Example Corp. 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 13.9.1.2, “ACI "Anonymous World"”.

13.9.1.1. ACI "Anonymous example.com"

In LDIF, to grant read, search, and compare permissions to the entire Example Corp. tree to Example Corp. 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:

In the Directory tab, right-click the example 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 check boxes for read, compare, and search rights. Make sure the other check boxes 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 check box.
All other check boxes should be selected. This task is 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.

13.9.1.2. ACI "Anonymous World"

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 13.9.8, “Setting a Target Using Filtering”.

From the Console:

In the Directory tab, right-click the Subscribers entry under the example 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 check boxes for read and search rights. Make sure the other check boxes 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, enter a filter which excludes unlisted subscribers ((!(unlistedSubscriber=yes))).
In the attribute table, select the check boxes for the homePhone, homePostalAddress, and mail attributes.
All other check boxes should be clear; if it is easier, click the Check None button to clear the check boxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
Click OK.

13.9.2. Granting Write Access to Personal Entries

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 Corp. want to allow users to change their own password, home telephone number, and home address, but nothing else. This is illustrated in Section 13.9.2.1, “ACI "Write example.com"”.

It is also Example Corp.'s policy to let their subscribers update their own personal information in the example tree, provided that they establish an SSL connection to the directory. This is illustrated in Section 13.9.2.2, “ACI "Write Subscribers"”.

13.9.2.1. ACI "Write example.com"

Note

By setting this permission, users will also have the right to delete attribute values.

Granting Example Corp. 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=people,dc=example,dc=com entry.

From the Console:

In the Directory tab, right-click the people entry under the example 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:
1. Remove All Users from the targeted user list.
2. Click Add.
3. Set the Search area to Special Rights, and select Self from the search results list.
4. Click the Add button to list Self in the list of users who are granted access permission.
5. Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the check box for write right. Make sure the other check boxes are clear.
In the Targets tab, click This Entry to display the ou=people,dc=example,dc=com suffix in the Target directory entry field. In the attribute table, select the check boxes for the homePhone, homePostalAddress, and userPassword attributes.
All other check boxes should be clear; if it is easier, click the Check None button to clear the check boxes 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.

13.9.2.2. ACI "Write Subscribers"

Note

By setting this permission, you are also granting users the right to delete attribute values.

In LDIF, to grant Example Corp. subscribers the right to update their password and home telephone number, write the following statement:

aci: (targetattr = "homePhone || homePostalAddress || mail") 
(target = "ldap:///ou=Subscribers,dc=example,dc=com") 
(targetfilter = (!(unlistedSubscriber=yes)) ) 
(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 Corp. subscribers do not have write access to their home address because they might delete the attribute, and Example Corp. needs that information for billing. Therefore, the home address is business-critical information.

From the Console:

In the Directory tab, right-click the subscribers entry under the example 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:
1. Remove All Users from the targeted user list.
2. Click Add.
3. Set the Search area to Special Rights, and select Self from the search results list.
4. Click the Add button to list Self in the list of users who are granted access permission.
5. Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the check box for write. Make sure the other check boxes 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.
1. In the Filter for subentries field, type a filter so that only listed subscribers are included:
```
(!(unlistedSubscriber=yes))
```
2. In the attribute table, select the check boxes for the homePhone, homePostalAddress, and mail attributes.
  All other check boxes should be clear; if necessary, click the Check None button to clear the check boxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
3. 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:
```
(targetattr = "homePhone || homePostalAddress || mail") 
(target = "ldap:///ou=Subscribers,dc=example,dc=com") 
(targetfilter = (!(unlistedSubscriber=yes)) ) 
(version 3.0;
acl "Write Subscribers";
allow (write)
(userdn = "ldap:///self") and authmethod="ssl";
;)
```
Click OK.

13.9.3. Restricting Access to Key Roles

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 6.2, “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 Corp., employees can add any role to their own entry except the superAdmin role. This is illustrated in Section 13.9.3.1, “ACI "Roles"”.

13.9.3.1. ACI "Roles"

In LDIF, to grant Example Corp. employees the right to add any role to their own entry except the superAdmin role, write the following statement:

aci: (targetattr = "nsroledn")
     (targetattrfilters="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=people,dc=example,dc=com entry.

From the Console:

In the Directory tab, right-click the people entry under the example 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:
1. Remove All Users from the targeted user list.
2. Click Add.
3. Set the Search area in the Add Users and Groups dialog box to Special Rights, and select Self from the search results list.
4. Click the Add button to list Self in the list of users who are granted access permission.
5. Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the check box for write. Make sure the other check boxes are clear.
In the Targets tab, click This Entry to use the ou=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:

(targetattrfilters="add=nsroledn:(nsroledn != "cn=superAdmin,dc=example,dc=com")")

The LDIF statement should read as follows:

(targetattrfilters="add=nsroledn:(nsroledn != "cn=superAdmin, 
     dc=example,dc=com")") (targetattr = "*") (target = "ldap:///
     ou=people,dc=example,dc=com") (version 3.0; acl "Roles"; 
     allow (write) (userdn = "ldap:///self") and (dns="*.example.com");)

Click OK.

13.9.4. Granting a Group Full Access to a Suffix

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 Corp., the Human Resources group is allowed full access to the ou=people branch of the directory so that they can update the employee database. This is illustrated in Section 13.9.4.1, “ACI "HR"”.

13.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=people,dc=example,dc=com";)

This example assumes that the ACI is added to the ou=people,dc=example,dc=com entry.

From the Console:

In the Directory tab, right-click the people entry under the example 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:
1. Remove All Users from the targeted user list.
2. Click Add.
3. 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 6, Organizing and Grouping Entries.
4. Click the Add button to list the HR group in the list of users who are granted access permission.
5. Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, click the Check All button.
All check boxes are selected, except for proxy rights.
Click OK.

13.9.5. Granting Rights to Add and Delete Group Entries

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 Corp., there is an active social committee that is organized into various clubs, such as tennis, swimming, and skiing. Any Example Corp. employee can create a group entry representing a new club. This is illustrated in Section 13.9.5.1, “ACI "Create Group"”. Any Example Corp. employee can become a member of one of these groups. This is illustrated in Section 13.9.9.1, “ACI "Group Members"” under Section 13.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 13.9.5.2, “ACI "Delete Group"”.

13.9.5.1. ACI "Create Group"

In LDIF, to grant Example Corp. 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)
    (targetattrfilters="add=objectClass:(objectClass=groupOfNames)")
    (version 3.0; acl "Create Group"; allow (add)
    (userdn= "ldap:///uid=*,ou=people,dc=example,dc=com")
    and dns="*.example.com";)

Note

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:

In the Directory tab, right-click the Social Committee entry under the example 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:
1. Remove All Users from the targeted user list.
2. Click Add.
3. Set the Search area to Special Rights, and select All Authenticated Users from the search results list.
4. Click the Add button to list All Authenticated Users in the list of users who are granted access permission.
5. Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the check boxes for add, search, and read. Make sure the other check boxes 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:

(targetattrfilters="add=objectClass:(objectClass=groupOfNames)")

The LDIF statement should read as follows:

(targetattrfilters="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.

13.9.5.2. ACI "Delete Group"

In LDIF, to grant Example Corp. 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)
     (targetattrfilters="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.

Note

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.

13.9.6. Granting Conditional Access to a Group or Role

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 Corp. 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.

13.9.6.1. ACI "HostedCompany1"

In LDIF, to grant HostedCompany1 full access to their own branch of the directory under the requisite conditions, 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:

In the Directory tab, right-click the HostedCompany1 entry under the example 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:
1. Remove All Users from the targeted user list.
2. Click Add.
3. Set the Search area to Users and Groups, and type DirectoryAdmin in the Search For field.
  (This assumes that there is an administrator's role with a cn of DirectoryAdmin.)
4. Click the Add button to list the administrator's role in the list of users who are granted access permission.
5. 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 directory.
Note
Directory Server supports both IPv4 and IPv6 IP addresses.
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:

(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.

13.9.7. Denying Access

If your directory holds business-critical information, it may be necessary to specifically deny access to it.

For example, Example Corp. 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 13.9.7.1, “ACI "Billing Info Read"” and Section 13.9.7.2, “ACI "Billing Info Deny"”, respectively.

13.9.7.1. ACI "Billing Info Read"

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:

In the Directory tab, right-click the Subscribers entry under the example 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:
1. Remove All Users from the targeted user list.
2. Click Add.
3. Set the Search area in the Add Users and Groups dialog box to Special Rights, and select Self from the search results list.
4. Click the Add button to list Self in the list of users who are granted access permission.
5. Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the check boxes for search and read rights. Make sure the other check boxes 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 check boxes for the connectionTime and accountBalance attributes. (These are custom schema that Example Corp. uses for ISP account management.)
All other check boxes should be clear; if it is easier, click the Check None button to clear the check boxes 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.

13.9.7.2. ACI "Billing Info Deny"

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:

In the Directory tab, right-click the Subscribers entry under the example 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:
1. Remove All Users from the targeted user list.
2. Click Add.
3. Set the Search area in the Add Users and Groups dialog box to Special Rights, and select Self from the search results list.
4. Click the Add button to list Self in the list of users who are granted access permission.
5. Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the check box for write. Make sure the other check boxes 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 check boxes for the connectionTime and accountBalance attributes.
All other check boxes should be clear; if it is easier, click the Check None button to clear the check boxes 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.

13.9.8. Setting a Target Using Filtering

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.

Note

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.

13.9.9. Allowing Users to Add or Remove Themselves from a Group

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 Corp., employees can add themselves to any group entry under the ou=social committee subtree. This is illustrated in Section 13.9.9.1, “ACI "Group Members"”.

13.9.9.1. ACI "Group Members"

In LDIF, to grant Example Corp. 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=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:

In the Directory tab, right-click the people entry under the example 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:
1. Remove All Users from the targeted user list.
2. Click Add.
3. 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.
4. Click the Add button to list All Authenticated Users in the list of users who are granted access permission.
5. Click OK to dismiss the Add Users and Groups dialog box.
In the Rights tab, select the check box for selfwrite. Make sure the other check boxes are clear.
In the Targets tab, type dc=example,dc=com suffix in the Target directory entry field. In the attribute table, select the check box for the member attribute.
All other check boxes should be clear; if it is easier, click the Check None button to clear the check boxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
Click OK.

13.9.10. Setting an ACI to Require a Certain Security Strength Factor for Some Operations

As mentioned in Section 13.4.8, “Requiring a Certain Level of Security in Connections”, the ssf keyword is used to require a secure connection and at a specific level of security. This can be a way to make changes to sensitive information only over a secure connection, like requiring that password changes be made over TLS or SASL:

aci: (targetattr="userPassword")(version 3.0; acl "Require secure password changes"; allow (write) userdn="ldap:///self" and ssf>="56";)

13.9.11. Defining Permissions for DNs That Contain a Comma

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";)

13.9.12. Proxied Authorization ACI Example

Proxied authorization allows one user to bind and perform operation as another user. For example, Example Corp. 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 -e authzid=dn: control to give the proxy account for a simple bind, as in the example, or use the -X auhzid argument for proxy authentication with a SASL bind.

ldapsearch -x -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w secret -e authz="dn:uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" ...

Note

Both the real user and the proxy user are recorded in the access logs. The real user is recorded as the dn, and the proxied user is recored as the authorization ID, authzid.

[01/Jul/2017:16:11:47 -0400] conn=1 op=0 BIND dn="uid=jsmith,ou=people,dc=example,dc=com" authzid="uid=admin,ou=corp-accounts,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.

Note

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.

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.