Gaining a solid understanding of directory services in general and Active Directory specifically will help in your efforts to work with Windows 2000.

A Directories Primer

Gaining a solid understanding of directory services in general and Active Directory specifically will help in your efforts to work with Windows 2000.

• By Harry Brelsford
• 04/01/2000

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.

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

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:

1. Launch the AD Users and Computers MMC from the Administrative Tools program group.
2. Right-click on the domain object in the left pane of the AD Users and Computers MMC to display the secondary menu.
3. Select New | Organizational Unit.
4. In the New Object - Organizational Unit dialog box, type the name of the organizational unit (such as Marketing).
5. 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.

We've Only Scratched the Surface

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.