Directory Service Design

In this section we describe Netscape's directory design and how it was developed.

Needs

As in many businesses, Netscape's directory requirements were largely determined by two needs: the need to support a wide range of applications and the need to deploy them in a manageable and cost-effective manner.

As mentioned previously, Netscape's IS department is charged with providing computing support to employees at the main campus and satellite offices. With few exceptions, IS provides all the hardware, software, and network connectivity for every employee. (This arrangement is in contrast to the decentralized support methods that will be described in Chapter 26.)

Despite this centralization, minor political problems arose when the directory service was being deployed. Obtaining a synchronization file that contained information on all full-time employees, contractors, temporary employees, and contingent employees proved difficult, and the issue had to be escalated to senior management. After the synchronization file was obtained, IS staff needed to spend a significant amount of time modifying existing IS and HR work processes to tie them into the directory. Connecting everything to the directory required some modifications to existing HR database tables and associated user interfaces, which required cooperation from the HR staff.

Another constraint was that the staff involved in the directory design and deployment, although extremely skilled, needed some time to become familiar with directory technology. Fortunately the developers responsible for the directory server software (Netscape Directory Server) were literally next door. The proximity of the two groups provided immense benefits for both IS and the Directory Server software engineering team; questions from IS were handled quickly and accurately, and Engineering obtained valuable information on how the product worked in an actual deployment. In essence, the Netscape internal directory deployment still provides an ongoing directory pilot that continually feeds back useful information to the Netscape Directory Server engineering group , ultimately resulting in a higher-quality , more functional product.

One of the primary motivations for the directory deployment was to support Netscape's suite of directory-enabled server products, including Netscape Messaging Server (electronic mail), Netscape Collabra Server (Usenet news and internal discussion groups), Netscape Enterprise Server (internal Web publishing), Netscape Certificate Management System (for public key certificates), and Netscape Calendar Server (for workgroup scheduling). ^[1] Each of these products is directory-enabled and can utilize the directory for user and group management and access control. In addition, employees have become very dependent on Netscape Phone Book, an internally developed application that allows quick and easy lookup of contact information and location information for people and meeting rooms.

^[1] Some of these Netscape products are no longer available.

The directory is also used for specific work processes, serving as the focal point for creation or removal of resources when a person joins or leaves Netscape. For example, when an employee is hired , a directory entry is created, triggering processes that create Unix and Microsoft Windows NT domain accounts, assign telephone numbers , add the employee to the security/badging database, allocate a network port, and include the employee on certain companywide , divisionwide, and workgroup-specific mailing lists.

Early in the design process, Netscape IS made the assumption that directory users needed to feel confident that the central repository of directory data was secure, stable, valuable, and accurate. These needs led to the conclusions described here:

• Security . Users must believe that the information in the directory is protected from unauthorized use by other employees and persons outside the company. This means that each attribute type stored in the directory should be reviewed and a policy established for how that data may be used, who may use it, and how it will be protected.

• Stability . Users must feel that the data in the directory is stable. Data should not change unless in response to a change in the environment (for example, a new phone number). When users are allowed to change data in the directory, their changes should not arbitrarily disappear.

• Value . Users must find some value in the directory data. They should find useful data that allows them to perform their jobs, and they should not be forced to wade through nonessential or inappropriate data. The directory can also provide value by allowing the directory data to be put to use in new and novel applications (see the section titled Leveraging the Directory Service later in this chapter).

• Accuracy . Users must feel that the data in the directory is accurate. Stale data reduces the usefulness of the directory and causes users to use other, less efficient means of obtaining the information they need.

In addition, the directory itself must be flexible enough to accommodate new applications, and it must scale well so that users always receive adequate performance.

Data

As mentioned in the previous section, the primary drivers behind the directory service revolved around the directory-enabled applications slated for deployment. Those applications had well-defined schema requirements, which made identification of the necessary data elements very straightforward.

What was less straightforward, however, was identifying the "owner," or authoritative source, of each data element. The Netscape IS organization began by developing a conceptual framework for understanding the directory, external data sources, and external users of the data. Figure 24.1 shows this framework.

Figure 24.1. A Conceptual Framework for Data Sources

Data owners are the databases that contain authoritative enterprise data. For example, data stored in the PeopleSoft system is considered authoritative for certain elements, such as a person's name and home postal address. The private branch exchange (PBX) telephone system is considered authoritative for office telephone numbers. In the Maintaining Data section of this chapter, we'll describe the process that synchronizes data between the directory and other data sources.

Data is collected from the authoritative data sources and placed into the directory service. In this role, the directory serves as a central repository , a rendezvous point where applications can meet to obtain data about people, groups, and other business- related objects. The directory serves a valuable role by publishing and grouping the data synchronized from the various distinct data sources.

The directory service itself is considered authoritative for some data elements, such as e-mail addresses. For these data elements, the directory functions simultaneously as the data owner and the central repository.

Data users are the applications, business processes, and people that make use of the directory data stored in the central repository.

After the fundamental data model had been developed, the Netscape directory deployment team refined the data plan further by establishing the following basic guidelines for deciding that a given data element should be stored in the directory:

• If two or more applications require the data element . If only one application needs it, the element does not need to be shared.

• If the directory data changes in response to events that occur in the Netscape environment . This guideline stands in contrast to other traditional databases that change in response to minute-by-minute data processing needs, such as an order fulfillment database. This policy is meant to discourage use of the directory as a relational database.

• If the directory data can facilitate location independence . Netscape believes that storing user preferences is a completely valid and desirable use of its directory service.

Next a detailed data element inventory was completed. This inventory described each data element, the directory's attribute name for it, the authoritative source, and the consumers that use it. Table 24.1 shows a portion of that inventory.

Table 24.1. A Portion of Netscape's Data Element Inventory

Data Element	LDAP Attribute Name	Authoritative Source	Consumers of the Data Element
E-mail address	mail	Directory	Messaging server Phone Book application E-mail client address books
Business telephone number	telephoneNumber	PBX system	Phone Book application E-mail client address books
Employee's manager	manager	PeopleSoft system	Phone Book application
Employee photograph	jpegPhoto	Facility access	Security photograph (badging)

Finally, a set of synchronization procedures was developed to propagate changes from external authoritative data sources such as the PeopleSoft and PBX systems into the directory. These synchronization procedures are the core of Netscape's directory coexistence strategy and are designed to capture changed data in the external authoritative data sources and apply updates to the directory.

Schema

The schema used in the central directory is composed of three distinct sets of schema definitions:

1. Schema definitions packaged with the directory-enabled applications, such as Netscape Calendar Server, Netscape Messaging Server, and Netscape Certificate Management System.

2. The POSIX (Portable Operating Systems Interface) schema, as defined in RFC 2307. These schema elements define the user information stored by POSIX-compliant Unix operating systems. They allow the directory to store user information for use by the company's Unix systems.

3. Custom schema elements that were developed in-house. These elements support Netscape business processes. For example, one attribute describes the termination date for an employee who is leaving the company. Automated processes revoke access to directory-enabled applications after the termination date.

Netscape IS staff members added the custom schema definitions only after carefully examining available schema elements and determining that no existing attribute types met Netscape's needs.

All schema extensions were implemented as auxiliary, or "mix-in," object classes. To illustrate , consider the definition of the nscpPerson object class shown in Listing 24.1 (note that nscpPerson-oid should be replaced by a real object identifier, or OID).

Listing 24.1 The nscpPerson Object Class

 (  nscpPerson-oid  NAME 'nscpPerson'   DESC 'Netscape-specific person information'   SUP top   AUXILIARY   MUST uid   MAY ( nscpBadgeImage $         nscpPersonExpDate $         nscpCurContactInfo $         nscpBuildingNum $         nscpBuildingLev $         nscpHarold   ) 

This auxiliary object class contains only the Netscape-specific attributes. Entries in the directory that describe people have both the inetOrgPerson and nscpPerson object classes . Thus a person entry may contain any of the attributes allowed by either the inetOrgPerson or the nscpPerson object class. In this way, Netscape extended the schema with business-specific attributes without altering the standard object class definitions. The added attributes were as follows :

• nscpBadgeImage . The digitized photograph from the employee's ID badge. This attribute may be viewed only by campus security personnel (to protect employee privacy).

• nscpPersonExpDate . The date after which an entry is no longer valid. When an employee leaves the company, this attribute contains the date of his or her last day of employment.

• nscpCurContactInfo . A free-form text attribute that may be set by the employee to indicate how he or she may be contacted if not in the office. Inclusion of this information allows employees to be tracked down for important customer support issues, for example.

• nscpBuildingNum . The number of the building where an employee works.

• nscpBuildingLev . The building floor where an employee works.

• nscpHarold . The legal name of the employee. Because the common name ( cn ) attribute contains the name by which people commonly know a person, there needs to be another attribute to hold the employee's legal name. In case you were wondering where the name of this attribute came from, one member of the directory deployment team went by a name other than his legal name, which happened to be Harold.

Namespace

Figure 24.2 shows Netscape's directory namespace. Netscape decided to use domain component naming for the top or global portion of the namespace ( dc=netscape,dc=com ). The organizational units that define subnamespaces beneath the top level are as follows:

• ou=People . Holds information about all Netscape employees and contractors. The namespace within this container is flat (that is, all people entries are located directly below the organizational unit container).

• ou=Groups . Holds groups used for access control decisions. For example, the list of mailing list administrators is defined in this container. The namespace underneath this container is also flat.

• ou=devices . Will hold information about various network-accessible devices such as printers (not currently used). IP address, MAC (Media Access Control) address, owner, serial number, and other information will be recorded for each device.

• ou=pseudoaccounts . Holds definitions of directory identities that are used for special purposes. For example, when one directory server needs to authenticate to another directory server as part of a replication session, it uses one of these identities. The namespace under this node is flat.

• ou=mailGroups . Holds group definitions used for routing electronic mail to groups of employees and to external e-mail addresses. The mail group entries are maintained in a separate directory tree because of limitations in earlier versions of internal mailing list management software. In the future, a single ou=Groups container will hold any type of group, including mail groups. Like the ou=Groups container, the namespace under this node is flat.

• ou=nscpservers . Holds contact and configuration information for all the officially supported servers deployed within Netscape.

• ou=offices . Holds contact and location information for Netscape offices located throughout the world.

• ou=conferencerooms . Holds definitions of all the conference rooms at Netscape's main campus and at most of the other campuses. This collection of entries is used by Netscape Calendar Server to provide information about the various conference rooms and to support scheduling of the rooms. The namespace under this node is also flat.

Figure 24.2. Netscape's Directory Namespace

There are several important points to note about this namespace design. To some extent, the portion of the global directory namespace that Netscape uses at this time is unimportant because the internal directory is not available outside Netscape's firewalls. However, if Netscape should want to share this information with external business partners in the future, it will be necessary to choose a portion of the namespace that cannot conflict with namespaces in use by other businesses.

With this constraint in mind, Netscape chose to use a naming method that leverages the existing Domain Name System (DNS) infrastructure to provide a unique namespace. The top-level name of dc=netscape,dc=com is derived from Netscape's assigned domain name, netscape.com . The other option would have been to use the X.500 naming method, which is based on a country “locality “organization name hierarchy. Using this scheme, Netscape's tree would have been rooted at o=Netscape Communications Inc.,st=California,c=US , or possibly o=Netscape Communications Inc.,c=US . Netscape chose the DNS-derived names because they are shorter and do not require registration with any standards organization (other than the domain name that was registered in the early days of the commercial Internet).

After the directory suffix was chosen , Netscape's IS department needed to decide how the directory information would be structured. The final decision took into consideration the following factors:

• IS knew it would be using Netscape Directory Server software to provide the service.

• Netscape Directory Server's access control model allows for directory access decisions to be based on attribute values within entries. This means that it is not necessary to divide the directory into subtrees for the purposes of delegating administrative authority, so it is much more feasible to use a flat namespace.

• The number of entries contained in the directory would be, at most, counted in the tens of thousands. This maximum is well within the capacity of a single Netscape directory server. Therefore, it was unnecessary to partition the directory among multiple servers.

• Employees within Netscape can and do move between departments. If the organizational hierarchy were part of the naming scheme, it would be necessary to change an entry's name (move it, in other words) whenever the employee changed departments. Such a requirement has several undesirable consequences, especially when there are references in the directory to the person's entry (for example, in electronic mail groups).

• During deployment of the directory server, the primary directory-enabled applications being supported were Netscape Messaging Server, Netscape Collabra (News) Server, and Netscape Calendar Server. All these products avoid making assumptions about the structure of the directory namespace, which provides great flexibility.

A flat namespace beneath ou=People was chosen to avoid the headaches caused when people move between departments. Within the ou=People container, the uid (user ID) attribute was chosen as the naming attribute for entries. This attribute has two desirable properties. First, it must be unique anyway because the employee's electronic mail address is [e-mail] . Second, because the namespace is flat, any attempts to create a duplicate uid would be rejected by the directory server (because the new entry would have the same distinguished name [DN] as an existing entry).

One trade-off in using a flat namespace under ou=People is that straightforward directory browsing is less interesting; all employees appear in a single, flat list of names. Browsing is more useful when the namespace reflects some organizational hierarchy. Netscape directory deployers realized that multiple hierarchies were present in the directory data. For example, each employee at Netscape is associated with a particular department, and this represents one type of hierarchy present in the data. Each employee also has a manager, and the reporting hierarchy represents a different type of hierarchy.

Instead of favoring one type of hierarchy, the deployers opted to make the namespace independent of any particular hierarchy. To construct multiple alternative hierarchies, such as the reporting hierarchy, DN-valued attributes are used. For example, each employee's entry contains a manager attribute that holds the DN of the employee's manager. A directory application can use this information to support several different views of the data. For example, an application might allow a user to jump to an employee's manager or to browse the directory according to employee/manager reporting relationships.

Topology

The topology chosen for the Netscape directory deployment is very simple: The entire directory is contained in a single partition. Two considerations led to this decision:

1. The number of directory entries is small relative to the capacity of the server hardware and software (the server can handle hundreds of thousands of entries or more). Therefore, it is not necessary to partition the data to achieve sufficient capacity. All the entries in the directory are contained in each replica (replicas are discussed in the next section).

2. Netscape had a central IS organization; therefore, there was no need to support separate areas of administrative control. Any required delegation of authority can be handled via the access control mechanisms supported by the server. Therefore, delegation of authority required no partitioning.

For these reasons, a single-partition design was chosen.

Replication

The primary motivator behind Netscape's replication architecture was to provide sufficient directory capacity for its directory-enabled applications, such as messaging and calendaring. Figure 24.3 shows the overall replication architecture.

Figure 24.3. Netscape's Replication Architecture

There are several important points to note about the replication architecture:

• Each of the main directory-enabled applications (messaging, calendaring, and phone book) are co-located with a directory server running on the same host. These applications are configured to query the local directory server first and then fall back to another server if the local server is unavailable (which is extremely rare). Co-location of a directory replica with each application-specific server improves response time and protects against network outages.

• At the time of the original deployment, the Netscape Directory Server software supported only a single-master replication scheme in which one server is designated as the updatable master and all other servers are read-only. (The latest version of the Netscape Directory Server software does support multiple masters, and the directory team is now revising its replication architecture.) Because Netscape's plans called for a relatively large number of replicas (11 replicas provide service to end users and applications), it was undesirable to try to feed all the replicas from the one updatable master. Instead, the updatable master server mainly feeds a replication hub, which is then responsible for distributing the changes to most of the remaining replicas. This arrangement has the advantage that the updatable master is freed from the task of updating many replicas; it needs to update only three replicas. The result is better update performance for clients .

This particular design leverages the strengths of Netscape Directory Server ”namely, its ability to store many entries while still providing excellent performance. If your directory server software limits you to a small number of entries per partition relative to how many entries you will have, a more complicated replication architecture may be required.

On the other hand, the presence of the replication hub is a concession to the single-master nature of Netscape's Directory Server software prior to version 6. Because there is a single updatable server, it is highly desirable to keep the server's load as light as possible ”which is why a replication hub is used. If your directory server software supports multimaster replication, you may be able to eliminate the concept of a replication hub from your architecture. Replication hubs do improve the directory service's ability to distribute data widely and also help accommodate network architectures that limit the ability of applications to access the master directory servers directly.

Privacy and Security

The security design for Netscape's internal directory service deployment focused on two major issues: controlling access to directory data and protecting against certain types of security attacks.

The data contained in Netscape's internal directory is composed primarily of public information that can be viewed by any employee. However, several attributes of person entries are potentially sensitive, such as the employee home address and telephone number.

To fully understand the security issues associated with each directory attribute, Netscape's IS department developed a security matrix. For each type of object stored in the directory, the matrix describes the attributes present in that entry and the security restrictions in effect for those attributes. For example, the electronic mail address for a given employee is considered public information; it is essential for other employees to know a given employee's e-mail address. On the other hand, the employee's home address is considered sensitive information and must be protected in order to address employee privacy concerns.

During the development of this security matrix, Netscape's Legal department offered advice about which attributes might be considered sensitive information. For each attribute considered sensitive, a policy was developed describing who may view and update it. Table 24.2 shows a portion of the final security matrix.

The update policy also allows an individual employee to decide whether certain information should be published in the directory at all. For example, the authoritative source for the employee's home telephone number is the PeopleSoft database. Unlike most of the other directory attributes, the home phone number is not automatically synchronized from PeopleSoft to the directory. Instead, an employee must place his own home phone number in the directory if he wants it there (the same policy is used for home postal address as well). This kind of approach places complete control of sensitive information in the hands of the employee.

Another part of Netscape's directory security design involved protecting the directory from several types of security attacks. Because Netscape's internal directory is used only by employees and contractors, certain assumptions make it unnecessary to protect against some types of attacks. Employees are trusted to conform to company policy, so disciplinary action can be levied against an employee who perpetrates a directory attack. Such attacks (of which there have been none to date) include denial-of-service attacks and impersonation attacks.

Table 24.2. An Excerpt from the Netscape Security Matrix

Attribute Type	Sensitivity	Readable by	Updatable by
cn	Low	Everyone	PeopleSoft synchronization process
homeTelephoneNumber	High	Everyone	Self (not automatically placed in the directory service by the PeopleSoft synchronization process)
jpegPhoto	High	Self, campus security personnel	Badging system (run by security personnel)

Nevertheless, other precautions need to be taken because Netscape sometimes uses leased lines provided by a third party. Netscape does not control the physical security of those lines; therefore, unencrypted data cannot be guaranteed safe from eavesdropping. The following precautions are in place:

• Application and directory servers are physically secured in machine rooms where they may be accessed only by operations staff and security personnel. This precaution provides a level of protection against theft or physical compromise of the servers (for example, breaking in by rebooting a server and starting a privileged shell).

• Login to directory and application server machines may be accomplished only via the Secure Shell (SSH) protocol. This precaution prevents network eavesdroppers from intercepting communication from a system administrator to a server.

• For the same reason, an administrator's workstation must connect to the Netscape administration server and the directory server over encrypted Secure Sockets Layer (SSL) sessions (either HTTP-over-SSL or LDAP-over-SSL). This precaution ensures that administrative work is not susceptible to eavesdropping.

• SSL is used to encrypt all replication updates flowing from the master server to the replication hub and from the replication hub to each consumer server. This precaution protects the directory data (especially sensitive user data) from eavesdropping and ensures that the data is not modified in transit. This was especially important for updates that went to a directory replica located in one of Netscape's European offices because the network connection was a leased line owned and operated by a third-party network provider.

• All directory servers support LDAP-over-SSL (LDAPS) in case a particular employee wants to communicate over an encrypted connection. The servers support standard LDAP as well, of course.

In summary, the security architecture for the directory service and the data it contains are tuned to Netscape's particular business requirements and culture. As business requirements change, the security architecture is reviewed and updated as necessary.