Red Hat DIRECTORY SERVER 8.0, Administration Manual

Page: 203 / 552

Granting Anonymous Access
185
• Grant write access to
example.com
employees for personal information, such as
homePhone
and
homePostalAddress
(
Section 6.9.2, “Granting Write Access to Personal Entries”
).
• Grant
example.com
employees the right to add any role to their entry, except certain critical roles
(
Section 6.9.3, “Restricting Access to Key Roles”
).
• Grant the
example.com Human Resources
group all rights on the entries in the
People
branch
(
Section 6.9.4, “Granting a Group Full Access to a Suffix”
).
• Grant all
example.com
employees the right to create group entries under the
Social Committee
branch of the directory and to delete group entries that they own (
Section 6.9.5, “Granting Rights to
Add and Delete Group Entries”
).
• Grant all
example.com
employees the right to add themselves to group entries under the
Social
Committee
branch of the directory (
Section 6.9.9, “Allowing Users to Add or Remove Themselves
from a Group”
).
• Grant access to the directory administrator (role) of
HostedCompany1
and
HostedCompany2
on
their respective branches of the directory tree, with certain conditions such as SSL authentication,
time and date restrictions, and specified location (
Section 6.9.6, “Granting Conditional Access to a
Group or Role”
).
• Deny individual subscribers access to the billing information in their own entries (
Section 6.9.7,
“Denying Access”
).
• Grant anonymous access to the world to the individual subscribers subtree, except for subscribers
who have specifically requested to be unlisted. (This part of the directory could be a consumer
server outside of the firewall and be updated once a day.) See
Section 6.9.1, “Granting Anonymous
Access”
and
Section 6.9.8, “Setting a Target Using Filtering”
.
6.9.1. Granting Anonymous Access
Most directories are run such that you can anonymously access at least one suffix for read, search,
or compare. For example, you might want to set these permissions if you are running a corporate
personnel directory that you want employees to be able to search, such as a phonebook. This
is the case at
example.com
internally and is illustrated in
Section 6.9.1.1, “ACI "Anonymous
example.com"”
.
As an ISP,
example.com
also wants to advertise the contact information of all of its subscribers
by creating a public phonebook accessible to the world. This is illustrated in
Section 6.9.1.2, “ACI
"Anonymous World"”
.
6.9.1.1. ACI "Anonymous example.com"
In LDIF, to grant read, search, and compare permissions to the entire
example.com
tree to
example.com
employees, write the following statement:
aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous
Example"; allow (read, search, compare) userdn= "ldap:///anyone"
and dns="*.example.com";)
This example assumes that the
aci
attribute is added to the
dc=example,dc=com
entry. The
userPassword
attribute is excluded from the scope of the ACI.
From the Console, set this permission by doing the following: