13.4. 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 credentials (for example, a keytab for SASL or a client certificate for SSL). 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, such as stating that the person accessing the directory must belong to a specific group. Bind rules can also be more complex, such as requiring that a person must belong to a specific group, must log in from a machine with a specific IP address, and is restricted to access between 8 a.m. and 5 p.m.
Bind rules define who can access the directory, when, and from where by defining any of the following:
  • Users, groups, and roles that are granted access.
  • Locations from which an entity must bind.
  • Times or days on which binding must occur.
  • Types of authentication that must be in use during binding.
Additionally, bind rules can be complex constructions that combine these criteria by using Boolean operators. See Section 13.4.11, “Using Boolean Bind Rules” for more information.

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

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.
Table 13.3, “LDIF Bind Rule Keywords” lists each keyword and the associated expressions and indicates whether wildcard characters are allowed in the expression.

Table 13.3. LDIF Bind Rule Keywords

Keyword Valid Expressions Wildcard Allowed
userdn
ldap:///distinguished_name
ldap:///all
ldap:///anyone
ldap:///self
ldap:///parent
ldap:///suffix??scope?(filter)
 Yes, in DN only
groupdn
ldap:///DN|| DN
ldap:///suffix??scope?(filter)
 No
roledn ldap:///DN|| DN No
userattr attribute#bindType orattribute#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 sasl_mechanism
 No

13.4.2. 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]"
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)

Note

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

13.4.2.1. 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, read or search access) or to specific subtrees or individual entries within the directory.
From the Directory Server Console, you define anonymous access through the Access Control Editor. See Section 13.5, “Creating ACIs from the Console”.

13.4.2.2. 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 Directory Server Console, you define general access on the Access Control Editor. For more information, see Section 13.5, “Creating ACIs from the Console”.

13.4.2.3. 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.
Self access can be configured in the Access Control Editor in the Directory Server Console. For more information, see Section 13.5, “Creating ACIs from the Console”.

13.4.2.4. 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 Directory Server Console.

13.4.2.5. LDAP URLs

You can dynamically target users in ACIs using a URL with an LDAP filter: 
userdn = "ldap:///suffix??scope?(filter)"
For example, all users in the accounting and engineering branches of the example 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 host name or port number within the LDAP URL. LDAP URLs always apply to the local server.
It is possible to string multiple LDAP URLs together so that the bind user must match both filter A and filter B. This is done by using multiple userdn keyword definitions. For example: 
userdn="ldap:///dc=example,dc=com??sub?(ou=engineering)" and userdn="ldap:///dc=example,dc=com??sub?(manager="uid=bjensen,ou=managers,dc=example,dc=com")"
Using a connector such as && is not allowed. For example, this is not an acceptable bind rule: 
groupdn="ldap:///dc=example,dc=com??sub?(ou=engineering) && ldap:///dc=example,dc=com??sub?(manager="uid=bjensen,ou=managers,dc=example,dc=com")"
For more information about LDAP URLs, see Appendix C, LDAP URLs.

13.4.2.6. 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 are allowed or denied access based on the permissions you set.
From the Directory Server Console, you set user access from the Access Control Editor. For more information, see Section 13.5, “Creating ACIs from the Console”.

13.4.2.7. Examples

Table 13.4. userdn Keyword Examples

Scenario Example Description
Userdn keyword containing an LDAP URL userdn = "ldap:///uid=*,dc=example,dc=com"; The bind rule is evaluated to be true if the user binds to the directory using any distinguished name of the specified pattern. For example, both of the following bind DNs would be evaluated to be true:
uid=ssarette,dc=example,dc=com
uid=tjaz,ou=Accounting,dc=example,dc=com
This bind DN would be evaluated to be false:
cn=Babs Jensen,dc=example,dc=com
Userdn keyword containing logical OR of LDAP URLs userdn="ldap:///uid=bj,dc=example,dc=com || ldap:///uid=kc,dc=example,dc=com"; The bind rule is evaluated to be true if the client binds as either of the two supplied distinguished names.
Userdn keyword excluding a specific LDAP URL userdn != "ldap:///uid=*,ou=Accounting,dc=example,dc=com"; The bind rule is evaluated to be true if the client is not binding as a UID-based distinguished name in the accounting subtree. This bind rule only makes sense if the targeted entry is not under the accounting branch of the directory tree.
Userdn keyword containing self keyword userdn = "ldap:///self";
The bind rule is evaluated to be true if the user is accessing the entry represented by the DN with which the user bound to the directory. That is, if the user has bound as uid=ssarette, dc=example,dc=com and the user is attempting an operation on the uid=ssarette,dc=example,dc=com entry, then the bind rule is true.
If you want to grant all users in the example tree write access to their userPassword attribute, you would create the following ACI on the dc=example,dc=com node.
aci: (targetattr = "userPassword") (version 3.0; acl "write-self"; allow (write) userdn = "ldap:///self";)
Userdn keyword containing the all keyword userdn = "ldap:///all";
The bind rule is evaluated to be true for any valid bind DN. To be true, a valid distinguished name must be presented by the user for a successful bind operation.
For example, if you want to grant read access to the entire tree to all authenticated users, you would create the following ACI on the dc=example,dc=com node:
aci:(version 3.0; acl "all-read"; allow (read) userdn="ldap:///all";)
Userdn keyword containing the anyone keyword userdn = "ldap:///anyone";
The bind rule is evaluated to be true for anyone; use this keyword to provide anonymous access to your directory.
For example, if you want to allow anonymous read and search access to the entire example tree, you would create the following ACI on the dc=example,dc=com node:
aci: (version 3.0; acl "anonymous-read-search"; allow (read,search) userdn = "ldap:///anyone";)
Userdn keyword containing the parent keyword userdn = "ldap:///parent";
The bind rule is evaluated to be true if the bind DN is the parent of the targeted entry.
For example, if you want to grant write access to every user's child entries, you would create the following ACI on the dc=example,dc=com node:
aci:(version 3.0; acl "parent access"; allow (write) userdn="ldap:///parent";)

13.4.3. 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 is granted or denied if the user binds using a DN that belongs to a specific group.
Group membership can be determined based on the user's DN or by using an LDAP filter to search for group members.
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 (\).
The groupdn keyword can also be expressed with an LDAP filter: 
groupdn="ldap:///suffix??scope?(filter)
With more complex groupdn syntax, the value of the groupdn expression is a single LDAP URL. Multiple groupdns can be grouped together within parentheses and use or or and connectors to define additional conditions on the group membership. For example: 
(groupdn = "ldap:///ou=Groups,dc=example,dc=com??sub?(cn=*s_0)" or groupdn = "ldap:///ou=Groups,dc=example,dc=com??sub?(cn=*s_1)") and groupdn = "ldap:///ou=Groups,dc=example,dc=com??sub?(cn=*s_2)"
When stringing multiple groupdn URLs together, the keyword supports pipes to separate the URLs: 
groupdn = "LDAPURI0 || LDAPURL1 || LDAPURL2"
However, it is not permissible to use ampersands (&), like groupdn = "LDAPURI0 && LDAPURL1", or double quotes.
For example, to use two groupdn keywords so that the bind user must belong to both an Administrators group and a Managers group: 
groupdn="ldap:///dc=example,dc=com??sub?(cn=*Administrators)" and groupdn="ldap:///dc=example,dc=com??sub?(cn=*Managers)"
For more information about LDAP URLs, see Appendix C, LDAP URLs.
The Directory Server Console defines specific groups through the Access Control Editor. For more information, see Section 13.5, “Creating ACIs from the Console”.

Table 13.5. groupdn Examples

Scenario Example Description
Groupdn keyword containing an LDAP URL groupdn = "ldap:///cn=Administrators,dc=example,dc=com"; The bind rule is evaluated to be true if the bind DN belongs to the Administrators group. If you wanted to grant the Administrators group permission to write to the entire directory tree, you would create the following ACI on the dc=example,dc=com node:
aci: (targetattr=*)(version 3.0; acl "Administrators-write"; allow (write) groupdn="ldap:///cn=Administrators,dc=example,dc=com";)
Groupdn keyword containing an LDAP URL with a filter groupdn = "ldap:///dc=example,dc=com??sub?(cn=*Administrators)"; The bind rule is evaluated to be true if the bind DN belongs to any of the groups which are returned, meaning they match the filter.
Groupdn keyword containing logical OR of LDAP URLs groupdn = "ldap:///cn=Administrators,dc=example,dc=com" || "ldap:///cn=Mail Administrators,dc=example,dc=com"; The bind rule is evaluated to be true if the bind DN belongs to either the Administrators or the Mail Administrators group.

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

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, with the exception of the LDAP filter, which is not implemented for role membership.

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

13.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.
13.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";)
13.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.)
13.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 8.4.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.
13.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.
13.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.
13.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 13.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.
Using Inheritance With the userattr Keyword

Figure 13.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";)
13.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.

13.4.6. Defining Access from a Specific IP Address

Note

Directory Server supports both IPv4 and IPv6 IP addresses.
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 13.5, “Creating ACIs from the Console”.

13.4.7. 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 host name is as follows: 
dns = "DNS_Hostname or dns != "DNS_Hostname

Warning

The dns keyword requires that the naming service used on your machine is DNS. If the name service is not DNS, 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";
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 13.4.6, “Defining Access from a Specific IP Address”.

13.4.8. Requiring a Certain Level of Security in Connections

A bind rule can specify that an operation must occur over a connection with a certain level of security. This forces operations — such as password change operations — to be performed over an SSL/TLS, Start TLS, or SASL connection. The security of the connection is determined by its security strength factor, which sets the minimum key strength required to process operations. The value for the SSF for any operation is the higher of the values between an SSL/TLS connection and a SASL bind; this means that if a server is configured to run over TLS and a replication agreement is configured for SASL/GSSAPI, the SSF for the operation is whichever available encryption type is more secure.
The SSF can be specified using any comparison pattern, like equals (=), less-than and greater-than, (< and >), is-not (!), less-than-or-equal-to (<=), or greater-than-or-equal-to (>=). The LDIF syntax for setting a bind rule based on the SSF is as follows: 
ssf = "key_strength" 
ssf >= "key_strength"
The ssf keyword accepts any positive whole number. If this is set to 0, than no secure connection is required for an operation.
The bind rule is evaluated to be true if the client accesses the directory using a connection of adequate strength.

13.4.9. 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 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:
equal to (=)
not equal to (!=)
greater than (>)
greater than or equal to (>=)
less than (<)
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 Directory 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.

13.4.9.1. Examples

The following are examples of the timeofday and dayofweek syntax:
  • The bind rule is evaluated to be true if the client is accessing the directory at noon. 
    timeofday = "1200";
  • The bind rule is evaluated to be true if the client is accessing the directory at any time other than 1 a.m. 
    timeofday != "0100";
  • The bind rule is evaluated to be true if the client is accessing the directory at any time after 8 a.m. 
    timeofday > "0800";
  • The bind rule is evaluated to be true if the client is accessing the directory at any time before 6 p.m. 
    timeofday < "1800";
  • The bind rule is evaluated to be true if the client is accessing the directory at 8 a.m. or later. 
    timeofday >= "0800";
  • The bind rule is evaluated to be true if the client is accessing the directory at 6 p.m. or earlier. 
    timeofday <= "1800";
  • The bind rule is evaluated to be true if the client is accessing the directory on Sunday, Monday, or Tuesday. 
    dayofweek = "Sun, Mon, Tue";

13.4.10. Defining Access Based on Authentication Method

The authmethod keyword sets the specific method that a client uses to bind to the directory. There are four available authentication methods:
  • None. Authentication is not required. This is the default. It represents anonymous access.
  • Simple. The client must provide a user name and password to bind to the directory.
  • SSL. The client must bind to the directory using some kind of PKI credentials, meaning a client must present an SSL certificate either in a database or on a smart card, token, or some other device.
    Certificate-based authentication, as one method, is described in Section 7.10, “Using Client (Certificate-Based) Authentication”.
  • SASL. The client must bind to the directory over a Simple Authentication and Security Layer (SASL) connection. Directory Server supports several SASL mechanisms: PLAIN, EXTERNAL, CRAM-MD5, DIGEST-MD5 (for Kerberos systems), and GSS-API (for Kerberos systems). For information on setting up SASL, see Section 7.11, “Setting up SASL Identity Mapping”.

Note

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 = "auth_mechanism
auth_mechanism can be none, simple, ssl, or "sasl  sasl_mechanism".

13.4.10.1. Examples

The following are examples of the authmethod keyword:
  • Authentication is not checked during bind rule evaluation. 
    authmethod = "none";
  • The bind rule is evaluated to be true if the client is accessing the directory using a user name and password. 
    authmethod = "simple";
  • 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. The authmethod = "ssl" means that a certificate must be presented to authenticate to the server. This does not configure a required connection type, even though SSL has to be used with certificate-based authentication. 
    authmethod = "ssl";
  • The bind rule is evaluated to be true if the client is accessing the directory using the SASL DIGEST-MD5 mechanism. 
    authmethod = "sasl DIGEST-MD5";

13.4.11. 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 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:
  • Innermost to outermost parenthetical expressions first.
  • All expressions from left to right.
  • NOT before AND or OR operators.
  • OR and 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 B is evaluated before bind rule A despite the left-to-right rule. 
(bind_rule_A) AND NOT (bind_rule_B)