Having defined the type of information you want to store in the directory, you must decide how you are going to divide it into naming contexts. You can choose to divide the information according to:
Geographical boundaries, for example per company site
Corporate organization
DNS mail domains
User types
Service types (NIS, RADIUS, for example)
A combination of the above: for example, when you enable the NIS service, by default one naming context is created for people, and another for services. If you enable the RADIUS service, it is recommended to have one naming context for remote users, and another for network access servers (NAS). You can also create a naming context for each corporate location.
The logic you follow to divide your information into naming contexts can be defined regardless of the location of the information because you can replicate any part of any naming context to any server in your network.
However, you should make sure that any given resource has just one master entry in the directory. Otherwise, you will lose the main advantage of having one unique information repository.
The XYZ Corporation is an international pharmaceutical company with headquarters in Boston, USA. They have two manufacturing operations, one in Boston and one in London. There are two research groups, in New York and Paris colocated with marketing and sales. The sales organization also has an office in Hong Kong. The Human Resources function is represented in Boston for the US sites and in London for the European sites and the rest of the world (RoW).
Figure 3-1 shows the functional structure of XYZ Corporation.
Figure 3-2 shows the geographical structure of XYZ Corporation.
Because the main functions within the XYZ Corporation are located on different sites, neither an organizational DIT structure nor a functional DIT structure completely meets the company's directory structure needs. Also, the XYZ Corporation uses the NIS naming service to centralize information on mail users and network resources. Because this information is critical to the company's operation, the network management team wants to maintain it centrally, regardless of organizational or geographical boundaries. However, they are willing to enforce a per site maintainance of information considered to be less critical, and likely to be updated often. This is the case for information on users who are granted remote access to the network through a NAS.
The result is the DIT structure shown in Figure 3-3.
In this DIT structure, the corporation is divided into six organizational units (ou) and four localities (l) corresponding to ten naming contexts. Table 3-1 shows the RDN of each naming context and the servers on which it is stored. Table 3-2 shows which is the master server for naming contexts that are replicated to other servers.