netigy - unified directory services white paper

7/31/2019 Netigy - Unified Directory Services White Paper

1/17

SM

Netigy Corporation100 Headquarters Drive

San Jose, CA 95134

Tel 408.953.8100

Fa x 408.526.2333

Tollfree 800.987.1400

www. n e t i g y .com

UnifiedDirectory Services

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.

D I R E C T O R Y S E R V I C E S W H I T E P A P E R

By Michael Chacon

June 2000


2/17

SM

page 2

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

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.

CONTENTS Page

Introduction 2

Directory Backgrounder 3

Directory Product Examples 9

Netigys Unified Directory Services 14

Unified Directory Services


3/17

SM

page 3U n i f i e d D i r e c t o r y S e r v i c e s

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 wasincreasing 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

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.


4/17

SM


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

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

various options regarding inheritance between object classes.

Figure 1

Illustration of a

common simple hierarchy

Level Root RDN DN

root nothing { }

Country c=us {c=us}

Organization o=netigy {c=us, o=netigy}

Common Name cn=michaelchacon {c=us, o=netigy,

cn=michaelchacon}

c=gb c=us c=ca

c=cisco c=netigy c=amazon

c= c=michaelchacon c=


5/17

SM


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

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


6/17

SM


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 UserAgent (DUA) to create queries and updates for the 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 alsocommonly 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

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

dua

duaDSP

DSP

DSP

DSP

DSA

dua

DAP

DAP

DAP

DAP

DAP

Directory

dua

application

application

DSA

DSA

DSA

DSA

Figure 2

Illustration of

the architectural

relationships between the

X.500 components


7/17

SM


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 EnabledNetworks (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 LAN-

based 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 mostlyconsidered 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

implementation and the character of LDAP.


8/17

SM


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 thedirectory 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 choosingonly 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

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.


9/17

SM


There are two basic approaches to metadirectories. In the first approach, all lower-

level 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 withthe 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 beattached 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 LDAPdirectories. This significant step brought other vendors over to the LDAP point-of-

view.

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

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.


10/17

SM


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.

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 read-

operations permitted on the Consumer Server. This is a particularly important

consideration during design as a network failure can cause considerable problems

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.

o=airius.com

ou=groupsou=people

o=airius.com

ou=groupsou=people

o=airius.com

ou=groupsou=peopleo=airius.com

ou=groupsou=people

Figure 3

Illustration of

_________________


11/17

SM


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

developed for ISPs to provide directory services for all of their customers in a similar

manner as they provide DNS service now.


12/17

SM


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

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


13/17

SM


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.

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

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

DNS

Client

LDAP Server

Domains

AD DIT

Figure 4

Locat ing domain

controllers through

DNS and then using

LDAP to interrogate the

directory service


14/17

SM


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, Netigy s 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 othersare 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?

What is the physical structure and geography of the network?


15/17

SM


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?

What would best be stored in the directory and what would best be stored in a

Relational Database?


16/17

SM


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.


17/17

Netigy Corporation

100 Headquarters Drive

S J CA

Tel 408.953.8100

Fa x 408.526.2333

8 8

www. n e t i g y . com

SM

D r i v i n g e B u s i n e s s P e r f o r m a n c e SM

U n i f i e d D i r e c t o r y S e r v i c e spage 17

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 ahighly tuned enabler for Driving eBusiness Performance

SM

.

Copyright 2000 by Netigy Corporation. All rights reserved. Netigy, the Netigy logo and Driving eBusiness Performance are servicemarks of Netigy Corporation. All other company and product names are trademarks of their respective companies.

netigy - unified directory services white paper

Documents