Understanding and Deploying LDAP Directory Services > 25. Case Study: A Large Multinational Enterprise > Directory Service Design |
Directory Service DesignThe first phase in HugeCo's directory service adventure was to analyze its needs and design the service itself. This task was accomplished over the course of four months by a team of five people from the central IS organization. An IS employee from each of the four regional IS departments was asked to participate in a weekly conference call and occasional face-to-face meetings to review the detailed directory design as it was drafted. HugeCo's chief information officer (CIO), who oversees all IS activities within the company, was involved early in the decision to develop an LDAP directory service. To bring the CIO up to speed and expose her to the short- and long- term benefits a directory would provide, the IS group arranged a private presentation and demonstration for her. An entire week was spent preparing for the meeting with the CIO, but the good will and support it generated in her helped the directory deployment process immensely. Having the CIO on board lowered the political barriers that occasionally threatened to block the progress of the design and deployment of HugeCo's directory service. NeedsWhen the directory design team was formed by HugeCo's senior IS managers, the reasons for the directory were clearly spelled out to the team. This and the fact that the overall computing environment was already well-known and documented by the central IS organization made the directory needs analysis a relatively easy step. The following applications were identified as good candidates to take advantage of a directory service immediately:
This list is in order of priority, although the explosion of Web-based applications that was underway made Netscape Enterprise Server increasingly important. Integration of the new LDAP directory service with Lotus Notes was a relatively low priority because of Notes' small user base (limited to HugeCo's executive staff). In contrast, almost all of HugeCo's professional employees use email daily. The directory design team also thought it would be cost-effective and useful to replace printed departmental employee phone lists with a Web-based phonebook application. This application could even be used by directory administrators and help desk staff to perform simple directory maintenance tasks , such as correcting an employee's information or resetting a password. Because of the wide geographic distribution of HugeCo's facilities, it was clear from the start that the directory service would need to be available to end users and applications 24 hours a day, seven days a week. The IS staff already was required to provide similar levels of service for most of the shared network infrastructure and important applications such as email. The design team also took time to develop a directory project plan. This plan included several goals, each with an associated target date. The goals were as follows :
Everyone agreed that this was an aggressive set of goals, but the team thought all of them could be achieved. The initial draft of the requirements document was created and published soon after the needs analysis stage was complete. The leader of the design team shared the goals with IS upper managers and other IS employees ”but not before padding the target dates by a few months to give the team more room to meet them. DataAs soon as the list of applications was in hand, the HugeCo design team worked with an existing data architecture team within the IS organization to craft a directory data policy statement. The core tenants of the statement included the following points:
IS quickly produced a list of data elements needed by each application. This was a relatively easy task; many of the applications supported LDAP already and therefore came with a set of well-documented data elements and schemas. For HugeCo's custom Web-based applications, a role-based access control system used by some of the newest applications was adopted and modeled in the directory. Roles at HugeCo include helpDesk , emailAdmin , systemAdmin , payrollClerk , seniorManager , lineManager , and dozens of others. The Web-based applications use a combination of the roles that a person is allowed to adopt, along with information about the department they are in, to grant or deny access to application functions. Many of the newest applications manage workflow tasks in which the appropriate flow of information is especially critical. The directory design team decided that in addition to a standard department number data element, a list of roles should be stored with each person entry in the directory service to facilitate the use of role-based access control by applications. Next , the team created a table of all the data elements that would initially need to be stored in the directory service. As recommended in Chapter 6, "Data Design," the table included a comprehensive set of characteristics for each data element. The team discovered that most of the data elements were shared by several applications and would not contain any sensitive information, which fit well within the directory data policy statement. The team also noted that many of the data elements had to accommodate data values of several different character sets and languages because of the multinationality of HugeCo. Although most official communication takes place in English, most of the sites located in non “English-speaking countries communicate internally using the native language. The final data design task was to examine an existing inventory of HugeCo's data sources. The team's goal was to determine which data elements that were to be stored in the directory were already available in existing stores. The team discovered that many of the employee- related data elements were already present in HugeCo's PeopleSoft human resources (HR) system. A series of meetings was planned with the PeopleSoft experts within the IS organization to determine how to best manage the relationship between the HR database and the directory service. SchemaTo accommodate the data elements, the HugeCo team chose to use standard schemas and schemas provided by the application vendors when available. In some cases the team members found that they needed to subclass standard schema elements to meet their needs. Some of the LDAP object classes selected for use in the HugeCo directory are shown in Figure 25.2. Figure 25.2 HugeCo object classes.To allow the storage of values for a few custom attributes in each employee entry, the standard inetOrgPerson object class was subclassed to create a hugeCoPerson object class. The first three custom attributes defined as part of the hugeCoPerson class were
By subclassing a standard LDAP object class, maximum compatibility with existing directory-enabled applications was maintained , and company-specific extensions could be made cleanly and easily in the future. For the routing of electronic mail, the mailRecipient object class defined by Netscape for use with its Messaging Server was the natural choice. For email and access control groups, the standard groupOfNames object class was used with Netscape's mailGroup auxiliary class to email-enable entries as needed. A new object class called hcRole was created to allow the entire list of available roles to be stored as a set of directory entries. The design of the hcRole object class is shown in Listing 25.1. Listing 25.1 The hcRole object classobject class objectclass hcRole superior top oid 1.2.3.4.5.6.7 required cn allowed description The cn attribute is used to hold the name of the role itself. A sample role entry is shown in Listing 25.2. Listing 25.2 A sample hcRole entry.dn: cn=helpDesk, ou=Roles, ou=Global, dc=hugeco, dc=com objectclass: top objectclass: hcRole cn: helpDesk description: people who handle questions sent to the IS help desk Storing all the available roles in the directory service allows directory-enabled administration tools and Web-based applications to easily obtain and present the complete list of roles to their users if needed. To accommodate international data, the language attribute subtypes and Unicode (UTF-8) character set specified by LDAPv3 were adopted. By convention, an ASCII-only value that is not tagged with any language is always stored for all attribute types. This provides maximum compatibility with directory-enabled applications that are not able to handle Unicode data. NamespaceThe HugeCo team made an early decision to follow a domain component ( dc ) naming scheme. This allowed them to leverage their existing Domain Name System (DNS) names for the top part of their namespace. Their top-level suffix of dc=hugeco, dc=com was simply derived from the company's existing Internet domain name ( hugeco.com ). The HugeCo design team wanted to keep the directory namespace fairly flat to reduce the overhead of managing distinguished name (DN) changes. A hierarchy was incorporated into the namespace to allow for delegation of responsibility and provide subtree roots to facilitate replication. HugeCo's initial directory namespace design is shown in Figure 25.3. Figure 25.3 The initial design of HugeCo's directory namespace.By splitting the directory tree along DNS subdomain lines, a useful hierarchy of directory entries was produced. This scheme fit well with the way electronic mail accounts are managed within HugeCo. It allowed different access control to be placed at the top of each dc container to allow for a rough mapping of authority based on departments. However, this namespace design did not mesh well with HugeCo's need to replicate its directory information in all locations. The main reason for this was the complexity of managing and setting up replication between 11 directory partitions. When revising the namespace design, the HugeCo team decided instead to separate the tree along regional lines. The final, revised namespace design is shown in Figure 25.4. Figure 25.4 The final design of HugeCo's directory namespace.In Figure 25.4, locality entries are used to represent each region. The relative distinguished name (RDN) of these entries is formed using the l (locality) attribute. The entry for the Asia Pacific region is shown in Listing 25.3. Listing 25.3 A sample hcPersonEntry entrydn: l=Asia Pacific, dc=hugeco, dc=com objectclass: top objectclass: locality l: Asia Pacific description: includes all sites in Japan and Australia There are three subtrees under each of the four locality entries: ou=People , ou=Groups , and ou=Resources . The namespace is flat under each of these containers. The ou=Global subtree rooted at the same level as the regional entries is used to store groups that are global to the entire company, along with the master list of HugeCo roles. Limiting the number of major directory partitions to only five makes replication easier to manage. In the new namespace design, delegation of authority over directory entries is accomplished by basing access control on attribute values stored in specific entries rather than on the structure of the tree. For example, a departmental directory administrator group can be granted authority over its own employees' directory information by creating an access control rule that refers to the departmentNumber attribute within each employee's entry. Every HugeCo employee and contractor is assigned a unique, nonrecycled identification (ID) number by the HR department. The directory team decided to use these ID numbers to form the RDN of all people entries. A typical employee entry is shown in Listing 25.4 Listing 25.4 . A sample hcPersonEntry entryA sample entry dn: employeeNumber=12397, ou=People, l=North America,dc=hugeco, dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: hugeCoPerson cn: Babs Jensen cn: B Jensen sn: Jensen employeeNumber: 12397 uid: babs telephoneNumber: +1 550 1234 roomNumber: 42 manager: employeeNumber=9837, ou=People, l=North America, dc=hugeco, dc=com hcBuildingNumber: 747 hcBuildingFloor: 3 hcRole: lineManager ... As we already saw, the four location entries are named using the l (locality) attribute. The cn and ou attributes are is used to form the RDN of all other entries. TopologyThe HugeCo IS organization's general strategy for managing important, widely used services such as electronic mail is to deploy a small number of relatively large server machines within each site. The company followed this same philosophy when designing its directory topology. For directory-enabled applications that have high search and read performance requirements, the design allows a directory replica to be located on the same machine or on the same network segment as the application. Because HugeCo was already leaning toward choosing directory server software that can support more than a million entries in one server partition, there was no need to partition the data across servers for scaling reasons. Partitioning along regional lines to accommodate HugeCo's replication strategy is discussed in the next section. Special thought was given to the configuration of the read-write master directory servers on which updates are applied. Because the master servers are single points of failure, the HugeCo designers wanted to use high availability (HA) hardware to reduce the risk of total failure. Each master server (there is one in each region) is paired with a hot standby master. The hot standby machines contain identical server software and are configured the same as the master server they are paired with. Each master server and its hot standby share a dual-ported RAID level 5 disk array, but they do not share any other components or network connections. The logical arrangement is shown in Figure 25.5. Figure 25.5 A master directory server with hot standby.If the master server fails for any reason, the directory server application on the hot standby machine can be quickly started to take the master's place, thereby minimizing downtime for end users and applications. ReplicationThe main goal of replication in the HugeCo design is to allow increased directory search and read capacity to be provided in an incremental way. This is accomplished by copying all of HugeCo's directory data to as many replicas as needed to provide adequate capacity. HugeCo uses a single-master configuration, in which each directory entry can be updated on only one server. Typically, a read-only replica is located near each important directory-enabled application such as a large mail server, a busy phonebook service, or a Web-enabled workflow application.
Directory data is mastered in five servers. The master servers and the data they hold are shown in Figure 25.6. Figure 25.6 HugeCo's master directory servers.One master directory server is located in each region, and one additional master server located in North America manages the directory entries that are not region-specific (the ou=Global, dc=hugeco, dc=com subtree). HugeCo chose a two-tiered replication scheme in which each master server supplies exactly one replica, which is in turn responsible for supplying all the other replicas (see Figure 25.7). Figure 25.7 A two-tiered replication scheme.The two-tiered scheme was selected to reduce the load on the master servers in an effort to maximize update performance. Aside from handling the update traffic for the entries it masters, each master server needs to supply only a single replication server. The HugeCo team plans to switch to a multimaster replication topology as soon as the feature is available from the directory server vendor. This will allow the team to increase the availability of the directory service for updates and eliminate the hot standby servers paired with each master server. Because the chosen directory server product's unit of replication must be defined as an entire subtree, the top-most entry in the HugeCo directory namespace (the dc=hugeco, dc=com entry) can not be automatically replicated. Instead, each server has its own copy of that entry, and access control rules are used to ensure that no changes are made to it.
Privacy and SecurityHugeCo generally trusts its own employees, but it is wary of outside security threats. Because no directory data is currently published outside HugeCo's corporate firewall, the threat from outsiders is minimized. However, some small sites are connected via VPNs, which originate at a local ISP, tunnel TCP/IP traffic across the Internet through an encrypted pipe, and enter HugeCo's corporate network through its Internet firewall (see Figure 25.9). Figure 25.9 The VPN used to connect small sites.Although the VPN encryption technology is thought to be nearly uncrackable, to be on the safe side directory access control was set up to disallow any changes to directory data from connections that come in through a VPN. A manual process (usually handled through email) is used by employees at VPN-connected sites to request updates of information in the directory service. Change requests are monitored and handled by directory services data administrators located in the IS department. To protect data against naive or misguided employees who might try to download large lists of employees from the directory service, two precautions were taken. First, all server-to-server replication transfers are done over 128-bit encrypted secure sockets layer (SSL) channels. Second, conservative size and time limits were specified for all directory servers to make it very difficult to collect large numbers of entries (a process called trawling ). There is also a lot of concern at HugeCo about keeping employee data private, and the CIO believes strongly in the right to personal privacy. To meet employees' privacy needs, the directory design team developed a conservative access control scheme that allows only an employee's manager to see the employee's home address and phone number. In addition, access control for groups was designed so that only the owners (maintainers) of a group can see the complete list of members.
|
Index terms contained in this sectionattributeshugeCoPerson object class case studies HugeCo data 2nd 3rd namespaces 2nd 3rd 4th 5th 6th needs 2nd 3rd 4th privacy and security 2nd 3rd 4th replication 2nd 3rd 4th schema 2nd 3rd 4th topology 2nd 3rd 4th classes object HugeCo case study 2nd configuring master servers HugeCo case study data HugeCo case study 2nd 3rd inventories roles storage table dc (domain component) schemes design HugeCo case study data 2nd 3rd namespaces 2nd 3rd 4th 5th 6th needs 2nd 3rd 4th privacy and security 2nd 3rd 4th replication 2nd 3rd 4th schema 2nd 3rd 4th topologies 2nd 3rd 4th directories case studies HugeCo 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 HA support HugeCo case study HugeCo case study data 2nd 3rd inventories roles storage table namespaces 2nd 3rd 4th 5th 6th 7th dc (domain component) schemes ID numbers partition limits sample hcPersonEntry entry 2nd 3rd 4th subtrees needs 2nd 3rd 4th privacy and security 2nd 3rd 4th SSL encrytption VPN encryption replication 2nd 3rd 4th masters servers two-tiered schemes schema 2nd 3rd 4th hcRole object class 2nd 3rd 4th hugeCoPerson object class mailRecipient object class topology 2nd 3rd 4th HA support master server configurations inventories data HugeCo case study mailRecipient object class master servers configuring HugeCo case study replication HugeCo case study namespaces HugeCo case study 2nd 3rd 4th 5th 6th 7th dc (domain component schemes) ID numbers partition limits sample hcPersonEntry entry 2nd 3rd 4th subtrees needs HugeCo case study 2nd 3rd 4th object classes HugeCo case study hugeCoPerson mailRecipient privacy HugeCo case study 2nd 3rd access control schemes user access VPN encryption replication HugeCo case study 2nd 3rd 4th master servers two-tiered schemes roles data HugeCo case study schema HugeCo case study 2nd 3rd 4th hcRole object class 2nd 3rd 4th hugeCoPerson object class mailRecipient object class security HugeCo case study 2nd 3rd 4th SSL encryption VPN encryption storage tables data HugeCo case study subtrees namespaces HugeCo case study topologies HugeCo case study 2nd 3rd 4th HA support master server configurations VPN encryption HugeCo case study |
2002, O'Reilly & Associates, Inc. |