Recommended practices for directory structure

The Directory Server is often used as a repository for users and groups. This section describes some recommended practices for setting up a structure that is optimized for managing users and groups. This structure and associated security model can be extended to other uses of the directory.

Users are typically stored in a single, or few, locations. You might have a single container, cn=users, that is the parent entry for all users, or separate containers for distinct sets of users that are administered separately. For example, employees, vendors, and self-registered Internet users might be located under objects named cn=employees, cn=vendors, and cn=internet users, respectively. One might be tempted to place people under the organizations they belong to; however, this can create difficulties when they move to another organization as the directory entry then also needs to be moved and groups or other data sources (both internal and external to the directory) might have to be updated to reflect the new DN. The relationship of users to the organizational structure can be captured within the user entry using directory attributes such as "o" (organization name), "ou" (organizational unit name), and departmentNumber which are part of the standard schema for organizationalPerson and inetOrgPerson.

Similarly, groups are typically placed in a separate container, for example a container named "cn=groups".

By organizing users and groups in this manner, there are only a few places where access control lists (ACLs) need to be set.

Depending on how the directory server is used, and how users and groups are managed, you might use one of the following access control patterns:

• If the directory is used for applications like an address book, you might want to grant the special group cn=anybody read and search permissions for "normal" attributes in the cn=users container and its parent objects.
• Often, only the DNs used by specific applications and group administrators need access to the cn=groups container. You might want to create a group holding the DNs of group administrators and make that group the owner of cn=groups and its subordinates. You might create another group holding the DNs used by applications to read group information, and grant that group read and search permissions to cn=groups.
• If user objects are updated directly by users, you will want to grant the special access-id cn=this appropriate read, write, and search permissions.
• If users are updated through applications, often those applications run under their own identity, and only those applications need authority to update user objects. Once again, it is convenient to add these DNs to a group, for example, cn=user administrators, and grant that group necessary permissions to cn=users.

Applying this type of structure and access control, your initial directory might look like this:

• c=mycompany, dc=com is owned by the directory administrator, or another user or group with authority to manage the top level of the directory. Additional ACL entries grant read access to normal attributes for one of cn=anybody or cn=authenticated, or possibly some other group if a more restrictive ACL is needed.
• cn=users has ACL entries beyond those described below to allow appropriate access to users. ACLs might include:
  • read and search access to normal attributes for cn=anybody or cn=authenticated
  • read and search access to normal and sensitive attributes for managers
  • other ACL entries as desired, perhaps allowing write access for individuals to their own entry.