A Piloting Road Map

Understanding and Deploying LDAP Directory Services > 23. Case Study: Netscape Communications Corporation > Directory Service Design

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012003013057135116112163138

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 needs were driven by two factors: 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 is in contrast to the decentralized support methods that will be described in Chapter 25.)

Despite this centralization, minor political problems arose when the directory service was being deployed. Obtaining a synchronization file with all full-time employees, contractors, temporary employees, and contingent employees proved difficult, and the issue had to be escalated to senior management. When the synchronization file was obtained, IS staff needed to spend a significant amount of time connecting existing IS work processes to the directory. This required some modifications to existing HR database tables and associated user interfaces.

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 developing the directory server software (the Netscape Directory Server) were literally next door. This 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, IS still provides an ongoing directory pilot that continually feeds back useful information to Engineering, ultimately resulting in a higher-quality , more functional product.

One of the primary drivers for the directory deployment was the support of Netscape's SuiteSpot family of directory-enabled products, including Netscape Messaging Server (electronic mail), Netscape Collabra Server (internal discussion groups), Netscape Enterprise Server (internal Web publishing), Netscape Certificate Server (for public-key certificates), and Netscape Calendar Server (for workgroup scheduling). Each of these products is directory-enabled and can utilize the directory for user and group management and access control. Additionally, employees have become very dependent on the Netscape Phone Book ”an internally developed application that allows quick and easy lookup of contact information and location information for people and meeting rooms.

The directory is also used for IS-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 Windows NT accounts, assign telephone numbers , add the employee to the security/badging database, allocate a network port, and add the employee to certain companywide , divisionwide, and workgroup-specific mailing lists.

Early in the design process, 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 in the following list:

  • 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 "Leveraging the Directory Service" section 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.

Additionally, 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 IS organization began by developing a conceptual framework for understanding the directory, external data sources, and external users of the data. This framework is pictured in Figure 23.1.

Figure 23.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. We'll describe the process that synchronizes data between the directory and other data sources in the "Maintaining Data" section of this chapter.

Data is collected from the authoritative data sources and placed into the directory. 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.

In some cases, the directory itself is considered authoritative for certain data elements such as email addresses. For these data elements, the directory functions simultaneously as a data owner and the central repository.

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

As soon as the fundamental data model had been developed, IS refined the data plan further by establishing the following basic guidelines for deciding whether 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 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 using the directory as a relational database.

  • If the directory data can facilitate location independence.   It is a completely valid and desirable use of the directory to store user preferences.

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. A portion of that inventory is shown in Table 23.1.

Table  23.1. A portion of the data element inventory
Attribute Contents Attribute Name Authoritative Source Consumers
Email address mail Directory Messaging server Phone Book application Communicator address book
Business telephone number telephoneNumber PBX Phone Book application Communicator address book
Employee's manager manager PeopleSoft Phone Book application
Employee Photo jpegPhoto Facility Access Security photograph (badging)

Finally, a set of synchronization procedures were developed that propagate changes from the external authoritative data sources into the directory. These synchronization procedures were designed to capture changed data in the external authoritative data source and apply updates to the directory.

Schema

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

  • Schemas packaged with the directory-enabled applications, such as the Netscape Calendar Server, Netscape Messaging Server, and Netscape

  • POSIX schemas, 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 propagated to the company's UNIX systems.

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

The custom schema definitions were added 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 23.1.

Listing 23.1 The nscpPerson object class

objectclass nscpPerson allows nscpBadgeImage, nscpPersonExpDate, nscpCurContactInfo, nscpBuildingNum, nscpBuildingLev, nscpHarold,

This object class contains only the Netscape-specific attributes. It is intended that entries in the directory that describe people are of object classes inetOrgPerson and nscpPerson . This allows the entry to contain any of the attributes allowed by either the inetOrgPerson or nscpPerson object classes. 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 Netscape 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 work day.

  • 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. This 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 an employee works on.

  • 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 some other attribute that holds the employee's legal name. (One of the IS directory designers goes by a different name than his legal name, which happens to be Harold, in case you were wondering about the name of this attribute.)

Namespace

Netscape's directory namespace is shown in Figure 23.2.

Figure 23.2 Netscape directory namespace.

The organizational units in Netscape's directory namespace contain the following data:

  • ou=People ” holds information on 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=device ” will hold information about various network-accessible devices such as printers (not currently used). IP address, MAC address, owner, serial number, and other information will be recorded for each device.

  • ou=pseudoaccounts ” holds definitions of various directory identities used for special purposes. For example, when one directory server needs to authenticate to another directory server, it uses one of these identities. This namespace is flat.

  • ou=mailGroups ” holds group definitions used for routing electronic mail to groups of employees and external email 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, there will be a single ou=Groups container that holds any type of group, including mail groups. Like the ou=Groups container, this namespace is flat.

  • ou=nscpservers ” will hold contact and configuration information for all the various servers deployed within Netscape (not currently used).

  • 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. It is used by the Netscape Calendar Server to define the various conference rooms. This namespace is flat.

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

To accomplish this, Netscape chose to use a naming method that leverages the existing Domain Name System (DNS) infrastructure to provide a unique namespace. The top of Netscape's namespace is an entry named dc=netscape , dc=com . This name 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 registered domain name).

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

  • IS chose to use the Netscape Directory Server to provide the service (for obvious reasons).

  • The Netscape Directory Server's access control model allows for access control decisions to be based upon attribute values within entries. This means that it is not necessary to divide the directory into subtrees for the purposes of delegating administrative authority. This makes it 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 is perfectly within the capacity of a single Netscape Directory Server. Therefore, it was unnecessary to partition the directory across 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. This has a number of undesirable consequences, especially when there are references in the directory to the person's entry (for example, in electronic mail groups).

  • During the deployment of the Directory Server, the primary directory-enabled applications being supported were the Netscape Messaging Server, Netscape Collabra Server, and Netscape Calendar Server. All these products avoid making assumptions about 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 has two desirable properties. First, the uid needs to be unique anyway because the employee's electronic mail address is uid@netscape.com . 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 as an existing entry).

One trade-off in using a flat namespace under ou=People is that directory browsing is less interesting ”all employees would appear in a single, flat list of names. Browsing is more useful when the namespace reflects some organizational hierarchy. Netscape directory deployers realized that there were multiple hierarchies 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 allow a user to jump to an employee's manager or to list all the employees who report to a given manager.

Topology

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

  • The number of directory entries is small relative to the capacity of the server (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 later in the chapter).

  • Netscape maintains a central IS organization; therefore, there is no need to allow separate islands 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

Netscape uses directory replication primarily as a means of providing sufficient directory capacity for its directory-enabled applications such as messaging and calendaring. This is the primary motivator behind the replication architecture. The overall replication architecture is shown in Figure 23.3.

Figure 23.3 The Netscape IS replication architecture.

There are several important points about the replication architecture:

  • Each of the directory-enabled applications (messaging, calendaring, and compass) are colocated 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 (this situation is extremely rare). Colocation of directory and application servers improves response time and protects against network outages.

  • Netscape Directory Server uses a single-master replication scheme in which one server is designated as the updatable master and all other servers are read-only. Because a relatively large number of replicas exist (there are 11 replicas providing direct end user service), it is undesirable to try to feed all the replicas from the updatable master. Instead, the updatable master server feeds a replication master, which is then responsible for distributing the changes to the remaining replicas. This has the advantage that the updatable master is freed from the task of updating a large number of replicas; it needs to update only the replication master. This results in better update performance for clients .

This particular design leverages the strengths of the Netscape Directory Server ”namely, its ability to store a large number of entries while still providing excellent performance. If your directory server software limits you to a particular number of entries per partition, 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. Because there is a single updatable server, it is highly desirable to keep its load as light as possible ”which is why a replication hub is used. If your directory server software supports multimaster replication, your architecture can do away with the concept of a replication hub.

Privacy and Security

Security design for Netscape's internal Directory Server deployment focused on two major issues: access control on directory data and protection against attack.

The data contained in Netscape's internal directory is primarily composed of public information that can be viewed by any employee. However, several attributes of person entries are potentially sensitive in nature, 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 email address for Netscape business processes to proceed. On the other hand, the employee's home address is considered sensitive information to protect employee privacy.

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 that describes who may view and update it. A portion of the final security matrix is shown in Table 23.2.

Table  23.2. An excerpt from the Netscape security matrix
Attribute Type Sensitivity Readable By Updatable By
cn Low Everyone PeopleSoft sync process
homeTelephoneNumber High Everyone Self (not automatically placed in directory by PeopleSoft synchronization process)
jpegPhoto High Self,Security Badging system (security)personnel

Note that 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 address is the PeopleSoft database. Unlike most of the other directory attributes, the home address is not automatically synchronized from PeopleSoft to the directory. Instead, the employee may place a home address in the directory if he or she desires. This policy places complete control of certain sensitive information such as home addresses in the hands of the employee.

Another part of Netscape's directory security design involves protecting the directory from several types of assault. Because Netscape's internal directory is used only by employees and contractors, certain assumptions make it unnecessary to protect against certain types of attacks. Employees are trusted to conform to organizational 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.

Despite this, however, certain other precautions need to be taken because Netscape uses leased lines provided by a third party. Netscape does not control the physical security of these lines; therefore, data transmitted across them cannot be guaranteed safe from eavesdropping. The following precautions are in place:

  • Application and directory servers are physically secured in machine rooms that may be opened only by operations staff and security personnel. This provides a level of protection against theft or physical compromise of the physical devices (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 protocol (SSH). This prevents network eavesdroppers from intercepting communication from a system administrator to a server.

  • For the same reason, connections from a administrator's workstation to the Administration Server are done via the Hypertext Transfer Protocol over SSL (HTTPS) to provide encryption. This allows the administrator to be certain that the session is not susceptible to eavesdropping.

  • Secure sockets layer (SSL) is used to encrypt all replication updates flowing from the master server to the replication hub, and from the replication hub to any of the consumer servers. This protects the directory data (especially sensitive user data) from eavesdropping and ensures that the data isn't tampered with in transit. This is especially important for the updates to the European directory server, which traverse a leased line owned an operated by a third-party network provider.

  • All directory servers support LDAP over SSL (LDAPS) in the event that a particular employee desires that all communications with the directory take place over an encrypted connection. The servers support standard LDAP as well, of course.

In summary, Netscape's security architecture for the directory and the data it contains are tuned to the particular needs of the business.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

accuracy
         needs
                    Netscape case study
attributes
          nscpPerson object class 2nd 3rd
case studies
          Netscape Communications Corporation
                    central data repository
                    data element inventory
                    data model
                    data owners
                    namespace 2nd 3rd 4th 5th 6th
                    needs 2nd 3rd 4th 5th 6th 7th 8th 9th
                    privacy and security 2nd 3rd 4th 5th 6th 7th 8th
                    replication 2nd 3rd
                    schema 2nd 3rd 4th
                    topology
                    users
central data repository
          Netscape Communications Corp.
custom schema
          Netscape case study
data
         Netscape Communications Corp. case study
                    central repository
                    model
                    owners
directories
         case studies
                    Netscape Communications Corporation 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th 37th
HTTPS (Hypertext Transfer Protocol over SSL)
Hypertext Transfer Protocol over SSL
inventories
         data element
                    Netscape Communications Corp. case study
namespaces
          Netscape Communications Corp. case study 2nd 3rd 4th 5th 6th
                    oranizational units 2nd 3rd
needs
          Netscape Communications Corp. case study 2nd 3rd 4th 5th
                    accuracy
                    data value
                    security
                    stability
Netscape Communications Corporation
          case study
                    central data repository
                    data element inventory
                    data model
                    data owners
                    namespace 2nd 3rd 4th 5th 6th
                    needs 2nd 3rd 4th 5th 6th 7th 8th 9th
                    replication 2nd 3rd
                    schema 2nd 3rd 4th
                    security 2nd 3rd 4th 5th 6th 7th 8th
                    topology
                    users
nscpPerson object class
          Netscape schema 2nd 3rd
                    attributes 2nd 3rd
object classes
         nscpPerson
                    Netscape schema 2nd 3rd 4th 5th 6th
organizational units
          Netscape directory namespace 2nd 3rd
owners
         data
                    Netscape Communications Corp.
POSIX schema
          Netscape case study
privacy
          Netscape Communications Corp. case study 2nd 3rd 4th 5th 6th 7th
                    security matrix
replication
          Netscape Communications Corp. case study 2nd 3rd
schema
          Netscape Communications Corp. case study 2nd 3rd 4th
                    nscpPerson object class 2nd 3rd 4th 5th 6th
security
         needs
                    Netscape case study
          Netscape Communications Corp. case study 2nd 3rd 4th 5th 6th 7th
                    matrix
stability
         needs
                    Netscape case study
topologies
         Netscape Communications Corp. case study
                    single-partition design
users
          Netscape Communications Corp. case study
value
         needs
                    Netscape case study

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net