Bind Rule Syntax

Whether access is allowed or denied depends on whether an ACI's bind rule is evaluated to be true. The following sections describe the bind rule syntax and the various keywords that can be used to allow or deny access.

• Bind Rule Syntax Overview

• Defining User Access (userdn Keyword)

• Defining Group Access (groupdn Keyword)

• Defining Access Based on Value Matching (userattr Keyword)

• Defining Access From a Specific IP Address (ip Keyword)

• Defining Access From a Specific Domain (dns Keyword)

• Defining Access at a Specific Time of Day or Day of Week (timeofday and dayofweek Keywords)

• Defining Access Based on Authentication Method (authmethod Keyword)

• Defining Access Based on a Connection's Security Strength Factor (ssf Keyword)

Bind Rule Syntax Overview

Bind rules use one of the following patterns:

• keyword = " expression";

• keyword != " expression";

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

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

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

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

Keyword Valid Expressions Wildcard Allowed? userdn ldap:///distinguishedName ldap:///all ldap:///anyone ldap:///self ldap:///parent ldap:///suffix??sub?(filter) Allowed, in DN only groupdn ldap:///DN Not Allowed userattr attribute#bindType or attribute#value Not Allowed ip IPaddress Allowed dns DNShostName Allowed dayofweek sun mon tue wed thu fri sat Not Allowed timeofday hhmm where hh is in the range 00–24 and mm is in the range 00–60 Not Allowed authmethod none simple ssl sasl authenticationMethod Not Allowed ssf 0–256 Not Allowed

The following sections provide additional information about the 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]..."

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

where dn can be a DN or one of the expressions anyone, all, self, or parent. These expressions refer to the following users:

userdn = "ldap:///anyone"

Both anonymous and authenticated users

userdn = "ldap:///all"

Only authenticated users

userdn = "ldap:///self"

Only the same user as the target entry of the ACI

userdn = "ldap:///parent"

Only the parent entry of the ACI target

The userdn keyword can also be expressed as an LDAP filter in this form:

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

Characters that are syntactically significant for a DN, such as commas, must be escaped with a single backslash (\).

The following sections describe how to define user access with the userdn keyword:

• Defining General Access (all Keyword)

• Defining Anonymous Access (anyone Keyword)

• Defining Self Access (self Keyword)

• Defining Parent Access (parent Keyword)

• Specifying Users With LDAP URLs

• Specifying Users With Wildcards

• Specifying Users With a Logical OR of LDAP URLs

• Excluding Specific LDAP URLs

Defining General Access (all Keyword)

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

For example, to grant read access to the entire tree to all authenticated users, create the following ACI on the dc=example,dc=com node:

aci: (version 3.0; acl "all-read"; allow (read)
userdn="ldap:///all";)

Defining Anonymous Access (anyone Keyword)

Granting anonymous access to the directory means that anyone can access it without providing a bind DN or password, 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. Anonymous access using the anyone keyword also allows access by any authenticated user.

For example, to allow anonymous read and search access to the entire example.com tree, 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";)

Defining 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. For example, to grant all users in the example.com tree write access to their userPassword attribute, create the following ACI on the dc=example,dc=com node.

aci: (targetattr = "userPassword") (version 3.0; acl
"modify own password"; allow (write) userdn = "ldap:///self";)

Defining 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. For example, to allow users to modify any child entries of their bind DN, create the following ACI on the dc=example,dc=com node:

aci: (version 3.0; acl "parent access";
allow (write) userdn="ldap:///parent";)

Specifying Users With LDAP URLs

You can dynamically target users in ACIs using a URL with a filter as shown in the following example:

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=eng)(ou=acct))"

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

Specifying Users With Wildcards

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

Specifying Users With a Logical OR of LDAP URLs

Specify several LDAP URLs or keyword expressions to create complex rules for user access. For example:

userdn = "ldap:///uid=b*,c=example.com ||
ldap:///cn=b*,dc=example,dc=com";

The bind rule is evaluated to be true for users binding with either of the DN patterns.

Excluding Specific LDAP URLs

Use the not-equal (!=) operator to define user access that excludes specific URLs or DNs. For example:

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 makes sense only if the targeted entry is not under the accounting branch of the directory tree.

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.

The groupdn keyword requires the distinguished name of one or more groups in the following format:

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

The bind rule is evaluated to be true if the bind DN belongs to a group specified by any of the group DNs. The following section give examples using the groupdn keyword.

Characters that are syntactically significant for a DN, such as commas, must be escaped with a single backslash (\).

Specifying a Group With a Single 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. For example, to grant the Administrators group permission to write to the entire directory tree, create the following ACI on the dc=example,dc=com node:

aci: (version 3.0; acl "Administrators-write"; allow (write)
groupdn="ldap:///cn=Administrators,dc=example,dc=com";)

Specifying a Group With a 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.

Defining Access Based on Value Matching (userattr Keyword)

The userattr keyword can be used to specify which attribute values must match between the entry used to bind (bind entry) and the targeted entry. A userattr expression has two formats, a bind-type format and an attribute-value format.

The following sections describe how to define access based on value matching:

• Bind-Type Format

• Attribute-Value Format

• USERDN Bind Type Example

• GROUPDN Bind Type Example

• LDAPURL Bind Type Example

• Attribute Value Example

• Inheritance

• Inheritance Example

• Add Permissions

Bind-Type Format

This format is named the bind-type format because it uses the bind DN and possibly the bind entry when evaluating a match. It is the more complicated of the two formats. The bind-type format can be used in the following three ways:

• Treat a target entry attribute value as a DN that must match the bind DN

• Treat a target entry attribute value as a group DN that the bind DN must be a member of

• Require that both the bind DN and the bind entry match an LDAP URL specified in a target entry attribute value

The bind-type userattr format uses this syntax:

userattr = "attrName#bindType"

where:

attrName

Is the name of the attribute in the target entry.

bindType

Must be one of the following:

USERDN

The value of attrName must match the bind DN.

GROUPDN

The value of attrName is a group that must contain the bind DN.

LDAPURL

The value of attrName is an LDAP URL that is treated as a search that the bind DN and entry must match. To satisfy the search, the URL's dn value is used as a base DN that the bind DN must match or have as a parent DN. The URL's scope value restricts how far below the base DN the bind DN can match. Finally, the bind entry must match the URL's filter value.

The bind type userattr format has a special parent keyword that allows targeting of entries levels below the current target entry. See Inheritance for more details on this keyword.

Attribute-Value Format

The attribute-value format requires the following two conditions to match:

• An attribute specified in the userattr expression must exist in both the target and bind entries.

• The values of both of these attributes must match a string value specified in the userattr expression. This string value cannot be one of the bind type keywords (USERDN, GROUPDN, LDAPURL).

The attribute value userattr format uses this syntax:

userattr = "attrName#attrValue"

where:

attrName

The name of the attribute in both the target and bind entries.

attrValue

The string representing the attribute value (not USERDN, GROUPDN or LDAPURL).

USERDN Bind Type Example

The following example of a bind rule userattr keyword expression specifies a match between the bind DN and the value of the target entry attribute manager.

userattr = "manager#USERDN"

This bind rule is evaluated to be true if the bind DN matches the value of the manager attribute in the target entry. The manager attribute in the target entry must match the bind DN. Wildcards are not allowed.

The following example ACI grants a manager full access to all user attributes of entries located in the subtree under the DN dc=example, dc=comm:

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

GROUPDN Bind Type Example

This is an example of a bind rule userattr keyword expression specifying an attribute that contains a group DN that the bind DN must be a member of.

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 target entry.

LDAPURL Bind Type Example

This is an example of a bind rule userattr keyword expression specifying an attribute that contains an LDAP URL that is treated as a search that the bind DN and entry must match.

userattr = "aciurl#LDAPURL"

The attribute aciurl is an example only.

The bind rule is evaluated to true if the bind DN and bind entry satisfy all of the search requirements specified in the LDAP URL. For example, if the value of aciurl is ldap:///dc=example,dc=com??one?(cn=joe*), then the bind DN must satisfy a one-level search under the base DN of dc=example,dc=com and the bind entry must satisfy the filter (cn=joe*).

Attribute Value Example

The following example of the bind rule userattr keyword expression specifies an attribute value that both the bind entry and target entry must match.

userattr = "favoriteBeverage#Water"

The bind rule is evaluated to be true if the bind and target entries include the favoriteBeverage attribute with a value of Water.

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 shown in the following example:

userattr = "parent[[inheritanceLevel].attribute#bindType"

where :

• inheritanceLevel is a comma-separated list that indicates how many levels below the target inherit the ACI. You can include ten levels [0,1,2,3,4,..,9] below the targeted entry. Zero (0) indicates the targeted entry.

• attribute is the attribute targeted by the userattr.

• bindType can be either USERDN or GROUPDN. The LDAPURL bind type is not supported with inheritance.

For example, the userattr = "parent[[0,1].manager#USERDN" bind rule is evaluated to be true if the bind DN matches the manager attribute of the target entry. Also, the bind rule is evaluated to be true for all entries immediately below the target entry (one level below the target) that have manager attributes matching the bind DN.

Inheritance Example

The following example 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.

cn=Profiles
aci:(targetattr="*")(version 3.0, acl "profiles access" allow(read, search)
userattr="parent[[0,1].owner#USERDN;)
owner=cn=bjensen, ou=people, dc=example, dc=com
cn=mail, cn=Profiles
mailuser: bjensen
cn=news, cn=Profiles
newuser: bjensen

If inheritance were not used in this example, you would need to do one of the following:

• 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 and the following ACI to the cn=mail, cn=Profiles and cn=news,cn=Profiles entries:

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

Add Permissions

If you use the userattr keyword in conjunction with all or add permissions, you might find that the behavior of the directory server is not what you expect. Typically, when a new entry is created in the directory, the 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, so the directory server's normal behavior is modified to avoid it.

Consider the following example ACI:

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[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 (ip Keyword)

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 shown in the following examples:

ip = "IPaddressList"
ip != "IPaddressList"

The IPaddressList is a list of one or more comma-separated elements from among any of the following:

• A specific IPv4 address, such as 123.45.6.7

• An IPv4/CIDR-compliant address, such as 192.168.0.0/16

• An IPv4 address with wildcards to specify a subnetwork, such as 12.3.45.*

• An IPv4 address or subnetwork with a subnetwork mask, such as 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 2373 and 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, such as 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. This can be useful for allowing certain kinds of directory access only from a specific subnet or machine. Note that 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.

Defining Access From a Specific Domain (dns Keyword)

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 shown here:

dns = "DNShostname"
dns != "DNShostname"

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. Note that wildcards do 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 (ip Keyword).

Defining Access at a Specific Time of Day or Day of Week (timeofday and dayofweek Keywords)

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 the time 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 shown here:

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)

• <= (less than or equal to)

The time is expressed as four digits representing hours and minutes in the 24-hour clock (hhmm where hh is in the range 00-24 and mm is in the range 00-60). For example:

• 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 time and date on the directory server are used for the evaluation of the timeofday and dayofweek bind rules and not the time on the client.

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

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. Specify all days you want to grant access, for example:

dayofweek = "mon, tue, wed, thu, fri";

The bind rule is true if the directory is being accessed on one of the days listed.

Defining Access Based on Authentication Method (authmethod Keyword)

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

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 over a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection.

In the case of SSL, the connection is established to the LDAPS second port. In the case of TLS, the connection is established through a Start TLS operation. In both cases, a certificate must be provided. For information on setting up SSL, see Using SASL Authentication in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

SASL

The client must bind to the directory using a Simple Authentication and Security Layer (SASL) mechanism, such as DIGEST-MD5 or GSSAPI.

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

authmethod = "authentication_method"

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

Authentication Method Examples

The following examples show typical specifications 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 user name and password.

authmethod = "ssl"

The bind rule is evaluated to be true if the client authenticates to the directory using a certificate over LDAPS. It is not 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. Other supported SASL mechanisms are EXTERNAL and GSSAPI.

Defining Access Based on a Connection's Security Strength Factor (ssf Keyword)

You can use bind rules to specify that binding can only occur based on a specific level of Security Strength Factor (SSF) enforced on the established connection. A connection's SSF is based on the key strength of the cipher enforced on the connection and pertains only to TLS/SSL or DIGEST-MD5/GSSAPI confidentiality or integrity connections.

The LDIF syntax for setting a bind rule based on the Security Strength Factor is shown here:

ssf operator "strength"

where 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 strength is a value representing the cipher key strength required on the connection and is a value (0 to 256). DIGEST-MD5/GSSAPI connections with integrity enforced have an SSF of 1. TLS/SSL and DIGEST-MD5/GSSAPI confidentiality connections can have variable values of SSF based on the cipher negotiation performed between the directory server and client. The higher a connection's negotiated SSF is, the stronger the encryption is on the connection, as shown in these examples:

• ssf = "1"; is true for access if integrity ssf = 1 only is enforced on the connection.

• ssf != "40"; is true for access if ssf not equal 40 is enforced on the connection.

• ssf > "128"; is true for access if ssf greater than 128 is enforced on the connection.

• ssf >= "128"; is true for access if ssf greater than or equal 128 is enforced on the connection.

• ssf < "56"; is true for access if ssf less than 56 is enforced on the connection.

Clear connections have an SSF of 0.

The following sections describe how to define based on a connection's security strength factor keyword

DIGEST-MD5 QOP Key Size Mapping

The following table illustrates the Quality of Protection (QOP) to cipher key size mapping.

Cipher QOP Description RC4 (40) Low RC4 cipher with 40-bit key (obsolete) RC4 (56) Medium RC4 cipher with 56-bit key DES Medium Data Encryption Standard (DES) cipher in cipher block chaining (CBC) mode with a 56–bit key RC4 (128) High RC4 cipher with 128–bit key Triple DES High Triple DES cipher in CBC mode with EDE with the same key for each E stage (also called “two keys mode”) for a total key length of 112 bits

TLS Cipher Key Size Mapping

Cipher TLS RFC Key Size Description RC2_CBC_40 4346 40 RC2 cipher in cipher block chaining (CBC) mode (obsolete) RC4_40 4346 40 RC4 cipher (obsolete) DES40_CBC 4346 40 DES 40–bit cipher in cipher block chaining (CBC) mode (obsolete) DES_CBC 4346 56 DES 56–bit in cipher block chaining (CBC) mode cipher 3DES_EDE_CBC 4346 112 TDES RC4_128 4346 128 RC4 cipher IDEA_CBC 4346 128 International Data Encryption Algorithm (IDEA) cipher in cipher block chaining (CBC) mode SEED_CBC 4162 128 SEED cipher in cipher block chaining (CBC) mode CAMELLIA_128_CBC 4132 128 Camellia cipher in cipher block chaining (CBC) mode AES_128_CBC 3268 128 Advanced Encryption Standard (AES) in cipher block chaining (CBC) mode AES_256_CBC 3268 256 Advanced Encryption Standard (AES) in cipher block chaining (CBC) mode CAMELLIA_256_CBC 4132 256 Camellia cipher in cipher block chaining (CBC) mode AES_256_GCM 5288 256 AES in Galois Counter Mode (GCM)

Example

The following ACI allows users to change their own passwords only over a connection with an SSF strength equal to or greater than 128:

(targetattr="userPassword||authPassword")(version 3.0; acl "User change pwd";
(allow (write) userdn="ldap:///self" and ssf >= "128");)