Bind rules identify the set of users to which an ACI applies. The permission and bind rule portions of the ACI are set as a pair. The specified permission to access the target is granted or denied depending on whether the accompanying bind rule is evaluated to be true or false.
For information about bind rules, see the following sections:
Bind rules identify a set of users by using the following methods:
The users, groups, and roles that are granted access.
The location from which an entity must bind. The location from which a user authenticates can be spoofed and cannot be trusted. Do not base ACIs on this information alone.
The time or day on which binding must occur.
The type of authentication that must be in use during binding.
A simple bind rule might require a person accessing the directory to belong to a specific group. A complex bind rule can require a person to belong to a specific group and to log in from a machine with a specific IP address, between 8 am and 5 pm. Additionally, bind rules can be complex constructions that combine these criteria by using Boolean operators.
The server evaluates the logical expressions used in ACIs according to a three-valued logic, similar to the one used to evaluate LDAP filters, as described in section 4.5.1.7 of RFC 4511 Lightweight Directory Access Protocol (v3). Therefore, if any component in the expression evaluates to Undefined (for example if the evaluation of the expression aborted due to a resource limitation), then the server handles this case correctly. The server does not erroneously grant access because an Undefined value occurred in a complex Boolean expression.
An ACI bind rule has this syntax:
keyword = "expression";
or
keyword != "expression";
The following values are used in the bind rule:
Indicates the type of bind rule.
Identifies the bind rule.
For information about bind rule keywords, see the following sections:
The following table summarizes the keywords for bind rules.
Table 2–2 Bind Rule Keywords and Their Expressions
The userdn keyword is used to allow or deny access to a specified user. The following sections contain more information about the userdn keyword.
The userdn keyword uses this syntax:
userdn = "ldap:///dn [|| ldap:///dn]..." userdn != "ldap:///dn [|| ldap:///dn]..."
The userdn keyword can alternatively be expressed as an LDAP URL filter. For information about expressing the userdn keyword as an LDAP URL, see LDAP URLs in the userdn Keyword.
dn can have of the following values:
A fully qualified DN. Characters that are syntactically significant for a DN, such as commas, must be escaped with a single backslash (\). The wild card * can be used to specify a set of users. For example, if the following user DN is specified, users with a bind DN beginning with the letter b are allowed or denied access:
uid=b*,dc=example,dc=com
Allows or denies access for anonymous and authenticated users, regardless of the circumstances of the bind.
This access can be limited to specific types of access (for example, access for read or access for search) or to specific subtrees or individual entries within the directory. The following ACI on the dc=example,dc=com node allows anonymous access to read and search the entire dc=example,dc=com tree.
aci: (version 3.0; acl "anonymous-read-search"; allow (read, search) userdn = "ldap:///anyone";)
Allows or denies access for authenticated users. This all value prevents anonymous access. The following ACI on the dc=example,dc=com node allows authenticated users to read the entire dc=example,dc=com tree:
aci: (version 3.0; acl "all-read"; allow (read) userdn="ldap:///all";)
Allows or denies users access to their own entries if the bind DN matches the DN of the targeted entry. The following ACI on the dc=example,dc=com node allows authenticated users in the dc=example,dc=com tree to write to their userPassword attribute.
aci: (targetattr = "userPassword") (version 3.0; acl "modify own password"; allow (write) userdn = "ldap:///self";)
Allows or denies users access to the entry if the bind DN is the parent of the targeted entry.
The following ACI on the dc=example,dc=com node allows authenticated users in the dc=example,dc=com tree to modify any child entries of their bind DN:
aci: (version 3.0; acl "parent access"; allow (write) userdn="ldap:///parent";)
The userdn keyword can also be expressed as an LDAP URL with a filter, by using this syntax:
userdn = ldap:///suffix??sub?(filter)
LDAP URLs always apply to the local server. Do not specify a hostname or port number within an LDAP URL.
The following ACI on the dc=example,dc=com node allows all users in the accounting and engineering branches of the example.com tree to access to the targeted resource dynamically based on the following URL
userdn = "ldap:///dc=example,dc=com??sub?(|(ou=eng)(ou=acct))"
LDAP URLs can be used with the logical OR operator and the not-equal operator as shown in the following examples.
This bind rule is evaluated to be true for users that bind with either of the specified DN patterns.
userdn = "ldap:///uid=b*,c=example.com || ldap:///cn=b*,dc=example,dc=com";
This bind rule is evaluated to be true if the client is not binding as a UID-based DN 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 != "ldap:///uid=*,ou=Accounting,dc=example,dc=com";
The groupdn keyword specifies that access to a targeted entry is granted or denied if the user binds by using a DN that belongs to a specific group. The groupdn keyword uses this syntax:
groupdn="ldap:///groupDN [|| ldap:///groupDN]..."
The bind rule is evaluated to be true if the bind DN belongs to a group that is specified by any of the values for groupDN.
In the following example, the bind rule is true if the bind DN belongs to the Administrators group :
aci: (version 3.0; acl "Administrators-write"; allow (write) groupdn="ldap:///cn=Administrators,dc=example,dc=com";)
Characters that are syntactically significant for a DN, such as commas, must be escaped with a single backslash (\).
The roledn keyword specifies 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 this 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.
Characters that are syntactically significant for a DN, such as commas, must be escaped with a single backslash (\).
The roledn keyword has the same syntax and is used in the same way as the groupdn keyword.
The userattr keyword specifies which attribute values in the entry that was used to bind must match those in the targeted entry. The userattr keyword can be used for the following attributes:
User DN
Group DN
Role DN
LDAP filter, in an LDAP URL
Any attribute type
An attribute generated by a Class of Service (CoS) definition cannot be used with the userattr keyword. ACIs that contain bind rules that depend on attribute values generated by CoS will not work.
The userattr keyword uses this syntax:
userattr = "attrName#bindType"
Alternatively, if you are using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter, the userattr keyword uses this syntax:
userattr = "attrName#attrValue"
The userattr keyword can have one of the following values:
The name of the attribute used for value matching
One of the following types of bind: USERDN,GROUPDN,ROLEDN,LDAPURL
Any string that represents an attribute value
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";)
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 directory. 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.
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.
The DN of the role can be under any suffix in the directory. If, in addition, you are using filtered roles, the evaluation of this type of ACI uses a lot of resources on the server.
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.
The following is an example of the userattr keyword associated with a bind based on any attribute value:
userattr = "favoriteDrink#Milk"
The bind rule is evaluated to be true if the bind DN and the target DN include the favoriteDrink attribute with a value of Milk.
The userattr keyword can be used with the parent keyword to specify the number of levels below the target that should inherit the ACI. The userattr keyword and parent keyword use this syntax:
userattr = "parent[inheritance_level].attribute#bindType"
The userattr keyword and parent keyword can have the following values:
A comma separated list that indicates how many levels below the target should inherit the ACI. These levels below the targeted entry can be specified: [0,1,2,3,4]. Zero (0) indicates the targeted entry.
The attribute targeted by the userattr or groupattr keyword.
The type of bind can be USERDN or GROUPDN. Inheritance cannot be used with LDAPURL and ROLEDN binds.
The following example shows how the userattr keyword is used with the parent keyword for inheritance:
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.
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, for ACIs that use 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, that is, 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.
The ip keyword is used to specify that a bind operation must originate from a specific IP address. The ip keyword uses this syntax:
ip = "IPaddressList" or ip != "IPaddressList"
The IPaddressList value is a list of one or more comma-separated elements from the following elements:
A specific IPv4 address: 123.45.6.7
An IPv4 address with wild cards to specify a subnetwork: 12.3.45.*
An IPv4 address or subnetwork with subnetwork mask: 123.45.6.*+255.255.255.192
An IPv6 address in any of its legal forms and contained in square brackets [ and ], as defined by RFC 2373and RFC 2732.
The following addresses are equivalent:
ldap://[12AB:0000:0000:CD30:0000:0000:0000:0000]
ldap://[12AB::CD30:0:0:0:0]
ldap://[12AB:0:0:CD30::]
An IPv6 address with a subnet prefix length: ldap://[12AB::CD30:0:0:0:0]/60
The bind rule is evaluated to be true if the client accessing the directory is located at the named IP address.
The ip keyword can be used to force all directory updates to occur from a given machine or network domain. However, the IP address from which a user authenticates can be spoofed, and can therefore not be trusted. Do not base ACIs on this information alone.
The wild card * can be used to specify a set of IP addresses.
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 is used to specify that a bind operation must originate from a specific domain or host machine. The dns keyword uses this syntax:
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";
You should use a fully qualified name such as:
dns = "legend.eng.example.com";
The dns keyword allows wild cards.
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. Note that wild cards do not work if your system uses a naming service other than DNS.
The timeofday keyword is used to specify that access can occur at a certain time of day. The time and date on the server are used for the evaluation of the timeofday and dayofweek bind rules, and not the time on the client. The timeofday keyword uses this syntax:
timeofday operator "time"
The timeofday keyword can have the following values:
Equal to (=)
Not equal to (!=)
Greater than or equal to (>=)
Less than (<)
Less than or equal to (<=)
Four digits representing hours and minutes in the 24-hour clock (0 to 2359)
timeofday = "1200"; is true if the client is accessing the directory during the minute that the system clock shows noon.
timeofday != "0100"; is true for access at any other time than 1 a.m.
timeofday > "0800"; is true for access from 8:01 a.m. through 11:59 p.m.
timeofday >= "0800"; is true for access from 8:00 a.m. through 11:59 p.m.
timeofday < "1800"; is true for access from 12:00 midnight through 5:59 p.m.
The dayofweek keyword is used to specify that access can occur on a certain day or on certain days of the week. The time and date on the server are used for the evaluation of the timeofday and dayofweek bind rules, and not the time on the client. The dayofweek keyword uses this syntax:
dayofweek = "day1, day2 ..."
The bind rule is true if the directory is being accessed on one of the days listed.
The dayofweek keyword can have one or more of the following values: sun, mon, tue, wed, thu, fri, sat.
The authmethod keyword is used to specify that a client must bind to the directory by using a specific authentication method. The authmethod keyword uses this syntax:
authmethod = "authentication_method"
The authmethod keyword can have the following values:
Authentication is not checked during bind rule evaluation. This is the default.
The bind rule is evaluated to be true if the client is accessing the directory using a username and password.
The client must bind to the directory over a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection.
The bind rule is evaluated to be true if the client authenticates to the directory by using a certificate over LDAPS. It will not be true if the client authenticates by using simple authentication (bind DN and password) over LDAPS.
The bind rule is evaluated to be true if the client authenticates to the directory by using one of the following SASL mechanisms: DIGEST-MD5, GSSAPI, or EXTERNAL.
Bind rules can be complex expressions that use the Boolean expressions AND, OR, and NOT to set precise access rules. Boolean bind rules use this syntax:
(bindRuleA and (bindRuleB or (bindRuleC and bindRuleD));)
Parentheses defines the order in which rules are evaluated, and a trailing semicolon must appear after the final rule.
The bind rule is true if both of the following conditions are met:
The bind DN client is accessed from within the example.com domain
The bind DN client is a member of either the administrators group or the bind DN client a member of both the mail administrators and calendar administrators groups
(dns = "*.example.com" and (groupdn = "ldap:///cn=administrators, dc=example,dc=com" or (groupdn = "ldap:///cn=mail administrators, dc=example,dc=com" and groupdn = "ldap:///cn=calendar administrators, dc=example,dc=com"));)