Windows Server 2003 : Active Directory Objects and Concepts

9/14/2012 12:44:49 AM
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:


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.


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.

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.


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.


Within Active Directory, 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.


The schema in Active Directory is the actual structure of the database—the "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.


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; 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.


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 and hasselltech.local are not.


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).

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 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 , 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 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.

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 (, 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 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, 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 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.

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 , controlling users' desktops, locking them out of potentially dangerous system modification settings, and creating a consistent user experience across your domain.

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, 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, also uses Active Directory's site structure to control file replication traffic.

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 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 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.

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.

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 1 shows the relationships between the types of groups and the respective abilities to nest.

Table 1. Nesting by group type
Type of nestingMachine localDomain localDomain globalUniversal
Within themselvesYesYes (from the same domain)Yes (from the same domain)Yes
Within other typesNoneMachine localMachine local

Domain local

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.

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 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 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 child—the transitive trust is created automatically. This type of trust is passed along the child domain chain, so a domain such as will automatically trust,,, and

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 family—cousins 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 trees—you 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.

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 forest—Active Directory 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 Business One purchases another organization with an Active Directory forest created already, known as Recall that I can't just graft onto the already existing forest at Business One. However, with a transitive forest root trust, I can make it so that trusts, 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.

  • Transitive forest root trusts do not flow through. For example, and trust each other. But if buys and a trust is set up there, will not trust 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 "pseudo-forest" within already existing trees.

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 1 shows how this is achieved.

Figure 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 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.

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 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.

7. Shared Folders and Printers

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.

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 organization—partners, 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.

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.

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.

  •  Connecting To A Virtual Private Network From Your MAC
  •  Tips, Tricks And Tweaks For Microsoft's Mighty, Windows 7
  •  Maintaining Your Windows XP System : Backing Up Your Files
  •  Maintaining Your Windows XP System : Defragmenting Your Hard Disk
  •  Asus P8Z77-V Premium : Loads Up Every Conceivable Feature
  •  Brother DCP-J140W
  •  Intel 330 Series – SSD For Mid-rang Market
  •  Iomega StorCenter PX4-300D 4TB - New Small Business NAS Box
  •  Install Android on Your PC
  •  Ivy League All Stars : Acer Aspire S5, Apple MacBook Air, Samsung 900X4C
  •  Linux from Scratch
  •  Meet The New Benchmarks : Adobe Premiere Pro CS6, Gigapan Stitch.EFX 2.0, Techarp X264 HD 5.0, Proshow Producer 5.0
  •  Reliving the Commodore 64 Glory Days (Part 1)
  •  Reliving the Commodore 64 Glory Days (Part 2)
  •  SAM PowerPC With AmigaOS 4.1
  •  Speed Up Boot Times with Startup Delayer
  •  File Grinder - Rename Files Easily
  •  Back Up With Clonezilla (Part 1) - Prepare For Backup
  •  Back Up With Clonezilla (Part 2) - Start Clonezilla, Select The Backup Device
  •  Back Up With Clonezilla (Part 3) - Use The Network, Disks And Partitions
    Top 10
    SQL Server 2005 : Working with SQL Server Management Objects in Visual Studio (part 3) - Creating Backup-and-Restore Applications, Performing Programmatic DBCC Commands with SMO
    SQL Server 2005 : Working with SQL Server Management Objects in Visual Studio (part 2) - Retrieving Server Settings
    SQL Server 2005 : Working with SQL Server Management Objects in Visual Studio (part 1) - Iterating Through Available Servers
    Deploying to an iPhone, Debugging, and Testing : Distributing Your Application
    Visual Basic 2010 : Setup & Deployment Projects for Windows Installer (part 2) - Configuring the Setup Project
    Visual Basic 2010 : Setup & Deployment Projects for Windows Installer (part 1) - Creating a Setup Project
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 3)
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 2)
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 1)
    Programming .NET Compact Framework 3.5 : Creating Graphical Output - Drawing on the Display Screen
    Most View
    3D Printing … for people who don’t have a 3D printer
    Windows Server 2003 : Windows Terminal Services - Installing an Application, Configuring Terminal Services Licensing
    Tiny Motherboard ODroid-X Integrated With Quad-Core Exynos Processor And 1GB RAM
    Programming the iPhone : Standard Control Types (part 2) - Modal Buttons
    IIS 7.0 : Implementing Security Strategies - Configuring Applications for Least Privilege
    Tips & Tricks Of November 2012 (Part 3)
    Adobe InDesign CS5 : Applying and Editing a Photoshop Clipping Path in InDesign, Creating and Editing an InDesign Clipping Path
    Windows 8 Hardware (Part 3) : Acer Iconia W510, Acer T232HL, Innovatouch IW2235P-U
    Windows Azure : Processing with worker roles - A simple worker role service
    Programming the iPhone : Standard Control Types (part 3) - Sliders
    SQL Azure : Tuning Techniques (part 4) - Indexed Views & Stored Procedures
    Tried And Tested – November 2012 (Part 2)
    Managing Hardware in Vista
    Architecting Applications for the Enterprise : UML Diagrams (part 3) - Sequence Diagrams
    The Future Of Apple: Chip Off The Block (Part 4)
    Plan The Perfect Shoot (Part 1)
    Tech Preview 2013 (Part 1) - Next-Gen Gpus
    Information Station For Data Storage and Transfer Devices
    Optimizing for Vertical Search : The Opportunities in Vertical Search
    Programming Windows Services with Microsoft Visual Basic 2008 : Installing Services