shadow man Administrator's Guide
Red Hat Directory Server
Previous      Contents      Index      DocHome      Next     

Chapter 6   Managing Access Control


Red Hat Directory Server (Directory Server) provides you with the ability to control access to your directory. This chapter describes the access control mechanism.

This section includes the following topics:

To take full advantage of the power and flexiblity of the access control mechanism, while you are in the planning phase for your directory deployment, you should define an access control strategy as an integral part of your overall security policy. Refer to Red Hat Directory Server Deployment Guide for tips on planning your access control strategy.

Access Control Principles

The mechanism by which you define access is called access control. When the server receives a request, it uses the authentication information provided by the user in the bind operation and the access control instructions (ACIs) defined in the server to allow or deny access to directory information. The server can allow or deny permissions such as read, write, search, and compare. The permission level granted to a user may be dependent on the authentication information provided.

Using access control, you can control access to the entire directory, a subtree of the directory, specific entries in the directory (including entries defining configuration tasks), or a specific set of entry attributes. You can set permissions for a specific user, all users belonging to a specific group or role, or all users of the directory. Finally, you can define access for a specific location such as an IP address or a DNS name.

ACI Structure

Access control instructions are stored in the directory as attributes of entries. The aci attribute is an operational attribute; it is available for use on every entry in the directory, regardless of whether it is defined for the object class of the entry. It is used by the Directory Server to evaluate what rights are granted or denied when it receives an LDAP request from a client. The aci attribute is returned in an ldapsearch operation if specifically requested.

The three main parts of an ACI statement are:

The permission and bind rule portions of the ACI are set as a pair, also called an Access Control Rule (ACR). The specified permission is granted or denied depending on whether the accompanying rule is evaluated to be true.

ACI Placement

If an entry containing an ACI does not have any child entries, the ACI applies to that entry only. If the entry has child entries, the ACI applies to the entry itself and all entries below it. As a direct consequence, when the server evaluates access permissions to any given entry, it verifies the ACIs for every entry between the one requested and the directory suffix, as well as the ACIs on the entry itself.

The aci attribute is multi-valued, which means that you can define several ACIs for the same entry or subtree.

You can create an ACI on an entry that does not apply directly to that entry but to some or all of the entries in the subtree below it. The advantage of this is that you can place at a high level in the directory tree a general ACI that effectively applies to entries more likely to be located lower in the tree. For example, at the level of an organizationalUnit entry or a locality entry, you could create an ACI that targets entries that include the inetorgperson object class.

You can use this feature to minimize the number of ACIs in the directory tree by placing general rules at high level branch points. To limit the scope of more specific rules, you should place them as close as possible to leaf entries.

Note  

ACIs placed in the root DSE entry apply only to that entry.



ACI Evaluation

To evaluate the access rights to a particular entry, the server compiles a list of the ACIs present on the entry itself and on the parent entries back up to the top level entry stored on the Directory Server. ACIs are evaluated across all of the databases for a particular Directory Server but not across Directory Servers.

The evaluation of this list of ACIs is done based on the semantics of the ACIs, not on their placement in the directory tree. This means that ACIs that are close to the root of the directory tree do not take precedence over ACIs that are closer to the leaves of the directory tree.

The precedence rule that applies is that ACIs that deny access take precedence over ACIs that allow access. Between ACIs that allow access, union semantics apply, so there is no precedence.

For example, if you deny write permission at the directory's root level, then none of the users can write to the directory, regardless of the specific permissions you grant them. To grant a specific user write permissions to the directory, you have to restrict the scope of the original denial for write permission so that it does not include the user.

ACI Limitations

When creating an access control policy for your directory service, you need to be aware of the following restrictions:

Default ACIs

When you install the Directory Server, the following default ACIs apply to your directory information stored in the userRoot database:

Whenever you create a new database in the directory, the top entry has the default ACIs listed above.

The NetscapeRoot subtree has its own set of default ACIs:

The following sections explain how to modify these default settings to suit the needs of your organization.

Creating ACIs Manually

You can create access control instructions manually using LDIF statements and add them to your directory tree using the ldapmodify utility. The following sections explain in detail how to create the LDIF statements.

Tip  

LDIF ACI statements can be very complex. However, if you are setting access control for a large number of directory entries, using LDIF is the preferred method over using the Console because of the time it can save.

To familiarize yourself with LDIF ACI statements, however, you may want to use the Directory Server Console to set the ACI and then click the Edit Manually button on the Access Control Editor. This shows you the correct LDIF syntax. If your operating system allows it, you can even copy the LDIF from the Access Control Editor and paste it into your LDIF file.



The ACI Syntax

The aci attribute uses the following syntax:

aci: (target )(version 3.0;acl "name" ;permission  bind_rules ;)

where

You can have multiple permission-bind rule pairs for each target. This allows you to set multiple access controls for a given target efficiently. For example:

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

If you have several ACRs in one ACI statement, the syntax is of the form:

aci: (target )(version 3.0;acl "name" ;permission  bind_rule ; permission  bind_rule ; ... permission  bind_rule ;)

Example ACI

The following is an example of a complete LDIF ACI:

aci: (target="ldap:///uid=bjensen,dc=example,dc=com")(targetattr=*)
(version 3.0;acl "aci1";allow (write) userdn="ldap:///self";)

In this example, the ACI states that the user bjensen has rights to modify all attributes in her own directory entry.

The following sections describe the syntax of each portion of the ACI in more detail.

Defining Targets

The target identifies to what the ACI applies. If the target is not specified, the ACI applies to the entry containing the aci attribute and to the entries below it.

A target can be:

The general syntax for a target is:

(keyword  = "expression ")

(keyword  != "expression ")

where:

The quotation marks ("") around expression are required. What you use for expression is dependent upon the keyword that you supply.

The following table lists each keyword and the associated expressions:


Table 6-1    LDIF Target Keywords  


Keyword

Valid Expressions

Wildcard
Allowed?

target

ldap:///distinguished_name

yes

targetattr

attribute

yes

targetfilter

LDAP_filter

yes

targattrfilters

LDAP_operation:LDAP_filter

yes



In all cases, you must keep in mind that when you place an ACI on an entry, if it is not a leaf entry, the ACI also applies to all entries below it. For example, if you target the entry ou=accounting,dc=example,dc=com, the permissions you set will apply to all entries in the accounting branch of the example.com tree.

As a counter example, if you place an ACI on the ou=accounting,dc=example,dc=com entry, you cannot target the uid=sarette,ou=people,dc=example,dc=com entry because it is not located under the accounting tree.

Be wary of using != when specifying an attribute you want to deny. ACLs are logically ORed, which means that if you created two ACLs

acl1: ( target=...)( targetattr!=a )(version 3.0; acl "name";allow (...)..

acl2: ( target=...)( targetattr!=b )(version 3.0; acl "name";allow (...)..

the result would be to allow all values of the target attribute. The first ACL (acl1) will allow b and the second ACL (acl2) will allow a. The result of these two ACLs will be the same as the one resulting from using an ACL of the form:

acl3: ( targetattr="*" ) allow (...) ...

Notice that nothing is denied. This could give rise to security problems.

When you want to deny access to a particular attribute, use deny in the permissions clause rather than using allow with ( targetattr != value ). For example, usages such as these are recommended:

acl1: ( target=...)( targetattr=a )(version 3.0; acl "name";deny (...)..

acl2: ( target=...)( targetattr=b )(version 3.0; acl "name";deny (...)..

Targeting a Directory Entry

To target a directory entry (and the entries below it), you must use the target keyword.

The target keyword can accept a value of the following format:

target="ldap:///distinguished_name"

This identifies the distinguished name of the entry to which the access control rule applies. For example:

(target = "ldap:///uid=bjensen,dc=example,dc=com")

Note  

If the DN of the entry to which the access control rule applies contains a comma, you must escape the comma with a single backslash (\). For example:

(target="ldap:///uid=lfuentes,dc=example.com Bolivia\,S.A.")



You can also use a wildcard when targeting a distinguished name using the target keyword. The wildcard indicates that any character or string or substring is a match for the wildcard. Pattern matching is based on any other strings that have been specified with the wildcard.

The following are legal examples of wildcard usage:

Depending on the position of the wildcard, it can apply to the full DN, not only to attribute values. Therefore, the wildcard can be used as a substitute for portions of the DN. For example, uid=andy*,dc=example,dc=com targets all the directory entries in the entire example.com tree with a matching uid attribute and not just the entries that are immediately below the dc=example,dc=com node. In other words, this target matches with longer expressions such as uid=andy,ou=eng,dc=example,dc=com , or uid=andy,ou=marketing,dc=example,dc=com.

Some other valid examples follow:

Targeting Attributes

In addition to targeting directory entries, you can also target one or more attributes included in the targeted entries. This is useful when you want to deny or allow access to partial information about an entry. For example, you could allow access to only the common name, surname, and telephone number attributes of a given entry. Or you could deny access to sensitive information such as passwords.

You can specify that the target is equal or is not equal to a specific attribute. The attributes you supply do not need to be defined in the schema. This absence of schema checking makes it possible to implement an access control policy when you set up your directory service for the first time, even if the ACLs you create do not apply to the current directory content.

To target attributes, you use the targetattr keyword. The keyword uses the following syntax:

(targetattr = "attribute ")

You can target multiple attributes by using the targetattr keyword with the following syntax:

(targetattr = "attribute1  || attribute2  ... || attributen ")

Where attribute is the name of the attribute you want to target.

For example, to target the common name attribute you would use:

(targetattr = "cn")

To target an entry's common name, surname, and uid attributes, you would use the following:

(targetattr = "cn || sn || uid")

The attributes specified in the targetattr keyword apply to the entry that the ACI is targeting and to all the entries below it. If you target the password attribute on the entry uid=bjensen,ou=Marketing,dc=example,dc=com, only the password attribute on the bjensen entry is affected by the ACI because it is a leaf entry.

If, however, you target the tree's branch point ou=Marketing,dc=example,dc=com, then all the entries beneath the branch point that can contain a password attribute are affected by the ACI.

Targeting Both an Entry and Attributes

By default, the entry targeted by an ACI containing a targetattr keyword is the entry on which the ACI is placed. That is, if you put the ACI

aci: (targetattr = "uid")(access_control_rules ;)

on the ou=Marketing, dc=example,dc=com entry, then the ACI applies to the entire Marketing subtree. However, you can also explicitly specify a target using the target keyword as follows:

aci: (target="ldap:///ou=Marketing, dc=example,dc=com")(targetattr="uid") (access_control_rules ;)

The order in which you specify the target and the targetattr keywords is not important.

Targeting Entries or Attributes Using LDAP Filters

You can use LDAP filters to target a group of entries that match certain criteria. To do this, you must use the targetfilter keyword with an LDAP filter.

The syntax of the targetfilter keyword is:

(targetfilter = "LDAP_filter ")

where LDAP_filter is a standard LDAP search filter. For more information on the syntax of LDAP search filters, see Appendix B, "Finding Directory Entries."

For example, suppose that all entries in the accounting department include the attribute-value pair ou=accounting, and all entries in the engineering department include the attribute-value pair ou=engineering subtree. To target all the entries in the accounting and engineering branches of the directory tree, you could use the following filter:

(targetfilter = "(|(ou=accounting)(ou=engineering))")

This type of filter targets whole entries. You can associate the targetfilter and the targetattr keywords to create ACIs that apply to a subset of attributes in the targeted entries.

The following LDIF example allows members of the Engineering Admins group to modify the departmentNumber and manager attributes of all entries in the Engineering business category. This example uses LDAP filtering to select all entries with businessCategory attributes set to Engineering:

dn: dc=example,dc=com
objectClass: top
objectClass: organization
aci: (targetattr="departmentNumber || manager")
(targetfilter="(businessCategory=Engineering)")
(version 3.0; acl "eng-admins-write"; allow (write)
groupdn ="ldap:///cn=Engineering Admins, dc=example,dc=com";)

Tip  

Although using LDAP filters can be useful when you are targeting entries and attributes that are spread across the directory, the results are sometimes unpredictable because filters do not directly name the object for which you are managing access. The set of entries targeted by a filtered ACI is likely to change as attributes are added or deleted. Therefore, if you use LDAP filters in ACIs, you should verify that they target the correct entries and attributes by using the same filter in an ldapsearch operation.



Targeting Attribute Values Using LDAP Filters

You can use access control to target specific attribute values. This means that you can grant or deny permissions on an attribute if that attribute's value meets the criteria defined in the ACI. An ACI that grants or denies access based on an attribute's value is called a value-based ACI.

For example, you might grant all users in your organization permission to modify the nsRoleDN attribute in their own entry. However, you would also want to ensure that they do not give themselves certain key roles, such as "Top Level Administrator." LDAP filters are used to check that the conditions on attribute values are satisfied.

To create a value-based ACI, you must use the targattrfilters keyword with the following syntax:

(targattrfilters="add=attr1 : F1  && attr2 : F2 ... && attrn : Fn ,del=attr1 : F1  && attr2 : F2  ... && attrn : Fn ")

where:

When creating an entry, if a filter applies to an attribute in the new entry, then each instance of that attribute must satisfy the filter. When deleting an entry, if a filter applies to an attribute in the entry, then each instance of that attribute must also satisfy the filter.

When modifying an entry, if the operation adds an attribute, then the add filter that applies to that attribute must be satisfied; if the operation deletes an attribute, then the delete filter that applies to that attribute must be satisfied. If individual values of an attribute already present in the entry are replaced, then both the add and delete filters must be satisfied.

For example consider the following attribute filter:

(targattrfilters="add=nsroleDN:(!(nsRoleDN=cn=superAdmin)) && telephoneNumber:(telephoneNumber=123*)")

This filter can be used to allow users to add any role (nsRoleDN attribute) to their own entry, except the superAdmin role. It also allows users to add a telephone number with a 123 prefix.

Note  

You cannot create value-based ACIs from the Server Console.



Targeting a Single Directory Entry

Targeting a single directory entry is not straightforward because it goes against the design philosophy of the access control mechanism. However, it can be done:

You can use the targetattr keyword to specify an attribute that is only present in the entry you want to target, and not in any of the entries below your target. For example, if you want to target ou=people,dc=example,dc=com, and there aren't any organizational units (ou) defined below that node, you could specify an ACI that contains:

targetattr=ou

A safer method is to use the targetfilter keyword and to specify explicitly an attribute value that appears in the entry alone. For example, during the installation of the Directory Server, the following ACI is created:

aci: (targetattr="*")(targetfilter=(o=NetscapeRoot))(version 3.0; acl "Default anonymous access"; allow (read, search) userdn="ldap:///anyone";)

This ACI can apply only to the o=NetscapeRoot entry.

The risk associated with these method is that your directory tree might change in the future, and you would have to remember to modify this ACI.

Defining Permissions

Permissions specify the type of access you are allowing or denying. You can either allow or deny permission to perform specific operations in the directory. The various operations that can be assigned are known as rights.

There are two parts to setting permissions:

Allowing or Denying Access

You can either explicitly allow or deny access permissions to your directory tree. For more guidelines on when to allow and when to deny access, refer to the Red Hat Directory Server Deployment Guide.

Note  

From the Server Console, you cannot explicitly deny access, only grant permissions.



Assigning Rights

Rights detail the specific operations a user can perform on directory data. You can allow or deny all rights, or you can assign one or more of the following rights:

Rights are granted independently of one another. This means, for example, that a user who is granted add rights can create an entry but cannot delete it if delete rights have not been specifically granted. Therefore, when planning the access control policy for your directory, you must ensure that you grant rights in a way that makes sense for users. For example, it doesn't usually make sense to grant write permission without granting read and search permissions.

Note  

The proxy mechanism is very powerful and must be used sparingly. Proxy rights are granted within the scope of the ACL, and there is no way to restrict who an entry that has the proxy right can impersonate—that is, when you grant a user proxy rights, that user has the ability to proxy for any user under the target; there is no way to restrict the proxy rights to only certain users. For example, if an entity has proxy rights to the dc=example,dc=com tree, that entity can do anything. So, make sure you set the proxy ACI at the lowest possible level of the DIT; see "Proxied Authorization ACI Example".

For a general overview, see "Proxy Authentication" in chapter 7, "Designing a Secure Directory," in the Red Hat Directory Server Deployment Guide.



Rights Required for LDAP Operations

This section describes the rights you need to grant to users depending on the type of LDAP operation you want to authorize them to perform.

The permissions you need to set up to allow users to search the directory are more readily understood with an example. Consider the following ldapsearch operation:

% ldapsearch -h host  -s base  -b "uid=bjensen,dc=example,dc=com" objectclass=* mail

The following ACI is used to determine whether user bkolics can be granted access:

aci: (targetattr = "mail")(version 3.0; acl "self access to mail"; allow (read, search) userdn = "ldap:///self";)

The search result list is empty because this ACI does not grant access to the objectclass attribute. If you want the search operation described above to be successful, you must modify the ACI to read as follows:

aci: (targetattr = "mail || objectclass")(version 3.0; acl "self access to mail"; allow (read, search) userdn = "ldap:///self";)

Permissions Syntax

In an ACI statement, the syntax for permissions is:

allow|deny (rights )

where rights is a list of 1 to 8 comma-separated keywords enclosed within parentheses. Valid keywords are read, write, add, delete, search, compare, selfwrite, proxy, or all.

In the following example, read, search, and compare access is allowed, provided the bind rule is evaluated to be true:

aci: (target="ldap:///dc=example,dc=com") (version 3.0;acl "example"; allow (read, search, compare) bind_rule ;)

Access Control and the modrdn Operation

To explicitly deny modrdn rights using ACIs, you must target the relevant entries but omit the targetattr keyword. For example, to prevent the cn=helpDeskGroup,ou=groups,o=example.com group from renaming any entries in the set specified by the pattern cn=*,ou=people,o=example.com, you would add the following ACI:

aci: (target="ldap:///cn=*,ou=people,o=example.com")
(version 3.0; acl "Deny modrdn rights to the helpDeskGroup";
deny(write) groupdn="ldap:///cn=helpDeskGroup,ou=groups,o=example.com";)

Bind Rules

Depending on the ACIs defined for the directory, for certain operations, you need to bind to the directory. Binding means logging in or authenticating yourself to the directory by providing a bind DN and password, or, if using SSL, a certificate. The credentials provided in the bind operation and the circumstances of the bind determine whether access to the directory is allowed or denied.

Every permission set in an ACI has a corresponding bind rule that details the required credentials and bind parameters.

Bind rules can be simple. For example, a bind rule can simply state that the person accessing the directory must belong to a specific group. Bind rules can also be more complex. For example, a bind rule can state that a person must belong to a specific group and must log in from a machine with a specific IP address, between 8 a.m. and 5 p.m.

Bind rules define who can access the directory, when, and from where. More specifically, bind rules can specify:

Additionally, bind rules can be complex constructions that combine these criteria by using Boolean operators. See "Using Boolean Bind Rules", for more information.

Bind Rule Syntax

Whether access is allowed or denied depends on whether an ACI's bind rule is evaluated to be true. Bind rules use one of the two following patterns:

keyword  = "expression ";

keyword  != "expression ";

where equal (=) indicates that keyword and expression must match in order for the bind rule to be true, and not equal (!=) indicates that keyword and expression must not match in order for the bind rule to be true.

Note  

The timeofday keyword also supports the inequality expressions (<, <=, >, >=). This is the only keyword that supports these expressions.



The quotation marks ("") around expression and the delimiting semicolon (;) are required. The expressions you can use depend on the associated keyword.

The following table lists each keyword and the associated expressions. It also indicates whether wildcard characters are allowed in the expression.


Table 6-2    LDIF Bind Rule Keywords  


Keyword

Valid Expressions

Wildcard Allowed?

userdn

ldap:///distinguished_name

ldap:///all

ldap:///anyone

ldap:///self

ldap:///parent

ldap:///suffix??sub?(filter)

yes, in DN only

groupdn

ldap:///DN || DN

no

roledn

ldap:///DN || DN

no

userattr

attribute#bindType or

attribute#value

no

ip

IP_address

yes

dns

DNS_host_name

yes

dayofweek

sun
mon
tue
wed
thu
fri
sat

no

timeofday

0 - 2359

no

authmethod

none

simple

ssl

sasl authentication_method

no



The sections that follow contain further detail on bind rule syntax for each keyword.

Defining User Access - userdn Keyword

User access is defined using the userdn keyword. The userdn keyword requires one or more valid distinguished names in the following format :

userdn = "ldap:///dn  [|| ldap:///dn ]...[||ldap:///dn ]"

where dn can be a DN or one of the expressions anyone, all, self, or parent:

userdn = "ldap:///anyone" - defines anonymous access

userdn = "ldap:///all" - defines general access

userdn = "ldap:///self" - defines self access

userdn = "ldap:///parent" - defines access for the parent entry

The userdn keyword can also be expressed as an LDAP filter of the form:

ldap:///suffix ??sub?(filter )

Note  

If a DN contains a comma, the comma must be preceded by a backslash (\) escape character.



Anonymous Access (anyone Keyword)

Granting anonymous access to the directory means that anyone can access it without providing a bind DN or password and regardless of the circumstances of the bind. You can limit anonymous access to specific types of access (for example, access for read or access for search) or to specific subtrees or individual entries within the directory.

From the Server Console, you define anonymous access through the Access Control Editor. See "Creating ACIs from the Console".

General Access (all Keyword)

You can use bind rules to indicate that a permission applies to anyone who has successfully bound to the directory; that is, all authenticated users. This allows general access while preventing anonymous access.

From the Server Console, you define general access on the Access Control Editor. For more information, see "Creating ACIs from the Console".

Self Access (self Keyword)

Specifies that users are granted or denied access to their own entries. In this case, access is granted or denied if the bind DN matches the DN of the targeted entry.

From the Server Console, you set up self access on the Access Control Editor. For more information, see "Creating ACIs from the Console".

Parent Access (parent Keyword)

Specifies that users are granted or denied access to the entry only if their bind DN is the parent of the targeted entry.

You cannot set up parent access control using the Server Console.

LDAP URLs

You can dynamically target users in ACIs using a URL with a filter as follows:

userdn = "ldap:///suffix ??sub?(filter )"

For example, all users in the accounting and engineering branches of the example.com tree would be granted or denied access to the targeted resource dynamically based on the following URL:

userdn = "ldap:///dc=example,dc=com??sub?(|(ou=engineering)
(ou=accounting))"

Note  

Do not specify a hostname or port number within the LDAP URL. LDAP URLs always apply to the local server.



For more information about LDAP URLs, see Appendix C, "LDAP URLs."

Wildcards

You can also specify a set of users by using the wildcard character (*). For example, specifying a user DN of uid=u*,dc=example,dc=com indicates that only users with a bind DN beginning with the letter u will be allowed or denied access based on the permissions you set.

From the Server Console, you set user access from the Access Control Editor. For more information, see "Creating ACIs from the Console".

Examples

This section contains examples of the userdn syntax.

Defining Group Access - groupdn Keyword

Members of a specific group can access a targeted resource. This is known as group access. Group access is defined using the groupdn keyword to specify that access to a targeted entry will be granted or denied if the user binds using a DN that belongs to a specific group.

The groupdn keyword requires one or more valid distinguished names in the following format :

groupdn="ldap:///dn  [|| ldap:///dn ]...[|| ldap:///dn ]"

The bind rule is evaluated to be true if the bind DN belongs to the named group.

Note  

If a DN contains a comma, the comma must be escaped by a backslash (\).



From the Server Console, you can define specific groups using the Access Control Editor. For more information, see "Creating ACIs from the Console".

Examples

This section contains examples of the groupdn syntax.

Defining Role Access - roledn Keyword

Members of a specific role can access a targeted resource. This is known as role access. Role access is defined using the roledn keyword to specify that access to a targeted entry will be granted or denied if the user binds using a DN that belongs to a specific role.

The roledn keyword requires one or more valid distinguished names in the following format :

roledn = "ldap:///dn  [|| ldap:///dn ]... [|| ldap:///dn ]"

The bind rule is evaluated to be true if the bind DN belongs to the specified role.

Note  

If a DN contains a comma, the comma must be escaped by a backslash (\).



The roledn keyword has the same syntax and is used in the same way as the groupdn keyword.

Defining Access Based on Value Matching

You can set bind rules to specify that an attribute value of the entry used to bind to the directory must match an attribute value of the targeted entry.

For example, you can specify that the bind DN must match the DN in the manager attribute of a user entry in order for the ACI to apply. In this case, only the user's manager would have access to the entry.

This example is based on DN matching. However, you can match any attribute of the entry used in the bind with the targeted entry. For example, you could create an ACI that allowed any user whose favoriteDrink attribute is beer to read all the entries of other users that have the same value for favoriteDrink.

Using the userattr Keyword

The userattr keyword can be used to specify which attribute values must match between the entry used to bind and the targeted entry. You can specify:

The LDIF syntax of the userattr keyword is as follows:

userattr = "attrName # bindType"

or, if you are using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter:

userattr = "attrName # attrValue"

where:

The following sections provide examples of the userattr keyword with the various possible bind types.

Example with USERDN Bind Type

The following is an example of the userattr keyword associated with a bind based on the user DN:

userattr = "manager#USERDN"

The bind rule is evaluated to be true if the bind DN matches the value of the manager attribute in the targeted entry. You can use this to allow a user's manager to modify employees' attributes. This mechanism only works if the manager attribute in the targeted entry is expressed as a full DN.

The following example grants a manager full access to his or her employees' entries:

aci: (target="ldap:///dc=example,dc=com")(targetattr=*) (version 3.0;
acl "manager-write"; allow (all) userattr = "manager#USERDN";)

Example with GROUPDN Bind Type

The following is an example of the userattr keyword associated with a bind based on a group DN:

userattr = "owner#GROUPDN"

The bind rule is evaluated to be true if the bind DN is a member of the group specified in the owner attribute of the targeted entry. For example, you can use this mechanism to allow a group to manage employees' status information. You can use an attribute other than owner as long as the attribute you use contains the DN of a group entry.

The group you point to can be a dynamic group, and the DN of the group can be under any suffix in the database. However, the evaluation of this type of ACI by the server is very resource intensive.

If you are using static groups that are under the same suffix as the targeted entry, you can use the following expression:

userattr = "ldap:///dc=example,dc=com?owner#GROUPDN"

In this example, the group entry is under the dc=example,dc=com suffix. The server can process this type of syntax more quickly than the previous example.

(By default, owner is not an allowed entry in a user's entry. You would have to extend your schema to allow this attribute in a person object.)

Example with ROLEDN Bind Type

The following is an example of the userattr keyword associated with a bind based on a role DN:

userattr = "exampleEmployeeReportsTo#ROLEDN"

The bind rule is evaluated to be true if the bind DN belongs to the role specified in the exampleEmployeeReportsTo attribute of the targeted entry. For example, if you create a nested role for all managers in your company, you can use this mechanism to grant managers at all levels access to information about employees that are at a lower grade than themselves.

Note  

This example assumes that you have added the exampleEmployeeReportsTo attribute to the schema and that all employee entries contain this attribute. It also assumes that the value of this attribute is the DN of a role entry.

For information on designing your schema, refer to Red Hat Directory Server Deployment Guide. For information on adding attributes to the schema, see "Creating Attributes".



The DN of the role can be under any suffix in the database. If, in addition, you are using filtered roles, the evaluation of this type of ACI uses a lot of resources on the server.

If you are using a static role definition and the role entry is under the same suffix as the targeted entry, you can use the following expression:

userattr = "ldap:///dc=example,dc=com?employeeReportsTo#ROLEDN"

In this example, the role entry is under the dc=example,dc=com suffix. The server can process this type of syntax more quickly than the previous example.

Example with LDAPURL Bind Type

The following is an example of the userattr keyword associated with a bind based on an LDAP filter:

userattr = "myfilter # LDAPURL"

The bind rule is evaluated to be true if the bind DN matches the filter specified in the myfilter attribute of the targeted entry. The myfilter attribute can be replaced by any attribute that contains an LDAP filter.

Example with Any Attribute Value

The following is an example of the userattr keyword associated with a bind based on any attribute value:

userattr = "favoriteDrink#Beer"

The bind rule is evaluated to be true if the bind DN and the target DN include the favoriteDrink attribute with a value of Beer.

Using the userattr Keyword with Inheritance

When you use the userattr keyword to associate the entry used to bind with the target entry, the ACI applies only to the target specified and not to the entries below it. In some circumstances, you might want to extend the application of the ACI several levels below the targeted entry. This is possible by using the parent keyword and specifying the number of levels below the target that should inherit the ACI.

When you use the userattr keyword in association with the parent keyword, the syntax is as follows:

userattr = "parent[ inheritance_level ].attrName # bindType"

or, if you are using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter:

userattr = "parent[ inheritance_level ].attrName#attrValue"

where:

For example,

userattr = "parent[0, 1].manager#USERDN"

This bind rule is evaluated to be true if the bindDN matches the manager attribute of the targeted entry. The permissions granted when the bind rule is evaluated to be true apply to the target entry and to all entries immediately below it.

Example with userattr Inheritance

The example in Figure 6-1 indicates that user bjensen is allowed to read and search the cn=Profiles entry as well as the first level of child entries which includes cn=mail and cn=news, thus allowing her to search through her own mail and news IDs.

Figure 6-1    Using Inheritance With the userattr Keyword

In this example, if you did not use inheritance, you would have to do one of the following to achieve the same result:

Granting Add Permission Using the userattr Keyword

If you use the userattr keyword in conjunction with all or add permissions, you might find that the behavior of the server is not what you expect. Typically, when a new entry is created in the directory, Directory Server evaluates access rights on the entry being created and not on the parent entry. However, in the case of ACIs using the userattr keyword, this behavior could create a security hole, and the server's normal behavior is modified to avoid it.

Consider the following example:

aci: (target="ldap:///dc=example,dc=com")(targetattr=*) (version 3.0;
acl "manager-write"; allow (all) userattr = "manager#USERDN";)

This ACI grants managers all rights on the entries of employees that report to them. However, because access rights are evaluated on the entry being created, this type of ACI would also allow any employee to create an entry in which the manager attribute is set to their own DN. For example, disgruntled employee Joe (cn=Joe,ou=eng,dc=example,dc=com) might want to create an entry in the Human Resources branch of the tree to use (or misuse) the privileges granted to Human Resources employees.

He could do this by creating the following entry:

dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com
objectclass: top
...
cn: Trojan Horse
manager: cn=Joe,ou=eng,dc=example,dc=com

To avoid this type of security threat, the ACI evaluation process does not grant add permission at level 0, to the entry itself. You can, however, use the parent keyword to grant add rights below existing entries. You must specify the number of levels below the parent for add rights. For example, the following ACI allows child entries to be added to any entry in the dc=example,dc=com that has a manager attribute that matches the bind DN:

aci: (target="ldap:///dc=example,dc=com")(targetattr=*)
(version 3.0; acl "parent-access"; allow (add)
userattr = "parent[0,1].manager#USERDN";)

This ACI ensures that add permission is granted only to users whose bind DN matches the manager attribute of the parent entry.

Defining Access from a Specific IP Address

Using bind rules, you can indicate that the bind operation must originate from a specific IP address. This is often used to force all directory updates to occur from a given machine or network domain.

The LDIF syntax for setting a bind rule based on an IP address is ip = "IP_address" or ip != "IP_address".

The IP address must be expressed in dot notation.You can use the wildcard character (*) to include multiple machines. For example, the following string is valid:

ip = "12.123.1.*";

The bind rule is evaluated to be true if the client accessing the directory is located at the named IP address. This can be useful for allowing certain kinds of directory access only from a specific subnet or machine.

For example, you could use a wildcard IP address such as 12.3.45.* to specify a specific subnetwork or 123.45.6.*+255.255.255.115 to specify a subnetwork mask.

From the Server Console, you can define specific machines to which the ACI applies through the Access Control Editor. For more information, see "Creating ACIs from the Console".

Defining Access from a Specific Domain

A bind rule can specify that the bind operation must originate from a particular domain or host machine. This is often used to force all directory updates to occur from a given machine or network domain.

The LDIF syntax for setting a bind rule based on the DNS hostname is dns = "DNS_Hostname" or dns != "DNS_Hostname".

Caution  

The dns keyword requires that the naming service used on your machine is DNS. If the name service is not DNS, you should use the ip keyword instead.



The dns keyword requires a fully qualified DNS domain name. Granting access to a host without specifying the domain creates a potential security threat. For example, the following expression is allowed but not recommended:

dns = "legend.eng";

You should use a fully qualified name such as:

dns = "legend.eng.example.com";

The dns keyword allows wildcards. For example:

dns = "*.example.com";

The bind rule is evaluated to be true if the client accessing the directory is located in the named domain. This can be useful for allowing access only from a specific domain. Wildcards will not work if your system uses a naming service other than DNS. In such a case, if you want to restrict access to a particular domain, use the ip keyword, as described in "Defining Access from a Specific IP Address".

Defining Access at a Specific Time of Day or Day of Week

You can use bind rules to specify that binding can only occur at a certain time of day or on a certain day of the week. For example, you can set a rule that will allow access only if it is between the hours of 8 a.m. and 5 p.m. Monday through Friday. The time used to evaluate access rights is the time on the Directory Server, not the time on the client.

The LDIF syntax for setting a bind rule based on the time of day is as follows:

timeofday operator "time"

where operator can be one of the following symbols: equal to (=), not equal to (!=), greater than (>), greater than or equal to (>=), less than (<), or less than or equal to (<=).

The timeofday keyword requires a time of day expressed in hours and minutes in the 24 hour clock (0 to 2359).

Note  

The time on the server is used for the evaluation, not the time on the client.



The LDIF syntax for setting a bind rule based on the day in the week is as follows:

dayofweek = "day1, day2 ..."

The possible values for the dayofweek keyword are the English three-letter abbreviations for the days of the week: sun, mon, tue, wed, thu, fri, sat.

Examples

The following are examples of the timeofday and dayofweek syntax:

timeofday = "1200";

The bind rule is evaluated to be true if the client is accessing the directory at noon.
 

timeofday != "0100";

The bind rule is evaluated to be true if the client is accessing the directory at any time other than 1 a.m.
 

timeofday > "0800";

The bind rule is evaluated to be true if the client is accessing the directory at any time after 8 a.m.
 

timeofday < "1800";

The bind rule is evaluated to be true if the client is accessing the directory at any time before 6 p.m.
 

timeofday >= "0800";

The bind rule is evaluated to be true if the client is accessing the directory at 8 a.m. or later.
 

timeofday <= "1800";

The bind rule is evaluated to be true if the client is accessing the directory at 6 p.m. or earlier.
 

dayofweek = "Sun, Mon, Tue";

The bind rule is evaluated to be true if the client is accessing the directory on Sunday, Monday, or Tuesday.
 

Defining Access Based on Authentication Method

You can set bind rules that state that a client must bind to the directory using a specific authentication method. The authentication methods available are:

You cannot set up authentication-based bind rules through the Access Control Editor.

The LDIF syntax for setting a bind rule based on an authentication method is as follows:

authmethod = "authentication_method"

where authentication_method is none, simple, ssl, or "sasl sasl_mechanism".

Examples

The following are examples of the authmethod keyword:

authmethod = "none";

Authentication is not checked during bind rule evaluation.
 

authmethod = "simple";

The bind rule is evaluated to be true if the client is accessing the directory using a username and password.
 

authmethod = "ssl";

The bind rule is evaluated to be true if the client authenticates to the directory using a certificate over LDAPS. This is not evaluated to be true if the client authenticates using simple authentication (bind DN and password) over LDAPS.
 

authmethod = "sasl DIGEST-MD5";

The bind rule is evaluated to be true if the client is accessing the directory using the SASL DIGEST-MD5 mechanism. The other supported SASL mechanisms are EXTERNAL and GSS-API.
 

Using Boolean Bind Rules

Bind rules can be complex expressions that use the Boolean expressions AND, OR, and NOT to set very precise access rules. You cannot use the Server Console to create Boolean bind rules. You must create an LDIF statement.

The LDIF syntax for a Boolean bind rule is as follows:

bind_rule  [ boolean ][ bind_rule ][ boolean ][ bind_rule ]...;)

For example, the following bind rule will be evaluated to be true if the bind DN is a member of either the administrator's group or the mail administrator's group and if the client is running from within the example.com domain:

(groupdn = "ldap:///cn=administrators,dc=example,dc=com" or groupdn = "ldap:///cn=mail administrators,dc=example,dc=com" and dns = "*.example.com";)

The trailing semicolon (;) is a required delimiter that must appear after the final bind rule.

Boolean expressions are evaluated in the following order:

The Boolean OR and Boolean AND operators have no order of precedence.

Consider the following Boolean bind rules:

(bind_rule_A ) OR (bind_rule_B )

(bind_rule_B ) OR (bind_rule_A )

Because Boolean expressions are evaluated from left to right, in the first case, bind rule A is evaluated before bind rule B, and, in the second case, bind rule B is evaluated before bind rule A.

However, the Boolean NOT is evaluated before the Boolean OR and Boolean AND. Thus, in the following example

(bind_rule_A ) AND NOT (bind_rule_B )

bind rule B is evaluated before bind rule A despite the left-to-right rule.

Creating ACIs from the Console

You can use the Directory Server Console to view, create, edit, and delete access control instructions for your directory. This section provides general instructions for:

See "Access Control Usage Examples", for a collection of access control rules commonly used in Directory Server security policies, along with step-by-step instructions for using the Directory Server Console to create them.

The Access Control Editor does not enable you to construct some of the more complex ACIs when you are in Visual editing mode. In particular, from the Access Control Editor you cannot:

Displaying the Access Control Editor

  1. Start the Directory Server Console. Log in using the bind DN and password of a privileged user, such as the Directory Manager, who has write access to the ACIs configured for the directory.
    2. For instructions, refer to "Using the Directory Server Console".
     
  2. In the Directory Server Console, select the Directory tab.
  3. Right-click the entry in the navigation tree for which you want to set access control, and select Set Access Permissions from the pop-up menu (Figure 6-2).
    4. Or highlight the entry, and select Set Access Permissions from the Object menu.
     

Figure 6-2    Selecting an Object in the Navigation Tree to Set Access Control

  1. Click New.
    2. The Access Control Editor is displayed as shown in Figure 6-3.
     

Figure 6-3    Access Control Editor Window

For information on navigating through the Access Control dialog boxes, refer to the online help.

Viewing Current ACIs

If you want to see what ACIs apply to a particular subtree in your directory, follow these steps:

  1. In the Directory tab, right-click the top entry in the subtree, and choose Set Access Permissions from the pop-up menu.
    2. The Access Control Manager window is displayed. It contains the list of ACIs belonging to the entry.
     
  2. Check the checkbox for Show Inherited ACIs if you want to display the full list of ACIs that apply to the entry.

Creating a New ACI

To create a new ACI:

  1. Display the Access Control Editor.
    2. This task is explained in "Displaying the Access Control Editor".
     
    If the view displayed is different from Figure 6-3, click the Edit Visually button.
     
  2. Name the ACI by typing a name in the ACI Name text box.
    3. The name can be any string you want to use to identify uniquely the ACI. If you do not enter a name, the server uses unnamed ACI.
     
  3. In the Users/Groups tab, select the users to whom you are granting access by highlighting All Users or clicking the Add button to search the directory for the users to add.
    4. In the Add Users and Groups window:
     
    1. Select a search area from the drop-down list, enter a search string in the Search field, and click the Search button.
      2. The search results are displayed in the list below.
       
    2. Highlight the entries you want in the search result list, and click the Add button to add them to the list of entries which have access permission.
    3. Click OK to dismiss the Add Users and Groups window.
      4. The entries you selected are now listed on the Users/Groups tab in the ACI editor.
       
  4. In the Access Control Editor, click the Rights tab, and use the checkboxes to select the rights to grant.
  5. Click the Targets tab, then click This Entry to display the node targeted by the ACI.
    6. You can change the value of the target DN, but the new DN must be a direct or indirect child of the selected entry.
     
    If you do not want every entry in the subtree under this node to be targeted by the ACI, you must enter a filter in the Filter for Sub-entries field.
     
    Additionally, you can restrict the scope of the ACI to only certain attributes by selecting the attributes you want to target in the attribute list.
     
  6. Click the Hosts tab, then the Add button, to display the Add Host Filter dialog box.
    7. You can specify a hostname or an IP address. If you specify an IP address, you can use the wildcard character (*).
     
  7. Click the Times tab to display the table showing at what times access is allowed.
    8. By default, access is allowed at all times. You can change the access times by clicking and dragging the cursor over the table. You cannot select discrete blocks of time.
     
  8. When you have finished editing the ACI, click OK.
    9. The ACI Editor is dismissed, and the new ACI is listed in the ACI Manager window.
     

    Note  

    At any time during the creation of the ACI, you can click the Edit Manually button to display the LDIF statement that corresponds to your input. You can modify this statement, but your changes will not necessarily be visible in the graphical interface.



Editing an ACI

To edit an ACI:

  1. In the Directory tab, right-click the