Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Internet Directory
11g Release 1 (11.1.1)

Part Number E10029-04
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

29 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 Services Manager or the command-line tool, ldapmodify.

This chapter contains these topics:

29.1 Introduction to Managing Directory Access Control

Authorization is the permission given to a user, program, or process to access an object or set of objects. When directory operations are attempted within a directory session, the directory server ensures that the user has the permissions to perform those operations. If the user does not have the permissions, then the directory server disallows the operation. The directory server protects directory data from unauthorized operations by directory users by using access control information.

Access control information is the directory metadata that captures the administrative policies relating to access control. This information is stored in Oracle Internet Directory as user-modifiable configuration attributes, each of which is called an access control item (A CI).

Typically, a list of these ACI attribute values, called an access control list (ACL), is associated with directory objects. The attribute values on that list represent the permissions that various directory user entities (or subjects) have on a given object.

An ACI consists of:

Access control policies can be prescriptive, that is, their security directives can be set to apply downward to all entries at lower positions in the directory information tree (DIT). The point from which such an access control policy applies is called an access control policy point (ACP).

ACIs are represented and stored as text strings in the directory. These strings must conform to a well-defined format, called the ACI directive format. Each valid value of an ACI attribute represents a distinct access control policy.

The following features of directory access control can be used by applications running in a hosted environment.

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 Services Manager or ldapmodify.

This section contains these topics:

29.1.1 Access Control Management Constructs

This section discusses the structures used for access control in Oracle Internet Directory. These include:

  • Access Control Policy Points (ACPs)

  • The orclACI attribute for prescriptive access control

  • The orclEntryLevelACI attribute for entry-level access control

  • Privilege Groups

29.1.1.1 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, a subordinate entry in that subtree inherits the access policies from all of the superior ACPs. 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.

29.1.1.2 The orclACI Attribute for Prescriptive Access Control

The orclACI attribute contains access control list (ACL) directives that are prescriptive—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 recommends using orclEntryLevelACI—discussed in Section 29.1.1.3, "The orclEntryLevelACI Attribute for Entry-Level Access Control." This is because the LDAP configuration overhead increases with the number of directives represented through orclACI. You can reduce this overhead by moving entry specific directives from orclACI to orclEntryLevelACI.

29.1.1.3 The orclEntryLevelACI Attribute for Entry-Level Access Control

When a policy pertains only to a specific entity—for example, a special user—you can maintain the ACL directives within the entry for that entity. You do this by using a user-modifiable configuration attribute called orclEntryLevelACI. This attribute contains ACL directives only for 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 object class top to include orclEntryLevelACI as an optional attribute.

The orclEntryLevelACI attribute is multi-valued and has a structure similar to that of orclACI.

See Also:

"Object: To What Are You Granting Access?" for the structure definition of the orclEntryLevelACI attribute

29.1.1.4 Security 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.

To specify access rights for a group of people or entities, you identify them in security groups. There are two types of security groups: ACP groups and privilege groups.

29.1.1.4.1 ACP groups

If an individual is a member of an ACP group, then the directory server simply grants to that individual the privileges associated with that ACP group.

Use ACP groups to resolve access at the level of an ACP. For example, suppose you want to give to several hundred users access to browse an entry. You could assign the browse privilege to each entry individually, but this could require considerable administrative overhead. Moreover, if you later decide to change that privilege, you would have to modify each entry individually. A more efficient solution is to assign the privilege collectively. To do this, you create a group entry, designate it as an ACP group, assign the desired privilege to that group, then assign users as members of that group. If you later change the access rights, you must do it in one place, for the group, rather than for each individual user. Similarly, you can remove that privilege from multiple users by removing them from the group, rather than having to access multiple individual entries.

ACP groups are associated with the orclacpgroup object class.

29.1.1.4.2 Privilege Groups

A privilege group is a higher-level access group. It is similar to an ACP group in that it lists users with similar rights. However, it also provides for additional checking beyond a single ACP, as follows: if an ACP denies access, an attribute in the user's entry tells the directory server whether the user being denied is in any privilege group. If so, then this user has additional rights at a higher administration level, and all higher administration levels in the DIT are checked. If the directory server finds a higher ACP that grants to the privilege group access to the requested object, then it overrides the denials by the subordinate ACP, and grants access to the user. If, however, the orclACI or orclEntryLevelACI attribute of a subordinate ACP contains the keyword DenyGroupOverride, the higher level ACP does not override the subordinate ACP. Use DenyGroupOverride to restrict superuser access through privileged groups.

Normally, you would implement only ACP groups. The additional checking that privilege groups provide can degrade performance. Use privilege groups only when access control at higher levels needs the right to override standard controls at lower levels.

Use privilege groups to grant access to administrators who are not recognized by ACPs lower in the DIT. For example, suppose that the global administrator in a hosted environment must perform operations in a realm. Because the global administrator's identity is not recognized in the realm of the hosted company, the directory server, relying only on the ACPs in that realm, denies the necessary access. However, if the global administrator is a member of a privilege group, then the directory server looks higher in the DIT for an ACP that grants to this privilege group the access rights to that subtree. If it finds such an ACP, then the directory server overrides the denials by ACPs in the hosted company's realm.

Add the DenyGroupOverride keyword to an ACI to deny access to members of privileged groups.

Privilege groups are associated with the orclPrivilegeGroup object class.

29.1.1.4.3 Users in Both Types of Groups

If a user is a member of both an ACP group and a privilege group, then the directory server performs an evaluation for each type of group. It resolves access rights for the privilege group by looking to ACPs higher in the DIT.

29.1.1.4.4 Constraints on Security Groups

Do not create a security group that is of both object classes orclacpgroup and orclPrivilegeGroup.

In nested security groups, the parent group and child group must always be of the same objectclass either orclacpgroup or orclPrivilegeGroup.

Violating either of these constrains can result in non-deterministic ACI evaluation.

29.1.1.4.5 Overview: Granting Access Rights to a Group

To grant access rights to a group of users, you do the following:

  1. Create a group entry in the usual way.

  2. Associate the group entry with either the orclPrivilegeGroup object class or the orclACPgroup object class.

  3. Specify the access policies for that group.

  4. Assign members to the group.

29.1.1.4.6 How the Directory Server Computes Security Group Membership

Entries can have either direct memberships in groups, or indirect memberships in other ACP or privilege 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 that level.

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

Each security group, nested or otherwise, must be associated with a security group object class—either orclACPgroup or orclPrivilegeGroup. Even if a group is a member of a security group, the directory server does not consider it for access control purposes unless it is associated with a security group object class. When it has determined the user's membership in security groups, the directory server uses that information for the lifetime of the session.

29.1.1.4.7 Example: Computing Security Group Membership

For example, consider the sample group of entries in Table 29-1, each of which, except Group 4, is marked as a privilege group (objectclass:orclprivilegegroup). You can set access control policies that apply to the members of group1, group2, and group3.

Table 29-1 Sample Security Groups

Group Entry

Group 1

dn: cn=group1,c=us
cn: group1
objectclass: top
objectclass: groupofUniqueNames
objectclass: orclPrivilegeGroup
uniquemember: cn=mary smith,c=us
uniquemember: cn=bill smith,c=us
uniquemember: cn=john smith,c=us

Group 2

dn: cn=group2,c=us
cn: group2
objectclass: top
objectclass: groupofUniqueNames
objectclass: orclPrivilegeGroup
uniquemember: cn=mary jones,c=us
uniquemember: cn=joe jones,c=us
uniquemember: cn=bill jones,c=us
uniquemember: cn=john smith,c=us

Group 3

dn:cn=group3,c=us
cn: group3
objectclass: top
objectclass: groupofUniqueNames
objectclass: orclPrivilegeGroup
uniquemember: cn=group2,c=us
uniquemember: cn=group1,c=us
uniquemember: cn=group4,c=us

Group 4

dn: cn=group4,c=us
cn: group4
objectclass: top
objectclass: groupofUniqueNames
uniquemember: cn=john doe,c=uk
uniquemember: cn=jane doe,c=uk
uniquemember: cn=anne smith,c=us

Group 3 contains the following nested groups:

  • cn=group2,c=us

  • cn=group1,c=us

  • cn=group4,c=us

Access control policies for Group 3 are applicable to members of Group 3, Group 1, and Group 2 because each of them is marked as a privilege group. These same access control policies are not applicable to the members of Group 4 because Group 4 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 doe,c=uk. None of the access policies applicable to the members of Group 3 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 Group 1 and Group 2—then his access rights are governed by access policies set up for members of Group 1, Group 2, and Group 3 (in which Group 1 and Group 2 are nested). This is because all three groups are associated with the object class orclPrivilegeGroup.

See Also:

Either Section 14.2, "Managing Group Entries by Using Oracle Directory Services Manager" or Section 14.3, "Managing Group Entries by Using the Command Line" for instructions on how to modify a group entry to associate it with or disassociate it from either the orclPrivilegeGroup or the orclACPgroup object class

29.1.2 Access Control Information Components

Access control information represents the permissions that various entities or subjects have to perform operations on a given object in the directory. Thus, an ACI consists of three components:

  • The object to which you are granting access

  • The entities or subjects to whom you are granting access

  • The kind of access you are granting

29.1.2.1 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=example,dc=com has an entry level ACI associated with it, then the entry governed by its ACI is exactly: dc=example,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-delimited list of attribute names in the object selector.

attr=(attribute_list)

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

attr!=(attribute_list)

The object part of an access control directive may also include special keywords. These are:

  • DenyGroupOverride, which prevents access from being overridden by higher level ACPs

  • AppendToAll, which causes the subject of an ACI to be added to all other ACIs in that ACP during evaluation.

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:

Appendix H, "The Access Control Directive Format" for information about the format or syntax of ACIs

29.1.2.2 Subject: To Whom Are You Granting Access?

This section describes:

  • The entity being granted access

  • The bind mode—that is, the authentication mode used to verify the identity of that entity

  • The bind IP filter—that is, the IP address filter used to verify the identity of that entity

  • The added object constraint, which limits the kind of objects a user can add below the parent when access is granted.

29.1.2.2.1 Entity

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

You can specify entities either directly or indirectly.

Directly specifying an entity: This method involves entering the actual value of the entity, for example group=managers. You can do this by using:

  • The wildcard character (*), which matches any entry

  • The keyword SELF, which matches the entry protected by the access

  • The keyword SuperUser, which matches the SuperUser DN specified in the directory.

  • A regular expression, which matches an entry's distinguished name, for example, dn=regex

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

Indirectly specifying an entity: This is a dynamic way of specifying entities. It involves specifying a DN-valued attribute that is part of the entry to which you are granting access. There are three types of DN-valued attributes:

  • dnattr: Use this attribute to contain the DN of the entity to which you are granting or denying access for this entry.

  • groupattr: Use this attribute to contain the DNs of the administrative groups to which you are granting or denying access for this entry.

  • guidattr: Use this attribute to contain the global user identifier (orclGUID) of the entry to which you want to grant or deny access for this entry.

For example, suppose you want to specify that Anne Smith's manager can modify the salary attribute in her entry. Instead of specifying the manager DN directly, you specify the DN-valued attribute: dnattr=manager. Then, when John Doe seeks to modify Anne's salary attribute, the directory server:

  1. Looks up the value for her manager attribute and finds it to be John Doe

  2. Verifies that the bind DN matches the manager attribute

  3. Assigns to John Doe the appropriate access

29.1.2.2.2 Bind Mode

The bind mode specifies the methods of authentication and of encryption to be used by the subject.

There are four authentication modes:

  • MD5Digest

  • PKCS12

  • Proxy

  • Simple: Simple password-based authentication

There are three encryption options:

  • SASL

  • SSL No Authentication

  • SSL One Way

Specifying the encryption mode is optional. If it is not specified, then no encryption is used, unless the selected authentication mode is PKCS12. Data transmitted by using PKCS12 is always encrypted.

There is a precedence rule among authentication choices, and it is as follows:

Anonymous < Proxy < Simple < MD5Digest < PKCS12

This rule means that:

  • Proxy authentication blocks anonymous access

  • Simple authentication blocks both Proxy and Anonymous access

  • MD5Digest authentication blocks Simple, Proxy and Anonymous access

  • PKCS12 authentication blocks MD5Digest, Simple, Proxy and Anonymous access

The bind mode syntax is:

BINDMODE =(LDAP_AUTHENTICATION_CHOICE + [ LDAP_ENCRYPTION_CHOICE ] ) 
LDAP_AUTHENTICATION_CHOICE = Proxy | Simple | MD5Digest | PKCS12 
LDAP_ENCRYPTION_CHOICE = SSLNoAuth | SSLOneway | SASL

The LDAP_ENCRYPTION_CHOICE is an optional parameter. If you do not specify it, then the directory server assumes that no encryption is to be used.

29.1.2.2.3 Bind IP Filter

IP address or IP address range of the subject, defined using a standard LDAP filter on the orclipaddress attribute. If the subject's IP address matches the filter defined, then the ACI on which it is defined is applicable for that operation.

The bind ip filter syntax is:

BINDIPFILTER =(LDAPFILTER_FOR_ORCLIPADDRESS)

For example:

The filter (|(orclipaddress=1.2.3.*)(orclipaddress=1.2.4.*)) applies when the subject's IP address begins with 1.2.3 or begins with1.2.4.

The filter (&(orclipaddress!=1.2.*)(orclipaddress!=3.4.*)) applies when the subject's IP address does not begin with 1.2 and does not begin with 3.4.

29.1.2.2.4 Added Object Constraint

When a parent entry has add access, it can add objects as entries lower in the hierarchy. The added object constraint can be used to limit that right by specifying an ldapfilter.

29.1.2.3 Operations: What Access Are You Granting?

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

  • None

  • Compare/nocompare

  • Search/nosearch

  • Read/noread

  • Selfwrite/noselfwrite

  • Write/nowrite

  • Add/noadd

  • Proxy/noproxy

  • Browse/nobrowse

  • Delete/nodelete

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

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

Table 29-2 Types of Access

Access Level Description Type of Object

Compare

Right to perform compare operation on the attribute value

Attributes

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.

Attributes

Search

Right to use an attribute in a search filter

Attributes

Selfwrite

Right to add yourself to, delete yourself from, or modify your 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.

Attributes

Write

Right to modify/add/delete the attributes of an entry.

Attributes

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.

Both entries and attributes

Add

Right to add entries under a target directory entry

Entries

Proxy

Allows the subject to impersonate another user

Entries

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.

Entries

Delete

Right to delete the target entry

Entries


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

Note:

The default access control policy grants the following to both entries and attributes: 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.

29.1.3 Access Level Requirements for LDAP Operations

Table 29-3 lists the various LDAP operations and the access required to perform each one.

Table 29-3 LDAP Operations and Access Needed 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 and Browse access to the entry

Search

  • Search access on the filter attributes and Browse access on the entry (if only the entry DN must 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 must be returned as a result)


29.1.4 How ACL Evaluation Works

When a user tries to perform an operation on a given object, the directory server determines whether that user has the appropriate access to perform that operation on that object. If the object is an entry, it evaluates the access systematically for the entry and each of its attributes.

Evaluating access to an object—including an attribute of an entry—can involve examining all the ACI directives for that object. This is because of the hierarchical nature of ACPs and the inheritance of policies from superior ACPs to subordinate ACPs.

The directory server first examines the ACI directives in the entry-level ACI, orclEntryLevelACI. It proceeds to the nearest ACP, then considers each superior ACP in succession until the evaluation is complete.

During ACL evaluation, an attribute is said to be in one of the states described in Table 29-4:

Table 29-4 Attribute States During ACL Evaluation

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.


In 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 the directory server would return an error to the client.

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

This section contains these topics:

29.1.4.1 Precedence Rules Used in ACL Evaluation

An LDAP operation requires the BindDN, or subject, of the LDAP session to have certain permissions to perform operations on the objects—including the entry itself and 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.

That order of processing follows these rules:

  • The entry level ACI is examined first. ACIs 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

29.1.4.1.1 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)
    
29.1.4.1.2 Precedence at the Attribute Level

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

  1. ACIs for specified attributes 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)
      
  2. ACIs for unspecified attributes 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)
      

29.1.4.2 Use of More Than One ACI for the Same Object

Oracle Internet Directory, enables you to define more than one ACI in the ACP of an object. It processes the ACIs associated with that object and stores them as a single ACI in its internal ACP cache. It then applies all the relevant policies in the multiple ACIs specified in the ACP.

The following example of an ACP illustrates how this works.

Access to entry by dn="cn=john" (browse,noadd,nodelete)
Access to entry by group="cn=admingroup" (browse,add,nodelete)
Access to entry by dn=".*,c=us" (browse,noadd,nodelete)

In this ACP, there are three ACIs for the object entry. When it loads this ACP, Oracle Internet Directory merges these three ACIs as one ACI in its internal ACP cache.

The ACI syntax is:

Access to OBJECT> by SUBJECT ACCESSLIST
OBJECT = [ entry | attr [EQ-OR-NEQ] ( * | ATTRLIST ) ]
[ filter = ( LDAFILTER ) ]

This syntax makes possible the following types of objects:

  • Entry

  • Entry + filter = ( LDAPFILTER )

  • Attr = ( ATTRLIST )

  • Attr = ( ATTRLIST) + filter = ( LDAPFILTER )

  • Attr != ( ATTRLIST )

  • Attr != ( ATTRLIST ) + filter = ( LDAPFILTER )

  • Attr = ( * )

  • Attr = ( * ) + filter = ( LDAPFILTER )

You can define multiple ACIs for any of the above types of objects. During initial loading of the ACP, the directory server merges the ACIs based on which of these object types are defined. The matching criterion is the exact string comparison of the object strings in the ACIs.

If one ACI specifies ATTR=(ATTRLIST) and another ATTR!=(ATTRLIST), then ATTR=(*) must not be specified as an ACI in the entry. Also, if an ACI specifies ATTR=(ATTRLIST), then, to specify the access rights to attributes not in ATTRLIST, ATTR=(*) must be used and not ATTR!=(ATTRLIST). ATTR=(*) implies all attributes other than those specified in ATTRLIST.

Note:

When you define multiple ACIs on the same attribute with the same filter, Oracle Internet Directory merges them to create a single ACI in the run-time structure.

When you define multiple ACIs on the same attribute with different filters, Oracle Internet Directory treats them as separate ACIs. In such cases, the precedence order is non-deterministic.

To prevent ambiguous behavior, if you define multiple ACIs with different filters against the same attribute, ensure that the filters yield non-overlapping sets of results.

29.1.4.3 Exclusionary Access to Directory Objects

If an ACI exists for a given object, you can specify access to all other objects except that one. You do this either by granting access to all the objects, or by denying access to the one object.

In the following example, access is granted to all attributes:

access to attr=(*) 

 by group2 (read)

In the following example, access is denied to the userpassword attribute:

access to attr!=(userpassword)

 by group2 (read)

29.1.4.4 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 that object 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 precedence over any denials lower in the DIT.

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

29.2 Managing Access Control by Using Oracle Directory Services Manager

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

Note:

Immediately after installing Oracle Internet Directory, be sure to reset the default security configuration as described in "Task 1: Reset the Default Security Configuration" on page 4-1

This section contains these topics:

29.2.1 Viewing an ACP by Using Oracle Directory Services Manager

You can locate and view an ACP as follows:

  1. Invoke Oracle Directory Services Manager and connect to the Oracle Internet Directory server as described in Section 7.4.5, "Invoking Oracle Directory Services Manager."

  2. From the task selection bar, select Security.

  3. Click Access Control in the left pane. All of the defined access control points (ACPs) appear in the left pane, listed by relative DN. Mouse over an entry to see the full DN.

  4. Select an ACP to display its information in the right pane.

  5. The Subtree Access Items section of the page shows the access controls on this ACP for entry level operations, that is, for operations on the entry itself.

    The Content Access Items section of the page shows the access controls on this ACP for attribute level operations, that is, for operations on the attributes of the entry.

29.2.2 Adding an ACP by Using Oracle Directory Services 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.

Adding an ACP by using Oracle Directory Services Manager involves three tasks:

29.2.2.1 Task 1: Specify the Entry That Will Be the ACP

  1. Invoke Oracle Directory Services Manager and connect to the Oracle Internet Directory server as described in Section 7.4.5, "Invoking Oracle Directory Services Manager."

  2. From the task selection bar, select Security.

  3. Click Access Control in the left pane. All of the defined ACPs appear in the left pane.

  4. In the left pane, click the Create Access Control Policy Point icon. The New Access Control Point screen appears.

  5. Enter the path to the entry you want to create, or click Browse, select a DN, and click OK.

    If the entry is already defined as an ACP, you see an error dialog

  6. Alternatively, to create an ACP that is similar to an existing ACP, select the existing ACP in the list under Access Control Management in the left pane and click the Create Like icon. The New Access Control Point: Create Like screen appears.

29.2.2.2 Task 2: Configure Structural Access Items

  1. To define a new structural access item, that is, an ACI that pertains to an entry, choose the Create new access item icon in the Structural Access Items section of the New Access Control Point pane or the New Access Control Point: Create Like pane. The Structural Access Item dialog box appears.

    Alternatively, you can create a structural access item similar to an existing item. Select an existing structural access item and choose the Create Copy of Selected Access Item icon in the Structural Access Items section of the he New Access Control Point or New Access Control Point: Create Like pane. The Structural Access Item dialog box appears. Some of the tabs are populated with configuration information, which you can modify as necessary.

    The structural Access Item dialog box has four tabs: Entry Filter, Added Object Filter, By Whom, and Access Rights. You can use the Entry Filters tab page to limit the subtree entries to which an ACI pertains. Use the Added Object Filter, By Whom, and Access Rights tabs to specify the access control.

  2. If you want all entries below the ACP to be governed by the ACP, then you do not need to enter anything on the Entry Filter tab page; simply proceed to the next step. Otherwise, perform this step.

    You might restrict access to an entry based on one or more of that entry's attributes. For example, you might choose to restrict access to all entries in which the title is manager and in which the organization unit is Americas.

    To use an existing filter, select Existing from the Filter Type menu., then select one of the existing filters.

    To create a new filter, select Create New from the Filter Type menu, then either type a query string directly into the LDAP Query text field, or use the lists and text fields on the search criteria bar to focus your search.

    1. From the list at the left end of the search criteria bar, select an attribute of the entry for which you want to search. Because not all attributes are used in every entry, be sure that the attribute you specify actually corresponds to one in the entry for which you are looking. Otherwise, the search fails.

    2. From the list in the middle of the search criteria bar, select a filter.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you just selected. For example, if the attribute you selected was cn, you could type the particular common name you want to find.

    4. Click + to add this search criterion to the LDAP Query field.

    5. To further refine your search, use the list of conjunctions (AND, OR, NOT AND, and NOT OR) and the lists and text fields on the search criteria bar to to add additional search criteria. Click + to add a search criterion to the LDAP Query field.Click X to delete a search criterion from the LDAP Query field.

  3. Select the Added Object Filter tab page.

    You can specify ACIs to restrict the kind of entries a user can add. For example, you can specify an ACI in the DSE root entry that allows users to add only entries with objectclass=country. The directory server then verifies that any new entry complies with the constraints in this filter.

    To restrict the kind of entries a user can add either type a query string directly into the LDAP Query text field, or use the lists and text fields on the search criteria bar to focus your search, following the same steps as in the Entry Filter tab page.

  4. Select the By Whom tab page.

    1. In the By Whom field, specify the entity or entities to whom you are granting access.

    2. From the Authentication Choice list under Bind Mode, select the type of authentication to be used by the subject (that is, the entity that seeks access).

      If you do not choose an authentication method, then any kind of authentication is accepted. The authentication method specified on one node should match the one specified on the node it is communicating with.

      From the Encryption Choice list under Bind Mode, select the type of encryption to be used.

  5. Select the Access Rights tab page.

    Specify the kinds of rights to be granted:

    • Browse: Allows the subject to see the entry

    • Add: Allows the subject to add other entries below this entry

    • Delete: Allows the subject to delete the entry

    • Proxy: Allows the subject to impersonate another user

  6. Click OK. The structural access item you just created appears in the list.

Repeat Task 2: Configure Structural Access Items to configure additional structural access items in this ACP.

29.2.2.3 Task 3: Configure Content Access Items

  1. To define content access items, that is, ACIs that pertain to attributes, choose the Create new access item icon in the Content Access Items section of the New Access Control Point pane or the New Access Control Point: Create Like pane. The Content Access Item dialog box appears.

    Alternatively, you can create a content access item similar to an existing item. Select an existing content access item and choose the Create copy of selected access item icon in the Content Access Items section of the he New Access Control Point or New Access Control Point: Create Like pane. The Content Access Item dialog box appears. Some of the tabs are populated with configuration information, which you can modify as necessary.

    The Content Access Item dialog box has four tabs: Entry Filter, By Whom, Attribute, and Access Rights. You can use the Entry Filters tab page to limit the subtree entries to which an ACI pertains. Use the By Whom, Attribute, and Access Rights tabs to specify the access control.

  2. If you want all entries below the ACP to be governed by the ACP, then you do not need to enter anything on Entry Filter tab page; simply proceed to the next step. Otherwise, perform this step.

    In an ACP, the access rights apply to the entry and all its subentries unless other filters restrict access further. If appropriate, use the Entry Filters tab page to identify the entries to which you are specifying access.

    You might restrict access to an entry based on one or more of that entry's attributes. For example, you might choose to restrict access to all entries in which the title is manager and in which the organization unit is Americas.

    To use an existing filter, select Existing from the Filter Type menu, then select one of the existing filters.

    To create a new filter, select Create New from the Filter Type menu, then either type a query string directly into the LDAP Query text field, or use the lists and text fields on the search criteria bar to focus your search.

    1. From the list at the left end of the search criteria bar, select an attribute of the entry for which you want to search. Because not all attributes are used in every entry, be sure that the attribute you specify actually corresponds to one in the entry for which you are looking. Otherwise, the search fails.

    2. From the list in the middle of the search criteria bar, select a filter.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you just selected. For example, if the attribute you selected was cn, you could type the particular common name you want to find.

    4. Click + to add this search criterion to the LDAP Query field.

    5. To further refine your search, use the list of conjunctions (AND, OR, NOT AND, and NOT OR) and the lists and text fields on the search criteria bar to to add additional search criteria. Click + to add a search criterion to the LDAP Query field. Click X to delete a search criterion from the LDAP Query field.

  3. Select the By Whom tab page.

    1. In the By Whom field, specify the entity or entities to whom you are granting access.

    2. From the Authentication Choice list under Bind Mode, select the type of authentication to be used by the subject (that is, the entity that seeks access).

      If you do not choose an authentication method, then any kind of authentication is accepted. The authentication method specified on one node should match the one specified on the node it is communicating with.

      From the Encryption Choice list under Bind Mode, select the type of encryption to be used.

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

  4. Select the Attribute tab page.

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

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

      For example, if you select EQ and cn, then the access rights you grant apply to the cn attribute. If you select NEQ and cn, then the access rights you grant do not apply to the cn attribute.

  5. Select the Access Rights tab page.

    Specify the kinds of rights to be granted or denied:

    • Read: Allows the subject to read the attribute

    • Search: Allows the subject to search for the attribute

    • Write: Allows the subject to change the attribute

    • Selfwrite: Allows the subject specified by the entry itself to change the attribute

    • Compare: Allows the subject to compare the value of the attribute with that of other attributes.

  6. Click OK. The content access item you just created appears in the list.

Repeat Task 3: Configure Content Access Itemsto configure additional content access items in this ACP.

29.2.2.4 Delete a Structural or Content Access Item

To delete a structural or content access item, select the item and click the Delete icon.

29.2.3 Modifying an ACP by Using Access Control Management in ODSM

  1. Invoke Oracle Directory Services Manager and connect to the Oracle Internet Directory server as described in Section 7.4.5, "Invoking Oracle Directory Services Manager."

  2. From the task selection bar, select Security.

  3. Click Access Control in the left pane. All of the defined ACPs appear in the left pane.

  4. In the left pane, select an ACP in the list. A tab page for that ACP appears in the right pane.

  5. To define a new structural access item, that is, an ACI that pertains to an entry, choose the Create icon in the Structural Access Items section of the entry tab page. The Structural Access Item dialog box appears.

    Alternatively, you can create a structural access item similar to an existing item. Select an existing structural access item and choose the Create Like icon in the Structural Access Items section of the he New Access Control Point or New Access Control Point: Create Like pane. The Structural Access Item dialog box appears. Some of the tabs are populated with configuration information, which you can modify as necessary.

    The Structural Access Item dialog box has four tabs: Entry Filter, Added Object Filter, By Whom, and Access Rights. You can use the Entry Filters tab page to limit the subtree entries to which an ACI pertains. Use the Added Object Filter, By Whom, and Access Rights tabs to specify the access control. Follow the steps beginning with Step 2 under Section 29.2.2.2, "Task 2: Configure Structural Access Items."

  6. To modify an existing structural access item, select the item and click Edit. The Structural Access Item dialog box appears. Some of the tabs are populated with configuration information, which you can modify as necessary. The tabs are:Entry Filter, Added Object Filter, By Whom, and Access Rights. You can use the Entry Filters tab page to limit the subtree entries to which an ACI pertains. Use the Added Object Filter, By Whom, and Access Rights tabs to specify the access control. Follow the steps beginning with Step 2 under "Task 2: Configure Structural Access Items". When you click OK, the changes you made to the structural access item are reflected in the list.

  7. To define a new content access item, that is, an ACI that pertains to attributes, choose the Create icon in the Content Access Items section of the entry tab page. The Content Access Item dialog box appears.

    Alternatively, you can create a content access item similar to an existing item. Select an existing content access item and choose the Create Like icon in the Content Access Items section of the he New Access Control Point or New Access Control Point: Create Like pane. The Content Access Item dialog box appears. Some of the tabs are populated with configuration information, which you can modify as necessary.

    The Content Access Item dialog box has four tabs: Entry Filter, By Whom, Attribute, and Access Rights. You can use the Entry Filters tab page to limit the subtree entries to which an ACI pertains. Use the By Whom, Attribute, and Access Rights tabs to specify the access control. Follow the steps beginning with Step 2under "Task 3: Configure Content Access Items".

  8. To modify an existing content access item, select the item and click Edit. The Content Access Item dialog box appears. It has four tabs: Entry Filter, By Whom, Attribute, and Access Rights. You can use the Entry Filters tab page to limit the subtree entries to which an ACI pertains. Use the By Whom, Attribute, and Access Rights tabs to specify the access control.hey are:Entry Filter, Added Object Filter, By Whom, and Access Rights. You can use the Entry Filters tab page to limit the subtree entries to which an ACI pertains. Use the Added Object Filter, By Whom, and Access Rights tabs to specify the access control. Follow the steps under "Task 3: Configure Content Access Items". When you click OK, the changes you made appear in the list.

  9. To delete a structural or content access item, select the item and click the Delete icon.

  10. Click Apply to effect the changes.

29.2.4 Adding or Modifying an ACP by Using the Data Browser in ODSM

To set subtree-level access by using the Data Browser in Oracle Directory Services Manager:

  1. Invoke Oracle Directory Services Manager as described in Section 7.4.5, "Invoking Oracle Directory Services Manager."

  2. From the task selection bar, choose Data Browser.

  3. Navigate to the entry you want to set access to.

  4. In the navigator pane, select the entry to display its properties in the right pane

  5. Select the Subtree Access tab page, then create and edit local ACIs in the Structural Access Item and Content Access Item tabs as described inSection 29.2.3, "Modifying an ACP by Using Access Control Management in ODSM."

  6. After you have made the changes, click Apply.

    Note:

    You must click Apply to send the information you just entered to the directory server. Otherwise, the information is simply held in the Oracle Directory Services Manager cache.

29.2.5 Setting or Modifying Entry-Level Access by Using the Data Browser in ODSM

To set entry-level access by using Oracle Directory Services Manager:

  1. Invoke Oracle Directory Services Manager as described in Section 7.4.5, "Invoking Oracle Directory Services Manager."

  2. From the task selection bar, choose Data Browser.

  3. Navigate to the entry you want to set access to.

  4. In the navigator pane, select the entry to display its properties in the right pane

  5. Select the Local Access tab page, then create and edit local ACIs in the Structural Access Item and Content Access Item tabs as described in Section 29.2.3, "Modifying an ACP by Using Access Control Management in ODSM."

  6. After you have made the changes, click Apply.

    Note:

    You must click Apply to send the information you just entered to the directory server.

29.3 Managing Access Control by Using Command-Line Tools

As described in Section 29.1, "Introduction to Managing Directory Access Control," directory access control policy information is represented as user-modifiable configuration attributes. You can manage it by using command-line tools, including ldapmodify and ldapmodifymt, to set and alter the values of these attributes.

To directly edit the ACI, you should understand the format and semantics of the directory representation of the ACI as described in Appendix H, "The Access Control Directive Format".

This section contains these topics:

See Also:

29.3.1 Restricting the Kind of Entry a User Can Add

You can specify ACIs to restrict the kind of entries a user can add. For example, you can specify an ACI in the DSE root entry that allows users to add only entries with objectclass=country. To do this, you use the added_object_constraint filter. The directory server then verifies that any new entry complies with the constraints in this filter.

The following example specifies that:

  • The subject cn=admin,c=us can browse, add, and delete under organization entries.

  • The subject cn=admin,c=us can add organizationalUnit objects under organization entries

  • All others can browse under organization entries

access to entry filter=(objectclass=organization)  
by group="cn=admin,c=us"
          constraintonaddedobject=(objectclass=organisationalunit)
          (browse,add,delete) 
by * (browse)

29.3.2 Setting Up an Inheritable ACP by Using ldapmodify

This example sets up subtree access permissions in an orclACI at the root DSE by using an LDIF file named my_ldif_file. Because this example refers to the orclACI attribute, this access directive governs all the entries in the DIT.

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

The LDIF file, my_ldif_file, contains the following:

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)

29.3.3 Setting Up Entry-Level ACIs by Using ldapmodify

This example sets up entry-level access permissions in the orclEntryLevelACI attribute by using an LDIF file named my_ldif_file. Because this example refers to the orclentrylevelACI attribute, this access directive governs only the entry in which it resides.

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

The LDIF file, my_ldif_file, contains the following:

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)

Note:

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

29.3.4 Using Wildcards in an LDIF File with ldapmodify

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

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

In the ACP at dc=com, the orclACI attribute is specified as follows:

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

Note that, in order to enable reading the attributes, you must grant permission to browse the entries.

29.3.5 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 read-only access to the address book attributes under dc=example,dc=com access.

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

The orclACI attribute of dc=example,dc=com is specified as follows:

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

The orclACI attribute of dc=us, dc=example,dc=com is specified as follows:

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

29.3.6 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=example,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 your manager and viewed by yourself. No one else has access to the salary attribute.

  • The userPassword attribute can be viewed and modified by yourself and the administrator. Others can only compare this attribute.

  • The homePhone attribute can be read and written by yourself 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.

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

The orclACI attribute of dc=us,dc=example,dc=com is specified as follows:

access to entry 
by dn="cn=admin, dc=us,dc=example,dc=com" (browse, add, delete) 
by dn=".*, dc=us,dc=example,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=example,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=example,dc=com" (compare, search, read, write) 
by * (compare, search, read) 

29.3.7 Granting Read-Only Access

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

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

The orclACI attribute of dc=example,dc=com is specified as follows:

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

The orclACI attribute of dc=us,dc=example,dc=com is specified as follows:

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

29.3.8 Granting Selfwrite Access to Group Entries

This example enables 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.

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

The orclEntryLevelACI attribute of the group entry is specified as follows:

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

29.3.9 Defining a Completely Autonomous Policy to Inhibit Overriding Policies

This example denies group override.

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

The example uses the following DNs:

Table 29-5 DNs Used in Example

Container DN

Naming context to be restricted from Group overriding policies

c=us

User container

cn=users,c=us

Sensitive data

cn=appdata

User admin group for this naming context

cn= user admin group, cn=users,c=us

Security admin group or this naming context

cn= security admin group, cn=users,c=us

Global password admin group for all naming contexts that reset passwords

cn=password admin group


The policy requirements for c=us are as follows:

  • Users can browse and read their information.

  • The user security admin can modify the information under c=us except for passwords and ACPs.

  • The security admin group can modify policies under c=us.

  • The global password admin and the user can reset a password.

  • All other users have no permissions.

  • This policy cannot be overridden.

Required ACP:

Access to entry DenyGroupOverride 
by dn=".*,c=us" (browse,noadd,nodelete)
by group="cn=User admin group,cn=users,c=us" (browse,add,delete)
Access to attr=(orclaci) DenyGroupOverride
by group="cn=security admin group,cn=users,c=us" (search,read,write,compare)
by * (none)
Access to attr=(userpassword) DenyGroupOverride
by self (search,read,write,compare)
by group="cn=password admin group" (search,read,write,compare)
by * (none)
Access to attr=(*) DenyGroupOverride
by self (search,read,nowrite,compare)
by group="cn= User admin group,cn=users,c=us" (search,read,write,compare)
by * (none)