All information in this document is based on Microsoft's own documentation and software, available on the Microsoft Developer Network CDs and the Microsoft Internet web site. Novell can only provide opinions based on the Active Directory documentation and latest beta software. Since Active Directory is 12-18 months from shipping, it is too early to state exactly what Active Directory will deliver.

Novell strongly recommends that you consult the Microsoft Distributed Services Technology Preview beta CD provided in the MS SDK and the Active Directory documents available at http://www.microsoft.com.

A Review of Today's NT Domain Limitations

Active Directory is simply the current NT Domain structure with minor modifications. Understanding the ‘what' and ‘why' of Active Directory requires a basic understanding of the issues and problems of the current NT Domain offering.

Legacy Technology
Microsoft Windows NT Server 4.0 uses the old LAN Manager domain as its basic unit of security and centralized administration. When introduced in 1987, the domain structure was sufficient for administration of small workgroup services. As networking technologies have evolved over the past decade, NT's domain technology has lagged behind. As a result, core components of NT Server 4.0 depend on outdated domain technology that is extremely difficult to design, implement, and support except for small companies.

Limited Object Types, Non Extensible
A LAN Manager / NT domain consists of five basic administrative objects: users, local and global groups, printers, and computers. The domain database, however, is not extensible, which prevents the domain from understanding new technologies that have appeared within the enterprise such as electronic mail, fax machines, database servers, Internet firewalls, etc. Ideally you should be able to create and manage these new enterprise technologies within the domain database. Since you cannot create additional object types within domains (such as fax machines, SQL servers, or Exchange servers) or object attributes (such as email addresses, pager number, or photograph) making them a part of your network has proven to be rather difficult.

Flat Name Space
Domains place all resources in a single, flat name space. All names within the domain must be unique. Examples of domain objects would be JSmith or NTSVR1. Hierarchical name spaces, such as DNS, provide additional information within the object's name. For example, jsmith.marketing.newyork.acme.com clearly indicates a user who works in the marketing department, based in New York, for the Acme Corporation. Hierarchical name spaces permit similar object names, as long at the entire object name is unique. For example it is possible to have a jsmith.mktg.ny.com and jsmith.eng.ny.com. Both user objects begin with ‘jsmith' but are unique because their suffixes are different. While the domain's flat name space may be sufficient for small workgroup environments, this can create naming problems with larger organizations.

Few Applications Integrate With Domains
NT Server is a popular application server, but without an extensible domain database, application developers are forced to implement application-specific directories. A Microsoft Exchange resides on an NT Server, neither the Exchange email database nor user email access is managed by the NT domain. Without an extensible domain database, Microsoft was forced to create an application specific directory for Microsoft Exchange. Microsoft Exchange users are actually defined and managed in two separate administrative databases – the domain database and the Exchange database.

Management
In the NT Server domain, management of domain resources is granted by object type, not by groups of objects or individual objects (figure 1). Membership in one of the default NT Server domain groups determines a user's administrative rights to certain types of objects within the domain. NT administration is an all or nothing issue. NT domains do not provide the flexibility to delegate administrative rights to a subset of objects within the domain. With NT Server, it's impossible to grant a user administrative rights to a single printer; the user must be added to the Print Operators group, thereby granting rights to manage ALL printers in the domain. Likewise, it's impossible to grant a user administrative rights over a single user or server; the user must be added to the Account Operators group or

the Server Operators group, thereby granting the user rights to ALL users or ALL servers in the domain.

Trust Relationships
NT Server domains are independent, non-hierarchical databases of account information. The original LAN Manager domain architecture did not provide a mechanism to tie multiple, independent domain databases together. Microsoft attempted to overcome this design limitation of LAN Manager by introducing the concept of trust relationshipsbetween NT Server domains. Trust relationships permit cross-domain administration, allowing users and groups in one domain to be assigned rights to resources, such as file

servers and printers, in a trusted domain. Trust relationships provide users a single login to their home domain and access to resources in other domains that trust the user's home domain.

Domain B trusts Domain A (figure 2). Therefore, users and global group accounts in Domain A may be assigned rights to resources in Domain B. Since Domain A doesn't trust Domain B, users in Domain A cannot access resources in Domain B. This is also known as a one-way trust relationship.

Here Domain A and Domain B both trust each other (figure 3). Users and global groups in Domain A can access resources in Domain B, and vice versa. This is also known as a two-way trust or reciprocal trust relationship.

Trust relationships are not transitive. Consider the following trust relationship:

Domain B trusts Domain A (Figure 4), allowing users in Domain A to access resources in Domain B. Domain C trusts Domain B, allowing users in Domain B to access resources in Domain C. Since trust relationships aren't transitive, Domain C doesn't trust Domain A, even though there are trust relationships connecting Domain A and C through the intermediate domain B. If a user in Domain A needs access to resources in Domain C, a separate trust relationship (indicated by the dotted arrow)must be established before users in Domain A could use resources in Domain C.

As domains are added to the enterprise, additional trust relationships are required for users to access resources in multiple domains. Eventually the number of trust relationships required to link domains becomes impractical.

How large is 249,500? If an administrator did nothing but create 1 trust relationship every minute, 8 hours a day, five days a week, 52 weeks a year, it would require over 2 years to create the trust relationships necessary to allow users and resources to share information between 500 NT Server domains.

It is doubtful that anyone would intentionally deploy a domain structure that required so many trust relationships, yet this is a common consequence of a ‘bottom up' NT Server deployment. NT Server is often implemented as a workgroup solution. Each department or location defines a small NT Server domain that includes the department's users and resources. Over time, these workgroups need to share information with other domains, which require trust relationships. As a result, trust relationships grow exponentially as more workgroup domains are linked into a structure that permits sharing of information. Eventually the number of trust relationships becomes unmanageable, forcing a redeployment of NT Server into a more acceptable domain model.

Domain Synchronization
Domains can be replicated across multiple NT servers. Every NT server that contains a copy of the domain is known as a domain controller. There are two types of domain controllers, the Primary Domain Controller (PDC) and the Backup Domain Controller (BDC). Each Domain must have at least one PDC and may have multiple BDCs.

All changes, such as user creates, deletes, and updates, occur only at the PDC (figure 5). The PDC is responsible for maintaining synchronization across the domain; it periodically communicates with all of the BDCs to exchange account information and ensures the integrity of the domain database. Users may use either the PDC or a BDC for login authentication. If the PDC is down or unreachable, changes to the domain cannot occur, until manual administrator intervention ‘promotes' a remaining BDC to the PDC. Because of this ‘single-master' replication, the PDC is a single point of failure within domain environments.

Single-master or master-slave replication may adversely impact WAN links. Consider

the case of three BDCs on a common LAN segment, separated from the PDC by the WAN. Even though the BDCs share a common LAN segment, each BDC must individually receive updates from the PDC across the WAN. Without multi-master replication, all domain updates must originate at the PDC, even if it is more efficient for a BDC to update another local BDC.

Limitations in the current NT Server 4.0 product were recently confirmed by Microsoft:

Some directory services use a master-slave approach to do updates: all of the updates must be made to the master copy of the directory, and these are then replicated to the slave copies. This is adequate for a directory with a small number for copies and an environment where all of the changes can be applied centrally, but this approach does not scale beyond small-sized, or address the needs of decentralized, organizations³.

Microsoft acknowledges what many customers have discovered: the current NT Server 4.0 master-slave replication technology simply does not scale beyond smaller NT Server implementations.

³Microsoft Windows NT Server White Paper: "Migrating to the Active Directory" p 9, Part No. 098-68324

NT Domain Database Management
NT Servers can only be designated as the PDC or BDC during installation of the NT Server operating system. Every time the domain database is added to or deleted from an NT Server, the NT Server operating system must be completely reinstalled, and all file system permissions must be reassigned.

NT Server may only participate as a domain controller (either PDC or BDC) for a single domain. NT Servers can not hold the domain databases from multiple domains. For example, consider a customer with 10 PDCs of 10 separate domains. In order to achieve fault tolerance, a customer will need to deploy a single BDC to hold replicas of the 10 domains. Since each NT Server is limited to a single domain, 10 new NT Servers are installed as BDCs, one for each of the original domains.

Moving Objects Between Domains
The current NT domain structure does not permit moving objects between domains. Users and groups must be deleted from the original domain and recreated in the destination domain, and all user and group rights to resources must be reassigned. Moving a domain controller (either the PDC or a BDC) between domains requires complete reinstallation of the NT operating system, and recreation of all file system rights on the NT Server.

What if you want to move large groups of objects between domains, such as splitting or merging entire domains? Unfortunately, NT Server does not provide the utilities to split or merge the NT domain database, nor is the underlying domain structure capable of such operations.

Due to limitations of a single large domain, customers often deploy NT Servers in multiple domains with trust relationships, connecting users and resources across multiple domains. However, users are often relocated or change job functions, departments are reorganized or consolidated, entire divisions may be bought or sold. You must be able to quickly and painlessly reorganize their computing environment as their corporation changes. NT Server's domain model does not adapt well to your dynamic environment.

Summary of Today's Domain Limitations

Legacy technology
The domain architecture was created to mange small workgroups of users, groups, and file shares. As technologies have evolved over the past decade, the legacy domain architecture is now pressed to deliver capabilities far beyond the scope of the original 1987 domain design.

Limited object types, non extensible
Since the NT domain is not extensible, it is impossible to expand the domain database definition to understand new technologies that have emerged within the past decade, such as extending the user object to understand fax machines, pagers, cellular phones, and so forth. Without an extensible domain database, it is necessary to deploy application-specific directories with redundant information.

Flat name space
A flat name space was sufficient in 1987 when the largest of domains had less than 200 objects. Now, a decade later, it might be necessary to store several thousand names in a single domain. A hierarchical name space allows more descriptive naming and is generally easier to manage than a single, flat name structure.

Few applications integrate with Domains
Because the domain is not extensible, it is impossible for NT applications, such as Exchange or SQL Server, to use the existing domain structure. NT applications must store their relevant management information, such as a user's email address or preferred SQL server, in application-specific directories, where they are managed separately from the NT domain.

Management by object type
As domains grow in size, it is often desirable to delegate some of the administrative tasks. With NT server, it is impossible to grant administrative rights to individual objects; rather, the user must be added to a special NT group that then grants rights to manage ALL objects of a particular type. For example, a user cannot be given administrative rights to a single user - they must be granted rights to manage ALL users in the domain.

Trust relationships
Trust relationships are required for multiple domain environments. As domains are added, trust relationships grow rapidly beyond practical management capabilities. Managing 100 user and resource domains requires 9,900 trust relationships – far beyond the patience of most administrators.

Domain synchronization
All updates to the domain database occur on a single NT Server known as the primary domain controller. The primary domain controller then replicates this information to one or more backup domain controllers spread throughout the network. Since all updates and replication occur at the primary domain controller, the primary domain controller becomes a single point of failure in the NT domain. Recovering a primary domain controller is a manual process that requires administrator intervention.

NT Domain Database Management
Adding or deleting the domain database to an NT Server, or moving a domain controller between NT domains requires reinstallation of the NT server operating system and reassignment of all file system rights. Each NT Server may hold the domain database for a single domain since it is not possible to place multiple domains on a single NT server. As a result, providing fault tolerance for the domain database with backup domain controllers requires purchasing additional NT Servers.

Moving objects between domains
NT Server does not permit moving objects between domains. Objects must be deleted and recreated. All permissions, such as file system rights, or group memberships, must be recreated. This is especially painful when a domain merge is necessary – since NT Server does not provide a domain merging tool, all objects in one domain must be deleted and recreated in the second domain.

Deploying NT Server - The Real World

Do these limitations really affect customers who choose NT Server? Consider the following, a typical NT Server deployment:

Eric in Engineering decided to use NT Server. Eric created a primary domain controller and called the domain "Engineering." Users throughout engineering were added to the Engineering domain. All was well, until Mike, from mechanical engineering, wanted to manage users in the mechanical engineering department. Eric had a problem – he couldn't grant Mike rights to manage just the users in the mechanical engineering department. Eric could only give Mike rights to manage ALL users throughout engineering, which was not practical since other engineering departments did not want Mike managing their users.

Discouraged, Mike created a new domain called "Mechanical Engineering." Even though Eric's NT server could accommodate all users in Engineering, it could not hold more than a single domain. Thus, Mike was forced to purchase a new NT Server and configure the server as the primary domain controller for the "Mechanical Engineering" domain.

What about all the mechanical engineering users in the Engineering domain? Since NT Server doesn't provide a tool for migrating users between domains, Mike spent hours deleting all the mechanical engineering users from the Engineering domain, being careful to write down all information, such as group memberships, file system rights, printer access, etc. Mike then recreated all the mechanical engineering users in the Mechanical Engineering domain. Finally, Mike could manage users in his department.

This scenario was repeated throughout the company as a grass-roots movement toward NT Server. Departments deployed NT Server for their respective workgroups, managing their users and resources within their own domains. Within a few months there were more than 30 domains deployed across ABC Corporation.

Each of the workgroups in ABC Corporation deployed their own domains because of the requirement to manage both users and resources within the workgroup. Since each NT Server can only hold the domain database for a single NT domain, thirty servers were purchased -- one for each domain.

Word spread after one of the NT Servers suffered a fatal crash – deploy backup domain controllers (BDCs) for fault tolerance. Someone suggested the logical choice — purchasing one large backup domain controller for all thirty domains. Since each NT server can only hold a copy of a single domain, a single large BDC for all thirty domains was technically impossible. Thirty additional NT servers were purchased (one BDC per domain), bringing the total number of NT Servers to sixty.

Strangely enough, most of the NT Servers were underutilized. Fifteen NT servers were more than sufficient to support the network load of the entire company. However, thirty NT servers were deployed because multiple domains were required for delegation of user management to workgroup administrators. Thirty additional NT Servers were required as BDCs adding fault tolerance to the design, bringing the total number of NT Servers to sixty.

All was well, until a user needed access to an NT Server in a different domain. Since there were thirty domains, each with users and resources, 870 trust relationships (30 x 29 = 870) were required. Weeks later, after all trust relationships had been established, it was now possible to grant users rights to resources in other domain.

Meanwhile, the company was reorganized. Users were moved between departments and divisions, some divisions were merged and a few new divisions were created. The reorganization wrecked havoc on the NT domain administrators. Moving users between domains was painful as the administrators had to delete and recreate the users and reassign all user file rights. Merging divisions was even more painful, since large quantities of users and groups were deleted and recreated. Several NT Servers were moved between domains, forcing the network administrators to reinstall the entire NT operating system and reassign all file system rights.

Eventually someone in management discovered the true cost of deploying NT Server. Limitations in the legacy NT Domain technology translate to excessive hardware requirements necessary to delegate administrative rights among the workgroups. Simple administrative tasks, such as moving users or NT Servers between domains, required hundreds of hours of expensive labor. Users were terribly inconvenienced and data was lost every time users and NT Servers were moved between domains. Management demanded a more tolerable NT Server deployment.

After spending thousands of dollars on an outside consultant, the answer was obvious – use a different domain structure, whereby users are kept in large, ‘master' domains. By storing all users in large, centralized domains, administrative costs associated with moving users between domains were reduced or eliminated.

Administrators and users were very unhappy with the consolidation into ‘master' domains. With the old domain model, administrators were responsible for their own users. Now, with the new ‘master' domain model, a departmental administrator cannot manage their own users, since the users are no longer part of their domain.

NT Server started as a ‘bottom-up' deployment by several workgroups, but quickly grew into an unmanageable multiple domain nightmare as workgroups started sharing information. Moving to a more acceptable domain structure required deleting and recreating almost all users and groups and reassigning almost all permissions, all because NT Server does not provide any tools that simplify these common operations.

Microsoft Active Directory

With a clear understanding of the current domain limitations, it is time to explore the Active Directory offering.

New Domain Database

The current NT Server 4.0 domain information is stored in a relatively secure portion of the NT Registry. The NT Registry was designed to store small amounts of machine specific information, such as software configurations and hardware settings. Since the registry does not incorporate important database features, such as indexing and advanced replication, it is not well suited to store large numbers of users and groups.

Domain interaction occurs through a management layer known as the "Security Account Manager," often referred to as "SAM" as in figure 6. SAM is actually a set of application program interfaces (APIs) that brokers requests between the registry and any domain-aware programs or utilities. All applications that interact with the domain, such as Microsoft Exchange and Microsoft SQL Server, use SAM APIs to interact with the domain.

Because the current domain database is not extensible (able to understand anything but what is predefined with NT Server), NT Server applications, such as Exchange and SQL Server, can't store their application specific information in the domain. These applications must dredge the domain database for users and groups, and then place this information in separate, application specific databases, where application specific attributes (such as email) are manipulated.

Active Directory no longer uses the registry for storing domain accounts. A new Microsoft JET database, based on the Exchange JET database (figure 7), is the repository for all Active Directory information. Replacing the registry with JET resolves registry scalability problems and provides mechanisms for extending the domain to understand new objects and attributes. Even though the registry portion of the domain has been replaced with JET, the SAM remains, providing backwards compatibility for all

applications that use the SAM APIs.

Accessing Extended Domain Attributes
With the registry portions of the domain replaced by JET, the domain becomes extensible. Objects within the domain may include additional attributes not found in the current NT 4.0 domain. For example, the domain user object could be extended to include a new attribute called "email address" or "fax number."

Extensions to the domain database are only consumable by Active Directory-enabled applications (figure 8). Applications that use old-style SAM APIs for accessing the domain database cannot access new Active Directory domain extensions. For example, the current release of Microsoft Exchange only understands legacy SAM APIs; therefore, even though the Active Directory domain may contain additional email related extensions, significant portions of Exchange must be rewritten to understand new Active

Directory email attributes.

In the future, applications may be rewritten to understand Active Directory and to take advantage of Active Directory's extensible objects. Unfortunately all information currently stored today in application-specific directories must somehow migrate to Active Directory. For example, Microsoft has stated that 12 to 18 months after Active Directory ships, Exchange will be updated to leverage the Active Directory database. This raises significant questions and concerns about migration tools and strategies for moving from the current Exchange application-specific directory to Active Directory.

Organizational Units
As domains grow in size, the existing flat name structure of the domain becomes cumbersome for locating and managing domain users and resources. Active Directory started to use theconcept of the organizational unit (OU) to the existing domain topology. Organizational Units allow the domain to be subdivided into more manageable units (figure 9).

The Active Directory OU addresses two significant limitations of the current NT Domain structure. First, the Active Directory OU provides hierarchal naming, allowing more descriptive names like rgraves.sales.ny.abc, instead of just rgraves. Hierarchal naming for users and resources simplifies locating resources, as the hierarchal name includes information about the user or resource, such as a department, division, or geographic location.

Second, the Active Directory OU allows finer delegation of domain administrative rights. With the current NT 4.0 domain, administration is granted per object type for the entire domain. The Active Directory OU enables delegation of domain administration rights per object type for the entire organizational unit. Per Microsoft:

The container hierarchy is important because, today, the scope of administrator is the domain, and the administrator of a domain has authority over every object and service within that domain. The Active Directory grants privileges to users based on the specific functions they must perform within a given scope. Administrative scope can include an entire domains, a subtree of OUs within a domain, or even a single OU⁴.

⁴"Microsoft Windows NT Directory Services: Building the Future with the Active Directory" Part No. 098-66900

According to this statement, Active Directory does not permit granting a user administrative rights over individual objects or groups of objects. Active Directory only permits granting administrative rights based on organizational units. Therefore, the ‘scope' of granting administrative rights is the organizational unit. For example, when Active Directory is available, it will be possible to grant a user administrative rights over an entire OU. However, Active Directory will not allow granting a user administrative rights over a single object within the OU, such as an individual server, printer, or another user.

Since its introduction in 1993, NDS provided the ability to delegate administrative rights to a subset of the NDS tree's objects. Like Active Directory, NDS allows granting a user rights to manage objects in a single organizational unit. Unlike Active Directory, NDS also provides the ability to grant finer administrative rights, such as the ability for a user to manage individual objects (like users, printers, and servers) or attributes (like email addresses and phone numbers). The ‘scope' of administration in NDS can be a single object or as specific as an object's individual attributes.

Ideally, as in other directory services, Active Directory OUs could simplify administration of the domain, such as granting rights to resources. In other words, since the users and resources are already logically grouped into an OU based on location or departments, the organizational unit could be used to grant rights to file and print services. For example, what if everyone in .Sales.ABC needed to access files on FS1.Eng.ABC (figure 10)? Ideally, this would be a simple solution - just grant the container .Sales.ABC rights to FS1.Eng.ABC. Then, as users are added or deleted from the .Sales.ABC container, they would automatically gain or lose access to files on FS1.Eng.ABC. Rather than use the OU to simplify management, Active Directory only

understands users and groups - a very ‘domain' approach.

How does Active Directory's limitations increase administrative cost? Consider a relatively simple task - granting all 300 users spread throughout the ABC corporation rights to access important corporate information on FS1. How does Active Directory stack up to NDS?

The flexibility of NDS allows granting rights to resources by either groups or organizational units. Active Directory takes a very ‘domain-centric' approach, much like today's NT Server, by forcing all management by groups, and not by leveraging the organization unit.

NDS organizational units provide much more functionality that greatly simplifies network management. Many of the important, labor saving NDS organizational unit features are missing from Active Directory. Since the organizational unit often reflects geographical locations or departments and divisions within a corporation, Active Directory should leverage the OU to simplify network management. Unfortunately, Active Directory management is limited to management by groups and does not leverage the Active Directory directory structure.

In summary, NDS organizational units were designed to reduce the administrative costs associated with directory management. NDS organizational units simplify and reduce network management. Active Directory organizational units, while providing hierarchy in the domain tree, do not simplify Active Directory management.

Active Directory is missing several key features of NDS organization units. Here's a summary of the key differences between NDS and Active Directory organizational units:

Trust Relationships
Because Microsoft Active Directory is a repackaging of the current NT Server 4.0 domains, it is no surprise that Active Directory requires trust relationships. In fact, the trust relationship is an integral component of Active Directory, as trust relationships are the links that build the Active Directory "tree." Active Directory improves the cumbersome trust relationship by addressing some of the most annoying limitations of today's NT Server 4.0 trust relationships.

Active Directory trust relationships are automatic and transitive. Unlike NT Server 4.0, which requires administrator intervention for trust relationship management, Active Directory handles most trust relationship management. Trust relationships are automatically created to parent domains when new domains are added to the Active Directory tree.

Active Directory trust relationships are transitive, allowing domains to use intermediate

trusts, reducing the n*(n-1) trust relationship requirement of today's NT Server 4.0. Consider the following customer scenario (figure 11):

A customer has five NT Server domains, each with both users and resources. In the existing NT Server 4.0 domain structure, 20 trust relationships (5*(5-1)) are required for any-to-any connectivity. Since Active Directory uses transitive trust relationships, those same five domains could be connected by as few as four trust relationships. For example, even though Domain B and Domain E do not directly trust each other, they may trust each other through the transitive trust relationships established through Domains A and Domain D. In other words, D trusts E, A trusts D, and B trusts A. Since the trust relationships are transitive, B trusts E because of the intermediate domains A and D. Active Directory also allows for manual trust relationships, as indicated by the dashed line.

Partitioning and Replication
Active Directory introduces multi-master replication to the NT domain. Multi-master replication permits updating the domain at any NT server that holds a writeable copy of the domain database (known as a ‘Domain Controller' or DC). Consider the current NT Server 4.0 structure, where all domain updates occur at the PDC, which are then replicated to the BDCs. The PDC-BDC single-master replication lacks fault tolerance - if the PDC is unavailable, the domain is unmanageable. With Active Directory's multi- master replication, domain updates may occur as long as a writeable copy of the domain is available.

Whereas NDS users time synchronization for efficient replication of the directory, Active Directory uses a concept known as Update Sequence Numbers (USNs). Active Directory's update sequence numbers are very similar to NDS time stamps - both determine which objects or attributes should synchronize between directory databases.

NDS replication uses time stamps based on global time synchronization, which Microsoft believes is ". . . inadvisable."⁵ In reality, NT Server 5.0 will provide new time synchronization services missing from NT Server 4.0. Microsoft is also promising Kerberos as an authentication service for Active Directory in NT Server 5.0. Kerberos absolutely requires time synchronization. Active Directory even uses time stamps as a ‘tiebreaker' for Active Directory synchronization collisions.

⁵"Migrating to the Active Directory", p 9, Part No. 098-68324

The smallest unit of replication in Active Directory is the entire domain - no more, no less. It is not possible to partition the domain into smaller units for replication, such as partitioning the domain at an organizational unit and replicating just those objects within the organizational unit instead of replicating the entire domain (figure 12).

Rather than implement one large Active Directory domain, customers may choose multiple domains linked by transitive trust relationships into a larger Active Directory tree. However, each NT 5 server may hold a domain replica of a single NT domain (figure 13). This one domain per domain controller limitation will increase the number of NT 5 servers required for domain fault tolerance.

Building a Active Directory Tree
Upon initial inspection, the Active Directory tree looks similar to an NDS tree. Domains are linked by transitive trust relationships into a Active Directory tree, as shown in figure 14. Upper level domains may represent geographical locations or independent business divisions, while lower domains may represent departments. The transitive trust relationships that connect the domains allow users in any portion of the Active Directory domain tree to be granted rights to resources in other domains.

How will customers migrate from their existing NT Server 4.0 domains to Active Directory? Today's NT Server 4.0 domains cannot reflect hierarchy within a company; therefore, current NT users are located in domains that reflect workgroups or are located in a centralized master domain structure. Moving to Active Directory raises several

questions:

• How will NT Server 4.0 customers migrate the flat structure of today's domains to the Active Directory hierarchy?
• Will Microsoft provide robust tools for moving users, groups, and resources between domains? Or must an administrator delete and recreate users and groups?
• Who determines the Active Directory hierarchy? If a customer has currently deployed domains that reflect workgroups (Sales, Marketing, Engineering, and Production), which domain is highest in the Active Directory tree? Is Sales above Marketing, or is Engineering above Sales?

Rights and Inheritance
Even though the Active Directory domain tree appears similar to an NDS tree, it does not provide the same level of functionality as NDS. Directory services, at a minimum, must provide core features that simplify user and resource management. Even though Active Directory claims to be a directory service, many of the core management features are absent, increasing the administrative costs associated with deploying a Active Directory solution. Active Directory goes to great lengths to arrange users and resources in a treelike structure, yet does this effort pay off in administrative savings?

Both Active Directory and NDS use Access Control Lists (ACLs) in their respective directories. ACLs determine WHO can do WHAT an object or WHO can do WHAT to an object's attributes.
Example of object ACLs:

Examples of attribute ACLs:

ACLs are usually kept as attributes on individual objects. For example, using a directory debugging tool, an ACL might look something like:
Object: Steve.Eng.Novell

The directory uses these ACLs to determine who can do what to this object. ACLs determine who has rights to manage the directory, and who has rights to access resources, such as printers, file servers, email servers, database servers, etc.

ACLs are the heart and soul of the directory - without strong ACL support, the directory cannot manage the relationships between objects in the directory. All directory service technologies must provide strong ACL management and tools; otherwise, the directory is nothing more than a glorified email address book or phone directory.

Both NDS and Active Directory provide ACLs to objects and attributes. However, NDS and Active Directory differ significantly in the tools and concept of ACL management, specifically as it relates to ACL inheritance from upper portions to the lower portions of the directory tree. NDS uses a dynamic ACL inheritance technology, whereas Active Directory uses a static ACL inheritance technology.

Inheritance: the ability for directory management and resource rights to ‘flow down' or effect subordinate objects.

Dynamic inheritance: directory management and resource rights granted to higher container objects permit management or access to subordinate objects without updating the subordinate objects' ACL list. NDS uses dynamic inheritance.

Static inheritance: directory management and resource rights granted to higher container objects permit management or access to subordinate objects but requires updating all subordinate objects' ACL list. Active Directory uses static inheritance

The following diagram highlights the fundamental differences between dynamic and static inheritance (figure 16).

Consider a real-world customer scenario - the ABC customer with 3000 objects in their directory tree needs to grant Steve rights to manage all objects in the tree. How is this accomplished in NDS and Active Directory? What are the consequences of this action?

NDS: Drag and drop Steve onto the top (O=ABC) of the NDS tree. Only one ACL is updated - the ACL on O=ABC container. Because of dynamic inheritance, Steve now has rights to manage all objects in the ABC tree, since Steve's management rights flow down to subordinate objects. Only one ACL was updated; namely, Steve's object was added to the ACL of the O=ABC container object. If we assume that each ACL is 512 bytes in size, the directory database increased by only 512 bytes.

Active Directory: Drag and drop Steve onto the top (O=ABC) of the Active Directory domain. The client's utility must then locate and individually update the ACL list on all 3000 objects. As a consequence of granting this right, the directory database grew by at least 3000 ACL updates; namely, Steve's objects is now in the ACL list for every object in the ABC tree. If we assume that each of the 3,000 ACLs are 512 bytes in size, the directory database increased by a minimum of 1,536,000 bytes.

By using static ACL inheritance, the Active Directory database quickly grows because redundant ACL information is added to multiple objects. Active Directory doesn't store the management information in the Active Directory hierarchy; rather, Active Directory requires updating every single object in the directory. Dynamic ACL inheritance allows NDS to store directory management information in one location in the directory. NDS directory logic then determines the flow of management rights throughout the directory, eliminating the need for storing redundant and wasteful management information on every single NDS object. With dynamic inheritance, the NDS database remains lean, fast, and efficient.

Active Directory's static inheritance increases replication traffic on the network, which is especially problematic for slower wide area networks (WAN) links. When granting global management rights, Active Directory updates all the directory objects with a new ACL list, generating a tremendous amount of directory synchronization traffic. Consider the previous example whereby Steve needed management rights over all 3000 users in the NDS or Active Directory tree. How would assigning these rights impact network traffic as this information is synchronized to 12 servers, each with a copy of the NDS or Active Directory database? Assuming each ACL is 512 bytes:
NDS:

Active Directory:

Replicating Steve's new management rights generated over 18 megabytes of network synchronization traffic in the Active Directory model, as compared to 6 kilobytes in NDS.

Inheritance in a Active Directory Tree
How does inheritance work in a Active Directory tree of domains? How does ACL inheritance apply to a directory of Active Directory domains? Per Microsoft:

The container hierarchy is important because, today, the scope of administrator is the domain, and the administrator of a domain has authority over every object and service within that domain. The Active Directory grants privileges to users based on the specific functions they must perform within a given scope. Administrative scope can include an entire domain, a subtree of OUs within a domain, or even a single OU⁶.

Note that administrative scope, or delegation of administrative rights, cannot include multiple domains. As such, Active Directory is managed as a set of independent domains, not a unified directory tree. Administrative rights do not pass through trust

relationships (figure 17). Even though multiple domains are linked into a Active Directory tree, they are managed as separate domains. In other words, it is not possible to grant administrative rights or rights to resources to the ‘top' of a Active Directory tree and expect administrative rights to ‘flow' to lower domains through trust relationships.

⁶"Microsoft Windows NT Directory Services: Building the Future with the Active Directory", Part No. 098-66900

How does the Active Directory trust relationship limitation affect management of a Active Directory tree? Consider the following customer requirement (figure 18). Steve

needs management right to the entire NDS or Active Directory tree. How many steps are required to grant Steve management rights?

A simple task, such as granting a user administrative rights over the directory tree, only requires one step in NDS, but requires multiple steps in Active Directory. What if the Active Directory domain tree consisted of 500 remote sites, each a separate domain? The foundation of Active Directory is the domain, just like the existing NT Server 4.0 product.

DNS, WINS, and Active Directory
Domain Name Services (DNS) provide basic naming services in an IP environment. Active Directory depends heavily on DNS, which raises several important technical and implementation issues.

"DNS is going to be an important part of the Enhanced Directory Services architecture in the next major revision of Windows NT Server, so it is important to design a DNS architecture that allows for a smooth transition/migration"⁷

Most potential Active Directory customers have an existing DNS infrastructure and most are using Unix platforms for DNS, yet Active Directory may force a redeployment of DNS services onto NT Servers. . Active Directory requires a very specific DNS structure. While it is probable that the DNS and Active Directory structures may have similarities, the rules and guidelines for providing DNS services may differ from the rules and guidelines for implementing Active Directory. As a result, Active Directory may require a redesign of a corporation's existing DNS structure.

Active Directory also requires a very specific DNS platform:

"Servers using Active Directory will use dynamic DNS to publish themselves in DNS"⁸

Dynamic DNS is not an accepted IETF standard. Until dynamic DNS becomes an accepted IETF standard, Active Directory requires deploying corporate DNS services on Microsoft NT Servers.

Today's NT Server 4.0, when deployed in TCP/IP environments, requires an additional NetBIOS naming service know as the ‘Windows Internet Naming Service', or WINS. Just as DNS maps Internet names to IP addresses, WINS maps NetBIOS workstation and server names to IP addresses. WINS allows NetBIOS clients, like Windows NT Workstations and Windows 95 clients, to ‘claim' their NetBIOS name in an NT Server environment. Customers who deploy NT Server 4.0 today must deploy an extensive WINS infrastructure to manage NetBIOS names within their IP environment. How will NT Server 5.0 leverage a customer's existing WINS infrastructure?

"Microsoft's solution for dynamically updating DNS tables, by integrating DNS and WINS, is a short term solution." "Dynamic DNS will eliminate the need for WINS . . . " ⁹

How much of today's efforts in deploying WINS will be negated when NT Server 5.0 ships?

⁷"White Paper: DNS and Microsoft Windows 4.0", p. 31
⁸"Microsoft Windows NT Directory Services: Building the Future with the Active Directory", p. 9, part number 098-66900
⁹"Microsoft Windows NT Directory Services: Building the Future with the Active Directory", p. 9, part number 098-66900

Active Directory's DNS dependency raises several disturbing questions:

• Is the DNS group willing to restructure DNS to meet the Active Directory requirements?
• Is there a single DNS/Active Directory design that meets the needs of both DNS and Active Directory, or will DNS suffer?
• Will the DNS group move DNS services from their existing Unix servers onto NT Servers?
• Who will retrain the Unix DNS administrators so that they may manage NT's DNS?
• How much effort is wasted today by deploying WINS, a short-term solution?

Migrating to Active Directory
Customers who have deployed NT Server 4.0 are struggling with such issues as master account domains, resource domains, NetBIOS names, trust relationships, DNS management, and WINS. Active Directory, as did ‘Cairo' four years earlier, promises to be the ‘end-all' solution to these NT ills. How will customers move to Active Directory? What policies, procedures, and tools are involved in the Active Directory migration? Will Active Directory leverage the existing NT Server 4.0 infrastructure, or will Active Directory require a new infrastructure? Beyond the obvious technical challenges, what corporate changes are necessary for Active Directory adoption? What about customers that are investing time today deploying NT Server 4.0? Are today's efforts wasted when Active Directory finally arrives?

¹⁰"Migrating to the Active Directory" p 14, Part No. 098-68324
¹¹"Migrating to the Active Directory" p 22, Part No. 098-68324
¹²"Migrating to the Active Directory" p 22, Part No. 098-68324
¹³"Microsoft Windows NT Directory Services: Building the Future with the Active Directory" p 15, Part No. 098-66900

Conclusion

Microsoft Active Directory is not a new directory technology that replaces the existing NT Server 4.0 domain. Active Directory is an attempt to retrofit the legacy NT Domain to solve the greatest limitations of the current domain offering. Active Directory will not deliver several core directory service technologies that have been available in NDS since 1993.

Caught off guard by the directory revolution, Microsoft is too short on time to provide a ground-up directory rework for NT Server. Microsoft will no doubt try to stall the industry's adoption of more revolutionary directory offerings as they begin a long journey of redefining domains as a directory service.

Active Directory retains much of the existing NT Server 4.0 technology and limitations. Today's customers are struggling to deploy NT Server domains and trust relationships, yet tomorrow's Active Directory requires domains and trust relationship. Simply stated, Microsoft Active Directory is anything but a directory; because it uses the same domain and trust relationship technologies of today's NT Server. While Active Directory does address some of the existing domain limitations, many limitations remain, which substantially increase your cost of deploying NT Server 5.0.

Even if Active Directory is released in 1998, it is Microsoft's first attempt at a directory service. Features taken for granted with Novell's NDS will not appear in Active Directory until sometime in the next century. Novell has developed and refined several key directory technologies since the birth of NDS in 1989, and is currently working on a fifth-generation directory. Microsoft hasn't even delivered the ‘1.0' Active Directory release.

Novell understands the limitations of NT Server and will provide the same robust, fault- tolerant, scalable directory solution found on Intranetware - a proven solution that has already scaled beyond 22 million NDS users. Novell's NDS for NT will ship in the fall of 1997, allowing customers to manage NT Servers and services as objects within NDS. For more information on Novell's NDS offering, including the fall 1997 release of NDS for NT, please see http://www.novell.com/nds.