Analyzing and Reducing Costs Checklist

Understanding and Deploying LDAP Directory Services > 25. Case Study: A Large Multinational Enterprise > Directory Service Design

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012003007237207190210112236

Directory Service Design

The 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.

Needs

When 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:

  • Netscape Messaging Server (electronic mail transfer and delivery)

  • A variety of electronic mail clients (used by end users to manage their email)

  • Netscape Enterprise Server (used to publish Web documents and support custom applications)

  • Lotus Notes (used for group discussions)

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 :

  • Publish a directory service requirements document (within 1 month).

  • Complete and publish the initial directory design (within 3 months).

  • Complete a directory pilot involving at least two regions of HugeCo (within 8 months).

  • Deploy a production-quality directory service used for phonebook lookups, email routing, and at least one important Web-based application (within 18 months).

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.

Data

As 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:

  • Data that is shared by more than one application should be stored in the directory service.

  • The authoritative source for each data element stored in the directory must be defined.

  • Data that is extremely sensitive or private should not be stored in the directory service unless there is an operational reason to do so. This kind of data includes payroll and employee benefit information.

  • All legal requirements, including national and regional privacy laws in effect where HugeCo operates, must be followed.

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.

Schema

To 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

  • hcEmployeeRole , to store the list of roles described earlier.

  • hcBuildingNumber , to store a number that uniquely identifies the building where an employee works.

  • hcBuildingFloor , to store the floor or building level where an employee works.

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 class

object 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.

Namespace

The 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 entry

dn: 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 entry

A 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.

Topology

The 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.

Replication

The 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.

20-20 Hindsight: The Need for Better HA Support

HugeCo's solution for HA is not ideal. Switching from the master server to the hot standby master is a manual process that must be done by a systems administrator. HA software and hardware solutions available from leading vendors such as Sun Microsystems automate the switch to a hot standby server. Unfortunately, most directory server vendors do not yet support these HA solutions.

In addition, the hot standby machine is a relatively expensive piece of hardware that sits idle nearly all the time. It would be more cost-effective if the hot standby server could handle some of the directory service load even while the master server functions normally. As soon as multimaster replication features are available in the directory service software itself, HugeCo plans to turn the hot standby servers into read-write replicas that are operational all the time .

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.

20-20 Hindsight: Awash in Replication Agreements

As HugeCo moved beyond the directory pilot and rolled out its production service worldwide, it found that setting up the large number of server-to-server replication agreements was a large chore. Now that the servers are set up, maintenance of the replicated servers is fairly easy, but there are still a lot of replication connections to monitor. For example, each of the five replication servers paired with a master server must supply its four peers, resulting in a total of 20 replication agreements. To reduce the number of replication agreements needed, a new design that includes one or more replication hubs is being considered . As shown in Figure 25.8, a simple star topology can be used to replicate data across five servers ”requiring only 10 agreements.

Figure 25.8 A proposed replication topology.

Privacy and Security

HugeCo 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.

20-20 Hindsight: Giving Individuals Greater Control over Access to Their Personal Information

After the HugeCo team rolled out its production directory service, it discovered that employees wanted finer control over the access granted to their personal information. The most common request was for home addresses and phone numbers to be accessible to more than just a person's manager .

To meet legal requirements, and because not all employees want to share their home information, a small redesign is under way to allow each employee to choose whether his or her home information is readable by everyone. This option will be provided by defining access control rules that allow anonymous access to the homePhone and homePostalAddress attributes if a Boolean attribute called within a person's hcHomeInfoIsPublic entry is set to TRUE . The phonebook front end is being altered to provide a "Home Information Is Public" check box that employees can toggle to change the value of the hcHomeInfoIsPublic attribute, granting or denying anonymous access if they so desire .



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

Index terms contained in this section

attributes
          hugeCoPerson 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.



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