Bind Rule Keywords

For information about bind rule keywords, see the following sections:

• userdn Keyword

• Syntax of the userdn Keyword

• LDAP URLs in the userdn Keyword

• groupdn Keyword

• roledn Keyword

• userattr Keyword

• Examples of userattr Keyword With Various Bind Types

• Use of the userattr Keyword With the parent Keyword for Inheritance

• Use of the userattr Keyword to Grant Add Permissions

• ip Keyword

• dns Keyword

• timeofday Keyword

• dayofweek Keyword

• authmethod Keyword

The following table summarizes the keywords for bind rules.

ldap:///distinguished_name
ldap:///all
ldap:///anyone
ldap:///self
ldap:///parent
ldap:///suffix??sub?(filter)

attribute#bindType

attribute#value

0 - 2359

userdn Keyword

The userdn keyword is used to allow or deny access to a specified user. The following sections contain more information about the userdn keyword.

Syntax of 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:

distinguished-name

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

anyone

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

all

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

self

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

parent

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

LDAP URLs in the userdn Keyword

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.

Example 2–5 Using the userdn Keyword With a Logical OR Operator in LDAP URLs

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

Example 2–6 Using the userdn Keyword With a Not-Equal Operator in LDAP URLs

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

groupdn Keyword

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 (\).

roledn Keyword

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.

userattr 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:

attrName

The name of the attribute used for value matching

bindType

One of the following types of bind: USERDN,GROUPDN,ROLEDN,LDAPURL

attrValue

Any string that represents an attribute value

Examples of userattr Keyword With Various Bind Types

Example 2–7 Using the userattr Keyword With the 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 2–8 Using the userattr Keyword With the 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 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.

Example 2–9 Using the userattr Keyword With the 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.

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.

Example 2–10 Using the userattr Keyword With the 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 2–11 Using the userattr Keyword With Any Attribute Value

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.

Use of the userattr Keyword With the parent Keyword for Inheritance

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:

inheritance_level

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.

attribute

The attribute targeted by the userattr or groupattr keyword.

bindType

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.

Use of the userattr Keyword to Grant Add Permissions

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.

ip Keyword

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.

dns Keyword

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.

timeofday Keyword

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:

operator

• Equal to (=)

• Not equal to (!=)

• Greater than or equal to (>=)

• Less than (<)

• Less than or equal to (<=)

time

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.

dayofweek Keyword

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.

authmethod Keyword

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:

None

Authentication is not checked during bind rule evaluation. This is the default.

Simple

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

SSL

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.

SASL sasl_mechanism

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.