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.
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 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 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.
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;
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 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 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
(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
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 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 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.
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 charlotte.eastcoast.us.northamerica.enterprise.com will automatically trust eastcoast.us.northamerica.enterprise.com, us.northamerica.enterprise.com, northamerica.enterprise.com, and enterprise.com.
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 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. 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 "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.
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.
|
