Back in the year 2000, when Active Directory was introduced to the larger public, we lived in a different world. The internet was only just starting to deliver value to businesses. That's why, in Windows 2000 Server, Active Directory was largely disconnected from the internet. Windows 2000 Server's default Domain Name System (DNS) settings even came with a root domain; so, if you wanted to connect to the internet, you had to delete the
. DNS zone manually.
Fast forward to today, and the internet and cloud services seem omnipresent. The default
. DNS zone has disappeared from Windows Server, but the concepts of trees and forests in Active Directory has persisted, and they still allow for some confusion among Active Directory admins.
To explain domains, trees, and forests in Active Directory, we need to acknowledge Active Directory's past. To create anything in Active Directory, you'll need to create a domain...
Choosing between a new domain or forest
In organizations, sometimes, an expansion or business change requires changes in Active Directory too. In Active Directory terms, the change might require creating a new Active Directory domain or a new Active Directory forest. In this recipe, we'll look at the reasoning between these two choices, taking the entire life cycle of Active Directory into consideration.
Why would you have a new domain?
The boundary of domains in Active Directory relates to the following:
- DNS name: An additional domain tree offers the possibility to add a DNS domain name to the organization to, for instance, correctly label a new business venture. An alternative might be to add an additional UPN suffix.
- Domain DNS zones replication: Throughout an Active Directory forest, all domain controllers...
Listing the domains in your forest
In an Active Directory environment with multiple domains and forests, it can be hard to distinguish the trees from the forest. As authentication is often per forest, an easy way to list the domains per forest is welcome.
Alas, the only reliable way to list the domains in a forest is to use PowerShell.
For this recipe, we'll need one of the following:
- A domain controller running Windows Server 2012 with Desktop Experience (or a newer version of Windows Server)
- A domain-joined member server running Windows Server 2012 with Desktop Experience (or a newer version of Windows Server) with the Active Directory module for Windows PowerShell installed
- A domain-joined device running Windows 8.1 (or a newer version of Windows) with the Active Directory module for Windows PowerShell installed
On domain controllers running Windows Server 2012 with Desktop Experience (and on newer versions of Windows Server), the...
Using adprep.exe to prepare for new Active Directory functionality
The Active Directory schema defines the way that objects can be created, and what attributes are required or are optional for these objects. With previous versions of Windows Server, the base schema has been improved and extended.
Many features require certain schema versions for Active Directory. For instance, when you want to deploy a Windows Server 2016-based Active Directory Federation Services (AD FS) farm, you'll need the Windows Server 2016 schema or a higher version of the schema.
Since Windows Server 2012, Microsoft updates the Active Directory schema automatically when you promote the first Windows Server 2012-based member server to an Active Directory domain controller.
However, consider what will happen if you want to do any of the following:
- Update the Active Directory schema only, because your organization doesn't want domain controllers running the latest version.
Raising the domain functional level to Windows Server 2016
When implementing new Active Directory domain controllers and removing domain controllers running previous versions of Windows Server, many admins forget to raise the Active Directory domain functional level (DFL) to the earliest Windows Server version still running as domain controllers. After upgrading all domain controllers from Windows Server 2008 R2 to Windows Server 2012 R2, for instance, they would not raise the DFL to Windows Server 2012 R2 but keep it at the Windows Server 2008 R2 level.
It's a shame, really, because many new Active Directory features and optional Active Directory features are only available when the functional level is raised. Furthermore, the DFL dictates the lowest version of Windows Server that admins can use to promote new domain controllers. In addition, since Windows Server 2008 R2, the DFL can also be reverted, as long as no new optional features have been enabled and the Active Directory...
Raising the forest functional level to Windows Server 2016
Just like the Active Directory DFL, the FFL also determines the availability of new Active Directory functionality. Where the DFL dictates the minimum version of Windows Server to run as domain controllers, the FFL dictates the minimum version of the DFL in the Active Directory forest.
The new functionality that is unlocked by raising the FFL includes the following:
- Privileged Access Management (PAM), which requires the Windows Server 2016 FFL
- Active Directory Recycle Bin, which requires the Windows Server 2008 R2 FFL
- Linked-value replication, which requires the Windows Server 2003 FFL
Microsoft recommends raising the FFL from the Active Directory domain controller that holds the Domain Naming Master FSMO role.
To locate this domain controller, run the following command on any domain-joined device, member server, or domain controller:
netdom.exe query fsmo
Creating the right trust
In an Active Directory environment with multiple domains, you're bound to have trusts. Trusts allow people to access resources in a domain or forest other than the domain or forest where their user accounts reside.
When Active Directory domains are added to an existing Active Directory domain, two-way transitive trusts are automatically created. However, in other situations, trusts have to be created manually. With many different types of trusts, two trust directions, and a choice in transitivity, which trust is the right trust for which situation?
Let's look at the six types of trust first:
- Parent-child trust: The parent-child trust is a trust type that is automatically created when you add a domain to a tree root. For example, a parent-child trust is automatically created between
sub.adatum.com. You cannot manually create a parent-child trust.
- Tree-root trust: The tree-root trust is a trust type that is also automatically...
Removing a trust
Preferably, you should sign in to the domain controller that is running the Domain Naming Master FSMO role or connect the Active Directory Domains and Trusts console to this specific domain controller.
To find this domain controller, right-click the Active Directory Domains and Trusts node and select Operations Master... from the menu. Alternatively, run the following command from any domain-joined device, member server, or domain controller:
netdom.exe query fsmo
Otherwise, you can use the following line of Windows PowerShell on a domain-joined system that has the Active Directory module for Windows PowerShell installed:
Get-ADForest | Format-List DomainNamingMaster
To remove a shortcut trust, use an account that is a member of the Domain Admins group in the Active Directory domain. To remove other trusts, use an account that is a member of the Enterprise Admins group.
Verifying and resetting a trust
After you create a trust, you might regularly want to check whether the trust is working properly. You might be notified by people who report that they can no longer access resources in other domains or forests, or it might be an activity that you perform on a regular basis.
When a trust is broken, there is a way to reset it. Also, when you want to reset the shared secret on both sides of the trust, a reset of the trust is needed.
It is recommended that you sign in to the domain controller that is running the Domain Naming Master FSMO role or connect the Active Directory Domains and Trusts console to this specific domain controller, by right-clicking in the console on the Active Directory Domains and Trusts node and selecting Change Active Directory Domain Controller… from the context menu.
To find this domain controller, right-click the Active Directory Domains and Trusts node and select Operations Master... from the...
Securing a trust
- Enable SID filtering
- Enable quarantine
- Enable selective authentication
SID filtering is enabled on all trust relationships, by default. SID filtering operates on the same surface as trust transitivity. When enabled, SID filtering filters the user accounts over the trust to user accounts from the domain tree that is explicitly trusted, only. In a way, it allows more granular transitivity.
Quarantine is enabled on all trust relationships, by default. Quarantine for a trust allows granular access, too. Where SID filtering allows for limiting access to a trusted domain tree, quarantine limits access to a trusted domain.
Extending the schema
Some applications require additional object types and/or attributes to store their information in Active Directory. Some good examples of these types of applications are Microsoft Exchange Server and Microsoft's free Local Administration Password Solution (LAPS).
These applications and their schema changes are thoroughly tested, but there's also the option to create your own custom Active Directory schema extension. For instance, you can introduce your own employee or customer ID type attribute to the user object class.
The domain controller holding the Schema Master FSMO role is authoritative for the Active Directory schema throughout an Active Directory forest. Microsoft recommends that you perform the following actions on the domain controller that is holding the Schema Master FSMO role.
To find this domain controller, run the following command on any domain-joined device, member server, or domain controller:
Enabling the Active Directory Recycle Bin
There were features available to administrators before the advent of the Active Directory Recycle Bin, such as Directory Services Restore Mode (DSRM) and object reanimation. In contrast to booting into DSRM, the Active Directory Recycle Bin saves admins time. In contrast to reanimating objects, the Active Directory Recycle Bin prevents the typical loss of attributes and group memberships.
There are also numerous third-party solutions that are available to restore objects and their attributes. They typically expand on the functionality that is offered by the Active Directory Recycle Bin, by offering granular attribute restore and group policy versioning. These are two areas where the Active Directory Recycle Bin doesn't offer a solution.
Managing UPN suffixes
In Active Directory, users and services can sign in using their pre-Windows 2000 logon name (the value of the
sAMAccountName attribute) or their Kerberos user principal name (the value of the
userPrincipalName attribute). As Kerberos relies heavily on DNS, the user principal name features a
userPrincipalName suffix, in the form of a DNS domain name.
userPrincipalName suffixes can be added to the list of available UPN suffixes for each Active Directory forest.
By default, this list already contains the DNS domain names of the Active Directory domains in the forest.
UPN suffixes in on-premises Active Directory environments do not need to be publicly routable. Only if you intend to use them with federation and/or hybrid identity do they then need to be. In many organizations, a cloud journey begins with changing the UPN suffix on all the user objects that need to be cloud-enabled to a publicly routable UPN suffix. Some organizations have adopted