Issues and Considerations Concerning Directory Architecture


When creating a directory service it's not always obvious that there are probably many other people tracking the same data in many random ways for different purposes. A Directory Server should be a central place to consolidate this information so that it can be kept updated and managed in a single place.

This doesn't always happen because the need for the data is unique for each user set, and as a result, a central repository lacks key pieces of data that would enable this capability. Providing a data model that allows data sharing to happen will go a long way to eliminating out of date data being used for critical business operations.

Some larger corporations have looked only to find thousands of replications of the same general data, in various states of update and rarely consistent with any other list. Even small companies end up with common data managed in a random fashion by their staff, with each person having their own unique and out of date copy.

Its not hard to understand why this happens. Some of the main reasons are:

  • Each person has a copy on their Laptop PC - contact information needs to be available when they travel. Same may happen if they have a Pocket PC or a Palm OS device - A need exist for a copy of the current contact list.

  • Some people or applications use this data for business solutions - it may be for an Excel spreadsheet, A customer mailing list or an application that monitors usage of resources with the company. People tend to copy data and update it as they see fit. If these people are away on vacation, or leave the company, the possiblity exists that the person taking over their task will have to re-create this data set.

  • The list of data needs to fit a certain format for a unique need. It may be that the more common way of storing this data doesn't provide fast enough access, or requires a very specific organization. It may also be that people see it, but don't know how to leverage the data, and rather than try to fit the available format, they prefer to have their own data set.

There are hundreds of other reasons, however the issue becomes that of data management and how to consolidate the common core of data and allow it to exist in a consistent fashion across the enterprise, no matter the size of the enterprise.

These are some of the things that directory architecture addresses. If you can solve these sorts of issues, your Return On Investment (ROI) for establishing a directory service will be quickly realized.

The best part is that you can, and should, start in smaller steps and build out the infrastructure to solve your business needs. All of these steps should be definable and measurable.

As part of your long term business strategy, your directory services should be utilized as a corporate resource - in the long run, better data control can be placed on solutions and the information that drives your initiatives will be consistent across your organization. This becomes more important if you have multiple sites, and partners that you share some data with.

In all cases, keeping your company data secure and immune to virus and hacker attacks should be a top priority.

     Back to top

Solving the Basics

The minimal application of a directory server tends to be tied to managing peoples contact information. Centralizing this solves immediate business needs, and opens up the doors for advanced services.

     Back to top

Corporate White Pages

People need to be able to communicate with the other people in the company. White Pages are nothing more than an automated address book function. As simple as this sounds, making it available, and allowing users to update things (such as phone numbers, pager numbers, Cell phone numbers, office location information) will make it easier for your operation to work together. This is a critical first step.

The data that originates the White Pages entries should be provided by a source of data that is the reference site - most often there is a tie in to Human Resources (HR). They typically provide common data (but never secured data) to the directory service - how often this update occurs is dependent on how the data is to be used. HR would also be the record of source for removals of employee directory entries. Doing this keeps your White Pages in sync and clearly defines who works there and who doesn't - this is critical if you want to use advanced services that allow controlled access to your Intranet.

Additionally, you will need to address a way to add people that are not employees. These might be part time workers, vendors, trusted partners and contractors. You will be listing phone numbers, including those that are associated with rooms - these are not people; this also holds true for shared resources such as Fax machines and other conferencing devices.

At this point, to implement this service you will need to work with your HR department for employees and define policies for non-employee entries. This could be critical as it may affect your liability at some later date relative to non-employees being represented within the same system. The HR databases will never be the same as your Corporate White Pages directory - there are too many legal ramifications; getting HR to work with you can be a challenge and will require written business justification as well as agreed upon operational policies. HR should 'own' any employee entry - they are responsible, however, there may be push back if HR is not involved in the effort from the beginning.

     Back to top

E-mail Services

Many e-mail services utilize directory servers to manage their users. Examples of this are Microsoft Exchange/2000, OpenWave Intermail, Novell NDS/GroupWare and iPlanets Unified Messaging solutions. When creating an e-mail account, you create a directory entry.

It is in your best interests to tie these entries into the White Pages solution (the above listed solution providers/systems allow for this) to eliminate duplication of entries in more databases than necessary. All new employees need an e-mail address, so utilizing these directories that are already in place and populated by HR to create the e-mail application is the proper start point.

Keep in mind that 10% or more of your e-mail users will not want to use their HR 'official' name. Often they will want to use a shortened version (for example: Mike instead of Michael, or Kim instead of Kimberly), or their middle name instead of their first name. HR data is often tied to official government naming/identification, so you usually cannot ask HR to change their data, but, within the directory, you can provide a way to use the desired name along with the HR official name.

     Back to top

Single Sign On

It would be better for your internal security if your users only had to remember a single password for their accounts anywhere within the company. There have been many attempts at this in the past, and it is usually solvable if everyone is using the same platform/operating system for everything. The problem is, this is rarely possible. Many Environments offer Single Sign On (SSO) in one form or another, and using it allows for simplified account management.

Computing systems are moving to put this sort of SSO data into directories in the form of authentication. At the high end of the scale this might involve digital certificates (PKI) and at the low end simple passwords. Its hard to come up with a universal solution since there are too many types of devices that have vastly differing capabilities that may need to authenticate. Initial solutions have focused on an internal user connected to the company's Intranet; most are platform specific, but do reduce the amount of passwords to remember if you are all using the same devices. What if you are not?


  • The average cell phone often has form of highly limited Web browser and it also has data entry keys (dialing keyboard) that can be used to 'type data' with. It doesn't lend itself to many applications, however it is an exceptional notification device - many events could be triggered to call a user, once the user has told the corporate systems that they want to be informed about sets of events - it may occur as a result of a policy defined and established at their corporate directory server. They may be able to customize these notifications from their cell phones.

  • A GPS systems can track where it currently is and report back to a central system. There is often no human intervention at all during the process, but each device needs to be able to uniquely identify itself. There may be thousands of these to track and they may need to send a status as a part of them 'checking in' to the corporate site.

  • Users, while in the office, might need different capabilities than the same user accessing the same systems remotely. There may need to be 2 or more completely different models. In the case where a laptop is being used, if it is lost or stolen, the capabilities of that system may need to be shut down very quickly, as well as prevent it from doing any more damage than necessary until it can be recovered or disabled. Even though the user has an Intranet connection at the office, their capabilities as a remote access user may need to be diminished, or customized.

  • Access should be limited to approved resources. Most Intranets go everywhere and allow access to all devices and systems. Unless you have a systems administrator or network staff that can manage the routing of access to specific devices or internal routes, you may want to associate policies based on business need or departmental access. Many security problems in a company come from within - centralized control of resource access can minimize the effects.

  • Web pages that might be shared with customers or internal users who are at remote sites. Restricting access as is appropriate, or granting capabilities that normally can only be done internally. Applications such as 'Netegrity' store operational policies into a directory server - allowing highly customized and secure Web page/data access.

  • Provisioning systems access - internal and external access.

Single Sign On means a lot of different things to different people. The area of Wireless access creates many new security issues to deal with. Simple platform solutions (for example, Kerbros basedSSO under Microsoft Active Directory and NFS - Network File System/ NIS - Network Information Service solutions under Unix) work for many cases, but they may not effectively model the long term needs of your organization; these simple solutions fall flat once you attempt to push them beyond their initial solution focus.

     Back to top

Security Past Desktops

Desktop systems connected by internal TCP/IP networks have become the standard access method to internal systems. These typically would be running Microsoft Windows, Linux or some other flavor of Unix. The back end systems either have hard coded a specific systems TCP/IP address, or they are using Dynamic Host Configuration Protocol (DHCP) to allocate TCP/IP addresses as needed.

Many companies have given laptops to their management and higher level people to use during the day, often moving these to different locations in multiple buildings, potentially anywhere in the world. These system may connect to TCP/IP ports via a cable, or possibly by a wireless network card in the laptop. The issue here is that these users often have access to critical company data and because they travel, you cannot lock down where they might be at any given moment.

It is possible a similar group of people might have other non-PC devices (RIM BlackBerry, Pocket PC or Palm OS) that are used for various on site and off site functions.

Some of these will sync data wirelessly, others will need to occasionally connect to the Intranet to get their data, but all will need to be able to utilize the Corporate White Pages to function within the organization. They may need to know schedules, corporate events/calendar information as well as contact lists of internal employees, contractors and vendors. This is not the type of data that you want to hand out casually to the Internet for access - many of these things are critical to your business and may be trade secrets. The Corporate White Pages and various services that connect to it will be the central focal point of access to this data.

Policies need to be in place to manage this information, and it would be a good idea to secure this data in some way. Some of it may be done by utilizing tools on the end devices, others will be done by controlled access by the devices on a network or thru the unsecured Internet.

Some devices, such as cell phones, while they have the ability to access the network and return data into a minimal web browser, often lack the ability to send data via a secure mechanism. In cases such as this, they can still be useful tools, but it is critical not to overwhelm these devices beyond their limitations or give them access that is not appropriate for the device.

     Back to top

Other Databases and Data Sources

Directory Servers are wonderful for managing data and application operational policies, but they are typically not the best way to manage all types of corporate data. Relational databases (Such as Oracle, IBM DB2, SQL Server, Sybase, Postgress, MySQL, and others) are better suited for transactional data using SQL or ODBC to manipulate it.

Access to this relational database information is controlled by application software. This software usually has its own security method and users typically log into it to access the data.

Newer relational database services are beginning to leverage the Corporate White Pages to determine who is and who isn't allowed to access the data, and in many cases, when the can access it, determining what data sets are available. This is often determined by a directory based policy where different users are associated to a policy based on job level, department, or the services that a user needs to do their job. This reliance on the base set of data in the Corporate White Pages means that it needs to be up to date and accurately defines what capabilities are associated with the each user.

The area of Meta directories is a way of combining distinct corporate Databases into what appears to be a uniform data store. Meta directories take a lot of planning and internal agreements to operate successfully, however the operational policies, and how they are associated with a given user, or class of user are typically placed into the same Corporate White Pages directory that people use to keep track of contacts.

     Back to top

LDAP, XML, SQL and Other Data access methods

The right way to represent data has been a challenge since the beginning of computer systems. Todays standards simplify things somewhat, but in reality, there is no single 'right' way to format data for all data requests.

If you end up implementing a meta-directory solution, all of these access methods will become blurred into a larger single view of the world. The challenge will be to find how they relate and then define the methods required to join them. The goal of 'Write Once - Replicate Everywhere' becomes possible with a little planning and cooperation among data centers.

It is likely that you will need to access applications, databases and other networks using these protocols. In all cases, using a standards based communication method will shorten development times and in the long term create a more manageable system.

     Back to top


LDAP (Light Weight Directory Access Protocol) is not a type of database, it is a protocol by which you access the data.

LDAP deals in data objects. Typically, these do not map well into relational database models, and are implemented as Object Oriented Databases. It is possible to do this using a relational database, however, the end result will often not be accessible in an intelligent way using SQL or ODBC - the data will be best accessed using LDAP.

Data objects may or may not be multi-valued and their individual content depends on the object classes that they inherit when they are created or updated. Objects are placed in trees and similar/related objects are often grouped together based on business need rather than general relationships. It is possible to create elements in the same tree structure that are vastly different than other objects in the tree.

LDAP allows you to easily traverse the tree and find the objects that you have been granted access to (access control is typically associated with individual authentication, group controls or directory based policies).

LDAP Directories are best suited for mostly read-only access. They are also typically used to secure access to other systems because of their ability to associate complex data objects to general entries.

     Back to top


Extensible Markup Language (XML) is a method/protocol by which unique data can be disseminated to different systems and have that data be utilized in a consistent fashion. This is a tall order for any protocol to accomplish, however it allows data to be represented once and then allow any device to be able to translate that to a format that is meaningful to it. It manages this by considering each XML transaction as a document, and these documents can be formatted as needed using DTD's or other document descriptions.

There are no XML databases, but most databases can return their data in an XML format. This format may vary depending on who or what asked for it. In the case of wireless devices, such as a cell phone, almost every model has unique characteristics and it is far better to be able to create a single XML adapter for that device than trying to create a general formatting tool to handle all of the potential variations.

Other systems that use XML create a translation table to map the XML document to a format that means something to that system. While this is verbose and apparently inefficient in some ways, it actually provides a 'Rosetta Stone' method by which any data can be shared with any other system. This allows data that was previously very difficult to access become a commodity data source. There are still many issues about XML that will not become obvious until you try to implement a solution, however, the problems are not unsolvable and they are more scalable in the long run.

     Back to top


LDAP directories use an object oriented model to store their data in. For many applications, this is not an optimal choice. Relational databases provide solutions that have been successfully deployed and remain critical to operations.

Access to most Relational databases is via SQL and ODBC. These are standardized to the point where it is fairly easy to create queries against it to locate data. There are also many external applications that can make requests using dynamic SQL or ODBC (Excel, Access, etc.).

     Back to top

Triggered events

SQL databases provide triggers - these are data sensitive actions that cause other events to occur as the result of a transaction completion, or a business rule that has been met. LDAP has no concept of this logic, however, that does not mean that it is not a valuable function to provide.

Currently, the only way to set up triggers in an LDAP directory server is to capture the actual LDAP request and test to see if it will be doing something that you are interested in. If it is, then you will have to cause the triggered event to occur. Some directory servers allow you to build that into the LDAP engine, others do not.

If you are using your directory server to manage an application, putting the trigger logic into the directory server (as its done with relational databases) makes good data management sense.

     Back to top

Operational Policies

First and foremost, all data elements need to be defined in the context of an access/usage policy. These are general guidelines about what is available and how it may be used. All applications and services must register how they will use this data and be held accountable for it.

Another type of policy is where the directory itself manages how data is used and/or how an application interacts with other operations internally or externally.

     Back to top


Directories can handle many entries - they are databases and have been used to make available data about people, places or things. The number of entries that you have will depend on how you want to manage your resources.

Once you have White Pages in place, it becomes a simple task to add asset management and associate those assets to a person, place, or thing. For example, many organizations assign a badge to a user; that badge number may be listed as a part of a persons entry. That person may have a desktop PC and a laptop PC - these assets can also be associated with the user. In reality, since these additional attributes can be hidden in a way that White Pages functions can't see them, a large amount of common data is often kept in the directory structure about a user. These profiles can be associated with operational policies as well.

Directory servers are designed to scale to very large numbers of entries containing an ever increasing number of unique attributes that describe interrelated data in ways that were not easily done before. The same structure used for 50 people will work for 100,000 people.

     Back to top


Directory servers that handle your security model (Single Sign On, Applications Access, etc.) will become central to your operations. Your business security model will often migrate into the directory server as a function of applications that use it, and to leverage the capabilities and licensing of your software.

Once your Directory Server is up and available, it needs to stay up and available. Any design that you put in place must not be sensitive to:

  • Network outages - you must have one or more alternate systems and your applications need to know how to use all possible paths.

  • General maintenance - There must be a way to allow the systems to be serviced, upgraded or reorganized.

  • Excessive use - Connections to a directory server use TCP/IP sockets - a poorly designed LDAP application connects, then never releases when it's done. Over time (often a very short period), the directory server could be rendered un-usable by a simple application. You need to provide more than one access point to your system, and manage all testing in an area that will not affect production utilization.

  • Remote access - Some data needs to be consistent across the network, while other parts may be segmented into functional areas. Many locations need unique data, others require a very limited subset of common data. If these servers are critical to operations, they must also be replicated with the same data model.

     Back to top

Directory Synchronization

All directory servers synchronize to other like directory servers. If your data is consistently defined at all sites, this remains simple. In many cases you may be able to sync a subset of the data, but again, only to a like directory server.

It is likely that you will need to create a custom sync function that allows you to sync any portion of the Directory data, in any format, to any database server (could be via XML or SQL) in your network. In a sense, your master directory will contain too much data and you have to share it on a business need basis.

It is also likely that you will want to push data into to your directory server from external sources. This may because your data is from a different type of database, or the data source is not under your direct control.

Anything that sends to your system, should never do so directly if the data originates outside of your local Intranet. Your directory may become the hub of your business - security of your data should be a top priority.

     Back to top

Other issues to resolve

Directory Redundancy

  • Locations
  • Disaster Recovery Issues
  • Backups
  • Intranet/Extranet issues

Sharing access to the outside world

  • Policies
  • Encryption
  • Laws relating to data transfer

Data Sources

  • Internal
  • External
  • ASP
  • Other


  • Messaging
  • Org Charts
  • Trouble Ticket Tracking
  • Network Management


  • Collaboration
  • Scheduling
  • Calendaring
  • B2B
  • B2C
  • P2P

     Back to top

Questions? Comments? Contact Engineering