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"; or keyword != "expression";

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.

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

Table 6.3, “LDIF Bind Rule Keywords” lists each keyword and the associated expressions and indicates whether wildcard characters are allowed in the expression.

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]"

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:

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

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

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

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

From the Directory Server Console, you can define specific groups using the Access Control Editor. For more information, see Section 6.5, “Creating ACIs from the Console”.

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

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

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.

6.4.5.1. 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 any of the following:

• A user DN

• A group DN

• A role DN

• An LDAP filter, in an LDAP URL

• Any attribute type

The LDIF syntax of the userattr keyword is as follows:

userattr = "attrName#bindType

Using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter has the following format:

userattr = "attrName#attrValue

• attrName is the name of the attribute used for value matching.

• bindType is either USERDN, GROUPDN, or LDAPURL.

• attrValue is any string representing an attribute value.

6.4.5.1.1. Example with USERDN Bind Type

The following associates the userattr keyword 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";)

6.4.5.1.2. Example with GROUPDN Bind Type

The following associates the userattr keyword 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.)

6.4.5.1.3. Example with ROLEDN Bind Type

The following associates the userattr keyword 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 exampleEmployeeReportsToattribute 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 adding attributes to the schema, see Section 9.2.2, “Creating Attributes”.

The DN of the role can be under any suffix in the database. If you are also 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.

6.4.5.1.4. Example with LDAPURL Bind Type

The following associates the userattr keyword 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.

6.4.5.1.5. Example with Any Attribute Value

The following associates the userattr keyword 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.

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

Using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter, the syntax is as follows:

userattr = "parent[inheritance_level].attrName#attrValue

• inheritance_level is a comma-separated list that indicates how many levels below the target inherits the ACI. You can include five levels (0, 1, 2, 3, 4) below the targeted entry; zero (0) indicates the targeted entry.

• attribute is the attribute targeted by the userattr or groupattr keyword.

• bindType can be one of USERDN, GROUPDN, or LDAPURL.

For example:

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

This bind rule is evaluated to be true if the bind DN 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.

The example in Figure 6.1, “Using Inheritance With the userattr Keyword” 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:

• Explicitly set read and search access for user bjensen on the cn=Profiles, cn=mail, and cn=news entries in the directory.

• Add the owner attribute with a value of bjensen to the cn=mail and cn=news entries, and then add the following ACI to the cn=mail and cn=news entries.

  aci: (targetattr="*") (version 3.0; acl "profiles access"; allow (read,search) 
       userattr="owner#USERDN";)
  

6.4.5.1.7. Granting Add Permission Using the userattr Keyword

Using the userattr keyword in conjunction with all or add permissions does not behave as one would typically 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.

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 as follows:

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, 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 Directory Server Console, you can define specific machines to which the ACI applies through the Access Control Editor. For more information, see Section 6.5, “Creating ACIs from the Console”.

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 as follows:

dns = "DNS_Hostname or dns != "DNS_Hostname

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

Instead, use a fully qualified name:

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 Section 6.4.6, “Defining Access from a Specific IP Address”.

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 allows 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

operator can be one of the following symbols:

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

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.

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

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

authmethod = "sasl_mechanism

sasl_mechanism can be none, simple, ssl, or "sasl  sasl_mechanism".

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 Directory 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, this bind rule is 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:

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 B is evaluated before bind rule A despite the left-to-right rule.

(bind_rule_A) AND NOT (bind_rule_B)