Under NT Server 4.0, the security boundary is
the domain. This created administrative burdens and the physical limitations meant that
larger organisations had to create multiple domains, involving unwelcome management
overhead. Active Directory now provides the store for all domain security policy and
account information, providing replication and availability of account information to
multiple Domain Controllers. It also supports a hierarchical name space for user, group,
and machine account information, so that accounts can be grouped by Organisational Units
(OUs), rather than the flat domain account name space provided by earlier versions of NT
Server.
A question of trust
AD supports a multi-level hierarchical tree of domains should organisations still wish to
utilise domains to create trust boundaries. Management of trust relationships between
domains is now greatly simplified, however, through automatic and transparent transitive
trust throughout the domain tree. Most organisations will be able to dispense with
multiple domains altogether, relying instead on the concept of sites and organisational
units to partition their Active Directory tree both physically and logically.
Many NT-based organisations will be faced for the first time with the prospect of being
able to support their entire organisation using a single domain. While this will cause
little problem for green-field sites, those with existing complex domain implementations
will find the move problematical. The effort involved in collapsing multiple domains into
a single domain structure will pay dividends in the long run, however.
Once the domain structure has been sorted out, the administrator needs to plan the
Organisational Unit and group strategy. Although groups and OUs are totally separate
entities they do have one common feature users. To create a complete administrative
solution, the group and OU structures therefore need to be synchronised to a certain
extent, and this is one complication of Active Directory that should have been avoided.
The primary difference between organisational units within Active Directory and other
directory services such as NDS is their use as security principals. An object is a
security principal if it can be granted rights to other objects or resources.
NDS security principals, for instance, 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 OUs. NDS organisational units may also be
granted rights to resources such as file servers, Web servers, dial-in devices, and
printers. NDS users contained within the OU then automatically inherit the security rights
granted to the parent organisational units. Thus, as users are moved from one department
to another, the administrator does not need to worry about what rights need to be revoked
and what new rights need to be granted. Instead, he simply drags the user from one OU to
another in the NDS tree, and that user loses all the rights of the original OU, and
automatically gains all the rights that apply to the new OU.
Automatic inheritance
When a new user joins a company or is moved between departments, the user automatically
inherits all directory and resource rights associated with any parent organisational
units. The business benefit is time and cost savings, since administrators do not need to
know anything about what resources are needed for the users position in the company.
Network administrators can rely on NDS to calculate each users rights based on their
location in the directory, rather than having to define explicit rights for each user in
the network this is how a directory service should work.
Active Directory organisational units, on the other hand, are not security principals - AD
security principals are still limited to users, groups and computers. Active Directory OUs
cannot be granted rights to other domain objects, or to any corporate resources such as
file servers, Web servers, and printers. Using Active Directory, only users, groups and
computers can be granted rights to other directory objects and corporate resources.
Since Active Directory OUs are not security principals, NT servers cannot leverage their
domain structure in the same way as NDS. When a user joins the company, the administrator
must know what the user needs to accomplish in his or her job, then remember which groups
provide the necessary directory and resource rights. Lastly, the administrator must add
the user to the appropriate groups.
The reliance on groups is far too heavy in AD. Groups will always be needed for some
things (they are still available in NDS too), but AD forces administrators to duplicate OU
contents with groups simply in order to grant rights to directories and other network
resources. In other words, the organisational unit with AD is used purely for delegating
administrative rights, and nothing more. Later releases of the Beta code have made things
slightly easier by providing an option when the administrator right clicks on an OU in the
Users and Computers administration utility that says "Add members
to a group". This allows all objects contained within the OU to be quickly
added to a group for subsequent security administration purposes. All it is really doing,
however, is making it a little easier to duplicate information already painstakingly
entered into the OU hierarchy, and it is further marred by the fact that the group has to
be created in advance of this operation.
New additions
None of this is helped by the fact that groups are further complicated in Windows 2000 by
the addition of a new group scope Universal to join the
existing Global and Domain local groups. Two additional types
security and distribution further increase the
number of possible permutations, allowing administrators to create groups for security
reasons (as before) or to be used as address lists for AD-aware applications. One of the
nice things about groups in Windows 2000 is the fact that, at last, they can be nested one
inside another at least they can once a network has switched from mixed mode to
native mode (i.e. running all Windows 2000 servers).
The true nature of AD "security" is revealed by the first menu option proffered
when the administrator right clicks on an OU "Delegate Control".
Here the wizard walks the administrator through the task of delegating administrative
responsibility for that particular OU to a user or group of users. Each user can be
allocated full control or a subset of administrative privileges (such as reset passwords,
create new users, and so on), and this allows numerous administrators to be granted
autonomous control of their own resources on a per-OU basis rather than having to create
new domains as with previous versions of NT. Administrative rights granted at higher
levels of the tree can flow down to child OUs automatically via the process of inheritance.
Unfortunately, whilst it is possible to look at the Security tab of an OU and check
manually which groups and users have administrative control, there is no equivalent means
of checking a user object to see which OUs he or she has been granted control of. This
smacks of an ideal opportunity for some third party auditing software, since it is an area
of potentially huge confusion for administrators.
The OU should be made a security principal, allowing it to be used to grant access other
network resources such as servers and directories. It would also be nice to see the file
system security brought into AD too. My prediction is that unless Microsoft heeds the
criticism levelled at it, NDS will quickly become the de facto directory service and
security administration interface for both NetWare and NT environments, relegating AD to
little more than a fancy hierarchical naming service for Windows 2000.