Section 5.1. Active Directory Objects and Concepts

5.1. Active Directory Objects and Concepts

First it's important to learn that you can divide Active Directory 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 Active Directory 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 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 their 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 its 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 Active Directory 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 Active Directory, an object is anything that can be part of the directorythat 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 Active Directory is the actual structure of the databasethe "fields," to use a not-quite-applicable analogy. The different types of information stored in Active Directory are referred to as attributes . Active Directory'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 locationsor 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; Active Directory 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 namespacethat 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 Active Directory is a secure method of communicating between domains, trees, and forests. Much like they worked in Windows NT, trusts allow users in one Active Directory domain to authenticate to other domain controllers within another, separate, 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).

5.1.1. Domains

When examining Active Directory for the first time, it's easiest to examine the domain first because so much of the basis of Active Directory 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 Active Directory. However, many other objects are stored within the directorywhich is actually a file on a domain controller's hard drive called NTDS.DITincluding 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 linksa 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 Active Directory 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.

Astute readers at this point 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 Active Directory 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, Active Directory 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 Active Directory 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 Active Directory features not supported directly within the LDAP specification. Additionally, Active Directory doesn't have the same size limitations that the SAM had. Active Directory 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!) Active Directory is also fast when handling large amounts of data, so you won't get bogged down when your directory grows.

5.1.2. Organizational Units

A domain can be an awfully big, comprehensive unit to manage, and most environments would benefit from some mechanism to separate that large, unitary domain into smaller, more manageable chunks. An organizational unit is Active Directory'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 Active Directory supports. You might choose to separate your domain into OUs in one of the following 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 Active Directory needs, but segregate objects into their geographical locationsan 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 thereinfor 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 Active Directory. 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 Active Directory 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 Active Directory, meaning that their point 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.

5.1.3. Sites

Sites are great ways to manage the use of bandwidth for Active Directory replication across WAN links. All domain controllers in an Active Directory domain must stay in contact with each other 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 Active Directory, a process we'll cover later in the replication section of this chapter, you can tell Active Directory 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 used 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 Active Directory .

In a domain environment, the Distrubuted File System, which you learned about in Chapter 3, also uses Active Directory's site structure to control file replication traffic.

5.1.4. Groups

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 sharefor 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 2003 and Active Directory, 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, multi-domain 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. New to Active Directory in Windows 2000 and Windows Server 2003, universal groups can contain global and universal groups, and those nested groups can be from any domain in your Active Directory 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.

5.1.4.1. Nesting

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:

Active Directory 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. Functional levels are covered later in this chapter, but for now, be aware of this limitation.

5.1.5. Trees

Trees refer to the hierarchies of domains you create within Active Directory. The first Active Directory 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 namefor 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 Active Directory 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 childthe transitive trust is created automatically. This type of trust is passed along the child domain chain, so a domain such as charlotte.eastcoast.us.northamerica.enterprise.com will automatically trust eastcoast.us.northamerica.enterprise.com, us.northamerica.enterprise.com, northamerica.enterprise.com, and enterprise.com.

5.1.6. Forests

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 their immediate brothers, and (usually!) each brother's family trusts the other brother's familycousins typically get along. Forests just refer to collections of domain trees that trust each other.

There are two caveats, though, that 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 treesyou can't directly add an existing tree to an existing forest without deleting and subsequently recreating 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 recreated or migrated.

5.1.6.1. Transitive forest root trusts

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 forestActive Directory makes things slick and easy when you do things its wayit 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 Active Directory 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 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. 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 automaticallyanother 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 "pseudo-forest" within already existing trees.

5.1.6.2. The dedicated forest root model

You also can create a hedge against future Active Directory changes if you are deploying Active Directory for the first time. If a department in your organization deploys Active Directory 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.

Figure 5-1. How the dedicated forest root model enables separate NT domains to be separate in Active Directory

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 Active Directory environment; a constant root makes further changes logical and easy to implement and managefor 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.

You can name the empty forest root domain anything you wanteven 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 accountthe Enterprise Administrator, which is, of course, created by default when you create the first domain in a new forestand 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 2003 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 Active Directory structure.

5.1.7. Shared Folders and Printers

As you saw in Chapter 3, the concept of shared folders and printers within Active Directory 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 Active Directory is to make them available for searching, either through Active Directory 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.

5.1.8. Contacts

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 Active Directory a phonebook of sorts, with names of vital business contacts that reside outside your organizationpartners, customers, vendors, and the like. Because Active Directory 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.

5.1.9. Global Catalog

The global catalog , in an Active Directory environment, acts as a sort of subset directory that is passed among all domains in a particular forest. Consider that Active Directory gives you the ability to connect to any computer in your particular Active Directory 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 Active Directory 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 Active Directory implementation.

For that reason, Active Directory 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. So, now 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.