Comparing Microsoft Active Directory to Novell's NDS

Article
06/29/2006

Microsoft Corporation

September, 1998

Summary: With Novell's release of NetWare Version 5.0 and Novell Directory Service Version 1.2 (NDS), Microsoft is asked frequently to compare the Active Directory of Microsoft® Windows® 2000 Server to NDS. Microsoft believes that customers are no longer looking for application-specific or limited-purpose directory services—they require directory technologies that can play a multipurpose role. For reasons outlined in this white paper, Microsoft believes that Active Directory will meet the customer requirements of a multipurpose directory service much better than NDS. This makes Active Directory the best long-term directory service.

Overview
Focus: Scalability
Focus: Internet Standards Support
Focus: Security Services
Focus: Synchronization and Consolidation
Focus: Development Environments
Conclusion

Overview

Customer Situation

The concept of using directory services in networked computing environments is not new. For example, many companies have implemented white pages using first-generation directories to make basic information about employees (for example, location, e-mail address and telephone number) available across the organization. E-mail applications have provided directories in the form of address books to simplify the process of finding people and sending them e-mail. In addition, products such as Novell's NetWare have shown that it is possible to simplify basic management tasks by including a directory service as part of their offering.

Figure 1. Application-specific directories

With the increase of distributed computing based on Internet technologies, however, the role that most companies need directory services to play is changing. Directory services must be capable of being used in all of the following roles:

User and network resource management—by providing a scalable, hierarchical information repository to simplify tasks such as delegating administrative privileges and locating network resources such as printers
Security authentication and authorization services—by providing flexible authentication and consistent authorization services that minimize barriers to doing business over the Internet while protecting data
Directory consolidation—by reducing the number of directories companies need to improve information sharing and enable common management of users, computers, applications, and directory-enabled devices
Directory-enabled infrastructure—by enabling elements such as networking hardware and shared file systems to offer enhanced service quality and greater functionality through access to information about users (and their roles), machines, network elements, and policies stored in the directory
Directory-enabled applications—by enabling simplified application configuration and management, greater functionality, and synergy with other directory-enabled components of the network-computing environment

Figure 2. Multipurpose directories

In essence, companies need to select directory services that are capable of functioning as a multipurpose directory on which many different facets of their network computing environments will be based.

Solution Requirements

To function successfully as a multipurpose directory service, technologies must meet a number of requirements:

Scalability must not come at the price of complexity. The various roles that directory services play require the efficient storage and replication of millions of objects and cannot require complex configuration of servers.
Locating, accessing, and managing directory objects must be through Internet standards. Given the wide range of ways that directory services will be used—often from across corporate and geographic boundaries—directories must be able to locate and access objects through Internet standards such as the Domain Naming Service (DNS) and the Lightweight Directory Access Protocol (LDAP).
Security must be flexible and simple. Along with the desire to increase access to directories comes the need to protect corporate resources without placing design restrictions on networks or increasing management complexity.
Directories must facilitate consolidation. Because most companies will not be able to eliminate all of the application-specific directories that they use today, multipurpose directories must enable consolidation and provide synchronization facilities to minimize duplicated administrative efforts.
Directory services must be part of a comprehensive application development environment. To attract software developers, directories must be full-featured, make it easy to use their features, and run on platforms that provide a comprehensive and simple-to-use development environment.

Without meeting each of these requirements, a directory service cannot play the role of a multipurpose directory service effectively.

The Best Long-Term Choice: Active Directory

With the Novell's release of NetWare Version 5 and Novell Directory Service Version 1.2 (NDS), Microsoft is asked frequently to compare the Active Directory of Windows 2000 Server to NDS. Microsoft believes that Active Directory will meet the requirements of a multipurpose directory service better than NDS:

Scalability without complexity—Active Directory scales to millions of objects per partition and uses indexing technology and advanced replication techniques to speed performance; NDS requires hundreds of partitions to scale to equivalent sizes and uses flat files to store data, slowing retrievals.
Built around Internet standards—Active Directory provides access to all features through LDAP and uses a DNS-based namespace; NDS does not make all of its features available through LDAP and does not support DNS as a way to name directory objects.
Flexible, simple security model—Active Directory supports multiple authentication protocols such as Kerberos, X.509 certificates, and Smart Cards and security groups can span partitions efficiently; NDS has no support for Kerberos or Smart Cards as authentication protocols and Novell recommends that administrators minimize use of groups that span partitions.
Facilitates directory consolidation—Active Directory provides synchronization support through LDAP-based interfaces and scales to accommodate application-specific directory consolidation requirements; NDS provides very limited synchronization support and limited scalability.
Provides a comprehensive feature set and development environment—Active Directory has attracted leading vendors such as SAP, Baan, J.D. Edwards, Cisco, and many more; Novell lacks this broad level of vendor support, which will limit the total cost of ownership (TCO) benefits that NDS can deliver.

For these reasons and more—described in the remainder of this white paper and summarized in Table 1—Microsoft believes that Active Directory is a better long-term multipurpose directory service choice than Novell's NDS.

Table 1. Comparing Active Directory to NDS by requirement

Requirement	Active Directory	NDS
Scalability without Complexity	Partition boundary is a Windows 2000 domain to enable direct access to all objects in a domain Partitions use indexed data store for fast retrieval Designed to hold millions of objects Optimized replication between sites and over slow network links Global Catalogs are updated simultaneously with other replication cycles to ensure low latency Single data store and access methods for partitions and catalogs	Partitions are not indexed Novell recommends a maximum of 1,000 objects per partition and that partitions should not span WAN links Administrators must manage partition sizes and restructure partitions as they fill up Searching for objects directly across partitions requires tree walking Different data store for partitions and catalogs High catalog latency since catalog is rebuilt only at scheduled intervals (default is 24 hours)
Internet Standards Support	Implemented as a native LDAP server that requires no request translation Consistent interpretation of access control rights when access is through LDAP Provides LDAP-based access to all features Full namespace integration with DNS to simplify object location and access	Provides LDAP support through server-based interface that must be installed on NDS servers individually LDAP requests must be translated to NDS formats Limited LDAP-based access to NDS features Different naming syntax for LDAP access versus access through NDS APIs Access rights interpreted differently when access is through LDAP versus NDS APIs No namespace integration with DNS makes object naming and location more complex
Flexible Security Services	Provides support for popular security technologies such as Kerberos and Smart Cards Catalog enforces object- and attribute-level security No restrictions on security groups that span partitions (domains)	Lacks support for Kerberos and Smart Cards Catalog does not enforce object- and attribute-level security within the catalog database Novell recommends that administrators minimize the use of groups that span partitions
Support for Synchronization and Consolidation	Provides the scalability required to consolidate large directories without administrative complexity Built-in LDAP-based change history interfaces facilitate use as a metadirectory platform Catalog architecture enables fast, efficient query of large number of objects Will be used by Microsoft products such as Exchange 6.0, MSMQ 2.0, MCIS 3.0	Partition size restrictions limit use for directory consolidation Provides no formal way to request change history information; requires customized synchronization agents Catalog architecture forces tradeoffs between speed and consistency with underlying partitions Not used by Novell's GroupWise product for account management and address book functions
Comprehensive Development Environment	Provides COM-based Active Directory Services Interface (ADSI) for simplified development JADSI supports access from Java applications Provides the scalability required to ensure that applications can store, access and manage millions of objects without application-level complexity Provides LDAP-based access to all features	No ADSI implementation for use by applications running on NetWare JNDI supports access from Java applications Applications must work within partition limitations Limited LDAP-based access to NDS features

Table 2. Comparing Active Directory to NDS by role

Role	Active Directory	NDS
User and Network Resource Management	Provides the scalability required to store, locate, and manage large numbers of objects efficiently and without administrative complexity Catalog architecture enables fast, efficient query of large number of objects Global Catalogs are updated simultaneously with other replication cycles to ensure low latency Designed to optimize replication traffic across wide-area network links	The number of partitions required by NDS to hold expected numbers of objects slows access and increases management complexity Catalog architecture forces tradeoffs between speed and consistency with underlying partitions High catalog latency, since catalog is rebuilt only at scheduled intervals (default is 24 hours) Partitions that span wide-area links not recommended by Novell
Security Authentication and Authorization Services	Provides support for popular security technologies such as Kerberos and Smart Cards Catalog enforces object- and attribute-level security Scales to supports large numbers of Extranet users DNS integration simplifies object naming and location through Internet protocols	Lacks support for Kerberos and Smart Cards Catalog does not enforce object- and attribute-level security within the catalog database Partition size limits complicate Extranet use No namespace integration with DNS makes object naming and location more complex
Centralized Directory Management	Provides the scalability required to consolidate large directories without administrative complexity Built-in LDAP-based change history interfaces facilitate use as a metadirectory platform Catalog architecture enables fast, efficient query of large number of objects	Partition size restrictions limit use for directory consolidation Provides no formal way to request change history information; requires customized synchronization agents Catalog architecture forces tradeoffs between speed and consistency with underlying partitions
Directory-Enabled Infrastructure and Directory-Enabled Applications	Strong support from leading vendors Windows NT provides a rich development environment that is supported by many tools Provides the scalability required to ensure that applications can store, access and manage millions of objects without application-level complexity Provides LDAP-based access to all features	Support from many leading vendors missing NetWare provides a limited environment for application developers Applications must work within partition limitations Limited LDAP-based access to NDS features

Focus: Scalability

Scalability Criteria

Because multipurpose directory services will be used in so many different roles, it is essential that they be scalable. The term scalable encompasses several different criteria:

The underlying data storage mechanism used by the directory must be able to hold many different objects. While the definition of many is subject to debate, given that it is common for companies have over 50,000 employees—most of whom have computers, application profiles, and network connections that will be represented as directory objects—it is reasonable to expect a directory service partition (see Endnote 1) to hold at least 1,000,000 objects.
It must be possible to locate objects quickly within the partition, either directly by name or by way of searching for partial matches (for example, "find all users with first name equal to Bob").
It must be possible to create full replicas (capable of both read and write operations) of the partition on multiple servers within the company to ensure that individual servers do not become points of failure or create network communication bottlenecks.
When multiple partitions must be maintained (for example, because full replication between servers is impractical due to network bandwidth or directory capacity limitations) it must be possible to create catalogs that contain selected subsets of all partitions in an efficient and timely manner.

A Customer Scenario

A good way to compare scalability is by using a typical customer scenario. The figure below shows a North America-based company with subsidiaries in Asia and Europe. Within North America, there are sites in San Diego, Chicago, and Boston. The sites within North America are linked by fast, reliable network connections; Asia and Europe are linked to North America with slower, less reliable connections. The company would like to implement a directory where all information stored about entities (for example, users, machines, printers, and so on) in North America is accessible from any location in North America, all information about entities in Asia is accessible from any location in Asia, and so on. In addition, because of the network connectivity issues to the Asian and European subsidiaries, the company wants to make a subset of all directory information (for example, name, telephone numbers and e-mail addresses) available world-wide.

Figure 3. Customer scenario

Active Directory Partitions

The boundary of a partition within Active Directory is a Windows NT domain. In other words, all of the entities within a Windows NT domain that have associated Active Directory objects will accessible within a single partition. Because Active Directory supports multimaster replication, a full replica of the partition will be available on all domain controllers in the domain, even when the domain spans multiple sites.

It is important to note that with Windows NT 4.0, many companies do not implement domains that span different sites. This is because Windows NT 4.0 itself offers limited support for delegation of administrative rights and limits the number of users and machines to 40,000 per domain. Practically speaking, this means that multiple domains are required to contain large numbers of users and machines, and to give sites the administrative autonomy they require.

With Windows 2000 and Active Directory, however, the domain model expands dramatically:

Because Active Directory partitions use an efficient indexed data store, and Windows 2000 uses Active Directory to store information about all entities in a domain, domains can contain millions of users and machines.
Centralized administrators can take advantage of the hierarchical structure used by Active Directory to delegate administrative rights (to whatever degree is appropriate) to teams, departments, sites, and so on.
Replication of Active Directory information between sites is highly optimized, through advanced techniques such as data compression and automatic use of bridgehead servers (see Endnote 2), reducing the need to need to create domain boundaries simply on the basis of network bandwidth limitations.

For these reasons, Microsoft expects that most companies will have fewer, but larger, domains when they deploy Windows 2000.

Figure 4. Partition design with Active Directory

Figure 4 shows how Active Directory might be deployed based on the customer scenario defined earlier. In this scenario, there would be three domains—one for each territory. Each site within a domain would have one or more domain controllers, each containing a full replica of the partition. Because domains form the boundary of a single Active Directory partition, users and applications within each territory will have direct access to all objects and attributes associated with the domain.

NDS Partitions

NDS uses partitioning technology to subset the NDS namespace from an object storage perspective and to define the unit of replication within NDS. Because NDS stores objects in partitions using flat files that are not indexed, Novell recommends that administrators should not configure partitions to hold more than approximately 1,000 objects (see Endnote 3). When more than 1,000 objects need to be stored, administrators must create additional partitions.

Figure 5. Partition design with NDS

Figure 5 shows how NDS might be deployed based on the same customer scenario. In this scenario, each territory and site would require multiple partitions to store all of the objects corresponding to that location.

Microsoft believes that NDS's partitioning scheme creates a number of challenges for administrators, users, and applications:

Searching for objects is inefficient. For example, if an administrator wants to locate all users with a first name of Bill at the Chicago site, multiple partitions will have to be searched using a technique Novell refers to as tree walking. Within each partition, searches are slowed by the fact that partitions are not indexed—each object must be scanned individually for matches.
Partition configuration management can be complex. Because the contents of container objects cannot span partitions, and because Novell recommends that partitions should not span wide-area networking connections, administrators must design organizational unit hierarchies carefully to fit within partitions.
Novell's applications automatically create a significant number of objects within partitions. For example, NetWare creates three objects for each DHCP user and between one and three objects for each ZenWorks user.
As objects are added and partitions fill up, it is the responsibility of administrators to restructure and rebalance partitions manually.

NDS's catalog mechanism, detailed in the next section, is designed to address some of the issues created by NDS partitions, but Microsoft believes that significant issues remain even when catalogs are considered.

The Need for Catalogs

In the case of both Active Directory and NDS, there will be situations where it will be impractical to store all possible objects in a single directory partition. For example, in the customer scenario above, wide-area networking may make replication traffic prohibitively slow between North America, Asia, and Europe. Because there will be some set of information that is of interest throughout the company, however, it is important to have a way to gather subsets of all individual partitions and make them available in a single place. Both Active Directory and NDS provide catalog features to address this requirement.

Active Directory Catalogs

Active Directory provides a mechanism called a Global Catalog to enable administrators build a specialized directory containing the subset of object attributes that are of interest beyond of a single domain. The Global Catalog builds off Windows 2000's concept of trees and forests of related domains to determine how domains participate in the Global Catalog process.

Figure 6. A Windows 2000 domain tree with Global Catalog

In particular, Active Directory enables administrators to specify which domain controllers in a given domain should hold Global Catalog information in their Active Directory partitions. Administrators then specify which object attributes should be replicated to the Global Catalog using Active Directory's Schema Manager. When any object in the tree or forest is added or updated, information about the update is propagated automatically, using the same replication technologies as within a domain, to all domain controllers that hold Global Catalog information.

In the customer scenario, the domains might be organized as a tree with North America as the parent and the Asia and Europe domains as child domains. Each domain could have a replica of the Global Catalog containing selected attributes from all domains. Strengths of the Active Directory approach to catalogs include:

Global Catalogs are updated simultaneously with other replication cycles to ensure that catalogs stay consistent with their underlying domain-based objects
Global Catalogs are kept within Active Directory partitions to enable a single, unified way of accessing all Active Directory objects
Objects and attributes in the Global Catalog retain their original access control lists to ensure that catalog operations do not compromise security

NDS Catalogs

NDS provides a mechanism called Catalog Services to create catalogs. With NDS catalogs, administrators enable users and applications to perform queries directly against a single entity that includes copies of objects from multiple NDS partitions. Novell recommends the use of catalogs to avoid the need to do NDS tree walking when doing searches.

To create and manage catalogs, administrators use a utility called the Catalog Service Manager. This utility enables administrators to define the partitions that should be cataloged and the object attributes that are of interest. Administrators also use the Catalog Service Manager for operations of what Novell calls the Dredger—a process that runs periodically to rebuild the catalogs.

Figure 7. The NDS catalog architecture

Microsoft believes that NDS catalogs have several significant weaknesses:

Catalogs are not based on incremental updates (like NDS replication techniques within a partition). When the Dredger begins to run, its starts with an empty file and proceeds to query each partition individually. When finished, the Dredger replaces the old version of the file with the updated version.
Because of the time it takes to dredge partitions individually, Novell recommends that catalogs be rebuilt only periodically (by default the Dredger runs every 24 hours). This means that catalogs are likely to be out-of-date with the underlying objects in their partitions.
Objects that are dredged lose their original access control properties. Instead, access control rights are applied to the catalog in its entirety. If a user is granted access to a catalog, they get access to all objects and attributes.
To enable efficient searching and ensure some level of attribute-level security, customers must define multiple catalogs—each representing a different view of objects. For example, administrators might define a separate Human Resources catalog that contains salary grade information so that this information is not available in the same catalog used for address book-type information.

Using the criteria defined at the beginning of this section to assess the scalability of NDS, Microsoft believes that it will be difficult for NDS to support the scalability requirements of many companies.

Focus: Internet Standards Support

Before the advent of ubiquitous connectivity based on Internet-style networking, corporate and geographic boundaries defined the level of connectivity that applications needed to provide. Now that virtually any computer able to locate and communicate with any other computer in the world, network computing infrastructures must support as many Internet standards as possible to ensure that computing systems are not what place limits on what business applications can be created.

With respect to directory services, Microsoft believes that there are two Internet standards that are particularly important:

The Lightweight Directory Access Protocol Version 3.0 (LDAP V3) for querying, accessing, and managing objects stored in directory services
The Domain Naming Service (DNS) for locating machines and services over the Internet using a standardized naming format

Active Directory and LDAP V3

Recognizing several years ago that application vendors and end-user companies would expect a high level of LDAP V3 compliance from their directory services in the future, Microsoft designed Active Directory from the ground up as a "native" LDAP server. LDAP-based requests are processed directly without translation against the Active Directory data store. Active Directory also exposes all of its functionality through LDAP interfaces. For example, Active Directory provides LDAP-based support for schema management, change history, and query scoping.

Perhaps most important, Active Directory—because its inherent scalability—is well-suited to function as an LDAP server in environments where large numbers of objects must be hosted in a single partition. For example, if a company wants to publish a public address book or product catalog through an LDAP server, Active Directory can host over a million objects in a single, fully indexed partition.

Figure 8. LDAP and Active Directory

NDS and LDAP

NDS's support for LDAP comes from LDAP Services for NDS. According to Novell, "LDAP Services for NDS is a server-based interface between NDS and applications that comply with LDAP" (see Endnote 4). This service acts as a translator between LDAP requests and the native way that NDS accesses data out of partitions.

Figure 9. LDAP and NDS

While Novell claims that NDS is fully compliant with LDAP V3, Microsoft believes that the way NDS provides LDAP support has several weaknesses:

LDAP Services must be installed on every NDS server that must support LDAP access. Novell also notes "If you uninstall LDAP Services for NDS with the intention of reinstalling it again later, you should wait a significant period of time before attempting the reinstall. Since the schema needs to resynchronize across the tree, the time period you wait should be commensurate with the size of the NDS tree" (see Endnote 5).
LDAP and NDS use different naming syntaxes (see Endnote 6).
Access control rights are computed differently when access to NDS is via LDAP as opposed to directly through NDS interfaces (see Endnote 7).
Using a "middleman" process between applications and NDS to process LDAP requests adds overhead to processing.
NDS does not expose all of its functionality through LDAP. While not strictly required for compliance, not exposing features such as schema management through LDAP extended controls forces applications to implement multiple access methods to NDS when certain features must be accessed.
Enabling access to NDS namespaces containing greater than 1,000 objects through LDAP requires companies to either expose applications to the performance limitations of tree walking (needed to search multiple partitions) or use catalogs that may be out-of-date with the underlying objects in their partitions.

Active Directory and DNS

One of the long-standing goals of companies implementing directory services is the concept of a global root that connects all individual namespaces together for simplified location of information. Work on solving this challenge focused around X.500 technologies for many years, but stalled as attempts to create a worldwide clearinghouse of directory location information failed. Lacking a global root capability, companies had to publish the addresses of their directory services. Accessing objects meant knowing how to find the directory server holding the object and the fully distinguished name of the object itself.

Microsoft chose to take a different approach and integrate Active Directory with the mechanism that the world already uses to find services on the Internet: DNS. Windows 2000 domain names are based on DNS names. Because domains have a one-to-one relationship with Active Directory partitions, Active Directory namespaces can be located directly through DNS. Further, an Active Directory object's fully distinguished name contains the DNS name of its partition, is globally unique and completely describes how to find the object in a company's intranet or across the entire Internet.

NDS and DNS

The object naming style used by NDS does not incorporate DNS names. To locate an object in NDS, users need to know first how to find the appropriate NDS server. Also, because NDS and LDAP use different naming syntaxes, intranet applications written to access NDS directly will use different object names than Internet applications that use LDAP.

Focus: Security Services

Along with the ability to access directories across the Internet comes an increased need to protect corporate resources. The challenge that companies face, however, is to protect resources without placing unnecessary design restrictions on networks or increasing management complexity. When evaluating directory technologies, it is therefore important to understand security system implementation issues such as:

How directories enable users and applications to authenticate themselves.
Once authenticated, how access rights are computed.
Any limitations imposed by the implementation.

Active Directory and Authentication

Active Directory supports multiple security authentication protocols such as Kerberos, X.509 certificates, and Smart Cards to facilitate extranet development. The Active Directory approach to authentication also makes it easy to extend Active Directory with additional authentication protocols. Once a user has authenticated to Active Directory, authorization is performed in a consistent fashion across files, applications and other resources.

NDS and Authentication

NDS supports x.509 certificates but does not support Kerberos or Smart Cards for authentication. Also, as mentioned earlier, access control rights are computed differently when access to NDS is through LDAP as opposed to directly through NDS interfaces.

Security and Inheritance

Support for access control inheritance enables administrators to simplify directory administration by enabling child objects to inherit their access control behaviors from parent objects. Changes to parent objects affect the access rights of children automatically. There are two primary ways to implement security inheritance: dynamic and static.

Strictly speaking, dynamic inheritance essentially means that the access control behavior of each object is computed (by examining all parent objects) at the time the child object is accessed. Each time the object is accessed, the access control behavior must be recomputed.

Static inheritance is where the access control behaviors of child objects are computed (and "attached" directly to the child object) when some access right to a parent object is changed. The definition of static inheritance does not dictate that an administrator must make explicit changes to each child object when an access right of a parent object is changed or that all changes must be replicated individually.

Active Directory and Inheritance

Active Directory implements a sophisticated form of static inheritance. Each child object has an access control list "attached" that contains the "summary" of all access rights that are either specifically assigned to the object or inherited from its parent objects. Active Directory recomputes child access rights automatically when a parent object's rights are changed. Only the change to the parent object is replicated between domain controllers and global catalogs. The child access rights are then recomputed on each domain controller—a fast and local operation.

Active Directory behaves in this way because directories must be optimized for read (versus write) behavior. Active Directory pays the price of recomputing access control bahaviors once (at the time a parent object is changed) rather than on every read operation. The net effect to the user regarding "true" dynamic inheritance and the way Active Directory implements inheritance is the same.

NDS and Inheritance

NDS implements dynamic inheritance of object access rights. In most cases, the difference between this method and the method used by Active Directory is minimal. However, because of the implications of catalog latency and dynamic inheritance, NDS catalogs do not support access control at the object and attribute level. Each attempt to search for objects in the catalog would force the catalog to locate each underlying object in its partition and recompute its access rights before the search would be permitted to include the object.

Active Directory and Groups

Active Directory implements security groups in a way that makes it possible (and efficient) to create groups that span organizational units within a partition and across domains that are part of a forest or a tree. This makes it easy for administrators to create groups that include members regardless of their location in a partition or the domain to which they belong.

NDS and Groups

While NDS supports the concept, Novell recommends that administrators minimize the number of security groups that span across partitions because of the impact on network traffic. Microsoft believes that this places significant restrictions on how NDS administrators define partitions—they may find that they must create groups that span many partitions to meet business requirements.

Focus: Synchronization and Consolidation

Today, information about people, applications, and resources is scattered throughout most IT enterprises—and is continuing to proliferate. For reasons of enhanced functionality, operating systems and applications (ranging from e-mail to enterprise resource planning (ERP) systems) frequently provide their own repositories to store information about users and resources. As companies continually increase the number of applications and platforms that they use and support, the number of different repositories increases as well. This forces companies to manage information in many different places—even when those places contain duplicated and related information.

To minimize costs and increase their ability to respond to change, companies want multipurpose directory services that provide a common way to store, access, and manage corporate information. Because of the lifecycle realities of important existing investments in applications and platforms, this goal will not be achieved overnight. However, with available, Internet-ready directory standards and the growing response from application vendors to customers' demands for interoperability, it is possible for companies to reduce the number of directories that they need and lay the groundwork for moving to a unified directory strategy in the future.

Requirements for multipurpose directories that will play a unification role include:

Facilities for synchronizing changes with other directories.
The scalability and flexibility to consolidate objects from many application-specific directories.

Active Directory and Synchronization

Active Directory provides synchronization features that enable companies to begin to use Active Directory immediately as their focal point for centralized management and single sign-on infrastructures while transitioning away from existing directories. In particular, Active Directory includes an LDAP-based interface for requesting lists of all object additions and updates since a given point in time. These interfaces make it easy for applications (including metadirectories products) to synchronize objects in different directories without resorting to inefficient techniques such as tree walking or monitoring replication traffic.

In addition, shortly after the release of Windows 2000 Server, Microsoft expects to offer an additional product that will use Active Directory change notification mechanisms to synchronize Active Directory objects with corresponding objects kept in NDS.

NDS and Synchronization

NDS provides no built-in mechanisms for publishing or retrieving directory change events. Third-party products that capture additions and updates to NDS do so by monitoring replication traffic within NDS partitions with specialized agents. When multiple partitions are required to hold a set of objects, agents are needed in each partition to capture all change events.

Active Directory and Consolidation

As discussed in the Scalability section of this white paper, Active Directory provides scalability up to millions of objects in a single partition. This level of scalability enables Active Directory to be used as a consolidation point for other application-specific directory services. For example:

Microsoft Exchange will use Active Directory exclusively (instead of the specialized directory that it currently uses), starting with Exchange Version 6.0.
Microsoft Message Queue Service Version 2.0 (MSMQ), part of Windows 2000 Server, will use Active Directory instead of the SQL Server™ 6.5 database used by MSMQ 1.0.
Microsoft Commercial Internet Services (MCIS) will use Active Directory for authenticated user access, starting with Version 3.0.
Important metadirectory vendors such as ISOCOR and Zoomit have announced their intentions to support Active Directory as their underlying object store.

As these products and others from independent software vendors (ISVs) support Active Directory, customers will benefit from an increased ability to manage directories centrally—which translates directly to lower TCO.

NDS and Consolidation

Microsoft believes that the issues regarding NDS scalability and support for LDAP identified earlier significantly limit NDS's ability to act as a point of directory consolidation. For example, an application that uses NDS as its directory service would have to limit the number of objects it stores to the objects that can be kept in a single partition, be tolerant of the significant time it takes to do searches across NDS partitions, or implement it own partition management functions.

Microsoft also believes that NDS catalog services would be of limited value in consolidation scenarios because an application could add or modify objects in a partition (see Endnote 8) and then be unable to find a consistent copy of the object in the catalog for long periods of time. This would be true even if the catalog is kept on the same server as the partition itself.

Focus: Development Environments

Many companies first realized the value of directory services because of the ways that directories help to simplify user and machine management in a network environment. For example, storing information about users and machines hierarchically in a directory allows administrators to delegate management responsibilities to appropriate individuals within departments and groups. This frees administrators to focus on other tasks and gives more autonomy and control to users.

Extending the role of directories to include security services, directory consolidation, and networking offers additional value. For example, directory-enabled networking enables companies to provision services based on policies and other information stored in directories instead of "throwing hardware at the problem" or leaving matters to chance.

Most important, by deploying applications that have been integrated with directory services, companies will be positioned to experience the best of all worlds: simplified management, enhanced network services, greater application functionality, lower TCO, and synergy between all directory-enabled components of the network-computing environment. This "raises the bar" for what a directory service needs to be—directories that offer only simplified administration or support a single application deny their users many important benefits.

Because companies acquire the majority of the software they use, it is critical that they be able to buy products and applications that work with the directory services that companies have chosen. What leads vendors to support a directory is largely determined by:

The features that the directory supports.
How easy it is to take advantage of these features.
The richness of the platform on which applications and the directory run.

Active Directory Service Interfaces (ADSI)

To make it easier to write directory-enabled applications that access the Active Directory and other LDAP-enabled directories, Microsoft developed Active Directory Service Interfaces (ADSI). ADSI is a set of extensible, easy-to-use programming interfaces based on Microsoft's Component Object Model (COM) that can be used to write applications to access and manage:

Active Directory
Any LDAP-based directory
Other directory services in a company's network, including NDS

Active Directory Service Interfaces abstract the capabilities of directory services from different network providers to present a single set of directory service interfaces for managing network resources. This greatly simplifies the development of distributed applications, as well as the administration of distributed systems. Developers and administrators use this single set of directory service interfaces to enumerate and manage the resources in a directory service, no matter which network environment contains the resource. Thus, ADSI makes it easier to perform common administrative tasks, such as adding new users, managing printers, and locating resources throughout the distributed computing environment. Combined with the wealth of tools that support COM—such as Microsoft Visual Basic®, Visual C++®, and Visual J++™—ADSI makes it easy for developers to directory enable their applications.

Active Directory-Enabled Applications

Windows 2000 Server, including Active Directory, is designed to provide developers with the features they need to build powerful directory-enabled applications that deliver greater functionality and enable lower TCO:

Group Policy Integration. Group Policy features enable administrators to define sets of applications, including specific configurations, that users should have available based on their roles in the company, the domain of which they are members, and the Windows NT security groups to which they belong. When a user is moved into an organization, or added to a Windows NT security group, his or her applications can be installed and configured automatically—helping to lower installation and configuration costs dramatically.
Service Publication. Active Directory enables applications to publish the names and locations of services they provide so that clients can locate and use services dynamically. This enables administrators to reconfigure servers for optimal response times and higher availability without having to update clients.
Directory Object Extension. Active Directory provides the ability for applications to add new types of objects and to extend existing objects with new attributes. This enables Active Directory to be a consolidation point for reducing the number of directories that companies have. Benefits include improved information sharing and common management of users, computers, applications, and directory-enabled devices.
The ADSI Extension Model. ADSI provides a feature called the ADSI Extension Model that enables application developers to associate COM-based business rules with objects stored in Active Directory. This provides a consistent and simple way for developers and administrators to interact with an application and its objects. The Extension Model also makes it easy to invoke methods across groups of objects, such as "all users in the Accounting department" to simplify administration.
The Active Directory Class Store. The Active Directory provides a section of the directory tree called the Class Store that is used to store the names (for instance, Class ID or Program ID) and locations of COM objects installed on the network. COM uses the Class Store to locate and install the COM objects that users are allowed to use on their machines automatically. This can lower the TCO of COM-based applications by simplifying client configuration and administration.

Windows 2000 Server and Active Directory together provide a full-featured platform for building directory-enabled applications. As a testament to the power of this platform, leading vendors such as Baan, J.D. Edwards, SAP, and Cisco have committed to adding support for Active Directory in their products.

The NDS Development Environment

Microsoft believes that Novell has had difficulty attracting leading networking and application vendors to develop for the NetWare and NDS environments for reasons including the well-known challenges of implementing applications as NetWare Loadable Modules (NLMs). For example, while Novell has announced that they will provide ADSI support for NDS, it is not possible for applications that run on NetWare servers to use ADSI because NetWare does not support COM or COM-based tools such as Visual Basic. Instead, NetWare-based applications must either use native NDS APIs or use JNDI calls when running in the Java Virtual Machine provided in NetWare Version 5.0.

In addition to the limitations mentioned above, applications that use NDS as a repository must work within the limitations of NDS partitions and cannot simply create an arbitrary number of objects in a partition. For example, an e-mail application cannot use a single container in a single partition to store an address book if the expectation is that there will eventually be more than 1,000 entries (that is, objects) in the book. This may be why Novell's own GroupWise product uses NDS for user authentication and administration but uses a separate database for its user account management and address book.

Conclusion

It is clear that companies expect to use directory services in a growing number of roles. Further, companies want to eliminate corporate and geographic boundaries as barriers to doing business over the Internet, reverse the trend towards proliferation of role-specific directories, and realize synergy from elements in their network computing environments. Most important, companies need to make informed decisions now about selecting the directory services that will support their business needs well into the future.

Microsoft believes that a good way for companies to make directory decisions is to identify the roles that they envision for directory services within their organization and compare how well Active Directory and NDS support each role. Based on the roles identified in the Introduction section of this white paper, Microsoft's view of how Active Directory compares to NDS is shown in Table 2.

Summarized, Table 2 shows that Active Directory:

Is a better directory than NDS for managing users and network resources.
Provides more flexible security services than NDS.
Is a better platform for directory consolidation and centralized directory management than NDS.
Has more support from important infrastructure and application vendors than NDS.

Based on this perspective, Microsoft believes that Active Directory will meet the customer requirements of a multipurpose directory service much better than NDS. This makes Active Directory the best long-term directory service choice.

Endnotes

A directory service partition is similar to a database table in that it represents the set of objects that can be accessed directly by query and update operations without linking or referring to other partitions. (Click here to return.)
Active Directory uses Bridgehead servers to ensure that replication traffic between sites and across slower network links is performed efficiently. Updates travel once between bridgehead servers, which then propagate the updates to other domain controllers in the site. (Click here to return.)
This recommendation is made in Novell's online planning guide for NetWare 5.0 posted at: www.novell.com/products/. (Click here to return.)
This statement is made in a white paper posted at www.novell.com/products. (Click here to return.)
This recommendation is made in Novell's online documentation for NetWare 5.0 posted at: www.novell.com/products/. (Click here to return.)
This topic is explained further in Novell's online documentation for NetWare 5.0 posted at: www.novell.com/products/. (Click here to return.)
This topic is explained further in Novell's online documentation for NetWare 5.0 posted at: www.novell.com/products/. (Click here to return.)
Objects cannot be modified in either Active Directory or NDS catalogs. (Click here to return.)

--------------------------------------------

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.