Planning the Directory Information Tree (DIT)

LDAP naming services have a default directory information tree (DIT) and an associated default schema. For example, the ou=people container contains the user account, password, and shadow information. The ou=hosts container contains information about systems in the network. Each entry in the ou=people container would be of objectclass posixAccount and shadowAccount.

The default DIT is a well designed directory structure and is based on open standards. It should be sufficient for most of naming service needs, and is recommended to be used without changes. If you choose to use the default DIT, the only thing you need to decide is from which node (base DN) in the directory tree the naming services information will be searched for a given domain. This node is specified with the defaultSearchBase attribute. Additionally, you might want to set the defaultSearchScope attribute to tell the clients the scope of search a naming service lookup should perform. Is it just searching one level under the DN (one), or the entire subtree under the DN (sub)?

There are times, however, that more flexibility is needed for the LDAP naming service to either work with an existing DIT or handle a more complicated DIT with naming service data scattered around the directory tree. For example, user account entries may exist in different part of the tree. The serviceSearchDescriptor, attributeMap, and objectclassMap attributes in the client profile are designed to handle these situations.

A service search descriptor can be used to override the default search base, search scope, and search filter for a particular service. See Service Search Descriptors (SSDs) and Schema Mapping.

The AttributeMap and ObjectclassMap attributes provide a way for schema mapping. They make it possible for the LDAP naming services to work with an existing DIT. You can map the posixAccount object class to an existing object class, myAccount, for example. You can map an attribute in the posixAccount object class to an attribute in the myAccount object class.

Multiple Directory Servers

Multiple LDAP servers can serve one DIT. For example, some subtrees of the DIT reside on other LDAP servers. In this case, an LDAP server may refer the LDAP client to a different server for the naming data it knows about but is not in its own database. If you plan such a DIT configuration, you should set the clients' profile attribute followReferrals to indicate to the LDAP naming service to follow server referrals to continue naming service lookups. However, it is best to have all naming data for a given domain reside on a single directory server, if at all possible.

Referrals can be useful if you want to have clients access read-only replicas most of the time and follow referrals to a read/write master server only when necessary. In this way, the master server does not get overloaded with requests that could be handled by replicas.

Data Sharing With Other Applications

To make best use of LDAP, you should have a single LDAP entry for each logical entry. For example, for a user you can have not only company white-page information, but also Solaris account information, and possibly application-specific data. Since posixAccount and shadowAccount are auxiliary object classes, they can be added to any entry in the directory. This will require careful planning, setup, and administration.

Choosing the Directory Suffix

See the Sun Java System Directory Server (formerly Sun ONE Directory Server) documentation for information about how to choose an appropriate directory suffix.