| Oracle® Fusion Middleware Administrator's Guide for Oracle Unified Directory 11g Release 2 (11.1.2) Part Number E22648-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Unified Directory 11g Release 2 (11.1.2) Part Number E22648-02 |
|
|
PDF · Mobi · ePub |
This chapter contains reference information about the directory server access control model. For information about configuring access control in the directory server, see Chapter 21, "Controlling Access To Data."
This chapter covers the following topics:
This section describes the principles of the access control mechanism provided with the directory server.
See also Section 21.1, "Managing Global ACIs With dsconfig".
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.
Access control instructions 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:
Determines the entry or attributes to which permissions apply.
Defines what operations are allowed or denied.
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 Section 7.2, "ACI Syntax."
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.
You can configure access control centrally by using dsconfig 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!="userPassword||authPassword")(version 3.0; acl : "Anonymous read access"; allow (read,search,compare) : userdn="ldap:///anyone";)", (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 Section 21.1, "Managing Global ACIs With dsconfig."
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. The default ACIs define anonymous read access and allow users to modify their own entries, except for attributes needed for security. For more information, see Section 21.1.1, "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.
Be aware of the following limitations when you create an access control policy for your directory service:
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.
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.
ACIs are complex structures with many possible variations. The following sections describe the syntax of an ACI in detail.
See also Section 7.4, "Bind Rule Syntax."
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.
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:
Section 7.2.2.4, "To Target Entries or Attributes Using LDAP Filters"
Section 7.2.2.5, "To Target Attribute Values Using LDAP Filters"
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 7-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 is dependent 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 7-1 LDIF Target Keywords
| Keyword | Valid Expressions | Wildcard Allowed? |
|---|---|---|
|
|
|
Allowed |
|
|
attribute |
Allowed |
|
|
LDAPfilter |
Allowed |
|
|
LDAPoperation |
Allowed |
|
|
|
Not Allowed |
|
|
oid |
Not Allowed |
|
|
oid |
Not Allowed |
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 (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.
In addition to targeting directory entries, you can also target one or more attributes (or all but 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")
The preceding example does not return operational attributes.
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.
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.
You can 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 Appendix D, "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:=<= Qu?bec)")
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.
You can use access control to target specific attribute values. This means that you can grant or deny permissions on an attribute if that attribute's value meets the criteria defined in the ACI. An ACI that grants or denies access based on an attribute's value is called a value-based ACI.
For example, you 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 Appendix D, "search filter" that apply 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*)")
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.
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:
baseThe ACI applies to the target resource only.
onelevelThe ACI applies to the target resource's first-generation children.
subtreeThe ACI applies to the target resource and the subtree below it.
subordinateThe 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.
To target LDAP controls, use the targetcontrol keyword and provide the control Appendix D, "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 Appendix D, "get effective rights control" and the Appendix D, "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.
To target extended operations, use the extop keyword and provide the operation Appendix D, "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 Appendix D, "StartTLS extended operation" and the Appendix D, "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.
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:
You can explicitly allow or deny access permissions by using the allow or the deny keyword.
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:
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.)
Indicates whether users can modify an entry by adding, modifying, or deleting attributes. This permission applies to the modify and modRDN operations.
Indicates whether users can create entries. This permission applies only to the add operation.
Indicates whether users can delete entries. This permission applies only to the delete operation.
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.
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.
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).
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 Section 21.5, "Proxy Authorization ACIs."
Used by the modify DN operation. This access right indicates whether an entry can be imported to the specified DN.
Used by the modify DN operation. This access right indicates whether an entry can be exported from the specified DN.
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.
This section describes the rights that you need to 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 permissions you need to set up to allow users to search the directory are more readily understood with an example. 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";)
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, provided that 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;)
Depending on the ACIs defined for the directory, for certain operations, you need to bind to the directory. The following sections describe how bind rules are used to control access:
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 Section 7.4, "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.
Bind rules can be complex expressions that use the Boolean expressions AND,OR, and NOT to set very precise access rules. 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.
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.
Section 7.4.4, "Defining Access Based on Value Matching (userattr Keyword)"
Section 7.4.5, "Defining Access From a Specific IP Address (ip Keyword)"
Section 7.4.6, "Defining Access From a Specific Domain (dns Keyword)"
Section 7.4.8, "Defining Access Based on Authentication Method (authmethod Keyword)"
Section 7.4.9, "Defining Access Based on a Connection's Security Strength Factor (ssf Keyword)"
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? |
|---|---|---|
|
|
Allowed, in DN only |
|
|
|
Not Allowed |
|
|
attribute |
Not Allowed |
|
|
IPaddress |
Allowed |
|
|
DNShostName |
Allowed |
|
|
Defining Access at a Specific Time of Day or Day of Week ( |
|
Not Allowed |
|
Defining Access at a Specific Time of Day or Day of Week ( |
hhmm where hh is in the range |
Not Allowed |
|
Defining Access Based on Authentication Method ( |
authenticationMethod |
Not Allowed |
|
Defining Access Based on a Connection's Security Strength Factor ( |
0-256 |
Not Allowed |
The following sections provide additional information about the bind rule syntax for each keyword.
userdn Keyword)User access is defined using the userdn keyword. The userdn keyword requires one or more valid distinguished names in the following format:
userdn = "ldap:///dn [|| ldap:///dn]..."
userdn!= "ldap:///dn [|| ldap:///dn]..."
where dn can be a DN or one of the expressions anyone, all, self, or parent. These expressions refer to the following users:
userdn = "ldap:///anyone"Both anonymous and authenticated users
userdn = "ldap:///all"Only authenticated users
userdn = "ldap:///self"Only the same user as the target entry of the ACI
userdn = "ldap:///parent"Only the parent entry of the ACI target
The userdn keyword can also be expressed as an LDAP filter in this form:
userdn = ldap:///suffix??sub?(filter)
Characters that are syntactically significant for a DN, such as commas, must be escaped with a single backslash (\).
The following sections describe how to define user access with the userdn keyword:
Section 7.4.2.2, "Defining Anonymous Access (anyone Keyword)"
Section 7.4.2.7, "Specifying Users With a Logical OR of LDAP URLs"
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";)
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";)
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";)
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";)
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.
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.
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.
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.
groupdn Keyword)Members of a specific group can access a targeted resource. This is known as group access. Group access is defined using the groupdn keyword to specify that access to a targeted entry is granted or denied if the user binds using a DN that belongs to a specific group.
The groupdn keyword requires the distinguished name of one or more groups in the following format:
groupdn="ldap:///groupDN [|| ldap:///groupDN]..."
The bind rule is evaluated to be true if the bind DN belongs to a group specified by any of the group DNs. The following section give examples using the groupdn keyword.
Characters that are syntactically significant for a DN, such as commas, must be escaped with a single backslash (\).
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";)
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.
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:
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:
Is the name of the attribute in the target entry.
Must be one of the following:
USERDN — The value of attrName must match the bind DN.
GROUPDN — The value of attrName is a group that must contain the bind DN.
LDAPURL — The value of attrName is an Appendix D, "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 Section 7.4.4.7, "Inheritance" for more details on this keyword.
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:
The name of the attribute in both the target and bind entries.
The string representing the attribute value (not USERDN, GROUPDN or LDAPURL).
USERDN Bind Type ExampleThe following example of a bind rule userattr keyword expression specifies a match between the bind DN and the value of the target entry attribute manager.
userattr = "manager#USERDN"
This bind rule is evaluated to be true if the bind DN matches the value of the manager attribute in the target entry. The manager attribute in the target entry must match the bind DN. Wildcards are not allowed.
The following example ACI grants a manager full access to all user attributes of entries located in the subtree under the DN dc=example, dc=comm:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0;acl "manager all access"; allow (all) userattr = "manager#USERDN";)
GROUPDN Bind Type ExampleThis is an example of a bind rule userattr keyword expression specifying an attribute that contains a group DN that the bind DN must be a member of.
userattr = "owner#GROUPDN"
The bind rule is evaluated to be true if the bind DN is a member of the group specified in the owner attribute of the target entry.
LDAPURL Bind Type ExampleThis 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*).
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.
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.
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";)
If you use the userattr keyword in conjunction with all or add permissions, you might find that the behavior of the directory server is not what you expect. Typically, when a new entry is created in the directory, the directory server evaluates access rights on the entry being created, and not on the parent entry. However, in the case of ACIs using the userattr keyword, this behavior could create a security hole, so the directory server's normal behavior is modified to avoid it.
Consider the following example ACI:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0; acl "manager-write"; allow (all) userattr = "manager#USERDN";)
This ACI grants managers all rights on the entries of employees that report to them. However, because access rights are evaluated on the entry being created, this type of ACI would also allow any employee to create an entry in which the manager attribute is set to their own DN. For example, disgruntled employee Joe, cn=Joe,ou=eng,dc=example,dc=com, might want to create an entry in the Human Resources branch of the tree to use (or misuse) the privileges granted to Human Resources employees.
He could do this by creating the following entry:
dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com objectclass: top ... cn: Trojan Horse manager: cn=Joe,ou=eng,dc=example,dc=com
To avoid this type of security threat, the ACI evaluation process does not grant add permission at level 0, that is, to the entry itself. You can, however, use the parent keyword to grant add rights below existing entries. You must specify the number of levels below the parent for add rights. For example, the following ACI allows child entries to be added to any entry in the dc=example,dc=com that has a manager attribute that matches the bind DN:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0; acl "parent-access"; allow (add) userattr = "parent[1].manager#USERDN";)
This ACI ensures that add permission is granted only to users whose bind DN matches the manager attribute of the parent entry.
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:
ldap://[12AB:0000:0000:CD30:0000:0000:0000:0000]
ldap://[12AB::CD30:0:0:0:0]
ldap://[12AB:0:0:CD30::]
An IPv6 address with a subnet prefix length, such as ldap://[12AB::CD30:0:0:0:0]/60
The bind rule is evaluated to be true if the client accessing the directory is located at the named IP address. This can be useful for allowing certain kinds of directory access only from a specific subnet or machine. Note that the IP address from which a user authenticates can be spoofed, and can therefore not be trusted. Do not base ACIs on this information alone.
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 that wildcards do not work if your system uses a naming service other than DNS. In such a case, if you want to restrict access to a particular domain, use the ip keyword, as described in Section 7.4.5, "Defining Access From a Specific IP Address (ip Keyword)."
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.
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:
NoneAuthentication is not required. This is the default. It represents anonymous access.
SimpleThe client must provide a user name and password to bind to the directory.
SSLThe client must bind to the directory over a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection.
In the case of SSL, the connection is established to the LDAPS second port. In the case of TLS, the connection is established through a Start TLS operation. In both cases, a certificate must be provided. For information on setting up SSL, see Section 19.6, "Using SASL Authentication."
SASLThe 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.
ssf Keyword)You can use bind rules to specify that binding can only occur based on a specific level of Security Strength Factor (SSF) enforced on the established connection. A connection's SSF is based on the key strength of the cipher enforced on the connection and pertains only to TLS/SSL or DIGEST-MD5/GSSAPI confidentiality or integrity connections.
The LDIF syntax for setting a bind rule based on the Security Strength Factor is shown here:
ssf operator "strength"
where operator can be one of the following symbols:
= (equal to)
!= (not equal to)
> (greater than)
>= (greater than or equal to)
< (less than)
<= less than or equal to
The strength is a value representing the cipher key strength required on the connection and is a value (0 to 256). DIGEST-MD5/GSSAPI connections with integrity enforced have an SSF of 1. TLS/SSL and DIGEST-MD5/GSSAPI confidentiality connections can have variable values of SSF based on the cipher negotiation performed between the directory server and client. The higher a connection's negotiated SSF is, the stronger the encryption is on the connection, as shown in these examples:
ssf = "1"; is true for access if integrity ssf = 1 only is enforced on the connection.
ssf!= "40"; is true for access if ssf not equal 40 is enforced on the connection.
ssf> "128"; is true for access if ssf greater than 128 is enforced on the connection.
ssf>= "128"; is true for access if ssf greater than or equal 128 is enforced on the connection.
ssf< "56"; is true for access if ssf less than 56 is enforced on the connection.
Clear connections have an SSF of 0.
The following sections describe how to define based on a connection's security strength factor keyword
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 |
| 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) |
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");)
The following sections describe how the Oracle Unified Directory access control model differs from the access control model provided with Oracle Directory Server Enterprise Edition.
Global ACI configuration differs from the Oracle Directory Server Enterprise Edition global ACI implementation in two ways:
The ds-config-global-aci attribute specifies a global ACI in the cn=Access Control Handler,cn=config entry (see Section 7.1, "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.
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"
Oracle Directory Server Enterprise Edition has no support for privileges. The privilege subsystem (discussed in Section 22.2, "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 (https://opends.dev.java.net/public/standards/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.
targetscope KeywordThe targetscope keyword differs from Oracle Directory Server Enterprise Edition by including a new scope:
subordinateRestricts the ACI to the subtree below the target resource only.
Oracle Unified Directory supports the LDAP Modify-Increment Extension (https://opends.dev.java.net/public/standards/rfc4525.txt). This extension is not supported in Oracle Directory Server Enterprise Edition. Attributes that are to be incremented must have write permissions.
There is no support for macros in ACIs.
roledn KeywordRoles are not supported in Oracle Unified Directory, so the roledn keyword should not be used. Equivalent functionality can be achieved by using groups.
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|