This chapter describes how to create ACIs to control access to your data.
Controlling access to directory contents is an integral part of creating a secure directory service. Access to data is managed with access control instructions (ACIs) that specify the access right to individual entries, all sub-entries below an entry, or all entries on a global basis.
Numerous or complicated ACIs require greater processing resources than a few simple ACIs. You can significantly reduce the performance of your directory by specifying a large number of ACIs or extremely complicated ACIs.
Oracle Unified Directory includes the ability to view the effective rights of a given user for a given entry. This feature simplifies the administration of the complex and powerful access control mechanism.
Note:
For an overview of the ACI model, see Chapter 9, "Understanding the Oracle Unified Directory Access Control Model."This chapter contains the following sections:
dsconfigGlobal ACIs control access to the root of the DIT instead of to a particular sub-tree. Global ACIs apply to all entries in the directory. You can set, reset, and delete global ACIs with the dsconfig command and with the ldapmodify command. dsconfig accesses the server configuration over SSL, using the administration connector. For more information about dsconfig, see Section 17.1, "Managing the Server Configuration Using dsconfig."
You cannot use dsconfig to manage ACIs that are applied to entries in sub-trees. To manage non-global ACIs, see Section 28.2, "Managing ACIs With ldapmodify."
When you install Oracle Unified Directory, nine default global ACIs are defined. The effect of all the default global ACIs is to allow the following:
Anyone has read access to certain controls and extended operations.
Anyone has access to search, compare, and read attributes at the rootDSE level. Certain attributes require explicit access.
Authenticated users can modify a subset of the attributes in their own entries in the directory. Users are unable to delete their own entries.
Anyone has access to key operational attributes including many in the root DSE and cn=schema, as well as other attributes that show up in entries throughout the server.
The proxy does not evaluate global ACIs. The proxy forwards LDAP requests to the remote LDAP server, and the remote LDAP server evaluates the ACIs.
The global ACIs are all values of the global-aci property of the access control handler. You can use dsconfig to display the global ACIs currently configured on the server by viewing the global-aci property.
Run the dsconfig command as follows:
$ dsconfig -h localhost -p 5444 -D cn="Directory Manager" -j pwd-file.txt -X -n get-access-control-handler-prop --property global-aci
Property : Value(s)
-----------:-------------------------------------------------------------------
global-aci : (extop="1.3.6.1.4.1.26027.1.6.1 || 1.3.6.1.4.1.26027.1.6.3 ||
: 1.3.6.1.4.1.4203.1.11.1 || 1.3.6.1.4.1.1466.20037 ||
: 1.3.6.1.4.1.4203.1.11.3") (version 3.0; acl "Anonymous extended
: operation access"; allow(read) userdn="ldap:///anyone";),
: "(target="ldap:///")(targetscope="base")(targetattr="objectClass||
: namingContexts||supportedAuthPasswordSchemes||supportedControl||su
: pportedExtension||supportedFeatures||supportedLDAPVersion||support
: edSASLMechanisms||vendorName||vendorVersion")(version 3.0; acl
: "User-Visible Root DSE Operational Attributes"; allow
: (read,search,compare) userdn="ldap:///anyone";)",
: (target="ldap:///cn=changelog")(targetattr="*")(version 3.0; acl
: "External changelog access"; deny (all) userdn="ldap:///anyone";),
: "(target="ldap:///cn=schema")(targetscope="base")(targetattr="obje
: ctClass||attributeTypes||dITContentRules||dITStructureRules||ldapS
: yntaxes||matchingRules||matchingRuleUse||nameForms||objectClasses"
: )(version 3.0; acl "User-Visible Schema Operational Attributes";
: allow (read,search,compare) userdn="ldap:///anyone";)",
: (target="ldap:///dc=replicationchanges")(targetattr="*")(version
: 3.0; acl "Replication backend access"; deny (all)
: userdn="ldap:///anyone";),
: (targetattr="audio||authPassword||description||displayName||givenN
: ame||homePhone||homePostalAddress||initials||jpegPhoto||labeledURI
: ||mobile||pager||postalAddress||postalCode||preferredLanguage||tel
: ephoneNumber||userPassword")(version 3.0; acl "Self entry
: modification"; allow (write) userdn="ldap:///self";),
: "(targetattr="createTimestamp||creatorsName||modifiersName||modify
: Timestamp||entryDN||entryUUID||subschemaSubentry||orclguid||nsuniq
: ueid")(version 3.0; acl "User-Visible Operational Attributes";
: allow (read,search,compare) userdn="ldap:///anyone";)",
: "(targetattr="userPassword||authPassword")(version 3.0; acl "Self
: entry read"; allow (read,search,compare) userdn="ldap:///self";)",
: (targetcontrol="1.3.6.1.1.12 || 1.3.6.1.1.13.1 || 1.3.6.1.1.13.2
: || 1.2.840.113556.1.4.319 || 1.2.826.0.1.3344810.2.3 ||
: 2.16.840.1.113730.3.4.18 || 2.16.840.1.113730.3.4.9 ||
: 1.2.840.113556.1.4.473 || 1.3.6.1.4.1.42.2.27.9.5.9") (version
: 3.0; acl "Authenticated users control access"; allow(read)
: userdn="ldap:///all";), (targetcontrol="2.16.840.1.113730.3.4.2 ||
: 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 ||
: 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 ||
: 2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31") (version
: 3.0; acl "Anonymous control access"; allow(read)
: userdn="ldap:///anyone";)
The easiest way to delete a global ACI is to use dsconfig in interactive mode. Interactive mode walks you through the ACI configuration, and is therefore not documented here. If you delete global ACIs in non-interactive mode, then ensure that you escape all special characters in the ACI specification as required by your command line shell.
This example deletes the global ACI by using dsconfig in non-interactive mode.
Run the dsconfig command as follows:
$ dsconfig -h localhost -p 4444 -D "cn="Directory manager" -j /tmp/passwd.txt -X -n \ set-access-control-handler-prop \ --remove global-aci: "(targetattr="createTimestamp||creatorsName||modifiersName||modifyTimestamp||entryDN||entryUUID||subschemaSubentry") \ (version 3.0;acl "User-Visible Operational Attributes"; allow (read,search,compare) \ userdn=\"ldap:///anyone\";)"
When you add a global ACI, ensure that you escape all special characters in the ACI specification as required by your command-line shell.
The following example adds the global ACI that was removed in the previous procedure, using dsconfig in non-interactive mode:
Run the dsconfig command as follows.
$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j /tmp/passwd.txt -X -n \ set-access-control-handler-prop \ --add global-aci:"(targetattr="*")(version 3.0; acl "Self entry modification"; allow (write) \ userdn=\"ldap:///self\";)"
ldapmodifyYou can create access control instructions (ACIs) manually using LDIF statements, and add them to your directory by using the ldapmodify command. Because ACI values can be very complex, it is useful to view existing values and copy them to help create new ones.
For additional sample ACIs to the ones illustrated here, see Section 28.5, "Access Control Usage Examples."
ACIs are stored as one or more values of the aci attribute on an entry. The aci attribute is a multivalued operational attribute that can be read and modified by directory users, and should itself be protected by ACIs.
Administrative users are usually given full access to the aci attribute.
View the values of the aci attribute by running the following ldapsearch command:
$ ldapsearch -h host -p port -D "cn=Directory Manager" -j pwd-file \ -b entryDN -s base "(objectclass=*)" aci
The result is LDIF text that you can copy into a new LDIF ACI definition for editing. Because the value of an ACI is a long string, the output from the ldapsearch operation is likely to be displayed over several lines, with the first space being a continuation marker. Take this into account when copying and pasting the LDIF output.
To view the effect of an ACI value, in terms of the permissions that it grants or denies, see Section 28.7, "Viewing Effective Rights."
You can add an ACI by specifying the ACI in an LDIF file and then applying the LDIF file with the ldapmodify command. The LDIF file must contain one or more aci attributes, each of which is composed of the aci: prefix followed by the ACI specification. For more information, see Section 9.2, "ACI Syntax."
Create the ACI in an LDIF file.
The following sample LDIF file (aci.ldif) adds an ACI that grants a particular user (csmith) full access rights to the directory:
dn: ou=people,dc=example,dc=com changetype: modify add: aci aci: (targetattr="*")(version 3.0; acl "give csmith full rights"; allow(all) userdn = "ldap:///uid=csmith,ou=People,dc=example,dc=com";)
Use the ldapmodify command to apply the ACI to the directory.
The following command applies the ACI contained in the aci.ldif file to the directory:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --filename aci.ldif Processing MODIFY request for ou=people,dc=example,dc=com MODIFY operation successful for DN ou=people,dc=example,dc=com
You can remove an ACI by specifying its value in an LDIF file, and then removing the value with the ldapmodify command.
Remove the ACI in an LDIF file.
The following sample LDIF file (remove-aci.ldif) removes the ACI that was added in the previous procedure:
dn: ou=people,dc=example,dc=com changetype: modify delete: aci aci: (targetattr="*")(version 3.0; acl "give csmith full rights"; allow(all) userdn = "ldap:///uid=csmith,ou=People,dc=example,dc=com";)
Use the ldapmodify command to apply the change to the directory.
The following command applies the changes contained in the remove-aci.ldif file to the directory:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --filename remove-aci.ldif Processing MODIFY request for ou=people,dc=example,dc=com MODIFY operation successful for DN ou=people,dc=example,dc=com
You can use ODSM to view the existing ACIs that are configured in the server, to create new access control points, and to create new ACIs in a user-friendly interface. The following topics described how to manage access control by using ODSM.
Oracle Unified Directory supports several preconfigured ACIs, by default. You can display all ACIs that are configured in the server by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
Expand the Directory ACLs element.
All configured ACIs are listed under the access control point in which the ACI is defined. Expand the access control point to view the ACIs. For example, to display the list of ACIs that apply to the Root entry, expand the Root entry.
Select an ACI to view its properties in the right hand pane.
An access control point is the entry in which an ACI is defined (in other words, the entry that contains the corresponding aci attribute.
You can define a new access control point by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
Expand the Directory ACLs element.
Click the Create icon.
In the Location field, enter the DN of the entry that will be the new access control point, or click Select to select the entry from the directory.
To add one or more ACIs to the access control point, click Create ACI.
Enter the ACI details. For more information about these fields, see Section 28.3.5, "Adding an ACI."
When you have added the required ACIs to the access control point, click Create.
You can define a new access control point that is based on an existing access control point by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
Expand the Directory ACLs element.
Select the access control point on which you want to base the new access control point.
Click the Create like icon.
In the Location field, enter the DN of the entry that will be the new access control point, or click Select to select the entry from the directory.
The new access control point is automatically created with the same ACL as the access control point on which it was based.
To add, remove, or edit the existing ACIs on the new access control point, click Create, Edit or Delete.
To add or edit an ACI, enter the required details. For more information about these fields, see Section 28.3.5, "Adding an ACI."
When you have modified the ACIs for the new access control point, click Create.
You can delete an access control point by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
Expand the Directory ACLs element.
Select the access control point that you want to delete and click the Delete icon.
Click OK to confirm the deletion.
You can add an ACI to an existing access control point, by using ODSM as follows:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
Expand the Directory ACLs element.
Expand the access control point to which you want to add the new ACI.
Select one of the ACIs in the access control list.
Click the Add icon.
To build the ACI in a user friendly interface, select the Detail View tab.
Select the Scope of the ACI.
Usually an ACI has subtree scope. You can restrict the scope of the ACI by selecting one of the following values:
Base. The ACI applies to the target resource only.
One. The ACI applies to the target resource's first-generation children.
Subtree. The ACI applies to the target resource and the subtree below it.
Subordinate. The ACI applies only to the subtree below the target resource.
In the Targets field, select each element of the ACI and click Edit to define its properties.
For more information about defining ACI targets, see Section 9.2.2, "Defining Targets."
You can now target one or more attributes that occur in the targeted entries to deny or allow access to partial information about an entry, by performing the following steps:
In the Targets field, select Target Attribute and click Edit.
Enter the following details:
For Operator, select the desired value.For Attributes, select the desired option.
Click Add to enter the one or more ACI Attributes and subtypes. You can also click Search to search for the attribute name.
You can enter subtypes for the attributes in the sub-type (optional) field. You can enter multiple subtypes for same attribute.
Click OK.
For more information, see Section 9.2.2.2, "Targeting Attributes."
In the Permissions field, click the Add icon to define permissions and bind rules.
For more information about defining ACI permissions, see Section 9.2.3, "Defining Permissions."
For more information about defining bind rules, see Section 9.3, "Bind Rules."
Perform the following steps to define the bind rules:
From Bind Rule Type list, select the desired bind rule.
Click the User Attribute tab to create user attribute bind rule.
Perform the following steps:
For User Attribute Operator property, select the desired value.
For Entry Selection property, select Target Entry and its Subtree.
From the Inheritance Levels list, select the desired inheritance level value.
In the User Attribute field, enter an attribute or alternatively click Select to search an entry.
For User Attribute Type property, click Bind Type Format.
From the Bind Type Value list, select the bind type value.
Click OK.
If you would rather define the ACI manually, click the Text Editor View tab and enter the details of the ACI.
Click Validate to check that the ACI conforms to the ACI syntax.
You can also use this view to copy and paste existing ACIs.
When you have completed the ACI definition, click Create.
You can add an ACI that is based on an existing ACI, by using ODSM as follows:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
Expand the Directory ACLs element.
Expand the access control point that contains the ACI that you want to copy.
Select the ACI that you want to copy.
Click the Add like icon.
Edit the elements of the ACI that you want to change, either in Text Editor View or in Detail View.
When you have completed the ACI definition, click Create.
You can modify an existing ACI, by using ODSM as follows:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
Expand the Directory ACLs element.
Expand the access control point that contains the ACI that you want to change
Select the ACI that you want to change.
Edit the elements of the ACI, either in Text Editor View or in Detail View.
When you have completed your changes, click Apply.
You can use ODSM to enter macro expressions in target, targetFilter, userDn, groupDN, and userAttr attributes. For more information about Macro ACIs, see Section 9.6, "Using Macro ACIs for Advanced Access Control."
This section contains the following topics:
This section describes how to enter a macro ACI in the target.
To edit a target to enter a macro ACI:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
From the Directory ACLs list, select the ACI that you want to edit.
From the Targets table, select the Target row.
Click Edit.
In the Target field, enter the macro expression.
Click OK.
This section describes how to enter a macro ACI in the target filter.
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
From the Directory ACLs list, select the ACI that you want to edit.
From the Targets table, select the Target Filter row.
Click Edit.
In the Target field, enter the filter with the macro expression.
Click OK.
This section describes how to define access for a targeted resource to specific user or a specific group.
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
From the Directory ACLs list, select the ACI that you want to edit.
From the Permissions table, select the Bind Rules row.
Click Edit.
From Bind Rule Type list, select the desired bind rule.
On the Access To tab, from the User DN list, select Specify Users.
Perform the following steps in the User table:
Click Add.
Enter the macro expression to define user access or alternatively click Select to search the entry and add the macro expression in the selected entry.
Perform the following steps to specify access to a specific group for a targeted resource in the Group DN Operator table:
Click Add.
Enter the macro expression to define group access or alternatively click Select to search the entry and add the macro expression in the selected entry.
Click OK.
Note:
You can edit an individual bind rule as well. You must select the required bind rule in the Permissions table, and then click Edit for modifying the bind rule.The section describes how to edit bind rules for a user attribute.
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Security tab.
From the Directory ACLs list, select the ACI that you want to edit.
From the Permissions table, select the Bind Rules row.
Click Edit.
Click the User Attribute tab.
From Bind Rule Type list, select the desired bind rule.
For Entry Selection property, select Specific Entry.
In the Entry Base DN field, enter the base DN or alternatively click Select to search an entry and add the macro expression in the selected entry.
In the User Attribute field, enter an attribute name or alternatively click Select to search an attribute name from the list of attribute names.
Click Bind Type Format.
From the Bind Type Value list, select the desired value.
Click OK.
Note:
You can edit an individual bind rule as well. You must select the required bind rule in the Permissions table, and then click Edit for modifying the bind rule.This section provides several sample ACIs that can be used to implement an access control policy.
Let us assume that a customer had granted an anonymous ACI for all user attributes except for the userpassword and authPassword attributes previously.
This example deletes that same global ACI by using dsconfig in non-interactive mode.
Run the dsconfig command as follows:
$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j /tmp/passwd.txt -X -n \ set-access-control-handler-prop \ --remove global-aci:"(targetattr!=\"userPassword||authPassword\") \ (version 3.0; acl \"Anonymous read access\"; allow (read,search,compare) \ userdn=\"ldap:///anyone\";)"
The default global ACIs allow write access to a limited subset of the attributes of a user's own entry. These attributes include the following:
audio
authPassword
description
displayName
givenName
homePhone
homePostalAddress
initials
jpegPhoto
labeledURI
mobile
pager
postalAddress
postalCode
preferredLanguage
telephoneNumber
userPassword
Use this procedures in this section to grant users write access to additional attributes of their own entries.
The following example ACI enables users internal to example.com to change their own business category and room number.
Remember, by allowing write access, you also grant users the right to delete attribute values.
aci: (targetattr="businessCategory || roomNumber") (version 3.0; acl "Write example.com"; allow (write) userdn="ldap:///self" and dns="*.example.com";)
This example assumes that the ACI is added to the ou=People,dc=example,dc=com entry.
The following example enables users to update all of their own personal information in the example.com tree if they establish an SSL connection to the directory.
By setting this permission, you are also granting users the right to delete attribute values.
aci: (targetattr="*") (version 3.0; acl "Write SSL"; allow (write) userdn= "ldap:///self" and authmethod="ssl";)
This example assumes that the aci is added to the ou=subscribers,dc=example,dc=com entry.
Most directories have a group that is used to identify certain corporate functions. These groups can be given full access to all or part of the directory. By applying the access rights to the group, you can avoid setting the access rights for each member individually. Instead, you grant users these access rights by adding them to the group.
The following sample ACI allows a group named the HRgroup full access to the ou=People branch of the directory so that they can update employee information:
aci: (targetattr="*") (version 3.0; acl "HR"; allow (all) groupdn= "ldap:///cn=HRgroup,ou=People,dc=example,dc=com";)
This example assumes that the ACI is added to the ou=People,dc=example,dc=com entry.
Some organizations want to allow employees to create entries in the tree if it can increase their efficiency, or if it can contribute to the corporate dynamics. The following examples assume that example.com has a social committee that is organized into various clubs (tennis, swimming, skiing, and so on).
"Create Group" ACIThis sample ACI allows any example.com employee to create a group entry representing a new club, under the ou=social committee branch.
aci: (target = "ldap:///dc=ou=social committee,dc=example,dc=com") (targetfilter="(|(objectClass=groupOfNames)(objectClass=top))") (version 3.0; acl"Create Group"; allow (search,read,add) (userdn = @ "ldap:///uid=*,ou=People,dc=example,dc=com" and dns = "*.example.com");)
This example assumes that the ACI is added to the ou=social committee, dc=example,dc=com entry.
Note:
This ACI does not grant write permission, which means that the entry creator cannot modify the entry. Because the server adds the valuetop behind the scenes, you must specify objectClass=top in the targattrfilters."Delete Group" ACIThis sample ACI ensures that only the group owner can modify or delete a group entry under the ou=Social Committee branch.
aci: (target="ou=social committee,dc=example,dc=com") (targetattr = "*") (targattrfilters="del=objectClass:(objectClass=groupOfNames)") (version 3.0; acl "Delete Group"; allow (write,delete) userattr="owner#GROUPDN";)
This example assumes that the ACI is added to the ou=social committee,dc=example,dc=com entry.
Many directories set ACIs that allow users to add or remove themselves from groups. This is useful, for example, for allowing users to add and remove themselves from mailing lists. The following sample ACI enables all employees to add themselves to any group entry under the ou=social committee subtree:
aci: (targettattr="member")(version 3.0; acl "Group Members"; allow (selfwrite) (userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") ;)
This example assumes that the ACI is added to the ou=social committee, dc=example,dc=com entry.
Usually, when you grant a group privileged access to the directory, you want to ensure that those privileges are protected from intruders trying to impersonate the privileged users. Therefore, access control rules that grant critical access to a group or role are often associated with several conditions.
The following sample ACI grants the Directory Administrators group full access to the corporate clients branch of the directory tree, provided the following conditions are fulfilled:
The connection is authenticated using a certificate over SSL
Access is requested between 08:00 and 18:00, Monday through Thursday
Access is requested from a specified IP address
aci: (target="ou=corporate-clients,dc=example,dc=com") (targetattr = "*") (version 3.0; acl "corporate-clients"; allow (all) (groupdn="ldap:///cn=DirectoryAdmin,ou=corporate-clients,dc=example,dc=com") and (authmethod="ssl") and (dayofweek="Mon,Tue,Wed,Thu") and (timeofday >= "0800" and timeofday <= "1800") and (ip="255.255.123.234"); )
This example assumes that the ACI is added to the ou=corporate-clients,dc=example,dc=com entry.
If your directory holds business-critical information, you might specifically want to deny access to it. The following sample ACIs allow users to read certain "billing information", such as connection time and account balance, under their own entries, but prohibits them from changing this information.
This ACI allows users to read the information. The example assumes that the relevant attributes have been created in the schema.
aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Read"; allow (search,read) userdn="ldap:///self";)
This ACI prevents users from changing the information. The example assumes that the relevant attributes have been created in the schema.
aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Deny"; deny (write) userdn="ldap:///self";)
DNs that contain commas require special treatment within LDIF ACI statements. In the target and bind rule portions of the ACI statement, commas must be escaped by a single backslash (\). The following example illustrates this syntax:
dn: o=example.com Bolivia\, S.A. objectClass: top objectClass: organization aci: (target="ldap:///o=example.com Bolivia\,S.A.") (targetattr="*") (version 3.0; acl "aci 2"; allow (all) groupdn = "ldap:///cn=Directory Administrators, o=example.com Bolivia\, S.A.";)
The proxy authorization method is a special form of authentication: a user that binds to the directory using his own identity is granted the rights of another user, through proxy authorization.
This example makes the following assumptions:
The client application's bind DN is uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com.
The targeted subtree to which the client application is requesting access is ou=Accounting,dc=example,dc=com.
An Accounting Administrator with access permissions to the ou=Accounting,dc=example,dc=com subtree exists in the directory.
For the client application to gain access to the Accounting subtree (using the same access permissions as the Accounting Administrator), the application requires the following rights and controls:
The Accounting Administrator must have access permissions to the ou=Accounting,dc=example,dc=com subtree. The following ACI grants all rights to the Accounting Administrator entry:
aci: (target="ldap:///ou=Accounting,dc=example,dc=com") (targetattr="*") (version 3.0; acl "allow All-AcctAdmin"; allow (all) userdn="ldap:///uid=AcctAdministrator,ou=Administrators, dc=example,dc=com";)
The client application must have proxy rights. The following ACI grants proxy rights to the client application:
aci: (target="ldap:///ou=Accounting,dc=example,dc=com") (targetattr="*") (version 3.0; acl "allow proxy- accounting software"; allow (proxy) userdn= "ldap:///uid=MoneyWizAcctSoftware,ou=Applications, dc=example,dc=com";)
The client application must be allowed to use the proxy authorization control. The following ACI allows the client application to use the proxy authorization control:
aci: (targetcontrol = "2.16.840.1.113730.3.4.18") (version 3.0; acl "allow proxy auth - accounting software"; allow (all) userdn="ldap:///uid=MoneyWizAcctSoftware,ou=Applications, dc=example,dc=com";)
With these ACIs in place, the MoneyWizAcctSoftware client application can bind to the directory and send an LDAP command such as ldapsearch or ldapmodify that requires the access rights of the proxy DN.
In the previous example, if the client wanted to perform an ldapsearch command, the command would include the following controls:
$ ldapsearch -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" \ -j pwd-file -Y "dn:uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" \ -b "ou=Accounting,dc=example,dc=com" "objectclass=*"\ ...
The base of the search must match the target of the ACIs. The client binds as itself but is granted the privileges of the proxy entry. The client does not need the password of the proxy entry.
For more information, see Section 18.5.3.13, "Searching Using the Proxied Authorization Control."
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 (http://tools.ietf.org/html/draft-ietf-ldapext-acl-model-08) 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:
TheaclRights 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. The directory server generates these attributes in response to the Get Effective Rights Control. For this reason, do not use either of these attributes 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" -j pwd-file \ -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" \ -j pwd-file -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" \
-j pwd-file -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).
| Entry-level Permission | Explanation |
|---|---|
add and delete |
The ability of a user to add and delete the entire entry. |
read |
The ability of a user to read and search attributes in the entry. |
write |
The ability of a user to add, delete, and replace attribute values in the entry. |
proxy |
The ability of a user to access the directory with the rights of the entry. |
Note:
For information about assigning these permissions in an ACI, see Section 9.2, "ACI Syntax."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.
| Attribute-level Permission | Explanation |
|---|---|
read |
The ability of a user to read the attribute value in the entry. |
search |
The ability of a user to search the attribute value in the entry. |
compare |
The ability of a user to compare the attribute value in the entry with a value that is provided by the user. |
write |
The ability of a user to add, delete, and replace the attribute value in the entry. This applies to all attributes except the authorization dn. |
selfwrite_add |
The ability of a user to add the attribute, authorization dn. |
selfwrite_delete |
The ability of a user to delete the attribute, authorization dn. |
proxy |
The ability of a user to access the directory with the rights of the attribute in the entry. |
Note:
Thewrite, 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 28-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.
write, selfwrite_add, and selfwrite_delete PermissionsThe 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 28-1 Effective Rights Permission Interdependencies
| write | selfwrite_add | selfwrite_delete | Effective Rights Explanation |
|---|---|---|---|
|
|
|
|
Cannot add or delete any values of this attribute. |
|
|
|
|
Can only delete the value of the |
|
|
|
|
Can only add the value of the |
|
|
|
|
Can only add or delete the value of the |
|
|
|
|
Can add or delete all values except the |
|
|
|
|
Can delete all values including the |
|
|
|
|
Can add all values including the |
|
|
|
|
Can add or delete all values of this attribute. |
|
|
|
|
Cannot add or delete the |
|
|
|
|
Can delete but cannot add the value of the |
|
|
|
|
Can add but cannot delete the value of the |
|
|
|
|
Can add and delete the value of the |
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 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 28-2 Effective Rights Logging Information Reasons and Their Explanations
| Logging Information Reason | Explanation |
|---|---|
|
|
No reason available to explain why access was allowed or denied. |
|
|
No |
|
|
Cached information was used to determine the access denied decision. |
|
|
Cached information was used to determine the access allowed decision. |
|
|
An ACI was evaluated to determine the access allowed decision. The name of the ACI is included in the log information. |
|
|
An ACI was evaluated to determine the access denied decision. The name of the ACI is included in the log information. |
|
|
No ACIs match the resource or target, which results in denied access. |
|
|
No ACIs match the subject requesting access control, which results in denied access. |
|
|
An ACI with a |
|
|
No ACI with a |
|
|
The user is root DN and is allowed access. |
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 Section 9.2.2, "Defining Targets."
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";)