Novell is now a part of Micro Focus

NDS eDirectory - Ending Directory Myopia

Novell Cool Solutions: Feature
By Jeffrey Harris, Nancy Cadjan

Digg This - Slashdot This

Posted: 23 Mar 2000

About the Authors

Over the last two years there has been a ground swell of interest in directory technology. The question we face today as IT professionals is not IF directories will play a significant role in the future of network technology, but exactly WHAT that role will be. As you all know, Novell has been banging the directory pulpit for years now. The question you need to ask is whether or not you buy Novell's vision of the role directories will play in modern network infrastructure. After all, Novell is not the only Directory Company in the world, and other vendors appear to have varying ideas about the role of directories in the modern networking era. In order to make sound decisions about the future of network technology in your own little piece of the world it is important to understand how directories might be used to solve common IT problems.

Now I know that I may be preaching to the choir here. If you are reading the NDS Cool Solutions web site you are already plugged in to the directory phenomenon. You are probably technically oriented and have already caught much of the directory vision that Novell is evangelizing. However, it is also very clear that many of the "decision makers" (Translation: those people that hold the purse strings) in today's organizations are increasingly isolated from the technical intricacies related to modern network infrastructure. Most of them understand at a high level what a directory is. They are up on the latest buzzwords and they have recognized that directories are going to play a part in their computing infrastructure. Unfortunately, many of these same decision-makers are hard pressed to identify goals for the eventual scope of the directory or exactly what the directory is really good for.

What I am hoping to do here is give you, as "recommenders of technology", a new way to present the directory discussion to those in authority who may not understand the importance of directories in the same way that you do. Novell has found that there is a significant myopia surrounding the role of directory solutions in today's modern networks. This is understandable since different directory vendors position their directory solutions in different ways. Talk to one vendor and you get Vision A. Talk to another vendor and you get Vision B. The difference in directory philosophies between vendors is really a question of degree. And the philosophy promoted by a given company is largely indicative of that company's roots in the IT industry. As you will see, this directory philosophy is critical because it defines the set of problems that a vendor is targeting with their directory technology.

For the sake of simplicity I have divided the world into three different directory camps.

  1. Directory as a platform extension
  2. Directory as a database extension
  3. Directory as a full service platform

This article examines each of these directory views, identify which of these views Novell has espoused and then argue why Novell's view is the best, of course, for you and your organization.

Directory as a Platform Extension

The first way to implement a directory is to make it an extension of a network operating system (NOS). If you put on your NOS-colored glasses you will be able to identify a certain set of problems that can be addressed via a NOS-attached directory. The directory, in this case, is designed to extend the capabilities of the NOS and make it more powerful . . . more desirable. The NOS directory is designed to address specific platform limitations.

These might include:

  • Ability to centrally manage multiple servers
  • Centralized security
  • Policy-based management of users, applications and other network resources
  • Provide a Single Sign-On opportunity for all network resources
  • Make user access network-centric instead of server-centric

If you will recall, this is where Novell started with its first release of NDS back in 1993. NDS was delivered as a NOS service attached to the NetWare 4.0 platform. Its primary purpose, at the time, was to make it easier to manage the NetWare environment.

NDS did great things for NetWare by changing the server-centric view of the network to a LAN/WAN-centric view. User accounts could be created once, rights and privileges could be assigned once and all LAN/WAN resources could be managed centrally. Furthermore, all these access controls could be abstracted away from the server so that configuration didn't have to take place on each server individually.

Now imagine you are the directory architect responsible for designing a directory capable of supporting the features mentioned above. What would your perspective be with regards to some of the more common categories of directory functionality? Think about the needs of the LAN/WAN environment as you consider the features below:

The typical LAN/WAN is oriented around a single organization and the needs of that organization. Even the largest organizations in the world would be hard pressed to come up with 500,000 objects for a single directory tree. So, for safety's sake you might want to be able to demonstrate directory installations up to a few million objects. However, that scalability could be delivered through a much larger number of servers, since that is primarily what you want to sell.

Security is an obvious concern for the corporate LAN/WAN environment, so it is important to implement some type of authentication/authorization mechanism in the directory. However, since the directory is a NOS service it may not be important to be able to extend that security to external systems.

Standards Support
Here is one area where a NOS-based directory has quite a bit of flexibility. After all, since you control the underlying platform it is not necessary to use standards for every operation. In fact, it may be counterproductive to your NOS business to make the directory too standards-friendly since that might make it possible to introduce competing systems for certain functions.

Platform Support
This one is easy--you support your NOS since the directory is a NOS service.

Application Support
It is important to provide directory management of your other NOS-based applications and services over time. However, there is no reason to extend this to applications hosted on other platforms.

Robust Architecture
I define this category to include things such as flexibility, stability and extensibility. These are many of the features that make a truly world class directory very difficult to build. This is also an area where the NOS-colored glasses can have a critical effect. There is a very real tendency to leverage the human administrative staff to provide the flexibility of a NOS-based system. Why? Because the NOS-based directory targets the needs of LAN/WAN environments where controls and procedures can more easily be centralized and homogenized. The administrative staff can compensate for weaknesses in the directory architecture through manual efforts while still enjoying an overall reduction in the effort required to manage the LAN/WAN.

This outlook makes it very easy to "settle" when designing a directory. Make it good enough to satisfy the needs of the LAN but don't worry about including all those little features that will truly make the directory exceptional. Some of these features might include multi-master replication, double-linking of references, dynamic inheritance and dynamically extensible schema. The fact is that these types of features are very difficult to do from an engineering perspective. It does not make business sense to spend all the extra effort necessary to do these things if their overall effect within the LAN/WAN environment is not going to be that great.

When Novell Chief Scientist Drew Major and his team started designing NDS in 1989 the LAN was all there was. The Internet was just a WAN between universities and government installations for sharing research and scientific information. Network communication protocols were much slower and less stable. Businesses still relied primarily on manual methods to communicate with external entities. Finally, remember that Novell NetWare was, for many people, the only force in the PC LAN market.

Given these conditions it is completely understandable that NDS was originally conceived with many of the assumptions discussed above. NDS was designed specifically for NetWare environments. It used a variety of proprietary protocols to accomplish its tasks. It scaled nicely for the LAN, but that was measured in the thousands of objects?not millions. NDS was designed to support NetWare-based applications and services.

The truly remarkable thing about NDS was that the NDS design team refused to compromise in the area of robust architecture. Guided by theory published in the nascent X.500 directory standard, Novell took the time to do all the little things that would make NDS a great directory service. Novell implemented nearly every architectural and object-modeling feature described in the X.500 family. In fact, under the hood NDS is often more X.500 than the X.500 directories you can get today. NDS differs from the X.500 model primarily to account for the reality of the PC LAN market.

Now I can't comment to the motives for doing this. Maybe Drew and his team recognized future potential, maybe they were just gluttons for punishment. Whatever the reason, NDS started life as a platform-based service with the potential to become something more.

Fast forward to the present day. Has our view of the network world changed a little? Today's reality is cross-organizational communications, the Internet, and a myriad of services hosted on many different platforms. The LAN/WAN is not the top of the food chain anymore and those little shortcuts taken when designing a directory for the LAN are now seen as huge deficiencies that prevent E-business and cost millions of dollars each year. Some of Novell's competitors are stuck in this situation. They are hoping that smoke and mirrors will give them the time to fill in these functional holes. Unfortunately, Internet time is working against them.

Directory as a Database Extension

A second directory paradigm comes from the more recent emergence of the Internet. For several companies out there the directory is yet another type of database. So put your DB-colored glasses on and let's take a look at the directory from a database perspective.

This view of the directory is very common in the world of the Internet. Consider for a moment what a directory might be able to contribute to the Internet and all its associated services and hoopla. The directory is most often characterized as a "white pages" for locating network content and resources. Contrast this with the NOS-centric view of directories and you can see that the way the directories are used is quite different. In the NOS world the directory is in the background, automating processes and isolating the user from the complexity of the network. Interaction between the user and the directory is often indirect. The database view, on the other hand, perceives the directory as a tool for much more direct usage. Users will search for content and other resources directly. This directory view is the foundation for many of the portal and search solutions common to the Internet today.

In light of this different perspective, let's take another look at the common directory functionality discussed above to see how the DB view differs from the NOS view:

Obviously, anything associated with the Internet is going to have to scale significantly. You aren't looking at the needs of a single organization now, but potentially at the entire human population. The ability to store, search and retrieve vast amounts of data is very important.

Furthermore, the need to perform these operations efficiently is much more important in the Internet world where connection speeds and competing traffic are constantly threatening to overwhelm the Internet infrastructure.

There are two sides to the security question from the Internet perspective. First, for most Internet content security is not an issue because the content is public in nature. Second, the Internet community is working towards a security model that will properly support the vast distributed nature of the Internet and provide for more secure interaction. However, there are many questions regarding the details of this work that still need to be answered.

Bottom line, a database-centric directory probably does not need to provide the same level of protection required by NOS-based directories--at least not yet.

Standards Support
Standards support is critical for a database-centric directory. After all, those who implement a directory on the Internet are not capable of controlling the nature of the client or the application that might need to access directory content. Standards are critical for making the directory ubiquitous and accessible.

Platform Support
The database directory is not tied to any particular platform. However, because of the reality of current database and Internet infrastructure the database directory will be most likely be based on UNIX and various UNIX derivatives.

Application Support
The database directory will likely not need to provide a great deal of direct application support. It will leverage standards to make the directory accessible to applications from a variety of different areas.

Robust Architecture
Interestingly, the database directory view produces the same type of myopia associated with NOS-based directories. The database-oriented directory will leverage the DB administrator and perhaps the web developer to compensate for those features that are viewed as too difficult to deliver through the directory. Internet standards also become a crutch for the database-centric directory since its reliance on standards makes it possible to stop where the standard stops, even if that means leaving out critical features that are not parts of the standard yet.

This is nowhere more evident than in the host of "LDAP" directories out there that use the LDAP standard as their architectural model. The result is a directory sorely lacking in directory features such as multi-master replication and dynamic schema that make a directory truly robust.

This DB orientation was foreign to Novell when it first began considering the directory potential associated with the Internet. However, because of the extra effort taken during the initial design of NDS it was capable of overcoming its NOS origins to also become a force in the Internet market. However, this does not mean that the transition from a NOS-only directory was a simple process--primarily because NetWare had not developed into an "Internet platform" of any particular merit (which, of course, it now has).

To compete in the Internet directory market, it was necessary to abstract the NDS service away from NetWare and then provide support for the common Internet directory standards such as LDAP and SSL. NDS also had to be modified to make it capable of scaling to the Internet space. Efforts to transform NDS began in 1996 and are nearing completion today. The result is a directory that is capable of performing admirably under either of these directory models. NDS is both a NOS and a DB directory. It is the only directory in the world that has truly spanned both of these directory paradigms. As we will see in the next section, the question we are facing today is whether or not either of these paradigms is appropriate--or even needed.

Directory as a Full Service Platform

In presenting the NOS and DB directory paradigms the most important conclusion is that each will result in an incomplete directory implementation. Each model focuses on a core set of functionality while identifying another set of functionality as beneficial but not critical. The specific architectural decisions made for a NOS directory and those made for a DB directory will vary, but the end result in either case is that corners will be cut in the name of reducing development costs and delivering the product in a timely manner.

Novell believes that this shortsighted development process prevents most people from recognizing that both the NOS and the DB directory models are just parts of a much greater potential. Just like the four blind men attempting to identify an elephant by touch alone, they each come away with a different view because they are incapable of seeing the big picture.

Well Novell has the big picture! Both the NOS and the DB view of directories are subsets of the set of features offered by what Novell calls the Full Service Directory (FSD). It is achieved by refusing to scrimp on the "difficult" aspects of directory architecture--even if those architectural features might not be necessary for the targeted feature set. The reason this is so critical is that it is nearly impossible to go back and insert these architectural features when they do become necessary in the future. You have to bite the bullet and over-design in the beginning in order to have any hope of delivering advanced features in the future.


That is what Novell did in 1989 - 1993 when the first release of NDS was being created. Novell followed the architectural model of X.500, and even surpassed it in some cases, even though many of the features could not be considered critical to the LAN-based directory market of the time. Novell was able to do this because it was on the cutting edge of LAN technology. It enjoyed a technological advantage in NetWare that permitted it to spend the extra time in getting NDS right.

Compare this with Microsoft's struggles with Windows 2000 and Active Directory. Microsoft has had tremendous difficulty converting the limited Domain model into an enterprise directory infrastructure capable of solving today's business problems. That is largely because the Domain foundation is completely inadequate. It was created to solve the problems of the day with no view toward the needs of the future. Now the future is today and Microsoft is unable to leverage its "directory" platform to solve the problems that NDS can handle quite easily. They are forced to compete with Marketing and FUD rather than solid technological merits.

So let's look at our list of directory features with our newly discovered FSD-colored glasses and see what a directory should really look like.

The FSD must be able to support the needs of the Internet as well as the needs of the corporation. This means that the directory must be able to support vast numbers of objects while simultaneously enabling the speedy retrieval of object data.

The Internet also requires architecture capable of supporting the extremely distributed nature of Internet computing. Internet directories will likely be hosted on hundreds or thousands of systems across the world. The ability to replicate and synchronize directory data must be rock solid and extremely efficient.

The FSD must be flexible enough to support both the potentially proprietary mechanisms of the corporation side-by-side with the standards-based needs of the Internet. Remember that Internet standards still lack critical features in some cases. The FSD must support standards without being beholden to them.

Both environments are clamoring for advanced security support such as PKI, SSL and Smart Cards together with mechanisms capable of delivering these modern security features. The FSD is the vehicle for delivering these features.

Standards Support
Standards support is critical for the FSD. This doesn't mean that the FSD must use solely standards-based mechanisms for accomplishing its tasks. However, it does mean that the FSD had better provide the interfaces and tools necessary to integrate with the prevailing standards of the day.

Platform Support
The FSD must not be tied to any particular platform. It must be possible to host the FSD on many modern platforms so that it is available where it is needed. This is critical for both the Internet and corporate view of the network. It shouldn't be necessary to change existing infrastructure in order to enjoy the benefits of the FSD. Let organizations choose the best-of-breed platform for their needs and make sure the FSD can run on it.

Application Support
The FSD must be able to quickly and easily support a wide variety of application interfaces in order to serve the needs of both the corporation and the Internet. This is possible through strong standards support as well as a wide array of development tools for creating directory-enabled applications. Existing applications should require a minimal amount of modification, if any, in order to integrate with the directory infrastructure.

Robust Architecture
Obviously, the FSD requires an extremely robust architecture. The architectural foundation must be able to adapt to meet the needs of new corporate and Internet usage. Design has to focus not on what is needed now but on what might be needed in the future. Furthermore, FSD vendors should actively push their future vision onto the standards bodies to make sure that upcoming standards consider all the potential needs of the future. The FSD architecture cannot cut corners in any way.


Novell has been talking about the Full Service Directory for some time now. We can demonstrate how NDS eDirectory delivers on the promises of an FSD and now customers are beginning to look beyond their current experience and imagine what might be possible in a directory-enabled world. In that situation NDS becomes a nearly automatic choice since no other directory in the world can deliver the same robust set of features that integrates the NOS and DB directory paradigms.

It is always rewarding to see the light go on when a person recognizes the tremendous potential available through an FSD. It promises to re-make business processes and deliver a previously impossible degree of integration between systems, organizations and individuals. I hope this information is useful to those of you who are looking for ways to present the directory story in a new way. After all, the question is not whether or not a directory should be used but just how much use can you get out of it.

About the Authors

Nancy Cadjan and Jeff Harris both work on the inside of Novell. They are co-authors of Administering NDS Corporate Edition which focuses on the tasks that administrators need to get eDirectory up and running in their network. Administering NDS Corporate Edition covers eDirectory on NetWare, Windows NT, and Solaris and was developed from questions sent to the NDS Cool Solutions Web Site. So, for those of you who wrote in questions and didn't think they were being answered, the answers are a measly $40 away!

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates