Skip Navigation Links | |
Exit Print View | |
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1) |
1. Starting and Stopping the Server
2. Configuring the Server Instance
3. Configuring the Proxy Components
4. Configuring Security Between Clients and Servers
5. Configuring Security Between the Proxy and the Data Source
6. Managing Oracle Unified Directory With Oracle Directory Services Manager
Managing Global ACIs With dsconfig
Managing Access Control With Oracle Directory Services Manager
Create an Access Control Point
Create an Access Control Point Based on an Existing Access Control Point
Delete an Access Control Point
Add an ACI Based on an Existing ACI
Granting Write Access to Personal Entries
Granting Write Access Based on DNS
Granting Write Access Based on Authentication Method
Granting a Group Full Access to a Suffix
Granting Rights to Add and Delete Group Entries
Allowing Users to Add or Remove Themselves From a Group
The Get Effective Rights Control
Using the Get Effective Rights Control
Understanding Effective Rights Results
write, selfwrite_add, and selfwrite_delete Permissions
Restricting Access to the Get Effective Rights Control
10. Managing Users and Groups With dsconfig
11. Managing Password Policies
This section provides several sample ACIs that can be used to implement an access control policy.
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" -w password -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";)'
Note - Depending on your shell, you might need to escape any quotations in the ACI itself.
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 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.
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).
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:///ou=social committee,dc=example,dc=com") (targetattr="*")(targattrfilters="add=objectClass: (|(objectClass=groupOfNames)(objectClass=top))") (version 3.0; acl "Create Group"; allow (read,search,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.
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.
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.
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,Tues,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.";)