Skip Navigation Links | |
Exit Print View | |
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1) |
1. Starting and Stopping the Server
2. Configuring the Server Instance
3. Configuring the Proxy Components
4. Configuring Security Between Clients and Servers
5. Configuring Security Between the Proxy and the Data Source
6. Managing Oracle Unified Directory With Oracle Directory Services Manager
Managing Global ACIs With dsconfig
Managing Access Control With Oracle Directory Services Manager
Create an Access Control Point
Create an Access Control Point Based on an Existing Access Control Point
Delete an Access Control Point
Add an ACI Based on an Existing ACI
Granting Write Access to Personal Entries
Granting Write Access Based on DNS
Granting Write Access Based on Authentication Method
Granting a Group Full Access to a Suffix
Granting Rights to Add and Delete Group Entries
Allowing Users to Add or Remove Themselves From a Group
Granting Conditional Access to a Group
Defining Permissions for DNs That Contain a Comma
The Get Effective Rights Control
Using the Get Effective Rights Control
Understanding Effective Rights Results
10. Managing Users and Groups With dsconfig
11. Managing Password Policies
When you maintain the access control policy on the entries of a directory, it is useful to know the effects on security of the ACIs that you define. The directory server enables you to evaluate existing ACIs and report the effective rights that they grant for a given user on a given entry.
The directory server responds to the Get Effective Rights control, which can be included in a search operation. The response to this control is to return the effective rights information about the entries and attributes in the search results. This extra information includes read and write permissions for each entry and for each attribute in each entry. The permissions may be requested for the bind DN used for the search or for an arbitrary DN, allowing administrators to test the permissions of directory users.
Effective rights functionality relies on an LDAP control. To view the effective rights when going through a proxy server, you must enable this control in the proxy chaining policy. You must also ensure that the proxy identity used to bind to the remote server is also allowed to access the effective rights attributes.
The behavior of the Get Effective Rights Control differs from the Internet draft Get Effective Rights Control in the following ways:
There is no response control returned with the search results. Instead, the rights information is added to the result entries. Also, the format of the rights information is completely different from the draft and is described below.
The request control only takes an authzid.
There are two ways to specify the Get Effective Rights control with the ldapsearch command:
Use the -J "1.3.6.1.4.1.42.2.27.9.5.2" option or simply -J effectiverights. If you specify a NULL value for the Get Effective Rights Control's authzid value, the bind user is used as the authzid and the rights for the attributes and entries being returned with the current ldapsearch operation are retrieved.
The simpler and preferred method is to use the -g option with or without the -e option:
-g "dn: DN"--The search results will show the effective rights of the user binding with the given DN. This option allows an administrator to check the effective rights of another user. The option -g "dn:" will show the effective rights for anonymous authentication.
-e attributeName1 -e attributeName2 --The search results will also include the effective rights on the named attributes. This option can be used to specify attributes that would not appear in the search results for the entry. For example, this option can be used to determine if a user has permission to add an attribute that does not currently exist in an entry.
Note - The -e option requires the -g option and should not be used with the -J option.
If you use the -g option, do not use the -J option with the OID of the Get Effective Rights control.
Besides using one of these two ways to specify the Get Effective Rights Control, you must specify the type of information you want to view, either the simple rights or the more detailed logging information that explains how those rights are granted or denied. The type of information is determined by adding either aclRights or aclRightsInfo, respectively, as an attribute to return in the search results. You can request both attributes to receive all effective rights information, although the simple rights are redundant with the information in the detailed logging information.
Note - The aclRights and aclRightsInfo attributes have the behavior of virtual operational attributes. They are not stored in the directory, and they will not be returned unless explicitly requested. These attributes are generated by the directory server in response to the Get Effective Rights Control. For this reason, neither of these attributes can be used in filters or search operations of any kind.
The effective rights feature inherits other parameters that affect access control (such as time of day, authentication method, machine address, and machine name) from the user initiating the search operation.
The following example shows how a user, Carla Fuente, can view her rights in the directory. In the results, a 1 means that permission is granted, and a 0 means that permission is denied.
$ ldapsearch -J effectiverights -h rousseau.example.com -p 1389 \ -D "uid=cfuente,ou=People,dc=example,dc=com" -w password \ -b "dc=example,dc=com" "(objectclass=*)" aclRights dn: dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=Groups, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Accounting Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=HR Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=bjensen,ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=cfuente, ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0
This result shows Carla Fuente the entries in the directory where she has at least read permission and that she can modify her own entry. The effective rights control does not bypass normal access permissions, so a user will never see the entries for which they do not have read permission. In the following example, the Directory Manager can see the entries to which Carla Fuente does not have read permission:
$ ldapsearch -h rousseau.example.com -p 1389 -D "cn=Directory Manager" -w password \ -g "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \ "(objectclass=*)" aclRights dn: dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=Groups, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Directory Administrators, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0 dn: ou=Special Users,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0 dn: ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Accounting Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=HR Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=bjensen,ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=cfuente, ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0
In the output above, the directory manager can see that Carla Fuente cannot even view the Special Users nor the Directory Administrators branches of the directory tree. In the following example, the Directory Administrator can see that Carla Fuente cannot modify the mail and manager attributes in her own entry:
$ ldapsearch -h rousseau.example.com -p 1389 -D "cn=Directory Manager" -w password \ -g "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \ "(uid=cfuente)" aclRights "*" version: 1 dn: uid=cfuente, ou=People, dc=example,dc=com aclRights;attributeLevel;mail: search:1,read:1,compare:1, write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0 mail: cfuente@example.com aclRights;attributeLevel;uid: search:1,read:1,compare:1, write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0 uid: cfuente aclRights;attributeLevel;givenName: search:1,read:1,compare:1, write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0 givenName: Carla aclRights;attributeLevel;sn: search:1,read:1,compare:1, write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0 sn: Fuente aclRights;attributeLevel;cn: search:1,read:1,compare:1, write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0 cn: Carla Fuente aclRights;attributeLevel;userPassword: search:0,read:0, compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0 userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow== aclRights;attributeLevel;manager: search:1,read:1,compare:1, write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0 manager: uid=bjensen,ou=People,dc=example,dc=com aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1, write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0 telephoneNumber: (234) 555-7898 aclRights;attributeLevel;objectClass: search:1,read:1,compare:1, write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
Depending on the options specified, an effective rights request returns the following information:
The effective rights information is presented according to the following subtypes:
aclRights;entrylevel - Presents entry-level rights information
aclRights;attributelevel - Presents attribute-level rights information
aclRightsInfo;entrylevel - Presents entry-level logging information
aclRightsInfo;attributelevel - Presents attribute-level logging information
The format of the aclRights string is as follows:
aclRights;entryLevel: permission:value(permission:value)*
and
aclRights;attributeLevel: permission:value(permission:value)*
The possible entry-level permissions are add, delete, read, write, and proxy. The possible values for each permission are 0 (permission not granted) and 1 (permission granted).
|
Note - For information about assigning these permissions in an ACI, see ACI Syntax in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory.
The possible attribute-level permissions are read, search, compare, write, selfwrite_add, selfwrite_delete, and proxy. The possible values for each permission are 0 (permission not granted) and 1 (permission granted). For the case of the write permission, the value of "?" is also permitted.
|
Note - The write, selfwrite_add, and selfwrite_delete permissions are particularly complex. If you see a "?", consult the logging information to establish why the permissions will or will not be granted. For more information, see Table 9-1.
The format of the aclRightsInfo string is as follows:
aclRightsInfo;logs;entryLevel;permission: acl_summary(main):permission-string
and
aclRightsInfo;logs;attributeLevel;permission;attribute: acl_summary(main):permission-string
The entry-level and attribute-level permissions are described in the preceding section.
The permission-string contains detailed information about the effective rights at the entry-level and attribute-levels.
The attribute-level permission for write can be either 0, 1, or "?". Only write attribute-level permissions can have a value of "?", which usually results from a targattrfilters ACI component. For add and delete permissions, the entries that can be modified depend on the values of the attributes in the entry. Only the permission, 0 or 1, is returned on the entries as they are returned with the ldapsearch operation.
For all attribute values except the authorization dn, if the value for a write permission is 1, the permission is granted for both add and delete. Similarly, for all attribute values except the authorization dn, a value of 0 for a write permission means that the permission is not granted for either add or delete ldapmodify operations. The permission in force for the value of the authorization dn is returned explicitly in one of the selfwrite permissions, that is, either selfwrite_add or selfwrite_delete.
Although selfwrite_add and selfwrite_delete attribute-level permissions do not exist in the context of ACIs, a set of ACIs can grant a user selfwrite permission for just the add or just the delete part of a modify operation. For selfwrite permissions, the value of the attribute being modified is the authorization dn. The same distinction is not made for write permissions because the value of the attribute being modified for a write permission is undefined.
When the effective permission depends on a targattrfilters ACI, the "?" value indicates that the logging information should be consulted for more permission detail. The interdependencies between the write, selfwrite_add, and selfwrite_delete permissions are fairly complex and are outlined in the following table.
Table 9-1 Effective Rights Permission Interdependencies
|
The effective rights logging information enables you to understand and debug access control difficulties. The logging information contains an access control summary statement, called the acl_summary, that indicates why access control has been allowed or denied. The access control summary statement includes the following information:
Whether access was allowed or denied
The permissions granted
The target entry of the permissions
The name of the target attribute
The subject of the rights being requested
Whether or not the request was made by proxy, and if so, the proxy authentication DN
The reason for allowing or denying access (important for debugging purposes as explained in the following table)
The following table lists the effective rights logging information reasons and their explanations.
Table 9-2 Effective Rights Logging Information Reasons and Their Explanations
|
Note - Write permissions for virtual attributes are not provided, nor is any associated logging evaluation information, because virtual attributes cannot be updated.
Viewing effective rights is itself a directory operation that should be protected and appropriately restricted.
The default ACI does not allow read access to the aclRights and aclRightsInfo operational attributes used to return effective rights. Create a new ACI for these attributes to enable access by directory users to this information.
For example, the following ACI allows members of the Directory Administrators group to get effective rights:
aci: (targetattr = "aclRights||aclRightsInfo")(version 3.0; acl "getEffectiveRights"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)
In addition, access is needed to use the Get Effective Rights Control.
To enable access by directory users to the Get Effective Rights Control, create a new ACI target by using the OID (1.3.6.1.4.1.42.2.27.9.5.2) for this control. For additional ACI syntax information, see Defining Targets in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory.
For example, the following ACI allows members of the Directory Administrators group to use the Get Effective Rights control:
aci: (targetcontrol = "1.3.6.1.4.1.42.2.27.9.5.2")(version 3.0; acl "getEffectiveRights control access"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)