Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java(TM) System Directory Server 5 2004Q2 Deployment Planning Guide 

Chapter 2
Planning and Accessing Directory Data

The data stored in your directory may include user names, e-mail addresses, telephone numbers, and information about groups users belong to, or it may contain other types of information. The type of data in your directory determines how you structure the directory, to whom you allow access to the data, and how this access is requested and granted. Directory Server enables you to access directory data either via LDAP or DSML, extending the types of applications that can interact directly with the data.

This chapter describes the issues and strategies behind planning and accessing directory data. It includes the following sections:

Introduction to Directory Data

Some types of data are better suited to a directory than others. Ideal data for a directory has the following characteristics:

What Your Directory Might Include

Examples of data you can store in your directory are:

Apart from server administration data, you may want to store the following types of information in your directory:

What Your Directory Should Not Include

Directory Server is well suited to managing large quantities of data that client applications read and occasionally write, but it is not designed to handle large objects, such as images or other media. These objects should be maintained in a file system. However, your directory can store pointers to these kinds of applications through the use of FTP, HTTP, or other types of URL.

Because Directory Server works best for read operations, you should avoid placing rapidly changing information in the directory. Reducing the number of write operations improves overall search performance.

Defining Your Data Needs

When you design your directory data, try to think not only of the data you currently require but also what you may include in your directory in the future. Considering the future needs of your directory during the design process will influence how the data is structured and distributed.

As you plan your deployment, consider the following:

Performing a Site Survey

A site survey is a formal method of discovering and characterizing the contents of a directory. Budget plenty of time for performing a site survey, as data is the key to your directory architecture. The site survey consists of the following tasks, which are described briefly here and then in more detail:

Identifying Client Applications

Generally, the applications that access your directory and the data needs of these applications drive the planning of directory contents. Common applications that may use your directory include:

When you examine the applications that will use your directory, look at the types of information each application uses. The following table gives an example of applications and the information used by each:

Table 2-1  Application Data Needs


Class of Data


Phone book


Name, e-mail address, phone number, user ID, password, department number, manager, mail stop

Web server

People, groups

User ID, password, group name, group members, group owner

Calendar server

People, meeting rooms

Name, user ID, cube number, conference room name

Web portal

People, groups

Name, User ID, password, group name, group members

When you have identified the applications and information used by each application, you may see that some types of data are used by more than one application. Doing this kind of exercise during the data planning stage can help you avoid data redundancy.

The data maintained in your directory, and when it starts being maintained, is affected by:

Identifying Data Sources

To identify the data to be included in your directory, perform a survey of existing data sources. Your survey should include the following:

During your survey, you may come up with a matrix that resembles the following table, identifying all of the information sources in your enterprise:

Table 2-2  Information Sources

Data Source

Class of Data


Human resources database


Name, address, phone number, department number, manager

E-mail system

People, Groups

Name, e-mail address, user ID, password, e-mail preferences

Facilities system


Building names, floor names, cube numbers, access codes

Characterizing Directory Data

The data you identify can be characterized as follows:

Study each piece of data you plan to include in your directory to determine what characteristics it shares with other pieces of data. This helps save time during the schema design stage, described in Chapter 3, "Directory Server Schema."

For example, you can create a table that characterizes your directory data as follows:

Table 2-3  Directory Data Characteristics





Related to

Employee Name

Text string

128 characters

Human resources

User’s entry

Fax number

Phone number

14 digits


User’s entry

E-mail address


Many characters

IS department

User’s entry

Determining Directory Availability Requirements

The level of service you provide, in terms of availability, depends on the expectations of those who rely on directory-enabled applications. To determine the level of service an application expects, first determine when and how the application is used.

As your directory evolves, it may need to support a variety of service levels. It may be difficult to raise the level of service after your directory is deployed, so make sure your initial design can meet future needs.

Considering a Data Master Server

The data master is the server that is the primary source of data. If you have more than one data center (physical site) you need to decide which server will be the data master, and which servers receives updates from this data master.

Data Mastering for Replication

If you use replication, decide which server will be the master source of your data. Directory Server supports multi-master configurations, in which more than one server can be a master for the same data. For more information about replication and multi-master replication, see Chapter 6, "Understanding Replication."

In the simplest case, put a master source of all your data on two Directory Servers and then replicate that data to one or more consumer servers. Having two master servers provides failover in the event that a server goes offline. In more complex cases, you may want to store the data in multiple databases, so that the entries are mastered by a server close to the applications that will update or search that data.

Data Mastering Across Multiple Applications

You also need to consider the master source of your data if you have applications that communicate indirectly with the directory. Keep the processes for changing data, and the places from which you can change data, as simple as possible. Once you decide on a single site to master a piece of data, use the same site to master all of the other data contained there. A single site simplifies troubleshooting if your databases get out of sync across your enterprise.

Here are some ways you can implement data mastering:

How you maintain master copies of your data depends on your specific needs. However, regardless of how you maintain data masters, keep it simple and consistent. For example, you should not attempt to master data in multiple sites, then automatically exchange data between competing applications. Doing so leads to a “last change wins” scenario and increases your administrative overhead.

Suppose you want to manage an employee’s home telephone number. Both the LDAP directory and a human resources (HR) database store this information. The HR database is LDAP enabled, so you can write an application that automatically transfers data from the LDAP directory to the HR database, and vice versa. However, if you attempt to master changes to the telephone number in both the LDAP directory and the HR database, the last place where the telephone number was changed overwrites the information in the other database. This is fine if the last application to write the data had the correct information. But if that information was out of date (because the HR data was reloaded from a backup, for example), the correct telephone number in the LDAP directory will be deleted.

Determining Data Ownership

Data ownership refers to the person or organization responsible for making sure the data is up to date. During the data design phase, decide who can write data to the directory. Common strategies for determining data ownership include the following:

As you determine who can write to the data, you may find that multiple individuals require write access to the same information. For example, you will want an information systems or directory management group to have write access to employee passwords. You may also want the employees themselves to have write access to their own passwords. While you generally must give multiple people write access to the same information, try to keep this group small and easy to identify. Keeping the group small helps ensure your data’s integrity.

For information on setting access control for your directory, see Chapter 7, "Access Control, Authentication, and Encryption."

Determining Data Access

After determining data ownership, decide who can read each piece of data. For example, you may decide to store an employee’s home phone number in your directory. This data may be useful for a number of organizations, including the employee’s manager and human resources. You may want the employee to be able to read this information for verification purposes. However, home contact information can be considered sensitive. Therefore, you must determine if you want this kind of data to be widely available across your enterprise.

For each piece of information stored in your directory, decide the following:

As you make these decisions for each piece of directory data, you define a security policy for your directory. Your decisions depend on the nature of your site and the kinds of security already available. For example, if your site has a firewall or no direct access to the Internet, you may feel more free to support anonymous access than if you are placing your directory directly on the Internet.

In many countries, data protection laws govern how enterprises must maintain personal information, and restrict who has access to the personal information. For example, the laws may prohibit anonymous access to addresses and phone numbers, or may require that users have the ability to view and correct information in entries that represent them. Check with your organization’s legal department to ensure that your directory deployment follows the necessary laws for the countries in which your enterprise operates.

The creation of a security policy and the way you implement it is described in detail in Chapter 7, "Access Control, Authentication, and Encryption."

Documenting Your Site Survey

Because of the complexity of data design, it is advisable that you document the results of your site surveys. During each step of the site survey we have suggested simple tables for keeping track of your data. Consider building a master table that outlines your decisions and outstanding concerns.

A basic data tracking example is provided in Table 2-4. This table identifies data ownership and data access for each piece of data identified by the site survey.

Table 2-4  Data Tracking Table Example for Site Survey Documentation Purposes

Data Name


Master Server Application

Self Read/Write

Global Read

HR Writable

IS Writable

Employee Name


People Soft


Yes (anonymous)



User password


Directory US-1





Home phone number


People Soft





Employee location


Directory US-1


Yes (must log in)



Office phone number


Phone switch


Yes (anonymous)



The row representing the employee name data contains the following:

Repeating the Site Survey

You may need to run more than one site survey, particularly if your enterprise has offices in multiple cities or countries. You may find your informational needs to be so complex that you have to allow several different organizations to keep information at their local offices rather than at a single, centralized site. In this case, each office that keeps a master copy of information should run its own site survey. After the site survey process has been completed, the results of each survey should be returned to a central team (probably consisting of representatives from each office) for use in the design of the enterprise-wide data schema model and directory tree.

Accessing Directory Data With DSML Over HTTP/SOAP

Previous versions of Directory Server enabled you to access directory data using the Lightweight Directory Access Protocol (LDAP). Directory Server 5.2 also enables you to access directory data using Directory Service Markup Language version 2 (DSMLv2) over HTTP/SOAP.

DSMLv2 is a markup language, that is, a vocabulary and schema that enables users to describe the structure and content of directory services data operations in an eXtensible Markup Language (XML) document. DSMLv2 standardizes the way directory services information is represented in XML. Directory Server supports the use of DSMLv2 over the Hypertext Transfer Protocol (HTTP/1.1) and uses the Simple Object Access Protocol (SOAP) version 1.1 as a programming protocol to transport the DSML content.

For information on configuring the DSML frontend and on accessing and searching data using DSMLv2 over HTTP/SOAP, see “Configuring DSML,” in Chapter 1 of the Directory Server Administration Guide.

DSMLv2 Over HTTP/SOAP Deployment

The following sample deployment using DSML-enabled Directory Servers and Sun Java System Web Proxy Server, enables non-LDAP clients to interact with directory data.

Figure 2-1  Sample DSML-Enabled Directory Deployment

Sample DSML--enabled deployment showing DSMl requests sent over HTTP (port 80)  and HTTPS (port 443)

In this sample deployment, update requests in DSML arriving from non-LDAP client applications cross a firewall over HTTP port 80 and enter a demilitarized zone (DMZ.) From there Directory Proxy Server configured as a reverse proxy server enforces the use of secure HTTP over port 443 for the requests to cross a second firewall and enter the intranet domain. The requests are then processed by the two master replicas on Master A and Master B, before being replicated to the non-DSML enabled Consumers C and D.

This deployment enables non-LDAP applications to perform directory operations. If the client requests are solely lookup requests, it is irrelevant whether the DSML-enabled Directory Servers hold read-only or read-write copies of the data, because both would be able to process the lookup requests. However, if a non-LDAP client issues modification requests, it is important for the DSML-enabled Directory Servers to hold read-write copies of the data. The default behavior for a consumer receiving a modification request is to return a referral with a list of LDAP URLs of the possible masters that could satisfy the request. Returning an LDAP URL over HTTP to a non-LDAP client application would not fulfill the objective of keeping client/directory traffic LDAP-free, which is why read-write copies are preferable. The deployment depicted in Figure 2-1, holds read-write copies of the data on the DSML-enabled Directory Servers Master A and Master B. These masters process modification requests and then replicate the data to the non-DSML enabled Consumers C and D.

The DSML front end constitutes a restricted HTTP server. It accepts only DSML HTTP post operations, and rejects requests that do not conform to the SOAP/DSML specification. Therefore, the threat is less extensive than for other types of HTTP web server. Nonetheless, you should take into account the following security considerations when including DSML-enabled Directory Servers in your deployment:

Previous      Contents      Index      Next     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.