- The Evolution of Directory Services
- Understanding the Development of AD DS
- AD DS Structure
- Outlining AD DS Components
- Understanding Domain Trusts
- Defining Organizational Units
- Outlining the Role of Groups in an AD DS Environment
- Understanding AD DS Replication
- Outlining the Role of DNS in AD DS
- Outlining AD DS Security
- Getting Familiar with AD DS Features in Windows Server 2016
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
AD DS 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 previous versions of AD DS 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 4.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.
)
FIGURE 4.1 Examining a sample domain in AD DS.
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 RODCs, which are described in greater detail in the following sections.
Describing AD DS Domain Trees
An AD DS tree consists 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 4.2, the root domain of the AD DS tree is companyabc.com and the subdomains are asia.companyabc.com and europe.companyabc.com.
)
FIGURE 4.2 A Windows Server 2016 AD DS tree with subdomains.
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.
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.
Incidentally, just because you can create subdomains within a forest, such as the ones shown in Figure 4.2, does not meant that it makes sense to do so. Many environments are better served with a single domain for all of their worldwide resources, and after you make the decision to create subdomains, it is not easy to change your mind and move resources later. You can find more information about this in Chapter 5, “Designing a Windows Server 2016 Active Directory.”
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.internal and technet.internal could theoretically be part of the same forest but maintain their own separate namespaces. In addition, forests, domains and domain controllers in remote locations can now be located anywhere, from local main offices to branch offices and the cloud. With services in Azure your domains and forests are now everywhere.
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. Often, when two or more companies that own AD forests merge, they initially “talk” to each other from separate forests until trusts, both technical and human, are proven.
Understanding the 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 use a form of authentication known as Kerberos, which is described in greater detail later in this chapter. In essence, Kerberos does not send password information over the network and is inherently more secure than NTLM.
Outlining Functional Levels in Windows Server 2016 AD DS
Just as Windows 2000 and later versions had their own functional levels that ensured down-level compatibility with legacy domain versions, Windows Server 2016 has its own functional levels that are used to maintain compatibility.
By default, a fresh installation of Active Directory on Windows Server 2016 DCs automatically puts you into Windows Server 2016 domain and forest functional levels. If you install Windows Server 2016 DCs into an existing legacy domain, however, you are allowed to choose which functional level you want to start the forest in. If an existing forest is in place, you can bring it to Windows Server 2016 functional level as follows:
Ensure that all DCs in the forest are upgraded to Windows Server 2016 or replaced with new Windows Server 2016 DCs.
Open Active Directory Domains and Trusts from the Tools menu in Server Manager on a DC.
In the left scope pane, right-click the domain name, and then click Raise Domain Functional Level.
In the Raise Domain Functional Level box, select Windows Server 2016, and then click Raise.
Click OK, and then click OK again to complete the task.
Repeat steps 1–5 for all domains in the forest.
Perform the same steps on the forest root, 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 2016 level, the forest can take advantage of the latest AD DS functionality. Remember, before you accomplish this task in a mixed-mode environment, Windows Server 2016 essentially operates in a downgraded mode of compatibility.