Chapter 6   Managing Access Control

Example ACI

The following is an example of a complete LDIF ACI:

aci: (target="ldap:///uid=bjensen,dc=example,dc=com")(targetattr=*)
(version 3.0;acl "aci1";allow (write) userdn="ldap:///self";)

In this example, the ACI states that the user bjensen has rights to modify all attributes in her own directory entry.

The following sections describe the syntax of each portion of the ACI in more detail.

Defining Targets

The target identifies what the ACI applies to. If the target is not specified, the ACI applies to the entry containing the aci attribute and to the entries below it.

A target can be:

• A directory entry or all of the entries in a subtree, as described in Targeting a Directory Entry.
  
  
• Attributes of an entry, as described in Targeting Attributes.
  
  
• A set of entries or attributes that match a specified LDAP filter, as described in Targeting Entries or Attributes Using LDAP Filters.
  
  
• An attribute value, or a combination of values, that match a specified LDAP filter, as described in Targeting Attribute Values Using LDAP Filters.

The general syntax for a target is:

(keyword= "expression")

(keyword!= "expression")

where:

• keyword indicates the type of target.
  
  
• equal (=) indicates that the target is the object specified in the expression, and not equal (!=) indicates the target is not the object specified in the expression.
  
  
• expression identifies the target.

The quotation marks ("") around expression are required. What you use for expression is dependent upon the keyword that you supply.

The following table lists each keyword and the associated expressions:

Table 6-1   LDIF Target Keywords

Targeting a Directory Entry

To target a directory entry (and the entries below it), you must use the target keyword.

The target keyword can accept a value of the following format:

target="ldap:///distinguished_name"

This identifies the distinguished name of the entry to which the access control rule applies. For example:

(target = "ldap:///uid=bjensen,dc=example,dc=com")

Note	If the DN of the entry to which the access control rule applies contains a comma, you must escape the comma with a single backslash (\). For example: (target="ldap:///uid=lfuentes,dc=example.com Bolivia\,S.A.")

Targeting Attributes

In addition to targeting directory entries, you can also target one or more attributes included in the targeted entries. This is useful when you want to deny or allow access to partial information about an entry. For example, you could allow access to only the common name, surname, and telephone number attributes of a given entry. Or you could deny access to sensitive information such as passwords.

You can specify that the target is equal or is not equal to a specific attribute. The attributes you supply do not need to be defined in the schema. This absence of schema checking makes it possible to implement an access control policy when you set up your directory service for the first time, even if the ACLs you create do not apply to the current directory content.

To target attributes, you use the targetattr keyword. The keyword uses the following syntax:

(targetattr="attribute")

You can target multiple attributes by using the targetattr keyword with the following syntax:

(targetattr="attribute1 || attribute2 ... || attributen")

Where attribute is the name of the attribute you want to target.

For example, to target the common name attribute you would use:

(targetattr = "cn")

To target an entry's common name, surname, and uid attributes, you would use the following:

(targetattr = "cn || sn || uid")

The attributes specified in the targetattr keyword apply to the entry that the ACI is targeting and to all the entries below it. If you target the password attribute on the entry uid=bjensen,ou=Marketing,dc=example,dc=com, only the password attribute on the bjensen entry is affected by the ACI because it is a leaf entry.

If, however, you target the tree's branch point ou=Marketing,dc=example,dc=com, then all the entries beneath the branch point that can contain a password attribute are affected by the ACI.

Targeting Both an Entry and Attributes

By default, the entry targeted by an ACI containing a targetattr keyword is the entry on which the ACI is placed. That is, if you put the ACI

aci: (targetattr = "uid")(access_control_rules;)

on the ou=Marketing , dc=example,dc=com entry, then the ACI applies to the entire Marketing subtree. However, you can also explicitly specify a target using the target keyword as follows:

aci: (target="ldap:///ou=Marketing, dc=example,dc=com")(targetattr="uid")(access_control_rules;)

The order in which you specify the target and the targetattr keywords is not important.

Targeting Entries or Attributes Using LDAP Filters

You can use LDAP filters to target a group of entries that match certain criteria. To do this, you must use the targetfilter keyword with an LDAP filter.

The syntax of the targetfilter keyword is:

(targetfilter="LDAP_filter")

where LDAP_filter is a standard LDAP search filter. For more information on the syntax of LDAP search filters, see Appendix B, "Finding Directory Entries."

For example, suppose that all entries in the accounting department include the attribute-value pair ou=accounting, and all entries in the engineering department include the attribute-value pair ou=engineering subtree. To target all the entries in the accounting and engineering branches of the directory tree, you could use the following filter:

(targetfilter = "(|(ou=accounting)(ou=engineering))")

This type of filter targets whole entries. You can associate the targetfilter and the targetattr keywords to create ACIs that apply to a subset of attributes in the targeted entries.

The following LDIF example allows members of the Engineering Admins group to modify the departmentNumber and manager attributes of all entries in the Engineering business category. This example uses LDAP filtering to select all entries with businessCategory attributes set to Engineering:

dn: dc=example,dc=com
objectClass: top
objectClass: organization
aci: (targetattr="departmentNumber || manager")
(targetfilter="(businessCategory=Engineering)")
(version 3.0; acl "eng-admins-write"; allow (write)
groupdn ="ldap:///cn=Engineering Admins, dc=example,dc=com";)

Note	Although using LDAP filters can be useful when you are targeting entries and attributes that are spread across the directory, the results are sometimes unpredictable because filters do not directly name the object for which you are managing access. The set of entries targeted by a filtered ACI is likely to change as attributes are added or deleted. Therefore, if you use LDAP filters in ACIs, you should verify that they target the correct entries and attributes by using the same filter in an ldapsearch operation.

Targeting Attribute Values Using LDAP Filters

You can use access control to target specific attribute values. This means that you can grant or deny permissions on an attribute if that attribute's value meets the criteria defined in the ACI. An ACI that grants or denies access based on an attribute's value is called a value-based ACI.

For example, you might grant all users in your organization permission to modify the nsRoleDN attribute in their own entry. However, you would also want to ensure that they do not give themselves certain key roles, such as "Top Level Administrator." LDAP filters are used to check that the conditions on attribute values are satisfied.

To create a value-based ACI, you must use the targattrfilters keyword with the following syntax:

(targattrfilters="add=attr1: F1 && attr2: F2 ... && attrn: Fn,del= attr1: F1 && attr2: F2 ... && attrn: Fn")

where:

• add represents the operation of creating an attribute.
  
  
• del represents the operation of deleting an attribute.
  
  
• attrx represents the target attributes.
  
  
• Fx represents filters that apply only to the associated attribute.

When creating an entry, if a filter applies to an attribute in the new entry, then each instance of that attribute must satisfy the filter. When deleting an entry, if a filter applies to an attribute in the entry, then each instance of that attribute must also satisfy the filter.

When modifying an entry, if the operation adds an attribute, then the add filter that applies to that attribute must be satisfied; if the operation deletes an attribute, then the delete filter that applies to that attribute must be satisfied. If individual values of an attribute already present in the entry are replaced, then both the add and delete filters must be satisfied.

For example consider the following attribute filter:

(targattrfilters="add=nsroleDN:(!(nsRoleDN=cn=superAdmin)) && telephoneNumber:(telephoneNumber=123*)")

This filter can be used to allow users to add any role (nsRoleDN attribute) to their own entry, except the superAdmin role. It also allows users to add a telephone number with a 123 prefix.

Note	You cannot create value-based ACIs from the Server Console.

Targeting a Single Directory Entry

Targeting a single directory entry is not straightforward because it goes against the design philosophy of the access control mechanism. However, it can be done:

• By creating a bind rule that matches user input in the bind request with an attribute value stored in the targeted entry. For more details, see Defining Access Based on Value Matching.
  
  
• By using the targetattr and targetfilter keywords.

You can use the targetattr keyword to specify an attribute that is only present in the entry you want to target, and not in any of the entries below your target. For example, if you want to target ou=people,dc=example,dc=com, and there aren't any organizational units (ou) defined below that node, you could specify an ACI that contains:

targetattr=ou

A safer method is to use the targetfilter keyword and to specify explicitly an attribute value that appears in the entry alone. For example, during the installation of the Directory Server, the following ACI is created:

aci: (targetattr="*")(targetfilter=(o=NetscapeRoot))(version 3.0; acl "Default anonymous access"; allow (read, search) userdn="ldap:///anyone";)

This ACI can apply only to the o=NetscapeRoot entry.

The risk associated with these method is that your directory tree might change in the future, and you would have to remember to modify this ACI.

Defining Permissions

Permissions specify the type of access you are allowing or denying. You can either allow or deny permission to perform specific operations in the directory. The various operations that can be assigned are known as rights.

There are two parts to setting permissions:

• Allowing or denying access
• Assigning rights

Allowing or Denying Access

You can either explicitly allow or deny access permissions to your directory tree. For more guidelines on when to allow and when to deny access, refer to the Netscape Directory Server Deployment Guide.

Note	From the Server Console, you cannot explicitly deny access, only grant permissions.

Assigning Rights

Rights detail the specific operations a user can perform on directory data. You can allow or deny all rights, or you can assign one or more of the following rights:

• Read -- Indicates whether users can read directory data. This permission applies only to the search operation.
  
  
• Write -- Indicates whether users can modify an entry by adding, modifying, or deleting attributes. This permission applies to the modify and modrdn operations.
  
  
• Add -- Indicates whether users can create an entry. This permission applies only to the add operation.
  
  
• Delete -- Indicates whether users can delete an entry. This permission applies only to the delete operation.
  
  
• Search -- Indicates whether users can search for the directory data. Users must have Search and Read rights in order to view the data returned as part of a search result. This permission applies only to the search operation.
  
  
• Compare -- Indicates whether the users can compare data they supply with data stored in the directory. With compare rights, the directory returns a success or failure message in response to an inquiry, but the user cannot see the value of the entry or attribute. This permission applies only to the compare operation.
  
  
• Selfwrite -- Indicates whether users can add or delete their own DN from a group. This right is used only for group management.
  
  
• Proxy -- Indicates whether the specified DN can access the target with the rights of another entry. For an overview of proxy access, refer to the Netscape Directory Server Deployment Guide.
  
  
• All -- Indicates that the specified DN has all rights (read, write, search, delete, compare, and selfwrite) to the targeted entry, excluding proxy rights.

Rights are granted independently of one another. This means, for example, that a user who is granted add rights can create an entry but cannot delete it if delete rights have not been specifically granted. Therefore, when planning the access control policy for your directory, you must ensure that you grant rights in a way that makes sense for users. For example, it doesn't usually make sense to grant write permission without granting read and search permissions.

Note	The proxy mechanism is very powerful and must be used sparingly. Proxy rights are granted within the scope of the ACL, and there is no way to restrict who an entry that has the proxy right can impersonate--that is, when you grant a user proxy rights, that user has the ability to proxy for any user under the target; there is no way to restrict the proxy rights to only certain users. For example, if an entity has proxy rights to the dc=example,dc=com tree, that entity can do anything. So, make sure you set the proxy ACI at the lowest possible level of the DIT; see Proxied Authorization ACI Example. For a general overview, see "Proxy Authentication" in chapter 7, "Designing a Secure Directory," in the Netscape Directory Server Deployment Guide.

Rights Required for LDAP Operations

This section describes the rights you need to grant to users depending on the type of LDAP operation you want to authorize them to perform.

Adding an entry:

• Grant add permission on the entry being added.
  
  
• Grant write permission on the value of each attribute in the entry. This right is granted by default but could be restricted using the targattrfilters keyword.

Deleting an entry:

• Grant delete permission on the entry to be deleted.
  
  
• Grant write permission on the value of each attribute in the entry. This right is granted by default but could be restricted using the  targattrfilters keyword.

Modifying an attribute in an entry:

• Grant write permission on the attribute type.
  
  
• Grant write permission on the value of each attribute type. This right is granted by default but could be restricted using the targattrfilters keyword.

Modifying the RDN of an entry:

• Grant write permission on the entry.
  
  
• Grant write permission on the attribute type used in the new RDN.
  
  
• Grant write permission on the attribute type used in the old RDN, if you want to grant the right to delete the old RDN.
  
  
• Grant write permission on the value of attribute type used in the new RDN. This right is granted by default but could be restricted using the targattrfilters keyword.

Comparing the value of an attribute:

• Grant compare permission on the attribute type.

Searching for entries:

• Grant search permission on each attribute type used in the search filter.
  
  
• Grant read permission on attribute types used in the entry.

The permissions you need to set up to allow users to search the directory are more readily understood with an example. Consider the following ldapsearch operation:

% ldapsearch -h host -s base -b "uid=bkolics, dc=example,dc=com " objectclass=* mail

The following ACI is used to determine whether user bkolics can be granted access:

aci: (targetattr = "mail")(version 3.0; acl "self access to mail"; allow (read, search) userdn = "ldap:///self";)

The search result list is empty because this ACI does not grant access to the objectclass attribute. If you want the search operation described above to be successful, you must modify the ACI to read as follows:

aci: (targetattr = "mail || objectclass")(version 3.0; acl "self access to mail"; allow (read, search) userdn = "ldap:///self";)

Permissions Syntax

In an ACI statement, the syntax for permissions is:

allow|deny (rights)

where rights is a list of 1 to 8 comma-separated keywords enclosed within parentheses. Valid keywords are read, write, add, delete, search, compare, selfwrite, proxy, or all.

In the following example, read, search, and compare access is allowed, provided the bind rule is evaluated to be true:

aci: (target="ldap:///dc=example,dc=com") (version 3.0;acl "example";
allow (read, search, compare) bind_rule;)

Access Control and the modrdn Operation

To explicitly deny modrdn rights using ACIs, you must target the relevant entries but omit the targetattr keyword. For example, to prevent the cn=helpDeskGroup,ou=groups,o=example.com group from renaming any entries in the set specified by the pattern cn=*,ou=people,o=example.com, you would add the following ACI: 

aci: (target="ldap:///cn=*,ou=people,o=example.com")
(version 3.0; acl "Deny modrdn rights to the helpDeskGroup";
deny(write) groupdn="ldap:///cn=helpDeskGroup,ou=groups,o=example.com";)

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

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

Table 6-2   LDIF Bind Rule Keywords

Keyword	Valid Expressions	Wildcard Allowed?
userdn	ldap:///distinguished_name ldap:///all ldap:///anyone ldap:///self ldap:///parent ldap:///suffix ??sub?(filter)	yes, in DN only
groupdn	ldap:///DN || DN	no
roledn	ldap:///DN || DN	no
userattr	attribute # bindType or attribute # 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 authentication_method	no

The sections that follow contain further detail on 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 ]...[||ldap:///dn ]"

where 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 of the form:

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

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

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, access for read or access for search) or to specific subtrees or individual entries within the directory.

From the Server Console, you define anonymous access through the Access Control Editor. See Creating ACIs from the Console.

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

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.

From the Server Console, you set up self access on the Access Control Editor. For more information, see Creating ACIs from the Console.

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

LDAP URLs

You can dynamically target users in ACIs using a URL with a filter as follows:

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=engineering)
(ou=accounting))"

Note	Do not specify a hostname or port number within the LDAP URL. LDAP URLs always apply to the local server.

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 will be allowed or denied access based on the permissions you set.

From the Server Console, you set user access from the Access Control Editor. For more information, see Creating ACIs from the Console.

Examples

This section contains examples of the userdn syntax.

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

whereas the following 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,c=example.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.com 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 and password must have been presented by the user during the 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.com 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";)

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

The bind rule is evaluated to be true if the user belongs to the engineering or sales subtree.

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 will be granted or denied if the user binds using a DN that belongs to a specific group.

The groupdn keyword requires one or more valid distinguished names in the following format :

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

The bind rule is evaluated to be true if the bind DN belongs to the named group.

Note	If a DN contains a comma, the comma must be escaped by a backslash (\).

Examples

This section contains examples of the groupdn syntax.

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: (version 3.0; acl "Administrators-write"; allow (write) groupdn="ldap:///cn=Administrators,dc=example,dc=com";)

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.

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

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:

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

or, if you are using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter:

userattr = "attrName # attrValue"

where:

• attrName is the name of the attribute used for value matching.
  
  
• bindType is one of USERDN, GROUPDN, or LDAPURL.
  
  
• attrValue is any string representing an attribute value.

The following sections provide examples of the userattr keyword with the various possible bind types.

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"

or, if you are using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter:

userattr = "parent[inheritance_level]. attrName#attrValue"

where :

• inheritance_level is a comma-separated list that indicates how many levels below the target will inherit 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 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.

Granting Add Permission Using the userattr Keyword

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

Defining Access from a Specific IP Address

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

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"

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

Examples

The following are examples of the timeofday and dayofweek syntax:

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

Defining Access Based on Authentication Method

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

• 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 chapter 11, "Managing SSL and SASL."

• SASL -- The client must bind to the directory over a Simple Authentication and Security Layer (SASL) connection. Directory Server supports three SASL mechanisms: EXTERNAL, DIGEST-MD5, and GSS-API for Kerberos systems. For information on setting up SASL, see chapter 11, "Managing SSL and SASL."

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 = "authentication_method"

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

Examples

The following are examples 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 username and password.
  
  
• authmethod = "ssl";
  
  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.
  
  
• 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. The other supported SASL mechanisms are GSS-API and EXTERNAL.

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 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, the following bind rule will be 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.

The Boolean OR and Boolean 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_A) AND NOT (bind_rule_B)

bind rule B is evaluated before bind rule A despite the left-to-right rule.

Editing an ACI

To edit an ACI:

1. In the Directory tab, right-click the top entry in the subtree, and choose Set Access Permissions from the pop-up menu.
   
   The Access Control Manager window is displayed. It contains the list of ACIs belonging to the entry.
   
   
2. In the Access Control Manager window, highlight the ACI that you want to edit, and click Edit.
   
   The Access Control Editor is displayed. For details on the information you can edit using this dialog box, refer to the online help.
   
   
3. Make the changes you want under the various tabs of the Access Control Editor.
   
   
4. When you have finished editing the ACI, click OK.
   
   The ACI Editor is dismissed, and the modified ACI is listed in the ACI Manager.

Deleting an ACI

To delete an ACI:

1. In the Directory tab, right-click the top entry in the subtree, and choose Set Access Permissions from the pop-up menu.
   
   The Access Control Manager window is displayed. It contains the list of ACIs belonging to the entry.
   
   
2. In the Access Control Manager window, select the ACI that you want to delete.
   
   
3. Click Remove.
   
   The ACI is no longer listed in the Access Control Manager.

ACI "Anonymous example.com"

In LDIF, to grant read, search, and compare permissions to the entire example.com tree to example.com employees, you would write the following statement:

aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous Example"; allow (read, search, compare) userdn= "ldap:///anyone" and dns="*.";)

This example assumes that the aci is added to the dc=example,dc=com entry. The userPassword attribute is excluded from the scope of the ACI.

From the Console, you can set this permission by doing the following:

1. In the Directory tab, right click the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
   
   
2. Click New to display the Access Control Editor.
   
   
3. In the Users/Groups tab in the ACI name field, type Anonymous example.com. Check that All Users is displayed in the list of users granted access permission.
   
   
4. In the Rights tab, tick the checkboxes for read, compare, and search rights. Make sure the other checkboxes are clear.
   
   
5. In the Targets tab, click This Entry to display the dc=example,dc=com suffix in the target directory entry field. In the attribute table, locate the userPassword attribute, and clear the corresponding checkbox.
   
   All other checkboxes should be ticked. This task is made easier if you click the Name header to organize the list of attributes alphabetically.
   
   
6. In the Hosts tab, click Add, and in the DNS host filter field, type *.example.com. Click OK to dismiss the dialog box.
   
   
7. Click OK in the Access Control Editor window.
   
   The new ACI is added to the ones listed in the Access Control Manager window.

ACI "Anonymous World"

In LDIF, to grant read and search access of the individual subscribers subtree to the world, while denying access to information on unlisted subscribers, you could write the following statement:

aci: (targetfilter= "(!(unlistedSubscriber=yes))") (targetattr="homePostalAddress || homePhone || mail") (version 3.0; acl "Anonymous World"; allow (read, search) userdn= "ldap:///anyone";)

This example assumes that the ACI is added to the ou=subscribers,dc=example,dc=com entry. It also assumes that every subscriber entry has an unlistedSubscriber attribute which is set to yes or no. The target definition filters out the unlisted subscribers based on the value of this attribute. For details on the filter definition, refer to Setting a Target Using Filtering.

From the Console, you can set this permission by doing the following:

1. In the Directory tab, right click the Subscribers entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
   
   
2. Click New to display the Access Control Editor.
   
   
3. In the Users/Groups tab, in the ACI name field, type Anonymous World. Check that All Users is displayed in the list of users granted access permission.
   
   
4. In the Rights tab, tick the checkboxes for read and search rights. Make sure the other checkboxes are clear.
   
   
5. In the Targets tab, click This Entry to display the dc=subscribers, dc=example,dc=com suffix in the target directory entry field.
   
   
   1. In the filter for subentries field, type the following filter:
      
      (!(unlistedSubscriber=yes))
      
      
   2. In the attribute table, tick the checkboxes for the homePhone, homePostalAddress, and mail attributes.
      
      All other checkboxes should be clear. This task is made easier if you click the Check None button to clear the checkoxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
   ,
   
6. Click OK.
   
   The new ACI is added to the ones listed in the Access Control Manager window.

ACI "Write example.com"

Note	By setting this permission, you are also granting users the right to delete attribute values.

ACI "Write Subscribers"

Note	By setting this permission, you are also granting users the right to delete attribute values.

ACI "Roles"

In LDIF, to grant example.com employees the right to add any role to their own entry except the superAdmin role, you would write the following statement:

aci: (targetattr = "nsRoleDn") (targattrfilters="add=nsRoleDN:(nsRoleDN != "cn=superAdmin,dc=example,dc=com")") (version 3.0; acl "Roles";
allow (write) userdn= "ldap:///self" and dns="*.example.com";)

This example assumes that the ACI is added to the ou=example-people,dc=example,dc=com entry.

From the Console, you can set this permission by doing the following:

1. In the Directory tab, right click the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
   
   
2. Click New to display the Access Control Editor.
   
   
3. In the Users/Groups tab, in the ACI name field, type Roles. In the list of users granted access permission, do the following:
   
   
   1. Select and remove All Users, then click Add.
      
      The Add Users and Groups dialog box is displayed.
      
      
   2. Set the Search area in the Add Users and Groups dialog box to to Special Rights, and select Self from the Search results list.
      
      
   3. Click the Add button to list Self in the list of users who are granted access permission.
      
      
   4. Click OK to dismiss the Add Users and Groups dialog box.
   
   
4. In the Rights tab, tick the checkbox for write. Make sure the other checkboxes are clear.
   
   
5. In the Hosts tab, click Add to display the Add Host Filter dialog box. In the DNS host filter field, type *.example.com. Click OK to dismiss the dialog box.
   
   
6. To create the value-based filter for roles, switch to manual editing by clicking the Edit Manually button. Add the following to the beginning of the LDIF statement:
   
   (targattrfilters="add=nsRoleDN:(nsRoleDN != "cn=superAdmin, dc=example,dc=com")")
   
   The LDIF statement should read as follows:
   
   (targattrfilters="add=nsRoleDN:(nsRoleDN != "cn=superAdmin, dc=example,dc=com")") (targetattr = "*") (target = "ldap:///dc=example,dc=com") (version 3.0; acl "Roles"; allow (write) (userdn = "ldap:///self") and (dns="*.example.com");)
   
   
7. Click OK.
   
   The new ACI is added to the ones listed in the Access Control Manager window.

ACI "HR"

In LDIF, to grant the HR group all rights on the employee branch of the directory, you would use the following statement:

aci: (version 3.0; acl "HR"; allow (all) userdn= "ldap:///cn=HRgroup,ou=example-people,dc=example,dc=com";)

This example assumes that the ACI is added to the ou=example-people,dc=example,dc=com entry.

From the Console, you can set this permission by doing the following:

1. In the Directory tab, right click the example.com-people entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
   
   
2. Click New to display the Access Control Editor.
   
   
3. In the Users/Groups tab, in the ACI name field, type HR. In the list of users granted access permission, do the following:
   
   
   1. Select and remove All Users, then click Add.
      
      The Add Users and Groups dialog box is displayed.
      
      
   2. Set the Search area to Users and Groups, and type HRgroup in the Search for field.
      
      This example assumes that you have created an HR group or role. For more information on groups and roles, see chapter 5, "Advanced Entry Management."
      
      
   3. Click the Add button to list the HR group in the list of users who are granted access permission.
      
      
   4. Click OK to dismiss the Add Users and Groups dialog box.
   
   
4. In the Rights tab, click the Check All button.
   
   All checkboxes are ticked, except for Proxy rights.
   
   
5. Click OK.
   
   The new ACI is added to the ones listed in the Access Control Manager window.

ACI "Create Group"

In LDIF, to grant example.com employees the right to create a group entry under the ou=Social Committee branch, you would write the following statement:

aci: (target="ldap:///ou=social committee,dc=example,dc=com) (targattrfilters="add=objectClass:(objectClass=groupOfNames)") (version 3.0; acl "Create Group"; allow (add)
(userdn= "ldap:///uid=*,ou=example-people,dc=example,dc=com") and dns="*.example.com";)

Note	This ACI does not grant write permission, which means that the entry creator cannot modify the entry.

ACI "Delete Group"

In LDIF, to grant example.com employees the right to modify or delete a group entry which they own under the ou=Social Comittee branch, you would write the following statement:

aci: (target="ou=social committee,dc=example,dc=com) (targattrfilters="del=objectClass:(objectClass=groupOfNames)") (version 3.0; acl "Delete Group"; allow (delete) userattr= "owner#GROUPDN";)

This example assumes that the aci is added to the ou=social committee,dc=example,dc=com entry.

Using the Console is not an effective way of creating this ACI because you would have to use manual editing mode to create the target filter and to check group ownership.

ACI "HostedCompany1"

In LDIF, to grant HostedCompany1 full access to their own branch of the directory under the conditions stated above, you would write the following statement:

aci: (target="ou=HostedCompany1,ou=corporate-clients,dc=example,dc=com")
(targetattr= "*") (version 3.0; acl "HostedCompany1";
allow (all) (roledn="ldap:///cn=DirectoryAdmin,ou=HostedCompany1,
ou=corporate-clients, dc=example,dc=com") and (authmethod="ssl") and
(dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and
timeofday <= "1800") and (ip="255.255.123.234"); )

This example assumes that the ACI is added to the ou=HostedCompany1, ou=corporate-clients,dc=example,dc=com entry.

From the Console, you can set this permission by doing the following:

1. In the Directory tab, right click the HostedCompany1 entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
   
   
2. Click New to display the Access Control Editor.
   
   
3. In the Users/Groups tab, in the ACI name field, type HostedCompany1. In the list of users granted access permission, do the following:
   
   
   1. Select and remove All Users, then click Add. The Add Users and Groups dialog box is displayed.
      
      
   2. Set the Search area to Users and Groups, and type DirectoryAdmin in the Search For field. This example assumes that you have created an administrators role with a cn of DirectoryAdmin.
      
      
   3. Click the Add button to list the administrators role in the list of users who are granted access permission.
      
      
   4. Click OK to dismiss the Add Users and Groups dialog box.
   
   
4. In the Rights tab, click the Check All button.
   
   
5. In the Targets tab, click This Entry to display the ou=HostedCompany1,ou=corporate-clients, dc=example,dc=com suffix in the target directory entry field.
   
   
6. In the Hosts tab, click Add to display the Add Host Filter dialog box. In the IP address host filter field, type 255.255.123.234. Click OK to dismiss the dialog box.
   
   The IP address must be a valid IP address for the host machine that the HostedCompany1 administrators will use to connect to the example.com directory.
   
   
7. In the Times tab, select the block time corresponding to Monday through Thursday and 8 a.m. to 6 p.m.
   
   A message appears below the table that specifies what time block you have selected.
   
   
8. To enforce SSL authentication from HostedCompany1 administrators, switch to manual editing by clicking the Edit Manually button. Add the following to the end of the LDIF statement:
   
   and (authmethod="ssl")
   
   The LDIF statement should be similar to:
   
   aci: (targetattr = "*") (target="ou=HostedCompany1,ou=corporate-clients,dc=example,dc=com") (version 3.0; acl "HostedCompany1"; allow (all) (roledn= "ldap:///cn=DirectoryAdmin,ou=HostedCompany1,ou=corporate-clients, dc=example,dc=com") and (dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and timeofday <= "1800") and (ip="255.255.123.234") and (authmethod="ssl");)
   
   
9. Click OK.
   
   The new ACI is added to the ones listed in the Access Control Manager window.

ACI "Billing Info Read"

In LDIF, to grant subscribers permission to read billing information in their own entry, you would write the following statement:

aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Read"; allow (search,read) userdn= "ldap:///self";)

This example assumes that the relevant attributes have been created in the schema and that the ACI is added to the ou=subscribers,dc=example,dc=com entry.

From the Console, you can set this permission by doing the following:

1. In the Directory tab, right click the subscribers entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
   
   
2. Click New to display the Access Control Editor.
   
   
3. In the Users/Groups tab, in the ACI name field, type Billing Info Read. In the list of users granted access permission, do the following:
   
   
   1. Select and remove All Users, then click Add.
      
      The Add Users and Groups dialog box is displayed.
      
      
   2. Set the Search area in the Add Users and Groups dialog box to to Special Rights, and select Self from the Search results list.
      
      
   3. Click the Add button to list Self in the list of users who are granted access permission.
      
      
   4. Click OK to dismiss the Add Users and Groups dialog box.
   
   
4. In the Rights tab, tick the checkboxes for search and read rights. Make sure the other checkboxes are clear.
   
   
5. In the Targets tab, click This Entry to display the ou=subscribers, dc=example,dc=com suffix in the target directory entry field. In the attribute table, tick the checkboxes for the connectionTime and accountBalance attributes.
   
   All other checkboxes should be clear. This task is made easier if you click the Check None button to clear the checkoxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
   
   This example assumes that you have added the the connectionTime and accountBalance attributes to the schema.
   
   
6. Click OK.
   
   The new ACI is added to the ones listed in the Access Control Manager window.

ACI "Billing Info Deny"

In LDIF, to deny subscribers permission to modify billing information in their own entry, you would write the following statement:

aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Deny"; deny (write) userdn= "ldap:///self";)

This example assumes that the relevant attributes have been created in the schema and that the ACI is added to the ou=subscribers,dc=example,dc=com entry.

From the Console, you can set this permission by doing the following:

1. In the Directory tab, right click the subscribers entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
   
   
2. Click New to display the Access Control Editor.
   
   
3. In the Users/Groups tab, in the ACI name field, type Billing Info Deny. In the list of users granted access permission, do the following:
   
   
   1. Select and remove All Users, then click Add.
      
      The Add Users and Groups dialog box is displayed.
      
      
   2. Set the Search area in the Add Users and Groups dialog box to to Special Rights, and select Self from the Search results list.
      
      
   3. Click the Add button to list Self in the list of users who are granted access permission.
      
      
   4. Click OK to dismiss the Add Users and Groups dialog box.
   
   
4. In the Rights tab, tick the checkbox for write. Make sure the other checkboxes are clear.
   
   
5. Click the Edit Manually button, and, in the LDIF statement that is displayed, change the word allow to deny.
   
   
6. In the Targets tab, click This Entry to display the ou=subscribers, dc=example,dc=com suffix in the target directory entry field. In the attribute table, tick the checkboxes for the connectionTime and accountBalance attributes.
   
   All other checkboxes should be clear. This task is made easier if you click the Check None button to clear the checkoxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
   
   This example assumes that you have added the the connectionTime and accountBalance attributes to the schema.
   
   
7. Click OK.
   
   The new ACI is added to the ones listed in the Access Control Manager window.

ACI "Group Members"

In LDIF, to grant example.com employees the right to add or delete themselves from a group, you would write the following statement:

aci: (targettattr="member")(version 3.0; acl "Group Members";
allow (selfwrite)
(userdn= "ldap:///uid=*,ou=example-people, dc=example,dc=com");)

This example assumes that the ACI is added to the ou=social committee, dc=example,dc=com entry.

From the Console, you can set this permission by doing the following:

1. In the Directory tab, right click the example-people entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager.
   
   
2. Click New to display the Access Control Editor.
   
   
3. In the Users/Groups tab, in the ACI name field, type Group Members. In the list of users granted access permission, do the following:
   
   
   1. Select and remove All Users, then click Add.
      
      The Add Users and Groups dialog box is displayed.
      
      
   2. Set the Search area in the Add Users and Groups dialog box to to Special Rights, and select All Authenticated Users from the Search results list.
      
      
   3. Click the Add button to list All Authenticated Users in the list of users who are granted access permission.
      
      
   4. Click OK to dismiss the Add Users and Groups dialog box.
   
   
4. In the Rights tab, tick the checkbox for selfwrite. Make sure the other checkboxes are clear.
   
   
5. In the Targets tab, type dc=example,dc=com suffix in the target directory entry field. In the attribute table, tick the checkbox for the member attribute.
   
   All other checkboxes should be clear. This task is made easier if you click the Check None button to clear the checkoxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones.
   
   
6. Click OK.
   
   The new ACI is added to the ones listed in the Access Control Manager window.

Macro ACI Syntax

Macro ACIs include the following types of expressions to replace a DN or part of a DN:

• ($dn)
• [$dn]
• ($attr. attrName), where attrName represents an attribute contained in the target entry

To simplify the discussion in this section, the ACI keywords used to provide bind credentials, such as userdn, roledn, groupdn, and userattr, are collectively called the subject, as opposed to the target ,of the ACI. Macro ACIs can be used in the target part or the subject part of an ACI.

Table 6-3 shows in what parts of the ACI you can use DN macros:

Table 6-3   Macros in ACI Keywords