.
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 (see figure 1). 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 (see figure 2). 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 (see figure 3).
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" (see figure 4). 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.
That’s all we have space for this month. Next month we will continue our comparison
by looking at DNS integration, inheritance and catalogue services.
Note this feature was based on the latest builds of Windows 2000 Server & Professional
RC2
 |
|
