In this post we will be discussing the Protected Users group in Microsoft Active Directory. This is to try and raise awareness of this security feature built into Microsoft Windows Active Directory (AD) 2012 R2 Domain environments. The Protected Users group in AD gives its members additional security features and protection when logging into Windows Server 2012 R2, Windows 8.1 and above.
If an account is made a member of the group. The user account can only authenticate using the Kerberos protocol. We will demystify this shortly with an example, however in brief it means that this user will not be able to authenticate with NTLM, WDigest Authentication, or CredSSP. Which means using one of these Security Support Providers (SSP) will fail. This is a win, as we know the NTLM hash is obtainable and is very crackable, Digest Auth stores credentials in clear text in memory, CredSSP also stores clear text credentials however is an interesting one as this may break applications that use it. However you might argue as you would probably only use this for high privilege accounts, (as Microsoft advises here) it might not be so much of an issue, and would probably be re-evaluated on a case by case basis after testing.
In addition to the above, the account will not use DES or RC4 in the pre-authentication stages. The domain therefore must support AES.
There are a couple of caveats that you should be aware (you can read about these here) of when using this as an option to help mitigate credential theft:
This will only take affect on Windows 8.1 and Windows Server 2012 R2, so no change for Windows 7 and Server 2008 I am afraid. So when logging into Windows 7 or Server 2008 variants your don’t get the protection from Protected Users membership.
Windows Server 2012 R2 Domain Functional Level is required.
Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs) as well as computer objects can not be added to the group. (technically they can, however it will break things).
What does all this mean then in actual protection terms, what does it look like?
I feel an example coming on:
Lets test with Windows Server 2012 R2. If we dump creds on a vanilla install with mimikatz this is typically what we would see. So no wdigest as this is disabled by default however what we can see and retrieve is the NTLM hash for the account ‘Adam2’, which as we know can be cracked off-line.
Now if we add our account to the Protected Users group and test, lets see what happens. Lets log off and back on and re-run mimikatz:
No NTLM hash, this is because members of the protected users group will only authenticate with Kerberos and not with NTLM. Great. This seems like a win for high privilege accounts. More to come on this soon.