Should you upgrade your existing AD forest to Windows Server 2016 Active Directory (aka AD 2016), or should you leave it where it is? Despite the focus and activity around adopting cloud services today, the fact remains that Active Directory continues to underpin it all. In addition to longstanding dominance as the on-premises identity source, the vast majority of midsize to enterprise organizations around the world use a hybrid identity model, sourced by AD, for their cloud services. As a result, it’s an important question.
A big reason IT departments have not upgraded their AD environment to Windows Server 2016 from midstream support OSes such as Windows Server 2012 or R2 is because they don’t think there’s a clear and compelling “hero feature” such as the AD Recycle Bin to justify the upgrade. If you’re one of them, you should look closely at Windows Server 2016.
Let’s use scenarios – business and technical examples of environments and needs you might also have – to look at the major Active Directory and OS security improvements of Windows Server since 2008 R2. Do any of these scenarios match your organization?
If you virtualize your DCs
Virtualization has been widespread for many years now, but virtualizing DCs has often lagged behind other workloads for a couple of good reasons: integrity and security. If you’ve virtualized some or all of your DCs, there are major integrity and security improvements in both the base Windows Server 2016 OS and AD that you should take advantage of immediately.
One issue with virtualizing an application such as AD that keeps track of its state is that, if restored from a VM snapshot taken earlier, the restored DC doesn’t realize it’s out of sync with its fellow DCs. This condition can cause serious divergence errors in your domain or forest. Windows Server 2012 introduced a feature in both AD and Hyper-V, the VM-GenID, that essentially tells AD it’s been restored from a snapshot and to take appropriate measures to protect itself.
Having been alerted of the snapshot restore, the DC discards its RID pool and resets the invocation ID (the AD database version number) to prevent divergence problems. (It’s still not a good idea to regularly restore DCs from snapshots, however.) VMware, Xen, and other virtualization providers have also adopted this method, so your DCs don’t necessarily need to be on Hyper-V.
If your DCs are up to Windows Server 2012 or 2012 R2 and you’ve still not virtualized your DCs due to security concerns related to its host servers, Windows Server 2016 has an important feature for you. The newest OS addresses a fundamental security problem with any VM: anyone with admin rights to the host machine can simply copy the VM’s files off the host and hack them at their leisure. A DC is a prime target for this attack because of course they contain the user ids and passwords of everyone in the company. The Shielded VMs feature protects virtual machines from compromised or malicious administrators, such as storage admins, backup admins, etc. by encrypting the disk and state of virtual machines so only VM or tenant admins can access it.
Supporting your clients in a hybrid world
An organization doesn’t exist on only its servers, of course. The clients that users interact with are important as well. Traditionally, IT only had to worry about domain joined Windows clients, but today business users have quite a variety to choose from. Over several releases, AD has adapted to handle this wider variety.
If your organization is embracing the “digital transformation” of cloud services – in particular Azure Active Directory with Windows 10 clients – there’s one scenario where you need to take a closer look at AD 2016. First, a little background on device support in AD will help understand the scenario.
Active Directory has historically supported domain-joined Windows devices. Beginning with Windows Server 2012 R2, AD also allowed a user to perform a registration (you can think of it as a lightweight join) of a mobile device such as a smart phone. This Workplace Join capability gives the device a presence in AD and associates it with a user. This association gives the device a higher degree of trust than an unknown device, and thus it can be granted single sign on and access to more secure network resources.
AD’s hefty younger brother in the cloud – Azure AD – also supports both these device types. You can join them directly to the cloud service using Azure AD join for Windows 10 devices and Intune registration for iOS, Android, and Mac OS devices. This confusing architecture gets more confusing in a hybrid environment with on-premises Windows 7 and 8 clients; Azure AD can be made aware of them via a hybrid Azure AD join, which are necessary to apply device aware conditional access policies.
Are you looking at Windows Hello for Business to provide secure authentication beyond passwords? Out of the box, Hello gives you the ability to unlock your Windows 10 device using a biometric or a PIN. Hello for Business is a broader MFA framework that uses asymmetric keys (stored in a device’s security module) to authenticate the user. There is an MFA scenario in an on-premises Active Directory / Azure AD hybrid environment where you need both AD 2016 and AD FS 2016. I’ll talk about reasons to consider upgrading to AD FS 2016 in a future blog post.
Better Security
Regardless of AD improvements, there’s security goodness you’ll gain in getting current with its underlying Windows Server 2016 OS. If you should happen to still be on 2008 R2, when you upgrade you’ll gain a UI for the AD Recycle Bin which makes it much easier to use. You can also start closing a longstanding security hole: ancient, unchanging passwords on your service accounts: group managed service accounts (gMSAs) automatically update the password on these accounts for you, even if they’re used in a cluster.
If you’re already on 2012 R2, Windows Server 2016 has a couple of security improvements to consider. Windows Defender Credential Guard and Remote Guard protect NTLM and Kerberos credentials in AD from being harvested by attackers and used for pass-the-hash attacks. Windows Defender Application Control protects the integrity of the base OS by allowing only certain applications to run (also known as whitelisting) – a great security measure for a server running a dedicated workload such as AD.
Privileged Access Management for AD
If you have a directive to really lock down your AD administrative accounts, AD 2016 also introduces Privileged Access Management (PAM). In conjunction with a dedicated MIM deployment, PAM is a special, highly secured, “red” forest you build that controls the administrative groups of a target AD forest.
AD 2016 has updates to security groups, called shadow principals, that allow admin groups in the target forest to be “shadowed” to the red forest via a new form of forest trust. When an administrator account in the red forest is added to a shadowed admin group in that forest, they gain the same SID as the admin group and thus the same rights. With this capability in place, administrative accounts are removed from the target forest and only exist in the secured red forest.
AD 2016 also has updates to the Kerberos protocol that allow group membership (stored in the PAC field of the Kerberos ticket) to be time-limited. When combined with shadow principals and access request workflow built into MIM, admins can request and be granted admin rights (via group membership) for a specified period of time. When time expires, these rights are automatically revoked.
Reasons to stay where you are
Frankly, there aren’t a lot of reasons to remain on a down level AD.
If you have a test forest in an isolated network, running on physical DCs, that doesn’t support client devices, then perhaps you can delay a bit.
Maybe budget is an issue at the moment. Your management needs to look at the larger picture: most companies have far fewer than fifty DCs. The cost of licensing, upgrading, and deploying new capabilities on these servers is trivial compared to the cost of a breach from gaining domain credentials from older AD versions.
AD compatibility with very old applications, or old embedded client software running very expensive hardware such as computerized manufacturing equipment can be a thornier issue. But 2008 R2 won’t be viable much longer: end of support (with SP1 applied, mind you) occurs on January 14th, 2020. That’s only a year and four months away. End of support means Microsoft will no longer provide security updates – an essential service in today’s cat-and-mouse world of vulnerabilities and patches. 2012 and 2012 R2 forests have more time: October 10, 2023. (Note that both 2012 and R2 have the same end of support date.)
Recommendations
My recommendations are:
- If your DCs are running 2008 R2, regardless of what scenarios above you fit into, you should be planning your upgrades and doing application compatibility testing right away.
- For you 2012 or 2012 R2 users, virtualization and base level OS security improvements warrant an upgrade. You’ll also want to work with the server engineering and security teams as a stakeholder to drive deployment of 2016 security improvements in the standardized platform build image. Application compatibility issues should be minor.
- Unless you fit into the special hybrid Hello for Business scenario, device management improvements won’t be a strong AD 2016 driver.
When you take a close look at upgrading to AD 2016 versus staying where you are, other than application compatibility there are really no good reasons not to upgrade. Probably the primary reason for not upgrading is complacency: it’s working well as it is. But security improvements in both the base OS and AD will significantly enhance your organization’s protection against attackers. And that means you should start planning your upgrades today.
