Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Unified Directory
11g Release 2 (11.1.2)

Part Number E22648-05
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

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

22 Controlling Access To 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.

For an overview of the ACI model, see Chapter 8, "Understanding the Oracle Unified Directory Access Control Model".

The following sections describe how to create ACIs to control access to data:

22.1 Managing Global ACIs With dsconfig

Global 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 14.1, "Managing the Server Configuration With dsconfig".

You cannot use dsconfig to manage ACIs that are applied to entries in sub-trees. To manage non-global ACIs, see Section 22.2, "Managing ACIs With ldapmodify".

22.1.1 Default Global ACIs

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.

22.1.2 To Display the Global 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 (output reformatted for readability).

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -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||supportedExtension||
           :   supportedFeatures||supportedLDAPVersion||supportedSASLMechanisms||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="objectClass||
           :   attributeTypes||dITContentRules||dITStructureRules||ldapSyntaxes||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="*")(version3.0; acl 
           :   "Replication backend access"; deny (all) userdn="ldap:///anyone";),
           : (targetattr="audio||authPassword||description||displayName||givenName||homePhone||
           :   homePostalAddress||initials||jpegPhoto||labeledURI||mobile||pager||postalAddress||
           :   postalCode||preferredLanguage||telephoneNumber||userPassword")(version 3.0; acl 
           :   "Self entry modification"; allow (write) userdn="ldap:///self";),
           : "(targetattr="createTimestamp||creatorsName||modifiersName||modifyTimestamp||entryDN||
           :   entryUUID||subschemaSubentry||orclguid")(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";)

22.1.3 To Delete a Global ACI

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, make sure that you escape all special characters in the ACI specification as required by your command line shell.

This example deletes the global ACI that allows anonymous access by using dsconfig in non-interactive mode.

Run the dsconfig command as follows.

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -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\"\;\)

22.1.4 To Add a Global ACI

When you add a global ACI, make sure 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 pwd-file -n \
  set-access-control-handler-prop \
  --add global-aci:\(targetattr!=\"userPassword\|\|authPassword\"\) \
  \(version\ 3.0\;\ acl\ \"Anonymous\ read\ access\"\;\ allow\ \(read,search,compare\)
  \ userdn=\"ldap:///anyone\"\;\)

22.2 Managing ACIs With ldapmodify

You 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 22.5, "Access Control Usage Examples".

22.2.1 To View ACI Attribute Values

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 22.7, "Viewing Effective Rights".

22.2.2 To Add an ACI

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 8.2, "ACI Syntax".

  1. 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";)
    
  2. 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
    

22.2.3 To Remove an ACI

You can remove an ACI by specifying its value in an LDIF file, and then removing the value with the ldapmodify command.

  1. 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";)
    
  2. 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
    

22.3 Managing Access Control With Oracle Directory Services Manager

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.

22.3.1 Display the Configured ACIs

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:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".

  2. Select the Security tab.

  3. Expand the Directory ACLs element.

  4. 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.

  5. Select an ACI to view its properties in the right hand pane.

22.3.2 Create an Access Control Point

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:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".

  2. Select the Security tab.

  3. Expand the Directory ACLs element.

  4. Click the Create icon.

  5. 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.

  6. To add one or more ACIs to the access control point, click Create ACI.

  7. Enter the ACI details. For more information about these fields, see Add an ACI.

  8. When you have added the required ACIs to the access control point, click Create.

22.3.3 Create an Access Control Point Based on an Existing Access Control Point

You can define a new access control point that is based on an existing access control point by using ODSM, as follows:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".

  2. Select the Security tab.

  3. Expand the Directory ACLs element.

  4. Select the access control point on which you want to base the new access control point.

  5. Click the Create like icon.

  6. 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.

  7. The new access control point is automatically created with the same ACL as the access control point on which it was based.

  8. To add, remove, or edit the existing ACIs on the new access control point, click Create, Edit or Delete.

  9. To add or edit an ACI, enter the required details. For more information about these fields, see Section 22.3.5, "Add an ACI".

  10. When you have modified the ACIs for the new access control point, click Create.

22.3.4 Delete an Access Control Point

You can delete an access control point by using ODSM, as follows:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".

  2. Select the Security tab.

  3. Expand the Directory ACLs element.

  4. Select the access control point that you want to delete and click the Delete icon.

  5. Click OK to confirm the deletion.

22.3.5 Add an ACI

You can add an ACI to an existing access control point, by using ODSM as follows:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".

  2. Select the Security tab.

  3. Expand the Directory ACLs element.

  4. Expand the access control point to which you want to add the new ACI.

  5. Select one of the ACIs in the access control list.

  6. Click the Add icon.

  7. To build the ACI in a user friendly interface, select the Detail View tab.

  8. 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.

  9. 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 8.2.2, "Defining Targets".

  10. In the Permissions field, click the Add icon to define permissions and bind rules.

    For more information about defining ACI permissions, see Section 8.2.3, "Defining Permissions".

    For more information about defining bind rules, see Section 8.3, "Bind Rules."

    Perform the following steps to define the bind rules:

    1. From Bind Rule Type list, select the desired bind rule.

    2. 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.

  11. 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.

  12. When you have completed the ACI definition, click Create.

22.3.6 Add an ACI Based on an Existing ACI

You can add an ACI that is based on an existing ACI, by using ODSM as follows:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".

  2. Select the Security tab.

  3. Expand the Directory ACLs element.

  4. Expand the access control point that contains the ACI that you want to copy.

  5. Select the ACI that you want to copy.

  6. Click the Add like icon.

  7. Edit the elements of the ACI that you want to change, either in Text Editor View or in Detail View.

  8. When you have completed the ACI definition, click Create.

22.3.7 Modify an ACI

You can modify an existing ACI, by using ODSM as follows:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".

  2. Select the Security tab.

  3. Expand the Directory ACLs element.

  4. Expand the access control point that contains the ACI that you want to change

  5. Select the ACI that you want to change.

  6. Edit the elements of the ACI, either in Text Editor View or in Detail View.

  7. When you have completed your changes, click Apply.

22.4 Managing Macro ACIs With Oracle Directory Services Manager

You can use ODSM to enter macro expressions in target, targetFilter, userDn, groupDN, and userAttr attributes. For more information about Macro ACIs, see Section 8.6, "Using Macro ACIs for Advanced Access Control."

This section contains the following topics:

22.4.1 Editing a Target

This section describes how to enter a macro ACI in the target.

To edit a target to enter a macro ACI:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."

  2. Select the Security tab.

  3. From the Directory ACLs list, select the ACI that you want to edit.

  4. From the Targets table, select the Target row.

  5. Click Edit.

  6. In the Target field, enter the macro expression.

  7. Click OK.

22.4.2 Editing a Target Filter

This section describes how to enter a macro ACI in the target filter.

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."

  2. Select the Security tab.

  3. From the Directory ACLs list, select the ACI that you want to edit.

  4. From the Targets table, select the Target Filter row.

  5. Click Edit.

  6. In the Target field, enter the filter with the macro expression.

  7. Click OK.

22.4.3 Editing Bind Rules for User DN or Group DN

This section describes how to define access for a targeted resource to specific user or a specific group.

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."

  2. Select the Security tab.

  3. From the Directory ACLs list, select the ACI that you want to edit.

  4. From the Permissions table, select the Bind Rules row.

  5. Click Edit.

  6. From Bind Rule Type list, select the desired bind rule.

  7. On the Access To tab, from the User DN list, select Specify Users.

  8. Perform the following steps in the User table:

    1. Click Add.

    2. 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.

  9. Perform the following steps to specify access to a specific group for a targeted resource in the Group DN Operator table:

    1. Click Add.

    2. 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.

  10. Click OK.

Note:

You can edit an individual bind rule as well. You need to select the required bind rule in the Permissions table, and then click Edit for modifying the bind rule.

22.4.4 Editing Bind Rules for User Attributes

The section describes how to edit bind rules for a user attribute.

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."

  2. Select the Security tab.

  3. From the Directory ACLs list, select the ACI that you want to edit.

  4. From the Permissions table, select the Bind Rules row.

  5. Click Edit.

  6. Click the User Attribute tab.

  7. From Bind Rule Type list, select the desired bind rule.

  8. For Entry Selection property, select Specific Entry.

  9. 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.

  10. In the User Attribute field, enter an attribute name or alternatively click Select to search an attribute name from the list of attribute names.

  11. Click Bind Type Format.

  12. From the Bind Type Value list, select the desired value.

  13. Click OK.

Note:

You can edit an individual bind rule as well. You need to select the required bind rule in the Permissions table, and then click Edit for modifying the bind rule.

22.5 Access Control Usage Examples

This section provides several sample ACIs that can be used to implement an access control policy.

22.5.1 Disabling Anonymous Access

The directory server allows anonymous access by default. There might be situations in which you want to disable anonymous access, particularly to sensitive data within your directory.

The following default ACI allows anonymous read access to all user attributes except for the userpassword and authPassword attributes:

aci: (targetattr!="userPassword||authPassword")(version 3.0; acl "
Anonymous read access"; allow (read,search,compare) userdn="ldap:///anyone";)

To disable anonymous access, remove this ACI from the default access control handler, as shown in the following example:

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -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";)'

Depending on your shell, you might need to escape any quotations in the ACI itself.

22.5.2 Granting Write Access to Personal Entries

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.

22.5.2.1 Granting Write Access Based on DNS

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.

22.5.2.2 Granting Write Access Based on Authentication Method

The following example enables any user to update all of his own personal information in the example.com tree provided that he 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.

22.5.3 Granting a Group Full Access to a Suffix

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.

22.5.4 Granting Rights to Add and Delete Group Entries

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).

22.5.4.1 Creating a "Create Group" ACI

This 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 value top behind the scenes, you must specify objectClass=top in the targattrfilters.

22.5.4.2 Creating a "Delete Group" ACI

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

22.5.5 Allowing Users to Add or Remove Themselves From a Group

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.

22.5.6 Granting Conditional Access to a Group

In many cases, 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, in many cases, access control rules that grant critical access to a group or role are often associated with a number of 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.

22.5.7 Denying Access

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";)

22.5.8 Defining Permissions for DNs That Contain a Comma

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.";)

22.6 Proxy Authorization ACIs

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:

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:

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 17.5.3.13, "Searching Using the Proxied Authorization Control".

22.7 Viewing Effective Rights

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.

22.7.1 The Get Effective Rights Control

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.

22.7.2 Using the Get Effective Rights Control

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:

  1. 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.

  2. 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" -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

22.7.3 Understanding Effective Rights Results

Depending on the options specified, an effective rights request returns the following information:

22.7.3.1 Rights 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 8.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:

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 22-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.

22.7.3.2 write, selfwrite_add, and selfwrite_delete Permissions

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 22-1 Effective Rights Permission Interdependencies

write selfwrite_add selfwrite_delete Effective Rights Explanation

0

0

0

Cannot add or delete any values of this attribute.

0

0

1

Can only delete the value of the authorization dn.

0

1

0

Can only add the value of the authorization dn.

0

1

1

Can only add or delete the value of the authorization dn.

1

0

0

Can add or delete all values except the authorization dn.

1

0

1

Can delete all values including the authorization dn and can add all values excluding the authorization dn.

1

1

0

Can add all values including the authorization dn and can delete all values excluding the authorization dn.

1

1

1

Can add or delete all values of this attribute.

?

0

0

Cannot add or delete the authorization dn value, but might be able to add or delete other values. Refer to logging information for further details regarding the write permission.

?

0

1

Can delete but cannot add the value of the authorization dn, and might be able to add or delete other values. Refer to logging information for further details regarding the write permission.

?

1

0

Can add but cannot delete the value of the authorization dn and might be able to add or delete other values. Refer to logging information for further details regarding the write permission.

1

?

1

Can add and delete the value of the authorization dn and might be able to modify add, modify, or delete other values. Refer to logging information for further details regarding the write permission.


22.7.3.3 Logging Information

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 22-2 Effective Rights Logging Information Reasons and Their Explanations

Logging Information Reason Explanation

no reason available

No reason available to explain why access was allowed or denied.

no allow acis

No allow ACIs exist, which results in denied access.

result cached deny

Cached information was used to determine the access denied decision.

result cached allow

Cached information was used to determine the access allowed decision.

evaluated allow

An ACI was evaluated to determine the access allowed decision. The name of the ACI is included in the log information.

evaluated deny

An ACI was evaluated to determine the access denied decision. The name of the ACI is included in the log information.

no acis matched the resource

No ACIs match the resource or target, which results in denied access.

no acis matched the subject

No ACIs match the subject requesting access control, which results in denied access.

allow anyone aci matched anon user

An ACI with a userdn = "ldap:///anyone" subject allowed access to the anonymous user.

no matching anyone aci for anon user

No ACI with a userdn= "ldap:///anyone" subject was found, so access for the anonymous user was denied.

user root

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.

22.7.4 Restricting Access to the Get Effective Rights Control

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 8.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";)