Managing AD DS with PowerShell
Active Directory, the identity glue that binds on-premises Microsoft networks, is at the center of almost all on-premises networks. Although each computer can have its own unique individual user and service accounts, Active Directory provides a central user, a computer, and a service account store.
But Active Directory is more than an identity store; it can also be used to store data for Active Directory-aware applications. One example of this is Microsoft Exchange Server, which stores server configuration information in Active Directory. Other applications, such as System Center Configuration Manager, are also highly dependent on Active Directory.
Active Directory is a topic so vast that completely covering it would require a multi-volume set. In this chapter, we look at managing Active Directory. We also cover deploying domain controllers, forests, domains, service accounts, and Group Policy, as well as examining how to restore deleted items.
Managing Active Directory
Domain Controllers are one of, if not the, highest value target for attackers on your network. An attacker that is able to take control of a domain controller has control over every domain joined computer in the organization. Also known as “domain dominance,” having control of a domain controller means having control of all the authentication and authorization processes in the domain.
While we will discuss server hardening in more detail in Chapter 19, “Hardening Windows Server and Active Directory,” one strategy for increasing server security is to reduce the attack surface. As mentioned in Chapter 2, where possible, you should deploy roles on computers installed in the Server Core configuration because this configuration has a smaller attack surface than a server that includes desktop components. Server Core is a great option for domain controller deployment because it provides a reduced attack surface, which strengthens the security of the installation.
Remote rather than local administration
You should perform Active Directory–management tasks remotely using Windows Admin Center, management consoles, or PowerShell rather than signing on to the domain controller directly using RDP. If you’re doing all your administrative tasks remotely using Windows Admin Center, management consoles, or PowerShell, it won’t make any difference to you that you’ve deployed the domain controller in the Server Core configuration. Using remote consoles also reduces the chance of malware being introduced to the domain controller. There are countless stories of organizations having their security compromised because an administrator signed in to a server using Remote Desktop, went to download a utility from the Internet using the built-in web browser, and ended up with more than they bargained for in terms of malware because they weren’t careful about their browsing destinations.
A general rule about consoles is that if you need to perform a task a couple of times, you should use Windows Admin Center or a console. If you are new to a task, you’re less likely to mess it up if you use a GUI tool. This is because a GUI tool holds your hand and assists you through the task. If you must repeatedly perform the same task, and it’s a task that you are familiar with, you should automate it using tools such as PowerShell. You’ll learn about the Active Directory related PowerShell cmdlets later in this chapter.
There are a number of consoles that you can use to perform Active Directory administrative tasks. These include the following:
Active Directory Administrative Center
Active Directory Users and Computers
Active Directory Sites and Services
Active Directory Domains and Trusts
At the time of writing, Windows Admin Center provides some Active Directory administrative functionality but not nearly enough that AD administrators could use it as their primary tool for managing Active Directory.
Active Directory Administrative Center
Active Directory Administrative Center (ADAC) was introduced with Windows Server 2012, but it never really caught on as the primary method of managing Active Directory for most administrators. Active Directory Administrative Center allows you to manage users, computers, and service accounts to perform tasks with the Active Directory, such as Recycle Bin, and to manage functionality, such as Dynamic Access Control.
Active Directory Administrative Center is a newer console that has better search functionality than the other consoles listed in this chapter, which haven’t substantively changed since the release of Windows 2000. Hopefully, Windows Admin Center will improve to the point that by the next edition of this book, it can be used as the primary GUI admin tool for Active Directory administration.
You can use Active Directory Administrative Center to manage the following:
User, computer, and service accounts
Domain and Forest functional level
Fine-grained password policies
Active Directory Recycle Bin GUI
Authentication Policies
Dynamic Access Control
ADAC is built on PowerShell, meaning that it provides a graphical interface to build and enact PowerShell cmdlets. You can use the PowerShell History viewer, shown in Figure 4-1, to see which cmdlets were used to carry out a task that you configured in the GUI. This simplifies the process of automating tasks because you can copy code straight out of the PowerShell history and then paste it into tools such as PowerShell ISE or Visual Studio Code.
Figure 4-1 Active Directory Administrative Center
One of the most useful elements of Active Directory Administrative Center is the search functionality. You can use this functionality to locate accounts that might require further attention, such as users who haven’t signed in for a certain period of time, users configured with passwords that never expire, or users with locked accounts. Using the Add Criteria option in the Global Search node of the Active Directory Administrative Center, you can search based on the following criteria:
Users with disabled/enabled accounts
Users with expired passwords
Users whose passwords have an expiration date or no expiration date
Users with enabled but locked accounts
Users with enabled accounts who have not signed in for more than a given number of days
Users with a password expiring in a given number of days
Computers running as a given domain controller type
Last modified between given dates
Object type is user/inetOrgPerson/computer/group/organizational unit
Directly applied password settings for a specific user
Directly applied password settings for a specific global security group
Resultant password settings for a specific user
Objects with a given last known parent
Resource property lists containing a given resource property
Name
Description
City
Department
Employee ID
First name
Job Title
Last Name
SamAccountName
State/Province
Telephone number
UPN
Zip/Postal Code
Phonetic company name
Phonetic department
Phonetic display name
Phonetic first name
Phonetic last name
There are several tasks that you can’t do with Active Directory Administrative Center or with PowerShell, such as running the delegation of Control Wizard. Generally speaking, when managing Active Directory using a console on Windows Server 2019, you should use Active Directory Administrative Center as your first option and fall back to Active Directory Users and Computers if you can’t accomplish what you need to in ADAC.
Active Directory Users and Computers console
The Active Directory Users and Computers console is the one that many system administrators use to perform basic AD-related tasks. They use this console primarily out of habit because almost all functionality present in this console is also present in Active Directory Administrative Center. Active Directory Users and Computers has been around since the days of Windows 2000 Server.
Active Directory Users and Computers allows you to perform tasks including:
Running the Delegation Of Control Wizard
Administering different domains within the forest
Selecting which domain controller or LDAP port the tool connects to
Finding objects within the domain
Raising the domain functional level
Managing the RID Master, PDC Emulator, and Infrastructure Master FSMO role locations
Creating and editing the properties of
Computer accounts
User accounts
Contacts
Groups
InetOrgPerson
msDS-ShadowPrincipalContainers
msImaging-PSPs
MSMQ Queue Alias
Organizational Unit
Printers
Shared Folder
Resultant Set of Policy planning
The View Advanced Features function allows you to see more details of the Active Directory environment. You enable this from the View menu of Active Directory Users And Computers. Enabling this view allows you to see containers that aren’t visible in the standard view. If you’ve ever read a set of instructions that tell you to locate a specific object using Active Directory Users And Computers, and you haven’t been able to find that object, chances are that you haven’t enabled the View Advanced Features option.
The Delegation Of Control Wizard is only available in Active Directory Users And Computers. This wizard allows you to delegate control over the domain and organizational units (OU). For example, you use this wizard to delegate the ability for a specific group to reset user passwords in an OU. This wizard is useful when you want to delegate some privileges to a group of IT ops staff, but you don’t want to grant them all the privileges that they’d inherit if you made them a member of the Domain Admins group. You’ll learn more about delegating permissions in Chapter 19, “Hardening Windows Server and Active Directory.”
Active Directory Sites and Services console
You use the Active Directory Sites And Services console to manage Active Directory sites, which indirectly allows you to control a number of things, including replication traffic and which server a client connects to when using products such as Exchange Server. Sites are configured for the forest, with each domain in the forest sharing the same set of sites.
An Active Directory site is a collection of TCP/IP subnets. Sites allow you to define geographic locations for Active Directory on the basis of TCP/IP subnets. You can have multiple TCP/IP subnets in a site. You should put subnets together in a site where the hosts in that site have a high-bandwidth connection to each other. Usually, this means being in the same building, but it could also be multiple buildings with very-low-latency gigabit links between them.
For example, imagine that your organization has its head office in Melbourne and a branch office in Sydney. You can set up two sites: one site for Melbourne and the other for Sydney. This ensures that computers in the Melbourne location interact as much as possible with resources located in Melbourne, and computers in the Sydney location interact as much as possible with resources located in Sydney.
You associate the TCP/IP subnets in the head office with the Melbourne site and the TCP/IP subnets in the branch office with the Sydney site. After you do this, functionality such as replication topology is automatically configured.
The default name for the site you installed the first domain controller in is something like Default-First-Site-Name. You should change this as appropriate prior to adding subnets. When you add a subnet, you need to specify its associated site, so add sites first and then add subnets after your sites are present.
To add a new Active Directory Site, right-click the Sites node in the Active Directory Sites And Services console and click New Site. Specify the site name and choose Select A Site Link object. A site link object represents a connection between two sites. The default site link object is named DEFAULTIPSITELINK. You can change the site link object later. Figure 4-2 shows the creation of a site named Sydney.
Figure 4-2 Create a new site.
To add a subnet, right-click the Subnets node in Active Directory Sites And Services and then click New Subnet. You can specify the new subnet in IPv4 or IPv6 format. After you’ve specified the subnet, you need to specify which site the subnet is associated with. Figure 4-3 shows the 10.10.10.0/24 subnet associated with the Melbourne site.
Figure 4-3 New subnet
Site links represent connections between sites. You can create IP or SMTP site links. You almost always use IP site links because these are authenticated and encrypted. You use SMTP site links when the connection between sites is unreliable. When configuring a site link, you can configure the replication interval, with the default being once every 180 minutes. You can also configure the hours in which replication can occur, the default being 24 hours a day, 7 days a week. You create a site link by right-clicking the IP node under Inter-Site-Transports in the Active Directory Sites And Services console and by clicking New Site Link. And you specify two or more sites that are connected by the link. After the link is created, you can modify the replication schedule, cost, and the hours replication can occur in. Site links with lower replication costs are preferred over site links with higher replication costs.
A site link bridge is a collection of site links, but you only need to use them when your IP network is not fully routed. For example, you might create a site link bridge to connect the Sydney-Melbourne and Melbourne-Perth site links as a way of ensuring that replication traffic between Sydney and Perth passes through the Melbourne site.
After you’ve provided information about sites, subnets, site links, and site-link bridges, an Active Directory component called the Knowledge Consistency Checker automatically creates a replication topology using a least-cost spanning tree design.
Domain controllers automatically associate with the site that they are deployed in. If you didn’t set up sites and subnets prior to deploying domain controllers in separate locations, right-click the domain controller that you want to move within Active Directory Sites And Services, click Move, and then specify the destination site.
Active Directory Domains and Trusts console
You use the Active Directory Domains And Trusts console to configure and manage trust relationships. By default, all domains in a forest trust each other. Your primary use of this console is to create trust relationships between:
Domains in separate forests
Separate forests
Kerberos V5 realms
When creating a trust, you can choose between the following types:
One-Way: Incoming. In this trust relationship, your local domain or forest is trusted by a remote domain or forest.
One-Way: Outgoing. In this trust relationship, your local domain or forest trusts a remote domain or forest.
Two-way. In this trust relationship, your local domain or forest trusts, and is trusted by, a remote domain or forest.
When configuring a trust, you can determine whether you want to configure selective authentication. By default, the trust works for all users in the source or destination forest or domain. When you configure selective authentication, you can limit which security principals are allowed access and which resources they can access. You do this by configuring those users with the Allowed To Authenticate permission on each resource computer in the trusting domain or forest.
Domain controllers
Domain controllers (DCs) are the heart of Active Directory. Their primary role is to host the Active Directory database, stored in the ntds.dit file. Given their importance, you should limit who can sign on locally to a domain controller.
Deployment
Although the wizard for deploying a domain controller has been updated from what it looked like back in Windows Server 2008 R2, the process is still functionally the same. You choose whether you want to:
Add a domain controller to an existing domain
Add a new domain to an existing forest
Add a new forest
If you are adding a domain controller to an existing domain, have the computer domain joined before promoting it. When you add a new domain to an existing forest, choose between adding a child domain or a tree domain. When you add a tree domain, you create a new namespace within an existing forest. For example, you can create the Adatum.com domain in the existing Contoso.com forest. Contoso.com remains the root domain of the forest.
Microsoft’s recommendation is that you use a registered root domain name, such as Contoso.com for the domain name, rather than a non-externally resolvable domain name like contoso.internal. Having a registered, externally resolvable domain name simplifies the process when configuring synchronization with Azure AD Connect.
Windows Server 2019 supports split DNS, which means that you can configure zones so that a subset of records is resolvable for clients on external networks. Many organizations still use non-resolvable domain names, and you should only take the Microsoft advice into account if you are deploying a new forest or you are reconfiguring a domain in preparation for synchronizing with Azure Active Directory.
When you add a new child domain to an existing forest, you specify the parent domain. For example, you could add the australia.contoso.com child domain to the contoso.com domain. After you’ve done that, you can add the victoria.australia.contoso.com child domain to the australia.contoso.com parent domain. Adding a child domain requires Enterprise Administrator credentials in the forest.
Domain controllers can also host the DNS service and function as global catalog servers. In Windows Server environments, DNS is almost always hosted on domain controllers. You’ll learn more about DNS configuration and options in Chapter 5 “DNS, DHCP, and IPAM.” Global Catalog servers are covered later in this chapter.
When deploying a domain controller in an environment with multiple sites configured, you can select which site you want the domain controller to belong to. You can change this after deployment using the Active Directory Sites And Services console.
Directory Services Restore Mode passwords
Directory Services Restore Mode (DSRM) allows you to perform an authoritative restore of deleted objects from the Active Directory database. You must perform an authoritative restore of deleted items because if you don’t, the restored item is deleted the next time the AD database synchronizes with other domain controllers where the item is marked as deleted. Authoritative restores are covered later in this chapter. You configure the Directory Services Restore Mode password on the Domain Controller Options page of the Active Directory Domain Services Configuration Wizard, as shown in Figure 4-4. Note that even though a computer running Windows Server 2019 is being configured as a domain controller, the maximum Forest and Domain functional level is Windows Server 2016. This is because there is no Windows Server 2019 domain or forest functional level.
Figure 4-4 Configuring Domain Controller Options
In the event that you forget the DSRM password, which, in theory, should be unique for each domain controller in your organization, you can reset it by running ntdsutil.exe from an elevated command prompt and entering the following command at the ntdsutil.exe prompt, at which point you are prompted to enter a new DSRM password:
Reset password on server null
Advanced installation options
One of the advanced installation options for domain controllers is to install from media. Installing from media gives you the option of pre-populating the AD DS database for a new DC from a backup of an existing DC’s AD DS database, rather than having that database populated through synchronization from other domain controllers in your organization. This is very useful when you need to deploy a DC at a remote location that has limited WAN connectivity and you don’t want to flood the WAN link with AD DS database synchronization traffic during domain controller deployment. Instead, you ship a backup of the AD DS database to the remote site and that backup is used to perform initial AD DS database population. After the newly installed DC connects to other domain controllers, it performs a synchronization, bringing the database up to date with a much smaller synchronization than what would be required when synchronizing from scratch.
Server Core
As the reduced attack surface area of Server Core deployments makes it more secure, domain controllers—which don’t have a GUI dependency—are one of several perfect workloads for Server Core deployments. Microsoft recommends deploying domain controllers using the Server Core deployment option and managing those servers remotely.
To configure a computer running Server Core as a domain controller, you can:
Remotely connect to the server using the Server Manager console.
Run the Add Roles And Features Wizard to remotely install the Active Directory binaries on the server.
Run the Active Directory Domain Services Configuration Wizard to promote the computer to a domain controller.
You can also use Windows Admin Center to deploy the AD DS feature, but at the time this book was written, you couldn’t configure the feature once it was deployed. As an alternative to using the wizard or console, you can run the following PowerShell commands, either locally or remotely, to install the AD DS binaries and promote the server to domain controller:
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools Install-ADDSDomainController -DomainName contoso.internal -InstallDNS:$True -credential (Get-Credential)
In addition to running this set of commands, you also need to specify a Directory Service Restore Mode password before the computer running Server Core completes the domain controller promotion process. You’ll need to use the Install-ADDSForest cmdlet if you are installing the first domain in a new forest, as shown here:
Install-ADDSForest -DomainName contoso.internal -InstallDNS
Virtualized domain controllers
Domain controllers can be run on supported virtualization platforms, including the latest version of VMware and Hyper-V. With the Production Checkpoints feature available in Windows Server 2019 Hyper-V, domain controllers can be restored from a checkpoint without causing problems. Microsoft recommends that you run virtualized domain controllers as shielded VMs on a guarded virtualization fabric because this will minimize the chance that a nefarious or compromised virtualization administrator account could be used to access the contents of the DC VM. You can learn more about production checkpoints, shielded VMs, and guarded fabrics in Chapter 6, “Hyper-V.”
Global catalog servers
Global catalog servers host a full copy of all objects stored in its host directory and a partial, read-only copy of all other objects in other domains in the same forest. They are used when it’s necessary to perform a check of other objects in the forest, such as when a check is performed of a universal group’s membership, which could contain members from other domains in the forest.
You can use the Active Directory Sites And Services console to configure a server to function as a global catalog server by right-clicking the NTDS settings of the server. Alternatively, you can run the Set-ADObject cmdlet. For example, to configure the DC MEL-DC1 in the Melbourne-Site site as a global catalog server, run the following command:
Set-ADObject "CN=NTDS Settings,CN=MEL-DC1,CN=Servers,CN=Melbourne-Site,CN=Sites,
CN=Configuration,DC=Contoso,DC=Internal" -Replace @{options='1'}
Read only domain controllers
Read Only Domain Controllers (RODC) are a special type of domain controller. They host a read-only copy of the AD DS database. Rather than storing the passwords for all users in the domain, RODCs only store the passwords of a specific set of accounts that you configure. The first domain controller in a new domain or forest cannot be an RODC.
The justification for RODCs is that DCs sometimes need to be located in places where servers have poor physical security and might be stolen. For example, many organizations had branch offices where servers were located under someone’s desk. A good rule of thumb is that you should consider a location insecure if it is accessible to anyone other than IT. If a janitor can pull out a computer’s power cord to power a vacuum cleaner, the computer isn’t in a secure location.
If a server that hosts a domain controller is stolen, the best practice is to reset the account passwords that might have been compromised because it’s possible, with the correct tools, to extract passwords from the AD DS database if you have direct access to it. If an ordinary DC is stolen, you would, in theory, need to reset the passwords of every account in the domain because you could never be sure that someone hadn’t gained access to the Active Directory database and found a way to extract the passwords of people in your organization.
With shielded VMs and shielded fabrics, it’s possible to run a DC in a manner where the VM itself is protected by encryption. In the event that the host server is stolen, the AD DS database cannot be recovered because the contents of the virtualization server’s storage is encrypted using BitLocker.
RODC password replication
One of the most important steps in configuring an RODC is limiting which passwords can be replicated down to the server from a writable domain controller. The default configuration of an RODC has it store almost everything from Active Directory except for user and computer account passwords. In the event that a user or computer account needs to be authenticated against Active Directory, the RODC acts as a proxy for a writable Windows Server DC. The authentication occurs but depends on the WAN link to be functional because if you could host a writable DC locally, you wouldn’t need the RODC.
Although you can configure an RODC to not cache any passwords locally, you can configure an RODC to cache the passwords of select staff working at a branch office to speed their login. Caching passwords also allows branch office users to log in if the WAN link fails. If the WAN link fails and the user’s credentials are not cached, the user is simply unable to log in to the domain.
You configure which accounts can authenticate using the RODC by using the Password Replication Policy, as shown in Figure 4-5. By default, only members of the Allowed RODC Password Replication group can use the RODC to authenticate. This is only the case if the user account is not a member of the Account Operators, Administrators, Backup Operators, Server Operators, or Denied RODC Password Replication Group groups.
Figure 4-5 Password Replication Policy
RODC local administrators
Because you deploy RODCs as a security measure, they are almost always placed at branch office sites. Because resources at branch office sites are often sparse, it is also likely that you’ll co-locate other services on the server hosting the RODC role. For example, a server that functions as an RODC can also function as a file server, DNS server, DHCP server, and local intranet server.
If the computer hosting the RODC role also needs to host other roles, you might need to grant administrator access to a user who works at the branch office (but who is not a member of your organization’s usual IT staff) in case your normal remote administration techniques don’t work. RODCs differ from normal domain controllers in that you can grant local administrator access without having to make the user a member of the Domain Admins group.
To configure a user to function as a local administrator on the computer that hosts the RODC role, edit the properties of the RODC’s computer account and configure a security group for the Managed By setting.
In Chapter 19, “Hardening Windows Server and Active Directory,” you’ll learn about Just Enough Administration (JEA), a technology that you could use to allow a user to perform remote administrative tasks on an RODC without being made an RODC local administrator.
Decommissioning an RODC
If you suspect that an RODC has been compromised, you can delete the RODC’s account from the Domain Controllers container in Active Directory Users And Computers. When you do this, you get the option of resetting all passwords for user and computer accounts that were cached on the RODC, as well as the option of exporting a list of all potentially compromised accounts.
Virtual domain controller cloning
Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019 support virtual domain controller cloning. Rather than redeploying domain controllers from scratch each time you need one, domain controller cloning allows you to take an existing virtual machine, make a copy of it, and deploy that copy.
Virtual domain controller cloning has the following prerequisites:
Hypervisor must support VM-GenerationID. The version of Hyper-V included with Windows Server 2012 and later supports this technology, as does the most recent versions of VMware.
The source domain controller needs to be running Windows Server 2012 or later.
The domain controller that hosts the PDC Emulator role must be online and contactable by the cloned DC. The computer that hosts the PDC Emulator role must also be running Windows Server 2012 or later.
The source DC must be a member of the Cloneable Domain Controllers group.
You also need to create the DCCloneConfig.xml file. You can do this by using the New-ADDCCloneConfig cmdlet in PowerShell. When running this cmdlet, you need to specify the cloned DC’s IPv4 address information and the site the cloned DC is deployed into. For example, to create the clone configuration file for a clone DC that has the IP address 10.10.10.42 with the subnet mask 255.255.255.0, default gateway of 10.10.10.1, DNS server address of 10.10.10.10, and site name MEL-SITE, issue this command:
New-ADDCCloneConfigFile -IPv4Address 10.10.10.42 -IPv4DefaultGateway 10.10.10.1 -IPv4SubnetMask 255.255.255.0 -IPv4DNSResolver 10.10.10.10 -Static -SiteName MEL-SITE
After the clone configuration file is created, you import the VM using this file and specify a copy of the source DC’s exported virtual hard disk.
AD DS structure
Active Directory is made up of forests and domains. A forest is a collection of Active Directory domains that share a schema and some security principals. The majority of organizations in the world have a single forest domain. Multiple domain forests are generally used by larger, geographically dispersed organizations.
Domains
For the majority of organizations in the world, a single domain would be sufficient. There are two general reasons for having multiple domains in a forest. The first is that your organization is geographically dispersed, and there are issues around domain replication traffic. The second is that your organization is very large. A single domain can hold a staggering number of objects. Unless your organization has tens of thousands of users, a single domain is usually more than enough.
A domain tree is a collection of domains that share a namespace in a parent–child relationship. For example, the domains australia.contoso.com and tonga.contoso.com would be child domains of the contoso.com domain.
You should always deploy at least two domain controllers per domain for redundancy purposes. Make sure that if you have a multi-domain forest, you are making regular backups of the domain controllers in the root domain. There has been more than one organization with a multidomain forest that has had the root domain’s domain controllers fail irreparably, making it necessary to redeploy the entire forest from scratch.
Domain functional levels
The domain functional level determines which Active Directory features are available and which operating systems can participate as domain controllers within the domain. The domain functional level determines the minimum domain controller operating system. For example, if the domain functional level is set to Windows Server 2012, domain controllers must run Windows Server 2012 or later. This rule does not apply to member servers. You can have a domain running at the Windows Server 2016 functional level that still has servers running the Windows Server 2008 R2 operating system. Unlike previous versions of the Windows Server operating system, which introduced new domain functional levels, there is no Windows Server 2019 domain functional level.
Windows Server 2019 DCs support the following functional levels:
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
You can introduce a DC running Windows Server 2019 to a domain at the Windows Server 2008 functional level as long as all the appropriate updates are installed. You can raise the functional level after you’ve retired existing domain controllers running older versions of the Windows Server operating system. If all your domain controllers are running Windows Server 2019, you should update your domain functional level to the Windows Server 2016 functional level.
Forests
A forest is a collection of domains that share a schema. There are automatic trust relationships between all domains in a forest. Accounts in one domain in a forest can be granted rights to resources in other domains. As mentioned earlier in this chapter, forests don’t need to have a contiguous namespace. For example, a forest can contain both the contoso.com and Adatum.com domains.
There are several reasons why an organization might have multiple forests with trust relationships configured between those forests. The most common reason is that one organization has acquired another organization, and multiple forests exist until such a time that the users and resources hosted in the forest of the acquired organization are moved to the forest of the acquiring organization. A less common one is that an organization is splitting off a part of itself and users need to be migrated out of the existing forest and into a new forest prior to the split occurring.
Forest functional levels are determined by the minimum domain functional level in the forest. After you’ve raised the domain functional levels in the forest, you can raise the forest functional level. Unlike in previous versions of Active Directory, it is possible to lower both the forest and domain functional levels after they have been raised. An important caveat with this is that the forest functional level must be lowered so that it is never higher than the lowest intended domain functional level.
Account and resource forests
Organizations are increasingly deploying what are known as Enhanced Security Administrative Environment (ESAE) forests. In an ESAE forest design, all the accounts used for administrative tasks in the production forest are hosted in a second forest known as the ESAE, bastion, or administrative forest. The ESAE forest is configured with one-way trust relationships with the production forest.
In their native administrative forest, the accounts used for administrative tasks in the production forest are traditional unprivileged user accounts. These accounts and the groups that they are members of in the administrative forest are delegated privileges in the production forest.
The advantage of this approach is that should one of these accounts become compromised, it can’t be used to alter any permissions or settings in the administrative forest because the account only has privileges in the production forest.
Organizational units
The benefit of a comprehensive OU structure is that it simplifies the delegation of permissions over objects and allows you to apply GPOs closer to the accounts that they influence. While it’s possible to filter GPOs based on security groups or WMI queries, it’s important to remember that each GPO within a computer and user account’s scope must be checked to see if it applies. If you have all of your GPOs applied at the domain level and filtered on the basis of security group or WMI query, your Group Policy processing time at startup and sign-on will be substantially longer than if you apply GPOs as close to the accounts they influence as possible.
Better privilege delegation targeting is also a great reason to have a good OU structure. When delegating privileges, you want to ensure that you only delegate privileges over an appropriate set of objects. For example, imagine that you want to allow each department’s administrative assistant to have the ability to reset passwords for users within their respective department. If all the user accounts for your organization are located in one OU, you won’t be able to do this because, at best, you’ll provide each administrative assistant with the ability to reset every user’s password in the organization. If user accounts are located in department-specific OUs, you can then delegate the ability to reset passwords on a per-OU basis. This way, the administrative assistant for the Marketing department can be granted the ability to change passwords for user accounts located in the Marketing OU without granting him or her the ability to change passwords for user accounts located in the Accounting OU.
When you create OUs in Windows Server 2019, the OUs are automatically configured so that accidental deletion protection is enabled.
Flexible Single Master Operations roles
The Flexible Single Master Operations (FSMO) roles are five special roles present on domain controllers. Two of these roles—the schema master and the domain naming master—are unique within each forest. The other three roles—PDC Emulator, infrastructure master, and RID master—must be present within each domain in the forest. For example, in a three-domain forest, there is only one schema master and domain naming master, but each domain in the forest has its own PDC emulator, infrastructure master, and RID master.
By default, FSMO roles are allocated to the first domain controller in a domain. After you have more than one domain controller in each domain, you should manually start to move FSMO roles to other domain controllers. This protects you from a situation where the first domain controller deployed in each domain goes offline and all FSMO roles become unavailable. When you do need to take a domain controller offline for an extended period, ensure that you transition any FSMO roles that it hosts to another domain controller in the same domain.
Schema master
The schema master is the single server in the forest that is able to process updates to the Active Directory schema. The Active Directory schema defines the functionality of Active Directory. For example, by modifying the schema, you can increase the available attributes for existing objects as well as enable Active Directory to store new objects. Products including Exchange Server and Configuration Manager require that the default Active Directory schema be extended prior to product installation so that each product can store important data in Active Directory.
The domain controllers that host the schema master role should be located in the root domain of the forest. If you need to extend the schema prior to installing products such as Exchange Server, do so either on the computer that hosts the schema master role or on a computer in the same site. The account used to extend the schema needs to be a member of the Schema Admins security group.
You can determine which computer hosts the schema master role by running the following PowerShell command:
Get-ADForest contoso.internal | FT SchemaMaster
Domain naming master
The domain naming master is a forest level role that is responsible for managing the addition and removal of domains from the forest. The domain naming master also manages references to domains in trusted forests. In a multi-domain environment, the domain controller that hosts this forest level role should be deployed in the root forest.
You can determine which server hosts the domain naming master role by running the following PowerShell command:
Get-ADForest contoso.internal | FT DomainNamingMaster
PDC emulator
The PDC emulator role is a domain level FSMO role that is responsible for handling both changes to account passwords as well as domain time synchronization. PDC emulators in child domains synchronize time against the PDC emulator in the forest root domain. You should ensure that the PDC emulator in the forest root domain synchronizes against a reliable external time source.
To determine which domain controller in a specific domain hosts the PDC emulator role, run the following PowerShell command:
Get-ADDomain contoso.internal | FT PDCEmulator
Infrastructure master
The computer that hosts the infrastructure master role keeps track of changes that occur in other domains in the forest as they apply to objects in the local domain. You should avoid having the infrastructure master role co-located with a domain controller that hosts the global catalog server role unless all domain controllers in the domain are configured as global catalog servers. You can determine which computer in a domain hosts the infrastructure master role by running the following PowerShell command:
Get-ADDomain contoso.internal | FT InfrastructureMaster
RID master
The RID (relative identifier) master processes relative ID requests from domain controllers in a specific domain. Relative IDs and domain Security IDs are combined to create a unique Security ID (SID) for the object. There is a RID master in each domain in the forest. You can use the following PowerShell command to determine which computer hosts the RID Master role:
Get-ADDomain contoso.internal | FT RidMaster
Seizing FSMO roles
In some cases, a domain controller hosting a FSMO role fails and you need to seize the FSMO role to move it to another domain controller. For example, to move the RID Master, Infrastructure Master, and Domain Naming Master roles to a domain controller named MEL-DC2, run the following command:
Move-ADDirectoryServerOperationMasterRole -Identity MEL-DC2 -OperationMasterRole RIDMaster,InfrastructureMaster,DomainNamingMaster -Force
Accounts
Accounts represent the identities of security principals in an Active Directory environment. The most common type of account is a user account, which represents a person as he or she interacts with the Windows environment. IT Ops personnel also need to regularly deal with computer accounts, group accounts, and service accounts.
User accounts
User accounts almost always represent real people in an Active Directory environment, with the caveat that some user accounts are used for services rather than traditional users signing in to their desktop computers.
In many organizations, a user account is nothing more than a username, a password, and a collection of group memberships. User accounts can contain substantial additional information, including:
First name
Last name
Middle initial
Full name
Office information
Email address
Webpage
Job title
Department
Company
Manager
Phone numbers (main, home, mobile, fax, pager, IP phone)
Address
User profile location
Log on script
Home folder
Remote desktop service profile
Dial-in permissions
Published certificates
Remote Desktop Sessions settings
Remote Control settings
You should configure important accounts to be protected from deletion by enabling the Protect From Accidental Deletion option, as shown in Figure 4-6. Unless this option is removed, the account cannot be deleted. This setting doesn’t stop an account from being removed deliberately, but it does stop the account from being deleted accidentally.
Figure 4-6 User account properties
You learn about securing accounts with log on restrictions, password policies, and authentication silos in Chapter 19, “Hardening Windows Server and Active Directory.”
Computer accounts
Computer accounts represent the computer within Active Directory. You often move computer accounts to specific OUs and then apply group policies to those OUs as a way of configuring the computer. When you join a computer to the domain, the computer account is automatically placed in the default Computers container.
If a computer account becomes desynchronized from the domain of which it is a member and loses its trust relationship, you can repair the relationship by signing in with the local Administrator account and running the following PowerShell command:
Test-ComputerSecureChannel -Credential Domain<AdminAccount> -Repair
If you don’t know the local Administrator account password but suspect that cached domain administrator credentials might be present, disconnect the computer from the network, either by physically removing the Ethernet connection or disconnecting the virtual network adapter, sign in using those credentials, and then run the PowerShell command previously mentioned. The Local Administrator Password Solution, which ensures that you don’t forget the local Administrator account password, is covered in Chapter 19, “Hardening Windows Server and Active Directory.”
Group accounts
Active Directory supports three different types of group account scopes: domain local, global (the default), and universal. It also supports two group types: Security and Distribution. You use security groups to control access to resources, delegate permissions, and for email distribution. Distribution groups can only be used for email distribution. If your organization uses Exchange Server, you manage distribution groups through Exchange. Best practice is to place users within global groups, add those global groups to domain local groups, and assign permissions and rights directly to the domain local groups. By default, members of the Account Operators, Domain Admins, or Enterprise Admins groups can modify the membership of groups. You can also delegate the right to manage groups, which is covered in Chapter 19, “Hardening Windows Server and Active Directory.”
Universal
A universal group can hold accounts and groups from the same forest. Universal groups are stored in the global catalog. If you change the membership of a universal group, this change replicates to all global catalog servers in the forest. Universal groups are great in single forest environments where replication traffic isn’t an issue or where there are few changes to universal group membership. Universal groups can be nested within other universal groups, or they can be added to domain local groups.
Global
Global groups can contain user accounts from its home domain. Global groups can also contain other global groups from its home domain. Global groups can be members of universal groups and domain local groups.
Domain local
Domain local groups can have universal groups, global groups, and domain local groups as members. Domain local groups can host accounts from any domain in the forest and accounts from domains in trusted forests. Domain local groups can only be added to domain local groups within its own domain. A domain local group can only be assigned rights and permissions within its own domain. Domain local groups cannot be added to global or universal groups.
Default groups
The groups listed in Table 4-1 are included in a Windows Server 2019 domain by default.
Table 4-1 Important groups
Group |
Function |
Access Control Assistance Operators |
Members can query authorization attributes and permissions for resources on the computer. |
Account Operators |
Members can manage domain user and group accounts. |
Administrators |
This is the built-in administrators group. On a DC, this provides unlimited access to the computer and domain. |
Allowed RODC Password Replication Group |
Members can have their passwords replicated to RODCs. |
Backup Operators |
Members can override security restrictions to back up or restore files. |
Cert Publishers |
Members can publish certificates to AD DS. |
Certificate Services DCOM Access |
Members can connect to Certification Authorities. |
Cloneable Domain Controllers |
Domain controllers that can be cloned. |
Cryptographic Operators |
Can perform cryptographic operations. |
Denied RODC Password Replication Group |
Members cannot have their passwords replicated to RODCs. |
Distributed COM Users |
Can launch, activate, and use Distributed COM objects. |
DNSAdmins |
DNS administrators group. |
DNSUpdateProxy |
Group for DNS clients who are able to perform dynamic updates on behalf of services, such as DHCP servers. |
Domain Admins |
Members can administer the domain. Members of this group are automatically members of the local Administrators group on every computer in the domain. Default owner of all objects created in Active Directory. |
Domain Computers |
All computers that are members of the domain. |
Domain Controllers |
All domain controllers in the domain. |
Domain Guests |
Hosts the built-in domain guest account. |
Domain Users |
Hosts all user accounts in the domain. |
Enterprise Admins |
Only present in the root domain of a forest. Can make forest-wide changes, such as raising forest functional level or adding domains. |
Enterprise Key Admins |
Members can perform administrative tasks on key objects at the forest level. |
Enterprise Read-Only Domain Controllers |
Group for enterprise read-only domain controllers. |
Event Log Readers |
Can view the contents of event logs on the computer. |
Group Policy Creator Owners |
Members can create and modify GPOs. |
Hyper-V Administrators |
Can manage Hyper-V on the local machine. |
IIS_IUSRS |
Internet Information Services built-in group. |
Incoming Forest Trust Builders |
Members can create incoming, one-way trusts to the forest. |
Key Admins |
Members can perform administrative tasks on key objects at the domain level. |
Network Configuration Operators |
Members can configure networking features. |
Performance Log Users |
Members can schedule logging of performance counters and collect event traces. |
Performance Monitor Users |
Members can access performance counter data locally and remotely. |
Pre-Windows 2000 Compatible Access |
A group that exists for backward compatibility. |
Print Operators |
Members can manage printers deployed on domain controllers. |
Protected Users |
Members of this group have stricter security controls applied to their accounts. |
RAS and IAS Servers |
Members in this group are able to access the remote access settings of user accounts. |
RDS Endpoint Servers |
Servers in this group host VMs used with RemoteApp programs and personal virtual desktops. |
RDS Management Servers |
Servers in this group can perform administrative actions on other servers running the Remote Desktop Services role. |
RDS Remote Access Servers |
Servers in this group enable users of RemoteApp programs and personal virtual desktop to access resources. |
Read-Only Domain Controllers |
Read-only domain controllers in the domain. |
Remote Desktop Users |
Granted the right to sign on using Remote Desktop. |
Remote Management Users |
Members can access WMI resources over management protocols. |
Replicator |
Group supporting file replication at the domain level. |
Schema Admins |
Root domain group. Members are authorized to make changes to Active Directory Schema. |
Server Operators |
Members can administer domain member servers. |
Storage Replica Administrators |
Members can manage storage replica. |
Terminal Server License Servers |
Members can update Active Directory information about terminal services licensing. |
Users |
Built-in Users group. |
Windows Authorization Access Group |
Have access to computed tokenGroupGlobalAndUniversal attribute on User objects. |
Service accounts
Service accounts are functionally user accounts used by services to interact with the operating system and resources on the network. By assigning rights to the service account, you can limit what the service can or cannot do.
In Chapter 19, “Hardening Windows Server and Active Directory,” you’ll learn how to lock down service accounts. One of the key things to remember about a service account is that it should not have the right to log on locally to a computer but should have the log on as a service right. This is important because administrators in many organizations have bad habits where they grant service accounts unnecessary rights and even go as far as to give all service accounts the same non-expiring password. Sophisticated attackers know this and use this to compromise service accounts and use them to gain privileged access.
Local System
The Local System (NT AUTHORITYSYSTEM) account is a built-in account. It has privileges equivalent to a local administrator account on the local computer. It acts with the computer account’s credentials when interacting on the network. This is the most powerful service account, and generally you should be reluctant to assign this service account manually to a service given its extensive privileges.
Local Service
The Local Service (NT AUTHORITYLocalService) account has the same level of privilege as user accounts that are members of the local Users group on a computer. This account has fewer local privileges than the Local System account. Any services assigned to this account access network resources as a null session without credentials. Use this account when the service doesn’t require network access or can access network resources as an anonymous user and requires only minimal privileges on the computer it is being used on.
Network Service
The Network Service (NT AUTHORITYNetworkService) account is similar to the Local Service account in that it has privileges on the local computer equivalent to those assigned to a member of the local Users group. The primary difference is that this account interacts with the computer account’s credentials with resources on the network.
GMSA
A group managed service account (GMSA) is a service account that is managed by the domain. This means that rather than having to update the service account’s password manually, Active Directory updates the password in line with the domain password policy. Many organizations that use regular user accounts as service accounts tend to set a static password for these accounts, which is often simple rather than complex.
Group Managed Service Accounts require the forest functional level to be Windows Server 2012 or higher. Forests at the Windows Server 2008 level support a version of a GMSA called an MSA, but this is more limited than a GMSA, with each MSA only being able to be installed on a single machine.
Prior to using GMSAs, you’ll need to create a Key Distribution Services (KDS) root key. You can do this with the following command:
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
You manage GMSAs using Windows PowerShell. To create a GMSA, specify the name of the account, a DNS hostname associated with the account, and the name of the security principals that are allowed to use the account. For example, to create a GMSA named MEL-SQL-GMSA for the contoso.internal domain that can be used by servers in the MEL-SQL-Servers security group, enact the following command:
New-ADServiceAccount MEL-SQL-GMSA -DNSHostname MEL-SQL-GMSA.contso.internal -PrincipalsAllowedToRetrieveManagedPassword MEL-SQL-Servers
To install the account on a specific server, so that you can use it, run the Install-ADServiceAccount cmdlet. For example, to install the MEL-SQL-GMSA account on a server so that you can assign the account to services, enact the command:
Install-ADServiceAccount MEL-SQL-GMSA
Prior to running this command, you may need to install the RSAT ADDS Tools on the local server. You can do this by running the command:
Install-WindowsFeature RSAT-ADDS-Tools
When assigning the account to a service, you should clear the Password and Confirm Password textbox. You’ll need to append a $ to the account name when configuring it as shown in Figure 4-7. Windows Server 2019 recognizes that the account is a GMSA and manages the password settings.
Figure 4-7 GMSA configuration
Virtual account
A virtual account is the local equivalent of a group managed service account. Virtual accounts are supported by products such as SQL Server 2012 as an alternative to the default built-in accounts. You can create virtual service accounts by editing the property of a service and setting the account name to NT Service<ServiceName>.
Group policy
Group policy provides a central way of managing user and computer configuration. You can use Group Policy to configure everything from password and auditing policies to software deployment, desktop background settings, and mappings between file extensions and default applications.
GPO management
The Group Policy Management console is the primary method that the Group Policy is managed through in a standard Windows Server environment. This tool allows you to view Group Policy items from the forest level down. It provides information on which GPOs are linked at the domain, site, and OU level. You can see a list of all GPOs in a domain under the Group Policy Objects node. There is also a WMI Filters node that contains all WMI filters configured for the domain, a Starter GPOs node that contains all starter GPOs, a Group Policy Modeling node, and a Group Policy Results node. By right-clicking a GPO and selecting Edit, you can edit a GPO in the Group Policy Management Editor. You can output information about a GPO, including which settings are configured and where the GPO is linked, to a file in HTML format using the Get-GPOReport cmdlet.
Advanced Group Policy Management
Advanced Group Policy Management (AGPM) is available to Software Assurance customers through the Microsoft Desktop Optimization Pack. AGPM integrates with the existing Group Policy Management console, extending its functionality. AGPM has several benefits over the standard Group Policy Management console.
The biggest advantage of AGPM is that it enables you to apply a workflow to the management of GPOs, allowing you to use versioning and offline editing. This is an advantage over the standard Group Policy Management console where any changes made to an active Group Policy are automatically propagated to clients that are influenced by that policy. Having offline functionality for editing GPOs allows for GPOs that are already active to be more extensively tested during the revision process than might be the case in a traditional GPO deployment.
AGPM offers a more advanced model for editing GPOs because it allows administrators to track precisely which person in an organization made a specific change to a GPO. In a traditional Windows Server deployment, even though it is possible to control who has the permissions required to edit and apply a GPO, if multiple people have these permissions, it can be almost impossible to determine who made a specific change to an existing GPO. Being able to track the changes made to a GPO is very important in a high-security environment.
AGPM uses the following roles in its delegation architecture:
AGPM Administrator. Users assigned this role can perform all tasks in AGPM. This includes configuring domain-wide options as well as delegating permissions.
Approver. Users assigned this role can deploy GPOs into the domain. Approvers are also able to approve or reject requests from users assigned the Editor role. Users assigned this role are also able to create and delete GPOs but cannot edit GPOs unless assigned the Editor role.
Reviewer. Users assigned the Reviewer role can view the contents of GPOs and compare the contents of GPOs, but they do not have the ability to modify or deploy GPOs. The Reviewer role is designed to review and audit GPO management.
Editor. Users assigned this role can view and compare GPOs as Reviewers can. They are also able to check GPOs out of the archive, edit them offline, and then check those GPOs back into the archive. They are unable to deploy GPOs but can request GPO deployment.
Backup and restore
In any environment where you make a change, you need to have the option to roll back that change. Even if you have the AGPM, it is a good idea to regularly back up Group Policy Objects. While GPOs are backed up when you perform a system state backup, they can be troublesome to restore if you delete or modify them in an unintended way. Using a tool like AGPM can reduce the chance that you can’t roll back to a previous configuration, but if you don’t have AGPM, you should make a backup of a GPO prior to making substantial, or even insubstantial, policy modifications.
Backing up a GPO is straightforward. In the Group Policy Management console, right-click the policy and then click Back Up. On the Back Up Group Policy Object dialog box, enter the folder to which you are backing up the GPO and provide a description. You can back up all GPOs in your organization by right-clicking the Group Policy Objects node within the Group Policy Management console and clicking Back Up All.
You can manage the backups that you have taken of Group Policy Objects by right-clicking the Group Policy Objects node and then clicking Manage Backups. This opens the Manage Backups dialog box. Using this dialog box, you can:
Restore a backed-up GPO
Verify what settings are applied in a backup GPO
View where the GPO was linked and how it was filtered
View the delegation settings on the GPO
Delete a specific GPO backup
You can also restore an individual GPO by right-clicking the GPO and then clicking Restore From Backup. When you do this, you have the option of restoring from any backup you’ve taken of that GPO.
You can use the Import Settings Wizard to import settings from a backed-up GPO into an existing GPO. You can use this technique to quickly duplicate GPOs by backing one up, creating a new “blank” GPO, and then importing the settings into the new GPO. To run the Import Settings Wizard, right-click a GPO under the Group Policy Objects in the Group Policy Management console, and then click Import Settings. Importing settings into a GPO overwrites all current settings in the GPO, effectively replacing the current GPO with the backed-up GPO. You do get the option to back up the GPO that you are going to overwrite when running the wizard; even if you are completely sure of what you are doing, this is a good option to take.
Policy processing
Group policy is processed in the following order, with subsequent policies overriding previously applied policies where conflicts exist:
Local
Site
Domain
Organizational unit
For example, if one policy configures a setting at the AD site–level and another policy configures the same setting at the organizational unit–level, the policy that configures the setting at the organization unit–level is applied.
The exception to this is when you configure one of the following settings:
Block Inheritance. The Block Inheritance option allows you to block upstream policies from applying. You can configure this option at the Domain or OU level. It blocks all upstream settings except those configured through a policy that has the No Override setting.
No Override. You use the No Override setting to stop the Block setting. Use this on policies that you need to have enforced.
Resultant Set of Policy tool
The Resultant Set of Policy tool allows you to generate a model of Group Policy application, allowing you to figure out which policies apply to particular objects within the domain. Resultant Set of Policy allows you to figure out why Group Policy application isn’t behaving in the way that you expect and allows you to resolve Group Policy conflicts.
There are two ways you can calculate Resultant Set of Policy. The first is to use Group Policy Modeling. The second is to use Group Policy Results. The difference between these is as follows:
Group Policy Modeling allows you to view the impact of altering site membership, security group membership, filtering, slow links, loopback processing, and the movement of accounts to new OUs on the application of policy.
Group Policy Results allows you to troubleshoot the application of policy by telling you which settings apply to a specific user or computer account.
By default, members of the Domain Admins and Enterprise Admins groups can generate Group Policy Modeling or Group Policy Results information. You can delegate permissions so users can perform these tasks at the OU or domain level.
Filtering
GPO filtering allows you to determine whether a linked GPO applies based on group membership or the results of a WMI query. For example, you could write a WMI query that performs a check so that a GPO applies only if the computer has more than 4 GB of RAM. If the computer has more than 4 GB of RAM, the policy applies normally. If the computer has less than 4 GB of RAM, the GPO does not apply.
Group Policy preferences
Group Policy preferences work around the idea of eliminating (or at least substantially reducing) the need for traditional startup and login scripts. Login scripts have a way of becoming convoluted over time. Group Policy preferences allow simplification of common login and startup script tasks such as drive mappings and setting environment variables.
By reducing or eliminating some of the complexity of login scripts, you can use Group Policy preferences to reduce configuration errors. You can use Group Policy preferences to configure the following:
Applications
Drive mappings
Environment variables
File updates
Folders
Ini files
Registry settings
Shortcuts
Data sources
Devices
Folder options
Internet settings
Local users and groups
Network options
Network shares
Power options
Printer settings
Regional options
Scheduled tasks
Start Menu settings
Some of these items can also be configured using a traditional Group Policy. If an item is configured in the same GPO using both policy and preferences, the traditional setting takes precedence. The difference between a Group Policy preference and a normal Group Policy setting is that users can change a Group Policy preference if they have the appropriate permissions. For example, users can un-map a mapped network drive. The drive would remain unmapped until the user logged in again, at which point, it would be remapped. Generally, if you want to enforce a setting, use a standard Group Policy. If you want to apply the setting and allow users to change it, use a Group Policy preference. The closest you can come to enforcing a Group Policy preference is to disable the Apply Once And Do Not Reapply setting in the policy item’s configuration. This way, the preference is applied each time Group Policy refreshes.
You can target Group Policy preferences so that different preferences can apply to the same item types within a single GPO. You can use the following items to restrict how a Group Policy preference applies:
The computer has a battery.
The computer has a specific name.
The computer has a specific CPU speed.
Apply by or after a specific date.
The computer has a certain amount of disk space.
The computer is a member of a domain.
The computer has a particular environment variable set.
A certain file is present on the computer.
The computer is within a particular IP address range.
The computer uses specific language settings.
The computer meets the requirements of an LDAP query.
The computer has a MAC address within a specific range.
The computer meets the requirements of a WMI query.
The computer uses a specific type of network connection.
The computer is running a specific operating system.
The computer is a member of a specific OU.
The computer has PCMCIA present.
The computer is portable.
The computer uses a specific processing mode.
The computer has a certain amount of RAM.
The computer has a certain registry entry.
The user or computer is a member of a specific security group.
The computer is in a specific Active Directory site.
The computer has a Remote Desktop Setting.
A specific time range is present.
The user has a specific name.
Administrative templates
Group Policy Administrative Templates allow you to extend Group Policy beyond the settings available in GPOs. Common software packages, such as Microsoft Office, often include Administrative Templates that you can import to manage software-specific settings. In early versions of Windows Server, Administrative Templates were available as files in ADM format. Since the release of Windows Server 2008, Administrative Templates are available in a standards-based XML file format called ADMX.
To be able to use an Administrative Template, you can import it directly into a GPO using the Add/Remove Templates option when you right-click the Administrative Templates node. A second option is to copy the Administrative Template files to the Central Store, located in the c:WindowsSysvolsysvol<domainname>PoliciesPolicyDefinitions folder on any domain controller. You might need to create this folder if it does not already exist. After the folder is present, the template is then replicated to all domain controllers, and you can access the newly imported Administrative Templates through the Administrative Templates node of a GPO.
Restoring deleted items
Sometimes an Active Directory account, such as a user account or even an entire OU, is accidentally—or on occasion, maliciously—deleted. Rather than go through the process of re-creating the deleted item or items, it’s possible to restore the items. Deleted items are retained within the AD DS database for a period of time specified as the tombstone lifetime. You can recover a deleted item without having to restore the item from a backup of Active Directory as long as the item was deleted within the Tombstone Lifetime window.
The default tombstone lifetime for an Active Directory environment at the Windows Server 2008 forest functional level or higher is 180 days. You can check the value of the tombstone lifetime by issuing the following command from an elevated command prompt, (substituting dc=Contoso,dc=Internal for the suffix of your organization’s forest root domain):
Dsquery * “cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=Contoso, dc=Internal” -scope base -attr tombstonelifetime
For most organizations the 180-day default is fine, but some administrators might want to increase or decrease this value to give them a greater or lesser window for easily restoring deleted items. You can change the default tombstone lifetime by performing the following steps:
From an elevated command prompt or PowerShell session, type ADSIEdit.msc.
From the Action menu, click Connect To. In the Connection Settings dialog box, click Configuration, as shown in Figure 4-8, and then click OK.
Figure 4-8 Connection Settings
Right-click the CN=Services, CN=Windows NT, CN=Directory Service node and click Properties.
In the list of attributes, select tombstoneLifetime, as shown in Figure 4-9, and click Edit.
Figure 4-9 Tombstone lifetime
On the Integer Attribute Editor dialog box, enter the new value for the tombstone lifetime and click OK twice; close the ADSI Edit console.
Active Directory Recycle Bin
Active Directory Recycle Bin allows you to restore items that have been deleted from Active Directory but are still present within the database because the tombstone lifetime has not been exceeded. Active Directory Recycle Bin requires that the domain functional level be set to Windows Server 2008 R2 or higher.
Once activated, you can’t deactivate the Active Directory Recycle Bin. There isn’t any great reason to want to deactivate AD Recycle Bin once it is activated. You don’t have to use it to restore deleted items should you still prefer to go through the authoritative restore process.
To activate the Active Directory Recycle Bin, perform the following steps:
Open the Active Directory Administrative Center and select the domain that you want to enable.
In the Tasks pane, click Enable Recycle Bin, as shown in Figure 4-10.
Figure 4-10 Enable Recycle Bin
After you have enabled the AD Recycle Bin, you can restore an object from the newly available Deleted Objects container. This is, of course, assuming that the object was deleted after the Recycle Bin was enabled and assuming that the tombstone lifetime value has not been exceeded. To recover the object, select the object in the Deleted Items container and then click Restore or Restore To. Figure 4-11 shows a deleted item being selected, which can then be restored to its original location. The Restore To option allows you to restore the object to another available location, such as another OU.
Figure 4-11 Deleted Objects container
Authoritative restore
An authoritative restore is performed when you want the items you are recovering to overwrite items that are in the current Active Directory database. If you don’t perform an authoritative restore, Active Directory assumes that the restored data is simply out of date and overwrites it when it is synchronized from another domain controller. If you perform a normal Restore on an item that was backed up last Tuesday when it was deleted the following Thursday, the item is deleted the next time the Active Directory database is synchronized. You do not need to perform an authoritative restore if you only have one domain controller in your organization because there is no other domain controller that can overwrite the changes.
Authoritative restore is useful in the following scenarios:
You haven’t enabled Active Directory Recycle Bin.
You have enabled Active Directory Recycle Bin, but the object you want to restore was deleted before you enabled Active Directory Recycle Bin.
You need to restore items that are older than the tombstone lifetime of the AD DS database.
To perform an authoritative restore, you need to reboot a DC into Directory Services Restore Mode. If you want to restore an item that is older than the tombstone lifetime of the AD DS database, you also need to restore the AD DS database. You can do this by restoring the system state data on the server. You’ll likely need to take the DC temporarily off the network to perform this operation simply because if you restore a computer with old system state data and the DC synchronizes, all the data that you wish to recover will be deleted when the domain controller synchronizes.
You can configure a server to boot into Directory Services Restore Mode from the System Configuration utility. To do this, select the Active Directory Repair option on the Boot tab as shown in Figure 4-12. After you’ve finished with Directory Services Restore Mode, use this same utility to restore normal boot functionality.
Figure 4-12 System Configuration
To enter Directory Services Restore Mode, you need to enter the Directory Services Restore Mode password.
To perform an authoritative restore, perform the following general steps:
Choose a computer that functions as a global catalog server. This DC functions as your restore server.
Locate the most recent system state backup that contains the objects that you want to restore.
Restart the restore server in DSRM mode. Enter the DSRM password.
Restore the system state data.
Use the following command to restore items (where Mercury is the object name, Planets is the OU that it is contained in, and contoso.com is the host domain):
Ntdsutil “authoritative restore” “restore object cn=Mercury,ou=Planets,dc=contoso,dc=com” q q
If an entire OU is deleted, you can use the Restore Subtree option. For example, if you deleted the Planets OU and all the accounts that it held in the contoso.com domain, you could use the following command to restore it and all the items it contained:
Ntdsutil “authoritative restore” “restore subtree OU=Planets, DC=contoso,DC=com” q q
Active Directory snapshots
You can use the Active Directory database mounting tool, dsamain.exe, to mount the contents of the AD DS database as it exists in snapshots or in backups so that you can interact with it using the Active Directory Users and Computers console. This provides you with a quick way of checking the state of a snapshot or backup without actually having to restore it to a production or development environment. For example, you might do this if you want to check what the AD DS database looked like at a specific point in time to determine the state of particular accounts or organizational units.
If you restored the AD DS database file ntds.dit to the location c: estore, you could mount this file using the dsamain.exe utility on port 51389 by entering the following command:
Dsamain.exe /dbpath C: estore tds.dit /ldapport 51389
You can then use Active Directory Users And Computers to connect to the specified port—in this case, port 51389—to view the mounted version of the AD DS database.
You can also create snapshots of the AD DS database that you can interact with without having to make a backup. A snapshot is a copy of the AD DS database as it exists at a specific point in time. You create a snapshot of the AD DS database by running the following command from an elevated command prompt on a domain controller:
Ntdsutil “Activate Instance NTDS” snapshot create quit quit
You can list all current snapshots of the AD DS database on a domain controller by running the following command:
Ntdsutil snapshot “list all” quit quit
Each snapshot has an odd number associated with it next to the date the snapshot was taken. To select and mount a snapshot, use the command:
Ntdsutil snapshot “list all” “mount 1” quit quit
This mounts snapshot 1. Make a note of the path on which the snapshot is mounted. You can then use the dsadmin.exe command to mount the snapshot so that it is accessible as an LDAP server. For example, to make the snapshot at path C:$SNAP_201606100306_VOLUMEC$ accessible on port 51389, use the command:
Dsamain.exe /dbpath C:$SNAP_201606100306_VOLUMEC$WINDOWSNTDS tds.dit /ldapport 51389
You can then use Active Directory Users And Computers to connect to the specified port to view the mounted snapshot. Only members of the Domain Admins and Enterprise Admins groups can view snapshots. While you can’t directly copy objects from a snapshot to the production version of the AD DS database, you can use utilities such as CSVDE and LDIFDE to export information from a snapshot and then later import it into the production AD DS database.
Managing AD DS with PowerShell
Many Active Directory administrative tasks are repetitive. If you’re likely to perform a task more than once, it’s better to script it in PowerShell than work your way through the appropriate wizard multiple times.
There are three PowerShell modules related to Active Directory. The Active Directory PowerShell module (Table 4-2) is the one you’re likely to use on a regular basis when managing Active Directory. The GroupPolicy module (Table 4-3) allows you to manage Group Policy from PowerShell. You use the ADDSDeployment (Table 4-4) module when performing deployment tasks.
Table 4-2 Active Directory module cmdlets
Noun |
Verbs |
Function |
ADAccount |
Unlock, Search, Enable, Disable |
Allows you to find, unlock, enable, or disable a user, computer, or service account. |
ADAccountAuthentication PolicySilo |
Set |
Allows you to configure the authentication policy or authentication policy silo of an account. |
ADAccountAuthorization Group |
Get |
Gets the security groups for a specified user, computer, or service account based on its token. Uses the global catalog to determine this information. |
ADAccountControl |
Set |
Modifies the user account control values of an Active Directory user or computer account. |
ADAccountExpiration |
Set, Clear |
Configure account expiration. |
ADAccountPassword |
Set |
Configure the password of a user, computer, or service account. |
ADAccountResultant PasswordReplicationPolicy |
Get |
Gets the password replication policy for a user, computer, or service account on a specific RODC. |
ADAuthenticationPolicy |
Set, Remove, New, Get |
Manipulate the properties of the AD DS authentication policy. |
ADAuthenticationPolicy Expression |
Show |
Displays Edit Access Control Conditions windows update or SSDL security descriptors. |
ADAuthenticationPolicySilo |
New, Remove, Get, Set |
Manipulate Active Directory Domain Services authentication policy silos. |
ADAuthenticationPolicySiloAccess |
Revoke, Grant |
Manage membership of authentication policy silos. |
ADCentralAccessPolicy |
Remove, Get, Set, New |
Manage central access rules and policies. |
ADCentralAccessPolicyMember |
Remove, Add |
Add and remove rules from a central access policy. |
ADCentralAccessRule |
New, Set, Remove, Get |
Manage central access rules. |
ADClaimTransformLink |
Set, Clear, Remove |
Manage claims transforms from being applied to one or more cross-forest trust relationships. |
ADClaimTransformPolicy |
New, Set, Get |
Manage claim transformation policy objects from Active Directory. |
ADClaimType |
New, Get, Remove, Set |
Manage Active Directory claim types. |
ADComputer |
Remove, New, Set, Get |
Manage Active Directory computer accounts. |
ADComputerServiceAccount |
Remove, Add, Get |
Add service accounts from Active Directory to a local computer. |
ADDCCloneConfigFile |
New |
Generates a clone configuration file for a domain controller. |
ADDCCloningExcludedApplicationList |
Get |
Manage which Active Directory applications are excluded when cloning the configuration of a domain controller. |
ADDefaultDomainPasswordPolicy |
Set, Get |
Manage the default password policy for a domain. |
ADDirectoryServer |
Move |
Use this cmdlet to move a DC to another AD site. |
ADDirectoryServerOperationMasterRole |
Move |
Move an operations master role to another computer. |
ADDomain |
Set, Get |
View and manage the properties of a domain. |
ADDomainController |
Get |
View the properties of a domain controller. |
ADDomainControllerPasswordReplicationPolicy |
Remove, Get, Add |
Manage which accounts can be replicated to an RODC. |
ADDomainMode |
Set |
Set the domain functional level. |
ADFineGrainedPasswordPolicy |
Remove, Get, Set, New |
Manage AD fine grained password policy. |
ADFineGrainedPasswordPolicySubject |
Get, Remove, Add |
Manage the application of fine-grained password policies. |
ADForest |
Set, Get |
Manage forest properties. |
ADForestMode |
Set |
Configure forest functional level. |
ADGroup |
Get, Set, Remove, New |
Manage AD groups. |
ADGroupMember |
Get, Remove, Add |
Manage AD group membership. |
ADObject |
Get, Restore, Rename, Set, Move, Remove, Sync, New |
Manage AD objects. |
ADOptionalFeature |
Disable, Get, Enable |
Configure AD optional features. |
ADOrganizationalUnit |
Set, Get, New, Remove |
Manage AD OUs. |
ADPrincipalGroupMembership |
Remove, Add, Get |
Manage group membership on the basis of user account. |
ADReplicationAttributeMetadata |
Get |
View replication metadata for AD object attributes. |
ADReplicationConnection |
Get, Set |
Manage the properties of an AD replication connection. |
ADReplicationFailure |
Get |
View information about AD replication failure. |
ADReplicationPartnerMetadata |
Get |
View information about AD replication partners. |
ADReplicationQueueOperation |
Get |
View all operations in the AD replication queue. |
ADReplicationSite |
Set, Get, Remove, New |
Manage AD replication sites. |
ADReplicationSiteLink |
Set, New, Get, Remove |
Manage AD replication site links. |
ADReplicationSiteLinkBridge |
Get, Remove, New, Set |
Manage AD replication site link bridges. |
ADReplicationSubnet |
New, Get, Set, Remove |
Manage AD replication subnets. |
ADReplicationUpToDatenessVectorTable |
Get |
Displays Update Sequence Numbers (USNs) for domain controllers. |
ADResourceProperty |
Set, New, Remove, Get |
Manage Active Directory resource properties. |
ADResourcePropertyList |
Remove, Set, New, Get |
Manage Active Directory resource property list. |
ADResourcePropertyListMember |
Remove, Add |
Add and remove resource properties from an Active Directory resource property list. |
ADResourcePropertyValueType |
Get |
View a resource property value type. |
ADRootDSE |
Get |
View the root of a Directory Server information tree. |
ADServiceAccount |
Get, Test, Set, Install, New, Remove, Uninstall |
Manage AD Managed Service Account. |
ADServiceAccountPassword |
Reset |
Reset AD Managed Service Account password. |
ADTrust |
Get |
View the properties of an AD Trust |
ADUser |
New, Set, Get, Remove |
Manage an Active Directory user. |
ADUserResultantPasswordPolicy |
Get |
Use this cmdlet to determine the resultant password policy for an account that has multiple fine-grained password policies applied to it. |
Table 4-3 Group Policy module cmdlets
Noun |
Verbs |
Function |
GPInheritance |
Get, Set |
View and manage which GPOs are applied and whether inheritance is blocked. |
GPLink |
Remove, New, Set |
Manage whether a GPO is linked. |
GPO |
Restore, Import, New, Remove, Rename, Backup, Get, Copy |
Manage GPOs, including backup restore and copy. |
GPOReport |
Get |
Generate a report on a GPO. |
GPPermission |
Set, Get |
Manage permissions on policies. |
GPPrefRegistryValue |
Remove, Set, Get, |
Manage registry-based policy preference settings. Microsoft maintains spreadsheets that map Group Policy settings to registry settings. To use this cmdlet to set registry settings, you need to consult the spreadsheet. |
GPRegistryValue |
Remove, Get, Set, |
Manage registry-based policy settings. |
GPResultantSetOfPolicy |
Get |
View the resultant set of policy information. |
GPStarterGPO |
New, Get |
Manage starter GPO. |
GPUpdate |
Invoke |
Triggers a Group Policy update. |
Table 4-4 AD Deployment module cmdlets
Noun |
Verbs |
Function |
ADDSDomain |
Install |
Installs a new Active Directory Domain Services domain. |
ADDSDomainController |
Install, Uninstall |
Use to add or remove a domain controller. |
ADDSDomainControllerInstallation |
Test |
Runs a prerequisite check prior to installing a domain controller. |
ADDSDomainControllerUninstallation |
Test |
Runs a prerequisite check prior to removing a domain controller. |
ADDSDomainInstallation |
Test |
Checks the prerequisites for a new Active Directory Domain services domain. |
ADDSForest |
Install |
Allows you to install a new Active Directory forest configuration. |
ADDSForestInstallation |
Test |
Allows you to perform a prerequisite check prior to performing an Active Directory forest installation. |
ADDSReadOnlyDomainControllerAccount |
Add |
Use this cmdlet to create a RODC account in the AD DS database. |
ADDSReadOnlyDomainControllerAccountCreation |
Test |
Allows you to check that the necessary prerequisites are in place before you create an RODC account. |
Active Directory module
As already mentioned, the Active Directory PowerShell module (see Table 4-2) is the one you’re likely to use on a regular basis when managing Active Directory.
Group Policy module
As mentioned earlier, the GroupPolicy module (see Table 4-3) allows you to manage Group Policy from PowerShell.
ADDSDeployment module
As previously mentioned, you use the ADDSDeployment (see Table 4-4) module when performing deployment tasks.