One of the hard nuts to crack in Active Directory is meeting the requirements for the infrastructure features your organization’s business needs to operate reliably, securely and smooth.
About Active Directory requirements
Throughout Microsoft’s recent history, features have been introduced in all sorts of products that have certain Active Directory requirements.
The perfect example is Kerberos Armoring (FAST). Besides a Group Policy setting, it requires a sufficient number of Domain Controllers running Windows Server 2012, or Domain Controllers running newer versions of Windows Server.
A recent example that comes to mind is Windows Hello for Business in recent versions of Windows 10. In most deployment types, you need Windows Server 2016-based Domain Controllers, or Domain Controllers running newer versions of Windows Server.
Here’s a table with requirements for Windows Server 2003 through Windows Server 2008 R2. Here’s the table for Windows Server 2012.
Pile-on effects
If these requirements are not met, the feature cannot be used. If requirements are met inadequately, the feature may behave surprisingly.
Throughout Active Directory’s history, there have been features that were unlocked by adding the first Domain Controller with the latest Windows Server Operating System (OS). However, what wasn’t always clear is that meeting the requirement with the bare minimum (one Domain Controller running the latest and greatest) might lead to a pile-on effect. This could lead to all Read-only Domain Controllers communicating to only one Domain Controller, all clients communication to the latest Domain Controller when Kerberos Armoring was enabled…
Finding out Domain Controllers’ capabilities
Before you turn on any feature that has Active Directory requirements, my recommendation is to check your Domain Controllers’ capabilities.
Your knee-jerk reaction as an AD admin might be to open the Active Directory users and computers MMC Snap-in (dsa.msc), but this usually doesn’t do the trick:
- It’s tedious to double-click each Domain Controller to look up its Operating System, then close the Properties window to go to the next Domain Controller.
- The MMC snap-in doesn’t provide an overview on what a device thinks about your Active Directory sites lay-out. This requires a look in the Active Directory sites and services MMC snap-in (dssite.msc).
- This investigation doesn’t account for network connections being blocked between certain devices and networks to other networks with Domain Controllers, doesn’t account for DNS issues, replication issues and deviations in netLogon.dns files.
- All of the above means cannot be utilized by device administrators. They may not have sufficient permissions and they lack the tools on the device they’re enabling the new feature on.
What we need is a simple command line admins can run on devices to find out what capabilities your Domain Controllers may offer to the device, from the device itself. his is fully possible using nltest.exe.
What you need is a Command Prompt window (cmd.exe) to run the nltest command on. The command prompt doesn’t even have to be elevated…
But, you must also know how to specify to filter for the Windows Server version running on Domain Controllers. For this, you can use the following table:
| ds_6 | Windows Server 2008 |
| ds_7 | Windows Server 2008 R2 |
| ds_8 | Windows Server 2012 |
| ds_9 | Windows Server 2012 R2 |
| ds_10 | Windows Server 2016 |
Now, by simply specifying the below command, substituting the domain name for your domain, you can find out if your Domain Controllers run Windows Server 2016, or up:
nltest.exe /dsgetdc:domain.tld /ds_10 /force
You can do all sorts of other reconnaissance with the nltest command. For instance, to find out what features the Primary Domain Controller (PDC) is offering, because you need ds_8 for Domain Controller cloning, simply type:
nltest.exe /dsgetdc:domain.tld /pdc
Concluding
Finding out if the environment meets the requirements for certain infrastructure features can be time-consuming in some organizations. If you have a domain-joined device with access to the Command Prompt, you can easily find out for yourself, without setting off any alarm bells.
Also, you don't need PowerShell for this; most cmdlets require installation of the Windows PowerShell module for Active Directory and, thus, require administrator privileges.
Good ol' nltest to the rescue.
Login