Author: Jens Moller
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:
- 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.
- The Directory will likely list conference rooms. The HR department
doesn't want to manage these either.
- 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
The issue is that the Directory quickly faded into the background and
it becomes 'infrastructure'. Other forms of infrastructure are:
Oil & Natural Gas
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
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.
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:
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
Single Sign On
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 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
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.
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
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
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