Directory Service Design

   

The first phase in HugeCo's directory service venture was to analyze the company's needs and design the service itself. This task was accomplished over 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 that 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 goodwill and support it generated helped the directory deployment process immensely. Having the CIO's support lowered the political barriers that occasionally threatened to block progress of the design and deployment of HugeCo's directory service.

Needs

When HugeCo's senior IS managers formed the directory design team, they clearly spelled out the reasons for creating the directory. The ready availability of this information, along with 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:

  • Sun ONE Messaging Server (used for e-mail transfer and delivery)

  • A variety of e-mail clients (used by end users to manage their e-mail)

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

  • Netegrity SiteMinder (used to control access to some custom applications)

  • Lotus Notes (used for group discussions)

This list is in order of priority, although the explosion of Web-based applications that was under way made Netscape Enterprise Server and Netegrity SiteMinder increasingly important. Integration of the new LDAP directory service with Lotus Notes was a relatively low priority because of the small user base of Notes (limited to HugeCo's executive staff). In contrast, almost all of HugeCo's professional employees use e-mail 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 phone book 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 contact information or resetting a password.

Because of the wide geographical 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, 7 days a week. The IS staff was already required to provide similar levels of service for most of the shared network infrastructure and important applications such as e-mail.

The design team also took time to develop a directory project plan. This plan included several goals, each with an associated target date:

  • 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 6 months).

  • Deploy a production-quality directory service used for phone book lookups, e-mail routing, and at least one important Web-based application (within 12 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 tenets of the statement included the following points:

  • Data 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.

  • Extremely sensitive or private data 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 country 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 Netegrity SiteMinder role-based access control system used by some of the newest applications was adopted.

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 the person is 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. Because Netegrity SiteMinder itself uses LDAP directories and can pass custom attributes along to applications, the role information can be used by SiteMinder-based applications as well as other 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 7, 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 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 multinational makeup of HugeCo. Although most official communication is in English, most of the employees at sites located in non-English-speaking countries communicate internally using their 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 data 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 best to 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. Figure 25.2 shows some of the LDAP object classes selected for use in the HugeCo directory.

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 from RFC 2798 was subclassed to create a hugeCoPerson object class. The first three custom attributes defined as part of the hugeCoPerson class were

  1. hugeCoEmployeeRole , to store the list of roles described earlier

  2. hugeCoBuildingNumber , to store a number that uniquely identifies the building where an employee works

  3. hugeCoBuildingFloor , to store the floor or building level where an employee works

Listing 25.1 shows the definition of the hugeCoPerson object class.

Listing 25.1 The hugeCoPerson Object Class
 (  HUGECOPERSON-OID  NAME 'hugeCoPerson'      DESC 'HugeCo person object class'      SUP inetOrgPerson      MAY ( hugeCoEmployeeRole $ hugeCoBuildingNumber $ hugeCoBuildingFloor ) ) 

HUGECOPERSON-OID must be replaced by a real OID (one was assigned by the HugeCo directory deployment team). Subclassing a standard LDAP object class meant that maximum compatibility with existing directory-enabled applications could be maintained , and company-specific extensions could be made cleanly and easily in the future.

For the routing of e-mail, the inetMailUser auxiliary object class that is recommended by Sun for use with its messaging server was the natural choice. For e-mail and access control groups, the standard groupOfNames object class was used with the inetMailGroup auxiliary class added to e-mail-enable entries as needed.

A new structural object class called hugeCoRole was created to allow the entire list of available roles to be stored as a set of directory entries. Listing 25.2 shows the design of the hugeCoRole object class.

Listing 25.2 The hugeCoRole Object Class
 (  HUGECOROLE-OID  NAME 'hugeCoRole'      DESC 'HugeCo role object class'      SUP top      STRUCTURAL      MAY description      MUST cn  ) 

The cn attribute is used to hold the name of the role itself. HUGECOROLE-OID must be replaced by a real OID (one was assigned by the HugeCo directory deployment team). Listing 25.3 shows a sample role entry.

Listing 25.3 A Sample hugeCoRole Entry
 dn: cn=helpDesk,ou=Roles,ou=Global,dc=hugeco,dc=com objectclass: top objectclass: hugeCoRole 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. Although some directory server products support a roles feature, to be as vendor-neutral as possible HugeCo chose to use its own schema for roles.

To accommodate international data, the language attribute subtypes (as defined in RFC 2596) 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 that have values. This practice provides maximum compatibility with directory-enabled applications that cannot handle Unicode data.

Namespace

The HugeCo team made an early decision to follow a domain component ( dc ) naming scheme. Using this scheme allowed the team to leverage the existing Domain Name System (DNS) names for the top part of the namespace. The 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.

Figure 25.3 shows HugeCo's initial directory namespace design. The small triangle shown beneath each node in the figure represents the subtree that exists below the node.

Figure 25.3. The Initial Design of HugeCo's Directory Namespace

Splitting the directory tree along DNS subdomain lines produced a useful hierarchy of directory entries. This scheme fit well with the way e-mail accounts are managed within HugeCo. It allowed different access control to be placed at the top of each dc container, enabling 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 was the complexity of managing and setting up replication among 11 directory partitions. The HugeCo team decided to revise the namespace design and separate the tree along regional lines instead.

Figure 25.4 shows the final, revised namespace design. In the final design, one locality entry is used to represent each region. The relative distinguished name (RDN) of these entries is formed from the L (locality) attribute. Listing 25.4 shows the entry for the Asia Pacific region.

Listing 25.4 A Sample HugeCo locality Entry
 dn: L=Asia Pacific,dc=hugeco,dc=com objectclass: top objectclass: locality L: Asia Pacific description: includes all sites in Japan and Australia 
Figure 25.4. The Final Design of HugeCo's Directory Namespace

There are three consistently named subtrees under each of the four locality entries: ou=People , ou=Groups , and ou=Resources , as the Latin America node in Figure 25.4 illustrates. The namespace is flat under each of these containers. An 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, access control rules that refer to values stored in specific directory entries rather than ones that refer to the structure of the tree provide for delegation of authority. For example, a departmental directory administrator group can be granted authority over its own employees' directory information by creation of 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 RDNs of all people entries. Listing 25.5 shows a typical employee entry.

Listing 25.5 A Sample hugeCoPerson Entry
 dn: employeeNumber=12397,ou=People,L=North America,dc=hugeco,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: hugeCoPerson objectclass: inetMailUser cn: Babs Jensen cn: B Jensen sn: Jensen employeeNumber: 12397 uid: babs telephoneNumber: +1 810 555 1234 roomNumber: 42 manager: employeeNumber=9837,ou=People,L=North America,dc=hugeco,dc=com mail: babs@hugeco.com mailhost: mail-1.manufacture.hugeco.com mailQuota: 25000000 hugeCoBuildingNumber: 747 hugeCoBuildingFloor: 3 hugeCoRole: lineManager ... 

As we have seen already, the four location entries are named with the L (locality) attribute. The cn attribute is used to form the RDNs of all other entries ”for example, groups and roles.

Topology

The HugeCo IS organization's general strategy for managing important, shared services such as e-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 network segment as the application. Because HugeCo was already leaning toward choosing directory server software that can support more than one million entries in one server database, 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 where updates are made by LDAP clients. To avoid introducing any single points of failure, the HugeCo designers chose to use directory server software with multimaster replication capabilities to reduce the risk of total failure. The master servers are deployed in pairs, with one pair in each region, except for the North America region, where a second pair is deployed to hold the non-region-specific ou=Global subtree. Data for each region is mastered within that region only. Figure 25.5 shows the five pairs and the data held by each server.

Figure 25.5. HugeCo's Paired Master Servers

Replication

The main role of replication in the HugeCo design is to allow increased directory search and read capacity to be provided in an incremental way. To provide adequate capacity, all of HugeCo's directory data is copied to as many replicas as necessary. In addition to the paired read/write master servers described in the previous section, a read-only replica is located near each important directory-enabled application, such as a large mail server, a busy phone book service, or a Web-enabled workflow application.

HugeCo chose a two-tiered replication scheme in which each pair of master servers supplies two replicator servers, each of which supplies all the other replicas. Figure 25.6 shows the details for this two-tiered replication schema for a sample region.

Figure 25.6. HugeCo's 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 approximately half the update traffic for the entries it masters, each master server needs to supply only two replicator servers. Each of the replicator servers holds a complete copy of the HugeCo directory tree, which is kept up-to-date by the master servers.

Because many directory server products require that the unit of replication be defined as an entire subtree, the topmost entry in the HugeCo directory namespace (the dc=hugeco,dc=com entry) cannot 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 easy, but there are still many replication connections to monitor. For example, each of HugeCo's 10 replicator servers must supply all the other replicators, with the exception of the replicator within its own region. That means that it each of the 10 replicator servers must supply the 8 peers located in the other regions, resulting in a total of 80 replication agreements (one agreement is needed in each direction of replication).

To reduce the number of replication agreements needed, a new design that includes some central replication hubs is being considered . As shown in Figure 25.7, a simple star topology can be used to replicate data across all regions while requiring only 20 agreements. To avoid creating a single point of failure, a second central replication hub will need to be introduced. Replication agreements between the pair of replicator servers within each region could be set up, and then an agreement between each regional replicator and one of the central replication hub servers could be established.

Figure 25.7. Future 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 HugeCo offices are connected via IPsec-based 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.8).

Figure 25.8. The VPN Used to Connect Small Sites

The VPN encryption technology is believed to be uncrackable. To be safe, however, 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 e-mail) is used by employees at small sites to request updates to the directory data. These change requests are handled by directory services data administrators located in the IS department, who screen the requests carefully .

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 Transport Layer Security (TLS) channels. Second, conservative size and time limits were specified for all directory servers to make it inconvenient to collect large numbers of entries (a process called trawling ). Searches initiated by regular users are limited to at most 200 returned entries, and a maximum of 30 seconds is spent by a directory server on each search. Higher limits are given to directory administrators and applications such as the e-mail servers.

There is also a lot of concern at HugeCo about keeping employee data private, and the CIO believes strongly in 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 telephone number. In addition, the 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 telephone 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 home information can be read by everyone. To provide this option, access control rules will be defined that allow anonymous access to the homePhone and homePostalAddress attributes if a Boolean attribute called hugeCoHomeInfoIsPublic within a person's directory entry is set to TRUE . The phone book front end is being altered to provide an Allow Everyone to See My Home Information check box that employees can toggle to change the value of the hugeCoHomeInfoIsPublic attribute, thereby granting access to other employees as they desire .

   


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

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