In Windows NT, administrators were introduced to the concept of domains. Active Directory Domain Services (AD DS) builds on that concept by creating a dynamic, easily accessible structure through which directory and management information can be stored and accessed centrally throughout an organization. By using AD DS, you create a structure for managing your equipment and the people who use that equipment, which is a helpful feature for all but the smallest of operations.
By using Active Directory as a whole, you have access to several cool management tools, including Group Policy (GP), the ability to put groups inside groups multiple times, and an online directory of users, computers, printers, and contacts that you can access easily through the Windows user interface. Although you certainly can operate a Windows-based network without Active Directory deployed in some form, you lose out on a lot of functionality. You will learn about these tools in this chapter and the next.
In this chapter, I'll introduce you to Active Directory and its concepts, walk you through the process of building an AD DS domain and tree structure, guide you through the process of managing domain users and groups, and discuss in detail the process of directory content replication. I'll also discuss different roles that domain controllers take in an AD DS environment, the importance of time synchronization and how to accomplish it, and how to keep your AD DS deployment in tiptop shape through regular maintenance.
There's a lot to cover in this chapter, so let's dig in.
First it's important to learn that you can divide AD DS components into two "states of being"—physical components, which include domain controllers, sites, and subnets; and logical components, which include forests, trees, domains, and organizational units. Physical and logical components of AD DS don't necessarily have to correlate with each other: for example, a domain controller can be a member of a forest based in Rome, while actually sitting in a machine room in Chicago.
Keep that frame of reference in mind. Now, before diving in any further, let me introduce a few common terms:
- Directory
A directory is a single repository for information about users and resources within an organization. Active Directory is a type of directory that holds the properties and contact information for a variety of resources within a network so that users and administrators alike can find them with ease.
- Domain
A domain is a collection of objects within the directory that forms a management boundary. Multiple domains can exist within a forest (defined later in this list), each with its own collection of objects and organizational units (also defined later in this list). Domains are named using the industry-standard DNS protocol, covered in detail in the previous chapter.
- Domain controller
A domain controller holds the security information and directory object database for a particular domain and is responsible for authenticating objects within their sphere of control. Multiple domain controllers can be associated with a given domain, and each domain controller holds certain roles within the directory, although for all intents and purposes all domain controllers within a domain are "equal" in power. This is unlike the primary and backup labels assigned to domain controllers in Windows NT.
- Forest
A forest is the largest logical container within AD DS and encompasses all domains within its purview, all linked together via transitive trusts that are constructed automatically. This way, all domains in a particular forest automatically trust all other domains within the forest.
- Organizational unit
An organizational unit (OU) is a container with objects (discussed next) contained within it. You can arrange OUs in a hierarchical, tree-like fashion and design them in a structure that best fits your organization for boundary delineation or ease of administration.
- Object
Within AD DS, an object is anything that can be part of the directory—that is, an object can be a user, a group, a shared folder, a printer, a contact, and even an OU. Objects are unique physical "things" within your directory and you can manage them directly.
- Schema
The schema in AD DS is the actual structure of the database—the "fields," to use a not-quite-applicable analogy. The different types of information stored in AD DS are referred to as attributes. AD DS's schema also supports a standard set of classes, or types of objects. Classes describe an object and the associated properties that are required to create an instance of the object. For example, user objects are "instances" of the user class; computer objects are "instances" of the computer class; and so on. Think of classes as guideline templates describing different types of objects.
- Site
A site is a collection of computers that are in distinct geographical locations—or at least are connected via a permanent, adequate-speed network link. Sites are generally used to determine how domain controllers are kept up-to-date; AD DS will select its methodology for distributing those updates (a process called replication) based on how you configure a site to keep traffic over an expensive WAN link down to a minimum.
- Tree
A tree is simply a collection of domains that begins at a single root and branches out into peripheral, "child" domains. Trees can be linked together within forests as well, and trees also share an unbroken DNS namespace—that is, hasselltech.local and america.hasselltech.local are part of the same tree, but mycorp.com and hasselltech.local are not.
- Trust
A trust in terms of AD DS is a secure method of communicating between domains, trees, and forests. Much like they worked in Windows NT, trusts allow users in one AD DS domain to authenticate to other domain controllers within another, distinct domain within the directory. Trusts can be one-way (A to B only, not B to A), transitive (A trusts B and B trusts C, so A trusts C), or cross-linked (A to C and B to D).
When examining AD DS for the first time, it's easiest to examine the domain first because so much of the basis of AD DS is derived from the domain. It's adequate to boil down the function of domains into three basic areas:
Consolidating lists of usernames and passwords for all machines within a domain and providing an infrastructure for using that consolidated list
Providing a method of subdividing objects within a domain for easier administration (into OUs, as described earlier)
Offering a centralized, searchable list of resources within the domain so that users and administrators can easily query that list to find objects they need
Domains, at a minimum, keep a list of all authorized users and their passwords on a machine or groups of machines called domain controllers. This list is stored in AD DS. However, many other objects are stored within the directory—which is actually a file on a domain controller's hard drive called NTDS.DIT—including sites, OUs, groups of users, groups of computers, GPOs (described in Chapter 6), and contacts, just to name a few.
The engine that drives this database of information is the same engine within Microsoft's powerhouse Exchange Server product, and it supports the transmission of database contents to multiple domain controllers over network links—a process called replication. Replication answers the question of how multiple domain controllers within a domain can contain the same information. For example, if you have a domain controller in Seattle and another in Charlotte, and you were to add a user in Charlotte, what if that user tried to log on to a computer in Seattle? How would the Seattle domain controller know about the user added in Charlotte? Replication allows AD DS to transmit changed data across a domain to all relevant domain controllers so that the contents of the directory are always up-to-date on each domain controller.
At this point, astute readers who are familiar with the domain structure of Microsoft's Windows NT products surely are asking, "What about PDCs and BDCs?" For the most part, Microsoft has removed that designation from domain controllers in AD DS environments, meaning that with only a couple of minor exceptions, all domain controllers are equal. This is referred to as a multimaster environment.
Because a domain controller holds a large database of information, AD DS has some interesting characteristics that weren't necessarily true of NT 4.0's Security Accounts Manager (SAM)-based list of accounts. For instance, programmers can write code to interface directly with AD DS and run queries to pull data from the database. These programmers can use either the Lightweight Directory Access Protocol (LDAP), an industry-standard protocol for accessing any sort of directory, or the Microsoft-specific Active Directory Services Interface (ADSI) for taking advantage of AD DS features not supported directly within the LDAP specification. Additionally, AD DS doesn't have the same size limitations that the SAM had. AD DS easily can handle up to a few million objects, as compared to the SAM's ability to handle no more than about 5,000 accounts. (That's scalability, folks!) AD DS is also fast when handling large amounts of data, so you won't get bogged down when your directory grows.
A domain can be an awfully big, comprehensive unit to manage, and most environments benefit from some mechanism to separate that large, unitary domain into smaller, more manageable chunks. An organizational unit is AD DS's way of doing that. Organizational units, or OUs, act like folders on a regular client's operating system, containing every type of object that AD DS supports. You might choose to separate your domain into OUs in one of these ways:
A university might create a domain with a name corresponding to the entire university (ncsu.edu, for example), with each college in that institution getting an OU (biology, physics, mathematics, etc.).
A medium-size business might use one domain for all of its AD DS needs, but segregate objects into their geographical locations—an OU for the Los Angeles office, an OU for the Birmingham office, and an OU for the Richmond office.
Larger corporations might want to divide their domain by department. Within business.com, for example, an OU could be created each for Sales, Support, Marketing, Development, and Q/A.
An administrator also could decide to create OUs based on the type of objects contained therein—for example, a Computers OU, a Printers OU, and so on.
A particularly interesting feature of OUs is the ability to delegate administrative control over them to a subset of users in AD DS. Take, for instance, the third example in the previous list. Perhaps you, as the domain administrator, want to designate one technically savvy person in each department as the official Password Change Administrator, to reduce your administrative load. You can delegate the authority to modify users' passwords to each user over only their respective OU, thereby both allowing them power but finely controlling it over certain areas of your AD DS infrastructure. This ability is called delegation, and you'll find an entire section devoted to it later in this chapter.
OUs are designed to be containers in AD DS—their purpose is to hold objects and to have contents. You can apply GPs to the objects within a specific OU (as you'll see in Chapter 6), controlling users' desktops, locking them out of potentially dangerous system modification settings, and creating a consistent user experience across your domain.
Sites are great ways to manage the use of bandwidth for AD DS replication across WAN links. All domain controllers in an AD DS domain must stay in contact with one another at regular intervals to acquire and transmit the changes that have occurred to their databases since the last update. Otherwise, information becomes "stale" and the directory is no good to anyone. However, this replication traffic can be costly if you have domain controllers in different countries and you use slow WAN links to keep in contact with your various offices.
By designating different sites with AD DS, a process we'll cover later in the replication section of this chapter, you can tell AD DS to compress the replication traffic to allow it to be transmitted more quickly, and you can give preferences to certain WAN links over others by using the "cost" feature, specifying a higher value for a connection you want to use less often and a lower value for a connection you'd like to use the most often. It's a great way to manage your telecommunications expenses while still taking advantage of the better management features of AD DS.
In a domain environment, the Distributed File System, which you learned about in Chapter 3, also uses AD DS's site structure to control file replication traffic.
The point of groups is to make assigning attributes to larger sets of users easier on administrators. Picture a directory with 2,500 users. You create a new file share and need to give certain employees permissions to that file share—for example, all accounting users. Do you want to take a hard-copy list of all members of the accounting department and hand-pick the appropriate users from your list of 2,500? Of course you don't. Groups allow you to create an object called Accounting and insert all the appropriate users into that group. So, instead of selecting each individual user from a large list, you can pick the Accounting group, and all members of that group will have the same permissions on the file share.
There are four different scopes of groups within Windows Server 2008 and AD DS, and each scope can nest groups differently. Let's outline the group scopes first, and then bear with me as I explain the concepts of each:
- Machine local groups
Machine local groups contain objects that pertain only to the local computer (or more specifically, to objects contained within the local computer's SAM database). These types of groups can have members that are global groups, domain local groups from their own domain, and universal or global groups from their own domain or any other domain that they trust.
- Domain local groups
Domain local groups can be created only on a domain controller, so ordinary client computers or member servers of a domain cannot host domain local groups. Domain local groups can be put inside machine local groups within the same domain (this is a process called nesting). They can contain global groups from a domain that trusts the current domain and other domain local groups from the same domain. As you will see later in the chapter, they are of limited utility unless you are working in a larger, multidomain environment.
- Domain global groups
Like domain local groups, domain global groups can be created only on a domain controller, but domain global groups can be put into any local group of any machine that is a member of the current domain or a trusted domain. Domain global groups can also be nested in other global groups; however, all nested domain global groups must be from the same domain. Domain global groups are great tools that contain all the functionality of domain local groups, and more, and they are the most common type of group used across a domain.
- Universal groups
Universal groups are a sort of "do-it-all" type of group. Universal groups can contain global and universal groups, and those nested groups can be from any domain in your AD DS forest.
Briefly, I'll also mention that there are two types of groups: a security group is used for the purposes of assigning or denying rights and permissions, and a distribution group is used for the sole purpose of sending email. A security group, though, can also act as a distribution group.
Nesting is a useful ability that has been around in limited form since Windows NT. By nesting groups, you achieve the ability to quickly and painlessly assign permissions and rights to different users. For example, let's say you have a resource called COLORLASER and you want all full-time employees to be able to access that resource. You don't have a group called FTEs that contains all your full-timers throughout your organization, but your departmental administrators have set up a structure wherein full-time employees are put into groups and part-timers are in another. To quickly create your overall FTE group, you can take your different groups of users from each department (ACCTG_FTE, ADMIN_FTE, PRODUCTION_FTE, and SALES_FTE, for example) and put them within a new group you create called ALL_FTE. Then, you can quickly assign access rights to COLORLASER by giving the ALL_FTE group permission to use the resource. You have "nested" the departmental groups within one big group.
Different types of groups, as you saw in the previous list of groups, support different methods of nesting. Table 5-1 shows the relationships between the types of groups and the respective abilities to nest.
Table 5-1. Nesting by group type
Type of nesting | Machine local | Domain local | Domain global | Universal |
|---|---|---|---|---|
Within themselves | Yes | Yes (from the same domain) | Yes (from the same domain) | Yes |
Within other types | None | Machine local | Machine local Domain local Universal | Machine local Domain local Domain global |
You should remember a couple of important issues regarding backward compatibility with Windows NT 4.0 and Windows 2000 and the types of group capabilities available:
AD DS cannot support universal groups until you operate at least in Windows 2000 Native functional level, as NT 4.0 supports only one level of group nesting.
A group cannot have more than 5,000 members until your forest is operating in the Windows Server 2003 forest-functional level or higher. Functional levels are covered later in this chapter, but for now, be aware of this limitation.
Trees refer to the hierarchies of domains you create within AD DS. The first AD DS domain you create is automatically designated the root of your first tree, and any domains after that are considered child domains unless you choose to create a domain at the root of a new tree. Child domains always have the root domain in their name—for example, if I create the hasselltech.local domain, any child domains must be in the format of newdomainname.hasselltech.local. In effect, you are creating what are referred to as subdomains in DNS parlance. You can create as many child domain levels as you need; children can be children of other children of other children, and so on, as long as it makes sense to you.
A neat feature of AD DS is that it automatically creates two-way trust relationships between parent and child domains, so you don't need to manually trust the domains you create. As such, my new child domain from our earlier example will automatically trust its parent domain, hasselltech.local, and the parent will trust the child—the transitive trust is created automatically. This type of trust is passed along the child domain chain, so a domain like charlotte.eastcoast.us.northamerica.enterprise.com will automatically trust eastcoast.us.northamerica.enterprise.com, us.northamerica.enterprise.com, northamerica.enterprise.com, and enterprise.com.
Forests, in the simplest terms, are just groups of trees. All trees in a forest trust each other automatically. Think of a forest as an extended family, and individual domain trees as brothers. If you have five brothers in a family, each child of those brothers trusts his immediate brothers, and (usually!) each brother's family trusts the other brother's family—cousins typically get along. Forests just refer to collections of domain trees that trust one another.
There are two caveats, though, which are fairly significant and bear mentioning:
The only way to add a domain to a tree is to create it completely from scratch, adding it to an existing tree at that time. It's the same with trees—you can't directly add an existing tree to an existing forest without deleting and subsequently re-creating it.
Likewise, two existing, separate domains can't be linked together as parent and child. For example, hasselltech.local created on one network and charlotte.hasselltech.local created on another, separate network cannot be joined later as parent and child. The child would need to be re-created or migrated.
The latter of the preceding two limitations might be frustrating for you, and you're not alone. Fortunately, what experts might term an "official hack" is available to effectively graft existing domains together into a tree-like structure so that trusts are established. Although it's not as easy and not as flexible as a forest—AD DS makes things slick and easy when you do things its way—it will work, with effort and maybe a bit of luck. The tool is called a transitive forest root trust, and with it, you can make two disparate forests trust each other.
Let's say I have a forest called businessone.com. Business One purchases another organization with an AD DS forest created already, known as businesstwo.net. Recall that I can't just graft businesstwo.net onto the already existing forest at Business One. However, with a transitive forest root trust, I can make it so that businessone.com trusts businesstwo.net, achieving some of the benefits of one unified forest. However, there are limitations and disadvantages:
Each forest must be operating in at least the Windows Server 2003 forest functional level. Although I will cover this later, suffice it to say that all domain controllers in each domain in each forest must be running Windows Server 2003, if not Windows Server 2008. This might be a prohibitive expense.
You'll learn more about this feature later in this chapter, but keep this in mind for now: a transitive forest root trust does not automatically make one, unified global catalog. Two separate forests still equals two separate global catalogs.
Transitive forest root trusts do not flow through. For example, businessone.com and businesstwo.net trust each other. But if businessone.com buys businessthree.org and a trust is set up there, businesstwo.net will not trust businessthree.org automatically—another trust will need to be set up. With that, we're back to the kludgy trust process found in Windows NT 4.0.
So, transitive forest root trusts aren't the answer to everything, but they are a reasonably effective way to create a "pseudoforest" within already existing trees.
You also can create a hedge against future AD DS changes if you are deploying Active Directory for the first time. If a department in your organization deploys AD DS ahead of other departments, as the other groups come on board, they effectively become subordinates of that first domain. How does a smart administrator get around that problem? The dedicated forest root model provides a way to maintain the autonomy of multiple domains that you create. Figure 5-1 shows how this is achieved.
A dedicated forest root domain can be either an "empty domain," which contains only a small number of universal users and resources, or a normal production domain that just happens to be at the root of a forest. The latter is not recommended. An empty forest root domain that does not serve as a production domain is advantageous for several reasons. For one, the domain administrators group in the root domain has power over the forest, which is something you might not want. Keeping the root empty allows you to delegate administrative authority to individual domains without giving everything away, a security protection that keeps honest administrators honest. It also helps you to structure your AD DS environment; a constant root makes further changes logical and easy to implement and manage—for instance, if you acquire a new company or build a new office. The forest root domain, if kept empty, is very easy to replicate and to back up. And if you ever make changes to the administrative authority in your business, you can transfer the keys to the kingdom to others without affecting the administrators' autonomy of your child domains.
Tip
You can name the empty forest root domain anything you want—even emptyroot.local. It is only a placeholder. However, most clients use a domain name based on their company's domain name.
However, the key to the empty root strategy is to keep the root empty: have it contain only one administrative account—the Enterprise Administrator, which is, of course, created by default when you create the first domain in a new forest—and use that only when absolutely necessary. Then, create all the domains you need under that first domain and you won't have one particular domain in your organization unnecessarily holding Enterprise Admin-style accounts.
Of course, this method has its downsides. Costs definitely are involved: for one, you need a separate license of Windows Server 2008 for your dedicated forest root domain controller, and you have the burden of administrative responsibility in ensuring that the root domain is kept up, patched, and the like. However, if you are in a high-growth industry and your organization is likely to make acquisitions and divestitures within the near future, it's best to use this method to hedge against major changes to AD DS structure.
As you saw in Chapter 3, the concept of shared folders and printers within AD DS merely relates to a "pointer" residing within the directory, guiding users to the real location on a physical filesystem of a server for a particular shared directory, or the location of a print share on a print server. This process is known as publishing a share (or publishing a printer).
The point of publishing shares and printers in AD DS is to make them available for searching, either through AD DS Users and Computers for administrators or through Start → Search or Start → Find for client users. You can search for shared folder or printer names containing target keywords, and their locations will be populated within the results box.
Contacts are simply objects in the directory that represent people and contain attributes with indicators as to how to contact them. Contacts neither represent users of any directory, nor convey any privileges to log on to the network or use any network or domain resources.
The point of the contacts object is to create within AD DS a phonebook of sorts, with names of vital business contacts that reside outside your organization—partners, customers, vendors, and the like. Because AD DS as a directory can be queried by the LDAP protocol, which most groupware applications support, the contents of contacts objects likely can be accessed directly within that application.
The global catalog, in an AD DS environment, acts as a sort of subset directory that is passed among all domains in a particular forest. Consider that AD DS gives you the ability to connect to any computer in your particular AD DS tree. If you have a small organization, this isn't much of a problem, but in a large organization with many domains, can you imagine the performance lag while AD DS tries to (a) find the correct domain where your account resides, then (b) communicate with it, and finally (c) log you in? You would be waiting for a significant amount of time for all the pieces of the puzzle to come together in a complex AD DS implementation.
For that reason, AD DS constructs a subset of all the domains in a forest and puts it into what's called the global catalog (GC). The GC contains a list of all domains in the forest and a list of all the objects in those domains, but only a subset of the attributes for each object. This is a fairly small bit of information compared to the rest of the directory, and because of its reduced size, it is easy to pass on to given domain controllers in the forest. As a result, when a user connects to a computer in any given domain in a forest, the nearest domain controller checks the username against the GC and instantly finds the correct "home" domain for a user and the authentication process can begin. Think of the GC, therefore, as an index of your directory, much like the index of this book helps you to see which pages cover a topic in which you're interested.
The GC also contains the name of each global group for every domain in the forest, and it contains the name and the complete membership list of every universal group in the forest (recall that universal groups can contain users and other groups from any domain in the forest). So, limit your use of universal groups, lest you decrease the performance of your users' logins.