JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Directory Server Enterprise Edition Administration Guide 11g Release 1 (11.1.1.5.0)
search filter icon
search icon

Document Information

Preface

Part I Directory Server Administration

1.  Directory Server Tools

2.  Directory Server Instances and Suffixes

3.  Directory Server Configuration

4.  Directory Server Entries

5.  Directory Server Security

6.  Directory Server Access Control

Creating, Viewing, and Modifying ACIs

To Create, Modify, and Delete ACIs

To View ACI Attribute Values

To View ACIs at the Root Level

ACI Syntax

ACI Targets

Target Syntax

Target Keywords

ACI Permissions

Permission Syntax

Permission Rights

Permissions for Typical LDAP Operations

ACI Bind Rules

Introduction to Bind Rules

Bind Rule Syntax

Bind Rule Keywords

Boolean Bind Rules

To Allow Normal Users to Manage User Accounts Using dsutil Command

Access Control Usage Examples

Granting Anonymous Access

ACI "Anonymous Example.com"

ACI "Anonymous World"

Granting Write Access to Personal Entries

ACI "Write Example.com"

ACI "Write Subscribers"

Granting Access to a Certain Level

ACI "Read Example.com only"

Restricting Access to Key Roles

ACI "Roles"

Granting a Role Full Access to an Entire Suffix

ACI "Full Access"

Granting a Group Full Access to a Suffix

ACI "HR"

Granting Rights to Add and Delete Group Entries

ACI "Create Group"

ACI "Delete Group"

Allowing Users to Add or Remove Themselves From a Group

ACI "Group Members"

Granting Conditional Access to a Group or Role

ACI "Company333"

Denying Access

ACI "Billing Info Read"

ACI "Billing Info Deny"

Proxy Authorization

Example Proxy Authorization

Setting a Target Using Filtering

Defining Permissions for DNs That Contain a Comma

Viewing Effective Rights

Restricting Access to the Get Effective Rights Control

Using the Get Effective Rights Control

Advanced Access Control: Using Macro ACIs

Macro ACI Example

Macro ACI Syntax

Matching for ($dn) in the Target

Substituting ($dn) in the Subject

Substituting [$dn] in the Subject

Macro Matching for ($attr.attrName)

Logging Access Control Information

To Set Logging for ACIs

Client-Host Access Control Through TCP Wrapping

To Enable TCP Wrapping

To Disable TCP Wrapping

7.  Directory Server Password Policy

8.  Directory Server Backup and Restore

9.  Directory Server Groups, Roles, and CoS

10.  Directory Server Replication

11.  Directory Server Schema

12.  Directory Server Indexing

13.  Directory Server Attribute Value Uniqueness

14.  Directory Server Logging

15.  Directory Server Monitoring

Part II Directory Proxy Server Administration

16.  Directory Proxy Server Tools

17.  Directory Proxy Server Instances

18.  LDAP Data Views

19.  Directory Proxy Server Certificates

20.  Directory Proxy Server Load Balancing and Client Affinity

21.  Directory Proxy Server Distribution

22.  Directory Proxy Server Virtualization

23.  Virtual Data Transformations

24.  Connections Between Directory Proxy Server and Back-End LDAP Servers

25.  Connections Between Clients and Directory Proxy Server

26.  Directory Proxy Server Client Authentication

27.  Directory Proxy Server Logging

28.  Directory Proxy Server Monitoring and Alerts

Part III Directory Service Control Center Administration

29.  Directory Service Control Center Configuration

Index

Creating, Viewing, and Modifying ACIs

You can create ACIs either by using Directory Service Control Center (DSCC) or by using the command line. Whichever method you choose, it is often easier to view and copy an existing ACI value, rather than to create a new ACI from scratch.

You can view and modify the aci attribute values in DSCC. For information about how to modify ACIs through DSCC, see the DSCC online help.

To Create, Modify, and Delete ACIs

To create ACIs by using the command line, you first create the ACIs in a file using LDIF statements. Then you add the ACIs to your directory tree by using the ldapmodify command.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

  1. Create the ACI in an LDIF file.
    dn: dc=example,dc=com
    changetype: modify
    add: aci
    aci: (target)(version 3.0; acl "name";permission bindrules;)

    This example shows how to add an ACI. To modify or delete the ACI, replace add with replace or delete.

    For more examples of ACIs that are commonly used, see Access Control Usage Examples.

  2. Make the change using the LDIF file.
    $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - -f ldif-file

To View ACI Attribute Values

ACIs are stored as one or more values of the aci attribute of an entry. The aci attribute is a multi-valued operational attribute that can be read and modified by directory users. Therefore, the ACI attribute itself should be protected by ACIs. Administration users are usually given full access to the aci attribute.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

To View ACIs at the Root Level

When you create a suffix, some default ACIs are created at the top or root level. These ACIs allow the default administration user cn=admin,cn=Administrators,cn=config to have the same access rights to directory data as the Directory Manager.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

ACI Syntax

The aci attribute has the following syntax:

aci: [list of (target)](version 3.0; acl "name";[list of "permission bindRules;"])

The following values are used in the ACI syntax:

target

Specifies the entry, attributes, or set of entries and attributes for which you want to control access. The target can be a distinguished name, one or more attributes, or a single LDAP filter. The target is optional. When a target is not specified, the ACI applies to the entry on which it is defined and its subtree. For information about targets, see ACI Targets.

version 3.0

A required string that identifies the ACI version.

name

A required string that identifies the ACI. Although there are no restrictions on the name, it is good practice to use unique, descriptive names for ACIs. Using unique names, will allow you to use Get Effective Rights to determine which ACI is in force.

permission

States what rights you are allowing or denying. For information about permissions, see ACI Permissions.

bindRules

Specifies the credentials and bind parameters that a user has to provide to be granted access. Bind rules can also be based on user membership, group membership, or connection properties of the client. For information about bind rules, see ACI Bind Rules.

The permission and bind rule portions of the ACI are set as a pair, also called an Access Control Rule (ACR). The specified permission to access the target is granted or denied depending on whether the accompanying bind rule is evaluated to be true or false.

Multiple targets and multiple permission-bind rule pairs can be used. This allows you to refine both the entry and attributes being targeted and efficiently set multiple access controls for a given target. The following example shows an ACI with multiple targets and multiple permission-bind rule pairs:

aci: (targetdefinition)...(targetdefinition)(version 3.0;acl "name"; 
permission bindRule; ...; permission bindRule;)

In the following example, the ACI states that bjensen has rights to modify all attributes in her own directory entry:

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

The following sections describe the syntax of targets, permissions and bind rules.

ACI Targets

An ACI target statement specifies the entry, attributes, or set of entries and attributes for which you want to control access.

Target Syntax

An ACI target statement has this syntax:

(keyword = "expression")

The following values are used in the target.

keyword

Indicates the type of target.

expression

Identifies the target. The quotation marks ("") around expression are syntactically required, although the current implementation accepts expressions like targetattr=*.

=
!=

Indicates that the target is or is not the object specified in the expression.

The != operator cannot be used with the targettrfilters keyword or the targetscope keyword.

Target Keywords

For a description of target keywords, see the following sections:

The following table lists the target keywords and their associated expressions.

Table 6-1 Target Keywords and Their Expressions

Keyword
Type of target
Expression
target
A directory entry or its subtree
ldap:///distinguished_name
targetattr
The attributes of an entry
attribute
targetfilter
A set of entries or attributes that match an LDAP filter
LDAP_filter
targattrfilters
An attribute value or combination of values that match an LDAP filter
LDAP_operation:LDAP_filter
targetscope
The scope of the target
base, onelevel, subtree
target Keyword

The target keyword specifies that an ACI is defined for a directory entry. The target keyword uses the following syntax:

(target = "distinguished_name")

or

(target != "distinguished_name")

The distinguished name must be in the subtree rooted at the entry where the ACI is defined. For example, the following target may be used in an ACI on ou=People,dc=example,dc=com:

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

The DN of the entry must be a distinguished name in string representation (RFC 4514). Therefore, characters that are syntactically significant for a DN, such as commas, must be escaped with a single backslash (\).

Wildcards, shown as asterisk characters can be used in the expression for the target keyword. The asterisk matches an attribute value, a substring of a value, or a DN component. For example, all of the following expressions match uid=bjensen,ou=people,dc=example,dc=com.

The following further examples show permitted uses of wildcards.

Other usage of wildcards to such as target="ldap:///uid=bjensen,o*,dc=com" might be accepted, but are deprecated.

targetattr Keyword

The targetattr keyword specifies that an ACI is defined for one or more attributes in the targeted entries. The targetattr keyword uses the following syntax:

(targetattr = "attribute")

or

(targetattr != "attribute")

If no targetattr keyword is present, no attributes are targeted. To target all attributes, the targetattr keyword must be targetattr="*".

Targeted attributes do not need to exist on the target entry or its subtree, but the ACI applies whenever they do.

Targeted attributes do not need to be defined in the schema. The absence of schema checking makes it possible to implement an access control policy before importing data and its schema.

The targetattr keyword can be used for multiple attributes, by using this syntax:

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

Note - If you configure attribute aliases, you must specify both the attribute name and the alias in the targetattr keyword for the ACI to take them into account.


Targeted attributes include all subtypes of the named attribute. For example, (targetattr = "locality") also targets locality;lang-fr.

Wildcards can be used in the expression for the targetattr keyword, but the use of wildcards would serve no purpose and may reduce performance.

targetfilter Keyword

The targetfilter keyword is used in ACIs to target entries that match an LDAP filter. The ACI applies to all entries that match the LDAP filter and that are in the scope of the ACI. The targetfilter keyword uses the following syntax:

(targetfilter = "(standard LDAP search filter)")

Example 6-1 Using the targetfilter Keyword to Target Specific Entries

The following example is for employees with a status of salaried or contractor, and an attribute for the number of hours worked as a percentage of a full-time position. The filter targets entries for contractors or part-time employees:

(targetfilter = "(|(status=contractor)(fulltime<=79))")

The Netscape extended filter syntax is not supported in ACIs. For example, the following target filter is not valid:

(targetfilter = "(locality:fr:=<= Québec)")

The filter syntax that describes matching rules for internationalized values is supported. For example, the following target filter is valid:

(targetfilter = "(locality:2.16.840.1.113730.3.3.2.18.1.4:=Québec)")

The targetfilter keyword selects whole entries as targets of the ACI. The targetfilter keyword and the targetattr keyword can be used together to create ACIs that apply to a subset of attributes in the targeted entries.

targattrfilters Keyword

The targattrfilters keyword is used in ACIs to target specific attribute values by using LDAP filters. By using the targattrfilters keyword, 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. The targattrfilters keyword uses this 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.

attrn

represents the target attributes.

Fn

represents filters that apply only to the associated attribute.

The following conditions must be met when filters apply to entries, and those entries are created, deleted or modified:

Example 6-2 Using the targattrfilters Keyword to Allow Users to Add Roles to Their Own Entries

The following ACI allows users to add any role to their own entry, except the superAdmin role. It also allows users to add a telephone number with a 123 prefix.

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

The targetscope keyword is used in ACIs to specify the scope of the ACI. The targetscope keyword uses this syntax:

(targetscope="base")

The targetscope keyword can have one of these values:

base

The ACI applies to the target resource only

onelevel

The ACI applies to the target resource and its first-generation children

subtree

The ACI applies to the target resource and its subtree

If the targetscope keyword is not specified, the default value is subtree.

ACI Permissions

Permissions specify the type of access that is allowed or denied by the ACI. For information about bind rules, see the following sections:

Permission Syntax

An ACI permission statement has this syntax:

allow|deny (right1, right2 ...)

Rights define the operations you can perform on directory data. In an ACI statement, rights is a list of comma-separated keywords enclosed within parentheses.

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

Permission Rights

The following rights can be allowed or denied in an ACI permission statement:

Read

Permission to read directory data. This permission applies only to the search operation.

Write

Permission to modify an entry by adding, modifying, or deleting attributes. This permission applies to the modify and modify DN operations.

Add

Permission to create entries. This permission applies only to the add operation

Delete

Permission to delete entries. This permission applies only to the delete operation.

Search

Permission to search for 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

Permission for users to 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

Permission for users to add or delete their own DN in an attribute of the target entry. The syntax of this attribute must be distinguished name. This right is used only for group management. The Selfwrite permission works with proxy authorization; it grants the right to add or delete the proxy DN from the group entry (not the DN of the bound user).

Proxy

Permission for the specified DN to access the target with the rights of another entry. You can grant proxy access using the DN of any user in the directory except the Directory Manager DN. You cannot grant proxy rights to the Directory Manager.

Import

Permission for an entry to be imported to the specified DN. This permission applies the modify DN operation.

Export

Permission for an entry to be exported from the specified DN. This permission applies the modify DN operation.

All

Permission for the specified DN to have the following rights for the targeted entry: read, write, search, delete, compare, and selfwrite. The All access right does control permission for the following rights to the target entry: proxy, import, and export.

Permissions for Typical LDAP Operations

This section describes the rights required to perform a set of LDAP operations.

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 targettrfilters 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 targettrfilters 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 targettrfilters 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 targettrfilters keyword.

Moving an entry to another subtree:
  • Grant export permissions on the entry that you want to move.

  • Grant import permission on the new superior entry of the entry that you want to move.

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 at least one attribute type used in the entry to ensure that the entry is returned.

  • Grant read permission an each attribute type to be returned with the entry.

Example 6-3 Granting ACI Permissions to Perform a Search

The following ACI determines whether bjensen can be granted access for searching her own entry:

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 allow bjensen the right to search on the objectclass attribute. To perform the search operation described, you must modify the ACI as follows:

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

ACI Bind Rules

Bind rules identify the set of users to which an ACI applies. The permission and bind rule portions of the ACI are set as a pair. The specified permission to access the target is granted or denied depending on whether the accompanying bind rule is evaluated to be true or false.

For information about bind rules, see the following sections:

Introduction to Bind Rules

Bind rules identify a set of users by using the following methods:

A simple bind rule might require a person accessing the directory to belong to a specific group. A complex bind rule can require a person to belong to a specific group and to log in from a machine with a specific IP address, between 8 am and 5 pm. Additionally, bind rules can be complex constructions that combine these criteria by using Boolean operators.

The server evaluates the logical expressions used in ACIs according to a three-valued logic, similar to the one used to evaluate LDAP filters, as described in section 4.5.1.7 of RFC 4511 Lightweight Directory Access Protocol (v3). Therefore, if any component in the expression evaluates to Undefined (for example if the evaluation of the expression aborted due to a resource limitation), then the server handles this case correctly. The server does not erroneously grant access because an Undefined value occurred in a complex Boolean expression.

Bind Rule Syntax

An ACI bind rule has this syntax:

keyword = "expression";

or

keyword != "expression";

The following values are used in the bind rule:

keyword

Indicates the type of bind rule.

expression

Identifies the bind rule.

Bind Rule Keywords

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

The following table summarizes the keywords for bind rules.

Table 6-2 Bind Rule Keywords and Their Expressions

Keyword
Used to define access based on
Expression
userdn
Specified user
ldap:///distinguished_name
ldap:///all
ldap:///anyone
ldap:///self
ldap:///parent
ldap:///suffix??sub?(filter)
groupdn
Specified group or groups
[ldap:///DN]
roledn
Specified role or roles
[ldap:///DN]
userattr
Matched attribute value
attribute#bindType
or
attribute#value
ip
Specified IP address or IP addresses
IP_address
dns
Specified domain or domains
DNS_host_name
timeofday
Specified time of day
0 - 2359
dayofweek
Specified day or days of the week
sun, mon, tue, wed, thu, fri, and sat
authmethod
Specified authentication method
none, simple, ssl, sasl authentication_method
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 wildcard * 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 6-4 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 6-5 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:

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 6-6 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 6-7 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 6-8 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 6-9 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 6-10 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:

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 wildcard * can be used to specify a set of IP addresses.

The wildcard * cannot be used in IPv6 addresses.

dns Keyword

Note - 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 wildcards.

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.

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.

Boolean Bind Rules

Bind rules can be complex expressions that use the Boolean expressions AND, OR, and NOT to set precise access rules. Boolean bind rules use this syntax:

(bindRuleA and (bindRuleB or (bindRuleC and bindRuleD));)

Parentheses defines the order in which rules are evaluated, and a trailing semicolon must appear after the final rule.

Example 6-11 Boolean Bind Rule

The bind rule is true if both of the following conditions are met:

(dns = "*.example.com"
  and (groupdn = "ldap:///cn=administrators, dc=example,dc=com"
  or (groupdn = "ldap:///cn=mail administrators, dc=example,dc=com"
  and groupdn = "ldap:///cn=calendar administrators, dc=example,dc=com"));)

To Allow Normal Users to Manage User Accounts Using dsutil Command