Starting and Stopping Your Server Instance
Configuring the Server Instance
Configuring the Proxy Components
Configuring Security Between Clients and Servers
Configuring Security Between the Proxy and the Data Source
Configuring Servers With the Control Panel
Managing Global ACIs With dsconfig
Granting Write Access to Personal Entries
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
Understanding Effective Rights Results
Restricting Access to the Get Effective Rights Control
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