6.7. Get Effective Rights Control
Finding the rights on existing attributes within a specific entry offers a convenient way for administrators to find and control the access rights.
Get effective rights is an extended ldapsearch which returns the access control permissions set on each attribute within an entry. The effective rights can be retrieved by sending an LDAP control along with a search operation. The results show the effective rights on each returned entry and each attribute of each returned entry.
The access control information is divided into two groups of access: rights for an entry and rights for an attribute. Rights for an entry means the rights, such as modify or delete, that are limited to that specific entry. Rights for an attribute means the access right to every instance of that attribute throughout the directory.
Some of the situations when this kind of detailed access control may be necessary include the following:
An administrator can use the get effective rights command for minute access control, such as allowing certain groups or users access to entries and restricting others. For instance, members of the QA Managers group may have the right to search and read attributes like manager and salary but only HR Group members have the rights to modify or delete them.
A user can run the get effective rights command to see what attributes he can view or modify on his personal entry. For instance, a user should have access to attributes such as homePostalAddress and cn but may only have read access to manager and salary.
An ldapsearch run with the -J option (which sets the get effective rights control) returns the access controls placed on a particular entry. The entryLevelRights and attributeLevelRights returns are added as attributes to the bottom of the query results. If ldapsearch is run without -J, then the entry information is returned as normal, without the entryLevelRights or attributeLevelRights information.
A get effective rights result looks like the following:
dn: uid=tmorris, ou=People, dc=example,dc=com
l: Santa Clara
userPassword: {SSHA}bz0uCmHZM5b357zwrCUCJs1IOHtMD6yqPyhxBA==
entryLevelRights: vadn
attributeLevelRights: l:rscwo, userPassword:wo
In this example, Ted Morris has the right to add, view, delete, or rename the DN on his own entry, as shown by the return values in entryLevelRights. For attributes, he has the right to read, search, compare, self-modify, or self-delete the location (l) attribute but only self-write and self-delete rights to his password, as shown in the attributeLevelRights return value.
Information is not given for attributes in an entry that do not have a value; for example, if the userPassword value is removed, then a future effective rights search on the entry above would not return any effective rights for userPassword, even though self-write and self-delete rights could be allowed. Likewise, if the street attribute were added with read, compare, and search rights, then street: rsc would appear in the attributeLevelRights results.
Table 6.6, “Permissions That Can Be Set on Entries” and Table 6.7, “Permissions That Can Be Set on Attributes” summarize the permissions that can be set on entries and on attributes that are retrieved by the get effective rights operation.
| Permission | Description |
|---|---|
| a | Add. |
| d | Delete. |
| n | Rename the DN. |
| v | View the entry. |
| Permission | Description |
|---|---|
| r | Read. |
| s | Search. |
| w |
Write (mod-add).
|
| o |
Obliterate(mod-del). Analogous to delete.
|
| c | Compare. |
| W | Self-write. |
| O | Self-delete. |
To retrieve the effective rights with ldapsearch, you must pass the control information with the ldapsearch utility's -J option, as follows:
ldapsearch -pport-hhost-DbindDN-wbindPassword-bsearch_base-Jcontrol OID:boolean criticality:dn:AuthId
search_base specifies the entry or entries being checked, while AuthId checks the rights of the AuthId entry over the search_base entry.
control OID is the OID for the get effective rights control, 1.3.6.1.4.1.42.2.27.9.5.2.
boolean criticality specifies whether the search operation should return an error if the server does not support this control (true) or if it should be ignored and let the search return as normal (false).
AuthId is the DN of the entry whose rights over the user account are being checked. If the AuthId is left blank (dn:), than the rights of an anonymous user are returned.
A user, such as Ted Morris, can use this ldapsearch option to retrieve the rights he has to his personal entry, as shown below. Along with returning the effective rights information, the ldapsearch returns the regular entry information:
ldapsearch -p 389 -h localhost -D "uid=tmorris,ou=people,dc=example,dc=com" -w password
-b "uid=tmorris,ou=people,dc=example,dc=com" -J "1.3.6.1.4.1.42.2.27.9.5.2:true:
dn:uid=tmorris,ou=people,dc=example,dc=com" "(objectClass=*)"
version: 1
dn: uid=tmorris, ou=People, dc=example,dc=com
givenName: Ted
sn: Morris
ou: Accounting
ou: People
l: Santa Clara
manager: uid=dmiller, ou=People, dc=example,dc=com
roomNumber: 4117
mail: tmorris@example.com
facsimileTelephoneNumber: +1 408 555 5409
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: tmorris
cn: Ted Morris
userPassword: {SSHA}bz0uCmHZM5b357zwrCUCJs1IOHtMD6yqPyhxBA==
entryLevelRights: v
attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rsc,
manager:rsc, roomNumber:rscwo, mail:rscwo,
facsimileTelephoneNumber:rscwo, objectClass:rsc, uid:rsc,
cn:rsc, userPassword:wo
An administrative user, such as Directory Manager, can use the get effective rights operation to determine what rights are granted between users. The following is a sample ldapsearch to retrieve effective rights that a manager, Dave Miller (shown in the dn:user part of the -J value), has over the entry of one of his subordinates, Ted Morris (shown in the -b value):
ldapsearch -p 389 -h localhost -D "cn=directory manager" -w password
-b "uid=tmorris,ou=people,dc=example,dc=com" -J "1.3.6.1.4.1.42.2.27.9.5.2:true:dn:
uid=dmiller,ou=people,dc=example,dc=com" "(objectClass=*)"
version: 1
dn: uid=tmorris, ou=People, dc=example,dc=com
givenName: Ted
sn: Morris
ou: Accounting
ou: People
l: Santa Clara
manager: uid=dmiller, ou=People, dc=example,dc=com
roomNumber: 4117
mail: tmorris@example.com
facsimileTelephoneNumber: +1 408 555 5409
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: tmorris
cn: Ted Morris
userPassword: {SSHA}bz0uCmHZM5b357zwrCUCJs1IOHtMD6yqPyhxBA==
entryLevelRights: vadn
attributeLevelRights: givenName:rscwo, sn:rscwo, ou:rscwo,
l:rscwo, manager:rscwo, roomNumber:rscwo, mail:rscwo,
facsimileTelephoneNumber:rscwo, objectClass:rscwo, uid:rscwo,
cn:rscwo, userPassword:rscwo
For all attributes, Dave Miller has read, search, compare, modify, and delete permissions to Ted Morris's entry. These results are different than the ones returned in checking Ted Morris's access to his own entry, since he personally had only read, search, and compare rights to most of these attributes.
Only an administrator can retrieve effective rights to another user's entry. If Ted Morris tried to determine Dave Miller's rights to Dave Miller's entry, then he would receive the following error:
ldapsearch -p 389 -h localhost -D "uid=dmiller,ou=people,dc=example,dc=com" -w password
-b "uid=tmorris,ou=people,dc=example,dc=com" -J "1.3.6.1.4.1.42.2.27.9.5.2:true:dn:
uid=tmorris,ou=people,dc=example,dc=com" "(objectClass=*)"
ldap_search: Insufficient access
ldap_search: additional info: get-effective-rights: requestor has no g permission on the entry
However, Ted Morris could run a get effective rights search on his personal entry to determine the rights another user, such as Sam Carter, has to it. Assuming that an ldapsearch was run with -b set to uid=tmorris,ou=people,dc=example,dc=com and the AuthId was set to uid=scarter,ou=people,dc=example,dc=com, then Ted Morris would retrieve the following effective rights information:
entryLevelRights: v attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rsc,manager:rsc, roomNumber:rsc, mail:rsc, facsimileTelephoneNumber:rsc, objectClass:rsc, uid:rsc, cn:rsc,userPassword:none
This means that Sam Carter has the right to view the DN of the entry and to read, search; the right to compare the ou, givenName, l, and other attributes; and no rights to the userPassword attribute.
To view effective rights from the Console, do the following:
Open the Directory tab, and right-click the entry which rights you want to check.
Select Advanced Properties from the drop-down menu.
The Property Editor appears.
Check the Show effective rights checkbox.
The attribute-level effective rights (r, s, c, w, o) appear next to the attributes. The entry-level rights (v, a, d, n) appear under the full DN for the entry in the lower left-hand corner of the Property Editor.
If you check the Show all allowed attributes checkbox, then the effective rights for those attributes appear next to the additional attributes, even though they do not have values.
If the criticality is set to false for a get effective rights search and an error occurs, the regular entry information is returned, but, in place of rights for entryLevelRights and attributeLevelRights, an error code is returned. This code can give information on the configuration of the entry that was queried. Table 6.8, “Returned Result Codes” summarizes the error codes and the potential configuration information they can relay.
| Code | Description |
|---|---|
| 0 | Successfully completed. |
| 1 | Operation error. |
| 12 |
The critical extension is unavailable. If the criticality expression is set to true and effective rights do not exist on the entry being queried, then this error is returned.
|
| 16 | No such attribute. If an attribute is specifically queried for access rights but that attribute does not exist in the schema, this error is returned. |
| 17 | Undefined attribute type. |
| 21 | Invalid attribute syntax. |
| 50 | Insufficient rights. |
| 52 | Unavailable. |
| 53 | Unwilling to perform. |
| 80 | Other. |