Sun Directory Services 3.1 Administration Guide

Chapter 3 Planning a Directory Service

This chapter explains the global decisions you need to make about your directory service before you can start configuring individual components.

These are the things that you need to consider:

Type of information to store, for example, entries describing mail users, remote users connecting through a NAS, NIS tables, equipment connected to the network
Overall volume of information, and how to divide it up into naming contexts
How many servers you require
The information and services expected from each server
The overlap of information between servers
Which servers will hold master copies of replicated information
Replication methods

Types of Information

You must define the kind of information that you want to store in the directory. The schema must include the object classes and attributes required to store your information. If the default schema does not cover all your needs, refer to "Modifying the Schema" for details on how to create the object classes and attributes that you need.

The default schema will allow you to store information on resources such as:

Users
Remote RADIUS users
Devices (hosts, printers, Network Access Servers)
NIS naming service
Java objects
Document references

For a complete list of the type of objects you can create in the directory with the default schema, refer to "Object Class Reference".

When you are looking for an object class that matches the characteristics of a resource you want to describe in a directory entry, you must make sure that:

The object class offers or inherits all the attributes you need to describe your resource
You can assign a value to all the mandatory attributes offered or inherited by that object class

For example, XYZ Corporation has a proprietary on-line directory that provides the following information about every employee:

Name (first name, last name)
E-mail address
Telephone number
Job function

In the default schema, the object class that allows you to store all these attributes for a person is inetOrgPerson. This object class contains the optional mail attribute for storing an e-mail address. It inherits from the organizationalPerson and Person object classes. These object classes provide the necessary attributes for storing employees' names, telephone numbers and job functions.

Creating Naming Contexts

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.

Example: Naming Contexts in XYZ Corporation

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-1 Functional Structure of XYZ Corporation

Figure 3-2 shows the geographical structure of XYZ Corporation.

Figure 3-2 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.

Figure 3-3 DIT Structure for XYZ Corporation

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.

Location of Information on Servers

You must determine on which servers in your network to store the naming contexts you create. These are the constraints that you will need to take into account:

Number of servers
Location of servers
User requirements: make sure users get the information they need most often from the closest server to reduce communication costs
Size of the directory database: the maximum number of entries in each data store is 1 million (though a server can hold several data stores)

Based on the constraints imposed by your network, and the needs of users, you can work out where you want to store information. This decision can be made regardless of overlaps of information between servers. These overlaps will be handled by setting up a replication strategy.

For example, the XYZ Corporation has a directory server on each site except in Hong Kong. Table 3-1 shows the naming contexts held by each server.

Table 3-1 Naming Contexts Location in XYZ Corporation


Server	Naming Contexts
boston	ou=XYZ, c=US ou=People, ou=XYZ, c=US ou=Services, ou=XYZ, c=US ou=HR, ou=XYZ, c=US
newyork	l=New-York, ou=XYZ, c=US ou=US-RD, ou=XYZ, c=US ou=Eur-RD, ou=XYZ, c=US ou=Sales-Mktg, ou=XYZ, c=US
london	l=London, ou=XYZ, c=US ou=People, ou=XYZ, c=US ou=Services, ou=XYZ, c=US ou=HR, ou=XYZ, c=US
paris	l=Paris, ou=XYZ, c=US ou=Eur-RD, ou=XYZ, c=US ou=US-RD, ou=XYZ, c=US ou=Sales-Mktg, ou=XYZ, c=US

Setting Up a Replication Strategy

To set up a replication strategy, you need to identify the number of locations where the same information is present, determine which location will hold the master copy, and define the most efficient replication process between servers.

Simple and Cascading Replication

If you have two locations that hold the same information, you will have a simple replication with one master and one slave. If you have three or more locations that hold the same information, you can have a simple replication with one master and two or more slaves, or a cascading replication.

In a cascading replication, there are several levels of information replication: a replica copy on a slave server is in turn replicated to another slave. For information that is replicated in many locations, a cascading replication has the advantage of reducing the network traffic originating from the master server by sharing the load with the first level of slave servers.

Replication Methods

Sun Directory Services replication is based on the LDAP protocol. However, when the NIS service is enabled on a Sun Directory Services server, NIS replication can take place between this server and legacy NIS servers.

The NIS replication feature of Sun Directory Services offers a smooth transition from a classic NIS naming service to an integrated naming and directory service.

LDAP replication has the following advantages over NIS replication:

Partial replication is possible: you can choose the part of the DIT that you want to replicate, and you can also replicate just the changed attributes of modified entries
Better scalability: NIS replication is likely to fail if the number of entries replicated is in excess of 50,000.

Therefore, when the Sun Directory Services product is installed on several servers used as NIS servers, NIS replication should be disabled in favor of LDAP replication. For details, refer to "Configuring the NIS Service".

There are two replication modes for propagating changes between master servers and slave servers:

Master-based replication: the master server owns the synchronization schedule and pushes modifications to its slaves
Client-based replication: the slave server owns the synchronization schedule, and pulls modifications from the master server

Caution -

If you have both LDAP v2 and LDAP v3 servers in your environment, you may lose LDAP v3 specific information when replicating from an LDAP v3 server to an LDAP v2 server. For example, if replicated information makes use of language tags in attributes, all replication targets must support LDAP v3. Refer to the product release notes for details of migration from Sun Directory Services 1.0 to Sun Directory Services 3.1.

Example: Replication in the XYZ Corporation

Table 3-1 shows that some of the naming contexts in the XYZ Corporation are held on several servers in order to provide faster access and to reduce the connection costs by keeping information local.

One server holds the master copy, the others are replicas.

Table 3-2 shows the replication strategy for each naming context in the XYZ Corporation directory service.

Table 3-2 Replication Strategy for the XYZ Corporation


Naming Context	Master Server	Slave Server
ou=People, ou=XYZ, c=US	boston	london
ou=Services, ou=XYZ, c=US	boston	london
ou=HR, ou=XYZ, c=US	boston	london
l=Boston, ou=XYZ, c=US	boston
l=New-York, ou=XYZ, c=US	newyork
ou=US-RD, ou=XYZ, c=US	newyork	paris
ou=Sales-Mktg, ou=XYZ, c=US	newyork	paris
l=London, ou=XYZ, c=US	london
l=Paris, ou=XYZ, c=US	paris
ou=Eur-RD, ou=XYZ, c=US	paris	newyork

The replication method used to replicate changes between master servers and slave servers is LDAP.

Referrals

A referral system ensures that if an entry cannot be found locally, the directory server can pass a referral back to the client with a request to contact another directory server. Most LDAP client libraries automatically follow referrals and resubmit the user's original request.

There are two ways of defining referrals in Sun Directory Services:

Default referral for the directory server
Referral entries

The default referral is a parameter that you configure for each directory server. It is a pointer to another directory server. Usually, the referral server holds a higher node in the DIT than the one held by the current server, in order to widen the scope of the search.

A referral entry can be created at any level in the DIT to point to any subtree of the DIT held on a different data store. The value of a referral entry is a URL.

Note -

Do not create referrals from LDAP v3 servers to LDAP v2 servers. Most client libraries cannot follow a referral to an LDAP v2 server when the initial request was submitted to an LDAP v3 server.

Referral entries can be used to overcome the one million entry limit for a data store. It is possible to create a data store that holds referral entries directly under the root entry. These entries point to subtrees of the global DIT held on different data stores on the same server, or on different servers.

This principle is illustrated in Figure 3-4.

Figure 3-4 Referrals in a Multi-Million Entry Directory

The newyork, london and paris servers have a default referral to the o=XYZ, c=US data store held on the boston server. The boston server contains the following three referral entries:

l=New-York, ou=XYZ, c=US
l=London, ou=XYZ, c=US
l=Paris, ou=XYZ, c=US

A referral entry contains the following attributes:

objectClass = referral
ref = "ldap://hostname[:port]/DN"
The naming attribute of the referenced data store, also used to name the referral entry, to avoid using the ref attribute as the naming attribute

For example, the l=New-York, ou=XYZ, c=US referral entry contains:

DN: l=New-York,ou=xyz,c=US
objectClass: referral
ref: ldap://newyork/ou=New-York,ou=XYZ,c=US
l: New-York

If a search operation in the l=New-York, ou=XYZ, c=US tree fails, the LDAP protocol follows the default referral and searches the ou=XYZ, c=US tree. If a search is started on the ou=XYZ, c=US tree, the LDAP protocol follows the URLs provided in the referral entries to search all referenced data stores.