Conclusiones y recomendaciones

The directory administrator (the user with theroot DN) is, by default, the only one person who can administer information in the directory. At times, it will be necessary to allow other users to have administrative privileges on all or portions of the directory. The Directory Information Tree (DIT) can be divided into administrative areas; the directory administrator can give other

distinguished names (DNs) full privileges to manage some subsection of the directory. In order to grant a user administrative permission to a subtree, that user DN must be specified in the entry owner attribute. The administrative domain will be delimited by the value of an owner inheritance attribute (OwnerPropagate); if it is set to FALSE, the scope of the administrator will be the single entry on which the owner was set, and if OwnerPropagate is set to TRUE, the administrative domain will be the entire subtree unless a new entry owner is specified in a descendant entry. For more details, see 7.9.3,

“Ownership and Access Control” on page 206.

The following three sections discuss some general consideration that apply when administration is being distributed to multiple administrators.

4.2.1 Who Administers The Data?

The simplest model of data administration is to allow only the directory administrator (root DN) to administer all the data. While this is clear cut and simple, it is not probable that the same person will be administrating all applications using the directory. In order to facilitate data administration, it is possible to allow additional users to administer parts of the directory. This flexibility allows administrative privileges to users, groups of users, or users acting in particular roles.

There are two methods of granting a user the ability to administer directory data. One is to grant them permissions on attribute classes via the ACL entry, and the other option is to make them an entry owner.

By making someone an entry owner, that person becomes an administrator for that particular entry. They can modify any attribute within the entry and can change the access control lists of that entry. Users given permissions by the ACL entry cannot modify the ACLs on the entry and only have

permissions to what is specified in the ACL entry.

In order to facilitate administration of the ACL information, two DNs have been created and are used as pseudo-subjects. These pseudo-subjects are not represented by an object in the directory but can be used on an ACL. They are used to refer to large numbers of DNs, which, at bind time, share a common characteristic in relation to either the operation being performed or the object on which the operation is being performed.

The first of these is the group <cn=Anybody>. When specified as part of an ACL, this group refers to all users. Users cannot be removed from this group, and this group cannot be removed from the database. <cn=Anybody> is considered to be the group of all unauthenticated users or any user which does not have a specific ACL on an object. By default, this group has read, search, and compare permissions to attributes within the normal class. The second pseudo DN is the access-id <cn=self>. When specified as part of an ACL, it grants permissions when the bind DN matches the object DN on which the operation is performed. If an operation is performed on the object <cn=personA, ou=IBM, c=US>, permissions associated with the access ID <cn=self> would be granted when the bind DN is <cn=personA, ou=IBM, c=US>.

An example of when a pseudo subject might be useful is a phone book application. The administrator might want to give individuals permissions to update parts of their own entry. If all the attributes that the user should be able to update are in the normal class, the administrator will put a single ACL on the entry (or propagate some parent ACL) which stated

<access-id:cn=self:normal:rwsc>. Each user would now have permission to update parts of their own entry.

You can see an example in 7.9.3, “Ownership and Access Control” on page 206 that gives you more information regarding this topic.

4.2.2 Attribute Grouping

It is likely that many attributes will require the same type of protection. It is, therefore, useful to coarsen the access policy granularity by grouping

attributes with similar access sensitivities. This reduces the number of access lists within the directory and greatly simplifies administration.

Attributes are grouped together inattribute access classes. Within the schema file, attributes are mapped to an access control class. Each class is discrete, that is, access to one attribute class does not imply access to another class.

Instead of specifying that a subject has access to an attribute, the

administrator gives a subject permissions to an access class. This grants the subject the specified permissions to all attributes within that access class. Let's use the example of modeling an organization. People attributes can be grouped into several categories. One might groupcriticalattributes, such as salary, job grade or level, and hire date together. Attributes such as phone, location, and e-mail address will be considered normal, and the performance evaluation ratings attribute might besensitive.

Subjects will then be given access to a given class of information. If the information they were requesting is within a class to which they are

authorized, then the LDAP operation succeeds. For example, a person might have read and write access to their own normal attributes but only read to sensitive and critical. One might want the person's manager to have read access to normal and critical and read-write access to sensitive while critical attributes can be read and written by anyone who is acting in the personnel role. The ACL for this might read something like (Aclentries are explained in 5.6, “Access Control” on page 120):

Aclentry: access-id:cn=self:normal:rwsc:sensitive:rcs:critical:rsc Aclentry: access-id:cn=manager, ou=org,

c=us:normal:rcs:critical:rsc:sensitive:rwsc

Aclentry: role:cn=personnel, ou=org,c=us:critical:rwsc

The default schema has classified each attribute into an access class based on the expected use of the attributes. The assigned classes can be seen by looking at the schema files. When adding attributes to the directory schema, the administrator will have to assign attributes to access classes.

Generally, overall guidelines for establishing the types of data that fall into each of the attribute classes can be decided on by the directory administrator. For instance, normal attributes are those which are readable by everyone, modifiable by the object DN, and possibly modifiable by some other DNs which have the authority to do so. Sensitive attributes might be those that are

The preceding example has granted search and compare permissions wherever read permissions are given.

writable by the object DN and possibly one or two other DNs. Critical attributes might be those that are readable to the object DN, but writable by one or two other administrative users.

4.2.3 Multiple Applications

When there is only one application that uses a directory, defining the objects and attributes and administering the data in the directory is very simple. Or, if an administrator is simply merging multiple existing directories into a single directory, it's easy to merge the objects and the attributes and decide on a grouping policy.

This activity becomes more difficult as the number of applications and administrators increases. It is very important to maximize common semantics and syntax of similar objects and attributes. However, for some small subset of object classes, multiple applications may need to use the same object and its attributes in slightly different manners.

In an ideal situation, the application administrators will reach an agreement regarding which attributes belong to which access classes. Furthermore, they will come to a consensus as to which DNs are given permissions to

administer those classes. While this sounds like an unlikely event at first, it is realizable. For instance, two applications (A and B) want their own attributes, which they alone administer. Previously, both had used the criticalattribute class for these attributes. If they both continue using the critical attribute class, the people granted rights on the critical class can now update the attributes for both application A and application B. This may, in fact, be the desired scenario if the administrator for the two applications is the same. If not, one must consider that the number of administrators updating critical attributes is probably very small. One alternative is to trust that the

administrator for application A will read the documentation and know which attributes belong to their application and operate only on those attributes. Unless the administrator is trying to maliciously undermine another application, there is no worry that they will harm the other application’s attributes.

For those instances where an agreement cannot be reached, there is another possibility. Each application can create a child node that contains the

attributes necessary for its own function. For instance, the object in question might be a person object of DN <cn=person, o=organization>. Application A wants total and complete control over some subset of the attributes as does Application B. Each application will create a child node with the relative distinguished name (RDN) of the application name:

will be of objectclass <applicationNamePersonNode>. The application will store its secret application data in this subnode. As much common information should be shared as possible, but, in cases where it is not feasible, another object is created. One can still effectively retrieve all the attributes of the object by performing a one-level search, which would return the application-specific attributes.

This approach has several benefits. It ensures that the <cn=person, o=organization> object cannot be deleted by anyone who does not have permission to delete all to the application-specific nodes under that object. Therefore, application A does not have to worry about nasty side effects of application B deleting the object. If application B wants the object gone, it deletes its own subNode <appName=applicationB, cn=person,

o=organization>, and the entry <cn=person, o=organization> is gone from application B's perspective. However, for application A, the entry still exists. Using the access control list on the application-specific subnode, the

administrator can completely control who has permissions to those attributes. It may be that some are still world-readable where in some cases some other applications find them useful. It is, of course, possible that each application can give delete or modify permission to administrators of one or more other applications. For instance, the user administrator might give modify

permissions on some classes to the help desk administrator so passwords or other information can be reset when the user calls the help desk.