9.7. Designing Access Control

After deciding on the authentication schemes to use to establish the identity of directory clients, decide how to use those schemes to protect the information contained in the directory. Access control can specify that certain clients have access to particular information, while other clients do not.

Access control is defined using one or more access control lists (ACLs). The directory's ACLs consist of a series of one or more access control information (ACI) statements that either allow or deny permissions (such as read, write, search, and compare) to specified entries and their attributes.

Using the ACL, permissions can be set at any level of the directory tree:

The entire directory.
A particular subtree of the directory.
Specific entries in the directory.
A specific set of entry attributes.
Any entry that matches a given LDAP search filter.

In addition, permissions can be set for a specific user, for all users belonging to a specific group, or for all users of the directory. Lastly, access can be defined for a network location such as an IP address or a DNS name.

9.7.1. About the ACI Format

When designing the security policy, it is helpful to understand how ACIs are represented in the directory. It is also helpful to understand what permissions can be set in the directory. This section gives a brief overview of the ACI mechanism. For a complete description of the ACI format, refer to the Red Hat Directory Server Administrator's Guide.

Directory ACIs use the following general form: target permission bind_rule

The ACI variables are defined below:

target. Specifies the entry (usually a subtree) that the ACI targets, the attribute it targets, or both. The target identifies the directory element that the ACI applies to. An ACI can target only one entry, but it can target multiple attributes. In addition, the target can contain an LDAP search filter. Permissions can be set for widely scattered entries that contain common attribute values.
permission. Identifies the actual permission being set by this ACI. The permission variable states that the ACI is allowing or denying a specific type of directory access, such as read or search, to the specified target.
bind rule. Identifies the bind DN or network location to which the permission applies. The bind rule may also specify an LDAP filter, and if that filter is evaluated to be true for the binding client application, then the ACI applies to the client application.

ACIs can therefore be expressed as follows: "For the directory object target, allow or deny permission if bind_rule is true."

permission and bind_rule are set as a pair, and there can be multiple permission-bind_rule pairs for every target. Multiple access controls can be effectively set for any given target. For example:

target (permission bind_rule)(permission bind_rule)...

A permission can be set to allow anyone binding as Babs Jensen to write to Babs Jensen's telephone number. The bind rule in this permission is the part that states "if you bind as Babs Jensen." The target is Babs Jensen's phone number, and the permission is write access.

9.7.1.1. Targets

Decide which entry is targeted by every ACI created in the directory. Targeting a directory branch point entry includes that branch point and all of its child entries in the scope of the permission. If a target entry is not explicitly defined for the ACI, then the ACI is targeted to the directory entry that contains the ACI statement. Further, the default set of attributes targeted by the ACI is any attribute available in the targeted entry's object class structure.

For every ACI, only one entry or only those entries that match a single LDAP search filter can be targeted.

In addition to targeting entries, it is possible to target attributes on the entry; this applies the permission to only a subset of attribute values. Target sets of attributes by explicitly naming those attributes that are targeted or by explicitly naming the attributes that are not targeted by the ACI. Excluding attributes in the target sets a permission for all but a few attributes allowed by an object class structure.

9.7.1.2. Permissions

Permissions can either allow or deny access. In general, avoid denying permissions (for the reasons explained in Section 9.7.2.2, “Allowing or Denying Access”). Permissions can be any operation performed on the directory service:

Permission	Description
Read	Indicates whether directory data may be read.
Write	Indicates whether directory data may be changed or created. This permission also allows directory data to be deleted but not the entry itself. To delete an entire entry, the user must have delete permissions.
Search	Indicates whether the directory data can be searched. This differs from the read permission in that read allows directory data to be viewed if it is returned as part of a search operation. For example, if searching for common names is allowed as well as read permission for a person's room number, then the room number can be returned as part of the common name search, but the room number itself cannot be used as the subject of a search. Use this combination to prevent people from searching the directory to see who sits in a particular room.
Compare	Indicates whether the data may be used in comparison operations. The compare permission implies the ability to search, but actual directory information is not returned as a result of the search. Instead, a simple Boolean value is returned which indicates whether the compared values match. This is used to match `userPassword` attribute values during directory authentication.
Self-write	Used only for group management. This permission enables a user to add to or delete themselves from a group.
Add	Indicates whether child entries can be created. This permission enables a user to create child entries beneath the targeted entry.
Delete	Indicates whether an entry can be deleted. This permission enables a user to delete the targeted entry.
Proxy	Indicates that the user can use any other DN, except Directory Manager, to access the directory with the rights of this DN.

9.7.1.3. Bind Rules

The bind rule usually indicates the bind DN subject to the permission. It can also specify bind attributes such as time of day or IP address.

Bind rules easily express that the ACI applies only to a user's own entry. This allows users to update their own entries without running the risk of a user updating another user's entry.

Bind rules indicate that the ACI is applicable in specific situations:

Only if the bind operation is arriving from a specific IP address or DNS hostname. This is often used to force all directory updates to occur from a given machine or network domain.
If the person binds anonymously. Setting a permission for anonymous bind also means that the permission applies to anyone who binds to the directory as well.
For anyone who successfully binds to the directory. This allows general access while preventing anonymous access.
Only if the client has bound as the immediate parent of the entry.
Only if the entry as which the person has bound meets a specific LDAP search criteria.

The Directory Server provides several keywords to more easily express these kinds of access:

Parent. If the bind DN is the immediate parent entry, then the bind rule is true. This means that specific permissions can be granted that allow a directory branch point to manage its immediate child entries.
Self. If the bind DN is the same as the entry requesting access, then the bind rule is true. Specific permission can be granted to allow individuals to update their own entries.
All. The bind rule is true for anyone who has successfully bound to the directory.
Anyone. The bind rule is true for everyone. This keyword is used to allow or deny anonymous access.

9.7.2. Setting Permissions

By default, all users are denied access rights of any kind, with the exception of the Directory Manager. Consequently, some ACIs must be set for the directory for users to be able to access the directory.

For information about how to set ACIs in the directory, refer to the Red Hat Directory Server Administrator's Guide.

9.7.2.1. The Precedence Rule

When a user attempts any kind of access to a directory entry, Directory Server examines the access control set in the directory. To determine access, Directory Server applies the precedence rule. This rule states that when two conflicting permissions exist, the permission that denies access always takes precedence over the permission that grants access.

For example, if write permission is denied at the directory's root level, and that permission is applied to everyone accessing the directory, then no user can write to the directory regardless of any other permissions that may allow write access. To allow a specific user write permissions to the directory, the scope of the original deny-for-write has to be set so that it does not include that user. Then, there must be additional allow-for-write permission for the user in question.

9.7.2.2. Allowing or Denying Access

Access to the directory tree can be explicitly allowed or denied, but be careful of explicitly denying access to the directory. Because of the precedence rule, if the directory finds rules explicitly forbidding access, the directory forbids access regardless of any conflicting permissions that may grant access.

Limit the scope of allow access rules to include only the smallest possible subset of users or client applications. For example, permissions can be set that allow users to write to any attribute on their directory entry, but then deny all users except members of the Directory Administrators group the privilege of writing to the uid attribute. Alternatively, write two access rules that allow write access in the following ways:

Create one rule that allows write privileges to every attribute except the uid attribute. This rule should apply to everyone.
Create one rule that allows write privileges to the uid attribute. This rule should apply only to members of the Directory Administrators group.

Providing only allow privileges avoids the need to set an explicit deny privilege.

9.7.2.3. When to Deny Access

It is rarely necessary to set an explicit deny privilege, but there are a few circumstances where it is useful:

There is a large directory tree with a complex ACL spread across it.
For security reasons, it may be necessary to suddenly deny access to a particular user, group, or physical location. Rather than spending the time to carefully examine the existing ACL to understand how to appropriately restrict the allow permissions, temporarily set the explicit deny privilege until there is time to do the analysis. If the ACL has become this complex, then, in the long run, the deny ACI only adds to the administrative overhead. As soon as possible, rework the ACL to avoid the explicit deny privilege and then simplify the overall access control scheme.
Access control should be based on a day of the week or an hour of the day.
For example, all writing activities can be denied from Sunday at 11:00 p.m. (2300) to Monday at 1:00 a.m. (0100). From an administrative point of view, it may be easier to manage an ACI that explicitly restricts time-based access of this kind than to search through the directory for all the allow-for-write ACIs and restrict their scopes in this time frame.
Privileges should be restricted when delegating directory administration authority to multiple people.
To allow a person or group of people to manage some part of the directory tree, without allowing them to modify some aspect of the tree, use an explicit deny privilege.
For example, to make sure that Mail Administrators do not allow write access to the common name attribute, then set an ACI that explicitly denies write access to the common name attribute.

9.7.2.4. Where to Place Access Control Rules

Access control rules can be placed on any entry in the directory. Often, administrators place access control rules on entries with the object classes domainComponent, country, organization, organizationalUnit, inetOrgPerson, or group.

Organize rules into groups as much as possible in order to simplify ACL administration. Rules generally apply to their target entry and to all of that entry's children. Consequently, it is best to place access control rules on root points in the directory or on directory branch points, rather than scatter them across individual leaf (such as person) entries.

9.7.2.5. Using Filtered Access Control Rules

One of the more powerful features of the Directory Server ACI model is the ability to use LDAP search filters to set access control. Use LDAP search filters to set access to any directory entry that matches a defined set of criteria.

For example, allow read access for any entry that contains an organizationalUnit attribute that is set to Marketing.

Filtered access control rules allow predefined levels of access. Suppose the directory contains home address and telephone number information. Some people want to publish this information, while others want to be unlisted. There are several ways to address that:

Create an attribute on every user's directory entry called publishHomeContactInfo.
Set an access control rule that grants read access to the homePhone and homePostalAddress attributes only for entries whose publishHomeContactInfo attribute is set to true (meaning enabled). Use an LDAP search filter to express the target for this rule.
Allow the directory users to change the value of their own publishHomeContactInfo attribute to either true or false. In this way, the directory user can decide whether this information is publicly available.

For more information about using LDAP search filters and on using LDAP search filters with ACIs, refer to the Red Hat Directory Server Administrator's Guide.

9.7.3. Viewing ACIs: Get Effective Rights

It can be necessary to view access controls set on an entry to grant fine-grained access control or for efficient entry management. Get effective rights is an extended ldapsearch which returns the access control permissions set on each attribute within an entry, and allows an LDAP client to determine what operations the server's access control configuration allows a user to perform.

The access control information is divided into two groups of access: rights for an entry and rights for an attribute. "Rights for an entry" means the rights, such as modify or delete, that are limited to that specific entry. "Rights for an attribute" means the access right to every instance of that attribute throughout the directory.

This kind of detailed access control may be necessary in the following types of situations:

An administrator can use the get effective rights command for minute access control, such as allowing certain groups or users access to entries and restricting others. For example, members of the QA Managers group may have the right to search and read attributes such as title and salary, but only HR Group members have the rights to modify or delete them.
A user can use the get effective rights option to determine what attributes they can view or modify on their personal entry. For example, a user should have access to attributes such as homePostalAddress and cn, but may only have read access to title and salary.

An ldapsearch executed using the -J switch returns the access controls on a particular entry as part of the normal search results. The following search the rights that user Ted Morris has to his personal entry:

/usr/lib64/mozldap/ldapsearch -p 389 -h localhost -D "uid=tmorris,ou=people,dc=example,dc=com" -w password -b "uid=tmorris,ou=people,dc=example,dc=com" -J "1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=tmorris,ou=people,dc=example,dc=com" "(objectClass=*)"

version: 1
dn: uid=tmorris,ou=People,dc=example,dc=com
givenName: Ted
sn: Morris
ou: Accounting
ou: People
l: Santa Clara
manager: uid=dmiller,ou=People,dc=example,dc=com
roomNumber: 4117
mail: tmorris@example.com
facsimileTelephoneNumber: +1 408 555 5409
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: tmorris
cn: Ted Morris
userPassword: {SSHA}bz0uCmHZM5b357zwrCUCJs1IOHtMD6yqPyhxBA==
entryLevelRights: vadn
attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rscow, manager:rsc, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rsc, uid:rsc, cn:rsc, userPassword:wo

In this example, Ted Morris has the right to add, view, delete, or rename the DN on his own entry, as shown by the results in entryLevelRights. He can read, search, compare, self-modify, or self-delete the location (l) attribute but only self-write and self-delete rights to his password, as shown in the attributeLevelRights result.

By default, effective rights information is not returned for attributes in an entry that do not have a value or which do not exist in the entry. For example, if the userPassword value is removed, then a future effective rights search on the above entry would not return any effective rights for userPassword, even though self-write and self-delete rights could be allowed. Similarly, if the street attribute were added with read, compare, and search rights, then street: rsc would appear in the attributeLevelRights results.

It is possible to return rights for attributes which are not normally included in the search results, like non-existent attributes or operational attributes. Using an asterisk (*) returns the rights for all possible attributes for an entry, including non-existent attributes.

/usr/lib64/mozldap/ldapsearch -J 1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=scarter,ou=people,dc=example,dc=com "(objectclass=*)" "*"

Using the plus sign (+) returns operational attributes for the entry, which are not normally returned in an ldapsearch asterisk (*). For example:

/usr/lib64/mozldap/ldapsearch -J 1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=scarter,ou=people,dc=example,dc=com "(objectclass=*)" "+"

The asterisk (*) and the plus sign (+) can be used together to return every attribute for the entry.

Get effective rights for existing attributes are also visible in the Directory Server Console. Open the Advanced Properties editor for the user entry, and then select the Show effective rights checkbox. This displays the attribute-level rights (r, s, c, w, o) next to the attributes listed in the main window and the entry-level rights (v, a, d, n) underneath the entry's DN at the bottom of the window.

For more information about using get effective rights options with ldapsearch, see the Administrator's Guide.

9.7.4. Using ACIs: Some Hints and Tricks

Keep this tips in mind when implementing the security policy. They can help to lower the administrative burden of managing the directory security model and improve the directory's performance characteristics.

Minimize the number of ACIs in the directory.
Although the Directory Server can evaluate over 50,000 ACIs, it is difficult to manage a large number of ACI statements. A large number of ACIs makes it hard for human administrators to immediately determine the directory object available to particular clients.
Directory Server minimizes the number of ACIs in the directory by using macros. Macros are placeholders that are used to represent a DN, or a portion of a DN, in an ACI. Use the macro to represent a DN in the target portion of the ACI or in the bind rule portion, or both. For more information on macro ACIs, refer to the "Managing Access Control" chapter in the Red Hat Directory Server Administrator's Guide.
Balance allow and deny permissions.
Although the default rule is to deny access to any user who has not been specifically granted access, it may be better to reduce the number of ACIs by using one ACI to allow access close to the root of the tree, and a small number of deny ACIs close to the leaf entries. This scenario can avoid the use of multiple allow ACIs close to the leaf entries.
Identify the smallest set of attributes on any given ACI.
When allowing or denying access to a subset of attributes on an object, determine whether the smallest list is the set of attributes that are allowed or the set of attributes that are denied. Then express the ACI so that it only requires managing the smallest list.
For example, the person object class contains a large number of attributes. To allow a user to update only one or two of these attributes, write the ACI so that it allows write access for only those few attributes. However, to allow a user to update all but one or two attributes, create the ACI so that it allows write access for everything but a few named attributes.
Use LDAP search filters cautiously.
Search filters do not directly name the object for which you are managing access. Consequently their use can produce unexpected results. This is especially true as the directory becomes more complex. Before using search filters in ACIs, run an ldapsearch operation using the same filter to make clear what the results of the changes mean to the directory.
Do not duplicate ACIs in differing parts of the directory tree.
Guard against overlapping ACIs. For example, if there is an ACI at the directory root point that allows a group write access to the commonName and givenName attributes, and another ACI that allows the same group write access for only the commonName attribute, then consider reworking the ACIs so that only one control grants the write access for the group.
As the directory grows more complex, the risk of accidentally overlapping ACIs quickly increases. By avoiding ACI overlap, security management becomes easier while potentially reducing the total number of ACIs contained in the directory.
Name ACIs.
While naming ACIs is optional, giving each ACI a short, meaningful name helps with managing the security model, especially when examining ACIs from the Directory Server Console.
Group ACIs as closely together as possible within the directory.
Try to limit ACI placement to the directory root point and to major directory branch points. Grouping ACIs helps to manage the total list of ACIs, as well as helping keep the total number of ACIs in the directory to a minimum.
Avoid using double negatives, such as deny write if the bind DN is not equal to cn=Joe.
Although this syntax is perfectly acceptable for the server, it is confusing for a human administrator.