White Paper

SM

D I R E C T O RY S E RV I C E S W H I T E PA P E R
By Michael Chacon June 2000

Unified Directory Services

Netigy Corporation 100 Headquarters Drive San Jose, CA 95134 408.953.8100 408.526.2333 To l l f r e e 800.987.1400
Te l Fa x

www. n e t i g y . com

Legal Notice: Neither Netigy Corporation nor any of its employees and agents: (1) Makes any warranty or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, process, method, or policy contained herein; or (2) represents that its use would not infringe any privately owned rights, including, but not limited to, patents, trademarks, or copyrights.

N e t i g y

page

Unified Directory Services

C o r p o r a t i o n

CONTENTS
Introduction Directory Backgrounder Directory Product Examples

Page 2 3 9

Introduction Unified Directory Services are critical for any organization planning to take advantage of the economic efficiencies realized by integrating user and configuration information of existing distributed computing systems. Netigys Unified Directory Services go beyond the products available in the marketplace today and provide four major service components: Measurement/Discovery, Planning, Design and Implementation. This approach permits clear demarcation milestones for measurement and re-evaluation purposes. Each Unified Directory Services component is a discrete Netigy service that delivers a standalone document that can be used as an objective starting point for the next phase. Measurement /Discovery: It is important to determine the number, logical and physical locations, dependencies, and available APIs of the existing directory data stores in the current environment. Each existing directory has a purpose and its role in the information system must be evaluated for proper integration into the design process. Planning: There are many approaches to a directory design. Netigy has specialization experts from all areas of information system practices, ranging from the physical layer to security, application performance and business process planning. As a team, Netigy works with customer experts to consider all of the relevant elements to be considered in the design of the directory to produce a measurable return on investment. Design: Building upon the key elements relevant to an organization, Netigy creates a detailed design document that is used as the blueprint for deployment. The document includes namespace standards, schema, data structure, replication patterns, Public Key Infrastructure (PKI) integration, white and yellow pages publishing, and the integration of client authentication for the applications/services available on the network. Implementation: Abiding by the design document, Netigy will evaluate and recommend directory products to meet the written criteria and develop a representative network pilot to substantiate the design specifications. Incorporating new design characteristics determined from the pilot, Netigy uses professional project management methodologies to ensure a rapid and non-intrusive deployment of the directory. With directories rapidly becoming such a vital element of todays eInfrastructures, it is

Netigys Unified Directory Services 14

SM

critical they are understood within their architectural framework and foundational development. Understanding how the technology has matured provides clarity for its future direction and how it can be used productively.

page

Unified Directory Services

N e t i g y C o r p o r a t i o n

Directory Backgrounder The median number of directories for many large organizations is well over one hundred different data stores. This may seem too large a number until you consider the many different places a user, or administrator, must add information in order to run or configure an application. Its clear that a comprehensive and unified directory service can significantly reduce costs and increase administrative efficiencies. Before determining how a directory can best solve business and technical problems, it is important to understand the background of the technologies that have inspired todays current mainstream directory products. The X.500 Standard The origin of a standards-based interoperable directory was realized in 1988 when X.500 was internationally ratified by the CCITT, now called the International Telecommunications Union (ITU). It was updated again in 1993 and in 1997 in concert with the International Standards Organization (ISO). While this work is still the basis of the standard that vendors prefer, few fully comply with it in their products. As a result, and to fully understand the present and future state of directory services, one must begin with the X.500 standard the basis for all of the most important directory service products that have since followed. Even before 1988, it was apparent that the interconnection of computers was increasing at a rapid pace and keeping track of the resources and people associated with each system was an exponential problem. The best example of this was the telephone directory, which is still often used as an example of a global directory. However, there are limitations with the phone directory model. One of the most common limitations is the need to know the name of the person you are trying to match to a number, and generally one must dial into the particular area where the person lives to check with a local directory. Today there is still no complete global phone directory that can be searched to obtain a number for a particular person. The development of the X.500 standard was designed to bypass the phone directory limitations, which are even greater for networks because there are multiple types of resources to locate beyond individual persons. X.500 is not a product. It is a standard that describes a collection of components which work together to manipulate a logical database of information about a set of objects in the real world. Its initial practical impetus was to provide a directory for the X.400 messaging standard that was developed to standardize all the e-mail accounts that proliferated with the rapidly growing internetwork. However, it greatly expanded
SM

to include many other objects. There are some that even see X.500 as the method to uniquely identify every object in the world, let alone those that exist on a network.

page

Unified Directory Services

N e t i g y C o r p o r a t i o n

At the core of the X.500 model is a distributed database, which can contain useful information about an object such as its characteristics and, most importantly, its location on the network. These are called attributes. The users of the directory, including people and computer programs, can read or modify the information, or parts of it, subject to having permission to do so. The X.500 term for the entire distributed database is the Directory Information Base (DIB) and its distributed components are Directory System Agents (DSA). The DIB is a data store, which contains the familiar tree-like hierarchical structure called the Directory Information Tree (DIT). Each entry in the DIT structure consists of one or more nodes that are called DSA Specific Entries (DSE). A DSE with no subsequent entries, or child entries, is called a leaf entry, and a DSE with a child is called a non-leaf-node. The name for each of these entries comprises the Relative Distinguished Name (RDN) for that entry. The complete related sequence of RDNs of the entry from the root to the DSE in question is the Distinguished Name (DN), which theoretically uniquely identifies the entry throughout all time and space.

Figure 1 Illustration of a common simple hierarchy

Level root Country Organization Common Name

Root

RDN nothing

DN { } {c=us} {c=us, o=netigy} {c=us, o=netigy, cn=michaelchacon}

c=gb c=us c=ca

c=us o=netigy cn=michaelchacon

c=cisco c=netigy c=amazon

c= c=michaelchacon c=

The objects shown in Figure 1 are simple names. However, X.500 allows for many different types of objects in the directory. These are represented by an attribute called an object class that contains other mandatory attributes, which define its character. These object classes can be used as building blocks to create new object classes down through the hierarchy. For example, a class object may be a person containing the attributes of name, address and phone number. You may then create the object class of a remote person, which is a sub-class of the person with the additional attributes of cellular phone and e-mail address. These attributes of the person are passed down to the object class of the remote person through what is called inheritance. This is one of the most powerful features of any directory service. However, it can also be one of the most problematic when it comes to designing a particular directory because of the
SM

various options regarding inheritance between object classes.

page

Unified Directory Services

N e t i g y C o r p o r a t i o n

X.500 is not a product. It is a standard that describes a collection of components, which work together to manipulate a logical database of information about a set of objects in the real world. Figure 1also demonstrates one of the most compelling features of the X.500 standard namely, the distribution of the DIT across data stores. We have driven right through the center of this DIT to reach the name Michael Chacon. The other branches quickly split away from the top into Great Britain and Canada. These, in turn, will split into the organizations which have become a part of the directory. Within the U.S. branch alongside Netigy is every organization in the nation that is registered in the directory. Unlike the phone directory, where the database is managed by a central office for the particular geographic area, X.500 is managed by the organization that is concerned with the leaf objects that are below their registered demarcation point. In this case that would be the Netigy non-leaf node. While the directory is represented as a single hierarchy in one location, it usually resides on many separate servers and data stores. This is very similar to the concept outlined in DNS, which is the most popular specific purpose directory used worldwide. Companies either manage their own DNS or outsource that service to an ISP. In either case, the people closest to the correct information manage each piece of the system. And, like the Internet itself, the value of the directory increases exponentially with the number of objects included in the directory. This distribution is accomplished at a technical level by the composition of the worldwide DIB of DSA components. Each DSA contains its unique portion of the DIT that it is responsible for maintaining. As the goal of X.500 is to have the entire world participate in the directory, it would be impractical to have the entire database reside on one computer. In addition, you have a better chance of accurate data flowing throughout the entire directory when the local owners of a DSA maintain the information. The two defined X.500 communication processes between DSAs are called chaining and referral. A chaining request is passed from one DSA to the next as the structure of the global hierarchical tree is transversed. Each DSA passes on a request to another DSA and waits until the result is passed back through the chain of DSAs. As this can make a directory slow, the referral method is used to increase speed. With this method a DSA responds to a request with the names and addresses of the DSAs that would have otherwise been chained. These methods are also similar to the conceptual methods DNS uses to return hostname-to-IP mappings.
SM

The 1988 version of X.500 did not deal with replication issues. In the 1992 version, replication was designed to use the master-slave database model whereby only the master copy is written to, and all changes are pushed out to, the slave copies. As a

page

Unified Directory Services

N e t i g y C o r p o r a t i o n

better model for data integrity, this method was chosen over the multiple master model which, by its nature, is very complex. The mechanism that DSAs use to communicate with each other is called the Directory System Protocol (DSP). Each DSA has an interface called an Access Point that DSP uses to communicate between DSAs. The protocol contains the operations and evaluation processes to complete the chaining operation. DSP is very similar in function to Directory Access Protocol (DAP), the precursor to Lightweight DAP (LDAP), which will be discussed later. The difference between DAP and DSP is that DSP controls the chaining operations and is dedicated to communicating between DSAs, while DAP is the protocol used by the clients to communicate with the DSAs. Clients use a Directory User Agent (DUA) to create queries and updates for the directory.

dua
DAP DSP DSA DSA DSP DSP DSA DAP DSA DAP DSP DSA DAP

application

Figure 2 Illustration of the architectural relationships between the X.500 components

dua

dua
application

DAP

dua

Directory
Security is provided in the X.500 standard in two ways. Overall access to objects in the directory is managed by access control lists (ACL), a standard practice in computing. However, each vendor implements ACLs differently. The other flavor comes into play while providing access at the edge of the directory. One is simple authentication, which is essentially a password-based system. The other, which is gaining more acceptance with all types of system access, is the cryptographic public/private key method known as X.509 certificates. The directory is also commonly the repository of the individual X.509 certificates for the users. This brings up an implementation problem for true X.500 directories. The original standard called for DAP to be built upon the OSI protocol, which was designed to replace all the other protocols such as XNS, IPX, and TCP/IP. Surprisingly, OSI was once thought to be the protocol of the future. At one point the government was going to mandate all transactions with its agencies only over OSI. However, the OSI protocol
SM

proved too resource-intensive and it fell away from mainstream use, at least in the United States. Most of the functionality that was designed for OSI is finding its way

page

Unified Directory Services

N e t i g y C o r p o r a t i o n

into IPv6. If you are planning to investigate a true X.500 directory for deployment, you will want to be certain that it supports TCP/IP through RFC-1277, which describes IP address support over non-OSI lower layers. X.500 products that support this will certainly note it in their informational literature. If you are interested in pure X.500 products, a good place to begin a search is in the informational RFC-2116, a catalog of existing X.500 implementations. As applications become more sophisticated, they are making greater demands upon the directory and bringing to the forefront such concepts as policy-based networks (PBN), Directory Enabled Networks (DEN) and quality of service (QoS). X.500 was intended to create a global service built upon independently managed and distributed DSAs. The Internet X.500 directory project currently has about 1.5 million entries in the DIB. You can search this directory if you point your browser to http://ganges.cs.tcd.ie/ntrg/x500.html. While 1.5 million is a large number, this is obviously not keeping pace with the number of nodes on the Internet. As previously mentioned, the most immediate problem the X.500 standard tried to solve was the management of the proliferation of e-mail addresses, which is why the X.400 standard usually goes hand-in-hand with directory. As applications become more sophisticated they are making greater demands upon the directory and bringing to the forefront such concepts as policy-based networks (PBN), Directory Enabled Networks (DEN) and quality of service (QoS). Groupware, collaborative workflow and Enterprise Resource Planning (ERP) applications are demanding the services X.500 has been promising for over a decade. Unfortunately X.500, and certainly the X.500 global directory, have not come to pass. There have been many reasons cited for this lack of progress most notably is the belief that X.500 is too complex and too resource-intensive to be deployed on the majority of these mainly PC LANbased connected network nodes. Lightweight Directory Access Protocol (LDAP) The push through the X.500 impasse has found new momentum through a subset of X.500, called Lightweight Directory Access Protocol (LDAP). LDAP is mostly considered an access protocol because it was first developed as an alternative to DAP as an entry point into X.500 directories. However, it has grown to encompass a complete directory service and LDAP is now both an access protocol and a distributed directory service standard. Major directory service vendors have joined the LDAP standard as the core method to at least query their DIB. Although X.500 aficionados may protest, X.500s greatest role may ultimately be that it was responsible for the
SM

implementation and the character of LDAP.

page

Unified Directory Services

N e t i g y C o r p o r a t i o n

Essentially, LDAP supports the view that the directory is changing from one in which it is used by users and applications, to one in which the directory service holds all the information about any entity on the network. The need for directory services has grown beyond white page services of e-mail addresses and phone numbers, to broader information such as public/private keys, document formats and bandwidth allocation permissions per application. In addition, as e-commerce continues to expand throughout the economy, the yellow pages functionality of the directory service will need to expand as users search for products and information across the Internet. Essentially, LDAP supports the view that the directory is changing from one in which it is used by users and applications, to one in which the directory service holds all the information about any entity on the network. This is regardless if it is a modem, router, chip set, self-registering application, a user currently on-line, or even a transitory service. The expression the network is the computer, may be replaced with the directory is the network. LDAP solves several of the X.500 limitations that have impeded widespread implementation. One important difference is that LDAP does not require synchronous communication between servers or clients. Requests and responses may be exchanged in any order as long as every request receives a response, if required. Another widely popular characteristic of LDAP is that it is implemented over TCP instead of OSI for both client and server-to-server communication. LDAP is not a complete rework of X.500. They both support a hierarchical namespace using entries with object class attributes. One does not have to choose between LDAP or X.500, as LDAP and X.500 servers will interoperate with LDAP servers passing queries to X.500 DSAs and the results returned to LDAP clients. METADIRECTORIES Many different directory services will continue to be implemented across the Internet and within individual enterprises, which leads to the topic of metadirectories. There is no one directory. A metadirectory is basically a directory of directories an indication that the directory service challenge is not necessarily resolved by choosing only one directory to solve all problems. This is not to say that a company should not investigate these concepts and the developed products surrounding them, but instead, acknowledge that there still exist a variety of options. The metadirectory of choice will be more LDAP-oriented than X.500. There are vendors that provide metadirectories based upon Directory Server, NDS and Active Directory architectures, which illustrates that the metadirectory is a concept rather
SM

than a specific product. The metadirectory will provide a common look for the users, regardless of how many directories are providing the service in the background.

page

Unified Directory Services

N e t i g y C o r p o r a t i o n

There are two basic approaches to metadirectories. In the first approach, all lowerlevel directories replicate information to the metadirectories. Thus, the information exists in the metadirectory's own information store. One advantage of this is that requests can be fulfilled through a search of the metadirectory store without having to transverse all of the other directory services objects below it. The disadvantage is this model involves the creation of duplicate data which uses more resources, particularly when the directory attributes contain large pieces of information such as images and public/private keys for encryption. Another problem with multiple data stores is replication between the metadirectory and the individual directories. Each individual directory will still be interacting with the applications and the user that it was created for. Changes in each directory will not only have to be replicated between distributed stores within its own architecture, the data will also then have to be replicated to the metadirectory. This introduces more complexity and latency than would exist without this second layer of abstraction. A metadirectory is basically a directory of directories-and an indication that the directory service challenge is not necessarily resolved by choosing only one directory to solve all problems. The second approach is to directly map the metadirectory schema to the other directories, creating a window into all the directories from one vantage point. This eliminates the problem of duplicated information and allows new directories to be attached to the metadirectory as they are introduced into the system. Each lower directory, however, must manage access to the upper metadirectory. Directory Product Examples Following is a brief overview of several prominent directory service products and how they implement the standards discussed above. NETSCAPEs Directory Server One example of a pure LDAP directory is Netscapes Directory Server. In April 1996, Netscape brought 40 companies together, including IBM, DEC and VeriSign, to proclaim support for LDAP as the standard for accessing both X.500 and LDAP directories. This significant step brought other vendors over to the LDAP point-ofview. Netscape built their directory service with LDAP as the core protocol supporting version 2 (RFC 1777), and more recently has also encompassed LDAP version 3 (RFC 2251). It is an interesting choice for a directory because it already runs across multiple platforms, including NT, NetWare and UNIX. Netscape provides LDAP clients with
SM

an HTML interface, Communicator 4.x, as well as an SDK that someone can use to build their own LDAP client and integrate it into their enterprise applications.

page

10

Unified Directory Services

N e t i g y C o r p o r a t i o n

The Netscape Server is a communication engine that is divided into two parts. The front-end of the server, or access point, is responsible for processing LDAP queries and requests. The back-end is responsible for the database management plug-ins. This abstraction allows the customers to use the default Netscape database or, if desired, to replace it with a relational database. The default database can be run with multiple plug-in databases concurrently so the back-end can span multiple data stores while maintaining the single LDAP referred to as a Directory Tree in the Netscape directory. This was done to closely follow the standard and still differentiate from the X.500 ideal of the DIT referring to a single complete global distributed store. The Netscape directory service hierarchy is initially the same as X.500, with an additional server suffix value that overlaps the root entry specified in X.500. This permits the integration of DNS, which is used to locate the identity of the specific LDAP server and where the DN is located in a directory service server. Netscape also defines a Root Distinguished Name (RDN) which is a special entry created for Netscape Management Services. They also have defined a Base Distinguished Name (BDN), which is configured on the client. This is the beginning of the client search path and usually the root of the company directory. Therefore, the entire private directory is available for the search. This is also referred to as the Search Base, or within Communicator, as the Search Root.

o=airius.com

Figure 3 Illustration of _________________

ou=people

ou=groups o=airius.com o=airius.com ou=people ou=people o=airius.com ou=people ou=groups

ou=groups

ou=groups

Following the LDAP standard, Netscape uses the master-slave database model trading the terms master for Supplier Server and slave for Consumer Server. This model means that all changes must be made to the Supplier Server with only readoperations permitted on the Consumer Server. This is a particularly important consideration during design as a network failure can cause considerable problems
SM

during update operations. It is one of the important weaknesses in the LDAP model and another reason why other directory service providers do not fully follow the LDAP or X.500 standards.

page

11

Unified Directory Services

N e t i g y C o r p o r a t i o n

The Netscape replication process provides different methods to create availability and load balancing. The Supplier Server is always the primary source for directory service information to maintain data integrity. However, Consumer Servers can also be a source for other Consumer Servers across the network. In addition, the Consumer Server can contain portions of the database. For example, you may want to publish a portion of the directory on the Internet while protecting proprietary information. You can maintain all of the information on the Supplier Server and create a Replica Consumer Server that only contains the information you want on a Consumer Server outside of your firewall for public consumption. A Replication Agreement between the servers controls this replication process. Both Suppliers and Consumers can be the initiator of the replication process. Supplier side information is replicated when changes are made and pushed down to the Consumer Servers. Consumer initiated replication, which is configured by set intervals, is useful for controlling bandwidth consideration over slow links. Obviously, the frequency of replication should be balanced against the dynamic nature of your directory service. This is another problem area for pure LDAP implementations. Netscape directory services also offer referrals to directory service requests that are outside of the DN context, or the search base. This functionality is based upon LDAPv3 and it sends the request to a server which supports the namespace that the request is trying to search through. This is essential to support the X.500 goal of a global directory. If we cannot create a global DIT then we can create a logical and widespread DIT through referrals to other namespaces in your enterprise or even outside of your management domains. Unlike the X.500 ideal, the LDAP referral process is only as effective as the configuration of the LDAP client to locate participating namespaces. NOVELL Network Directory Services (NDS) Novells Network Directory Services (NDS) is probably the most widely-used directory service simply because of the proliferation of LANs and the number of NetWare nodes on those LANs in the marketplace. NDS was originally based upon the X.500 standard, but has moved beyond the standard instead of waiting for the standard to move forward. The NDS maturity benefit has also been a challenge in that its support for LDAP is a service that you install on each partition to support the protocol. Novells goal is to have NDS become the global directory service that the X.500 audience had failed to implement. One sign of their ambition is that the N in NDS used to stand for NetWare, and now represents Network. Another more important indication is that there are ported versions for other operating systems, including Sun Solaris, Linux, IBM AS/400 and Windows NT. The latest version of NDS was
SM

developed for ISPs to provide directory services for all of their customers in a similar manner as they provide DNS service now.

page

12

Unified Directory Services

N e t i g y C o r p o r a t i o n

NDS refers to its DSAs as partitions. As a good DSA, each partition is stored on a separate machine and they do not overlap, providing a distributed database of information for the users. All of the Partitions in an NDS-tree represent the entire directory. The partitions can be replicated, as called for in the X.500 standard, but NDS uses the multiple-master model rather than the master-slave relationship. This allows for greater local reliability in case of inter-network problems and greater availability of service to logins, as they need a writable entry to store information related to that session. NDS refers to these X.500 shadow copies as Replicas. Unlike Active Directory, Novell recommends that partitions (Domains) not span WAN links, as the replication among partition replicas is automatic and can chew up bandwidth. NDS also follows the X.500 standard through object and attribute definitions, referred to as properties in NDS, creating extensible leaf and non-leaf entry. Novell uses the terms leaf and container objects rather than the respective X.500 terms leaf and parent entry. While NDS is not an X.500 directory, it certainly contains the spirit. It cannot be considered an X.500 directory because it does not support DAP or the other protocols outlined in the standard, and relies upon proprietary protocols. NDS does support LDAP and native IP, but it is still its own cloistered system, and LDAP is provided as an add-on service. MICROSOFT Active Directory Microsoft has built Active Directory around the LDAP model with services that act as an interface to a proprietary back-end. The Active Directory is built around the concept of Domains, which have been unfairly characterized as unwieldy in previous versions of NT. It was not the domains that were actually unwieldy, but rather the horrendous non-extensible flat file database that was pawned off as a directory. The domain is only a management demarcation construct that is similar, but not exactly the same as, partitions in NetWare. Unlike NDS, each Active Directory Domain contains a complete copy of the domain database. Clients locate DCs (Domain Controllers ) through DNS and then use LDAP to interrogate the directory service as shown in Figure 4. For DNS to work with Active Directory, each DC is named using standard naming conventions such as dc1. netigy.com. The entry in the DNS contains a SRV (Service) record (RFC 2052), similar to the MX (Message Exchange) record used by the SMTP mail servers to map the name to an IP address. The client then uses LDAP to request information from the Active Directory service on the machine located through DNS. Active Directory will not work without a DNS server providing IP and name mapping functions. As with Netscape and Novell, Active Directory supports LDAP versions 2 and 3.
SM

While Active Directory uses DNS names for service locations, it uses LDAP names for the objects in the directory. This means that one of the attributes in the entry is used

page

13

Unified Directory Services

N e t i g y C o r p o r a t i o n

as the CN (Common Name) for the object. Active Directory provides a proprietary naming convention for directory service objects. An example would be // netigy.com/employee/chacon. The Active Directory name is used in the GUI, while the LDAP name is still carried across the wire. A dc= RDN convention is used in the directory so it can place the DNS name in the hierarchy, such as dc= netigy and dc=com to express the netigy.com DNS entry. Domains must have a contiguous DNS namespace to be a part of the same domain Tree. If they don't , the relationship between the trees is called a forest. Searches will then transverse the forest between the tops of the trees.

LDAP Server LDAP Server

Figure 4 Locating domain controllers through DNS and then using LDAP to interrogate the directory service

DNS

Domains AD DIT

Client
Another aspect of Active Directory outside the LDAP standard, along with NDS, is the concept of an indexed catalog to speed searches. Active Directory refers to this as the Global Catalog (GC). The GC can be used when the requestor does not know the LDAP name of an entry. Attributes alone can then be the basis of the query. The GC consists of entry attributes, which can be specified by the administrator that would most likely be used by the users. The GC spans all the trees in the Active Directory to encompass the entire forest. For example, if the only information a person has about an entry object is the first name of someone, they can then search for a name, for example, and the request will locate all like names in the GC bringing them to the user. Each like name is mapped to the complete entry in the Active Directory and the user can jump to the full entry after choosing the name they want from other indexed attributes, or simply try them all. Domains develop several issues during replication. If a domain spans a WAN link, too much traffic could cause performance problems. Active Directorys solution to this problem works with the concept of sites. A site is one or more subnets that exist
SM

among devices that share local high-speed connectivity, such as a router with Ethernet interfaces. All replication traffic is automatic within a site. Sites are connected through

page

14

Unified Directory Services

N e t i g y C o r p o r a t i o n

bridgehead servers that exist on each side of a serial interface on a router, which commonly provides slower services such as frame relay over T1 lines. The replication process between bridgehead servers can be controlled in terms of the replication frequency. In addition, intrasite communication is replicated using Active Directory proprietary processes. Netigys Unified Directory Services As discussed at the beginning of this document, Netigys Unified Directory Services are delivered as four discrete service phases. Each one is individually important, and combines with the others to systematically create an interrelated and complete approach. The key to Netigys approach is having world-class specialists that have worked on many different types of information system implementations. Together they work with your experts intimately familiar with your information systems to create a synergy that maximizes productivity and efficiency. The four discrete phases of Netigys Unified Directory Services are: Measurement / Discovery Planning Design Implementation Measurement / Discovery One of the pertinent predicators of the implementation success of any system is an accurately defined baseline from a technical, business process and user perspective. The people who use the system will ultimately determine the long-range success of the directory implementation. During this phase, structured and recorded meetings are held between the business stakeholders and sponsors of the engagement to identify expectations and uncover the driving business factors. All existing environment documents are reviewed and others are created to fully document the existing information and business environment. The essential goal of the Measurement / Discovery process is to obtain the objective answers to fundamental questions that, when appropriately organized, accurately describe the current environment. What is the organizational structure of the company?
SM

What is the physical structure and geography of the network?

page

15

Unified Directory Services

N e t i g y C o r p o r a t i o n

What operating systems and computer architectures are currently in place? What applications exist and which ones need to publish information into the directory? Where is data stored? Is it centralized, or on individual workstations? What is the skill level of the support staff? What are the business initiatives driving the directory investigation? How do the users currently interact with the information systems? Is there an internal software development team writing affected applications? Until these and other questions are answered in a systematic, written format, and agreed to by the management and users within the organization, an accurate analysis cannot be conducted. As in any other endeavor, a faulty premise will produce faulty analysis and planning. Planning Once a thorough and objective overview of the environment is achieved, it is necessary to evaluate this information within the context of what the organization is trying to accomplish. The business, as well as the technological impact of future business requirements, needs to emerge from this process. The planning process is accomplished with the input of the users and management. A clear set of expectations should result and will be used to measure both the design and implementation of the directory and the services that reply upon it. Among the questions answered are: What are the needs of the applications that will use the directory? What new applications are being considered that leverage the directory? What are the expectations of the users regarding any new functionality? What economic, organizational, and other restraints are in place that must be considered and worked within? What other new technologies interest IS management? What new business objectives are being considered that might rely upon existing or new systems? What types of information is the organization interested in storing in the directory?
SM

What would best be stored in the directory and what would best be stored in a Relational Database?

page

16

Unified Directory Services

N e t i g y C o r p o r a t i o n

What criteria is the organization going to use to prioritize conflicting objectives? Who owns the data? A professional planning process leaves the organization with a document spelling out the needs and objectives of the directory. This document will be the foundation for a design that is created with the proper expectations clearly articulated. Design Design follows the objectives and expectations of the planning document, and considers the broad, long-term picture, as well as maps the objectives to existing technologies. This means there should be a standards-based design that incorporates fundamentals such as security, availability, performance and distribution. Some of the issues covered in the design process are: Choosing specific products Data elements and relationships Schema design Version control policies Namespace design Physical topology Privacy & legal considerations Data policy guidelines Exception policies Permissions Managing dynamic information Data conversions and importation Operating systems integration Replication and synchronization The design document clarifies each planning element into a specific method for implementing each component. It matches the needs and objectives to specific technologies with detailed information.

SM

page

17

Unified Directory Services

N e t i g y C o r p o r a t i o n

Implementation Many companies rush to implementation with disastrous results. The keys to successful implementation are good planning, design, and the adherence to a professional project management methodology. The first step in the implementation process is the creation of clearly defined, and easily measurable, goals and milestones. The next step is a pilot project that follows the design document in order to validate design. While a pilot cannot cover every contingency, there are methods by which the major portions of the design can be effectively validated. Some of tasks accomplished during the implementation phase are: Review the design document Create hardware and software inventory and requisition check-off documentation Identify project team members and their specific responsibilities Identify users and components of the existing system that will be part of the pilot project Evaluate pilot results and review design document if necessary Rollout implementation according the validated design and project plan Complete documentation of system Netigy has an eProved Methodology that can ensure the effective and efficient implementation of a directory service while being as unobtrusive as possible to the day-to-day workflow of the organization. Netigy: The Worlds Premier Architect of eBusiness Infrastructure As infrastructure architects, Netigy provides consulting and professional services to help enterprise clients and service providers make a smooth and successful transition to network-based business models. With a full range of services from strategy/planning to design, implementation and measurement, Netigy ensures the underlying technology foundation from the network to the IT systems to the application environment is a highly tuned enabler for Driving eBusiness Performance .
Copyright 2000 by Netigy Corporation. All rights reserved. Netigy, the Netigy logo and Driving eBusiness Performance are service marks of Netigy Corporation. All other company and product names are trademarks of their respective companies.
SM

SM

Driving eBusiness Performance

Netigy Corporation 100 Headquarters Drive San Jose, CA 95134 408.953.8100 408.526.2333 To l l f r e e 800.987.1400
Te l Fa x

SM

www. n e t i g y . com

WO-0013 8/9/00