Technical Considerations for Choosing the Best Directory
Articles and Tips: article
Chief Strategist, Directory Services
Novell, Inc.
jtaylor@novell.com
01 Jun 2002
This AppNote presents some solid technical criteria that you can use to make an educated decision on which directory to use.
- Introduction
- Do You Know What a Directory Is?
- Technical Criteria for Choosing a Directory
- Other Factors to Consider
- Conclusion
|
Topics |
directory services |
|
Products |
Novell eDirectory |
|
Audience |
network administrators, consultants, integrators |
|
Level |
beginning |
|
Prerequisite Skills |
familiarity with basic directory services concepts |
|
Operating System |
n/a |
|
Tools |
none |
|
Sample Code |
no |
Introduction
Looking for a directory? If you are like IT professionals in most organizations today, you are striving to create a directory services strategy. But with the wide range of directories on the market, this strategy decision is not an easy one to come to. Bring up this topic in the average IT department and battle lines will be drawn. It is reminiscent of the good old days of the NOS battles, where religious fervor often outweighed solid decision making.
The purpose of this AppNote is to help remove the religious fervor that surrounds this very critical decision and replace it with solid technical criteria that you can use to make an educated decision.
Do You Know What a Directory Is?
This question may seem condescending to many people, but to be honest a great many people will give you a great many answers to the question of what a directory is, what it does, and what it is useful for. Some believe that directories are simply databases. Some think that directories are only useful for telephone white page type applications. Others would have you believe that all directories are the same and that all you need is a database with LDAP (Lightweight Directory Access Protocol) support.
To help put directories in perspective, it is important to realize that directories are not necessarily computer-centric. Many directories in existence today have nothing to do with computers. For example, have you ever looked up a telephone number or address from a telephone book? Do you have a personal address book with information about telephone numbers, addresses, birthdays or other pertinent information about friends, family, or business contacts? Have you ever gone to a large building and had to read the office listings and map to find out where to go?
These items are all examples of directories that we use on a daily basis no matter where we live in the world. While there are many implementations and formats of these, they all serve the same purpose: they guide us. In most cases these directories follow the definition of a directory as an adjective: "serving to direct." Isn't that really what we use the above types of directories for? They help us make decisions. For example, if you were looking for your doctor's office in a building, you could simply read the office listings to find out what room he or she is in. If you weren't sure which way to go to get to that room, you could reference the map and allow it to guide you there.
It is important to realize that these forms of directories have evolved over time, due to the specific needs they address. For example, before the creation of the telephone, there was no need for a city- or county-wide telephone book. The first phone books were not in the format we know today. Instead, early owners of telephones had their own personal telephone books that they created with numbers for people they called regularly. As more and more households and businesses began using telephones, the need arose for a more standardized method of providing directories. The white pages we have today were created to answer this need. Over time, as businesses wanted to attract customers to them, the white pages evolved into the yellow pages. This model has subsequently evolved into Web pages and targeted ad banners.
Technical Criteria for Choosing a Directory
There are a number of technical criteria which you should use to decide on a directory. These include:
Discovery
Security
Storage
Relationship
Each of these criteria is discussed below.
Discovery
The simplest definition of discovery is: The ability to search for, retrieve, and update information. This is the simplest of all criteria to consider, as it encompasses the elementary topics of reading and writing which all of us have been doing since our childhood. But while discovery is simple in concept, implementations of the sub-components are vastly diverse and fairly complex.
Discovery is a critical component of a directory, because without discovery the rest of the directory service is worthless. Discovery makes up a large portion of the directory's access method. It covers the ability to perform the following tasks:
Create objects in the directory
Update these objects and their attributes
Alert internal or external systems of changes made within the directory
Find information either by a complete name or partial name
Provide for unique names throughout the directory
Bring data from the directory to the user
Provide a common way to refer to objects in the directory
Discovery - Publication. Publication does just as its name suggests: it permits a user, device, or application to write information to the directory service. In using the word "write," it is important to note that this implies the ability to create new objects as well as the ability to update properties or attributes of that object. When examining a directory service, you need to determine which methods are available to publish to the directory. Organizations need to ensure that the directory service supports the methods they desire. Many are using LDAP as a standard publication method. As an Internet RFC standard, LDAP has many appealing features such as portability across directory services.
Note: Not all directories that claim LDAP support are equal. Examine closely the implementation of LDAP to ensure that the directory you choose will be able to interoperate with LDAP-enabled applications. The Open Group's LDAP 2000 certification is a good way to ensure interoperability of the directory service with LDAP-enabled applications.
LDAP is not the only method to publish to a directory service. Besides LDAP, directories can use database publishing tools such as the Open Database Connector (ODBC) standard and Sun's Java Database Connector (JDBC) to interface to off-the-shelf applications, programming tools such as Sun's Java Naming and Directory Interface (JNDI) and Microsoft's Active Directory Service Interface (ADSI), as well rich directory-specific publication methods such as the Novell Directory Access Protocol (NDAP). The important thing to note is that when it comes to directory publishing methods, one size doesn't fit all. You should choose the one that offers solutions for your particular needs for today and tomorrow.
Discovery - Retrieval. If a directory can have information published to it, it makes sense that it should have the ability to get the data back out again. Retrieval allows for this, and it is the other side of the publication component. The same methods used for publishing are also commonly used for retrieval of the directory's data.
When evaluating a directory service and the methods it allows for publication and retrieval, options are of paramount importance. It is equally important to know what your directory service can do in the future. When comparing directory services, be sure that the directory provides for an abstraction layer that permits new publication and retrieval methods to be added later. This will ensure that, as new technologies and solutions present themselves, your investment will be protected. While some may choose the directory today because of support for a particular access protocol, it is wise not to limit yourself to a directory that can only handle that particular protocol and cannot be extended to support others.
Discovery - Notification. Applications and devices use the data stored in the directory for many purposes. Many applications make use of the data in the directory service by periodically polling the directory. This involves checking objects and reading attributes, or checking time stamps to look for new objects that have been created or updated since the last polling interval. In such a scenario, decisions being made based on data the application retrieved during the last polling interval may be based on old data instead of real-time data.
Systems that make use of data as it is changed or entered are referred to as "event-driven" systems. In such a system, the directory service notifies the application that something has happened such as a new object being created, modified or deleted. The directory service then alerts or informs the application or device of the change and subsequently acts on it.
Most people would agree that a dynamic system is a better solution. However, in order for this to be implemented, the directory service must provide mechanisms to report these changes. This capability is referred to as an event system. A directory service should not only have an event system, but it should allow for third-party and custom development using this event system, ensuring that it is flexible and capable of being easily developed to with a standard set of development tools.
Discovery - Search. Search is similar to retrieval. As the size of the directory increases, it becomes important to be able to find information that you are looking for. Most of the time people simply leave it at that, but search functionality is another important item to consider when evaluating a directory service.
Figure 1 shows how searching works. A client makes a request, using a tool such as a command-line utility, a management console, or the address book from an e-mail package. This request may be as simple as "Show me John Smith" or as complex as asking to show all servers which have IP addresses within a certain range. In most cases it is the client that has or doesn't have the capability to create complex queries. The query request is formulated by the client and then sent to the directory service.
Basic interaction between a client and a directory service.
When comparing these two models, you can look at two key areas: bandwidth utilization and security enforcement. Here's how they stack up:
|
Issue
|
||
|
Bandwidth Utilization |
Client Side |
Inefficient use of bandwidth since you are sending data that was not requested over the wire. |
|
Server Side |
Promotes efficient use of available bandwidth as only the requested data or the answer is sent over the wire. |
|
|
Security Enforcement |
Client Side |
In client-side implementations, security and access rights are enforced at the client. This creates a security risk since the network administrator cannot control what applications are run on a workstation. |
|
Server Side |
Server-side implementations enforce security at the server and only send what the client requested based on their access control rights. |
While some use the search feature to measure the performance and strength of a directory service, it is important to not look solely at search performance numbers when comparing directory services. Instead, ensure that the directory service performance is sufficient to meet your needs today and in the future.
Discovery - Identification. As a directory grows, it becomes more important to ensure that objects are named correctly and uniquely. This is where identification fits in. Within any medium to large organization, there will be persons with the same name. The key question is: Does your directory service accommodate this?
Directory services that are based on the X.500 model perform this function via the directory hierarchy. In Figure 2, Acme, Inc. is using a directory service that leverages the X.500 model. Acme has created a tree with container objects known as organizational units ( OUs) for each of their geographic sites-in this case, Tokyo and Osaka. In each office there is a person named John. Because of the hierarchical design of the directory, each "John" object is uniquely identified by its distinguished or full name.
Two objects uniquely identified by their globally unique distinguished names.
Most directory services offer a hierarchal approach similar to or derived from the X.500 model, while others do not, thus limiting their usefulness. A few make it look like they are X.500-based, but in reality their structure is flat. It would be wise to investigate and test how the directory handles hierarchy when dealing with identification of objects in the directory.
Discovery-Indirection. In a directory service, indirection ensures that objects can have a relationship created with physical assignments such as file system rights and applications that their associated objects are to use in their day-to-day work. Typically, directory services provide for this type of management for users and groups.
The real test of a directory service and indirection comes when you add physical devices such as servers, routers, switches, and printers to the directory. These objects can be referenced in the directory by using their distinguished name, as discussed above. Rferencing these devices using their logical directory service names ensures that, regardless of where the object resides on the physical network, the directory can always find it.
Later in this AppNote we will see how the directory service must provide for registration services to make this possible and how the directory's ability to provide reference capabilities are needed.
Security
Webster's dictionary defines security as "the quality or state of being secure; freedom from danger; freedom from fear or anxiety." With this definition in mind, it is crucial that a directory service ensure that the data and the service itself be "secure" and "free from danger." This in turn will allow the administrators who are responsible for it to be "free from fear and anxiety" in regardw to the security of the directory.
Finding a directory services that covers all components of security is difficult. Even those that seem to cover all of the aspects may only do so in a limited fashion. This section covers the following security-related components of a directory service:
Authentication
Key management
Qualification
Authority
Enforcement
Audit
Security - Authentication. Authentication allows systems to answer an all-important question: "Who are you?" This is the most basic of all security functions, since it is in essence the front door to your network. This is commonly referred to as "logging in," something millions of people around the world do every single day. Since authentication is so important, it is no wonder that all directory services provide for this function in some form or another.
So how do you distinguished between directory services when it comes to authentication? As always, the decision revolves around options. There are many different forms of authentication that can be implemented today and more will come tomorrow. The current forms of authentication are based on three concepts:
Something You Know. The most common forms of authentication fit into this category. Around the world, millions of people enter user names and passwords every day to obtain access to various computer services. Yet this common combination has many problems in regards to password strength and security. In order to make passwords stronger, administrators create policies dictating how long passwords must be, how often users must change them, what types of passwords can be used, and whether or not they can be reused. These policies make it difficult for users to remember their passwords, so they write them on a piece of paper and tape it to their computer monitor. Needless to say, this defeats all the extra protection the strong password policies were designed to enforce.
Something You Are. This form of authentication is commonly referred to as biometrics. Biometrics involves using physical indicators as a key. Different physical characteristics-fingerprints, voice, and facial or retinal features- act as these keys. Because of the uniqueness of a person's fingerprints, voice, face, or retinas, this provides a very strong authentication method.
Something You Have. This is the method used most often in real life. For example, when you travel by airplane you must show some form of ID such as a driver's license or passport to provide positive proof that you are who you say you are. When you write a check, you may be required to show ID as well. Computer systems can now provide the same capability using "smart card" technologies. Devices such as tokens allow for unique one-time passwords to be created, allowing for stronger password-based systems. X.509 certificates also fit into this realm and can allow for stronger authentication using Web browsers and the Internet.
So which one of these authentication methods should you look for in a directory service? A good directory service will provide support for all of these methods and allow you to deploy them as needed within your organization. An additional feature to look for is a modular authentication engine within the directory service that will allow for new authentication methods to be added as time goes on.
Some directories provide for a more powerful version of authentication by permitting more than one form of authentication to be used to ensure identity. Using multiple methods, administrators can create a higher level of trust than is possible with a single form of authentication.
Security - Qualification. Qualification deals with trust. It allows a directory service to provide different levels of access to the directory and the resources that it controls. It helps to determine the extent of the information that each object can access. As is common in most organizations, certain users are alowed to perform administrative tasks and others can only access the components they have been given authority over. Using the qualification function, different levels of access can be granted for those who are anonymous users than for those who have an authenticated directory identity. In this way, the directory can be made extremely secure, allowing for minute levels of trust to be delegated to anonymous users- maybe just enough to enter a Web site and perform self-service types of duties.
A more powerful feature of qualification deals with access based upon the authentication method used. With all the new forms of authentication, it makes sense to decide which method is required to access certain types of information. For example, if a user authenticates using a simple user name and password, will you necessarily allow that user full access to all aspects of the directory or the resources and services that it protects? Put another way, how much assurance do you have that users are who they say they are? With most directory services, you will have no choice but to trust username-password authentication since this is the only method allowed.
Another key consideration, then, is whether a directory service allows for varying levels of trust depending upon the forms of authentication used to identify the user. As the strength of the authentication increases, so does the trust. The stronger the trust, the more the person is allowed to do. To represent this model, engineers commonly use the diagram in Figure 3.
A directory with both single- and multi-factor authentication.
This model defines the strength of each authentication. The bottom includes single-factor authentication methods, while the top deals with strong multi-factor authentication methods. Using this model, an administrator can require that certain users must authenticate using a certain single- or multi-factor method. Taking it a step further, the administrator can also decide what types of access to allow depending upon the authentication method used.
Security - Authority. Authority is defined by answering the question, "What can I do and what can't I do?" In most security environments, access to resources is controlled via access control lists (ACLs). These AC's are made up of access control entries (ACE) that dictate what an object's rights are. Notice the word used was "object," not "user." When choosing a directory service, it is important to ensure that any object can be given rights to any other object. Since users are the most common object in a directory service, some directories only allow for users, groups, and maybe a few other object classes to be assigned rights. But in reality, all objects need the ability to be granted authority.
For example, applications and services need to have access to the directory and the resources that it controls. Most directories require applications to obtain access via a service account. A service account is a User object with the necessary rights to be able to do its job. This creates a security hole since these accounts become vulnerable to hacks because of their higher level of authority.
A directory service should also allow for self-service, allowing users to opt in and out of services as well as letting them to create their own identities for Internet- type applications.
Security - Enforcement. Enforcement is the other side of authority. As defined above, authority deals with access. Enforcement ensures that the access limits you define are actually put into practice. This sounds like a simple item, and all directories provide for this. But it is important to understand how they enforce the rights.
Enforcement can be initiated several ways. Some systems enforce authority in a static fashion. In this way, the user's rights are determined upon authentication by reading access control lists. The user is then returned a "ticket" with that user's access rights stamped on it. When a user wants to obtain access to a resource, the ticket is passed to the resource and access is granted based upon what the token says the users access rights are. This type of system is very popular due to its simplicity. The down-side of this method is the fact that if users' rights are changed or if a user is deleted, the ticket is still valid until the user logs out of the network.
A more powerful method is to dynamically check the user's rights every time he or she requests access to a resource. This ensures that access is enforced based upon the most up-to-date information available from the directory service.
Security - Audit. When discussing security, auditing is always involved. Auditing allows for changes that are made to the directory to be logged and subsequently tracked. In essence, this becomes the electronic version of a paper trail. This feature is not simply an extra, but is a requirement for those organizations interested in ensuring that their network is truly secure by performing routine audits of the directory service to ensure that no unauthorized access or modifications were made.
Most auditing systems try to interact with the directory services event system. This makes auditing difficult for directories that do not have a robust event system. By tying directly into the event system, certain events can be tagged as being of importance to the administrators and then subsequently logged for future use. The administrator can review the log to check for certain events that are of interest or relevance. More sophisticated systems allow for alerts to be sent to an administrator, letting them know of events in real time. Using this method, problems can be stopped immediately instead of waiting until the problem is found during a routine audit.
Security - Key Management. One of the more advanced features of a directory service involves the use of Public Key Infrastructure or PKI technologies. These technologies provide for highly secure information by using public and private key pairs commonly know as digital certificates. Using this type of technology, data and e-mail within a company can be digitally signed to ensure that the e-mail came from the address listed. Digital certificates can also be used to encrypt the data to ensure that the data is not read or tampered with by unauthorized users.
These forms of technologies are being used more and more in the Internet-centric business world. The most common technology for this revolves around the X.509 standard that is part of the X.500 directory standard. The solution involves using specialized servers known as Certificate Authorities that not only mint (create) these certificates, but also allow for outside organizations to verify the validity of the certificate. From the beginning, the management of these certificates was intended to be the domain of a directory service. Directories are a natural fit since the certificates themselves identify users. Directories provide for a central point of management and the certificates themselves can be used to authenticate users.
Storage
At the heart of any directory service is a database. Usually this database is abstracted to the point that the administrator doesn't really think of it much. The users who need access to the services that rely upon the database never see it or even care about its existence-it is simply there. But although administrators and users give little mind to the particulars of the storage engine, it is the foundation upon which the other components (such as discovery and security) are built upon. If the foundation is faulty, the rest of the directory will suffer.
The storage component deals with persistence, integrity, segmentation, distribution, indexing, caching, and classification. This section discusses each of these components and tells how to make decisions around the following issues:
Keeping the data secure against corruption and failure (persistence)
Ensuring that all instances of the directory are in sync with each other (integrity)
Providing the ability to break the database into smaller, more manageable pieces (segmentation)
Making the data accessible wherever it is needed (distribution)
Increasing the speed of searches via indexing and caching
Giving administrators the ability to enlarge the scope the directory service by increasing the number of objects and attributes that it can contain (classification)
Storage - Persistence. Before the invention of the printing press, people known as scribes where responsible for copying books and other types of documents. This was a tedious and painstaking task. A single scribe may have spent up to one year copying a single book. These people had to be very persistent to ensure that the content was as correct as humanly possible. A single error could result in the waste of several hours or days worth of work.
A directory service requires that the same level of care towards accuracy be maintained within the underlying storage engine of the directory service. Persistence ensures that the data the directory contains is securely stored and protected against data corruption or hardware failure.
Saying that a directory service should protect against data corruption sounds very obvious. However, while most directory services provide for some methods to prevent or fix corruption, they do not all do it with the same level of protection. When choosing a directory service, you would be wise to look for these features:
Logging. Logging allows the directory services storage engine to ensure that transactions (changes) made to the directory are completed. In the event that a transaction does not complete due to some failure, the directory uses these logs to roll back the object to its former state. The directory service should implement both the ability to roll backward as well forward. Using the combination of rollback and roll-forward logging, a directory service has the ability to move back and forth to any moment of changes.
Maintaining references. Throughout the directory, various objects will make references to other objects within the directory. As objects are moved or renamed, these references can become broken. A directory service should provide services to ensure that these links are not broken, thereby ensuring guaranteed name resolution.
Repair utilities. Most directory services have repair utilities of one kind or another, but not all repair utilities are the same. When evaluating the tools, it is important to examine the effects on the directory service uptime. Some tools require that the directory be taken offline in order to be repaired. This can have catastrophic results in many organizations, especially as more and more information is contained within the directory.
Storage - Segmentation. The concept of directory-enabled networks is very valuable for organizations. As organizations move toward a complete directory- enabled network, more data will be stored and referenced within the directory. Segmentation allows administrators to divide a large directory tree into smaller portions known typically as partitions. These partitions can then be distributed to individual directory service agents around your network (see "Storage - Distribution" below for more details).
Besides dividing the directory into smaller pieces for distribution, segmentation allows for enhanced scalability for maintenance tasks. Without this feature, operations such as repairing the directory must be enacted against the entire directory (or large chunks of it) and will take considerably longer to complete. In the case of those directories that require the server to be taken down for repairs, this will increase the time that the directory is unavailable for services.
When examining a directory service's segmentation capabilities, you need to be sure that, even when segmented, the name space is still a single cohesive name space. Some directory services look like they provide for segmentation, but in reality is a series of individual name spaces that are linked together. This creates problems when trying to manage naming models since you need to use another name space to manage the naming of the objects in the directory service. Security is also a problem in these environments since these individual name spaces are actually security boundaries that interfere with the delegation of rights.
Storage - Distribution. Another key differentiator of a directory service is the survivability of the data. In order to provide a high degree of survivability and accessibility, a directory service should allow for the data contained within partitions to be distributed to other directory service agents (DSAs) throughout the network. In most directory services, this is typically referred to as replication.
Using the directory's ability to be segmented, administrators create partitions at a high level in the directory service based on the geographic/WAN environment. The administrator can thereby store replicas of the partitions locally on servers that are on the network that the partition refers to.
In Figure 4, the administrator has created an OU for the two geographic locations in the network: Tokyo and Osaka. By segmenting this way, the administrator can distribute the Tokyo partition to the local Tokyo servers and store the Osaka data on the Osaka server. This allows the data to be accessible to the proper scope of clients. The Tokyo partition contains the information for people working in Tokyo, while the Osaka partition contains the data for clients working in Osaka.
Partitioning by geographic boundaries to keep directory data local.
By storing the data on multiple servers in each geographic location, the directory is protected against hardware failure and can provide for load balancing. The number of servers on which to replicate the segments is based on the specifics of each directory service and your fault tolerance/load balancing needs.
One important note on the choice of partition boundaries needs to be addressed. Some directory vendors would have you believe that it is okay to have a big directory with no segmentation. When dealing with the distribution factors of a directory service, it becomes vital that large directories intended to work across multiple geographic locations have the ability to be distributed with WAN traffic in mind. Using a single large segment and replicating it across WAN links can be quite expensive in terms of bandwidth consumption. Partitioning the directory around WAN connections provides for intelligent control of your organization's directory replication.
An examination of a directory service's suitability would not be complete without considering the number of partitions a single DSA can hold. Figure 4 demonstrates that a single DSA should be able to hold multiple partitions. Most directory services allow a DSA to hold only one partition. This limitation results in excessive hardware having to be deployed and does not provide for scalability or utilization of the resources already deployed.
Planning a proper distribution design for the segments in your directory is crucial. Besides providing for local access to the partition data, you may need to provide for remote access to it. For example, if users in Osaka needed to regularly gain access to resources or data stored in the Tokyo partition, then the administrator may want to place a local replica of the Tokyo partition in Osaka for accessibility purposes, as demonstrated in Figure 5.
Placing replicas to facilitate directory accessibility across partitions.
Storage - Integrity. When working with directory services, it is important to ensure that copies, or replicas, of the partitions are in sync. This integrity component ensures that data changes that occurring on one instance of the directory occur on all other copies.
Replication itself is very common not only in direc
Changes made in a partition are propagated to all replicas.
Many directory services provide for replication. However, they are not all the same. Two key points to look for in the replication process are:
Transparency of replication. Replication should not be a complex operation to set up and manage. It should as transparent as the underlying database. However, this does not mean that there should be no management tools for the process.
Delta replication. As changes are made to objects in the directory, only the actual change should be replicated, not the entire object.
Another key point is to examine how many of the partition replicas can be updated by clients. Some directories are distributed in a master-slave combination, allowing changed to be made only at a single DSA. Decision makers should be sure that their directory choice provides for multi-master replication. Directories that use this method are extremely scalable since they allow changes to occur on the DSA of their choice. They also are much more fault-tolerant because of the removal of a central point of failure.
Storage - Indexing. When dealing with large amounts of data, it becomes difficult to find information. If a directory service contains features in the discovery component such as search and retrieval, it would seem logical that it should also provide for indexes that are built around the most common attributes. Using this indexing feature allows a directory service to perform much faster searches due to the search being run against the index instead of the entire database/directory.
Indexing itself is nothing new; it is a key component of any database. When evaluating directory services, be sure to examine the tools that are used to create and manage the indexes. Also, be sure that these tools can index the information that you need indexed.
Storage - Caching. Since a significant factor in the directory service decision- making process is speed, it is vital to ensure that the directory service will scale well. One method that a directory service can use is caching. Caching for a directory service works in a similar fashion to any other type of cache, except that in this case the DSA is caching the data that the directory contains.
There are two different forms of cache that a directory service should provide. The first type is the directory cache, which stores the actual contents of the directory in memory. When clients make a request of the directory, these requests should ideally be serviced by the cache contents. In the event that the cache does not contain the data that is requested, the directory service will go to the physical disk and retrieve the necessary data.
The second type of cache, and also the most rare to find, is the change cache. Change caches allow the distribution processes with the directory service to simply read a cache on an individual DSA to determine what has changed. Using this type of cache can greatly increase the integrity of the directory across multiple servers.
In a great many cases, the amount of cache that the directory service can use is directly related to the platform on which it runs on. Various platforms use more memory than others. An ideal directory service should be able to limit or increase the amount of RAM that is used for the cache on all platforms that it runs on. This allows you to optimize the memory allocation on the platform and not adversely affect the OS.
Storage - Classification. As mentioned earlier, the power of a directory service is related to the relationships that it allows to be built. As the power of the directory is leveraged within your organization, you will want to increase the types of objects that the directory can contain. You may also want to provide for additional information about an already existing object to be extended. This type of extensibility is crucial to consider when choosing a directory service.
Most directory services refer to this classification method as a schema. The schema refers to the list of objects and attributes that the directory permits to be stored. All directory services have schemas; the difference lies in how extensible the schema is. Some directory services have set schemas that cannot be modified or extended. Others have extensible schemas, but have serious restrictions on what these new objects can be used for. It would also be prudent to determine what tools are available to manage the schema. Many directories allow for extensibility but are very difficult to extend, requiring changes to be made programmatically.
Relationship
This section discusses one of the most important aspects of a directory service: the components of relationship. In fact, I have come up with what I call Taylor's Law of Directories which states: "The value of a directory is measured by the number of relationships it manages and the new applications that result."
When I discuss directory services with people, they usually want to get into the nuts and bolts or the technological issues surrounding items such as storage, security, and discovery. While these components are crucial, they are not as important as the ability of the directory service to create and manage relationships. By utilizing the capabilities covered in the relationship components, organizations can create relationships between objects that have little or no native relationships between each other. This in turn empowers the organization to create a new breed of intelligent applications.
This section discusses the following aspects of a directory's relationship components:
Relationships between separate autonomous directories (federation)
A logical structure with which to manage your enterprise (organization)
Relationships between objects that may not fit into any one organization (collection)
Unique naming capabilities (registration)
A system to effectively manage rights and policy distribution (inference)
Capabilities to ensure that users and other objects are given special considerations based upon who they are and what they are doing (policy)
The ability to allow users to opt in or out of services that the directory or its derived applications provide (subscription)
Relationship - Federation. Organizations have many various boundaries applied around natural groupings such as departments, divisions, or project teams. Typically we refer to these boundaries as authoritive boundaries, meaning that the authority over the operations within these bounds is kept internally.
Directory services allow for the delegation of this authority by using the various aspects of the security components described earlier. However, for either political or legal reasons, there may be a need to maintain separate directories. When separate directories are used, the ability to manage the organization can be impaired. The ideal directory service helps in this matter by allowing the separate directories to function as one while still respecting the authoritive bounds.
In Figure 7, user John is part of the Acme tree based in Tokyo. John needs to access information and services offered on server FS1. However, server FS1 is part of the Widgets tree in Osaka.
Scenario where a user in one tree requires access to services in another tree.
In some directories, the administrator in the Widgets tree would be required to make a new account for John in that tree. This would require John to maintain multiple identities and to be authenticated to both trees. With federation, the administrator in the Widgets tree can simply add user John from the Acme tree to the access control list for FS1. Using this approach, John has only one account maintain and will only be required to authenticate once to the Acme tree.
Few directory services actually provide for federation. When evaluating directories, be sure to examine the federation features carefully. Some directory services seem to offer this feature, but in reality require that the individual trees join some higher-level authoritive boundary. In these circumstances, the autonomy of the various organizations is hindered due to the need to allow a higher entity to govern the aspects of security and schema.
Relationship - Organization. As directories became more and more prevalent, the need to organize the objects in a logical format became evident. In 1988 the X.500 standard created a method of organizing objects. In this standard, special objects know as containers are used to organize the directory.
There are many kinds of container objects that can be used. These include:
Root. Root objects represent the top of the directory tree. Nothing can be above the Root object. Root objects are required in X.500-derived directories.
Country. Since the X.500 model was intended to create a global directory service, the standard permitted the creation of top-level objects known as country containers. These containers are limited to two-character names that conform to the international format (for example, Japan = JP). Country containers can only appear below the Root object. Country objects are optional in X.500-derived directories.
Organization. These are containers that represent an organization itself. Typically there would be one organization object for any single organization. Organization containers can be contained below the Root or a Country object. Organization containers are required in X.500-derived directories.
Organizational Unit. These container types are used to represent geographical locations, divisions, departments, and other logical groups within an organization. Organizational units (OUs) can be nested within each other to create a logical representation of your organization. OUs can be placed below an Organization object or other OUs, and are optional in an X.500-derived directory.
By organizing objects using these objects, an administrator can quickly find objects as well as ensure unique naming. Other directory services features can take advantage of these organizational capabilities (see "Relationship - Inference" below).
Relationship - Collection. While using the organization features described above is the preferred method of organizing objects, sometimes objects do not easily fit into just one model. In these cases, a collection feature helps. In its simplest form, collection refers to group objects. Group objects allow administrators to assign policies and authority to objects by making the objects members of groups.
Figure 8 demonstrates the need for alternatives to using the organization model alone.
Scenario where members of a group are in different geographic locations.
In this example there are two users: user John in Tokyo and user Mary in Osaka. While the tree design allows for the organization of objects based upon their geographic location, it does not allow for the creation of collections of users that span different locations. In this case, the administrator has created a group called "Project_Group". Mary and John have been added to this group. This group can then be granted rights to access various resources or have certain policies imparted to John and Mary by virtue of their group membership. Some directories offer other objects that can be used as collections and are similar in nature to groups.
Another form of collection that a directory service can offer is catalogs. Catalogs permit administrators to include a subset of the directory's data in one central collection. As an example, Figure 9 shows the user objects from the Tokyo and Osaka organizational units being stored in a central catalog. This feature is very useful for large distributed environments. In these environments, using this type of collection for application use is typical in order to reduce name resolution.
Using a catalog to include a subset of directory data in a central collection.
In some cases, catalogs are actually replicas that are sparse and fractional, meaning they don't hold all objects or even all attributes for the objects they do hold.
When evaluating a directory service's abilities in regard to catalogs, carefully examine the following issues:
Can the catalog service contain any objects and attributes you desire?
Does the directory service provide tools to manage the catalog?
How do directory changes get updated to the catalogs?
Is the catalog required or optional? If required, does it become a central point of failure?
Is the catalog accessible using the various discovery components of the directory service, or is it limited to a particular access protocol?
Relationship - Registration. As new objects are added to the directory, the need for uniqueness is important. The registration feature ensures that objects such as user names are unique. The registration component can also ensure that other objects that need to ensure unique names or IDs can. This feature is typically handled using globally unique identification numbers or GUIDs.
Relationship - Reference. As seen above, groups reference other objects in the membership list. This is one of the most important features in building relationships, permitting objects that have little in common to be associated with each other using references to other objects and the data that they contain.
Since most directories permit the use of groups, they also provide for reference capabilities. It is important to understand how the directory handles references; there is more to it than simply adding an object to a membership list. The directory needs to be able to ensure that a change to the object (such as changing its name or moving it) does not break the link. This is a very advanced feature and few directories permit this. When reviewing directory services, be sure to examine closely how the directory deals with the referential integrity of links.
Relationship - Policy. The ideal directory service should provide the ability to manage your environment via policies. Directories allows for the creation and storage of policies for various types of objects, including users, servers, routers, and switches. These policies can then be associated to the appropriate objects using the various methods such as the organizational hierarchy, collections, and individual users.
Policy management via a directory is unique because of the synergy that can be created between the objects. For example, a user can have a policy associated with its objects. This allows administrators to take into account that different people have various needs. Now the policy for the desktop that the user is logged into applied to the desktop giving the desktop new features based upon whom the users is. When the user seeks access to a file server, the file server's policy is enacted, as well as the quality of service requirements that were obtained for the router that the user is attaching to.
Relationship - Subscription. A directory service should include the ability for users to subscribe to services that make use of the directory service. This subscription feature permits authenticated users to opt in and out of services. To leverage this important feature, the directory must allow a special yet rare right called add self. This right permits user to add opt in and out of services without having to have unnecessary rights to the objects that represent the services.
Relationship - Inference. The distribution of security and policy to objects can be a very daunting task to administer. To aid administrators in this, the ideal directory service should permit them to delegate rights and associate policies using a solution known as inference.
Inference allows rights and policies to be managed using collection and organizational objects. Using objects like organizations, organizational units and groups, administrators can infer rights to objects and mandate policies as needed. The most advanced method is to leverage the organizational hierarchy to infer rights and policies. Using this method, administrators can manage the scope of their assignments by varying the level of the assignment of the hierarchy.
While many directory services have X.500-like hierarchies, they do not all allow for inference by using container objects such as organizations or organizational units. Be sure to carefully analyze how the directory service handles inference.
Other Factors to Consider
Besides looking at the directory services features and components covered above, you may also want to consider a number of other issues.
Scalability
As the directory becomes more strategic within your organization, the size and distribution of the directory will mandate a scalable solution. This scalability deals not only with the number of objects that it can realistically hold, but also how well it scales in regards to management, distribution, and accessibility.
For example, a directory vendor might rightly say that their directory can scale to 10 million objects per DSA. But how does it handle distribution (replication) in such a distributed environment? Also, what is the performance like when doing basic operations such as searches and authentication?
Ownership
Many directory services use third-party databases that they do not own. This may seem like a good idea, but it leaves the customer at somewhat of a support disadvantage. When problems arise due to database issues, the directory vendor many times will be required to go to the database vendor to get support. This may increase the amount of time it takes to get patches and support.
Cross-Platform Support
Most organizations have multiple operating system platforms. As you examine directory services, be sure that the directory service is cross-platform and easily portable to new platforms. This will ensure the long-term viability of your directory decision. It will also ensure that your decision on current and future operating systems will not affect your directory decision.
Abstraction
From a storage point of view, abstraction allows the directory vendor to replace the underlying database as the need arises, with a minimal amount of work. Directory services that are abstracted to this point are rare, but provide for future enhancements.
Adoption Rate
Most people don't like to be the only person doing anything. As you make your choice of directory services, analyze the adoption rate of the directory. Small niche players typically have smaller adoption rates than general purpose or full service directories. Also compare the methodologies used to determine market adoption. Most vendors' methods of measuring adoption rates center on "licenses distributed or sold," but the number of licenses in actual use can be very different from the number of licenses shipped.
Conclusion
This AppNote has described the technical criteria you should use in determining which directory service is best for you. For more information, visit Novell's eDirectory Web site at http://www.novell.com/products/edirectory.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.