|
DNS Integration
 DNS 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.
Summary
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 |
