Enterprise Directory

Executive Summary#

The purpose of this document is to provide a high level, logical view of the centralized enterprise directory design and a strategy to develop a full directory services infrastructure.

A centralized Enterprise Directory needs to be considered a vital component of a more complete directory services strategy and not the strategy itself. A complete directory services strategy must take into account the various directories that either cannot or should not be replaced by a centralized directory, as well as address the unique needs of our e-business architectures.

The goal of the typical directory services program is to provide an overall strategy and architectural design for directory services. This will focus on enterprise needs for universal authentication as well as the consolidation and reduction of the disparate directories currently performing this function. The directory services strategy will not address authorization or Access Control, except in situations where existing applications can share the enterprise directory’s common credentials and attributes without jeopardizing performance. Business units retaining responsibility for authorization will be provided with specific guidelines to ensure that the enterprise authentication solution performs seamlessly with the authorization and access control within their independent systems.


A universal solution is critical. The longer the wait to implement it, the more difficult and expensive it will be to develop because of the number of specialized authentication Methods designed to meet application specific needs. Often larger organizations will have more than 400 authentication repositories have been identified throughout the many organizations, with more expected to be found and built. The problem will become more and more complex with the addition of each new authentication repository. Reduced signon value is determined by the reduction of these disparate directories and the utilization of the a Reduced Sign-On for the majority of applications.

Centralized Enterprise Directory#

  • Elimination of the need for each application to develop and maintain an authentication Methods, resulting in improved time to market for implementations and developments;
  • Individual business units will not have to outlay resources and time toward the development of authentication Methods;
  • Reduction in help desk calls (due to reduction in password Resets), and the improvement of administration for identity management;
  • Improved security due to improved management of Digital Identity and an authentication Methods, a reduced number of passwords and a reduced number of disparate directories. This further improves the efficiency of administration in these areas.
  • Asset management will be better integrated with provisioning opportunities through the directory services infrastructure;
  • Directory strategy provides an opportunity to centralize company policies, work procedures and enhancing cross-functional teamwork;
  • Reduction of the number of directories that need to be maintained and improve the data quality overall;
  • A universal foundation for authentication and directory services which will alleviate potential difficulties stemming from divergent processes.

eBusiness Directory#

  • Customers, employees and business partners will be able to move seamlessly between systems due to access across all media types. This should improve the customer perception by offering the ability to log onto multiple systems using a single username and password. This may result in improved service to all groups, increased loyalty to the organization, and improved reputation. Without a directory services/authentication strategy (as well as subsequent authorization improvements), customers may become frustrated and do business with another source.
  • Improving authentication improves the perceived security of our customer, employee and partner systems. Improvements will reduce complexity for users by eliminating the need to recall multiple passwords, thus circumventing many log-in difficulties;
  • Provides the opportunity to share common customer data from a single source across the enterprise, easing customer profiling efforts.

Identity Management Architecture#

  • Identity Management Architecture services will provide the ability to automatically synchronize data between the disparate directories at WILLEKE.COM. WILLEKE.COM will have the ability to choose the directories to consolidate, collapse, or leave alone during the migration phases since the use of metadirectory technologies will create a common set of data. It will never be practical or cost-effective to move the organization to a single directory for all authentication, but metadirectory services allow us to realize the full value of this infrastructure.
  • The metadirectory design will allow for a more streamlined process between business entities with improved security and performance. This will allow our central process and controls to be managed from a central, secure environment.

Enterprise Directory Services, the Current State#

Most enterprises are currently plagued by an excessive number of authentication databases. As a result, employees and customers must utilize a variety of signon procedures, and security must monitor hundreds of authentication databases. As an added challenge, many of the directories do not have consistent or proactive management practices, and the disparate state of the current directory relationships offers little opportunity for synchronization. Many of these directories are considered Class B and Class C for the purpose of this document.

Issues for Consideration#

Separation of Authentication and Authorization#

The separation of authentication and authorization is not always "black and white." Authentication is primarily the identification of a user and confirmation of their identify. Authorization is the process of granting access to specific applications and data. The authorization requirements of other highly specialized applications across the company will remain under the management of their operating business units when possible. The attributes required to provide authorization are usually more application specific than those used for authentication. These attributes are very granular in nature and are usually better addressed by application specific directories. For those directories, such as NOS, where authentication and authorization are closely tied together, we will utilize metadirectory services and mapping strategies to manage these mechanisms concurrently with a single system. The decision on what attributes will be included in the directory will be under the governance of a decision-making body yet to be established (further discussed in the section: Governance).

Proliferation of Authentication Directories#

The current environment contains many disparate repositories, many of which are redundant. The Enterprise Directory Services project team has started the process of identifying these repositories. A classification definition will be circulated with the various business units to ensure a clear understanding of the varying classes of directories. For the purposes of this document, definitions consist of three classes, the unvalidated definitions of the directory classes will be used. These classes are Class A, Class B, and Class C.


A cross-company board will be formed as the vehicle to define the schema. This governing group will be made up of representatives from, but not limited to, the organization and their affiliates. This advisory board will ensure that the project effectively reduces costs and streamlines the processes associated with doing business at the Organization. Once the initial directory is developed, the role of this governing body will initiate the formation of a "Review Board." The "Review Board" will be tasked with verifying the validity of any and all proposed changes based on criteria determined jointly by the business units and will define the process/change control policies required to maintain the directory infrastructure.

Test Environment#

In an effort to provide a reliable directory services environment, the project team will construct a "test" directory environment, which will be a mirror of the production environment. This mirrors the strategic beliefs of clients who value multiple environments to ensure the most effective solutions. The purpose of this "test" environment will be to eliminate the need to move changes, such as schema, directly to the live production directory. Any change to the environment that is requested by any affiliated company, business unit, or an application area will first be moved into the "test" environment for certification. Once the change has received certification it will be scheduled and moved into the production environment through a documented process.

It is important to note the "test" environment does not replace the need for a development or lab environment. Any proposed changes should be validated in a development (or lab) before it is brought to the review board for consideration.

The test environment will be deployed to the core network and shall reside in the data center just like the production environment. This will enable an SLA to be associated with the test environment. An SLA associated with this environment is critical and must not be overlooked in order to provide a timely process for certifying changes. Overview of Directory Services Component Strategies

As mentioned previously, an enterprise directory strategy encompasses more than just an enterprise directory. The following descriptions provide a summary of the expectations for each component, with a concluding diagram illustrating the relationship between these components.

Enterprise Directory#

The purpose of the enterprise directory is to provide a centralized repository for attributes that are common across the enterprise. Authentication credentials are a perfect example of this type of attribute and will be addressed by this component of the overall architecture. Currently, an Interim Model is in production, performing the role of the enterprise directory on a limited basis. It was designed to offer an immediate solution to those business units seeking an authentication solution, reducing the proliferation of authentication directories.

eBusiness Directory#

The eBusiness directory is essentially an enterprise directory that faces externally and services a different customer base. Due to the inherent similarities of the B2B and B2C spaces, the same requirements and recommendations are applicable to both. Further investigation will determine how closely tied this component will be to the enterprise directory.

Metadirectory Services#

It is very likely metadirectory technologies will need to be used in roles that will change and evolve throughout the life of this initiative. Metadirectory services should not be viewed as a product. This technology needs to be viewed only as a means of exchanging and/or synchronizing data between directories that otherwise could not “talk” to one another. As mentioned previously, the metadirectory will allow for more streamlined processes between business entities with improved security, and eventually, improved performance over the current disparate directory state.

More Information#

There might be more information for this subject on one of the following: