Oracle Internet Directory Administrator's Guide Release 2.1.1 Part Number A86101-01 |
Library | Service | Contents | Index

# 9
Managing Directory Access Control

This chapter provides an overview of access control policies and describes how to administer directory access control by using either Oracle Directory Manager or the command-line tool ldapmodify.

This chapter contains these topics:

- Overview of Access Control Policy Administration

- Managing Access Control by Using Oracle Directory Manager

- Managing Access Control by Using Command Line Tools

  See Also: "Access Control and Authorization" for a conceptual explanation before you begin implementing and administering access control policies Appendix D, "Using Access Control Directive Format" for information about the format or syntax of Access Control Items (ACIs)

## Overview of Access Control Policy Administration

You manage access control policies by configuring the values of the ACI attributes within appropriate entries. You can do this by using either Oracle Directory Manager or ldapmodify.

This section contains these topics:

- Access Control Management Constructs

- Access Control Information Components

- How ACL Evaluation Works

- Modifying Existing ACPs and their ACI Directives by Using Oracle Directory Manager

- Adding an ACP and Creating Access Items by Using Oracle Directory Manager

- Example: Managing ACPs by Using Oracle Directory Manager

- Granting Entry-Level Access by Using Oracle Directory Manager

- Examples: Managing Access Control

### Access Control Management Constructs

This section contains these topics:

- orclACI

- Access Control Policy Points (ACPs)

- orclEntryLevelACI

- Privilege Groups

#### orclACI

``The `orclACI` attribute contains Access Control List (ACL) directives that are prescriptive in nature, that is, these directives apply to all entries in the subtree below the ACP where this attribute is defined. Any entry in the directory can contain values for this attribute. Access to this attribute itself is controlled in the same way as access to any other attribute.

Note: It is possible to represent ACL directives specific to a single entry in the `orclACI` attribute. However, in such scenarios, for administrative convenience and performance advantages, Oracle Corporation recommends using `orclEntryLevelACI`--discussed in "orclEntryLevelACI". This is because the LDAP operational overhead increases with the number of directives represented through `orclACI`. You can reduce this overhead by moving entry specific directives from `orclACI` to `orclEntryLevelACI`.

#### Access Control Policy Points (ACPs)

ACPs are entries in which the `orclACI` attribute has been given a value. The `orclACI` attribute value represents the access policies that are inherited by the subtree of entries starting with the ACP as the root of the subtree.

When a hierarchy of multiple ACPs exists in a directory subtree, the subordinate entries in that subtree inherit the access policies from all of the ACPs that are superior to the entry. The resulting policy is an aggregation of the policies within the ACP hierarchy above the entry.

For example, if an ACP is established in the HR department entry, and the Benefits, Payroll, and Insurance groups are entries within the HR department, then any entry within those groups inherits the access rights specified in the HR department entry.

When there are conflicting policies within a hierarchy of ACPs, the directory applies well-defined precedence rules in evaluating the aggregate policy.

See Also: "How ACL Evaluation Works"

#### orclEntryLevelACI

When a policy pertains only to a specific entity--for example, a special user--you can maintain, within a single entry, the ACL directives specific to that entry. Oracle Internet Directory enables you to do this through a user-modifiable operational attribute called `orclEntryLevelACI`. The `orclEntryLevelACI` attribute contains ACL directives that apply only to the entry with which it is associated.

Any directory entry can optionally carry a value for this attribute. This is because Oracle Internet Directory extends the abstract class `top` to include `orclEntryLevelACI` as an optional attribute.

The `orclEntryLevelACI` attribute is multi-valued and has a structure similar to that of `orclACI`. The structure definition is provided later in this chapter.

#### Privilege Groups

Group entries in Oracle Internet Directory are associated with either the `groupOfNames` or the `groupOfUniqueNames` object class. Membership in the group is specified as a value of the `member` or `uniqueMember` attribute respectively.

It is possible to specify access rights for a group of people or entities. Such groups are called privilege groups and are associated with the `orclPrivilegeGroup` object class.

To grant access rights to a group of users, you create a group entry in the usual way, then associate it with the `orclPrivilegeGroup` object class. You then specify the access policies applicable to that group.

Entries can have either direct memberships to groups, or indirect memberships to other groups by means of nested groups, thus forming a forest of privilege groups. Access policies specified at a given level are applicable to all the members directly or indirectly below it.

Because Oracle Internet Directory evaluates for access control purposes only groups marked as privilege groups, it does not allow setting access policies for non-privilege groups. When a user binds with a specific distinguished name (DN), Oracle Internet Directory computes the user's direct membership in privilege groups. Once it knows the first level groups for the given DN, Oracle Internet Directory computes nesting of all these first level groups into other privilege groups. This process continues until there are no more nested groups to be evaluated.

It is imperative that all groups created for access control purposes, nested or otherwise, be marked as privilege groups by associating them with the `orclPrivilegeGroup` object class. A normal group will not be considered for access control purposes even though it may be a member of a privilege group.

For example, consider the following group of entries each of which, with the exception of group4, is marked as a privilege group (`objectclass:orclprivilegegroup`). One can set access control policies such that they are applicable to the members of group1, group2, and group3.

`dn: cn=group1, c=us` | `dn: cn=group2, c=us`
`cn: group1` | `cn: group2`
`objectclass: top` | `objectclass: top`
`objectclass: groupofUniquenames` | `objectclass: groupofUniquenames`
objectclass: orclprivilegegroup | objectclass: orclprivilegegroup
`uniquemember: cn=john smith, c=us` | `uniquemember: cn=john smith, c=us`
`uniquemember: cn=joe smith, c=us` | `uniquemember: cn=joe smith, c=us`
`uniquemember: cn=bill smith, c=us` | `uniquemember: cn=bill smith, c=us`

`dn: cn=group3, c=us` | `dn: cn=group4, c=us`
`cn: group3` | `cn: group4`
`objectclass: top` | `objectclass: top`
`objectclass: groupofUniquenames` | `objectclass: groupofUniquenames`
objectclass: orclprivilegegroup | `uniquemember: cn=john smith, c=uk`
`uniquemember: cn=group2, c=us` | `uniquemember: cn=joe smith, c=uk`
`uniquemember: cn=group1, c=us` | `uniquemember cn=bill smith, c=us`
`uniquemember: cn=group4, c=us` | ``

Group `cn=group3,c=us` contains the following nested groups:

- `cn=group2,c=us`

- `cn=group1,c=us`

- `cn=group4,c=us`

Access control policies for group3 are applicable to members of group3, group1, and group2 because each of them is marked as a privilege group. These same access control policies are not applicable to the members of group4 because group4 is not marked as a privilege group.

For example, suppose that the user binds to Oracle Internet Directory as a member of group 4 with the DN `cn=john smith,c=uk`. None of the access policies applicable to the members of group3 will apply to this user. This is because his only direct membership is to a non-privilege group. By contrast, if the user were to bind as `cn=john smith,c=us`--that is, as a member of group1 and group2--then his access rights will be governed by access policies set up for members of group1, group2, as well as group3 (in which group1 and group2 are nested). This is because all three groups are associated with the object class `orclPrivilegeGroup`.

### Access Control Information Components

Access Control Information associated with a directory object represents the permissions on the given object that various directory user entities (or subjects) have. Thus, an ACI consists of three components:

- Object: To What Are You Granting Access?

- Subject: To Whom Are You Granting Access?

- Operations: What Access Are You Granting?

#### Object: To What Are You Granting Access?

The object part of the access control directive determines the entries and attributes to which the access control applies. It can be either an entry or an attribute. Entry objects associated with an ACI are implicitly identified by the entry or the subtree where the ACI itself is defined. Any further qualification of objects at the level of attributes is specified explicitly in the ACL expressions.

In the `orclACI` attribute, the entry DN component of the object of the ACI is implicitly that of all entries within the subtree starting with the ACP as its topmost entry. For example, if `dc=com` is an ACP, then the directory area governed by its ACI is:

    .*, dc=com.

However, since the directory area is implicit, the DN component is neither required nor syntactically allowed.

In the `orclEntryLevelACI` attribute, the entry DN component of the object of the ACL is implicitly that of the entry itself. For example, if `dc=acme,dc=com` has an entry level ACI associated with it, the entry governed by its ACI is exactly: `dc=acme,dc=com`. Since it is implicit, the DN component is neither required nor syntactically allowed.

The object portion of the ACL allows entries to be optionally qualified by a filter matching some attribute(s) in the entry:

    filter=(ldapFilter)

where ldapFilter is a string representation of an LDAP search filter. The special entry selector `*` is used to specify all entries.

Attributes within an entry are included in a policy by including a comma-separated list of attribute names in the object selector.

    attr=(attribute_list)

Attributes within an entry are excluded from a policy by including a comma-separated list of attribute names in the object selector.

    attr!=(attribute_list)

Note: Access to the entry itself must be granted or denied by using the special object keyword ENTRY. Note that giving access to an attribute is not enough; access to the entry itself through the ENTRY keyword is necessary.

See Also: "Examples: Managing Access Control" for examples using command line tools Appendix D, "Using Access Control Directive Format" for information about the format or syntax of ACI

#### Subject: To Whom Are You Granting Access?

This section describes the authentication mode, called the bind mode, used to verify the identity of the subject, also called the entity, to whom access is granted.

##### Bind Mode

The bind mode specifies the method of authentication to be used by the subject. There are four modes:

- `Simple`: Simple password-based authentication

- `SSLNoauth`: For SSL-based clients with either anonymous or simple password based authentication

- `SSLOneway`: For SSL-based clients with server authentication with either anonymous or password based authentication

- `SSLTwoway`: For SSL-based clients with strong authentication through SSL.

The bind mode is optional in subject specification. When specified, the mode should match the mode specified in the ACI.

##### Entity

The entity component identifies the entity or entities being granted access. Note that access is granted to entities, not entries.

Entities can be specified by:

- The special "*" identifier, matching any entry

- The keyword SELF matching the entry protected by the access

- A regular expression matching an entry's distinguished name: `dn=`regex

- The members of a privilege group object: group=dn

- An entry listed in a DN-valued attribute in the entry to which the access applies: `dnattr=(`dn-valued_attribute_name`)`

The `dnattr` specification is used to give access to a group entry to whomever is listed as the owner of the group entry.

#### Operations: What Access Are You Granting?

The kind of access granted can be one of the following:

- None

- Compare/nocompare

- Search/nosearch

- Browse/nobrowse

- Read/noread

- Selfwrite/noselfwrite

- Write/nowrite

- Add/noadd

- Delete/nodelete

Note that each access level can be independently granted or denied. The `no` xxx means xxx permission is denied.

Access Level | Description
--- | ---
None | No access rights. The effect of granting no access rights to a subject-object pair is to make the directory appear to the subject as though the object were not present in the directory.
Add | Right to add entries under a target directory entry
Browse | Permission to return the DNs in the search result. It is equivalent to the list permission in X.500. This permission is also required for a client to use an entry DN as the base DN in an ldapsearch operation.
Compare | Right to perform compare operation on the attribute value
Delete | Right to delete the target entry
Read | Right to read attribute values. Even if read permission is available for an attribute, it cannot be returned unless there is browse permission on the entry itself.
Search | Right to use an attribute in a search filter
Selfwrite | Right to add oneself to, delete oneself from, or modify one's own entry in a list of DNs group entry attribute. Use this to allow members to maintain themselves on lists. For example, the following command allows people within a group to add or remove only their own DN from the member attribute:
    access to attr=(member) by dnattr=(member) (selfwrite)
The `dnattr` selector indicates that the access applies to entities listed in the member attribute. The `selfwrite` access selector indicates that such members can add or delete only their own DN from the attribute.
Write | Right to modify/add/delete the attributes of an entry.

Note that some access permissions are associated with entries and others with attributes.

Permissions for Entries: | Permissions for Attributes:
--- | ---
Browse/nobrowse | Compare/nocompare
Add/noadd | Search/nosearch
Delete/nodelete | Read/noread
None | Selfwrite/noselfwrite
| Write/nowrite
| None

The entry level access directives are distinguished by the keyword ENTRY in the object component.

Note: By default, for both structural and content access items, everyone is given access to read, search, write, and compare all attributes in an entry, and selfwrite permissions are unspecified. If an entry is unspecified, access is determined at the next highest level in which access is specified.

### How ACL Evaluation Works

This section contains these topics:

- About ACL Evaluation

- ACL Evaluation Precedence Rules

- Assigning More Than One ACI to the Same Object

- Granting Exclusionary Access to Objects

- ACL Evaluation For Groups

#### About ACL Evaluation

When processing a request, the access level granted to the requester has to be evaluated for each of the attributes involved in the request. This evaluation is done systematically for each attribute associated with every entry involved in an LDAP operation.

The process of evaluating access to any object (attribute in an entry) involves potentially examining all the ACI directives that are applicable for that object. This is because of the hierarchical nature of ACPs and the inheritance of policies from superior ACPs to subordinate ACPs.

The evaluation starts with examining ACI directives in the entry's entry level ACI, `orclEntryLevelACI`. Until the evaluation is complete, the ACP policies are successively considered, starting with the immediate ACP, followed by the chain of its superior ACPs.

The access evaluation is done for the entry and each of its attributes individually. Oracle Internet Directory evaluates entry level access permissions to see whether the given subject is allowed to perform the given operation.

During ACL evaluation, an attribute is said to be in one of the following states:

State | Description
--- | ---
Resolved with permission | The required access for the attribute has been granted in the ACI.
Resolved with denial | The required access for the attribute has been explicitly denied in the ACI.
Unresolved | No applicable ACI has yet been encountered for the attribute in question.

For all operations except search, the evaluation stops if:

- Access to the entry itself is denied

- Any of the attributes reach the resolved with denial state.

In this case the operation would fail and an error would be returned to the client.

For a search operation, the evaluation continues until all the attributes reach the resolved state. Attributes that are resolved with denial are not returned.

#### ACL Evaluation Precedence Rules

An LDAP operation requires the BindDN, or subject, of the LDAP session to have certain permissions to the objects affected by the operation--including permissions on the entry itself and on the individual attributes of the entry.

Typically, there could be a hierarchy of access control administration authorities, starting from the root of a naming context down to successive administrative points (or access control policy points). An ACP is any entry which has a defined value for the `orclACI` attribute. Additionally, the access information specific to a single entry can also be represented within the entry itself (`orclEntryLevelACI`).

ACL evaluation involves determining whether a subject has sufficient permissions to perform an LDAP operation. Typically an `orclentryLevelACI` or `orclACI` might not contain all the necessary information for ACL evaluation. Hence, all available ACL information is processed in a certain order until the evaluation is fully resolved:

- The entry level ACI is examined first. ACI in the `orclACI` are examined starting with the ACP closest to the target entry and then its superior ACP and so on.

- At any point, if all the necessary permissions have been determined, the evaluation stops; otherwise, the evaluation continues.

- Within a single ACI, if the entity associated with the session DN matches more than one item identified in the by clause, the effective access evaluates to:

  - The union of all the granted permissions in the matching by clause items

    ANDed with

  - The union of all the denied permissions in the matching by clause items

##### Precedence at the Entry Level

ACIs at the entry level are evaluated in the following order:

1. With a filter. For example:

       access to entry filter=(cn=p*)

       by group1 (browse,add,delete)

2. Without a filter. For example:

       access to entry

       by group1 (browse,add,delete)

##### Precedence at the Attribute Level

At the attribute level, specified ACIs have precedence over unspecified ACIs.

Specified ACIs at the attribute level are evaluated in the following order:

1. Those with a filter. For example:

       access to attr=(salary) filter=(salary >10000)

       by group1 (read)

2. Those without a filter. For example:

       access to attr=(salary)

       by group1 (search,read)

Unspecified ACIs at the attribute level are evaluated in the following order:

1. With a filter. For example:

       access to attr=(*) filter (cn=p*)

       by group1 (read,write)

2. Without a filter. For example:

       access to attr=(*)

       by group1 (read,write)

#### Assigning More Than One ACI to the Same Object

If there are two or more ACIs at the same ACP for the same object, then only one ACI is checked, and all other ACIs are ignored. For example, suppose you have the following two ACIs at the same ACP for the same entry:

- ACI #1:

      access to entry

             by dn="cn=admin, dc=us,dc=acme,dc=com" (browse, add, delete)

- ACI #2:

      access to entry

             by dn="cn=manager,dc=us,dc=acme,dc=com" (search, read)

If ACI #2 happens to be checked first, then the access granted specifically to the administrator in ACI #1 is ignored. If an administrator should then seek access to the entry, that access could not be resolved at this level of the hierarchy. The evaluation would have to move progressively up the hierarchy in search of resolution. If no resolution is found, all access is denied.

The solution is to create only one ACI at the same ACP for this entry. For example:

    access to entry

    by dn="cn=admin, dc=us,dc=acme,dc=com" (browse, add, delete)
    by dn="cn=manager,dc=us,dc=acme,dc=com" (search, read)

Similarly, at the attribute level, suppose you have the following two ACIs:

- ACI #1:

      access to attr=(userpassword)

              by dnattr=(".*,dc=us,dc=acme,dc=com) (none)

- ACI #2:

      access to attr=(userpassword)

              by self (read,write)

If ACI #1 happens to be returned first, it wins, and the access granted to self in ACI #2 is ignored. If a user then wishes to change his or her own password, that access cannot be granted.

As with the ACIs for entries, the solution is to create only one ACI at the same ACP for this attribute. For example:

    access to attr=(userpassword)

    by dnattr=(".*,dc=us,dc=acme,dc=com) (none)
    by self (read,write)

#### Granting Exclusionary Access to Objects

If an ACI exists for a given object, and you want to specify access to all other objects except that one, then you must verify that the specified objects do not intersect. For example, suppose you have the following two ACIs:

- ACI #1:

      access to attr=(userpassword)by group1 (read,write)

- ACI #2:

      access to attr=(*)by group2 (read)

In this case, the two ACIs intersect, that is, both ACIs try to grant access to the `userpassword` attribute, but ACI #2 is unsuccessful. The reason is that, during the evaluation process, ACI #1 wins because, as noted in "ACL Evaluation Precedence Rules", it is specified. This means that anyone in group2 who tries to access the `userpassword` attribute is not given access at this level of the hierarchy. The evaluation would have to move progressively up the hierarchy in search of resolution. If no resolution is found, all access is denied.

The solution is to use the following syntax for ACI #1 and ACI #2:

- ACI#1:

      access to attr=(userpassword)by group1 (read,write)by group2 (read)

- ACI #2:

      access to attr!=(userpassword)by group2 (read)

In the revised ACI #1, we give to group2 read access to the `userpassword` attribute.

In the revised ACI #2, we negate group2 access to the `userpassword` attribute, and we grant read access to all attributes except the `userpassword` attribute.

#### ACL Evaluation For Groups

If an operation on an attribute or the entry itself is explicitly denied at an ACP low in the DIT, then, typically, the ACL evaluation for the attribute (or entry) is considered "Resolved with Denial." However, if the user of the session (bindDN) is a member of a group object, then the evaluation continues as if it is still unresolved. If permissions are granted to the user of the session at an ACP higher in the tree through a group subject selector, then such grants have higher precedence than any denials lower in the tree.

This scenario is the only case in which ACL policy at a higher level ACP has a higher precedence than that of an ACP lower in the DIT.

#### Access Level Requirements for LDAP Operations

The following table lists LDAP operations and the access required to perform each one.

Operation | Required Access
--- | ---
Create an object | Add access to the parent entry
Modify | Write access to the attributes that are being modified
ModifyDN | Delete access to the current parent and Add access to the new parent.
ModifyDN (RDN) | Write access to the naming attribute, that is, the RDN attribute
Remove an object | Delete access to the object being removed
Compare | Compare access to the attribute
Search | Search access on the filter attributes and browse access on the entry (if only the entry DN needs to be returned as a result) Search access on the filter attributes, browse access on the entry, and read permission on the attributes (for all attributes whose values need to be returned as a result)

## Managing Access Control by Using Oracle Directory Manager

You can view and modify access control information configured within ACPs by using either Oracle Directory Manager or command line tools. This section explains how to accomplish these tasks by using Oracle Directory Manager.

Note: Immediately after installing Oracle Internet Directory, be sure to reset the default security configuration as described in "Task 3: Reset the Default Security Configuration"

This section contains these topics:

- Configuring the Display of ACPs in Oracle Directory Manager

- Configuring Searches for ACPs When Using Oracle Directory Manager

- Viewing an ACP by Using Oracle Directory Manager

- Modifying Existing ACPs and their ACI Directives by Using Oracle Directory Manager

- Adding an ACP and Creating Access Items by Using Oracle Directory Manager

- Example: Managing ACPs by Using Oracle Directory Manager

- Granting Entry-Level Access by Using Oracle Directory Manager

  See Also: Appendix A, "Syntax for LDIF and Command Line Tools" for a description of command line tools

### Configuring the Display of ACPs in Oracle Directory Manager

Oracle Directory Manager enables you to determine whether the navigator pane displays all ACPs automatically or only as the result of a search. If you have a large number of ACPs, you may want to display them only as the result of a search.

To configure the display of ACPs:

1. In the navigator pane, expand Oracle Internet Directory Servers and select the server you want to configure.

2. On the toolbar, click User Preferences. The User Preferences dialog box appears.

3. Select the Configure Access Control Policy Management tab page.

4. In the Configure Access Control Policy Management tab page, select either:

   - Always display all ACPs

   - Only display ACPs based on search request

5. Click Ok.

   Note: To effect your changes, you must restart Oracle Directory Manager.

### Configuring Searches for ACPs When Using Oracle Directory Manager

For ACP searches, Oracle Directory Manager enables you to specify:

- The root of the search

- The maximum number of entries retrieved

- The time limit of the search

- The search depth.

To configure searches for ACP entries:

1. In the navigator pane, expand Oracle Internet Directory Servers >
   directory_server, and select Access Control Management.

2. On the toolbar, click Configure ACPs Search. The Configure ACPs Search dialog box appears.

3. In the Root of the Search field, enter the DN of the root of your search, or click Browse to navigate to it.

4. In the Max Results (entries) field, enter the number of entries you want ACP searches to retrieve.

5. In the Max Search Time (seconds) field, enter the maximum number of seconds for the duration of the search.

6. In the Search Depth list, select the level at which you want to search. Options are:

   - One Level--To limit the search to all ACP entries one level down from the root of the search

   - Subtree--To search entries within the entire subtree, including the root of the search

7. Click Ok.

### Viewing an ACP by Using Oracle Directory Manager

If you configured Oracle Directory Manager to display ACPs only as the result of a search, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then you can locate and view an ACP as follows:

1. Expand Oracle Internet Directory Servers > directory_server, then select Entry Management. Perform a search for the entry designated as an ACP. The search result appears in the Distinguished Name box in the lower half of the right pane.

2. In the Distinguished Name box, double-click the entry. The corresponding Entry dialog box appears.

3. To view subtree access controls for this ACP, select the Subtree Access tab.

   To view entry level access controls for this ACP, select the Local Access tab.

If you configured Oracle Directory Manager to always display ACPs, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then you can locate and view an ACP as follows:

1. In the navigator pane, expand Oracle Internet Directory Servers >
   directory_server > Access Control Management. All of the defined Access Control Policy Points (ACPs) appear both below Access Control Management in the navigator pane and in the right pane.

2. In the navigator pane, under Access Control Management, select an ACP to display its information in the right pane.

   You can alternatively double-click an ACP in the right pane to display the data in its own window.

The three fields in the Access Control Management pane are:

Field | Description
--- | ---
Path to the Subtree Access Control Point | Contains the path defined by the ACP. If you have navigated down a tree to this point, the path to this point appears in this field. If you are creating a new ACP, you must enter the path to it here.
Structural Access Items (Entry Level Operations) | Lists access to entries. Items listed in the Structural Access Items box identify an entry by the following categories: By Whom: To whom or what you are granting access (the subject) Bind Mode: Whether bind mode (authentication) is used Access rights: Browse, Add, and Delete See Also: "Modifying Structural Access Items of an Existing ACP by Using Oracle Directory Manager" for instructions on how to modify structural access items
Content Access Items (Attribute Level Operations) | Lists items related to attributes within the entry or entries identified in the Entry Filter column. Columns in this window include: By Whom: To whom or what you are granting access (the subject) Bind Mode: Whether bind mode (authentication) is used Op: The matching operation to be performed against the attribute. Choices are EQ (=) and NEQ (!=) Attribute: The specific attribute to which access is granted or denied (the object) Access rights: Read, Search, Write, Selfwrite, or Compare access See Also: "Modifying Content Access Items of an Existing ACP by Using Oracle Directory Manager" for instructions on how to modify content access items.

### Modifying Existing ACPs and their ACI Directives by Using Oracle Directory Manager

ACPs are entries that contain prescriptive, that is, inheritable, access control information. This information affects the entry itself and all entries below it. You will most likely create ACPs to broadcast large-scale access control throughout a subtree.

This section contains these topics:

- Adding Structural Access Items to an Existing ACP by Using Oracle Directory Manager

- Adding Content Access Items to an Existing ACP by Using Oracle Directory Manager

- Modifying Structural Access Items of an Existing ACP by Using Oracle Directory Manager

- Modifying Content Access Items of an Existing ACP by Using Oracle Directory Manager

#### Adding Structural Access Items to an Existing ACP by Using Oracle Directory Manager

If you configured Oracle Directory Manager to always display ACPs, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then you can navigate to and add a structural access item to an existing ACP as follows:

1. In the navigator pane, expand Oracle Internet Directory > directory server > Access Control Management. Select Access Control Management. All of the defined Access Control Policy Points (ACPs) appear in a list below Access Control Management. They also appear in the right pane.

2. In the navigator pane, under Access Control Management, select an ACP to display its information in the right pane.

3. Just below the Structural Access Items box, click Create. The Structural Access Items dialog box displays three tabs: Entry Filter, By Whom, and Access Rights.

4. Use the Entry Filters tab page to narrow the set of entries to which you are granting access. If you want all entries below the ACP to be governed by the ACP, you do not need to use this tab page.

   You might choose an entry based on one or more attributes. For example, you might choose to search for all those whose title is administrative assistant, or for all those whose title is manager and whose organization unit is Americas.

   In the Criteria box of the Entry Filters tab page, use the search criteria bar to select an attribute, enter a value for that attribute, and specify a filter for matching the specified attribute with the value you entered. To do this:

   1. In the menu at the left end of the bar, select an attribute.

   2. In the menu in the middle of the bar, select one of the following filter options:

      Filter | Description
      --- | ---
      Begins With | Searches by using only the first few characters of the attribute value
      Ends With | Searches for an entry by using only the last few characters of the specified attribute value
      Contains | Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter
      Exact Match | Searches for an entry whose specified attribute is the same as the value you enter
      Greater or Equal | Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.
      Less or Equal | Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.
      Present | Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase `cn Present` retrieves all entries with a `cn` attribute value at that level of the tree.

   3. In the text field at the right end of the search criteria bar, type the value for the attribute you selected.

5. Select the By Whom tab page to define the subject of the ACI.

   1. Specify the type of authentication--called Bind Mode--to be used by the subject (that is, the entity that seeks access). The bind mode is optional in subject specification. However, for the directive to be applicable, the bind mode specified on one node should match the bind mode specified on the node with which it is communicating.

   There are five bind modes from which to select:

   :

   Bind Mode | Description
   --- | ---
   None | No authentication
   SSL No Authentication | Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used.
   SSL One Way | Only the directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic.
   SSL Two Way | Both client and server authenticate themselves to each other. They do this by sending certificates to each other.
   Simple | The client identifies itself to the server by means of a DN and a password which are sent in the clear over the network. The server verifies that the DN and password sent by the client matches the DN and password stored in the directory.

Specify the entity or entities to whom you are granting access. Options are:

Entity | Description
--- | ---
Everyone (*) | All who try to access the entry
A Specific Group | A previously defined group name
A Specific Entry | A previously defined directory entry
A Subtree | An entire subtree in the directory, which you select
When Session User's Distinguished Name (DN) Is Identified by Attribute | Anyone whose DN is an attribute in the entry. For example, you might want to grant read access to a group entry to members of the group
When Session User's Distinguished Name (DN) Matches the Accessed Entry | Anyone who has correctly logged in as the entry specified

- Click OK.

- Select the Access Rights tab page.

  1. Select the appropriate options to specify the kinds of rights you want to grant: Browse, Add, or Delete.

  2. Click Ok to close the Structural Access Items dialog box and return to the main Oracle Directory Manager window. The structural ACI you just set is listed in the Structural Access Items window of the main Oracle Directory Manager dialog box.

  #### Adding Content Access Items to an Existing ACP by Using Oracle Directory Manager

  If you configured Oracle Directory Manager to always display ACPs, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then you can navigate to and add a content access item to an existing ACP as follows:

  1. In the navigator pane, expand Oracle Internet Directory Servers > directory server > Access Control Management. Select Access Control Management. All of the defined Access Control Policy Points (ACPs) appear in a list below Access Control Management in the navigator pane. They also appear in the right pane.

  2. Select an ACP under Access Control Management in the navigator pane to display its information in the right pane, or double-click an ACP in the right pane to display the data in its own dialog box.

  3. In the Content Access Items window, select the Content Access Item you want to modify.

  4. Just below the Content Access Item box, click Create. The Content Access Items dialog box appears.

  5. In the Entry Filter tab page, specify the items (if applicable) as described in "Adding Structural Access Items to an Existing ACP by Using Oracle Directory Manager".

  6. Select the By Whom tab page and specify the items as described in "Adding Structural Access Items to an Existing ACP by Using Oracle Directory Manager".

  7. Select the Attribute tab page.

     1. From the right list, select the attribute to which you want to grant or deny access.

     2. From the left list, select the matching operation to be performed against the attribute. Choices are EQ (Equal (=)) and NEQ (Not Equal (!=)).

  8. Select the Access Rights tab page and specify the items as described in the section "Adding Structural Access Items to an Existing ACP by Using Oracle Directory Manager".

  9. Click OK.

  #### Modifying Structural Access Items of an Existing ACP by Using Oracle Directory Manager

  If you configured Oracle Directory Manager to always display ACPs, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then you can navigate to and modify a structural access item to an existing ACP as follows:

  1. In the navigator pane, expand Oracle Internet Directory Servers > directory server > Access Control Management. Select Access Control Management. All of the defined Access Control Policy Points (ACPs) appear in a list below Access Control Management in the navigator pane. They also appear in the right pane.

  2. In the navigator pane, under Access Control Management, select an ACP to display its information in the right pane.

  3. In the Structural Access Items window, select the item you want to modify, and, just below the Structural Access Items window, click Edit. The Structural Access Item dialog box appears.

  4. Use the Entry Filters tab page to narrow the set of entries to which you are granting access. If you want all entries below the ACP to be governed by the ACP, proceed to the next step.

     You might choose an entry based on one or more attributes. For example, you might choose to search for all those whose title is secretary, or for all those whose title is manager and whose organization unit is Americas.

     In the Criteria window of the Entry Filters tab page, use the search criteria bar to select an attribute, enter a value for that attribute, and specify a filter for matching the specified attribute with the value you entered. To do this:

     1. In the menu at the left end of the bar, select an attribute.

     2. In the menu in the middle of the bar, select one of the following filter options:

        Filter | Description
        --- | ---
        Begins With | Searches by using only the first few characters of the attribute value
        Ends With | Searches for an entry by using only the last few characters of the specified attribute value
        Contains | Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter
        Exact Match | Searches for an entry whose specified attribute is the same as the value you enter
        Greater or Equal | Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.
        Less or Equal | Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.
        Present | Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase `cn Present` retrieves all entries with a `cn` attribute value at that level of the tree.

     3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

  5. Select the By Whom tab page.

     1. Specify the type of authentication--called Bind Mode--to be used by the subject (that is, the entity that seeks access). There are five bind modes from which to select:

        Bind Mode | Description
        --- | ---
        None | No authentication
        SSL No Authentication | Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used.
        SSL One Way | Only the directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic.
        SSL Two Way | Both client and server authenticate themselves to each other. They do this by sending certificates to each other.
        Simple | The client identifies itself to the server by means of a DN and a password which are sent in the clear over the network. The server verifies that the DN and password sent by the client matches the DN and password stored in the directory.

        The bind mode is optional in subject specification. For the directive to be applicable, the bind mode specified on one node should match the bind mode specified on the node with which it is communicating.

     2. Specify the entity or entities to whom you are granting access.

        Entity | Description
        --- | ---
        Everyone (*) | All who try to access the entry
        A Specific Group | A previously defined group name
        A Specific Entry | A previously defined directory entry
        A Subtree | An entire subtree in the directory, which you select
        When Session User's Distinguished Name (DN) Is Identified by Attribute | Anyone whose DN is an attribute in the entry. For example, you might want to grant read access to a group entry to members of the group
        When Session User's Distinguished Name (DN) Matches the Accessed Entry | Anyone who has correctly logged in as the entry specified

  6. Select the Access Rights tab page.

     1. Determine what kinds of rights are granted: Browse, Add, Delete, or Unspecified. If an entry is unspecified, then access is determined at the next highest level in which access is specified.

     2. Click OK.

  #### Modifying Content Access Items of an Existing ACP by Using Oracle Directory Manager

  If you configured Oracle Directory Manager to always display ACPs, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then you can navigate to and modify a content access item to an existing ACP as follows:

  1. In the navigator pane, expand Oracle Internet Directory Servers > directory server > Access Control Management. Select Access Control Management. All of the defined Access Control Policy Points (ACPs) appear in a list below Access Control Management in the navigator pane. They also appear in the right pane.

  2. Under Access Control Management, select an ACP to display its information in the right pane, or double-click an ACP in the right pane to display the data in its own dialog box.

  3. In the Content Access Items box, select the content access item you want to modify.

  4. Just below the Content Access Item window, click Edit. The Content Access Items dialog box appears. Each tab page contains items you can modify.

  5. Specify the items in the Entry Filter tab page (if applicable) as described in "Modifying Structural Access Items of an Existing ACP by Using Oracle Directory Manager".

  6. Select the By Whom tab page and specify the items as described in the section "Modifying Structural Access Items of an Existing ACP by Using Oracle Directory Manager".

  7. Select the Attribute tab page.

     1. From the right menu, select the attribute to which you want to grant or deny access.

     2. From the left menu, select the matching operation to be performed against the attribute. Choices are EQ (Equal (=)) and NEQ (Not Equal (!=)).

  8. Select the Access Rights tab page and specify the items as described in the section "Modifying Structural Access Items of an Existing ACP by Using Oracle Directory Manager".

  9. Click OK.

  ### Adding an ACP and Creating Access Items by Using Oracle Directory Manager

  To create a new ACP:

  1. In the navigator pane, expand, Oracle Internet Directory Servers > directory server. Select Access Control Management.

  2. On the toolbar, click Create. A New Access Control Point dialog box appears.

  3. In the Path to Entry field, enter the distinguished name (DN) of the entry that will be the ACP.

     Note: You can find the DN by looking in the navigator pane for the entry or by clicking Browse.

  4. To define structural access items (entries), just below the Structural Access Items window, click Create. The Structural Access Item dialog box appears. Use the tab pages in this dialog box as explained in the section "Modifying Structural Access Items of an Existing ACP by Using Oracle Directory Manager".

  5. To define content access items (attributes), just below the Content Access Items window, click Create. The Content Access Item dialog box appears. Use the tab pages in this dialog box as explained in the section "Modifying Content Access Items of an Existing ACP by Using Oracle Directory Manager".

  6. Click Ok to close this dialog box and return to the main Oracle Directory Manager dialog box.

  ### Example: Managing ACPs by Using Oracle Directory Manager

  This example illustrates how to use Oracle Directory Manager to create a new ACP that has ACIs within it. Suppose you are an administrator in a large company, and you want to limit access to user passwords, so that everyone can compare a password, but only the owner of each password, that is, the user, can read the password or modify it.

  In this example, we create a new ACP and populate it with four ACIs that set the following permissions:

  - Limited access to a `userpassword` attribute by everyone

  - Open access to the same `userpassword` attribute by the user himself

  - Open access to all attributes except `userpassword` to everyone

  - Open access to all attributes to everyone

  #### Create a New ACP

  1. In the navigator pane, expand Oracle Internet Directory Servers > directory server, and select Access Control Management. A list of ACPs appears in the right pane.

  2. Click Create at the bottom of the right pane. A New Access Control Point dialog box appears.

  3. In the Path To Entry field, enter the DN where you want the ACP. The ACIs within the ACP will apply to all entries below and including that DN.

  ##### Structural Access Items

  To set the access rights for an entry:

  1. Just below the Structural Access Items box, click Create. A Structural Access Items dialog box appears. It contains three tabs: Entry Filter, By Whom, and Access Rights.

     Because you want the ACIs to apply to all entries under the ACP, do not use the Entry Filter tab page.

  2. Select the By Whom tab page to define the subject of the ACI. From the Bind Mode list, select the authentication mode appropriate to your environment. To create access rights for everyone, select Everyone. Click OK.

  3. Select the Access Rights tab page. By default, all rights--browse, add, and delete--are granted.

     1. Change the access rights so that Everyone can browse all entries, but cannot add or delete them.

     2. Click Ok.

  ##### Content Access Items

  The four ACIs in this example use the same structural content item information. They differ only in the content access they allow. The rest of this section describes how to create the content access for the ACIs.

  To define the content access items:

  1. Below the Content Access Items box, click Create. The Content Access Items dialog box appears.

     Because you want this ACI to apply to all entries under the ACP, do not use the Entry Filter tab page.

  2. Select the By Whom tab page, select Everyone, then click OK.

  3. Select the Attribute tab page. This page has two fields. The first has two choices: EQ (equals) and NEQ (not equals). The second sets the attribute.

     Select EQ and select `userPassword`.

  4. Select the Access Rights tab page. By default, all permissions are granted. Change the permissions so that read, search, write, and compare are denied.

  5. Click Ok.

     You have completed one ACI.

  #### Create Another ACI

  Create another ACI that allows a user to read, write, search, and compare his own password.

  1. Under the Content Access Items box, click Create. The Content Access Items dialog box appears.

  2. Select the By Whom tab page. Click When Session User's Distinguished Name (DN) Matches the Accessed Entry, then click OK.

  3. Select the Attribute tab page. This tab page has two lists.The first has two choices: EQ (equals) and NEQ (not equals). The second sets the attribute.

     Select EQ and userPassword.

  4. Select the Access Rights tab page.

     Grant access to read, search, write, and compare. Leave selfwrite unspecified.

  5. Click Ok.

  You have now created two ACPs. One denies Everyone read, search, write, and compare access to the `userPassword` attribute. The second allows the owner of the password to read, search, write, and compare that attribute.

  #### Create a Third ACI

  The next ACI grants access to Everyone to read, search, and compare all attributes except `userPassword`. It denies write access.

  1. Under the Content Access Items field, click Create to display the Content Access Items.

  2. Select the By Whom tab page.

     Select Everyone, then click OK.

  3. Select the Attribute tab page.

     Select NEQ and `userPassword`.

     This combination means that any attribute that is not equal to `userpassword` is the object of the permissions in this ACI.

  4. Select the Access Rights tab page.

     Grant access to read, search, and compare. Deny write access. Leave selfwrite unspecified.

  5. Click Ok to apply these permissions and close the dialog box.

  #### Create a Fourth ACI

  The next ACI grants access to Self to read, browse, and write all attributes except `userpassword`. Including this ACI avoids any ambiguity about whether Self has the same access permissions as Everyone to attributes other than `userPassword`.

  1. Under the Content Access Items field, click Create to display the Content Access Items dialog box.

  2. Select the By Whom tab page.

     Click When Session User's Distinguished Name (DN) Matches the Accessed Entry. Click Ok.

  3. Select the Attribute tab page.

     From the lists, select NEQ and `userPassword`. This combination means that any attribute that is not equal to `userPassword` is the object of the permissions in this ACI.

  4. Press the Access Rights tab page.

     Grant access to read, search, and write. Leave Selfwrite unspecified.

  5. Click Ok to apply these permissions and close the dialog box.

  Consider other access restrictions you might want to implement. Your directory might contain many entries and attributes that should not be available to everyone.

  ### Granting Entry-Level Access by Using Oracle Directory Manager

  To grant entry-level access by using Oracle Directory Manager:

  1. In the navigator pane, expand Oracle Internet Directory Servers > directory server > Entry Management. You may either:

     - Select the entry to display its properties in the right pane

     - Use the search panel to find the entry, then double-click the entry to open the Entry dialog box.

  2. Select the Local Access tab page, then create and edit local ACIs in the Structural Access Item and Content Access Item boxes.

  3. Once you have made the changes, click Apply in the main Oracle Directory Manager window.

     Note: You must click Apply to send the information you just entered to the directory server. If you do not click Apply, the information you just entered is simply held in the Oracle Directory Manager cache.

  ## Managing Access Control by Using Command Line Tools

  As described in "Overview of Access Control Policy Administration", directory access control policy information is represented as user modifiable operational attributes. Hence, you can manage directory access control by using the ldapmodify command to set and alter values of these attributes. Any tool, including ldapmodify and ldapmodifymt, can be used for this purpose.

  In order to directly edit the ACI, you should understand the format and semantics of the directory representation of the ACI. This section contains the formal specification of the ACI format and a description of the semantic issues necessary to manage the ACI using command line tools.

  See Also: "LDAP Data Interchange Format (LDIF) Syntax" for information about how to format input using LDAP Data Interchange Format (LDIF)

  , the required input format for line mode commands

- "ldapmodify Syntax" for information about how to run ldapmodify

- Appendix D, "Using Access Control Directive Format" for information about the format or syntax of ACI

### Examples: Managing Access Control

This section contains these topics:

- Example: Setting Up an Inheritable ACP by Using ldapmodify

- Example: Setting Up Entry-Level ACIs by Using ldapmodify

- Typical Access Control Policies

#### Example: Setting Up an Inheritable ACP by Using ldapmodify

This example sets up subtree access permissions in an `orclACI` at the Root DSE. Because this example refers to the `orclACI` attribute, this access directive governs all the entries in the DIT.

Note the presence of the << EOF characters.

    ldapmodify -v -h $1 -D "cn=Directory Manager, o=IMC, c=US" -w "controller" <<
    EOF
    dn:
    changetype: modify
    replace: orclaci
    orclaci: access to entry

    by dn= "cn=directory manager, o=IMC, c=us" (browse, add, delete)
    by * (browse, noadd, nodelete)

    orclaci: access to attr=(*)

    by dn= "cn=directory manager, o=IMC, c=us" (search, read, write, compare)
    by self (search, read, write, compare)
    by * (search, read, nowrite, nocompare)

    EOF

#### Example: Setting Up Entry-Level ACIs by Using ldapmodify

This example sets up entry-level access permissions in the `orclEntryLevelACI` attribute. Because this resides in the `orclEntryLevelACI` attribute, this ACL governs only the entry in which it resides. Note the presence of the << EOF characters.

    ldapmodify -v -h $1 -D "cn=Directory Manager, o=IMC, c=US" -w "controller" <<
    EOF
    dn:
    changetype: modify
    replace: orclentrylevelaci
    orclentrylevelaci: access to entry

    by dn= "cn=directory manager, o=IMC, c=us" (browse, add, delete)
    by * (browse, noadd, nodelete)

    orclentrylevelaci: access to attr=(*)

    by dn= "cn=directory manager, o=IMC, c=us" (search, read, write, compare)
    by * (search, read, nowrite, nocompare)

    EOF

Note: In this example, no DN value is specified. This means that this ACI pertains to the root DSE and its attributes only.

#### Typical Access Control Policies

This section shows these advanced and typical examples of access control policies:

- Example: Using Wild Cards

- Example: Selecting Entries by DN

- Example: Using Attribute and Subject Selectors

- Example: Granting Read-Only Access

- Example: Granting Selfwrite Access to Group Entries

##### Example: Using Wild Cards

This example shows the use of wild cards (*) in the object and subject specifiers. For all entries within the `acme.com` domain, it grants to everyone browse permission on all entries, as well as read and search permissions on all attributes.

`orclACI` attribute in the ACP at `dc=com`

    access to entry by * (browse)

    access to attr=(*) by * (search, read)

Note that, in order to allow reading the attributes, browse permissions must be granted on the entries in order for read permissions to be granted to the attributes of those entries.

##### Example: Selecting Entries by DN

This example shows the use of a regular expression to select the entries by DN in two access directives. It grants to everyone under `dc=acme,dc=com` access to read address book attributes only. It extends only to everyone within `dc=us,dc=acme,dc=com` read access to all attributes.

`orclACI` attribute of `dc=acme, dc=com`:

    access to entry by * (browse)
    access to attr=(cn, telephone, email) by * (search, read)

`orclACI` attribute of `dc=us, dc=acme, dc=com`:

    access to entry by * (browse)
    access to attr=(*) by dn=".*,dc=us,dc=acme,dc=com" (search, read)

##### Example: Using Attribute and Subject Selectors

This example shows the use of an attribute selector to grant access to a specific attribute, and various subject selectors. The example applies to entries in the `dc=us,dc=acme,dc=com` subtree. The policy enforced by this ACI can be described as follows:

- For all entries within the subtree, the administrator has add, delete, and browse permissions. Others within the `dc=us` subtree can browse, but those outside it have no access to the subtree.

- The salary attribute can be modified by one's manager and viewed by oneself. No one else has access to the salary attribute.

- The `userPassword` attribute can be viewed and modified by oneself and the administrator. Others can only compare this attribute.

- The `homePhone` attribute can be read and written by oneself and viewed by anyone else.

- For all other attributes, only the administrator can modify values. Everyone else can compare, search, read, but cannot update attribute values.

"orclACI" attribute of "dc=us, dc=acme, dc=com":

    access to entry
    by dn="cn=admin, dc=us,dc=acme,dc=com" (browse, add, delete)
    by dn=".*, dc=us,dc=acme,dc=com" (browse)
    by * (none)

    access to attr=(salary)
    by dnattr=(manager) (read, write)
    by self (read)
    by * (none)

    access to attr=(userPassword)
    by self (search, read, write)
    by dn="cn=admin, dc=us,dc=acme,dc=com" (search, read, write)
    by * (compare)

    access to attr=(homePhone)
    by self (search, read, write)
    by * (read)

    access to attr != (salary, userPassword, homePhone)
    by dn="cn=admin, dc=us,dc=acme,dc=com" (compare, search, read, write)
    by * (compare, search, read)

##### Example: Granting Read-Only Access

This example gives to everyone under `dc=acme,dc=com` access only to read address book attributes. It also extends to everyone read access to all attributes within the `dc=us,dc=acme,dc=com` subtree only.

`orclACI` attribute of `dc=acme, dc=com`:

    access to entry by * (browse)
    access to attr=(cn, telephone, email) by * (search, read)

`orclACI` attribute of `dc=us, dc=acme, dc=com`:

    access to entry by * (browse)
    access to attr=(*) by dn=".*,dc=us,dc=acme,dc=com" (search, read)

##### Example: Granting Selfwrite Access to Group Entries

This example allows people within the US domain to add or remove only their own name (DN) to or from the member attribute of a particular group entry, for example, a mailing list.

`orclEntryLevelACI` attribute of the group entry in question:

    access to attr=(member)
    by dn=".*, dc=us,dc=acme,dc=com" (selfwrite)

| Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index