Understanding the Development of AD DS
Introduced with Windows
2000 Server as a replacement to Windows NT 4.0 domains, AD DS (then
known simply as AD) was later greatly improved in Windows Server 2003
and Windows Server 2003 R2 Edition. AD DS has achieved wide industry
recognition and acceptance and has proven itself in reliability,
scalability, and performance. The introduction of AD DS served to
address some limitations in the legacy NT 4.0 domain structure design
and also allowed for future Microsoft and third-party products to tie
into a common interface.
Detailing Microsoft’s Adoption of Internet Standards
Since
the early development of Windows 2000/2003 and continuing with Windows
Server 2008 R2, Microsoft has strived to make all its products embrace
the Internet. Standards that before had been options or previously
incompatible were subsequently woven into the software as primary
methods of communication and operability. All applications and operating
systems became TCP/IP compliant, and proprietary protocols such as
NetBEUI were phased out.
With the introduction of
Windows Server 2008 R2, the Internet readiness of the Microsoft
environment reaches new levels of functionality, with enhancements such
as the ability to restore deleted objects using the Active Directory
Recycle Bin, Offline Domain Join, Managed Service Accounts, the ability
to use multiple password policies per domain, Read-Only Domain
Controller (RODC) support, the ability to start/stop AD on a domain
controller (DC), and the ability to audit changes made to AD objects.
Examining AD DS’s Structure
The logical structure of AD
DS enables it to scale from small offices to large, multinational
organizations. Administrative granularity is built in to allow
delegation of control to groups or specific users. No longer is the
assigning of administrative rights an all-or-nothing scenario.
AD DS loosely follows an
X.500 directory model but takes on several characteristics of its own.
Many of us are already getting used to the forests and trees of AD DS,
and some limitations that existed before in Windows 2000 and Windows
Server 2003 have been lifted. To understand AD DS, we must first take a
good look at its core structural components.
Understanding the AD DS Domain
An AD DS domain, traditionally represented by a triangle, as shown in Figure 1,
is the initial logical boundary of AD DS. In a standalone sense, an AD
DS domain acts very much like the legacy Windows NT 4.0 domain structure
that it replaced. Users and computers are all stored and managed from
within the boundaries of the domain. However, several major changes have
been made to the structure of the domain and how it relates to other
domains within the AD DS structure.
Domains in AD DS serve
as administrative security boundaries for objects and contain their own
security policies. It is important to keep in mind that domains are a
logical organization
of objects, and can easily span multiple physical locations.
Consequently, it is no longer necessary to set up multiple domains for
different remote offices or sites as replication concerns and security
concerns are more properly addressed with the use of AD DS sites or
Read-Only Domain Controllers, which will be described in greater detail
in the following sections.
Describing AD DS Domain Trees
An AD DS tree is composed of
multiple domains connected by two-way transitive trusts. Each domain in
an AD DS tree shares a common schema and global catalog. In Figure 2, the root domain of the AD DS tree is companyabc.com and the subdomains are asia.companyabc.com and europe.companyabc.com.
The transitive trust
relationship is automatic. The transitive trust relationship means that
because the Asia domain trusts the root companyabc domain, and the
Europe domain trusts the companyabc domain, the Asia domain trusts the
Europe domain as well. The trusts flow through the domain structure.
Note
Although trusts are
transitive in an AD DS environment, that does not mean that permissions
are fully accessible to all users or even to administrators between
domains. The trust only provides a pathway from one domain to another.
By default, no access rights are granted from one transitive domain to
another. The administrator of a domain must issue rights for users or
administrators in another domain to access resources within their
domain.
All domains within a tree share
the same namespace, in this example companyabc.com, but have security
mechanisms in place to segregate access from other domains. In other
words, an administrator in the Europe domain could have relative control
over his entire domain,
without users from the Asia or companyabc domains having privileges to
resources. Conversely, the administrators in Europe can allow groups of
users from other domains access if they so want. The administration is
granular and configurable.
Describing Forests in AD DS
Forests are a group
of interconnected domain trees. Implicit trusts connect the roots of
each tree together into a common forest.
The overlying
characteristics that tie together all domains and domain trees into a
common forest are the existence of a common schema and a common global
catalog. However, domains and domain trees in a forest do not need to
share a common namespace. For example, the domains microsoft.com and
msnbc.com could theoretically be part of the same forest but maintain
their own separate namespaces.
Forests are the main
organizational security boundary for AD DS, and it is assumed that all
domain administrators within a forest are trusted to some degree. If a
domain administrator is not trusted, that domain administrator should be
placed in a separate forest.
Understanding AD DS Authentication Modes
Windows NT 4.0 used a system
of authentication known as NT LAN Manager (NTLM). This form of
authentication sent the encrypted password across the network in the
form of a hash. The problem with this method of authentication was that
anyone could monitor the network for passing hashes, collect them, and
then use third-party decryption tools that effectively decrypt the
password using dictionary and brute-force techniques.
All versions of Windows
Server beyond Windows 2000 utilize a form of authentication known as
Kerberos. In essence, Kerberos does not send password
information over the network and is inherently more secure than NTLM.
Outlining Functional Levels in Windows Server 2008 R2 AD DS
Just as Windows 2000 and
Windows 2003 had their own functional levels that ensured down-level
compatibility with legacy domain versions, Windows Server 2008 R2 has
its own functional levels that are used to maintain compatibility. The
following functional levels exist in Windows Server 2008 R2:
Windows 2000 Native functional level—
This functional level allows Windows Server 2008 R2 domain controllers
to coexist with both Windows 2000 SP3+ and Windows 2003 domain
controllers within a forest.
Windows Server 2003 functional level—
This functional level allows Windows 2003 and Windows Server 2008 R2
domain controllers to coexist. Additional functionality is added to the
forest, including cross-forest transitive trust capabilities and
replication enhancements.
Windows Server 2008 functional level— In this functional level, all domain controllers must be running Windows Server 2008 or later. Changing the domain and forest functional level to Windows Server 2008 adds additional functionality, such as fine-grained password policies.
Windows Server 2008 R2 functional level—
In this functional level, all domain controllers must be running
Windows Server 2008 R2. Changing the forest functional level to this
latest AD DS level grants Windows Server 2008 R2 feature functionality,
such as access to the Active Directory Recycle Bin.
By default, a fresh
installation of Active Directory on Windows Server 2008 R2 domain
controllers allows you to choose which functional level you want to
start the forest in. If an existing forest is in place, it can be
brought to Windows Server 2008 R2 functional level by performing the
following steps:
1. | Ensure
that all domain controllers in the forest are upgraded to Windows
Server 2008 R2 or replaced with new Windows Server 2008 R2 DCs.
|
2. | Open Active Directory Domains and Trusts from the Administrative Tools menu on a domain controller.
|
3. | In the left scope pane, right-click on the domain name, and then click Raise Domain Functional Level.
|
4. | In the box labeled Raise Domain Functional Level, select Windows Server 2008 R2, and then click Raise.
|
5. | Click OK and then click OK again to complete the task.
|
6. | Repeat steps 1–5 for all domains in the forest.
|
7. | Perform
the same steps on the root node of Active Directory Domains and Trusts,
except this time choose Raise Forest Functional Level and follow the
prompts.
|
When all domains and the forest
level have been raised to Windows Server 2008 R2 functionality, the
forest can take advantage of the latest AD DS functionality, such as the
Active Directory Recycle Bin. Remember, before you accomplish this task, Windows Server 2008
R2 essentially operates in a downgraded mode of compatibility.
