Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide

Chapter 6 Directory Server Access Control

The control of access to your directory is an integral part of creating a secure directory. This chapter describes access control instructions (ACIs) that determine which permissions are granted to users who access the directory.

While you are in the planning phase of your directory deployment, define an access control strategy that serves your overall security policy. See the Sun Java System Directory Server Enterprise Edition 6.1 Deployment Planning Guide for tips on planning an access control strategy.

For additional information about ACIs, including ACI syntax and bind rules, see Sun Java System Directory Server Enterprise Edition 6.1 Reference.

This chapter covers the following topics:

Creating, Viewing, and Modifying ACIs

You can create ACIs either by using Directory Service Control Center (DSCC) or by using the command line. Whichever method you choose, it is often easier to view and copy an existing ACI value, rather than to create a new ACI from scratch.

You can view and modify the aci attribute values in DSCC. For information about how to modify ACIs through DSCC, see the DSCC online help.

To Create, Modify, and Delete ACIs

To create ACIs by using the command line, you first create the ACIs in a file using LDIF statements. Then you add the ACIs to your directory tree by using the ldapmodify command.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

Create the ACI in an LDIF file.
dn: dc=example,dc=com changetype: modify add: aci aci: (target)(version 3.0; acl "name";permission bindrules;)
This example shows how to add an ACI. To modify or delete the ACI, replace add with replace or delete.

For more examples of ACIs that are commonly used, see Access Control Usage Examples.

Make the change using the LDIF file.

$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - -f ldif-file

To View ACI Attribute Values

ACIs are stored as one or more values of the aci attribute of an entry. The aci attribute is a multi-valued operational attribute that can be read and modified by directory users. Therefore, the ACI attribute itself should be protected by ACIs. Administration users are usually given full access to the aci attribute.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

View the ACI attribute value of an entry by running the following ldapsearch command:
$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b entryDN -s base "(objectclass=*)" aci
The result is LDIF text that you can copy to your new LDIF ACI definition for editing. Because the value of an ACI is a long string, the output from the ldapsearch operation is likely to be displayed over several lines. In addition, the first space is a continuation marker. If you want the LDIF output to not contain a continuation marker, use the -T option. Take the output format into account when copying and pasting the LDIF output.

Note –
To view the permissions that an aci value grants and denies, see Viewing Effective Rights.

To View ACIs at the Root Level

When you create a suffix, some default ACIs are created at the top or root level. These ACIs allow the default administration user cn=admin,cn=Administrators,cn=config to have the same access rights to directory data as the Directory Manager.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

View the default root level ACIs.

$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \
 -b "" -s base "(objectclass=*)" aci

Access Control Usage Examples

The examples in this section illustrate how an imaginary ISP company, Example.com, would implement its access control policy.

In addition, you can find ACI examples in the example LDIF file provided with your installation, install_path/ds6/ldif/Example.ldif.

All of the examples explain how to perform a given task by using an LDIF file. The following figure shows the example.com Directory Information Tree in graphical form.

Topography of an example directory tree. The top level
entry and the entries directly below the top level entry are shown.

Example.com offers 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, Company333 and Company999. Example.com also provides internet access to a number of individual subscribers.

Example.com wants to put the following access rules in place:

Grant anonymous read, search, and compare access to the entire Example.com tree for Example.com employees. See Granting Anonymous Access.
Grant write access to Example.com employees for personal information, such as homeTelephoneNumber, and homeAddress. See Granting Write Access to Personal Entries.
Grant Example.com subscribers the right to read the entry dc=example,dc=com for company contact information, but not to read any entries below it. See Granting Access to a Certain Level.
Grant Example.com employees the right to add any role to their entry, except certain critical roles. See Restricting Access to Key Roles.
Grant certain administrators the same rights as the Directory Manager for a suffix. See Granting a Role Full Access to an Entire Suffix.
Grant the Example.com Human Resources group all rights on the entries in the People branch. See 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 an employee owns. See 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. See Allowing Users to Add or Remove Themselves From a Group.
Grant access to the directory administrator (role) of Company333 and Company999 on their respective branches of the directory tree, with certain conditions. These conditions include SSL authentication, time and date restrictions, and specified location. See Granting Conditional Access to a Group or Role.
Grant individual subscribers access to their own entries. See Granting Write Access to Personal Entries.
Deny individual subscribers access to the billing information in their own entries. See Denying Access.
Grant anonymous access to the world to the individual subscribers subtree, except for subscribers who have specifically requested to be unlisted. If desired, this part of the directory could be a read-only server outside of the firewall, and be updated once a day. See Granting Anonymous Access and Setting a Target Using Filtering.

Granting Anonymous Access

Most directories are configured to enable you to anonymously access at least one suffix for read, search, or compare. You might want to set these permissions if you are running a corporate personnel directory, such as a phone book that you want employees to be able to search. This is the case at Example.com internally, as shown in 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 phone book that is accessible to the world. This is depicted in ACI “Anonymous World”.

ACI “Anonymous Example.com”

In LDIF, to grant read, search, and compare permissions to the entire Example.com tree to Example.com employees, you would write the following statement:

aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous
 example"; allow (read, search, compare)
 userdn= "ldap:///anyone") ;)

This example assumes that the aci is added to the dc=example,dc=com entry. Note that the userPassword attribute is excluded from the scope of the ACI.

Note –

Protect attributes that are confidential and attributes that should not be visible using the same syntax used in the example to protect the password attribute, (targetattr !="attribute-name").

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 subscribers who want to be unlisted, you could 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. The example also assumes that every subscriber entry has an unlistedSubscriber attribute that 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, refer to Setting a Target Using Filtering.

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

Example.com also has a policy to let their subscribers update their own personal information in the Example.com tree provided that the subscribers establish an SSL connection to the directory. This is depicted in ACI “Write Subscribers”.

ACI “Write Example.com”

Note –

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

In LDIF, to grant Example.com employees the right to update their home telephone number and home address, you would write the following statement:

aci: (targetattr="homePhone ||
 homePostalAddress")(version 3.0; acl "Write Example.com";
 allow (write) userdn="ldap:///self" ;)

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

ACI “Write Subscribers”

Note –

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 home telephone number, you would write the following statement:

aci: (targetattr="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, and that users must bind using SSL.

Note that Example.com subscribers do not have write access to their home address because they might delete that attribute. The home address is business-critical information that Example.com needs billing purposes.

Granting Access to a Certain Level

You can set the scope of an ACI to affect different levels within your directory tree, to fine-tune the level of access you want to allow. The target ACI scope can be set to one of the following:

base: The entry itself
onelevel: The entry itself and all entries one level below
subtree: The entry itself and all entries beneath that entry, to an unlimited depth

ACI “Read Example.com only”

In LDIF, to grant Example.com subscribers the right to read the entry dc=example,dc=com for company contact information, but not allow access to any entries below it, you would write the following statement:

aci: (targetscope="base") (targetattr="*")(version 3.0;
 acl "Read Example.com only";  allow (read,search,compare)
 userdn="ldap:///cn=*,ou=subscribers,dc=example,dc=com";)

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

Restricting Access to Key Roles

You can use role definitions in the directory to identify functions that are critical to your business, such as the administration of your network and directory.

For example, you might create a superAdmin role by identifying a subset of your system administrators who 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 staff members who have first aid training at a particular site. For information about creating role definitions see Managing 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, as shown in the following example.

ACI “Roles”

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

aci: (targetattr="*") (targattrfilters="add=nsRoleDN:
 (nsRoleDN !="cn=superAdmin, dc=example, dc=com")")
 (version 3.0; acl "Roles"; allow (write)
 userdn= "ldap:///self" ;)

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

Granting a Role Full Access to an Entire Suffix

Sometimes it is useful to grant certain users the same rights as the Directory Manager for a suffix. At Example.com, Kirsten Vaughan is an administrator for Directory Server. She has a role of superAdmin. This role has the following advantages:

Better security because administrators binding as themselves can be forced to use strong authentication such as SSL
Better security because the Directory Manager password is known by fewer people
More traceability through logging

Note –

Adding Kirsten Vaughan to the cn=Administrators,cn=config group would also grant her the same rights as Directory Manager.

To give a user the same rights as the Directory Manager for the whole server, follow the procedure in To Create an Administration User with Root Access.

ACI “Full Access”

In LDIF, to grant the administrator Kirsten Vaughan the same rights as a Directory Manager, use the following statement:

aci: (targetattr="*") (version 3.0; acl "Full Access";
 allow (all) groupdn= "ldap:///cn=SuperAdmin,dc=example,dc=com"
 and authmethod="ssl" ;)

This example assumes that the ACI is added to the root entry "" (no text).

Granting a Group Full Access to a Suffix

Most directories have groups that are used to identify certain corporate functions. A group can be given access to all or part of the directory. By applying access rights to a group, you can avoid setting access rights for each member individually. Instead, you grant users access rights by adding them to a group.

For example, when you create a Directory Server instance, an Administrators group cn=Administrators,cn=config with full access to the directory is created by default.

At Example.com, the Human Resources group is allowed full access to the ou=People branch of the directory so that they can update the employee directory, as shown in ACI “HR”.

ACI “HR”

In LDIF, to grant the HR group all rights to the employee branch of the directory, you would use the following statement:

aci: (targetattr="*") (version 3.0; acl "HR"; allow (all)
  groupdn= "ldap:///cn=HRgroup,ou=Groups,dc=example,dc=com";)

This example assumes that the ACI is added to the following entry:

ou=People,dc=example,dc=com

Granting Rights to Add and Delete Group Entries

Some organizations allow employees to create entries in the tree to increase employees' efficiency and to encourage employees to contribute to the corporate dynamics. At Example.com, for example, the social committee is organized into various clubs, such as tennis, swimming, skiing, and role-playing.

Any Example.com employee can create a group entry that represents a new club, as shown in ACI “Create Group”.

Any Example.com employee can become a member of one of these groups, as shown in Allowing Users to Add or Remove Themselves From a Group.

Only the group owner can modify or delete a group entry, as shown in ACI “Delete Group”.

ACI “Create Group”

In LDIF, to grant Example.com employees the right to create a group entry under the ou=Social Committee branch, you would write the following statement:

aci: (targetattr="*") (targattrfilters="add=objectClass: 
(|(objectClass=groupOfNames)(objectClass=top))") 
(version 3.0; acl "Create Group"; allow (read,search,add) 
userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") 
and dns="*.Example.com";)

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

Note –

This ACI does not grant write permission, which means that the entry creator cannot modify the entry.
Because the server adds the value top behind the scenes, you need to specify objectClass=top in the targattrfilters keyword.
This ACI restricts the client machine to be in the example.comdomain.

ACI “Delete Group”

In LDIF, to grant Example.com employees the right to modify or delete a group entry of the group to which they belong under the ou=Social Committee branch, you would write the following statement:

aci: (targetattr = "*") (targattrfilters="del=objectClass:
(objectClass=groupOfNames)")
 (version 3.0; acl "Delete Group"; allow (write,delete)
 userattr="owner#GROUPDN";)

This example assumes that the aci is added to the ou=Social Committee,dc=example,dc=com entry.

Note that to use DSCC to create this ACI is not very effective because you have to use manual editing mode to create the target filter and to check group ownership.

Allowing Users to Add or Remove Themselves From a Group

Many directories set ACIs that allow users to add or remove themselves from groups such as mailing lists.

At Example.com, employees can add themselves to any group entry under the ou=Social Committee subtree, as shown in ACI “Group Members”.

ACI “Group Members”

In LDIF, to grant Example.com employees the right to add themselves to a group, you would 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.

Granting Conditional Access to a Group or Role

In many cases, when you grant a group or role privileged access to the directory, you must 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, for example, has created a Directory Administrator role for each of its hosted companies, Company333 and Company999. Example.com wants these companies to be able to manage their own data and implement their own access control rules while securing the data against intruders.

For this reason, Company333 and Company999 have full rights on their respective branches of the directory tree, provided that the following conditions are fulfilled:

The connection is authenticated using a certificate over SSL.
Access is requested between 8:00 and 18:00, Monday through Thursday.
Access is requested from a specified IP address for each company.

These conditions are depicted in one ACI for each company, ACI “Company333” and ACI “Company999”. Because the content of both ACIs is the same, the following examples use the “Company333” ACI only.

ACI “Company333”

In LDIF, to grant Company333 full access to its own branch of the directory under the conditions stated previously, you would write the following statement:

aci: (targetattr = "*") (version 3.0; acl "Company333"; allow (all)
 (roledn="ldap:///cn=DirectoryAdmin,ou=Company333,
 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=Company333,ou=corporate clients,dc=example,dc=com entry.

Denying Access

If you have already allowed access to a large part of your suffix, you might want to deny access to a smaller part of the suffix beneath the existing ACI.

Note –

Denying access should be avoided where possible, because it can lead to surprising or complicated access control behavior. Restrict access by using a combination of scoping, attribute lists, target filters and so on.

Also, deleting a deny access ACI does not remove rights, but instead expands the rights set by other ACIs.

When the Directory Server evaluates access rights, it reads deny rights first, then allow rights.

In the examples that follow, Example.com wants all subscribers to be able to read billing information, such as connection time or account balance, under their own entries. Example.com also explicitly wants to deny write access to that information. The read access is depicted in ACI “Billing Info Read”. The deny access is depicted in ACI “Billing Info Deny”.

ACI “Billing Info Read”

In LDIF, to grant subscribers permission to read billing information in their own entry, you would 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.

ACI “Billing Info Deny”

In LDIF, to deny subscribers permission to modify billing information in their own entry, you would 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.

Proxy Authorization

The proxy authorization method is a special form of authentication. A user that binds to the directory by using his or her own identity is granted the rights of another user through proxy authorization.

To configure Directory Server to allow proxy requests you must do the following:

Grant the administrators the right to proxy as other users.
Grant your regular users normal access rights as defined in your access control policy.

Note –

You can grant proxy rights to any users of the directory except the Directory Manager. In addition, you cannot use the Directory Manager’s DN as a proxy DN. You need to exercise great care when granting proxy rights because you grant the right to specify any DN (except the Directory Manager DN) as the proxy DN. If Directory Server receives more than one proxied authentication control in the same operation, an error is returned to the client application and the operation attempt is unsuccessful.

Example Proxy Authorization

Example.com wants the client application that binds as MoneyWizAcctSoftware to have the same access rights to the LDAP data as an Accounting Administrator.

The following parameters apply:

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.

For the client application to gain access to the Accounting subtree, by using the same access permissions as the Accounting Administrator, the following must be true:

The Accounting Administrator must have access permissions to the ou=Accounting,dc=example,dc=com subtree. For example, the following ACI grants all rights to the Accounting Administrator entry:
aci: (targetattr="*") (version 3.0; acl "allowAll-AcctAdmin"; allow (all) userdn="ldap:///uid=AcctAdministrator,ou=Administrators, dc=example,dc=com";)

The following ACI that grants proxy rights to the client application must exist in the directory:

aci: (targetattr="*") (version 3.0; acl "allowproxy- accountingsoftware";
 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 then send an LDAP command, such as ldapsearch or ldapmodify, that requires the access rights of the proxy DN.

In this example, if the client wanted to perform an ldapsearch command, the command would include the following controls:

$ ldapsearch -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w - \
 -y "uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" ...

Note that the client binds as itself, but is granted the privileges of the proxy entry. The client does not need the password of the proxy entry.

Setting a Target Using Filtering

If you want to set access controls that allow access to a number of entries that are spread across the directory, you might want to use a filter to set the target.

In LDIF, to use a filter to allow all users in HR access to employee entries, you would write the following statement:

aci: (targetattr="*") (targetfilter=(objectClass=employee))
 (version 3.0; acl "HR access to employees";
 allow (all) groupdn= "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.

Note –

Because search filters do not directly name the object for which you are managing access, try not to allow or deny access to the wrong objects. Unintentionally allowing or denying access to the wrong objects becomes more of a risk as your directory becomes more complex. Additionally, filters can make it difficult for you to troubleshoot access control problems within your directory.

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 (\). The following example illustrates this syntax:

dn: o=Example.com Bolivia\, S.A. 
objectClass: top 
objectClass: organization 
aci: (target="ldap:///o=Example.com Bolivia\,S.A.") (targetattr="*") 
(version 3.0; acl "aci 2"; allow (all) groupdn = 
"ldap:///cn=Directory Administrators, o=Example.com Bolivia\, S.A.";)

Viewing Effective Rights

When maintaining the access policy on the entries of a directory, you need to know the effects on security of the ACIs that you define. Directory Server enables you to evaluate existing ACIs by viewing the effective rights that the ACIs grant for a given user on a given entry.

Directory Server responds to the “Get Effective Rights”, control which can be included in a search operation. The response to this control is to return the effective rights information about the entries and attributes in the search results. This extra information includes read and write permissions for each entry and for each attribute in each entry. The permissions can be requested for the bind DN that is used for the search or for an arbitrary DN. This choice allows administrators to test the permissions of directory users.

Effective rights functionality relies on an LDAP control. You must ensure that the proxy identity used to bind to the remote server is also allowed to access the effective rights attributes.

Restricting Access to the Get Effective Rights Control

The operation of viewing effective rights is a directory operation that needs to be protected and appropriately restricted.

To restrict access to effective rights information, modify the default ACI for getEffectiveRights attribute. Then create a new ACI for the getEffectiveRightsInfo attribute .

For example, the following ACI allows only members of the Directory Administrators Group to get effective rights:

aci: (targetattr != "aci")(version 3.0; acl
 "getEffectiveRights"; allow(all) groupdn =
 "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)

To obtain effective rights information, you need to have access control rights to use the Effective Rights control and read access to the aclRights attribute. This double layer of access control provides basic security that can be more finely tuned if necessary. By analogy with proxy, if you have read access to the aclRights attribute in an entry, you can request information about anyone’s rights to that entry and its attributes. This implies that the user who manages the resource can determine who has rights to that resource, even if that user does not actually manage those with the rights.

If a user requesting rights information does not have the rights to use the Effective Rights control, the operation fails and an error message is returned. However, if the user requesting rights information does have the rights to use the control but lacks the rights to read the aclRights attribute, the aclRights attribute will not appear in the returned entry. This behavior reflects Directory Server’s general search behavior.

Using the Get Effective Rights Control

Specify the “Get Effective Rights” control by using the ldapsearch command with the -J "1.3.6.1.4.1.42.2.27.9.5.2" option. By default, the control returns the effective rights of the bind DN entry on the entries and attributes in the search results.

Use the following options to change the default behavior:

-c "dn: bind DN " — The search results show the effective rights of the user binding with the given DN. This option allows an administrator to check the effective rights of another user. The option -c "dn:" shows the effective rights for anonymous authentication.
-X "attributeName ... " — The search results also include the effective rights on the named attributes. Use this option to specify attributes that do not appear in the search results. For example, use this option to determine if a user has permission to add an attribute that does not currently exist in an entry.
When using either or both of the -c and -X options, the -J option with the OID of the “Get Effective Rights” control is implied and does not need to be specified. If you specify a NULL value for the Effective Rights control, the rights are retrieved for the current user. In addition, the rights are retrieved for the attributes and entries that are being returned with the current ldapsearch operation.

Then you must select the type of information you want to view. Choose either the simple rights or the more detailed logging information that explains how those rights are granted or denied. The type of information is determined by adding either aclRights or aclRightsInfo, respectively, as an attribute to return in the search results. You can request both attributes to receive all effective rights information, although the simple rights essentially repeat the information in the detailed logging information.

Note –

The aclRights and aclRightsInfo attributes behave like virtual operational attributes. These attributes are not stored in the directory and are not returned unless explicitly requested. They are generated by Directory Server in response to the “Get Effective Rights” control.

Thus, these attributes cannot be used in filters or search operations of any kind.

The effective rights feature inherits other parameters that affect access control. These parameters include time of day, authentication method, machine address, and name.

The following example shows how the user Carla Fuente can view her rights in the directory. In the results, 1 means that permission is granted, and 0 means that permission is denied.

$ ldapsearch -J "1.3.6.1.4.1.42.2.27.9.5.2 -h host1.Example.com -p 389 \
 -D "uid=cfuente,ou=People,dc=example,dc=com" -w - -b "dc=example,dc=com" \
 "(objectclass=*)" aclRights
Enter bind password:
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

This result shows Carla Fuente the entries in the directory where she has at least read permission and shows that she can modify her own entry. The Effective Rights control does not bypass normal access permissions, so a user does not see the entries for which they do not have read permission. In the following example, the Directory Manager can see the entries to which Carla Fuente does not have read permission:

$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
 "(objectclass=*)" aclRights
Enter bind password:
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Directory Administrators, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=Special Users,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

In the preceding output, the Directory Manager can see that Carla Fuente cannot even view the Special Users or the Directory Administrators branches of the directory tree. In the following example, the Directory Manager can see that Carla Fuente cannot modify the mail and manager attributes in her own entry:

$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
 "(uid=cfuente)" aclRights "*"
Enter bind password:
version: 1
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;attributeLevel;mail: search:1,read:1,compare:1,
 write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
mail: cfuente@Example.com
aclRights;attributeLevel;uid: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
uid: cfuente
aclRights;attributeLevel;givenName: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
givenName: Carla
aclRights;attributeLevel;sn: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
sn: Fuente
aclRights;attributeLevel;cn: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
cn: Carla Fuente
aclRights;attributeLevel;userPassword: search:0,read:0,
 compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow==
aclRights;attributeLevel;manager: search:1,read:1,compare:1,
 write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
manager: uid=bjensen,ou=People,dc=example,dc=com
aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
telephoneNumber: (234) 555-7898
aclRights;attributeLevel;objectClass: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

Advanced Access Control: Using Macro ACIs

Organizations that use repeating directory tree structures can optimize the number of ACIs used in the directory by using macros. When you reduce the number of ACIs in your directory tree, it is easier to manage your access control policy. In addition, the efficiency of your ACI memory usage is improved.

Macros are placeholders that are used to represent a DN or a portion of a DN in an ACI. You can use a macro to represent a DN in the target portion of the ACI, in the bind rule portion, or in both. In practice, when Directory Server gets an incoming LDAP operation, the ACI macros are matched against the resource targeted by the LDAP operation. The matching occurs in order to determine a matching substring, if any matching substring exists. If a match exists, the bind rule-side macro is expanded using the matched substring, and access to the resource is determined by evaluating that expanded bind rule.

This section contains an example of a macro ACI and information about macro ACI syntax.

Macro ACI Example

The benefits of macro ACIs and how they work are best explained by using an example. Figure 6–1 shows a directory tree in which using macro ACIs is an effective way of reducing the overall number of ACIs.

In this illustration, note the repeating pattern of subdomains with the same tree structure (ou=groups,ou=people). This pattern is also repeated across the tree because the Example.com directory tree stores the two suffixes dc=hostedCompany2,dc=example,dc=com, and dc=hostedCompany3,dc=example,dc=com, which are not shown in the figure.

The ACIs in the directory tree also have a repeating pattern. For example, the following ACI is located on the dc=hostedCompany1,dc=example,dc=com node:

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))(version 3.0;
 acl "Domain access"; allow (read,search) groupdn=
 "ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,
 dc=example,dc=com";)

This ACI grants the domainAdmins group read and search rights to any entry in the dc=hostedCompany1,dc=example,dc=com tree.

Figure 6–1 Example Directory Tree for Macro ACIs

Topography of an example directory tree, showing dc=hostedcompany1,dc=example,dc=com,
and various subdomains.

The following ACI is located on the dc=hostedCompany1,dc=example,dc=com node:

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)

The following ACI is located on the dc=subdomain1,dc=hostedCompany1, dc=example,dc=com node:

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,
  dc=example,dc=com";)

The following ACI is located on the dc=hostedCompany2,dc=example,dc=com node:

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2, dc=example,dc=com";)

The following ACI is located on the dc=subdomain1,dc=hostedCompany2, dc=example,dc=com node:

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany2,
 dc=example,dc=com";)

In the preceding four ACIs, the only difference is the DN that is specified in the groupdn keyword. By using a macro for the DN, it is possible to replace these ACIs with a single ACI at the root of the tree, on the dc=example,dc=com node. This macro ACI reads as follows:

aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
 (targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search) 
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

Note that the target keyword which was not previously used needs to be introduced.

In the preceding example, the number of ACIs is reduced from four to one. However, the real benefit is a factor of how many repeating patterns you have down and across your directory tree.

Macro ACI Syntax

To simplify the discussion in this section, the ACI keywords such as userdn, roledn, groupdn, and userattr that are used to provide bind credentials are collectively called the subject of the ACI. The subject determines to whom the ACI applies.

The following table shows which macros can be used to replace specific ACI keywords.

Table 6–1 Macro ACI Keywords


Macro	Description	ACI Keywords
`($dn)`	For matching in the target, and direct substitution in the subject.	`target, targetfilter, userdn, roledn, groupdn, userattr`
`[$dn]`	For substituting multiple RDNs that work in subtrees of the subject.	`targetfilter, userdn, roledn, groupdn, userattr`
`($attr.attrName)`	For substituting the value of the `attributeName` attribute from the target entry into the subject.	`userdn, roledn, groupdn, userattr`

The following restrictions apply to macro ACI keywords:

When using the ($dn) and [$dn] macros in a subject, you must define a target that contains the ($dn) macro.
You can combine the ($dn) macro (but not the [$dn] macro) with the ($attr.attrName) macro in a subject.

Matching for `($dn)` in the Target

The ($dn) macro in the target of an ACI determines the substitution value by comparing it to the entry targeted by the LDAP request. For example, you have an LDAP request targeted at this entry:

cn=all,ou=groups,dc=subdomain1, dc=hostedCompany1,dc=example,dc=com

In addition, you have an ACI that defines the target as follows:

(target="ldap:///ou=Groups,($dn),dc=example,dc=com")

The ($dn) macro matches with “dc=subdomain1, dc=hostedCompany1”. This substring is then used for substitutions in the subject of the ACI.

Substituting `($dn)` in the Subject

In the subject of the ACI, the ($dn) macro is replaced by the entire substring that matches in the target. For example:

groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com"

The subject becomes this:

groupdn="ldap:///cn=DomainAdmins,ou=Groups,
 dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"

After the macro has been expanded, Directory Server evaluates the ACI following the normal process to determine whether access is granted.

Note –

Unlike a standard ACI, an ACI that uses macro substitution does not necessarily grant access to the child of the targeted entry. This is because when the child DN is the target, the substitution might not create a valid DN in the subject string.

Substituting `[$dn]` in the Subject

The substitution mechanism for [$dn] is slightly different than for ($dn). The DN of the targeted resource is examined several times, each time dropping the left-most RDN component, until a match is found.

For example, suppose that you have an LDAP request targeted at the cn=all,ou=groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com subtree, and the following ACI:

aci: (targetattr="*")
 (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],
 dc=example,dc=com";)

The server proceeds as follows to expand this ACI:

The server verifies that the ($dn) in target matches dc=subdomain1,dc=hostedCompany1.
The server replaces [$dn] in the subject with dc=subdomain1,dc=hostedCompany1.

The resulting subject is groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com". If access is granted because the bind DN is a member of that group, the macro expansion stops, and the ACI is evaluated. If the bind DN is not a member, the process continues.
The server replaces [$dn] in the subject with dc=hostedCompany1.

The resulting subject is groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com". Again, the bind DN is tested as a member of this group and if it is, the ACI is evaluated fully. If the bind DN is not a member, macro expansion stops with the last RDN of the matched value, and ACI evaluation is finished for this ACI.

The advantage of the [$dn] macro is that it provides a flexible way to grant domain-level administrators access to all the subdomains in the directory tree. Therefore, the [$dn] macro is useful for expressing a hierarchical relationship between domains.

For example, consider the following ACI:

aci: (target="ldap:///ou=*,($dn),dc=example,dc=com") (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain)) 
(version 3.0; acl "Domain access"; allow (read,search) groupdn= 
"ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

The ACI grants access to the members of cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com to all of the subdomains under dc=hostedCompany1. Thus, an administrator who belongs to that group could access, for example, the subtree ou=people,dc=subdomain1.1,dc=subdomain1.

However, at the same time, members of cn=DomainAdmins,ou=Groups, dc=subdomain1.1 would be denied access to the ou=people,dc=subdomain1, dc=hostedCompany1 and ou=people,dc=hostedCompany1 nodes.

Macro Matching for `($attr.attrName)`

The ($attr.attrname) macro is always used in the subject part of a DN. For example, you could define the following roledn:

roledn = "ldap:///cn=DomainAdmins,($attr.ou),dc=HostedCompany1,dc=example,dc=com"

Now, assume that the server receives an LDAP operation that is targeted at the following entry:

dn: cn=Babs Jensen,ou=People,dc=HostedCompany1,dc=example,dc=com
cn: Babs Jensen
sn: Jensen
ou: Sales
...

To evaluate the roledn part of the ACI, the server reads the value of the ou attribute stored in the targeted entry. The server then substitutes this value in the subject to expand the macro. In the example, the roledn is expanded as follows:

roledn = "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1,dc=example,dc=com"

Directory Server then evaluates the ACI according to the normal ACI evaluation algorithm.

When the attribute that is named in the macro is multivalued, each value is used in turn to expand the macro. The first value that provides a successful match is used.

Logging Access Control Information

To obtain information about access control in the error logs, you must set the appropriate log level.

To Set Logging for ACIs

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

Set the log level to take into account ACI processing.

$ dsconf set-log-prop -h host -p port error level:err-acl

Client-Host Access Control Through TCP Wrapping

You can control the host or IP address from which connections are accepted or rejected at the TCP level using TCP wrappers. You can limit client-host access through TCP wrapping. This enables you to have non host-based protection for initial TCP connections to a Directory Server.

Although you can set TCP wrapping for Directory Server, TCP wrapping can result in significant performance degradation, especially during a Denial of Service attack. The best performance is achieved by using a host-based firewall that is maintained outside Directory Server, or IP port filtering.

To Enable TCP Wrapping

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

Create a hosts.allow file or a hosts.denyfile, somewhere within the instance path.

For example, create the file in instance-path/config. Ensure that the formatting of the files that you create comply with hosts_access(4).

Set the path to the access file.

$ dsconf set-server-prop -h host -p port host-access-dir-path:path-to-file

For example:

$ dsconf set-server-prop -h host -p port host-access-dir-path:/local/ds1/config
"host-access-dir-path" property has been set to "/local/ds1/config".
The "/local/ds1/config" directory on host1 must contain valid hosts.allow
and/or hosts.deny files.
Directory Server must be restarted for changes to take effect.

To Disable TCP Wrapping

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

Set the host access path to "".

$ dsconf set-server-prop -h host -p port host-access-dir-path:""

Chapter 6 Directory Server Access Control

Creating, Viewing, and Modifying ACIs

To Create, Modify, and Delete ACIs

To View ACI Attribute Values

To View ACIs at the Root Level

Access Control Usage Examples

Granting Anonymous Access

ACI “Anonymous Example.com”

ACI “Anonymous World”

Granting Write Access to Personal Entries

ACI “Write Example.com”

ACI “Write Subscribers”

Granting Access to a Certain Level

ACI “Read Example.com only”

Restricting Access to Key Roles

ACI “Roles”

Granting a Role Full Access to an Entire Suffix

ACI “Full Access”

Granting a Group Full Access to a Suffix

ACI “HR”

Granting Rights to Add and Delete Group Entries

ACI “Create Group”

ACI “Delete Group”

Allowing Users to Add or Remove Themselves From a Group

ACI “Group Members”

Granting Conditional Access to a Group or Role

ACI “Company333”

Denying Access

ACI “Billing Info Read”

ACI “Billing Info Deny”

Proxy Authorization

Example Proxy Authorization

Setting a Target Using Filtering

Defining Permissions for DNs That Contain a Comma

Viewing Effective Rights

Restricting Access to the Get Effective Rights Control

Using the Get Effective Rights Control

Advanced Access Control: Using Macro ACIs

Macro ACI Example

Figure 6–1 Example Directory Tree for Macro ACIs

Macro ACI Syntax

Matching for ($dn) in the Target

Substituting ($dn) in the Subject

Substituting [$dn] in the Subject

Macro Matching for ($attr.attrName)

Logging Access Control Information

To Set Logging for ACIs

Client-Host Access Control Through TCP Wrapping

To Enable TCP Wrapping

To Disable TCP Wrapping

Matching for `($dn)` in the Target

Substituting `($dn)` in the Subject

Substituting `[$dn]` in the Subject

Macro Matching for `($attr.attrName)`