[an error occurred while processing this directive]


Exploring 2000 - AD v NDS (Part 2)
- February 2000
This month, Bob Walder continues his detailed look at Active Directory (AD), comparing it with its main competitor – Novell Directory Services (NDS). (See Bob’s previous article, January 2000.)

DNS Integration

Figure 1 - Click to see detailed viewDNS is very much entrenched in AD, and this is certainly the cause of much confusion amongst potential purchasers/evaluators, and will be the source of consternation amongst many implementers. Dynamic DNS and DHCP are especially well integrated with AD (see figure 1: DNS records are stored within AD), though DNS and DHCP services can be hosted separately if required.

The first element of confusion here is that many people think that they have to rip out their existing DNS servers and replace them with Microsoft’s in order to deploy Windows 2000. Nothing could be further from the truth. Firstly, it is possible to use third party DNS servers, though you may not get all the benefits of Dynamic DNS (this depends on the third party server).

The only real requirement is that the DNS server that is authoritative for the name of the Windows 2000 domain must support SRV records (RFC 2052). BIND has supported this RFC since version 4.9.6. Microsoft also recommends that this server support secure dynamic updates (though this is not a requirement). This is covered by RFC 2136, which defines the ‘Dynamic Update Protocol’ and BIND has supported this RFC since version 8. When using third party DNS servers that do not support dynamic updates, the biggest disadvantage is that the administrator will bear a heavier admin burden, since updates will have to be done manually (see figure 2: Numerous service (SRV) records are created by AD). For an entire Windows 2000 and Active Directory deployment, as few as one DNS server needs to be modified, while all other DNS servers in a company can remain untouched. It is even possible to seamlessly introduce Windows 2000 DNS servers into a network by using DNS delegation, and not have to touch a single existing DNS server except to create the delegation relationship.

The fact that DNS is so firmly entwined with AD is concerning some people who worry about how changes to the AD structure will affect an established DNS implementation. The worst-case scenario is where an AD domain is split, and even then the change will affect only entities that would prefer their Fully Qualified Domain Names (FQDN) to be changed to include the name of the new Windows 2000 domain to which they belong. The only entities that require new FQDNs, however, are the domain controllers in the new domain. All other domain members can continue to use their old DNS names. In addition, computers that are not members of the Windows 2000 domain, but simply belong to the DNS domain with the same name, are not affected.

Undoubtedly, green field sites or those that do not already rely heavily on DNS will fare the best. Complex installations with existing DNS deployments may or may not find themselves faced with problems. The introduction of Microsoft DNS servers may be unacceptable in many organisations and the cost of doing so could be excessive. It is a shame that the directory service and DNS could not be separated more.

Static versus Dynamic Inheritance

One of the other major concerns with AD is how it handles inheritance, the process by which child objects automatically acquire access rights pertaining to their parents (see figure 3: Shaded boxes show inherited properties, and the check box can block or allow inheritance). There are two ways of doing this – known as static and dynamic inheritance.

NDS uses the dynamic inheritance model, which allows it 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 information on every single NDS object. Active Directory, on the other hand, uses static inheritance, and thus stores complete ACL information against every object in the directory. This means that if the ACL of a parent OU is updated, that change is also written to every child OU beneath it, which obviously takes up additional disk space with the redundant data.

It is something of a religious issue, however, since in most cases the difference between static and dynamic inheritance is minimal. NDS is probably more efficient in terms of directory size, since the dynamic approach ensures that multiple ACL’s do not need to be updated when access rights are changed on a parent directory (although pointers are used to refer to the parent ACL in Active Directory, thus saving space).

However, there are cases where read-time access creates problems - AD’s approach negates the requirement to tree-walk when attempting to determine access rights, for example. Under NDS, the requirement to tree-walk to determine access rights to a resource that is used sporadically (and is not represented in the local partition) could lead to access being denied if a WAN link is down and the reference cannot be resolved. In addition, there is a potential problem at the Global Catalogue level in NDS. Because of the implications of dynamic inheritance, NDS catalogues do not enforce data protection at the object or attribute level (access to data in catalogues is granted or denied at the catalogue level only). Each attempt to search for objects in the catalogue would force the catalogue to locate each underlying object in its partition, and recompute its access rights, before the search would be permitted to include the object. This search may even have to be performed across a slow WAN connection.

One claim Novell makes is that static inheritance results in inordinate amounts of replication traffic. This is not true - although there will be a fair amount of activity throughout the network! This is because AD replication is intelligent enough to know that only the initial change to the parent object that sparked the multiple ACL updates needs to be replicated to other DC’s – so only one item goes across the wire. As that single change is applied to the parent object on other DC’s, it is up to them to then recompute and apply the necessary changes to the child objects in their local AD database – a fast, efficient and, above all, local operation.

Microsoft’s explanation for static inheritance is that directories should be optimised for read (versus write) behaviour. Active Directory recomputes access control behaviours once (at the time a parent object is changed), rather than on every read operation. In addition, the impact in WAN environments is minimal. The net effect to the user between dynamic inheritance and the Active Directory inheritance model is the same.

Note also, that AD replication uses bridgehead servers, so that rather than have multiple updates fan out from a single DC to multiple DC’s across a slow link, the change is replicated to the bridgehead, which replicates to the bridgehead on the other side of the link. That remote server then replicates to other DC’s local to itself.

Catalogue Services

Catalogue services provide a cut down version of the directory database – a sort of high-level view - in order to provide higher performance for clients searching the directory tree. NDS was originally designed without a catalogue, so is very clever about the way it partitions and replicates. However, Novell recognised late in the day that replication does not solve everything, and that there is a need for catalogue services. For NDS, therefore, catalogues have been added as an afterthought, whereas AD was designed from the ground up with catalogue services.

The AD catalogue is maintained automatically alongside the AD database itself, and at least one catalogue server is required per site (see figure 4: Any Domain Controller can be made a Catalogue Server at the click of a mouse). One nice feature is that the catalogue itself creates little or no additional replication traffic since changes are piggy-backed with normal AD replicated deltas. Within a well-connected network, catalogue updates will be virtually instantaneous (meaning it does not suffer from the latency issues of the NDS catalogue). NDS uses something called the "dredger" to make mass updates to the catalogue at scheduled intervals, thus introducing latency.

Another issue is that of NDS allowing multiple catalogues. Microsoft claims that AD does not need to rely on multiple catalogues, and that NDS needs them to cover another weakness. With AD, it is possible to create copies of objects at different points in the directory and not have to follow links back to the original each time the rights need to be evaluated. This applies to catalogue entries too. So, when BOB is created as a user, if he does not have rights to view a salary attribute in the AD, then when the object is copied to the catalogue, he does not have rights to view salary attributes in the catalogue either. This is completely automatic – there is no need to follow links to the original object to evaluate rights.

In contrast, it would appear that the NDS catalogue strips ACL’s when the object is written the catalogue. The catalogue has a single ACL that allows users to view everything or nothing in the catalogue. Presumably, the reason this was done is to preserve the dynamic inheritance model. With individual ACL’s on each object in the catalogue, it would have been necessary to walk the tree back to the source object that contributed the catalogue entry in order to resolve access rights at run time – this would negate the value of the catalogue, of course. This makes it essential to have multiple catalogues. For example, if you wanted to include a salary object in the catalogue to be seen by HR personnel only, you would need to create a completely new catalogue with an HR-specific view of the directory, and make it available only to HR personnel via the single catalogue ACL.


It is apparent that on the face of it, there is not much to choose between the two technologies – providing AD performs as promised. Many of the differences between the two could be considered "philosophical" or "religious" and should not affect the customer in live implementations. In other words, we need real world implementations and benchmarks of AD before many of the criticisms can be finally proved or disproved. At the time of writing, all we have to go on is lab testing of the RC2 release of Windows 2000 Advanced Server, and these tests – together with a detailed examination of the underlying architecture and technology – do not reveal too many significant weaknesses in Active Directory.

Note this feature was based on the latest builds of Windows 2000 Server & Professional RC2