Chapter 3 Planning Your Directory Data

Your directory data is the information that you contain in your directory service. This data will include common information such as users' names, contact information (such as email addresses and telephone numbers), group identification, and group membership. A large part of designing your directory service is planning your directory's content.

In this chapter you will learn about the issues and strategies behind planning your directory's content. This chapter includes the following sections:

Data Planning Overview—This section provides an overview to the planning activities that you will perform while planning your directory's contents.

Introduction to Directory Data—This section describes what should and should not be included in your directory. Examples of the kind of data that is a good candidate for your directory is provided, as well as the kind of data that you should avoid placing in your directory.

Data Planning—This section provides advice on how to approach your data planning tasks.

Performing the Site Survey—This section provides advice on surveying your site for directory data.

Analyzing Your Site Survey—This section tells you how to approach data management in your directory. The concepts of data mastering, data ownership, and data access are discussed. Finally, some advice is given as to how you can document the results of your site survey and data analysis.

You will spend the majority of your time surveying your enterprise to locate all the data stores where directory information is managed. As you perform this survey, expect to find that some kinds of data are not well managed; some processes may be inefficient, inadequate, or nonexistent altogether; and some kinds of data that you expect to find are not available at all. All of these issues should be addressed before you finish your data-planning phase.

Your data-planning activities should include:

• Determine what directory-enabled applications you want to deploy and what their data needs are.
• Survey your enterprise and identify where the data comes from (such as NT or Netware directories, PBX systems, Human Resources databases, email systems, and so forth).
• Determine who needs access to the data. In particular, pay attention to your enterprise's mission-critical applications. Find out if those applications can directly access and/or update the directory.
• For each piece of data, determine the location where it will be mastered.
• For each piece of data, determine who owns the data; that is, who is responsible for ensuring that the data is up-to-date.
• For each piece of data, determine the name of the attribute that you will use to represent the data in the directory and the object class (the type of entry) that the data will be stored on.
• If you are going to import data from other sources, develop a strategy for both bulk imports and incremental updates. As a part of this strategy, try to master any given piece of data in just a single location, and limit the number of applications that can change the data to as few as possible. Also, keep the number of people who can write to any given piece of data to a small, easily identifiable group. Doing this will help ensure your data's integrity while greatly reducing your enterprise's administrative overhead.

Remember that simpler is better when it comes to managing data sources.

• Document your findings.

• The data should typically be read much more often than it is written. This is because directory services are tuned for read operations; write operations are considerably more expensive than reads in that they slow your server's performance down with respect to its intended usage.
• The data must be expressible in attribute-data format (for example, surname=jensen).
• The data should be of interest to more than one audience. For example, an employee's name or the physical location of a printer can be of interest to many people and applications.
• It should be useful to access the data from more than one physical location. For example, an employee's preference settings for a software application may not be a candidate for inclusion in the directory because only a single instance of that application needs access to the information. However, if the application is capable of reading preferences from the directory, then it is very useful to include the preference information in the directory. Doing so allows the user to interact with the application according to her preferences, regardless of where the user is physically located within the enterprise.

The following are typical examples of directory data:

• a person's contact information, such as telephone numbers, physical addresses, and email addresses
• a person's descriptive information, such as an employee number, job title, manager or administrator identification, and job-related interests
• an organization's contact information, such as a telephone number, physical address, administrator identification, and business description
• device information such as a printer's physical location, type of printer, whether the printer is capable of color output, and the number of pages per minute that the printer can produce
• contact and billing information for your corporation's trading partners, clients, and customers
• contract information, such as the customer's name, due dates, job description, pricing information, and general contact information for both the customer as well as the personnel within your enterprise responsible for the contract
• a person's software preferences or software configuration information
• resource locations, such as pointers to web servers or the file system location of a certain file or application

A directory service is not a file system, a file server, an ftp server, a web server, or a relational database. Therefore, if you want to include large, unstructured objects in your directory, you should consider using a server more appropriate for the task. However, it is appropriate to store pointers to these kinds of applications within your directory service through the use of FTP, HTTP, or other types of URLs.

Remember that a directory service is not a replacement for a relational database, although you can use a relational database to store directory data (see "The Netscape Directory Server" for details). Therefore, you should avoid placing any data that needs a relational data mode into your directory.

Also, because the directory is tuned for read operations, you should avoid placing rapidly changing information in the directory. Reducing the number of write operations occurring in your directory service maximizes overall search performance.

• A directory browser application, such as an online telephone book. Decide what information (such as email addresses, telephone numbers, employee name, and so forth) you want your users to be able to obtain through the directory when doing telephone book lookups and make sure you put that kind of information into the directory.
• Email applications, especially email servers. Not all email servers will require the same types of information. All email servers require email addresses, user names, and some routing information to be available in the directory. Others, however, will require more advanced information such as the location on disk where a user's mailbox is stored, vacation notification information, and protocol information (IMAP versus POP, for example).
• Directory-enabled HR applications. These require more personal information such as government identification numbers, home addresses, home telephone numbers, birth dates, salary, and job title.

As you plan, consider these points:

• What do you want to put in your directory today? That is, what is your immediate problem that you hope to solve by deploying a directory service? What is immediately needed by the directory-enabled applications that you will use first?
• What do you want to put in your directory in the future? For example, your enterprise might use an accounting package that does not currently support LDAP, but which you know will be LDAP-enabled in the near future. You should identify the data use by applications such as this and plan for the migration of the data into the directory when the technology becomes available.
• What do you think you might want to someday store in your directory? While this is the hardest case of all to consider, doing so may pay off in unexpected ways. At a minimum, this kind of planning helps you identify data stores (that is, locations where information is managed) that you might not otherwise become aware of.

• contracts or client accounts
• payroll
• physical devices
• home contact information
• office contact information for the various sites within your enterprise

• Locate all the organizations that manage your enterprise's information. Typically this will include your information services (IS), human resources (HR), payroll, and accounting departments.
• Identify the tools and processes that your enterprise uses to maintain this information. Some of the more common sources for information are networking operating systems (Windows NT, Novell Netware, Unix NIS), email systems, security systems, PBX [telephone switching] systems, and HR applications.
• Determine how centralizing each piece of data will impact the managing organizations. In the optimum case there is no impact, but you are likely to find that centralized data management might require new tools and new processes. Sometimes this centralization may require adding personnel to some organizations while reducing head count in others (in fact, overall you could see a reduction in head count as your processes become more efficient).

Finally, you may need to run more than one site survey. This is especially true of large enterprises with offices in multiple cities or even countries. You may find your informational needs to be so complex that you will have to allow various organizations to master information at a local office rather than at a single, centralized master server. In this case, each office responsible for mastering information should run its own site survey. After this 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.

Schema design is discussed in Chapter  4, "Planning Directory Schema." Directory tree design is discussed in Chapter  6, "Directory Tree Design."

The decision about what types of data are maintained in your directory, and when you will start maintaining it there, will be driven by several factors:

• The data required by your various legacy applications (such as existing email applications) as well as your user population.
• The ability of your legacy applications to communicate with an LDAP directory service.

Data Mastering

Data mastering is important only if your data resides in more than one physical location. This can happen if you are using replication or if you are using applications that cannot communicate over LDAP.

Data Mastering for Replication

If you use replication, then you must consider which server will master, or supply, any given piece of data. This is because the Netscape Directory Server requires you to master any given piece of information on a single master server. (For more information on replication, see Chapter  7, "Planning Replication.")

In the simplest case, you can choose to master all your data on a single Directory Server and then replicate that data to one or more consumer servers. In more complex cases, especially for large, multinational enterprises, you may want to master the data in a location close to the people, applications, or things that the data represents.

Data Mastering Across Multiple Applications

Data mastering will be an issue for you if you have applications that cannot directly communicate with the directory service. In this case, it best to keep the processes by which data can be changed, and the locations that it can be changed from, as simple as possible. Also, once you settle on a single location to master a piece of data, such as an employee's name, then if possible use that same location to master all of the other data also contained there, such as the employee's home address and telephone number. This allows you to more easily know where the ultimate repository for the information lies in the event that your databases get out of synch across your enterprise.

The approach that you take for data mastering can be one of the following:

• Master the data in both the directory service and all the other applications that are not directory-capable. This is the simplest case to implement because it does not require that you write custom scripts to move data in and out of the directory and the other applications. Of course, this method also means that if the data changes in one location, someone has to change it in all the other locations. Ultimately this is not an ideal situation because it will result in data being out of synch across your enterprise (which is what your directory is supposed to prevent).
• Master the data in the directory service and then write scripts or code to export changes to the relevant applications. This strategy makes the most sense if you have only a few applications that cannot communicate with the directory.
• Master the data in some application other than the directory and then write scripts, programs, or gateways to import that data into the directory. This makes the most sense if you can identify one or two applications that you already use to master your data, and you want to use your directory service only for lookups, such as is the case with online corporate telephone books.

For example, suppose you want to manage an employee's home telephone number. This information is stored in both the LDAP directory as well as in an human resources (HR) database. Depending on the HR application, you can probably write an automatic application that transfers data from the LDAP directory to the HR database, and vice versa. However, if you attempt to master changes to that employee's telephone number in both the LDAP directory and the HR data, this can lead to a situation in which the last location that the telephone number was changed overwrites the information in the other database. This is acceptable as long as the last writing application had the correct information. But if that information was old or out of date (perhaps because, for example, the HR data was reloaded from a backup), then the correct telephone number in the LDAP directory will be destroyed.

For a brief look at writing custom filters, see Chapter  10, "Extending Your Directory Service."

Data Ownership

Data ownership refers to the person or organization that is responsible for making sure the data is up-to-date. As you plan your data management, you need to decide who you want to be able to write to the data. Some common strategies are:

• Allow read-only access to the directory for everyone except a small group of directory content managers.
• Allow individual users to manage some strategic subset of information for themselves. This information might include their own passwords, descriptive information about themselves and their role within the organization, their automobile license plate number, and contact information such as telephone numbers or office numbers.
• Allow a person's manager to write to some strategic subset of that person's information, such as contact information or job title.
• Allow an organization's administrator to create and manage entries for that organization. This effectively causes your enterprise's administrators to also be your directory content managers.
• Create groups that define roles, such as Human Resources, Finance, or Accounting. Allow each of these roles to have read and/or write access only to the data, especially sensitive data, that is needed by the group, such as salary information, government identification number (in the US, social security number), and home phone numbers and address.

For information on setting access-control for your directory, see Chapter  5, "Planning Security Policies."

Determining Data Access

Besides determining data ownership, you must also decide who can read each piece of information. For example, you may decide to store an employee's home phone number in your directory. This can be useful information for a number of organizations, including the employee's manager and your human resources organization. Presumably, you would also want the employee herself to be able to read this information for verification purposes. However, home contact information can be considered sensitive information. Therefore you must ask yourself (and your users) if you want this kind of data to be widely available across your enterprise.

Consequently, for each piece of information that you store in your directory, you must decide the following:

• Can the data be read anonymously? Anonymous access is supported by the LDAP protocol, and it is frequently used to allow easy lookups for commonly needed information such as office locations, email addresses, business telephone numbers (voice and fax), and so forth. The downside to anonymous access is that can access the directory can also access the information. Consequently, you should use this feature sparingly.
• Can the data be read widely across your enterprise? You can set up access-control so that it is necessary to log in to (bind to) the directory in order to read specific information. You might want to choose this form of general access over anonymous access to ensure that only members of your enterprise can view directory information. This form of access-control also allows you to see who is accessing any given piece of information because the user's login information can be captured in the directory's access log.
• Is there an identifiable group of people or applications who need to be able to read the data? Anyone who has write privileges to the data generally also needs read access (the exception to this is write access to passwords). However, you may also have data that is needed only by a specific organization or project group. Identifying these access needs as early as possible will help you to determine what groups and what access-controls you need to create in your directory.

For information on group management, see "Planning Your Groups".

The creation of a security policy and the way in which you implement it is described in detail in Chapter  5, "Planning Security Policies."

Documenting Your Site Survey

Because of the complexity of this planning activity, it is important that you document the results of your data analysis. One way to approach this problem is to create a simple table that outlines your decisions and outstanding concerns. You can build this table with the word-processing package of your choice, or you may want to use a spreadsheet so that the table's contents can easily be sorted and searched.

The following table is a simple example of what you might want to build to help you with your data planning. The table identifies data ownership and data access for each piece of identified data.

Data Name	Owner	Master Server/Application	Self Read/Write	Global Read	HR Writable	IS Writable
Employee name	HR	People Soft	Read-only	Yes (anonymous)	Yes	Yes
User password	IS	Directory US-1	Read/Write	No	No	Yes
Home phone number	HR	People Soft	Read/Write	No	Yes	No
Employee location	IS	Directory US-1	Read-only	Yes (must login)	No	Yes
Office phone number	Facilities	Phone switch	Read-only	Yes (anonymous)	No	No

• Owner—The owner of this information is human resources (they are the organization responsible for updating or changing the information).
• Master Server/Application—The application that will manage employee name information is a HR application called People Soft.
• Self Read/Write—A person can read their own name, but not write (or change) it.
• Global Read—Employee names can be read anonymously by everyone who has access to the directory.
• HR Writable—Members of the group HR can change, add, and delete employee names in the directory.
• IS Writable—Members of the group called IS (information services) can change, add, and delete employee names in the directory.

A final aspect to your data analysis is designing your directory schema. Essentially, schema design involves mapping the pieces of data that you have discovered to an appropriate attribute name and syntax. You will also have to decide what types of entries you will contain in your directory (people, devices, organizations, and so forth) and this will, in turn, determine the actual attributes that you have available to you on any given type of entry.

Most likely you will have to extend the standard directory schema to support your enterprise's needs. Consequently, you should leave room in your data analysis table for identifying the attribute name and object class structure on which the specific piece of data will be represented. In addition, you may want to record other schema-related information such as the syntax used for a type of data, the object class used by the entry that the data will be stored on, and so forth.

The next chapter discusses directory schema, and the concepts of attributes, object class structures, and schema extension. In addition, "Customizing the Schema" provides general advice for managing your directory schema.