• What’s in a Domain Name?
• When is an OU not an OU?
• Naming
• Partitioning & Replication

This month we continue our series of Windows 2000 articles with a more detailed look at Active Directory (AD), comparing it with its main competitor – Novell Directory Services (NDS). It is also worth noting that this is the first month we have had RC2 to play with, which we now assume to be feature complete and free of all ‘major’ bugs. As well as resolving the few major issues we had with RC1, the latest release certainly offers a much wider driver support, which makes installation that much easier.

Despite all the other nice features of Windows 2000 (some of which are so ‘nice’ you wonder if they have a place in a server operating system), it is Active Directory that receives the most attention. And quite rightly so. NT Server has always lacked a real directory service, and its limited domain model – with its flat name space – makes it incredibly difficult to maintain in a distributed enterprise environment. Novell, on the other hand, has had a true directory service to go with its NetWare operating system for some time now. Understandably, Novell is keen to rain on Microsoft’s parade as far as Active Directory is concerned and has released a few documents comparing the two technologies. Microsoft has replied with a few comparisons of its own and, as you can guess, neither is particularly complimentary about the other’s technology.

In the next two articles, we will put both through their paces, take a look at the underlying architectures, and try to separate fact from fiction in the directory service wars. Obviously we are not going to be able to cover every aspect, but we will try to pick out the ones which are the most important or where there is the most scope for confusion.

What’s in a Domain Name?

The first point to clear up is whether AD is a directory service at all. Novell claims that Active Directory is a bit of a misnomer since, rather than being a true directory service, it is actually a packaged set of enhancements to the NT 4.0 domain structure.

The main problem seems to be one of terminology and is caused by the way Microsoft uses the word "domain". Microsoft’s own literature is extremely confusing when it comes to the word "domain", using it several times in the same sentence in some documentation, with each use referring to something different. Because Windows 2000 and AD are so reliant on DNS, the word "domain" can be used in several different contexts depending on what you are talking about – a DNS domain and a Windows 2000 domain could be thought of as one and the same, and both are different, though similar, to the NT 4 domain.

Domains and trusts in the NT 4.0 sense are not mandatory under Windows 2000, and it is perfectly possible to build an enterprise directory using a single domain (directory tree) hierarchically structured via Organisational Units (OUs). Multi-master replication provides for consolidation of domains, and the opportunity now exists to maintain single domains – people will only create multiple domains in order to create separate security boundaries as a conscious decision. The per-domain object limit has been raised from 40,000 to millions to enable this to happen. In short, AD looks like a directory service to us! Whether it is as feature rich as NDS remains to be seen, however.

When is an OU not an OU?

We mentioned that both directory services allow the name space to be structured hierarchically by dividing it into a number of containers called Organisation Units (OUs). Each OU can be a container for other OUs or for ‘leaf’ objects such as users, printers, computers, and so on. The difference in the way OUs are handled by the two directory services is very important, however, NDS allows its OUs to be security principals, whereas AD does not.

A security principal is an object in the directory that can be granted rights to other objects and resources. NDS security principals include users, groups, workstations, organisational units, organisational roles, and profiles. Any of these objects may be granted rights to other directory objects and corporate resources. For example, NDS organisational units can be granted rights to users, groups, and other organisational units. NDS OUs may also be granted rights to resources such as file servers, Web servers, dial-in devices, and printers. One key point that greatly simplifies user administration under NDS is that NDS users contained within the organisational unit automatically inherit the security rights granted to the parent organisational units. This allows the administrator to move a user from one OU to another and have NDS automatically revoke all the rights of the original OU and grant all the rights pertaining to the new OU.

In contrast, AD OUs are not security principals, and they cannot be granted rights to other domain objects, or to any corporate resources such as file servers, Web servers, and printers. The only security principals available under AD are those that exist under NT 4 at the moment – computers, users and groups. Using Active Directory, therefore, only computers, users and groups can be granted rights to other directory objects and corporate resources. This has negative implications in terms of ease of administration – the reliance on Groups is too heavy in AD. Groups will always be needed for some things (they are still available in NDS for this reason), but AD forces administrators to duplicate OU contents with Groups simply in order to grant administrative rights.

Microsoft argues – not entirely convincingly – that OUs should not be security principles because it could cause problems assigning security rights when users exist in more than one OU. Microsoft also insists that security groups are the correct way to assign rights. It has to be said that this argument simply does not hold water. Relying on groups alone will significantly increase the administrative burden in most organisations, and at least NDS gives you the choice of which approach to adopt, since it allows both groups and OUs to be security principles. For day-to-day administrative tasks, we believe that NDS is easier to use.

Naming

Each object within the Active Directory domain has both a hierarchical name and a domain name, but the flat domain name takes precedence over the hierarchical name. Whenever a hierarchical name is created in Active Directory, a corresponding domain account is also created, and problems arise when hierarchical names conflict within the flat domain name space.

In other words, if you have a user Bob in Marketing and one in Sales, the distinguished names should be unique (bob.sales.nss.co.uk and bob.marketing.nss.co.uk). In NDS this is certainly the case. You can have two Bobs – they simply have a different context in the directory. This is not true in AD, however, where the down-level name (to provide backwards compatibility) is BOB in both cases. This is a potentially serious issue with AD in certain environments. However, on the upside (from AD’s point of view) this approach does mean that the user never has to be aware of the tree structure in order to log in – context is very important in NDS and can be confusing. An AD user always logs in simply as BOB.

Also, you would have to ask yourself just how serious it is likely to prove in most real world implementations. With email of vital importance in most organisations, it is usually expected that each user will have a unique name generated from a mixture of initials and surname or forename – it is likely that this would also be the login ID for the user.

Partitioning & Replication

One of the other big differences is the way the two directory services handle partitioning and replication. NDS allows a directory to tree to be sub-divided – or partitioned – at an OU level, and copies of those partitions – called replicas – can then be stored on multiple machines throughout the network. This provides redundancy, since the directory is stored in several different places (albeit in little chunks), but means that users in one part of the tree may have to ‘tree walk’ across slow WAN links in order to resolve a reference that is stored in a remote partition. The answer, of course, is to ensure that the appropriate replicas are stored in the right physical locations to keep tree walking to a minimum.

Microsoft recommends partitioning on a purely physical or geographical basis, and AD partitions at the subnet level, calling it a "site". It criticises NDS for forcing partitioning at an OU level, effectively forcing the NDS OU structure to mimic a physical rather than logical representation of the company. A single OU in Active Directory can actually span more than one site if required. So, an AD domain cannot be partitioned at an OU level as can NDS, but this is theoretically unnecessary given the operation of AD. All controllers keep a full copy of the domain, and by definition a full copy of the domain database exists on every partition (site). Replication is at an attribute level, and can be controlled between sites – replication control is the main reason for partitioning under NDS anyway.

The biggest disadvantage of the AD approach is when bringing a new DC on-line in a new site, since it must receive a full copy of the domain database from another controller elsewhere in the network. There is no way to reduce this by assigning just an appropriate subset (i.e. an NDS-like partition) to the DC. Unlike NDS, AD does not allow you to replicate just a portion of a domain’s objects to another domain controller, such as a single OU or part of the domain hierarchy – the entire domain must be replicated. However, this does mean that every DC has the entire name space available to it, and tree walking is never required to resolve references. If links go down between sites, all the name space is always available – whereas replicas could become temporarily unavailable in NDS.

The price for this convenience is paid once only when the domain database is first replicated, and should not be as bad as it might first appear since Active Directory achieves a data compression ratio of approximately 10 to 1 over WAN connections. Having performed a full replication initially, only attribute-level changes are replicated thereafter. The advantage of AD here is that there is no need to design complex replication strategies, since everything is always available at every server. It is also worth noting that replication between sites occurs via bridgehead servers, meaning that only a single replication event is transmitted across the WAN link. The bridgehead servers then take care of replicating that event to other domain controllers local to themselves.
.