CHAPTER 4
Active Directory Domain Services Primer

Microsoft’s Active Directory technologies have come a long way since their original release with Windows 2000 Server. From a single product referred to simply as Active Directory, or AD, Windows Server 2016 now encompasses a total of five separate Active Directory technologies. Each of these technologies is similar—they all exist to supply directory services and to serve as a platform for future integration of Microsoft technologies. The additional four Active Directory services roles in Windows Server 2016 are Active Directory Lightweight Directory Services (AD LDS), Active Directory Federation Services (AD FS), Active Directory Certificate Services (AD CS), and Active Directory Rights Management Services (AD RMS).

The focus of this chapter is on the traditional Active Directory service, Active Directory Domain Services (AD DS), and touches on the information needed to understand what AD DS is and how it has become the most common enterprise directory platform in use today. This chapter initially focuses on describing a history of directory services in general. It then proceeds to give a primer on AD DS itself as a technology. Finally, specific changes made to Active Directory technologies in general are outlined at the end of the chapter, including all new improvements introduced in the Windows Server 2016 version of AD DS. The additional Active Directory services outside of AD DS are covered in subsequent chapters, primarily in Chapter 8, “Creating Federated Forests and Lightweight Directories.”

Directory services are commonly referred to as the white pages of a network. They provide user and object definition and administration. Early electronic directories were developed soon after the invention of the digital computer and were used for user authentication and to control access to resources. With the growth of the Internet and the increase in the use of computers for collaboration, the use of directories expanded to include basic contact information about users. Examples of early directories included MVS PROFS (IBM), Grapevine’s Registration Database, and WHOIS.

Application-specific directory services soon arose to address the specific addressing and contact-lookup needs of each product. These directories were accessible only via proprietary access methods and were limited in scope. Applications utilizing these types of directories were programs such as Novell GroupWise Directory, Lotus Notes, and the UNIX sendmail /etc/aliases file.

The further development of large-scale enterprise directory services was spearheaded by Novell with the release of Novell Directory Services (NDS) in the early 1990s. It was adopted by NetWare organizations and eventually was expanded to include support for mixed NetWare/NT environments. The flat, unwieldy structure of NT domains and the lack of synchronization and collaboration between the two environments led many organizations to adopt NDS as a directory service implementation. It was these specific deficiencies in NT that Microsoft addressed with the introduction of AD DS.

The development of the Lightweight Directory Access Protocol (LDAP) corresponded with the growth of the Internet and a need for greater collaboration and standardization. This nonproprietary method of accessing and modifying directory information that fully utilized TCP/IP was determined to be robust and functional, and new directory services implementations were written to utilize this protocol. AD DS itself was specifically designed to conform to the LDAP standard.

Several other Microsoft applications ran their own directory services, namely Internet Information Server and Site Server. However, each directory service was separate from the others, and integration was not very tight between the different implementations.

TCP/IP compatibility—Unlike some of the original proprietary protocols such as IPX/SPX and NetBEUI, the Transmission Control Protocol/Internet Protocol (TCP/IP) was designed to be cross-platform. The subsequent adoption of TCP/IP as an Internet standard for computer communications has propelled it to the forefront of the protocol world and essentially made it a requirement for enterprise operating systems. AD DS and Windows Server 2016, like all previous versions, utilize the TCP/IP protocol stack as their primary method of communications.

Lightweight Directory Access Protocol support—LDAP has emerged as the standard Internet directory protocol and is used to update and query data within the directory. AD DS directly supports LDAP.

Domain name system (DNS) support—DNS was created out of a need to translate simplified names that can be understood by humans (such as www.cco.com) into an IP address that is understood by a computer (such as 12.222.165.154). The AD DS structure supports and effectively requires DNS to function properly.

Security support—Internet standards-based security support is vital to the smooth functioning of an environment that is essentially connected to millions of computers around the world. Lack of strong security is an invitation to be hacked, and Windows Server 2016 and AD DS have taken security to greater levels. Support for IP Security (IPsec), Kerberos, certificate authorities, and Secure Sockets Layer (SSL) encryption is built in to Windows Server 2016 and AD DS.

Ease of administration—Although often overlooked in powerful directory services implementations, the ease in which the environment is administered and configured directly affects the overall costs associated with its use. AD DS and Windows Server 2016 are specifically designed for ease of use to lessen the learning curve associated with the use of a new environment. Windows Server 2016 also enhanced AD DS administration with the introduction of the Active Directory Administration Center, Active Directory Web Services, and an Active Directory module for Windows PowerShell command-line administration that has been greatly improved from the one originally included in Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 and Windows Server 2012 R2. PowerShell support in Windows Server 2016 AD DS has been significantly extended over earlier versions. You can now fully troubleshoot and completely automate provisioning of domain controllers and entire forests from the command line. This was essential with the arrival of the core implementation of the server, and now Nano server, both of which can be enrolled in directory services from the command-line interface. In addition, Windows Server 2016 also allows for better domain controller virtualization support, a concept that has been further expanded in this version. We will explore it more fully in this section of the book.

With the introduction of Windows Server 2016, the Internet readiness of the Microsoft environment reaches new levels of functionality, with enhancements such as the ability to join virtual domain controller templates to a forest; the ability to restore deleted objects using the Active Directory Recycle Bin, offline domain join, and 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.

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.

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.

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

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.

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.

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:

1. Ensure that all DCs in the forest are upgraded to Windows Server 2016 or replaced with new Windows Server 2016 DCs.

2. Open Active Directory Domains and Trusts from the Tools menu in Server Manager on a DC.

3. In the left scope pane, right-click the domain name, and then click Raise Domain Functional Level.

4. In the Raise Domain Functional Level box, select Windows Server 2016, 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 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.

Click here to view code image

CN=Joel Oleson,OU=SLC,DC=Companyabc,DC=com

The CN component of the distinguished name is the common name, which defines an object within the directory. The OU portion is the organizational unit in which the object belongs. The DC components define the DNS name of the Active Directory domain.

OU=SLC,DC=companyabc,DC=com

This object would have a relative distinguished name of OU=SLC. The relative distinguished name in this case defines itself as an organizational unit within its current domain container.

Global catalog servers, commonly referred to as GCs or GC/DCs, are AD DS DCs that contain a copy of the global catalog. It is wise to either locate a minimum of one global catalog server in each physical location or use RODCs in remote sites because the global catalog must be referenced often by clients and the traffic across slower wide-area network (WAN) links would limit this traffic. In addition, technologies such as Microsoft Exchange Server need fast access to global catalog servers for all user transactions, making it very important to have a global catalog server nearby. Note that Exchange cannot make use of RODCs or read-only global catalog (ROGC) servers.

Often, a larger organization will use multiple DCs and multiple global catalog servers in each large location, which distributes load, provides redundancy, and locates resources where they are needed. Choosing the right blend of global catalog servers and DCs is vital to the proper functionality of your AD DS environment.

Schema master—There is only one writable master copy of the AD DS schema in a single AD DS forest. It was deliberately designed this way to limit access to the schema and to minimize potential replication conflicts. There can be only one schema master in the entire AD DS forest.

Domain naming master—The domain naming master is responsible for the addition of domains into the AD DS forest. This OM role must be placed on a global catalog server because it must have a record of all domains and objects to perform its function. There can be only one domain naming master in a forest.

PDC emulator—This role used to exist to emulate the legacy Windows NT 4.0 PDC for down-level clients. With Windows Server 2016, the PDC emulator still performs certain roles, such as acting as the primary time sync server for the domain. There is one PDC emulator FSMO role per AD DS domain.

RID master—All objects within AD DS that can be assigned permissions are uniquely identified through the use of a security identifier (SID). Each SID is composed of a domain SID, which is the same for each object in a single domain, and a relative identifier (RID), which is unique for each object within that domain. When assigning SIDs, a DC must be able to assign a corresponding RID from a pool that it obtains from the RID master. When that pool is exhausted, it requests another pool from the RID master. If the RID master is down, you might not be able to create new objects in your domain if a specific DC runs out of its allocated pool of RIDs. There is one RID master per AD DS domain.

Infrastructure master—The infrastructure master manages references to domain objects not within its own domain. In other words, a DC in one domain contains a list of all objects within its own domain plus a list of references to other objects in other domains in the forest. If a referenced object changes, the infrastructure master handles this change. Because it deals with only referenced objects and not copies of the object itself, the infrastructure master must not reside on a global catalog server in multiple domain environments. The only exceptions to this are if every DC in your domain is a global catalog server or if you are in a single-domain environment. In the first case, there is no need to reference objects in other domains because full copies are available. In the second case, the infrastructure master role is not used because all copies of objects are local to the domain.

Transfer of an OM role to another DC can be performed as part of regular maintenance, or in the case of a disaster recovery situation where an OM server is brought offline, the OM can be seized to be brought back online. This is true for conditions where the schema master, domain naming master, or RID master either needs to be moved to another system (transfer) or has gone down and no backup is available (seized). The transfer and seizure of an OM role is done through the use of a command-line tool called Ntdsutil, shown in Figure 4.4. Keep in mind that you should use this utility only in emergency situations and should never bring the old OM server that has had its role seized back online into the domain (at the risk of some serious system conflicts). You can read more about this tool in Chapter 7, “Active Directory Infrastructure.”

When an explicit trust is set up to expedite the flow of trusts from one subdomain to another, it is known as a shortcut trust. Shortcut trusts simply allow authentication verifications to be processed faster, as opposed to having to move up and down a domain tree. In Figure 4.6, even though a transitive trust exists between the asia.companyabc.com and the europe.companyabc.com domains, a shortcut trust has been created to minimize authentication time for access between the two subdomains of this organization.

Another possible use for explicit trusts is to allow connectivity between an AD DS forest and an external domain. These types of explicitly defined trusts are known as external trusts, and they allow different forests to share information without actually merging schema information or global catalogs.

As you can see, OUs can be further subdivided into resource OUs for easy organization and delegation of administration. Far-flung offices could have their own OUs for local administration as well. It is important to understand, however, that an OU should usually be created when the organization has a specific need to delegate administration to another set of administrators. If the same person or group of people administer the entire domain, there is no need to increase the complexity of the environment by adding OUs. In fact, too many OUs can affect group policies, logons, and other factors. Chapter 6, “Designing Organizational Unit and Group Structure,” gives a detailed rundown of the design considerations encountered with organizational units.

OUs can, therefore, be structured to allow for separate departments to have various levels of administrative control over their own users. For example, a secretary in the Engineering department can be delegated control of resetting passwords for users within his own OU. Another advantage of OU use in these situations is that users can be easily dragged and dropped from one OU to another. For example, if users are moved from one department to another, moving them into their new department’s OU is extremely simple.

It is important to keep in mind that OU structure can be modified when an administrator feels fit to make structural changes, within certain constraints (namely after mapping out any group policies and administrative permissions that have been applied to the OU structure). This gives AD DS the added advantage of being forgiving for OU design flaws because changes can be made at any time.

The concept of groups was therefore devised to ease administration. If a large department needs access to that same printer, the department’s group need only be supplied the necessary permissions. This greatly eases security-based administration and has the added advantage of providing for ease of transition if specific users leave the company or are transferred to a different department. For example, suppose an administrator is in charge of printing and her user account is a member of a group named Printer Admins, which has full administrative privilege to the printers. Now, if this user transfers to become an email administrator, for example, reassigning permissions to a new print administrator is as simple as adding that new user to the Printer Admins group. This capability greatly simplifies these types of situations.

Groups in AD DS work in the way that previous group structures, particularly in Windows NT, have worked, but with a few modifications to their design. Groups are divided into two categories: group type and group scope. There are two group types in AD DS: security and distribution. Essentially, a security group can be used to apply permissions to objects for the members of the group. A distribution group, however, cannot be used for permissions but is used instead to send mail to members of the group. Group scope in AD DS is likewise divided into several components, as follows:

Machine local groups—Machine local groups, also known as simply local groups, can theoretically contain members from any trusted location. Users and groups in the local domain, as well as in other trusted domains and forests, can be included in this type of group. However, it is important to note that local groups allow resources to be accessed only on the machine where they are located, which greatly reduces their usability.

Domain local groups—Domain local groups are essentially the same thing as local groups in Windows NT, and are used to administer resources located only on their own domain. They can contain users and groups from any other trusted domain. Most typically, these types of groups are used to grant access to resources for groups in different domains.

Global groups—Global groups are on the opposite side from domain local groups. They can contain users only in the domain in which they exist but are used to grant access to resources in other trusted domains. These types of groups are best used to supply security membership to user accounts that share a similar function, such as the sales global group.

Universal groups—Universal groups can contain users and groups from any domain in the forest and can grant access to any resource in the forest. Along with this added power come a few caveats. First, universal groups are available only in Native mode domains. Second, all members of each universal group are stored in the global catalog, increasing the replication load. It is important to note, however, that universal group membership replication has been noticeably streamlined and optimized in Windows Server 2016 because the membership is incrementally replicated.

To summarize, the basic differences between OUs and groups is that groups can be used when applying security to objects, whereas OUs exist when certain administrative functionality needs to be delegated. Chapter 6 gives a more thorough explanation of groups and OU design.

Instead of having information replicated immediately between servers within a high-speed connected site, the administrator can specify to replicate information between two sites only once per night or at a time when network demands are low, allowing more bandwidth availability to replicate AD DS information.

Servers that funnel intersite replication through themselves are known as site link bridgeheads.

Figure 4.8 shows a potential Windows Server 2016 AD DS site structure. Site links exist between offices, and a DC in each site acts as the site link bridgehead. The site structure is completely modifiable and should roughly follow the WAN structure of an organization. By default, only a single site is created in AD DS, and administrators must manually create additional sites to be able to optimize replication. You can find more information about these concepts in Chapter 7.

While fully conforming to the standards established for DNS, AD DS can expand on the standard feature set of DNS and offer some new capabilities such as AD-integrated DNS, which greatly eases the administration required for DNS environments. In addition, AD DS can easily adapt to exist in a foreign DNS environment, such as UNIX BIND, as long as the BIND version is 8.2.x or later.

Given the importance of DNS in Windows Server 2016 AD DS, a thorough understanding of DNS is a must. Chapter 9, “Domain Name System, WINS, and DNSSLC,” discusses DNS in Windows Server 2016 in detail.

External (published) namespaces—A DNS name that can be resolved from anywhere on the Internet is known as a published or external namespace. This type of namespace was previously common for organizations that wanted the full convenience of having their commonly used Internet domain name represent their AD DS structure. Best practices have evolved to make this model less attractive, however, as security becomes a concern and DNS must be set up as “split brain” because it is generally ill-advised to have internal AD DNS zones accessible from the Internet.

Internal (hidden) namespaces—For many organizations, publication of their internal domain structure is too high a security risk. These organizations can easily define their AD DS with an internal namespace that is not readable from the Internet. For example, a company might have an external DNS namespace of cco.com but decide that its AD DS structure will correspond to cco.internal or any namespace it wants. Bear in mind that any combination will work for internal namespaces because there is no limitation on using .com, .net, .gov, and so on when dealing with a namespace that is not published. For all intents and purposes, you could name your domain ilovemydomain.verymuch if you want (although it’s not recommended, of course). For practical reasons, however, the .internal namespace has been specifically reserved for private name addressing, and using it is a best practice approach in many cases.

AD DS expands on other implementations of DNS by allowing administrators to integrate DNS into AD DS. By doing this, the DNS zones themselves exist as objects in the AD DS, which allows for automatic zone transfers to be accomplished. DNS replication traffic piggybacks off AD DS traffic, and the DNS records are stored as objects in the directory. In the Windows Server 2016 implementation of AD DS, AD-integrated DNS zones are optimized by being stored in the application partition, thus reducing replication traffic and improving performance. For more information about DNS, see Chapter 9.

The actual functionality of Kerberos is complicated, but essentially what happens is the computer sends an information packet to the client that requires authentication. This packet contains a “riddle” of sorts that can be answered only by the user’s proper credentials. The user applies the “answer” to the riddle and sends it back to the server. If the proper password was applied to the answer, the user is authenticated. Although used in Windows Server 2016 and earlier, this form of authentication is not proprietary to Microsoft and is available as an Internet standard. For a greater understanding of Kerberos security, see Chapter 12, “Server-Level Security.”

File Replication Service (FRS) and the Windows Server 2003 functional levels were deprecated in Windows Server 2012 R2. However, with Windows Server 2016, it’s important to remember that Windows Server 2003 operating system is no longer supported. If you still have domain controllers running Windows Server 2003, they need to be taken out of the domain.

Also raise all domains and forest functional levels to Windows Server 2008 and later. This will prevent a domain controller still running Windows Server 2003 from being added to your domain.

Windows Server 2008 itself introduced multiple changes to AD DS functionality above and beyond the Windows Server 2003 and Windows Server 2003 R2 Active Directory versions. Windows Server 2012 and 2012 R2 then introduced additional features and functionalities above those introduced with the RTM version of Windows Server 2008 and the later Windows Server 2008 R2 version. The bullet list that follows here is the accumulation of many features that are now part of Windows Server 2016:

Privileged access management (PAM)—helps protect Active Directory against credential theft such pass-the-hash, spear phishing, and so on. Using Microsoft Identity Manager (MIM), PAM provides means of setting up a so-called bastion Active Directory forest. The bastion forest establishes a special PAM trust with an existing forest. What you get is a new Active Directory environment free of any malicious code and made available to privileged accounts. PAM also introduces the ability to request administrative privileges, along with new workflows based on the approval of requests, shadow security principals (groups) and time-bound membership in a shadow group. In other words, users can be added to groups for just enough time required to perform an administrative task. PAM needs MIM and a domain functional level of at least Windows Server 2012 R2.

Azure Active Directory Join—Enterprise, business, and EDU users can join their systems to Azure AD for advanced and improved capabilities for both corporate and personal devices. This new feature lets Oxygen Services users operate without the need of a personal Microsoft account. With Oxygen Services working on PCs that are joined to corporate on-premises Windows domain, and PCs and devices that are “joined” to your Azure AD tenant (“cloud domain”), you set up features like roaming or personalization, accessibility settings and credentials, Backup and Restore, Live tiles and notifications, and so on.

Virtualization support—The ability to create DCs based on virtual machine templates. Microsoft safeguards AD DS by protecting DCs from mistakes made with virtual machine snapshotting. This concept is discussed in step-by-step detail in Chapter 7.

Dynamic access control—Dynamic access control creates a new central access policy (CAP) model that allows for file classification information to be used in authorization decisions. This allows for business intent to be more readily apparent when examining the security that is set on file servers. This model is supported on Windows Server 2016 and Windows Server 2102/R2 DCs, assuming the file servers also are running the same versions of the operating systems.

Kerberos security improvements—Microsoft supports the industry standard Flexible Authentication Secure Tunneling (FAST) feature in Kerberos to reduce the likelihood of Kerberos errors being spoofed by hacking attacks. This is often referred to as Kerberos armoring.

Better fine-grained password policy control and AD Recycle Bin interfaces—Microsoft makes it much easier to implement either fine-grained password policy controls or the AD Recycle Bin, both features that were previously difficult to implement.

Active Directory deployment—Features such as Active Directory Based Activation (AD BA) allow for server licenses to be more easily activated, while improvements to off-premises domain join functionality have been added. ADPrep functionality is also found in the deployment tools, and the entire process to join a DC to a domain or create a new forest is supported in PowerShell.

Active Directory Federation Services (AD FS) improvements—AD FS 4.0 is the latest iteration included natively in Windows Server, and supports AD DS claims directly, allowing for the population of SAML tokens with user and device claims taken directly from the Kerberos ticket. It now also provides access control and single sign-on to the cloud, into systems and applications such as Office 365, and cloud-based Software as a Service (SaaS) applications.

Group Managed Service Accounts (gMSA)—Group Managed Service Accounts allows for managed service accounts to be used by services that need to share a single security principal, such as clusters.

Enhanced PowerShell support—A whole host of new PowerShell commandlets for Windows Server 2016 AD DS has been designed, allowing for nearly all operations to be automated from the command line.

These features are in addition to the features introduced in Windows Server 2008 R2 and later, which included the following:

Active Directory Recycle Bin—Enables you to restore deleted AD DS objects.

Offline domain join—Allows for prestaging of the act of joining a workstation to the AD DS domain.

Managed Service Accounts—Provides a mechanism for controlling and managing AD DS service accounts.

Authentication mechanism assurance—Enables administrators to grant access to resources differently based on whether a user logs in with a smart card or multifactor authentication source or whether the user logs in via traditional techniques.

Enhanced administrative tools—This includes newly designed and powerful utilities such as Active Directory Web Services, Active Directory Administrative Center, Active Directory Best Practice Analyzer, a new AD DS Management Pack, and an Active Directory Module for Windows PowerShell.

The previous version of AD DS, from Windows Server 2008 and later, included the following key features that are still available with Windows Server 2016. If you are upgrading from any of the previous versions of Active Directory, all of these new features will be made available:

Ability to create multiple fine-grained password policies per domain—Lifts the restrictions of a single password policy per domain.

Ability to restart AD DS on a domain controller—Allows for maintenance of an AD DS database without shutting the machine down.

Enhanced AD DS auditing capabilities—Provides useful and detailed item-level auditing capabilities in AD DS without an overwhelming number of logs generated.

The AD DS forest and domain must be at least at Windows Server 2008 R2 or higher functional level (or at Windows Server 2016 functional level).

Membership in the Enterprise Administrators group is required to enable the AD Recycle Bin.

The process of enabling the AD Recycle Bin is nonreversible.

1. Right-click Windows PowerShell, and then select Run as Administrator.

2. From the PowerShell prompt, type in dsac.exe to start the ADAC.

3. Click Manage—Add Navigation Nodes, and then select the target domain and click OK.

4. Next, select the target domain and then under Tasks, click Enable Recycle Bin, and then click OK and OK twice to accept the changes, as shown in Figure 4.9. Click F5 to refresh ADAC.

5. To validate that the Recycle Bin is enabled, go to the CN=Partitions container, using an editor such as ADSIEdit. In the details pane, find the msDS-EnabledFeature attribute and confirm that the value includes the Recycle Bin DN that you typed above.

Alternatively, you can enable the AD Recycle Bin by using the following PowerShell command. Replace companyabc.com and DC=companyabc,DC=com with the appropriate name of the domain where the AD Recycle bin will be enabled.

Click here to view code image

Enable-ADOptionalFeature–Identity 'CN=Recycle Bin Feature,CN=Optional Features,
CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=companyabc,DC=com'–Scope ForestOrConfiguration
Set–Target 'companyabc.com'

In addition to allowing for maintenance and recovery, turning off the DC functionality on an AD DC essentially turns that DC into a member server, allowing for a server to be quickly brought out of DC mode if necessary. In addition, with RODCs, Microsoft has removed the need for local administrators on the DC to have Domain Admin rights as well, which improves overall security in places where administration of the DC server is required but full Domain Admin rights are not needed.

To take a Windows Server 2016 DC offline, follow these steps:

1. Open up the Services MMC (Start, All Programs, Administrative Tools, Services).

2. From the Services MMC, select the Active Directory Domain Services service, as shown in Figure 4.11. Right-click it and choose Stop.

3. When prompted that stopping AD DS will stop other associated services such as DNS, DFS, Kerberos, and Intersite Messaging, choose Yes to continue.

4. To restart AD DS, right-click the AD DS service and choose Start.

You need to understand a few key points about this technology before implementing it, as follows:

Domain mode must be set to a level of Windows Server 2008 and later.

Fine-grained password policies always win over a domain password policy.

Password policies can be applied to groups, but they must be global security groups.

Fine-grained password policies applied to a user always win over settings applied to a group.

The Password Settings objects (PSOs) are stored in the Password Settings Container in AD (that is, CN=Password Settings Container,CN=System,DC=companyabc,DC=com).

Only one set of password policies can apply to a user. If multiple password policies are applied, the policy with the lower-number precedence wins.

To create a custom password policy for a specific user, a PSO must be created using ADAC.

To create a new PSO, open ADAC and follow these steps:

1. Navigate to domain root—System—Passwords Settings Container.

2. Under Tasks, select New—Password Settings.

3. Enter the information into the dialog box, shown in Figure 4.12, using Table 4.1 as a reference.

4. Click OK to finalize the creation of the PSO.

To enable AD object auditing on a Windows Server 2016 DC, follow these steps:

1. From Server Manager, click Tools, Group Policy Management.

2. Navigate to forest name, Domains, domain name, Domain Controllers, Default Domain Controllers Policy.

3. Right-click the Default Domain Controllers Policy and click Edit.

4. In the GPO window, navigate to Preferences, Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy.

5. Under the Audit Policy setting, right-click Audit Directory Service Access and click Properties.

6. Check the Define These Policy Settings check box, and then check the Success and Failure check boxes, as shown in Figure 4.13.

7. Click OK to save the settings.

Global AD DS auditing on all DCs will subsequently be turned on. Audit event IDs will be displayed as Event ID 5136, 5137, 5138, or 5139, depending on whether the operation is a modify, create, undelete, or move, respectively.

Active Directory Lightweight Directory Services (AD LDS)—AD LDS, previously referred to as Active Directory in Application Mode (ADAM), is a smaller-scale directory service that can be used by applications that require a separate directory. It can be used in situations when a separate directory is needed but the overhead and cost of setting up a separate AD DS forest is not warranted. You can find detailed information about AD LDS in Chapter 8, “Creating Federated Forests and Lightweight Directories.”

Active Directory Federation Services (AD FS)—AD FS 3.0, included in Windows Server 2016 provides for Single Sign-On technology to allow for a user logon to be passed to multiple web applications within a single session. You can find more information about AD FS in Chapter 8.

Active Directory Certificate Services (AD CS)—AD CS provides for the ability to create a public key infrastructure (PKI) environment and assign PKI certificates to AD users and machines. These certificates can be used for encryption of traffic, content, or logon credentials. You can find more information about deploying AD CS in Chapter 14, “Transport-Level Security.”

Active Directory Rights Management Services (AD RMS)—AD RMS is the evolution of the older Windows Rights Management Server technology. AD RMS is a service that protects confidential information from data leakage by controlling what can be done to that data. For example, restrictions can be placed on documents, disallowing them from being printed or programmatically accessed (such as by cutting/pasting of content). Chapter 13 covers this Active Directory technology in more detail.

Read-only domain controller (RODC) support—Windows Server 2016 includes the ability to deploy DCs with read-only copies of the domain. This is useful for remote branch office scenarios where security might not be tight. This scenario is covered in detail in Chapter 7.

Group Policy central store—Administrative templates for group policies are stored in the SYSVOL on the PDC emulator in Windows Server 2016, resulting in reduced replication and reduced SYSVOL size.

DFS-R replication of the SYSVOL—A Windows Server 2008 RTM/R2 functional domain uses the improved Distributed File System Replication (DFS-R) technology rather than the older, problematic File Replication Service (FRS) to replicate the SYSVOL.

Active Directory database mounting tool—The Active Directory database mounting tool (DSAMain.exe) enables administrators to view snapshots of data within an AD DS or AD LDS database. This can be used to compare data within databases, which can prove useful when performing AD DS data restores.

GlobalNames DNS zone—Windows Server 2016 DNS allows for creation of the concept of the GlobalNames DNS zone. This type of DNS zone allows for a global namespace to be spread across multiple subdomains. For example, a client in the asia.companyabc.com subdomain would resolve the DNS name portal.asia .companyabc.com to the same IP address as a client in a different subdomain resolving portal.europe.companyabc.com. This can improve DNS resolution in multizone environments. You can read more about this technology in Chapter 10.

Windows Server 2003 Active Directory Domain Rename Tool—Windows Server 2003 originally introduced the concept of domain rename, which has continued to be supported in Windows Server 2016. This enables administrators to prune, splice, and rename AD DS domains. Given the nature of corporations, with restructuring, acquisitions, and name changes occurring constantly, the ability of AD DS to be flexible in naming and structure is of utmost importance. The Active Directory Domain Rename Tool was devised to address this very need.

Before AD DS domains can be renamed, several key prerequisites must be in place before the domain structure can be modified. First, and probably the most important, all DCs in the entire forest must be upgraded from Windows Server 2003 to Windows Server 2008 or later. In addition, the domains and the forest must be upgraded to at least Windows Server 2008 functional level before any consideration to upgrade servers and domain controllers to Windows Server 2016. Finally, comprehensive backups of the environment should be performed before undertaking the rename.

The domain rename process is complex and should never be considered as routine. After the process, each DC must be rebooted and each member computer across the entire forest must also be rebooted (twice). For a greater understanding of the Domain Rename Tool and process, see Chapter 5.

Cross-forest transitive trust capabilities—Windows Server 2003 Active Directory introduced the capability to establish cross-forest transitive trusts between two disparate AD DS forests. This capability allows two companies to share resources more easily, without actually merging the forests. This support continues for all versions later than Windows Server 2003. Forests must be running the same functional levels for the transitive portion of this trust to function properly.

AD DS replication compression disable support—You have the ability to turn off replication compression to increase DC performance. This would normally be an option only for organizations with very fast connections between all their DCs.

Schema attribute deactivation—Developers who write applications for AD DS continue to have the ability to deactivate schema attributes, allowing custom-built applications to use custom attributes without fear of conflict. In addition, attributes can be deactivated to reduce replication traffic.

Incremental universal group membership replication—Windows 2000 Active Directory had a major drawback in the use of universal groups. Membership in those groups was stored in a single, multivalued attribute in AD DS. Essentially, what this meant was that any changes to membership in a universal group required a complete re-replication of all membership. In other words, if you had a universal group with 5,000 users, adding number 5,001 would require a major replication effort because all 5,001 users would be re-replicated across the forest. Windows Server 2003 and 2008 simplify this process and allow for incremental replication of universal group membership. In essence, only the 5,001st member is replicated in Windows Server 2003/2008.

AD-integrated DNS zones in application partitions—DNS replication was enhanced by storing DNS zones in the application partition. This basically meant that fewer objects needed to be stored in AD, reducing replication concerns with DNS.

AD lingering objects removal—Another major improvement originally introduced with Windows Server 2003 and still supported now is the ability to remove lingering objects from the directory that no longer exist.

Design domains sparingly: Don’t necessarily set up multiple domains for different remote offices or sites.

Turn on the Active Directory Recycle Bin after upgrading to Windows Server 2016 forest-functional level to take advantage of the ability to do a full-fidelity restore of domain objects that have been deleted and to use the much improved interface provided with this version of AD DS.

Purchase any external domain namespaces that you might want to use on the Internet.

Use RODCs in remote sites where security is not as strong.

Strongly consider using dynamic DNS in an AD DS domain environment.

Turn on global AD DS auditing to better understand changes made to Active Directory objects.

Consider using cross-forest transitive trusts between two disparate AD DS forests when merging the forests is not an option.

Place the infrastructure master role on a DC that isn’t also a global catalog, unless all DCs in the domain are global catalog servers or you are in a single domain environment.

Properly plan fine-grained password policies to avoid conflicting policies being applied to users. Leave enough numeric space between the precedence numbers of individual PSOs so as to allow for new PSOs to be placed above and below the PSO in order of priority.

Switch to Windows Server 2016 Functional mode as early as possible, to be able to take advantage of the numerous improvements, including AD Recycle Bin support, fine-grained password policies, Kerberos improvements, last interactive logon information, and the use of DFS-R for the SYSVOL replication.

Use DC virtualization with Windows Server 2008 R2 to be able to quickly stage and deploy multiple DCs across a wide environment.

Seriously consider deploying AD DS DCs on Server Core to reduce their security footprint. Use PowerShell to manage and control the DCs.

Use global groups to contain users in the domain in which they exist but also to grant access to resources in other trusted domains.

Use universal groups to contain users from any domain in the forest and to grant access to any resource in the forest.