9 Understanding Access Control Model in Oracle Unified Directory

Access control is a mechanism that is used to regulate access to resources in a computing environment.

The following topics provide descriptive and reference information about the directory server access control model:

• Understanding Access Control Principles

• Understanding the Syntax of Access Control Instructions

• Understanding Bind Rules

• Understanding Bind Rule Syntax

• Compatibility With the Oracle Directory Server Enterprise Edition Access Control Model

• Using Macro ACIs for Advanced Access Control

• Understanding Virtual Access Control Instructions

For information about configuring access control in the directory server, see Controlling Access To Data.

9.1 Understanding Access Control Principles

You need to understand the principles of the access control mechanism provided with the directory server to configure access control policies.

This section contains the following topics:

• About Access Control

• Overview of Access Control Instructions Structure

• Configuring Directory Server Global Access Control Instructions

• About Evaluation of Access Control Instructions

• About Limitations of Access Control Instructions

• About Replication of Access Control Instructions

• About Anonymous Read Access ACI

See also Managing Global ACIs Using dsconfig.

9.1.1 About Access Control

When the directory server receives a request, it uses the authentication information provided by the user in the bind operation, and the access control instructions (ACIs) defined in the server to allow or deny access to directory information.

The server can allow or deny permissions such as read, write, search, or compare. The permission level granted to a user might depend on the authentication information that the user provides.

Using access control, you can control access to the entire directory, a subtree of the directory, specific entries in the directory (including entries that define configuration tasks), a specific set of entry attributes, or specific entry attribute values. You can set permissions for a particular user, for all users who belong to a specific group or role, or for all users of the directory. Finally, you can define access for a specific client, identified by its IP address or DNS name.

9.1.2 Overview of Access Control Instructions Structure

ACIs are used to allow or deny access to directory information. ACIs are stored in the directory as attributes of entries.

The aci attribute is an operational attribute that is available for use on every entry in the directory, regardless of whether it is defined for the object class of the entry. This attribute is used by the directory server to evaluate what rights are granted or denied when the directory server receives an LDAP request from a client. The aci attribute is returned in an ldapsearch operation only if it is specifically requested.

An ACI statement includes three main parts:

Target

Determines the entry or attributes to which permissions apply.

Permission

Defines what operations are allowed or denied.

Bind Rule

Determines who is subject to the ACI, based on their bind DN.

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 rule is evaluated to be true. For more information, see Understanding the Syntax of Access Control Instructions.

If an entry that contains an ACI does not have child entries, the ACI applies to that entry only. If the entry has child entries, the ACI applies to the entry itself and to all entries below it. Therefore, when the directory server evaluates access permissions to an entry, it verifies the ACIs for every entry between the one that was requested and the base of its root suffix.

The aci attribute is multivalued, which means that you can define several ACIs for the same entry or subtree.

You can create an ACI on an entry that does not apply directly to that entry but to some or all of the entries in the subtree below it. The advantage of this is that you can place at a high level in the directory tree a general ACI that effectively applies to entries that are more likely to be located lower in the tree. For example, at the level of an organizationalUnit entry or a locality entry, you could create an ACI that targets entries that include the inetorgperson object class.

You can use this feature to minimize the number of ACIs in the directory tree by placing general rules at high-level branch points. To limit the scope of more specific rules, place them as close as possible to leaf entries.

Note:

ACIs that are placed in the root DSE entry (with the DN "") apply only to that entry.

9.1.3 Configuring Directory Server Global Access Control Instructions

You can configure access control centrally by using the dsconfig command to modify the properties of the Access Control Handler.

The following default global ACIs apply to all suffixes that are defined in the directory server because the rules do not specify a target expression:

Property   : Value(s)
-----------:-------------------------------------------------------------------
global-aci : "(targetattr="*")(version 3.0; acl "Self entry modification";
           : allow (write) userdn="ldap:///self";),
           : "(targetattr="createTimestamp||creatorsName||modifiersName||modify
           : Timestamp||entryDN||entryUUID||subschemaSubentry")(version 3.0;
           : acl "User-Visible Operational Attributes"; allow
           : (read,search,compare) userdn="ldap:///anyone";)",

For more information, see Managing Global ACIs Using dsconfig.

9.1.4 About Evaluation of Access Control Instructions

To evaluate the access rights to a particular entry, the server compiles a list of the ACIs present on the entry itself and on the parent entries back up to the base of the entry's root suffix. During evaluation, the server processes the ACIs in this order.

ACIs are evaluated in all of the suffixes and subsuffixes between an entry and the base of its root suffix, but not across chained suffixes on other servers.

Note:

Access control does not apply to any user who has the bypass-acl privilege. The Directory Manager has this privilege. When a client is bound to the directory as the Directory Manager, the directory server does not evaluate any ACIs before performing operations. As a result, performance of LDAP operations as Directory Manager is not comparable to the expected performance of other users. You should always test directory performance with a typical user identity.

By default, if no ACI applies to an entry, access is denied to all users except those with the bypass-acl privilege. Access must be explicitly granted by an ACI for a user to access any entry in the directory. For more information, see About Default Global ACIs.

Although the directory server processes the ACIs that are closest to the target entry first, the effect of all ACIs that apply to an entry is cumulative. Access granted by any ACI is allowed unless any other ACI denies it. ACIs that deny access, no matter where they appear in the list, take precedence over ACIs that allow access to the same resource.

For example, if you deny write permission at the directory's root level, none of the users can write to the directory regardless of the specific permissions you grant them. To grant a specific user write permissions to the directory, you must restrict the scope of the original denial for write permission so that it does not include that user.

9.1.5 About Limitations of Access Control Instructions

There are some limitations that you must bear in mind when you create an access control policy for your directory service.

The limitations are as follows:

• If your directory tree is distributed over several directory servers, some restrictions apply to the keywords that you can use in access control statements. ACIs that depend on group entries (groupdn keyword) must be located on the same directory server as the group entry. If the group is dynamic, all members of that group must also have an entry on the directory server. If the group is static, the members' entries can be located on remote directory servers. However, you can do value matching of values stored in the target entry with values stored in the entry of the bind user (for example, using the userattr keyword). Access is evaluated normally even if the bind user does not have an entry on the directory server that holds the ACI.

• Access control rules are always evaluated on the local directory server. You must not specify the host name or port number of the directory server in LDAP URLs used in ACI keywords. If you do, the LDAP URL is not taken into account at all.

9.1.6 About Replication of Access Control Instructions

ACIs are stored as attributes of entries, so if an entry containing ACIs is part of a replicated suffix, the ACIs are replicated like any other attribute.

9.1.7 About Anonymous Read Access ACI

Anonymous read access ACI is automatically added to a server instance during the Oracle Unified Directory setup when you enable an instance as a datastore for Oracle Enterprise User Security (EUS).

"(targetattr!="userPassword||authPassword")(version 3.0; acl "Anonymous read access"; allow (read,search,compare) userdn="ldap:///anyone";)"

To enable a server instance as a datastore for EUS, you must select the Enable for EUS (Enterprise User Security), EBS, Database Net Services and DIP option in the Oracle Components Integration window during the Oracle Unified Directory setup. See Setting Up Oracle Unified Directory as a Directory Server in Installing Oracle Unified Directory.

9.2 Understanding the Syntax of Access Control Instructions

ACIs are complex structures with many possible variations. A detailed analysis of the ACI syntax is dealt with in this section.

This section contains the following topics:

• Overview of Access Control Instructions Syntax

• Defining Targets

• Setting Permissions

See also Understanding Bind Rule Syntax.

9.2.1 Overview of Access Control Instructions Syntax

You must review the ACI syntax to regulate access to directory data.

The aci attribute has the following syntax:

aci: (target)(version 3.0;acl "name";permissionBindRules;)

where:

• 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 the target is not specified, the ACI applies to the entire entry where it is defined and all of its children.

• version 3.0 is a required string that identifies the ACI version.

• name is a name for the ACI. The name can be any string that identifies the ACI. The ACI name is required and should describe the effect of the ACI. Although there are no restrictions on the name, it is good practice to use unique names for ACIs. If you use unique names, the Get Effective Rights control enables you to determine which ACI is in force.

• permission specifically states what rights you are either allowing or denying, for example read or search rights.

• bindRules specify the credentials and bind parameters that a user has to provide to be granted access. Bind rules can also be based on user or group membership or connection properties of the client.

You can specify multiple targets and permission-bind rule pairs. This allows you to refine both the entry and attributes being targeted and efficiently set multiple access controls for a given target, as shown here:

aci: (target)...(target)(version 3.0;acl "name"; permissionBindRule; permissionBindRule; ...; permissionBindRule;)

The following example shows a complete LDIF ACI:

aci: (target="ldap:///uid=bjensen,dc=example,dc=com")
(targetattr="*")(version 3.0; acl "example"; 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.

9.2.2 Defining Targets

The target identifies what the ACI applies to. When a client requests an operation on attributes in an entry, the directory server evaluates the target to see if the ACI must be evaluated to allow or deny the operation.

If the target is not specified, the ACI applies to all attributes in the entry containing the aci attribute and to the entries below it.

The following sections describe how to define targets:

• Overview of LDIF Target Keywords

• Targeting a Directory Entry

• Targeting Attributes in a Targeted Entry

• Targeting Both an Entry and Attributes

• Targeting Entries or Attributes Using LDAP Filters

• Targeting Attribute Values Using LDAP Filters

• Targeting a Single Directory Entry

• Specifying the Scope of an ACI

• Targeting LDAP Controls

• Targeting LDAP Extended Operations

9.2.2.1 Overview of LDIF Target Keywords

The general syntax for a target is one of the following:

(keyword = "expression")
(keyword != "expression")

where:

• keyword indicates the type of target. The following types of targets are defined by the keywords in Table 9-1:

  • A directory entry or its subtree

  • The attributes of an entry

  • A set of entries or attributes that match an LDAP filter

  • An attribute value or combination of values that match an LDAP filter

  • The scope of the ACI

  • An LDAP control

  • An extended operation

• The equal sign (=) indicates that the target is the object specified in the expression, and not equal (!=) indicates that the target is any object not specified in the expression.

  Note:

  The not-equal operator is not supported for the targattrfilters and targetscope keywords.

• expression depends on the keyword and identifies the target. The quotation marks ("") around expression are syntactically required, although the current implementation accepts expressions like targetattr=*. In future versions, syntax checking might become more strict, so you should always use quotation marks.

The following table lists each keyword and the associated expressions.

Table 9-1 LDIF Target Keywords

Keyword	Valid Expressions	Wildcard Allowed?
target	ldap:///distinguishedName	Allowed
targetattr	attribute	Allowed
targetfilter	LDAPfilter	Allowed
targattrfilters	LDAPoperation:LDAPfilter	Allowed
targetscope	base, onelevel, subtree, subordinate	Not Allowed
targetcontrol	oid	Not Allowed
extop	oid	Not Allowed

9.2.2.2 Targeting a Directory Entry

Use the target keyword and a DN inside an LDAP URL to target a specific directory entry and any entries below it. The targeted DN must be located in the entry where the ACI is defined or in the subtree below the entry. The target expression has the following syntax:

(target = "ldap:///distinguishedName")
(target != "ldap:///distinguishedName")

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

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

The keyword target is optional. If it is not present, the default target for the ACI is the entry where the ACI is stored.

Note:

The DN of the entry must be a distinguished name in string representation (as defined in RFC 4514 (http://www.ietf.org/rfc/rfc4514.txt)). Therefore, characters syntactically significant for a DN, such as commas, must be escaped with a single backslash (\). For example:

(target="ldap:///uid=cfuentes,o=Example Bolivia\, S.A.")

You can also use a wildcard in the DN to target any number of entries that match the LDAP URL. The following are legal examples of wildcard usage:

• (target="ldap:///uid=*,dc=example,dc=com") Matches every immediate child of the example.com branch entry that has the uid attribute in the entry's RDN, as shown in this example.

  uid=tmorris,dc=example,dc=com
  uid=yyorgens,dc=example,dc=com
  uid=bjensen,dc=example,dc=com
  

• (target="ldap:///uid=*,**,dc=example,dc=com") Matches every entry more than one level below the example.com branch entry that has the uid attribute in the entry's RDN, as shown in this example.

  uid=tmorris,ou=sales,dc=example,dc=com
  uid=yyorgens,ou=marketing,dc=example,dc=com
  uid=bjensen,ou=eng,ou=east,dc=example,dc=com
  

• (target="ldap:///uid=*Anderson,ou=People,dc=example,dc=com") Matches every entry immediately below the ou=People branch entry with a uid ending in Anderson.

• (target="ldap:///*=*Anderson,ou=People,dc=example,dc=com") Matches every entry immediately below the ou=People branch whose RDN ends with Anderson, regardless of the naming attribute.

Multiple wildcards are allowed, such as in uid=*,ou=*,dc=example,dc=com, which matches every entry in the example.com tree whose distinguished name contains the uid and ou attributes in the specified positions.

9.2.2.3 Targeting Attributes in a Targeted Entry

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

If no targetattr rule is present, no attributes can be accessed by default. To access all attributes, the rule must be targetattr="*".

The targeted attributes do not need to exist on the target entry or its subtree, but the ACI applies whenever they do. The attributes you target 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 your data and its schema.

To target attributes, use the targetattr keyword and provide the attribute names. The targetattr keyword uses the following syntax:

(targetattr = "attribute")
(targetattr != "attribute")

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

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

For example, to target an entry's common name, surname, and UID attributes, you would use the following:

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

To target all of an entry's user attributes, except carlicense, you would use the following target:

(targetattr != "carlicense")

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

You can use a wildcard as a stand-alone character in a targetattr rule (such as targetattr="*"), but this use is discouraged because it serves no particular purpose and can have a negative performance impact.

9.2.2.4 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 apply the ACI aci: (targetattr = "uid")(accessControlRules;) to 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 shown in the following example:

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

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

9.2.2.5 Targeting Entries or Attributes Using LDAP Filters

Use LDAP filters to target a set of entries that match certain criteria. To do this, use the targetfilter keyword with an LDAP filter. The ACI applies to all entries that match the filter at the level of the target DN and in the subtree below it.

The targetfilter keyword uses this syntax:

(targetfilter = "LDAPfilter")

where LDAPfilter is a standard LDAP search filter. For more information about filter syntax, see search filter.

For example, suppose that all entries representing employees have a status of salaried or contractor and an attribute representing the number of hours worked, as a percentage of a full-time position. To target all the entries representing contractors or part-time employees, you could use the following filter:

(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:=<= Quebec)")

Target filters select whole entries as targets of the ACI. 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 Admin 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";)

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.

9.2.2.6 Targeting Attribute Values Using LDAP Filters

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 can grant all users in your organization permission to modify the roomNumber attribute in their own entries. However, you would also want to ensure that they do not give themselves reserved room numbers, all of which begin with 12. 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="Op=attr1:F1[(&& attr2:F2)*][;Op=attr:F[(&& attr:F)*]")

where:

• Op is either an add or delete operation:

  • add represents the operation of creating an attribute.

  • delete represents the operation of deleting an attribute.

• attr represents the target attributes.

• F represents search filter that applies only to the associated attribute.

When creating an entry, if a filter applies to an attribute in the new entry, then all values of that attribute must satisfy the filter. When deleting an entry, if a filter applies to an attribute in the entry, then all values 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.

The following example attribute filter allows users to add any roomNumber attribute to their own entries except the reserved room numbers, which have a 12 prefix. It also allows users to add a telephone number with a 123 prefix.

(targattrfilters="add=roomNumber:(!(roomNumber=12*)) && telephoneNumber:(telephoneNumber=123*)")

9.2.2.7 Targeting a Single Directory Entry

There is no explicit way to target a single entry. However, you can achieve this in one of two ways:

• By creating a bind rule that matches user input in the bind request with an attribute value stored in the targeted entry

• By using the targetfilter keyword

With the targetfilter keyword you can specify an attribute value that appears only in the desired entry. For example, during the installation of the directory server, the following ACI is created:

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

This ACI can apply only to the o=example entry, because that is the only entry with an attribute o having the value example.

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

9.2.2.8 Specifying the Scope of an ACI

Usually an ACI has subtree scope. You can restrict the scope of an ACI by using the targetscope keyword with the following syntax:

(targetscope="expression")

where expression is one of the following:

base

The ACI applies to the target resource only.

onelevel

The ACI applies to the target resource's first-generation children.

subtree

The ACI applies to the target resource and the subtree below it.

subordinate

The ACI applies only to the subtree below the target resource.

If the targetscope is not specified, the default value is subtree. The following example restricts the ACI target match only to the entry with the distinguished name uid=bjensen,ou=People,dc=example,dc=com and any of the children one level below it:

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

Note:

The not-equal operator is not supported for the targetscope keyword.

9.2.2.9 Targeting LDAP Controls

To target LDAP controls, use the targetcontrol keyword and provide the control object identifier. The targetcontrol keyword uses the following syntax:

(targetcontrol="oid")

(targetcontrol!="oid")

You can target multiple LDAP controls by using the targetcontrol keyword with the following syntax:

(targetcontrol="oid1 || oid2... || oidN")

(targetcontrol!="oid1 || oid2... || oidN")

For example, to target both the get effective rights control and the proxied authorization control, use the following targetcontrol expression:

(targetcontrol = "1.3.6.1.4.1.42.2.27.9.5.2 || 2.16.840.1.113730.3.4.18")

Note:

The get effective rights control has OID value of 1.3.6.1.4.1.42.2.27.9.5.2. The proxy authorization V2 control has OID value of 2.16.840.1.113730.3.4.18.

9.2.2.10 Targeting LDAP Extended Operations

To target extended operations, use the extop keyword and provide the operation object identifier. The extop keyword uses the following syntax:

(extop= "oid")

(extop!= "oid")

You can target multiple extended operations by using the extop keyword with the following syntax:

(extop = "oid1 || oid2... || oidN")

(extop!= "oid1 || oid2... || oidN")

For example, to target both the StartTLS extended operation and the Password Modify extended operation, use the following extop expression:

(extop = "1.3.6.1.4.1.1466.20037 || 1.3.6.1.4.1.4203.1.11.1.")

Note:

Access control using the extop keyword with a StartTLS extended operation target must always be done using Global ACIs. The authorization entry in the StartTLS extended operation is null.

9.2.3 Setting Permissions

Permissions specify the type of access that 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

The following sections describe how to define permissions:

• About Access Permissions

• Overview of Rights Assignment

• Overview of Rights Required for LDAP Operations

• About Permissions in ACI Statement

9.2.3.1 About Access Permissions

You can explicitly allow or deny access permissions by using the allow or the deny keyword.

9.2.3.2 Overview of Rights Assignment

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 the directory entries and the attributes of entries specified in the ACI. This permission applies only to the search operation. (Compare the Read permission with the description of the Search permission that follows.)

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 entries. This permission applies only to the add operation.

Delete

Indicates whether users can delete entries. This permission applies only to the delete operation.

Search

Indicates whether users can search on the targets specified in the ACI. This permission applies only to the search operation. The Search right is checked once, and after the search is allowed or denied, it is not checked again. If the search is allowed, the read right is then applied to each entry to be returned as a result of the search and to each attribute of each entry.

Compare

Indicates whether 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 in an attribute of the target entry. The syntax of this attribute must be a distinguished name. This right is used only for group management. Selfwrite 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

Indicates whether the specified DN can 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. Moreover, you cannot grant proxy rights to the Directory Manager. An example is provided in About Proxy Authorization ACIs.

Import

Used by the modify DN operation. This access right indicates whether an entry can be imported to the specified DN.

Export

Used by the modify DN operation. This access right indicates whether an entry can be exported from the specified DN.

All

Indicates that the specified DN has the following rights to the targeted entry: read, write, search, delete, compare, and selfwrite. The All access right does not give the following rights to the target entry: proxy, import, and export.

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 does not usually make sense to grant write permission without granting read and search permissions.

9.2.3.3 Overview of Rights Required for LDAP Operations

This section describes the rights that you must grant to users depending on the type of LDAP operation that 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 the attribute type used in the new RDN. This right is granted by default but could be restricted using the targattrfilters 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.

The following example better illustrates the permissions that you must configure to enable users to search the directory. Consider the following search:

$ ldapsearch -h host -p port -D "uid=bjensen,dc=example,dc=com" \
  -j pwd-file -b "dc=example,dc=com" \
  "(objectclass=*)" mail

The following ACI is used to determine whether user 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. For the search operation to be successful, you must modify the ACI, as shown in the following example:

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

9.2.3.4 About Permissions in ACI Statement

In an ACI statement, permissions use the following syntax:

allow|deny (rights)

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

The all access right does not give the following rights to the target entry: proxy, import, and export.

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

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

9.3 Understanding Bind Rules

Depending on the ACIs defined for the directory, for certain operations, you must bind to the directory. You must analyze the bind rules to control access to directory information.

The following sections describe how bind rules are used to control access:

• Overview of Bind Rules

• Using Boolean Bind Rules

9.3.1 Overview of Bind Rules

Binding means logging in or authenticating yourself to the directory by providing a bind DN and password, or, if using SSL, a certificate. The credentials provided in the bind operation and the circumstances of the bind determine whether access to the directory is allowed or denied.

Every permission set in an ACI has a corresponding bind rule that details the required credentials and bind parameters.

A simple bind rule might require that the person accessing the directory belong to a specific group. A complex bind rule can state that a person must belong to a specific group and must log in from a machine with a specific IP address between 8 a.m. and 5 p.m.

Bind rules define who can access the directory, when, and from where. More specifically, bind rules can specify the following:

• Users, groups, and roles that are granted access

• Location from which an entity must bind (The location from which a user authenticates can be spoofed and can therefore not be trusted. Do not base ACIs on this information alone.)

• Time or day on which binding must occur

• Type of authentication that must be in use during binding

• Security strength factor (that is, the length of encryption key currently in use)

Additionally, bind rules can be complex constructions that combine these criteria by using Boolean operators, as described in Understanding Bind Rule Syntax.

The directory 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 RFC 4511 (http://www.ietf.org/rfc/rfc4511.txt) Lightweight Directory Access Protocol (LDAP): The Protocol. In summary, this means that 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 directory server handles this case correctly: it does not erroneously grant access because an Undefined value occurred in a complex Boolean expression.

9.3.2 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 must follow the bind rules to create valid expressions.

When creating boolean bind rules, always use parentheses to define the order in which rules are to be evaluated. A trailing semicolon is a required delimiter that must appear after the final rule.

For example, to bind with bindRuleA, and with either bindRuleB, or with either bindRuleC and bindRuleD, use the following syntax:

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

Using another example, the following bind rule is evaluated to be true if the bind DN client is accessed from within the example.com domain and is a member of either the administrators group or both the mail administrators and calendar administrators groups.

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

The || operator is allowed only in the groupdn bind rule keyword expression. For all other bind rule expressions, the or operator must be used.

9.4 Understanding Bind Rule Syntax

Whether access is allowed or denied depends on whether an ACI's bind rule is evaluated to be true.

The following sections describe the bind rule syntax and the various keywords that can be used to allow or deny access.

• Overview of Bind Rule Syntax

• Defining User Access (userdn Keyword)

• Defining Group Access Using groupdn Keyword

• Defining Access Based on Value Matching Using userattr Keyword

• Understanding How to Define Access From a Specific IP Address (ip Keyword)

• Understanding How to Define Access From a Specific Domain Using dns Keyword

• Understanding How to Define Access at a Specific Time of Day or Day of Week Using timeofday and dayofweek Keywords

• Understanding How to Define Access Based on Authentication Method Using authmethod Keyword

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

9.4.1 Overview of Bind Rule Syntax

Bind rules use one of the following patterns:

• keyword =" expression";

• keyword!=" expression";

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

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

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

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

Keyword	Valid Expressions	Wildcard Allowed?
Defining User Access (userdn Keyword)	ldap:///distinguishedName ldap:///all ldap:///anyone ldap:///self ldap:///parent ldap:///suffix??sub?(filter)	Allowed, in DN only
Defining Group Access Using groupdn Keyword	ldap:///DN	Not Allowed
Defining Access Based on Value Matching Using userattr Keyword	attribute#bindType or attribute#value	Not Allowed
Understanding How to Define Access From a Specific IP Address (ip Keyword)	IPaddress	Allowed
Understanding How to Define Access From a Specific Domain Using dns Keyword	DNShostName	Allowed
Understanding How to Define Access at a Specific Time of Day or Day of Week Using timeofday and dayofweek Keywords	sun mon tue wed thu fri sat	Not Allowed
Understanding How to Define Access at a Specific Time of Day or Day of Week Using timeofday and dayofweek Keywords	hhmm where hh is in the range 00-24 and mm is in the range 00-60	Not Allowed
Understanding How to Define Access Based on Authentication Method Using authmethod Keyword	none simple ssl sasl authenticationMethod	Not Allowed
Defining Access Based on a Connection's Security Strength Factor Using ssf Keyword	0-256	Not Allowed

The following sections provide additional information about the bind rule syntax for each keyword.

9.4.2 Defining User Access (userdn Keyword)

In this section you will learn about the procedural information to define user access with the userdn keyword.

It contains the following topics:

• About userdn Keyword

• Defining General Access Using all Keyword

• Defining Anonymous Access Using anyone Keyword

• Defining Self Access Using self Keyword

• Defining Parent Access Using parent Keyword

• Specifying Users With LDAP URLs

• Specifying Users With Wildcards

• Specifying Users With a Logical OR of LDAP URLs

• Excluding Specific LDAP URLs

9.4.2.1 About userdn Keyword

User access is defined using the userdn keyword. The userdn keyword requires one or more valid distinguished names in the following format:

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

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

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

userdn = "ldap:///anyone"

Both anonymous and authenticated users

userdn = "ldap:///all"

Only authenticated users

userdn = "ldap:///self"

Only the same user as the target entry of the ACI

userdn = "ldap:///parent"

Only the parent entry of the ACI target

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

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

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

9.4.2.2 Defining General Access Using all Keyword

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

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

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

9.4.2.3 Defining Anonymous Access Using anyone Keyword

Granting anonymous access to the directory means that anyone can access it without providing a bind DN or password, regardless of the circumstances of the bind. You can limit anonymous access to specific types of access (for example, access for read or access for search) or to specific subtrees or individual entries within the directory. Anonymous access using the anyone keyword also allows access by any authenticated user.

For example, to allow anonymous read and search access to the entire example.com tree, create the following ACI on the dc=example,dc=com node:

aci: (version 3.0; acl "anonymous-read-search";
allow (read, search) userdn = "ldap:///anyone";)

9.4.2.4 Defining Self Access Using self Keyword

Specifies that users are granted or denied access to their own entries. In this case, access is granted or denied if the bind DN matches the DN of the targeted entry. For example, to grant all users in the example.com tree write access to their userPassword attribute, create the following ACI on the dc=example,dc=com node.

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

9.4.2.5 Defining Parent Access Using parent Keyword

Specifies that users are granted or denied access to the entry only if their bind DN is the parent of the targeted entry. For example, to allow users to modify any child entries of their bind DN, create the following ACI on the dc=example,dc=com node:

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

9.4.2.6 Specifying Users With LDAP URLs

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

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

For example, all users in the accounting and engineering branches of the example.com tree would be granted or denied access to the targeted resource dynamically based on the following URL:

userdn = "ldap:///dc=example,dc=com??sub?(|(ou=eng)(ou=acct))"

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

9.4.2.7 Specifying Users With Wildcards

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

9.4.2.8 Specifying Users With a Logical OR of LDAP URLs

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

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

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

9.4.2.9 Excluding Specific LDAP URLs

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

userdn != "ldap:///uid=*,ou=Accounting,dc=example,dc=com";

The bind rule is evaluated to be true if the client is not binding as a UID-based distinguished name in the accounting subtree. This bind rule makes sense only if the targeted entry is not under the accounting branch of the directory tree.

9.4.3 Defining Group Access Using groupdn Keyword

Members of a specific group can access a targeted resource. This is known as group access. Group access is defined using the groupdn keyword to specify that access to a targeted entry is granted or denied if the user binds using a DN that belongs to a specific group.

The following topics describe how to define group access using groupdn keyword:

• About groupdn Keyword

• Specifying a Group With a Single LDAP URL

• Specifying a Group With a Logical OR of LDAP URLs

9.4.3.1 About groupdn Keyword

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

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

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

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

9.4.3.2 Specifying a Group With a Single LDAP URL

To specify a group with a single LDAP URL, use the following format:

groupdn = "ldap:///cn=Administrators,dc=example,dc=com";

The bind rule is evaluated to be true if the bind DN belongs to the Administrators group. For example, to grant the Administrators group permission to write to the entire directory tree, create the following ACI on the dc=example,dc=com node:

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

9.4.3.3 Specifying a Group With a Logical OR of LDAP URLs

To specify a group with a logical OR of LDAP URL, use the following format:

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.

9.4.4 Defining Access Based on Value Matching Using userattr Keyword

The userattr keyword can be used to specify which attribute values must match between the entry used to bind (bind entry) and the targeted entry.

A userattr expression has two formats, a bind-type format and an attribute-value format.

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

• Overview of Bind-Type Format

• Overview of Attribute-Value Format

• Example for USERDN Bind Type

• Example for GROUPDN Bind Type

• Example for LDAPURL Bind Type

• Example for Attribute Value

• About Inheritance Level

• Example for Inheritance

• Adding Permissions to a User

9.4.4.1 Overview of Bind-Type Format

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

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

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

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

The bind-type userattr format uses this syntax:

userattr = "attrName#bindType"

where:

attrName

Is the name of the attribute in the target entry.

bindType

Must be one of the following:

• USERDN — The value of attrName must match the bind DN.

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

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

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

9.4.4.2 Overview of Attribute-Value Format

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

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

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

The attribute value userattr format uses this syntax:

userattr = "attrName#attrValue"

where:

attrName

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

attrValue

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

9.4.4.3 Example for USERDN Bind Type

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

userattr = "manager#USERDN"

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

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

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

9.4.4.4 Example for GROUPDN Bind Type

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

userattr = "owner#GROUPDN"

The bind rule is evaluated to be true if the bind DN is a member of the group specified in the owner attribute of the target entry.

9.4.4.5 Example for LDAPURL Bind Type

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

userattr = "aciurl#LDAPURL"

The attribute aciurl is an example only.

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

9.4.4.6 Example for Attribute Value

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

userattr = "favoriteBeverage#Water"

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

9.4.4.7 About Inheritance Level

When you use the userattr keyword to associate the entry used to bind with the target entry, the ACI applies only to the target specified and not to the entries below it. In some circumstances, you might want to extend the application of the ACI several levels below the targeted entry. This is possible by using the parent keyword and specifying the number of levels below the target that should inherit the ACI.

When you use the userattr keyword in association with the parent keyword, the syntax is as shown in the following example:

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

where:

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

• attribute is the attribute targeted by the userattr.

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

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

9.4.4.8 Example for Inheritance

The following example indicates that user bjensen is allowed to read and search the cn=Profiles entry as well as the first level of child entries, which includes cn=mail and cn=news.

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

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

• Explicitly set read and search access for user bjensen on the cn=Profiles, cn=mail, and cn=news entries in the directory.

• Add the owner attribute and the following ACI to the cn=mail, cn=Profiles and cn=news,cn=Profiles entries:

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

9.4.4.9 Adding Permissions to a User

If you use the userattr keyword with all or add permissions, you might find that the behavior of the directory server is not what you expect. Typically, when a new entry is created in the directory, the directory server evaluates access rights on the entry being created, and not on the parent entry. However, for ACIs using the userattr keyword, this behavior could create a security hole, so the directory server's normal behavior is modified to avoid it.

Consider the following example ACI:

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

This ACI grants managers all rights on the entries of employees that report to them. However, because access rights are evaluated on the entry being created, this type of ACI would also allow any employee to create an entry in which the manager attribute is set to their own DN. For example, disgruntled employee Joe, cn=Joe,ou=eng,dc=example,dc=com, might want to create an entry in the Human Resources branch of the tree to use (or misuse) the privileges granted to Human Resources employees.

He could do this by creating the following entry:

dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com
objectclass: top
...
cn: Trojan Horse
manager: cn=Joe,ou=eng,dc=example,dc=com

To avoid this type of security threat, the ACI evaluation process does not grant add permission at level 0, that is, to the entry itself. You can, however, use the parent keyword to grant add rights below existing entries. You must specify the number of levels below the parent for add rights. For example, the following ACI allows child entries to be added to any entry in the dc=example,dc=com that has a manager attribute that matches the bind DN:

aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0; acl "parent-access"; allow (add)
userattr = "parent[1].manager#USERDN";)

This ACI ensures that add permission is granted only to users whose bind DN matches the manager attribute of the parent entry.

9.4.5 Understanding How to Define Access From a Specific IP Address (ip Keyword)

Using bind rules, you can indicate that the bind operation must originate from a specific IP address. This is often used to force all directory updates to occur from a given machine or network domain.

The LDIF syntax for setting a bind rule based on an IP address is shown in the following examples:

ip = "IPaddressList"
ip != "IPaddressList"

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

• A specific IPv4 address, such as 123.45.6.7

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

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

• An IPv4 address or subnetwork with a subnetwork mask, such as 123.45.6.*+255.255.255.192

• An IPv6 address in any of its legal forms and contained in square brackets [and], as defined by RFC 2373 (http://www.ietf.org/rfc/rfc2373.txt) and RFC 2732 (http://www.ietf.org/rfc/rfc2732.txt). The following addresses are equivalent:

  • [12AB:0000:0000:CD30:0000:0000:0000:0000]

  • [12AB::CD30:0:0:0:0]

  • [12AB:0:0:CD30::]

• An IPv6 address with a subnet prefix length, such as [12AB::CD30:0:0:0:0]/60

The bind rule is evaluated to be true if the client accessing the directory is located at the named IP address, which can be useful for allowing certain kinds of directory access only from a specific subnet or machine.

Note:

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.

9.4.6 Understanding How to Define Access From a Specific Domain Using dns Keyword

A bind rule can specify that the bind operation must originate from a particular domain or host machine. This is often used to force all directory updates to occur from a given machine or network domain.

The LDIF syntax for setting a bind rule based on the DNS host name is as shown here:

dns = "DNShostname"
dns != "DNShostname"

Caution:

The dns keyword requires that the naming service used on your machine is DNS. If the naming service is not DNS, use the ip keyword instead.

The dns keyword requires a fully qualified DNS domain name. Granting access to a host without specifying the domain creates a potential security threat. For example, the following expression is allowed but not recommended:

dns = "legend.eng";

You should use a fully qualified name such as:

dns = "legend.eng.example.com";

The dns keyword allows wildcards. For example:

dns = "*.example.com";

The bind rule is evaluated to be true if the client accessing the directory is located in the named domain. This can be useful for allowing access only from a specific domain.

Note:

Wildcards do not work if your system uses a naming service other than DNS. In this case, if you want to restrict access to a particular domain, then use the ip keyword, as described in Understanding How to Define Access From a Specific IP Address (ip Keyword).

9.4.7 Understanding How to Define Access at a Specific Time of Day or Day of Week Using timeofday and dayofweek Keywords

You can use bind rules to specify that binding can only occur at a certain time of day or on a certain day of the week. For example, you can set a rule that allows access only if the time is between the hours of 8 a.m. and 5 p.m. Monday through Friday. The time used to evaluate access rights is the time on the directory server, not the time on the client.

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

timeofday operator "time"

where operator can be one of the following symbols:

• = (equal to)

• != {not equal to}

• > (greater than)

• >= (greater than or equal to)

• < (less than)

• <= (less than or equal to)

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

• timeofday = "1200"; is true if the client is accessing the directory during the minute that the system clock shows noon.

• timeofday!= "0100"; is true for access at any other time than 1 a.m.

• timeofday> "0800"; is true for access from 8:01 a.m. through 11:59 p.m.

• timeofday>= "0800"; is true for access from 8:00 a.m. through 11:59 p.m.

• timeofday< "1800"; is true for access from 12:00 midnight through 5:59 p.m.

The time and date on the directory server are used for the evaluation of the timeofday and dayofweek bind rules and not the time on the client.

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

dayofweek = "day1, day2 ..."

The possible values for the dayofweek keyword are the English three-letter abbreviations for the days of the week: sun, mon, tue, wed, thu, fri, sat. Specify all days you want to grant access, for example:

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

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

9.4.8 Understanding How to Define Access Based on Authentication Method Using authmethod Keyword

You can set bind rules that state that a client must bind to the directory using a specific authentication method.

The following authentication methods are available:

None

Authentication is not required. This is the default. It represents anonymous access.

Simple

The client must provide a user name and password to bind to the directory.

SSL

The client must bind to the directory over a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection.

For SSL, the connection is established to the LDAPS second port. For TLS, the connection is established through a Start TLS operation. In both cases, you must provide a certificate. For information about setting up SSL, see Using SASL Authentication.

SASL

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

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

authmethod = "authentication_method"

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

The following examples show typical specifications of the authmethod keyword:

authmethod = "none"

Authentication is not checked during bind rule evaluation.

authmethod = "simple"

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

authmethod = "ssl"

The bind rule is evaluated to be true if the client authenticates to the directory using a certificate over LDAPS. It is not true if the client authenticates using simple authentication (bind DN and password) over LDAPS.

authmethod = "sasl DIGEST-MD5"

The bind rule is evaluated to be true if the client is accessing the directory using the SASL DIGEST-MD5 mechanism. Other supported SASL mechanisms are EXTERNAL and GSSAPI.

9.4.9 Defining Access Based on a Connection's Security Strength Factor Using ssf Keyword

In this section you will learn how to define access based on a connection's security strength factor keyword.

It contains the following topics:

• Overview of Bind Rule Using Security Strength Factor

• DIGEST-MD5 QOP Key Size Mapping

• TLS Cipher Key Size Mapping

• Example of Using SSF Strength

9.4.9.1 Overview of Bind Rule Using Security Strength Factor

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

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

ssf operator "strength"

where operator can be one of the following symbols:

• = (equal to)

• != (not equal to)

• > (greater than)

• >= (greater than or equal to)

• < (less than)

• <= less than or equal to

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

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

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

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

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

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

Clear connections have an SSF of 0.

9.4.9.2 DIGEST-MD5 QOP Key Size Mapping

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

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

9.4.9.3 TLS Cipher Key Size Mapping

The following table illustrates the TLS RFC to cipher key size mapping.

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

9.4.9.4 Example of Using SSF Strength

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

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

9.5 Compatibility With the Oracle Directory Server Enterprise Edition Access Control Model

It’s time that we delve into the differences between the Oracle Unified Directory access control model with the access control model provided with Oracle Directory Server Enterprise Edition.

This section contains the following topics:

• Global Access Control Instructions

• About the Distinguished Name (DN) Wildcard Matching

• About the Impact of Privilege Subsystem

• About targetscope Keyword

• About LDAP Modify Increment Extension

• About Macro Support

• About roledn Keyword

9.5.1 Global Access Control Instructions

Global ACI configuration differs from the Oracle Directory Server Enterprise Edition global ACI implementation in some ways. You will learn about those differences in this section.

The Global ACI implementation differs in two ways from Oracle Directory Server Enterprise Edition:

• The ds-config-global-aci attribute specifies a global ACI in the cn=Access Control Handler,cn=config entry (see Understanding Access Control Principles) rather than placing the ACI in the root DSE entry.

• The scope of the global ACI can be narrowed by specifying a target keyword in the ACI. For example, the following global ACI restricts anonymous read access to entries under the suffix dc=example,dc=com:

  ds-cfg-global-aci: (target="dc=example,dc=com")
  (targetattr!="userPassword||authPassword")
  (version 3.0; acl "Anonymous read access only under dc=example,dc=com suffix";
  allow (read,search,compare) userdn="ldap:///anyone";)
  

Removing the (target="dc=example,dc=com") expression would make the ACI global to all entries in Oracle Unified Directory.

9.5.2 About the Distinguished Name (DN) Wildcard Matching

Wild cards appear as asterisk characters and are used in the expression for the target keyword. The asterisk matches an attribute value, a substring of a value, or a DN component.

The ACI DN wildcard matching implementation supports the following usage:

• Any number of wildcards can appear in Relative Distinguished Name (RDN) attribute values, where they match zero or more characters (similar to substring filters). For example, the bind rule matches the following DNs: uid=bob jensen,dc=example,dc=com and uid=bjensen,dc=example,dc=com:

  userdn="ldap:///uid=b*jensen*,dc=example,dc=com"
  

  It does not match the DN cn=bill jensen,dc=example,dc=com because the attribute type of the first RDN does not match.

• A single wildcard can also be used to match any RDN attribute type. (The wildcard in this case can be omitted as a shorthand). For example, these two bind rules behave exactly the same:

  userdn="ldap:///*=bjensen, dc=example, dc=com"
  userdn="ldap:///bjensen, dc=example, dc=com"
  

  They both match the following DNs: uid=bjensen,dc=example,dc=com and cn=bjensen,dc=example,dc=com.

• A single wildcard can be used to match exactly one RDN component, which can be single or multivalued). For example, the following bind rule matches the DNs uid=jensen,dc=example,dc=com and cn=smith,dc=example,dc=com:

  userdn="ldap:///*,dc=example,dc=com"
  

• A double wildcard can be used to match one or more RDN components. For example, the following bind rule matches the DNs uid=jensen,ou=people,dc=example,dc=com and uid=jensen,ou=sales,ou=people,dc=example,dc=com:

  userdn="ldap:///uid=bjensen,**,dc=example,dc=com"

9.5.3 About the Impact of Privilege Subsystem

The Privilege Subsystem allows you to assign refined privileges to users who might require only a specific set of root user access privileges.Oracle Directory Server Enterprise Edition does not support privileges.

The privilege subsystem (discussed in Root Users and the Privilege Subsystem) impacts ACIs in two ways:

• Users with ds-privilege-name: bypass-acl privileges can bypass access control evaluation.

• Users needing to modify access control rules need the ds-privilege-name: modify-acl privilege.

Note:

Use of the Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control (http://www.ietf.org/rfc/rfc4370.txt) requires the bind user to have the ds-privilege-name: proxied-auth privilege. When the proxied authorization control is used, evaluation of the ds-privilege-name: bypass-acl privilege is performed using the bind user, not the proxied user.

In general, a user should not have both the ds-privilege-name: proxied-auth and ds-privilege-name: bypass-acl privileges simultaneously since this allows a proxied user to bypass ACI access evaluation.

9.5.4 About targetscope Keyword

The targetscope keyword differs from Oracle Directory Server Enterprise Edition by including a new scope.

subordinate

Restricts the ACI to the subtree below the target resource only.

9.5.5 About LDAP Modify Increment Extension

Oracle Unified Directory supports the LDAP Modify-Increment Extension.

This extension is not supported in Oracle Directory Server Enterprise Edition. Attributes that are to be incremented must have write permissions. For more information, see https://www.ietf.org/rfc/rfc4525.txt.

9.5.6 About Macro Support

Oracle Unified Directory supports macros in ACIs.

9.5.7 About roledn Keyword

Roles are not supported in Oracle Unified Directory, so the roledn keyword should not be used. Equivalent functionality can be achieved by using groups.

9.6 Using Macro ACIs for Advanced Access Control

Organizations that use repeating directory tree structures can enhance the performance and ACI memory usage by using macros to optimize the number of ACIs in the directory tree.

When you reduce the number of ACIs in your directory tree, it is easier to manage your access control policy.

This section describes macro ACIs and its usage, and contains the following topics:

• What are Macros?

• Example of Macro Access Control Instructions

• Understanding Macro Access Control Instructions

9.6.1 What are Macros?

Macros are placeholders used to represent a DN or a part of a DN in an ACI. You can use a macro to represent a DN in the target section of the ACI, in the bind rule section, or in both.

In practice, when Directory Server receives an incoming LDAP operation, the ACI macros are matched against the resource targeted by the LDAP operation. The matching occurs to determine a matching substring, if it exists. If a match exists, the bind rule-side macro is expanded using the matched substring, and access to the resource is determined by evaluating that expanded bind rule.

9.6.2 Example of Macro Access Control Instructions

The advantage of using macro ACIs and how they work are best explained through an example. Figure 9-1 shows a directory tree that uses macro ACIs to effectively reduce the total number of ACIs.

Figure 9-1 Example Directory Tree for Macro ACIs

This illustration uses repeating pattern of subdomains with the same tree structure (ou=groups, ou=people). This pattern is also repeated across the tree because the example.com directory tree stores the suffixes dc=hostedCompany2, dc=example,dc=com and dc=hostedCompany3,dc=example,dc=com not shown in the preceding graphic.

The ACIs that apply in the directory tree also have a repeating pattern. For example, the following ACI is located on the dc=hostedCompany1,dc=example,dc=com node:

aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search) 
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)

This ACI grants read and search rights to the DomainAdmins group to any entry in the dc=hostedCompany1,dc=example,dc=com tree.

The following ACI is located on the dc=hostedCompany1,dc=example,dc=com node:

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)

The following ACI is located on the dc=subdomain1, dc=hostedCompany1, dc=example, dc=com node:

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,
 dc=example,dc=com";)

The following ACI is located on the dc=hostedCompany2, dc=example, dc=com node:

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2, dc=example,dc=com";)

The following ACI is located on the dc=subdomain1, dc=hostedCompany2, dc=example, dc=com node:

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany2,
 dc=example,dc=com";)

In the preceding four ACIs, the only difference is the DN that is specified in the groupdn keyword. By using a macro for the DN, it is possible to replace these ACIs with a single ACI at the root of the tree on the dc=example,dc=com node. This macro ACI reads as follows:

aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
 (targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search) 
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

The target keyword, which was not previously used, is utilized in the new ACI.

In this example, the number of ACIs is reduced from four to one. The real determining factor is the number of repeating patterns you have down and across your directory tree.

9.6.3 Understanding Macro Access Control Instructions

This section provides a description of macro access control instructions and the evaluation mechanism for macro ACIs.

It contains the following topics:

• About Macro Access Control Instructions

• Matching for ($dn) in the Target

• About Macro Matching for ($attr.attrName)

9.6.3.1 About Macro Access Control Instructions

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

In this section, the ACI keywords used to provide bind credentials, such as userdn, roledn, groupdn, and userattr are collectively called the subject of the ACI. The subject determines to whom the ACI applies.

Table 9-2 lists the macros that can be used to replace specific ACI keywords.

Table 9-2 Macro ACI Keywords

Macro	Description	ACI Keywords
($dn)	For matching in the target, and direct substitution in the subject. For example, it will match either target or targetfilter and substitute the matched value into userdn, groupdn, or userattr.	(target, targetfilter) and (userdn, groupdn, userattr)
[$dn]	For substituting multiple RDNs that work in subtrees of the subject.	(targetfilter) and (userdn, groupdn, userattr)
($attr.attrName)	For substituting the value of the attributeName attribute from the target entry into the subject.	userdn, groupdn, userattr

The following restrictions apply to macro ACI keywords:

• If you use ($dn) macro in a subject, then you must define a target that contains ($dn).

• If you use [$dn] macro in a subject, then you must define a target that contains ($dn).

• You can combine both the ($dn) macro and the [$dn] macro with the ($attr.attrName) macro in a subject.

9.6.3.2 Matching for ($dn) in the Target

The ($dn) macro in the target of an ACI determines the substitution value by comparing it to the entry targeted by the LDAP request. For example, you have an LDAP request targeted at this entry:

cn=all, ou=groups, dc=subdomain1, dc=hostedCompany1, dc=example, dc=com

In addition, you have an ACI that defines the target as follows:

(target="ldap:///ou=Groups,($dn),dc=example,dc=com")

The ($dn) macro matches with "dc=subdomain1, dc=hostedCompany1". This substring is then used for substitutions in the subject of the ACI.

Substituting ($dn) in the Subject

In the subject of the ACI, the ($dn) macro is replaced by the entire substring that matches in the target. For example:

groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com" 

In this scenario, if the string matching ($dn) in the target is dc=subdomain1, dc=hostedCompany1, then the same string is used in the subject. The subject is then expanded as follows:

groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"

In the targetfilter of the ACI, the ($dn) macro is replaced with the entire substring that matches in the target. For example:

(targetattr="*")(targetfilter=(&(objectClass=nsManagedPerson)
(!(memberOf=cn=ServiceAdministrators,ou=Groups,($dn),o=ace industry,c=us))
(!(memberOf=cn=Service Help Desk Administrators,ou=Groups,
($dn),o=ace industry,c=us))))

The targetfilter becomes:

(targetattr="*")(targetfilter=(&(objectClass=nsManagedPerson)
(!(memberOf=cn=ServiceAdministrators,ou=Groups,dc=subdomain1,
dc=hostedCompany1,o=ace industry,c=us))
(!(memberOf=cn=Service Help Desk
Administrators,ou=Groups,dc=subdomain1,dc=hostedCompany1,o=ace industry,c=us)))) 

After the macro has been expanded, Directory Server evaluates the ACI following the normal process to determine whether access is granted.

Note:

Unlike a standard ACI, an ACI that uses macro substitution does not necessarily grant access to the child of the targeted entry. This is because when the child DN is the target, the substitution might not create a valid DN in the subject string.

Substituting [$dn] in the Subject

The substitution mechanism for [$dn] is slightly different than for ($dn). The DN of the targeted resource is examined several times, each time dropping the left-most RDN component, until a match is found.

Consider a scenario in which you have an LDAP request targeted at the cn=all,ou=groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com subtree, and the following ACI:

aci: (targetattr="*") (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:/cn=DomainAdmins,ou=Groups,[$dn], dc=example,dc=com";)

The server proceeds as follows to expand this ACI:

1. The server verifies that the ($dn) in target matches dc=subdomain1, dc=hostedCompany1.
2. The server replaces [$dn] in the subject with dc=subdomain1, dc=hostedCompany1.

   The resulting subject is groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com". If access is granted, because bind DN is a member of that group, macro expansion stops, and the ACI is evaluated. If bind DN is not a member, the process continues.

3. The server replaces [$dn] in the subject with dc=hostedCompany1.

   The resulting subject is groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com". Bind DN is again tested for being a member of this group and if it is, the ACI is evaluated fully. However, if bind DN is not a member, macro expansion stops with the last RDN of the matched value, and ACI evaluation is finished for this ACI.

   The advantage of the [$dn] macro is that it provides a flexible mechanism to grant domain-level administrators access to all the subdomains in the directory tree. Therefore, the [$dn] macro is useful for expressing a hierarchical relationship between domains.

   For example, consider the following ACI:

   aci: (target="ldap:///ou=*,($dn),dc=example,dc=com") (targetattr="*")
    (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; 
   acl "Domain access"; allow (read,search) groupdn= "ldap:/cn=DomainAdmins,
   ou=Groups,[$dn],dc=example,dc=com";) 
   

   The ACI grants access to the members of cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com to all of the subdomains under dc=hostedCompany1. Thus, an administrator who belongs to that group could access, for example, the subtree ou=people,dc=subdomain1.1,dc=subdomain1.

   However, at the same time, members of cn=DomainAdmins,ou=Groups, dc=subdomain1.1 would be denied access to the ou=people,dc=subdomain1, dc=hostedCompany1 and ou=people,dc=hostedCompany1 nodes.

9.6.3.3 About Macro Matching for ($attr.attrName)

The ($attr.attrname) macro is always used in the subject part of an ACI. For example, you could define the following groupdn:

groupdn = "ldap:/cn=DomainAdmins,ou=($attr.ou),dc=HostedCompany1,dc=example,dc=com"

Now, assume that the server receives an LDAP operation that is targeted at the following entry:

dn: cn=Babs Jensen,ou=People,dc=HostedCompany1,dc=example,dc=com
cn: Babs Jensen
sn: Jensen
ou: Sales ...

To evaluate the groupdn part of the ACI, the server reads the value of the ou attribute stored in the targeted entry. The server then substitutes this value in the subject to expand the macro. In this example, the groupdn is expanded as follows:

groupdn= "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1,dc=example,dc=com"

Directory Server then evaluates the ACI according to the normal ACI evaluation algorithm.

When the attribute that is named in the macro is multivalued, each value is used in turn to expand the macro. The first value that provides a successful match is used.

9.7 Understanding Virtual Access Control Instructions

In this section you will learn about the principles of the access control mechanism provided with the proxy server.

It contains the following topics:

• About the Virtual Access Control Instructions

• About the Virtual Access Control Instructions Syntax

• About the Virtual Access Control Instructions Configuration Model

• Considerations for Virtual Access Control Instructions Usage

Note:

To use the virtual directory capabilities described here, you must have a valid Oracle Directory Service Plus license.

9.7.1 About the Virtual Access Control Instructions

Oracle Unified Directory allows virtualization by exposing virtual directory view of data. Therefore, Oracle Unified Directory is responsible for controlling who can access that data, and what parts of the data can be accessed.

To control access to virtual directory view of data, you can define virtual ACIs. When Oracle Unified Directory receives a request on a virtual directory data view, it uses the virtual ACIs, and any authentication information provided by the user, to allow or deny access to the information that is requested.

Virtual ACI allows you to define ACIs that apply at workflow level. This means that you can apply virtual ACIs to workflows containing any kind of workflow elements.

9.7.2 About the Virtual Access Control Instructions Syntax

Virtual ACIs have the same syntax as ACI with some restrictions defined in this section.

For more information about the ACI syntax, see Understanding the Syntax of Access Control Instructions. Only bind rules with following keywords are supported:

• userdn

• ip

• dns

• timeofday and dayofweek

• authmethod

• ssf

  This is Security Strength Factor. For more information, see Defining Access Based on a Connection's Security Strength Factor Using ssf Keyword.

9.7.3 About the Virtual Access Control Instructions Configuration Model

You can define virtual ACIs for each workflow in the network group. However, each workflow can use or not use virtual ACIs.

The virtual-aci-mode property of workflow allows you to specify if virtual ACIs should be used or not. If virtual-aci-mode is set to true, then all operations handling the ACI attribute manage this attribute as a virtual ACI. Attribute is no longer stored along with user data, but is stored in a specific directory information tree (DIT) known as "cn=virtual acis."

For each workflow, you can define the access control group to use using the access-control-group property. If the virtual ACI feature is disabled, then the workflow can only use the Local Backends access control group. If the virtual ACI feature is enabled, then you can use any access control group.

9.7.4 Considerations for Virtual Access Control Instructions Usage

You must bear in my mind some restrictions while implementing virtual ACIs.

• If you install as directory server, then virtual ACIs are not supported.

• If you install Oracle Unified Directory as proxy server, then you can use virtual ACIs in any supported deployment.

• Virtual ACIs does not support all types of bind rules. For more information about supported bind rules, see About the Virtual Access Control Instructions Syntax.

• Global ACIs apply, if virtual ACIs are enabled.

• You can enable replication of cn=virtual acis. To do so, you must ensure that configuration of access control groups are identical on replicated servers.