Corporate Directories grow out of a few general needs. Most often, they are tasked to promote better resources utilization by allowing people to locate other people by their name, phone number, email address and location. In the case of Active Directory (under Windows 2000 and future Microsoft based OS's), the Single Sign On management capabilities may be leveraged first. In all cases, the ability to better utilize resources is a strong argument to build a corporate directory.

The next steps that are taken tie applications to the initial 'People Resource' information. This usually means that additional attributes to properly define roles within the corporation is needed. Without this additional information, you cannot easily tie business rules to the applications that are Directory Enabled.

Security - who owns the Directory?

The most obvious answer is usually the wrong one. Since Human Resources tracks people, you might think that they should run this service. There are many reasons that they would not and should not do it:

1. The Directory's 'people' data will need to contain everyone that people need to look up and reference. This starts with employees but also includes any contractors and often includes vendors and external contacts. The HR department only cares about employees.
2. The Directory will likely list conference rooms. The HR department doesn't want to manage these either.
3. Directory data is often used for application authentication and network security. The HR department does not deal with very many external applications and it definitely does not want to manage any networks, VPN or digital certificates. The HR department really should be focusing on HR related issues.

The Corporate Directory needs HR related data in order for it to be useful, but it will be used for many things that HR really should not be working on. The task of running the Corporate Directory typically ends up in the hands of a Network Management Group. Its not a perfect fit, however, the Network Management Group cares about how the network is operated and the applications that will be deployed across the network.

The issue is that the Directory quickly faded into the background and it becomes 'infrastructure'. Other forms of infrastructure are:

TCP/IP networks
Electricity
Water
Telecommunications
Oil & Natural Gas
Transportation
Banking
Government Services

All in all, you don't even think about them unless they suddenly stop functioning or become unavailable. The Directory becomes an infrastructure service for applications. This is rarely something that people think about when creating a Corporate Directory, however it is what happens as more an more services leverage the existence of the Directory. It only makes sense that the owners of another infrastructure that is critical to most operations (TCP/IP networks) manage the Directory Servers.

The side effect of this is that the data the ends up in a Directory comes from other groups and those groups really own that data. There is a control issue to be resolved. The technical issues are small compared to the politics of data ownership.

Infrastructure before applications

The most complex technical issue about Directory Services is keeping it highly available and highly reliable. Once a Directory starts being used, it tends to be used heavily. Because of this, any solutions must be able to scale to very high performance levels.

To make a service available and reliable, the system that provides the Directory Services needs to have a redundant copy on some other system at a different location. The redundant version of the Directory needs to be able to take over if needed. How this actually occurs is dependent on the Directory Server product that is used.

The data feeds to the Directory must be carefully planned, and the managers of the Directory will determine what they store and how it is managed. A Directory Server is not a single use application server, it may appear to be used in that way when it is initially integrated into applications, however, over time the Directory will become a central repository for a data that is related to people, but the source of data attributes will be associated with applications that are security related, and use the Directory to leverage the relationships. It will serve purposes that no one specific system will handle well, and the purposes will be associated with unrelated groups that need to share some common data.

The sooner you get to an effective and manageable Directory structure, and the more centralized you make repositories and storage in your organization, the much better off you're going to be doing business-to-business and business-to-customer transactions.

The Directory will not be the source of most of the data that it hosts. It will need to capture data that applications and people will utilize. Getting the groups that own these bits of data to share it with you may not be easy to do; groups that own data feel that they should control it and manage its access - this is contrary to how some of it will be utilized as a part of a Directory Server. Because of this, any Directory Services implementation must have full backing of the upper management where it will be deployed; never assume that groups that own data will cooperate with each other or the team that it putting up the Corporate Applications Directory - everything will require a solid Business Justification, otherwise the Directory will not be utilized at all. Lining up and establishing Service Level Agreements (SLA's) with the data sources should be done far in advance of connecting the applications that need the data from the Directory Server. Without these SLA's and upper management support, any attempt at a Directory Service will fail by virtue of 'current' data not being available. Getting this infrastructure support and buy-in is critical to bringing up your Directory Enabled applications.

Directory Uses

The relationship between People and Non-People data is the keystone that allows a Directory Service to enable applications. The reason that this is so important is that the Directory allows customization to be widespread and managed at the same time. The average person in a company may to have an email account, network access to one or more computer systems, application access to one or more network applications. These services all need to know who the person is and will want to know if they are currently allowed to do the things that are requesting. This is somewhat more challenging since there is rarely a single source of people information. This is because people who access corporate resources could be any of:

Employees
Contractors
Vendors
Customers
Outside Organizations

Each of these are unique classes of people. Each of these are likely to have specific applications that they need to run. Some will need to be able to do many things that others should never have any access to at all. On top of that, many of these people will have one or more Roles defined that extend or limit functionality.

Human Resources manages Employees, but they will not deal directly with the other types of people that need to interact with the organization. In general, the Human Resources department needs to focus only on Employees. Contractors tend to come from other peoples budgets and are view as an expense rather than a person in the accounting system. In all cases, a Service Level Agreement about how this data originates and is presented to the Directory Services Data Store needs to defined and agreed upon.

Applications leverage the user's entry information by forcing a user to authenticate (ie. log in) against a Directory. By doing so, the authentication can be used to determine what this individual is allowed to do.

Common Functions:

Single Sign On
White Pages
Tracking Training
Organizational Charting
VPN Access
Corporate Roles Management (used by other applications)
Applications customized to use Roles from the Directory
Digital Certificate management (X.509)
VoIP (Voice over IP) routing

All of these things can be highly tailored based on the information available within a Directory Server.

Data flow

Data is rarely originated within a Directory Server, however once an entry is presented, control information is usually applied to allow the Directory to manage built in Directory Functionality.

The Directory Administrator will define what appears within a Directory, and determine how its added, modified and deleted. As discussed above, the actual base 'people' data actually comes from many sources. The Sources of data may have different rules about how that data is managed on the 'source of record' systems.

What the data is, how it gets extracted and how it is delivered to the Directory Server is defined in the Service Level Agreement. Once it has been delivered to the Directory Server, the business rules associated with the Directory Server will be applied. The Directory business rules will not often be the same as those applied to the systems that provide the original data. For example:

Since resources are often associated with a Directory Entry, People entries are not removed until the resources have been de-allocated. While the HR system, may have terminated an employee, the equipment being tracked in the Directory for this person still needs to be accounted for. If you were to delete the entry, you will have lost the list of resources associated with the entry. Typically people entries remain for at least 30 days or until the resources are resolved. During this time, the person entry is 'Marked Deleted' and applications will need to be able to know the difference between 'Marked Deleted' and 'Active.

Another common instance where this 30 day rule is useful is when a Contractor converts to an Employee. At that time, the Contractor management system deletes the entry, and the user is moved to the HR system. This may take more than one business working day; during the transition, attributes in the Directory associated with that persons individual entry is not lost.

This simply means that only applications that should Add/Update/Delete a Directory entry should be controlled by the Directory Server manager, or should be designed in conjunction with the Business Rules for the Directory and the Directory Server manager. Changes that are inconsistent with the Directory Server business rules can cause major operational problems.

The Directory Read versus Add/Update/Delete ratio should be on the order of 1000:1 or higher. Directories are made to be read often, read fast and highly available. If there are many Add/Update/Deletes and few reads, the performance of the Directory Server will suffer greatly. It is very bad practice to store transient data (ie. data that has a very short lifetime) within a Directory - doing this will usually violate the 1000:1 ratio rule. Configuration related data (customizations for an individual entry) that remain static once defined are perfectly acceptable.

Structure

Directories are hierarchical, which means that data is stored in trees. There are many ways to place data within Directory trees. Trees can be used to define organizations, but in practice, organizations get re-organized quite frequently, and as such, over time some tree structures tend to end up wrong for the organization. Because of this, a general rule of thumb is to see if it is possible to keep an organizations people based trees as flat as possible.

Extensive tree structures make sense when defining objects that rarely ever need to be moved to other trees, or in cases where business rules dictate the structure. Functions are often placed in their own trees as are groups.

Many Directories are organized based on how applications will navigate the data. Flat trees are very easy to navigate, deep trees are more challenging to navigate.

LDAP is a method by which you access the Directory Objects; you cannot use other methods (such as SQL). The Object format of the data in a Directory does not lend itself well to other access methods.

When is a Schema not a Schema?

People often think of Directory Schemas in terms of Relational Database Schemas. This may be a good way to start, however it won't be long before the realization sets in that, unlike a Relational Database, any Directory Object can appear in any Directory Tree at any time. The structure is not based on tables - nothing like that exists within a Directory, in fact, its not really even possible to simulate it since there are only very limited constraints possible within a Directory in the first place. Objects are composed of attributes. The Objects are related by the Directory organization that was chosen when the original structure was layed out. This structure may be very flat, or it may have a substantially deep tree structure. That does not prevent an object from appearing anywhere within the Directory Tree.

The problem now is that no matter what you think the organizational structure might be, it may still require that you navigate the trees without making any assumptions about what the tree structure is. The Schema definition used will probably not assist in how you use the Directory.

Delegation of tasks

Data management in a Directory often relates to managing sets of attributes. These sets of attributes may depend on other attributes that are part of the same entry. Its not always as cleanly defined as people might like it to be. This is because the same attribute may be owned by an unrelated data source in each entry within a tree. For example, Human Resources will provide 'people' related information for Employees, while the same attribute set will be provided by a non-HR source for Contractors. That means that an attribute that defines the 'type' of user will also determine who can update other attributes in the system.

Many times, the organization that owns a given set of data will be obvious, however, there often are exceptions to the general rules. Because of this, the Directory manager needs to take ownership of the methods allowed to Add/Delete/Update entries and find a way to delegate these tasks to the people or applications that actually should have the rights to make changes. These capabilities need to come with business rules and automated processes that clean up after data that has delayed actions based on the business rules being enforced.

Some people or applications will have direct access to parts of the Directory; their operational functions will often be limited by using access control methods that limit them tp the specific attribute sets and tree structures that utilize their data.

People and applications will authenticate to the directory for the vast majority of information that they need to access. Adds/Deletes/Updates will always require authentication and may have limitations applied to the accounts, depending on appropriate business rules.

The Directory manager will establish Business rules for the data within the Directory and define/execute all access control utilized.

Comments? Questions? Contact Engineering