Access Control Usage Examples

The examples in this section illustrate how an imaginary ISP company,
Example.com, would implement its access control policy.

In addition, you can find ACI examples in the example LDIF file provided
with your installation, install_path/resources/ldif/Example.ldif.

All of the examples explain how to perform a given task by using an
LDIF file. The following figure shows the example.com Directory Information
Tree in graphical form.

Example.com offers a web hosting service and internet access. Part of
Example.com’s web-hosting service is to host the directories of client
companies. Example.com actually hosts and partially manages the directories
of two medium-sized companies, Company333 and Company999. Example.com also
provides internet access to a number of individual subscribers.

Grant access to the directory administrator (role) of Company333
and Company999 on their respective branches of the directory tree, with certain
conditions. These conditions include SSL authentication, time and date restrictions,
and specified location. See Granting Conditional Access to a Group or Role.

Deny individual subscribers access to the billing information
in their own entries. See Denying Access.

Grant anonymous access to the world to the individual subscribers
subtree, except for subscribers who have specifically requested to be unlisted.
If desired, this part of the directory could be a read-only server outside
of the firewall, and be updated once a day. See Granting Anonymous Access and Setting a Target Using Filtering.

Granting Anonymous Access

Most directories are configured to enable you to anonymously access
at least one suffix for read, search, or compare. You might want to set these
permissions if you are running a corporate personnel directory, such as a
phone book that you want employees to be able to search. This is the case
at Example.com internally, as shown in 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 phone book that is accessible
to the world. This is depicted in ACI “Anonymous World”.

ACI “Anonymous Example.com”

In LDIF, to grant read, search, and compare permissions to the entire
Example.com tree to Example.com employees, you would write the following statement:

This example assumes that the aci is added to the dc=example,dc=com entry. Note that the userPassword attribute
is excluded from the scope of the ACI.

Note –

Protect attributes that are confidential and attributes that should
not be visible using the same syntax used in the example to protect the password
attribute, (targetattr !="attribute-name").

ACI “Anonymous World”

In LDIF, to grant read and search access of the individual subscribers
subtree to the world, while denying access to information on subscribers who
want to be unlisted, you could write the following statement:

This example assumes that the ACI is added to the ou=subscribers,dc=example,
dc=com entry. The example also assumes that every subscriber entry
has an unlistedSubscriber attribute that is set to yes or no. The target definition filters out the
unlisted subscribers based on the value of this attribute. For details on
the filter definition, refer to Setting a Target Using Filtering.

Granting Write Access to Personal Entries

Many directory administrators want to allow internal users to change
some but not all of the attributes in their own entry. The directory administrators
at Example.com want to allow users to change their own password, home telephone
number, and home address, but nothing else. This is depicted in ACI “Write Example.com”.

Example.com also has a policy to let their subscribers update their
own personal information in the Example.com tree provided that the subscribers
establish an SSL connection to the directory. This is depicted in ACI “Write Subscribers”.

ACI “Write Example.com”

Note –

By setting this permission, you are also granting users the right
to delete attribute values.

In LDIF, to grant Example.com employees the right to update their home
telephone number and home address, you would write the following statement:

This example assumes that the aci is added to the
ou=subscribers,dc=example, dc=com entry, and that users
must bind using SSL.

Note that Example.com subscribers do not have write access to their
home address because they might delete that attribute. The home address is
business-critical information that Example.com needs for billing purposes.

Granting Access to a Certain Level

You can set the scope of an ACI to affect different levels within your
directory tree, to fine-tune the level of access you want to allow. The target
ACI scope can be set to one of the following:

base

The entry itself

onelevel

The entry itself and all entries one level below

subtree

The entry itself and all entries beneath that entry, to an
unlimited depth

ACI “Read Example.com only”

In LDIF, to grant Example.com subscribers the right to read the entry dc=example,dc=com for company contact information, but not allow
access to any entries below it, you would write the following statement:

This example assumes that the ACI is added to the dc=example,
dc=com entry.

Restricting Access to Key Roles

You can use role definitions in the directory to identify functions
that are critical to your business, such as the administration of your network
and directory.

For example, you might create a superAdmin role by
identifying a subset of your system administrators who are available at a
particular time of day and day of the week at corporate sites worldwide. Or
you might want to create a First Aid role that includes
all staff members who have first aid training at a particular site. For information
about creating role definitions see Managing Roles.

When a role gives any sort of privileged user rights over critical corporate
or business functions, consider restricting access to that role. For example,
at Example.com, employees can add any role to their own entry, except the
superAdmin role, as shown in the following example.

ACI “Roles”

In LDIF, to grant Example.com employees the right to add any role to
their own entry, except the superAdmin role, you would
write the following statement:

This example assumes that the ACI is added to the ou=People,dc=example,
dc=com entry.

Granting a Role Full Access to an Entire Suffix

Sometimes it is useful to grant certain users the same rights as the
Directory Manager for a suffix. At Example.com, Kirsten Vaughan is an administrator
for Directory Server. She has a role of superAdmin.
This role has the following advantages:

Better security because administrators binding as themselves
can be forced to use strong authentication such as SSL

Better security because the Directory Manager password is
known by fewer people

More traceability through logging

Note –

Adding Kirsten Vaughan to the cn=Administrators,cn=config group
would also grant her the same rights as Directory Manager.

This example assumes that the ACI is added to the root entry "" (no
text).

Granting a Group Full Access to a Suffix

Most directories have groups that are used to identify certain corporate
functions. A group can be given access to all or part of the directory. By
applying access rights to a group, you can avoid setting access rights for
each member individually. Instead, you grant users access rights by adding
them to a group.

For example, when you create a Directory Server instance, an Administrators
group cn=Administrators,cn=config with full access to the
directory is created by default.

At Example.com, the Human Resources group is allowed full access to
the ou=People branch of the directory so that they can
update the employee directory, as shown in ACI “HR”.

ACI “HR”

In LDIF, to grant the HR group all rights to the employee branch of
the directory, you would use the following statement:

Granting Rights to Add and Delete Group Entries

Some organizations allow employees to create entries in the tree to
increase employees' efficiency and to encourage employees to contribute to
the corporate dynamics. At Example.com, for example, the social committee
is organized into various clubs, such as tennis, swimming, skiing, and role-playing.

Any Example.com employee can create a group entry that represents a
new club, as shown in ACI “Create Group”.

This example assumes that the ACI is added to the ou=Social
Committee, dc=example,dc=com entry.

Granting Conditional Access to a Group or Role

In many cases, when you grant a group or role privileged access to the
directory, you must ensure that those privileges are protected from intruders
trying to impersonate your 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.

Example.com, for example, has created a Directory Administrator role
for each of its hosted companies, Company333 and Company999. Example.com wants
these companies to be able to manage their own data and implement their own
access control rules while securing the data against intruders.

For this reason, Company333 and Company999 have full rights on their
respective branches of the directory tree, provided that the following conditions
are fulfilled:

The connection is authenticated using a certificate over SSL.

Access is requested between 8:00 and 18:00, Monday through
Thursday.

Access is requested from a specified IP address for each company.

These conditions are depicted in one ACI for each company, ACI “Company333”
and ACI “Company999”. Because the content of both ACIs is the
same, the following examples use the “Company333” ACI only.

ACI “Company333”

In LDIF, to grant Company333 full access to its own branch of the directory
under the conditions stated previously, you would write the following statement:

This example assumes that the ACI is added to the ou=Company333,ou=corporate
clients,dc=example,dc=com entry.

Denying Access

If you have already allowed access to a large part of your suffix, you
might want to deny access to a smaller part of the suffix beneath the existing
ACI.

Note –

Denying access should be avoided where possible, because it can
lead to surprising or complicated access control behavior. Restrict access
by using a combination of scoping, attribute lists, target filters and so
on.

Also, deleting a deny access ACI does not remove rights, but
instead expands the rights set by other ACIs.

In the examples that follow, Example.com wants all subscribers to be
able to read billing information, such as connection time or account balance,
under their own entries. Example.com also explicitly wants to deny write access
to that information. The read access is depicted in ACI “Billing Info Read”. The deny access is depicted in ACI “Billing Info Deny”.

ACI “Billing Info Read”

In LDIF, to grant subscribers permission to read billing information
in their own entry, you would write the following statement:

This example assumes that the relevant attributes have been created
in the schema and that the ACI is added to the ou=subscribers,dc=example,dc=com entry.

Proxy Authorization

The proxy authorization method is a special form of authentication.
A user that binds to the directory by using his or her own identity is granted
the rights of another user through proxy authorization.

To configure Directory Server to allow proxy requests you must do
the following:

You can grant proxy rights to any users of the directory except
the Directory Manager. In addition, you cannot use the Directory Manager’s
DN as a proxy DN. You need to exercise great care when granting proxy rights
because you grant the right to specify any DN (except the Directory Manager
DN) as the proxy DN. If Directory Server receives more than one proxied
authentication control in the same operation, an error is returned to the
client application and the operation attempt is unsuccessful.

Example Proxy Authorization

Example.com wants the client application that binds as MoneyWizAcctSoftware to have the same access rights to the LDAP data as an Accounting
Administrator.

With this ACI in place, the MoneyWizAcctSoftware client
application can bind to the directory and then send an LDAP command, such
as ldapsearch or ldapmodify, that requires
the access rights of the proxy DN.

In this example, if the client wanted to perform an ldapsearch command,
the command would include the following controls:

This example assumes that the ACI is added to the ou=People,dc=example,dc=com entry.

Note –

Because search filters do not directly name the object for which
you are managing access, try not to allow or deny access to the wrong objects.
Unintentionally allowing or denying access to the wrong objects becomes more
of a risk as your directory becomes more complex. Additionally, filters can
make it difficult for you to troubleshoot access control problems within your
directory.

Defining Permissions for DNs That Contain a Comma

DNs that contain commas require special treatment within your
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: