- Evolution of Directory Services
- Active Directory Development
- Active Directory Structure
- Active Directory Components
- Domain Trusts
- Organizational Units
- Groups in an Active Directory Environment
- Active Directory Replication
- DNS in Active Directory
- Active Directory Security
- Active Directory Changes in Windows .NET Server 2003
- Best Practices
Active Directory Structure
The logical structure of Active Directory 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.
Active Directory 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 Active Directory, and some limitations that existed before in Windows 2000 have been lifted. To understand Active Directory, we must first take a good look at its core structural components.
The Active Directory Domain
An Active Directory (AD) domain is the main logical boundary of Active Directory. In a standalone sense, an AD domain looks very much like a Windows NT domain. 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 Active Directory structure.
Domains in Active Directory serve as a security boundary for objects and contain their own security policies. For example, different domains can contain different password policies for users. 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 because replication concerns can be addressed with the proper use of Active Directory sites, which will be described in greater detail in the following sections.
Active Directory Domain Trees
An Active Directory tree is composed of multiple domains connected by two-way transitive trusts. Each domain in an Active Directory tree shares a common schema and global catalog. In Figure 4.2, the root domain of the Active Directory tree is companyabc.com and the subdomains are asia.companyabc.com and europe.companyabc.com.Figure 4.2 Simple Windows .NET Server 2003 Active Directory tree with subdomains.
The transitive trust relationship is automatic, which is a change from the domain structure of NT 4.0, in which all trusts had to be set up manually. 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.
Although trusts are transitive in a Windows Active Directory 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.
Forests in Active Directory
Forests are a group of interconnected domain trees. Implicit trusts connect the roots of each tree together into a common forest.
One of the key differences between AD domains in Windows 2000 and AD domains in Windows .NET Server 2003 is that administrators now have the ability to rename domains. For this to occur, however, all domain controllers within the forest must be converted to Windows .NET Server 2003 domain controllers and the Active Directory forest functionality levels must be raised to support Windows .NET Server 2003. A detailed discussion of the Active Directory domain rename tools is provided in Chapter 17, "Migrating from Windows 2000 to Windows .NET Server 2003."
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 (for obvious reasons).
Active Directory 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 such as L0phtcrack, which effectively decrypts the password using dictionary and brute-force techniques.
Windows 2000 and .NET Server utilize a form of authentication known as Kerberos, which is described in greater detail in the following sections. In essence, Kerberos does not send password information over the network and is inherently more secure than NTLM. However, Kerberos authentication is not required by default in Active Directory because AD is set up by default to be backward compatible for legacy Windows clients.
Functional Levels in Windows .NET Active Directory
Just as Windows 2000 is installed to be initially compatible with legacy Windows NT domains and clients, Windows .NET Server 2003 initially does not upgrade the Active Directory forest to .NET functionality. This helps to maintain backward compatibility with Windows 2000 and Windows NT4 domain controllers. Four separate functional levels exist at the domain level in Windows .NET Server 2003, and three separate functional levels exist at the forest level.
Windows 2000 Mixed Domain Functional Level
When Windows .NET Server 2003 is installed into a Windows 2000 Active Directory forest that is running in Mixed mode, it essentially means that Windows .NET Server 2003 domain controllers will be able to communicate with Windows NT and Windows 2000 domain controllers throughout the forest. This is the most limiting of the functional levels, however, because functionality such as universal groups, group nesting, and enhanced security is absent from the domain. This is typically a temporary level to run in because it is seen more as a path toward eventual upgrade.
Windows 2000 Native Functional Level
Installed into a Windows 2000 Active Directory that is running in Windows 2000 Native mode, Windows .NET Server 2003 will run itself at a Windows 2000 functional level. Only Windows 2000 and Windows .NET Server 2003 domain controllers can exist in this environment.
Windows .NET Interim Functional Level
Windows .NET Interim mode enables the .NET Active Directory to interoperate with a domain composed of Windows NT 4.0 domain controllers only. Although a confusing concept at first mention, the Windows .NET Interim functional level does serve a purpose. In environments that seek to upgrade directly from NT 4.0 to Windows .NET Active Directory, Interim mode allows .NET Server to manage large groups more efficiently than if an existing Windows 2000 Active Directory exists. After all NT domain controllers have been removed or upgraded, the functional levels can be raised.
Windows .NET Functional Level
The most functional of all the various levels, .NET functionality is the eventual goal of all .NET Active Directory implementations. Functionality on this level opens the environment up to features such as schema deactivation, domain rename, domain controller rename, and cross-forest trusts. To get to this level, first all domain controllers must be updated to Windows .NET Server 2003. Only after this can the domains and then the forest be updated to Windows .NET functionality. To accomplish this task, you must perform the following steps:
Ensure that all domain controllers in the forest are upgraded to Windows .NET Server 2003.
Open Active Directory Domains and Trusts from the Administrative Tools.
In the left scope pane, right-click Active Directory Domains and Trusts and then click Raise Domain Functional Level.
In the box labeled Select an Available Forest Functionality, shown in Figure 4.3, select Windows .NET (version 2003) and then click Raise.
Click OK and then click OK again to complete the task.
Repeat steps 15 for all domains in the forest.
Perform the same steps on the forest root, except this time click Raise Forest Functional Level in step 3 and follow the prompts.
Figure 4.3 Raising the functional level of the Windows .NET Server 2003 domain.
When all domains and the forest level have been raised to Windows .NET Server 2003 functionality, various .NET Server activities such as domain rename can be accomplished, and full realization of the Windows .NET Active Directory capabilities can be achieved. Remember, before you accomplish this task, Windows .NET Server 2003 will essentially be operating in a Mixed mode of compatibility, much as Windows 2000 initially ran in a Mixed mode with Windows NT Servers.