4620-1 ch11.f.qc 10/28/99 12:28 PM Page 411
Managing Active Directory expectations
Defining Active Directory
Taking a logical view of Active Directory
Taking a physical view of Active Directory
Comparing and contrasting Active Directory and Domain Name System (DNS)
Learning the 4 P’s of Active Directory planning
M ind if I spend a few minutes engaging in Windows 2000 Server expectation management? No Windows 2000 Server feature I can think of has received more publicity and advanced buildup than Active Directory. While you will enjoy Active Directory very much, the power of which I will unleash over the next two chapters, you must also manage your expectations. With such hype, many are looking to Active Directory to solve world population problems and the like. You and I are bound to be disappointed at some point with Active
Directory while working with Windows 2000 Server. Why? For several reasons:
■ Learning Curve.
First, the more time you spend with Active Directory, the more you will be able to see for yourself its relative strengths and weaknesses. Early on in your Windows 2000 Server experience, you’re not qualified or experienced enough with Active Directory to make that decision.
■ Red Head Revenge.
Get ready for this barrage. NetWare prophets will dance madly, celebrating the fact the NDS is more mature, more stable, more everything than first-generation Active Directory. As a former
Novell NetWare practitioner (a.k.a. Red Head) and current Certified
NetWare Engineer (CNE), I see both sides. NDS is now over five years old; this is not the case with Active Directory. And because no operating system is immune to the necessary and lengthy process of debugging
(er...perfecting), it is true NDS has aged very nicely and shows the signs of maturity that Active Directory doesn’t. Throw this into the expectation management stew.

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 412
■
412 Par t IV: Active Director y and Security
■ Growing Pains.
Many of us MCSE types are also forming families at home when we’re not designing Active Directory trees. Just as your child first turns over, then crab walks around the house, takes baby steps, and ultimately walks, the same forces of nature apply to Active Directory. It’s safe to say that Active Directory is in its infancy, and will have some growing pains. Some will be humorous, others painful.
■ Great Expectations.
The one thing you can count on is that Active
Directory will improve. To attain these improvements, it will necessarily undergo changes via additions and deletions to its core feature set. In short, the Active Directory you work with today won’t be the same
Active Directory that your children will work with.
But enough about Active Directory expectation management. What are these two Active Directory chapters really about? This chapter, Active Directory Part
I, is about planning. The next chapter, Active Directory Part II, is practical and pragmatic with an emphasis on implementations, rollouts, and even keystrokes you will perform. So, in the next few pages, I speak to the solution architects amongst us. Next chapter, I honor the in-the-trenches gang, the hands-on
MCSE-types. Enjoy!
Because Active Directory is new on the Windows 2000 scene, I am right there with you in defining what Active Directory is. Two reference points that I’m using to better understand Active Directory are based on my life experiences in technology. A reference point is data structures in C programming. For the uninitiated, data structures are where you define what data and information are at a very foundational and object level.
Another more pragmatic reference point for relating to Active Directory is
NetWare’s NDS; this is Novell’s directory services offering that I discussed in the introduction of this chapter. What parallels to Active Directory might you draw from your own technology background? I’d encourage you to engage in this intellectual exercise for a few minutes so that you’re better prepared to learn the new terminology and constructs associated with
Active Directory. Remember that learning is often a function of having reference points that relate well to something new and unfamiliar.
Technically speaking, Active Directory is based on the Lightweight Directory
Access Protocol (LDAP). LDAP is actually a heavyweight component in the whole directory services arena, so its name is somewhat misleading. It is the industry standard protocol used to access Active Directory and integrates
Active Directory with the Internet. LDAP performs several functions. First,
LDAP facilitates the descriptive entries in the directory database. Second,
LDAP is the hierarchical tree that facilitates each object’s unique pathway in
Active Directory. Next, LDAP provides the query mechanism for retrieving information. Last, and certainly not least, LDAP accommodates authentication protocols, meaning only authenticated users can access information.
■

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 413
■
Chapter 11: Active Director y, Par t I
The “official” party line from the Big M (Microsoft) is that Active Directory is the directory service in Windows 2000 Server that identifies and manages all network resources. Active Directory can be considered from two viewpoints: size and capabilities.
To be honest, my smaller clients won’t initially benefit from Active Directory.
These are typically the Small Business Server (SBS) sites that will continue to function just fine under Windows NT Server 4.0’s single domain model
(something I discuss at length in Chapter 16). Enough said. Contrast that with the large electronics manufacturing firm mentioned in Chapter 15.
Without naming names, this firm and its 140,000 users span the entire reach of the globe. Active Directory was designed with this firm in mind.
Back to basics for a minute. Active Directory essentially provides basic directory management capabilities or “services, hence the term directory services . Active Directory provides a way to organize, manage and enable access to resources on the network. Much like a real-world directory, such as an Internet white pages (for example, www.whowhere.com
), users may use
Active Directory, whether they really know it or not, to locate and use network resources.
Active Directory is designed to make your life as a Windows 2000 Server professional easier. This is accomplished by its capability to query objects in the Active Directory tree, replicate itself to prevent damage from system failures, lay down the law so that unauthorized access is prohibited, and integrate with other operating systems and directory services.
In this first iteration of Active Directory, there are some glaring omissions. But hey — who’s to say that Microsoft won’t get it right for the third generation of
Active Directory? If you think back to just a few years ago, it’s not like NDS was code-complete with the first release of NetWare 4.
x either.
The two most obvious limitations in Active Directory today are its continued reliance on multiple layers of groups (especially local and global) and its non meta-information orientation. Using multiple group layers is offensive to those of us who come from the NetWare community. Active Directory retains the global and local groups of Windows NT Server and even adds universal groups. But I for one can live with the groups. Less easy to live with is Active
Directory’s myopic view of the directory as an operating system thing. What I had hoped for and don’t see is true meta-information management. Metainformation is best described as uniform information. That is, when you add
413
■

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 414
■
414 Par t IV: Active Director y and Security a user to a computer system, the user accounts in the e-mail, database, human resource, and accounting systems are automatically created. You see hints of it when you add a user and the user is automatically added as a
Microsoft Exchange recipient, but what I really needed to see is that the basic user information you enter for a user automatically populates a Contact form in a Public Folder-based Contacts file in Microsoft Outlook. That’s an example of something that’s practical and you and your users would really use. It’s simply not present in Active Directory at this time.
Time for a virtual visit to Active Directory. Before getting physical, let’s first define Active Directory logically. The components include
■ Objects
■ Domains
■ Organizational units (OU)
■ Trees
■ Forests
I will now define each of the components.
Objects are relative to exactly what you’re speaking about. That is, objects mean different things to different people and at different times. For example, objects can be viewed from a very granular level. You might say that a user is an object.
There is something in Active Directory called a container object.
Strictly speaking, container objects house other objects. An example of this is the organizational unit (OU), which I will define later in this chapter. In the
NetWare community, these (Windows 2000 Server’s container objects) are akin to containers.
And then there is the issue of the object food chain (see Figure 11-1). Objects have characteristics that are called attributes. Attributes have values. An attribute might be the zip code field and a value for that might be 99005.
Objects may be represented by a variety of shapes, including machines, people, and folders (see Figure 11-2).
■

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 415
■
Chapter 11: Active Director y, Par t I 415
■
Object Attribute
Figure 11-1: Object food chain
Object Food Chain
Value
Computer
Figure 11-2: Objects
User Folder
In the context of objects, a schema is akin to a data dictionary. A schema consists of the definitions and rules for all objects in the Active Directory.
Plainly speaking, a global catalog stores information that contains a subset of all objects’ attributes in an Active Directory. Via the global catalog, the location of an object in the directory can be determined quickly. I’ll discuss global catalog servers later in this chapter.
A quick quiz for the legacy MCSEs reading this book. If you were taking the
Windows NT Server 4.0 Enterprise exam on the TV show “Jeopardy,” where you have to try to guess the answer with a question, what would the question be for the following? “The answer is, core administrative unit”? Well, you guessed it. The question would be, “What is a domain?” Fast forward to
Windows 2000 Server and both the question and the answer are still the same.

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 416
■
416 Par t IV: Active Director y and Security
Huh? Didn’t that Microsoft Certified Trainer tell me in my MCSE classes that domains would disappear in Windows 2000 Server? Well, that MCT was wrong. Get over it. While the domain serves as an administrative unit in Active Directory, it’s probably better cast as a security unit. That is, domains really define security boundary lines. Because of this Active
Directory feature, you can have a sub-administrator who can only manage his or her explicit domain. Again, not very exciting for the small company, but a wonderful feature for the large enterprise deploying Windows 2000
Server. And just what is the importance of security boundaries? For that answer, be sure to catch my lead-in to Chapter 19, where I discuss the power of corruption in both political and networking circles.
Domains are typically represented by a triangle shape (see Figure 11-3).
■
TCI
Domain
Figure 11-3: Domain
Those from the NetWare community will now find common ground with
Windows 2000 Server’s Active Directory. Even MBAs from the business side of the organization get it when it comes to organizational units. Just as the name implies, organizational units typically reflect a grouping of users, groups, other OUs, and so on. The point is that, more often than not, organizational units reflect the alleged structure of the organization (that is, how it officially perceives itself, the grapevine and gossip aside).
It is with OUs that the touchy-feely management consultants will reap the rewards of Windows 2000 Server deployments. It is here that they can interpret the departmental and geographical boundary banter to create
OUs that reflect the organizational structure of the firm.
MCSEs, on the other hand, will initially view OUs from the perspective of administrative responsibilities. One example might be creating an OU for printers to simplify the management of printers in the enterprise.
OUs are typically depicted as circles (see Figure 11-4).

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 417
■
Chapter 11: Active Director y, Par t I 417
■
Organizational
Unit (OU)
Figure 11-4: Organizational unit (OU)
You would think you’ve stumbled into the wrong classroom. Perhaps you were on your way to attend an MCSE course on Windows 2000 Server at a local college, but mistakenly in your confused state you find yourself in an
MBA class, listening to a lecture about seeing the forest for the trees. It might take you more than a few minutes to realize you’re attending the wrong class. That’s because Active Directory not only uses the forest-andtrees terminology, but uses these metaphors in a manner similar to the
MBA community.
An Active Directory tree is a top-down configuration of one or more Windows
2000 domains. A simple Active Directory tree is displayed in Figure 11-5.
TCI
Domain
TCI-1a TCI-1b TCI-1c
Domain Domain Domain
Figure 11-5: Active Directory tree
A tree in Active Directory is conceptually similar to a tree in NetWare’s NDS.

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 418
■
418 Par t IV: Active Director y and Security
A domain that is added to an existing tree becomes by definition a child domain of an existing parent domain. This is conceptually similar to sites in Microsoft System Management Server (SMS), where the parent/child relationship is also employed.
Maybe you thought life was getting better and you left trusts back with
Windows NT Server 4.0. Not so. Trusts are back, albeit they have gotten mysteriously more palatable. Active Directory supports two types of trusts: two-way transitive trusts and one-way transitive trusts.
Hallelujah! Transitive trusts, the ultimate trick question on the Windows NT
Server 4.0 Enterprise exam, now exist in Windows 2000 Server. Transitive trusts are easily understood. Borrowing from Figure 11-5, if Domain TCI-1a trusts TCI-1b and TCI-1b trusts TCI-1c, then by strict definition, TCI-1a trusts
TCI-1c.
A two-way trust is the same as it was in Windows NT Server 4.0. Here, Domain
TCI-1a would trust TCI-1b and vice versa.
Even though the Windows 2000 Server exams haven’t been created as of this writing, be aware that a common trick question regarding trusts focuses on the wording. Here is what I mean: It is common to say “two-way trust” when that is the situation that you are describing. But it is also permissible to say
“two one-way trusts” to describe the same situation. The MCSE exams have been known to use the play-on-words ploy.
Simply stated, the fact that Domain A trusts Domain B doesn’t mean that
Domain B automatically trusts Domain A. It’s a one-way trust, not the twoway trusts discussed previously. In the legal community, it would be stated as reciprocity not being a given.
The small business folks can skip to the next section. But the enterprise folks will easily visualize an Active Directory forest . A forest is a grouping of Active
Directory trees, as the name would imply. Very simple metaphor, eh?
There are several physical planning considerations with Active Directory, including sites, domain controllers, and global catalog servers.
■

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 419
■
Chapter 11: Active Director y, Par t I
If you’re a brazen BackOffice warrior, you’ve bumped into sites already. But you might recall that a site in Exchange is a different site or boundary from a site in SMS. And a domain, a type of site, is a different type of site from an IP subnet, which is the underlying definition of a site in Active Directory.
Officially speaking, an Active Directory site is one or more IP subnets that are connected via high-speed links. These links can be LAN or WAN in nature, but are assumed to be over 128Kbps (that’s two-channel ISDN speed). Note that subnets are discussed extensively in Chapter 7 as well as other chapters in
Part II. The basic modus operandi behind sites is to speed Active Directory replication traffic and facilitate reliable user logons to domains.
Here’s a braintwister for you. A single site may have multiple domains, yet a single domain may span multiple sites.
This should be a fairly easy definition for you. The Windows 2000 Server that stores a replica of the directory is a domain controller . This makes a lot of sense if you think about it. From your Windows NT days, you may recall that a domain controller contained a copy of the security accounts manager
(SAM), permitting local logons to the bigger domain. If you accept the basic premise that Active Directory is a newer and more improved SAM, then the notion that a domain controller contains a directory replica makes perfect sense.
Active Directory behaves like the old SAM model in that it acts as the security subsystems and manages access authentication, data storage, security model, and trust information.
But there’s a slight twisted end to my tale. Active Directory borrows a page out of the NetWare NDS book and uses multi-master replication. Here, come hell or high water, no single domain controller is the master domain controller. Instead, all domain controllers maintain directory copies.
At any given moment, one domain controller may contain some information in its directory copy that hasn’t been replicated to the other domain controllers yet. Thus, the purpose of replication is to distribute such delta changes as often as is practicable. If you haven’t had a course in statistics, you might need to know that delta represents only the changed values. So only the changes to the database are distributed, not the entire database. Two design issues you will encounter are concerns about where to place domain controllers (for example, across slow WAN links) and how often domains replicate their directory changes.
419
■

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 420
■
420 Par t IV: Active Director y and Security
Simply stated, a global catalog server stores and processes a global catalog.
Global catalogs were discussed earlier in this chapter (they are used to enhance performance when searching through Active Directory forests).
Time for a little compare and contrast. Exactly what is the relationship between Active Directory and DNS? Certainly the underlying common relationship relates to name space. DNS provides name resolution and
Active Directory names things.
Whereas Active Directory may consist of one or more domains, DNS identifies domains. The domain names compare straight across very well:
DNS and Active Directory share the same domain names. However, by contrast, DNS creates and manages zone records and Active Directory creates and manages domain objects. Note that DNS is discussed extensively in Chapter 6.
Each Active Directory domain requires a unique DNS domain.
Tying it all together, understand that LDAP is the “glue” between Active
Directory and DNS. It is the protocol that enables the two distinct bodies to communicate and interact.
The goal of this chapter, as stated earlier, is to provide a planning platform for your implementation of Active Directory. It’s critical to revisit that underlying theme as I continue to manage your Active Directory expectations and conclude this chapter.
Early on with Active Directory, you will encounter the four P’s of Active
Directory planning: politics, physical issues, perspectives, and practical considerations.
Many solutions architects will make good money just operating in the political realm as they design and introduce Active Directory into the organization.
That’s because Active Directory, with its boundary orientation, calls into question what resources belong where in the organization and who controls them. Thank goodness for the capability to have administrators at the single domain-level so the political considerations relating to empowerment and decentralization may be easily accommodated. And you always wanted to work on a political campaign, right?
■

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 421
■
Chapter 11: Active Director y, Par t I
On the one hand, the physical location of resources really doesn’t matter under Active Directory. This is similar to the strict domain concepts in
Windows NT Server. It doesn’t matter if a machine is located in Building 42 or Building 55 on the campus. Here, when talking about locations, the logical groupings of physical things win every time. In other words, you might group everyone in the marketing area into an OU called Marketing, even thought these people are physically located, shall we say, across state lines.
And as far as Active Directory is concerned, I’ve already defined its physical attributes via the discussion on objects, sites and the like.
However, there is one physical concern mentioned in passing to which you should pay careful attention. The concern relating to replication is paramount. A poorly designed WAN, at the true enterprise level, could suffer poor Active Directory performance due to slow logons, replication traffic choking the links, and so on. Be advised.
This chapter and this book were written to convey a broad array of secrets, tips and tricks relating to Windows 2000 Server. It’s a tall order because almost any chapter could easily be a book in itself. In fact, there are many good books on
Active Directory (and they’re thick, too!). The point is this. You need to keep a proper perspective on Active Directory. It’s not an area sufficiently covered in one or two chapters of any book. Rather, your next step as you embark on the study of Active Directory is to take the foundational Active Directory knowledge garnered from this and the next chapter and leverage upon that as you acquire and use a specialized Active Directory book. In such a specialized book, you will gain insights into advanced directory issues such as:
■ Multidomain directories
■ Replication
■ Naming strategies
■ Administrative authority
■ Active Directory data recovery
■ Active Directory maintenance
■ Schema modifications
■ Integration with Microsoft Exchange
■ Windows NT Server domain upgrades to Active Directory
I would also encourage you to avail yourself of some or all of the following
Microsoft certification courses. It will be essential for MCSEs to heed this advice in order to remain competitive.
421
■

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 422
■
422 Par t IV: Active Director y and Security
■ Course 1560: Updating Support Skills from Microsoft Windows NT 4.0 to
Microsoft Windows 2000
■ Course 1561: Designing a Microsoft Windows 2000 Directory Services
Infrastructure
■ Course 1562: Designing a Microsoft Windows 2000 Networking
Infrastructure
■ Course 1563: Designing a Change and Configuration Management
Infrastructure for Microsoft Windows 2000 Professional
The preceding course titles and numbers are subject to change by Microsoft
(and frequently are!).
Above all, keep your wits about this Active Directory stuff. It’s easy, much like the aspiring MCSE in the old Windows NT Server days, to over-design an Active Directory. Stay practical and justify each and every layer of complexity you introduce into your Active Directory. Let’s face it, most of us work for firms that are not in the Fortune 1000. Statistics show that more people (namely, end users) are employed by small- and medium-sized organizations than by enterprises. So in Microsoft’s justifiable enthusiasm to conquer the enterprise, understand that its written works and that of many authors speak towards organizations that are global in scale.
The best advice I was ever given by a peer relating to NetWare’s NDS also applies equally well to Active Directory. Over lunch at a Tex-Mex restaurant, this NetWare guru told me to just keep it simple and “throw everything into one OU.” He was basically communicating, in NetWare terms, to start from the bindery perspective. In Windows NT Server terms, that would translate into throwing everything into a single domain. In Active Directory terms, the translation is straight across: Start by throwing everything into a single OU.
Now, of course my lunch buddy was advising me on a medium-sized network that had been over-engineered and super-sized by the last network engineer, but you get the point. Start simple. If you’re a smaller organization, truly put everything in one OU and then “discover” why you would need and can justify increasing levels of complexity in your Active Directory. Call it the
Zen of Active Directory.
■

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 423
■
Chapter 11: Active Director y, Par t I
This ends the high-level view of Active Directory planning topics. In the next chapter, a more pragmatic Active Directory approach is presented. In this chapter, the following topics were discussed.
Managing Active Directory expectations
Defining Active Directory
Taking a logical view of Active Directory
Taking a physical view of Active Directory
Comparing and contrasting Active Directory and Domain Name System (DNS)
Learning the 4 P’s of Active Directory planning
423
■

4620-1 ch11.f.qc 10/28/99 12:28 PM Page 424