First published on TechNet on Apr 04, 2016
Hi all – This is Jerry Devore back again with a quick post on the “Protected Users” group. As a PFE, I work with several enterprise customers who have a global presence, and have become very focused on protecting highly privileged accounts. The major concern that’s at the top of their list is “How do we prevent credential theft and reuse?” That’s why Windows Server 2012 R2 features like Authentication Silos and Protected Users has them more excited about upgrading. However, the fact that the organizations are “global” typically translates that the wheels of change are moving slowly. Which means migrating to the Windows Server 2012 R2 Domain Functional Level (DFL) is still several months away. Additionally, Windows 7 is their standard desktop OS and any Windows 10 pilots are just in planning phases. At first glance, it might appear that without raising the DFL to Windows Server 2012 R2, the Protected Users group is of no benefit in the ongoing battle to mitigate Pass the Hash (PtH) vulnerabilities. I must say, however, that impression is not completely accurate. If you take the time and read this article closely, you will notice it mentions “ client-side protection ” …which actually can be achieved without raising the DFL to Windows Server 2012 R2 levels. Are you intrigued yet? Let’s then take a look at what those client benefits are, and how we can enable them.
Creating and Replicating the Protected Users Group
While 2012 R2 DFL is not required, having at least one 2012 R2 domain controller is a prerequisite. That obviously implies the forest schema will need to be extended to version 69. Many enterprise change control boards lose their minds at the mere mention of performing an Active Directory schema update. Reading "AD schema update" in a change request is apparently as detrimental as hearing Ni! From the Knights Who Say Ni . Having worked with Windows domains since NT 3.51 I know too well why that is. In the early days of Active Directory we conditioned everyone to believe that if a schema update went sideways it would destroy the Active Directory forest. While that remains to be true, the reality is that the logic used for standard Microsoft schema extensions is highly robust. If there has been a customer who extended their schema for a domain upgrade and bricked their forest, I certainly haven’t heard about it. That is not to say to you should take schema extensions lightly or not test them in your development environment. Just don't let fear keep you from moving forward.
Once you have introduced your first 2012 R2 domain controller you need to transfer the PDCe FSMO role to it. That will trigger replicating the newly created Protected User group to all domain controllers in the domain. At this point you are ready to take advantage of the client-side protections. As long at the client is compatible, those protections will be effective even if the authenticating domain controller is not 2012 R2. In fact, you could even move the PDCe role back to a down-level domain controller at this point.
What have we accomplished?
So what are the client-side protections we just made possible? Well most importantly the NTLM hash is no longer retained in LSASS when a member of Protected Users logs on. Sound too good to be true? If you enable the ProtectUser-Client event log you can see for yourself that is really what happens.
Would you like more confirmation that NTLM authentication is not happening in the background? Attempt to connect to another computer in the domain using its IP address. Because using an IP address will cause Kerberos to fail, the client will fall back to NTLM authentication. Given there is no cached NTLM password hash, you will be prompted to re-enter the password.
More proof can be found back in the Protected-Client event log. As you can see the 101 event confirms that authentication failed because the user is a Protected User
Removing NTLM hashes from your highly privileged accounts should be all the justification you need to get moving with the Protect Users group. But there are some other great benefits. First Wdigest and Credssp credentials will also no longer be stored in LSASS. Wdigest uses a challenge / response method similar to NTLM which allows the user passwords to be validated without sending it over the wire. A typical scenario of a client using Wdigest is connecting to IIS or an LDAP server. The concern with Wdigest is that the cached password is stored in clear text within LSASS memory. Kurt Falde explains in his blog why Wdigest is not disabled by default and how a registry setting on a device can remove the password from LSASS. The benefit of using Protected Users is that Wdigest can be disabled anywhere a highly privileged user logs on regardless of the device configuration.
CredSSP was introduced with Windows XP and can be used to delegate a credential for the purpose for making a remote session connection. RDP to a Terminal Server is an example of where CredSSP can be used. A key problem with this security provider is that the delegation is unconstrained so there are no restrictions on where user’s credentials can be exposed. Like Wdigest, CredSSP can be disabled at the device level using policies or the registry. However, targeting privileged user accounts rather than devices is going to yield quicker security gains.
Another client side protection is that the Kerberos long term key is not retained. The long term key is basically a hashed version of the user’s password which is used to acquire a Kerberos Ticket Granting Ticket (TGT). By default, a TGT is valid for 10 hours. When a TGT expires Windows will automatically renew it. Given Protected Users client-side protections removes the long term key, members will be prompted to provide their password when the TGT expires. Once the DFL has been raised to 2012 R2, Protected Users members will be issued a 4 hour TGT.
The last benefit on the client side to mention is that the "cached logon verifier" is not created. If cached logon verifier does not ring a bell that is because most of us commonly refer to it as "cached credentials". Not having an administrator’s password cached does improve security but it can also impact functionality when not on the network. Keep that in mind when planning out how remote access will be impacted.
More fine print on Protected Users
There is one last aspect of Protected Users which is not evident from much of the documentation. Many sources indicate that Windows 8.1 \ Server 2012 or higher is required for the client-side protections. However, when KB2871997 was released in May of 2014 the feature was backported to Windows 7 and 2008 R2. That is great news for customers who are stuck on those operating systems. In particular, the ones that do not have a PAW solution for their highly privileged administrators. If that is your environment, I certainly hope you will give implementing Protected Users serious consideration.
Jerry Devore, PFE