Microsoft introduced the Protected Users group in Windows Server 2012 R2 and Windows 8.1, and it’s designed to harden accounts that are group members, in particular to protect against pass-the-hash attacks by disabling the use of NT LAN Manager (NTLM), a legacy authentication protocol that’s still present in Windows for backwards compatibility.
The extra protections are only provided when users log in to Windows Server 2012 R2 or Windows 8.1, and the full list of defenses requires the domain functional level to be set to Windows Server 2012 R2 (or higher).
Protected Users is primarily intended for use with domain and enterprise administrator accounts, which are particularly susceptible to attack, as when compromised they provide wide-open access to systems. That’s not to say that other user accounts, that might be considered a target, can’t be added to Protected Users. But because of the tight restrictions placed on members of Protected Users, it’s essential to perform thorough testing beforehand.
There are no workarounds for the restrictions, so it’s wise to make sure that if you intend to add highly-privileged accounts, like domain and enterprise administrators, that at least one that’s not used for regular administration tasks, is left outside of the group.
The following protections are enabled for members of the Protected Users group when logging in from a supported device:
- Cached credentials are blocked. A domain controller must be available to authenticate the user
- Long-term Kerberos keys cannot be used to log in
- Plaintext passwords are not cached for Windows Digest authentication or default credential delegation (CredSSP), even when the relevant policies are enabled
- NTLM one-way function (NTOWF) is blocked
If the domain functional level is set to Windows Server 2012 R2 or higher, additional protections are enabled:
- Kerberos ticket-granting tickets (TGT) cannot be renewed for longer than a 4 hour time-to-live (TTL) period
- NTLM is blocked
- Data Encryption Standard (DES) and RC4 can’t be used for Kerberos pre-authentication
- Constrained and unconstrained delegation is blocked
When DES and RC4 are blocked, all domain controllers (DC) must be running Windows Server 2008 (or later), and before adding users to Protected Users, their passwords should be changed against a Windows Server 2008 DC so that the AES keys are stored in Active Directory.
I Can’t See the Protected Users Group in my Domain
If you don’t have the Protected Users group in your domain, you will need to make sure there is at least one Windows Server 2012 R2 DC, and transfer the Primary Domain Controller (PDC) Emulator Flexible Single Master Operation (FSMO) role to a Windows Server 2012 R2 DC. If necessary, the PDC role can be transferred back to its original location.
To check if you have the Protected Users group in your domain, log in to Windows Server 2012 R2 as a domain administrator:
- Open Server Manager from the Start screen
- Select Active Directory Users and Computers from the Tools
- In the left pane, expand your domain and click Users.
If Protected Users is present in the domain, you should see it on the right. Users can be added to Protected Users, as you would add them to any AD group. Using PowerShell for example, to add the admin1 user account:
Add-ADGroupMember –Identity ‘Protected Users’ –Members admin1
To transfer the PDC emulator FSMO role to a Windows Server 2012 R2 DC, log in to the DC using a domain administrator account, and open a PowerShell prompt using the icon on the desktop taskbar. Now type the command below and press ENTER, replacing DC6 with the name of the Windows Server 2012 R2 DC:
Move-AdDirectoryServerOperationMasterRole -Identity DC6 –OperationMasterRole pdcemulator
If you want to confirm the new or original location of the PDC emulator FSMO role, run the command below, replacing ad.contoso.com with the name of your AD domain:
Get-AdDomain ad.contoso.com | Format-List pdcemulator
