A Directories Primer

Directory services are at the top of the many lists when
it comes to justifying a Windows 2000 implementation.
This month I explore why there's such a focus and enthusiasm
for directory services. After defining Active Directory
(AD), the directory services implementation in Win2K,
I'll compare and contrast directory services in Win2K
to what we have with Windows NT and Windows 3.1/Windows
for Workgroups.

A Definition

Directory services means different things to different
people. If you get on an elevator and somebody asks for
an explanation of directory services, you won't have sufficient
time to answer the question before you have to get off
many floors later. So here I provide a list of definitions-some
I agree with; others I don't. A good definition depends
on your requirements.

Ultimate computer network index.
The ability to query the information system infrastructure
for information, locations of data, settings, etc.

Ultimate computer network telephone
book. A popular view of directory services that
speaks towards the management of computer, group, and
user objects.

Ultimate war room/mission control
center. You can organize your network as you
see fit and create domains and organizational units
(OUs) that reflect the geopolitical structure of your
firm. You can also manage what is called the namespace,
such as the Internet domain names, used in your organization.
And don't forget security, another important role for
directory services. Finally, the directory services
schema contains definitions of objects and attributes
(the data) for those objects.

Ultimate growth path. As
a system-wide database, a directory service must be
able to accommodate growth in the organization, including
mergers and divestitures.

Ultimate reliability. A
directory services mechanism must be accessible, backed
up, accurate and otherwise reliable. It contains core
information about your information system infrastructure,
and it must necessarily maintain the confidence of you
and your users. This is typically accomplished by replication.
That is, all or parts of the directory services database
is maintained on different servers. A terribly complex
little devil called a Global Catalog Server (this is
a designation and honor for a server that holds this
title) plays a huge role in facilitating the replication
process.

Ultimate Unification. A
goal of all directory services, one that is achieved
by none, is the ability to set a single sign-on/single
database standard for everything on the network. That
means the accounting software package you work with
would use the network user name and password for logon
purposes, and information changes made to a person inside
the accounting system would be duly noted by the directory
services. This generation of directory services is making
strides towards the ultimate unification goal. An example
of this is how Exchange 2000 will be AD-aware. Unification
also means different networks and operating systems
could share critical authentication and configuration
information. But, alas, the ultimate unification strategy
is a metadirectory, still the stuff of Ph.D. thesis.
[For insights on meta-directories, read
Michael Chacon's column in this issue, April 2000.
-- Ed.]

Customizable Database.
Believe it or not, you can use AD to perform some minor
database functions (but I'd certainly recommend SQL
Server instead). For example, you can store user contact
information along with photos and other graphic images
if you desire.

To reiterate an early point, AD is the directory services
mechanism in Win2K. Other competing directory services
include Novell's NDS and Banyan's StreetTalk.

You're most likely to see and interact with AD via any
one of the three following Win2K Server Microsoft Management
Consoles (MMCs): AD Domains and Trusts (Figure 1), AD
Sites and Services (Figure 2), and AD Users and Computers
(Figure 3).

Figure 1. Larger companies and
enterprises use the Active Directory Domains and Trusts
MMC to manage large sites.

Figure 2. AD Sites and Services
is one of the best ways to see how AD interacts with
your physical network (such as your IP subnet).

Figure 3. The most common tool
for interacting with AD is the AD Users and Computers
MMC. It's here where you manage object such as users,
computers, and OUs.

Top-Down

You'll need to understand the following objects when
designing, planning for, and discussing anything related
to AD. After defining each object, I'll try to wrap it
all together in two figures. I'll start the object discussion
from a top-down perspective. That is, I'll start with
the broadest object and work my way down to the narrowest
one.

Objects

First, you need to understand that AD is typically viewed
from a logical perspective without regard for the physical
location of your offices, servers, or people. The primary
logical objects related to AD are: Forests, Trees, Domains,
and Objects.

Tip:

One word of advice on trying
to understand AD. Read this section all
of the way through with an eye cast only
towards the basic meanings. Then, after
pausing, reread the section again. Why?
Because with the top-down approach, some
definitions are used that, quite frankly,
haven't been defined until a paragraph
or two later. Another approach on your
second pass is to read this section backwards,
starting at the bottom and working your
way up to the forest definition.

Forests

A forest is a collection of trees, much like the ones
in the real world. It's the highest-level or broadest
object we'll discuss in the context of AD. You can have
multiple forests in your AD and might well do so to accommodate
subsidiaries, outside business entities, or merger partners.
To be honest, this ability to have multiple forests in
your AD is a real-world lifesaver; it allows for unforeseen
events such as hostile corporate takeovers.

Graphically, a forest is sometimes represented by a large
box that contains everything else. In Figures 5 and 6,
you'll see a forest. Speaking from an AD management perspective,
you're most likely to discuss forests in only the largest
enterprises. Smaller and medium-size organizations (SOMO)
wouldn't typically use the "f" word (Forests).

Trees

Simply stated, trees are a collection of domains, typically
arranged in a hierarchical view. A characteristic of trees
is that they share a common root domain name, such as
expectationmanagment.com.

Larger organizations, such as enterprises, actually speak
of trees. SOMOs are unlikely to really have anything to
do with trees. A tree appears as lines connecting multiple
domains, but doesn't implicitly have a shape itself. In
Figures 5 and 6 you'll see trees displayed.

Domains

Win2K domains are the same as what you've known under
Windows NT -- with a few new twists. Officially, Microsoft
defines domains as a container of objects that share:

Security requirements

Replication processes

Administration

Tip:

All domain controllers are
equal in a domain under Win2K. Domain
controllers are Win2K Server machines
charged with performing security/administrative/replication
duties. Note that there are no primary
and secondary domain controllers in Win2K.

Considered to be the core unit (OK, center of the universe)
in AD, domains now are assumed to take on the name of
your registered Internet domain name. And in the Zen of
AD, your internal network domains (similar to your NT
domain) and your registered Internet domain are one (sit
on the floor and assume the Zen-like Lotus position as
you read this). Also note that the top-level domain is
called the parent domain, and the lower-level domains
(typically placed beneath the parent domain in a figure)
are child domains. For you Internet geeks, this translates
into second- and third-level domain names. Organizations
of all sizes would both use and speak about domains. The
relationship between domains and organization size is
direct. Larger organizations would have multiple domains;
many SOMOs will have as few as one.

A domain is represented by the triangle shape in Win2K
Server.

Organizational Units

Organizational Units (known as OUs), are one of the coolest
things in AD and represent administrative units. An OU
is a container that holds other objects, such as nested
OUs, users, computers, etc. I especially like OUs for
both the pragmatic role they assume and the great aid
OUs bring to the design effort. For example, I find the
fact that the Marketing department would have an OU titled
"Marketing" to be very practical. I also recommend
that AD design inherently start with a simple OU. Successive
OUs should be added only when all parties reach consensus
and such a move is justified.

An OU is typically represented by a circle. All organizations
implementing Win2K and Active Director would use OUs.
The steps to add an OU are:

Launch the AD Users and Computers MMC from the Administrative
Tools program group.

Right-click on the domain object in the left pane
of the AD Users and Computers MMC to display the secondary
menu.

Select New | Organizational Unit.

In the New Object - Organizational Unit dialog box,
type the name of the organizational unit (such as Marketing).

Click OK. The OU will be created.

Objects

A picture is worth a thousand words. In Figure 4, you'll
notice that several objects, ranging from computers to
a shared folder, can be added to an OU.

Figure 4. Adding new objects
to an OU occurs when you select the New menu option
from the OU's secondary menu.

I'll briefly describe each object:

Computer. The computer account for all Win2K
and pre-Win2K machines. This allows the computer to
participate in the Win2K security model.

Contact. An AD contact record, not a Microsoft Outlook
or Microsoft Exchange contact record. It isn't very
useful (yet!).

Group. Where you create a security or distribution
group. Security groups relate to rights and permissions.
Distribution groups relate to sending messages to a
group of accounts.

Printer. You can create a printer object,
which allows you to manage printer access and other
chores.

User. You can create the user account object.
Note that you'll create the user logon name for Win2K
environments, which looks very much like an Internet
address and the user logon name for pre-Win2K environments.

Shared Folder. You can create a shared folder
object that can be recognized and managed by AD.

Objects such as those listed immediately above are the
lowest level of interaction you will have with AD. All
organizations of any size using Win2K and AD would use
objects.

Sites

On a distant but related note, sites are used to show
to the physical network (typically the TCP/IP subnet).
As such, discussing sites doesn't fit very well with the
Forest-through-object discussion above that's based on
logical views. Organizations of all sizes would discuss
sites in the context of the physical network.

Bringing It All Together

Now that you've seen the full breadth of AD, look at
Figure 5 to see how all of the logical AD components are
brought together. In Figure 6, I overlay the "physical"
view of sites over the logical view of Active Director
components.

Figure 5. The big picture view
of AD.

Figure 6. Relating the logical
and physical AD views.

Compare and Contrast

This section will compare and contrast Win2K's AD with
the alleged directory services in Windows NT and the way
that such system information was managed in Windows 3.x/Windows
for Workgroups). I'm hoping this provides you with a bit
of context for AD that will make it an easier concept
for you to understand and work with.

Item

Windows
2000

Windows
NT

Windows
3.x/WfW

"Directory" or
"Directory Services"

Active Directory

Domains

Folders and Sub-directories

Single sign-on

Yes

Yes

No

Interoperability between
OS and applications

Yes for AD-aware applications.

Interoperability between
OS and Microsoft Exchange and SQL Server.

Fonts installed at OS-level,
not at application-level.

Interoperability between
different OSs.

Stronger than ever with
LDAP standard.

Limited. Had to use NFS
clients, NetWare Gateway (GSNW) to achieve
limited interoperability.

So there you have it. Directory services is such a huge
topic, we've barely had a chance to scratch its surface.
Before I close, I want to share a few final thoughts.
First, remember that the whole directory services and
AD area is truly the big leagues and, as such, will affect
larger organizations much more than SOMOs. Second, this
is a complex area. When your company begins working with
AD, I suggest you engage the services of a bona fide AD
architect to assist you. Third, AD is a notoriously hostile
political area where the MBAs and MCSE battle it out.
The MBAs trying to influence the "shape" of
the organization, and the MCSE wants to win the technical
war (such as having an efficient WAN). And fourth, you
might avail yourself of my forthcoming AD book, Active
Directory Design and Planning, written for both MCSEs
and MBAs. It'll be out in early summer.