The Protected Users security group was introduced with Windows Server 2012 R2 and continued in Windows Server 2019. This group was developed to provide better protection for high privileged accounts from credential theft attacks. Members of this group have non-configurable protection applied. In order to use the Protected Users group, PDC should be running with a minimum of Windows Server 2012 R2 and the client computers should be running with a minimum of Windows 8.1 or Windows 2012 R2.
If a member of this group logs into Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016 or Windows server 2019, we can expect the following:
• Members of this group cannot use NTLM, digest authentication, or CredSSP for authentication. Plain text passwords are not cached. So, any of the devices using these protocols will fail to authenticate to the domain.
• Kerberos long-term keys not cached. For accounts in this group, the Kerberos protocol verifies authentication at each request (the TGT acquired at log on).
• Sign-in is offline. A cached verifier is not created at sign-in.
For the Protected Users group feature, it is not a must to have a domain or forest functional level run on Windows Server 2012 R2 or higher (Windows Server 2008 is the minimum as Kerberos needs to use AES). The only requirement is to run the PDC emulator FSMO role in the Windows Server 2012 R2 domain controller.
If the AD environment uses Windows Server 2012 R2 or Windows Server 2016 domain functional levels, it provides additional protections with Protected User groups, as:
• No NTLM authentication
• No DES or RC4 encryption in Kerberos pre-authentication
• No delegation using the unconstrained or constrained method
• No Kerberos TGT valid more than 4 hours
[su_note]Service accounts and computers cannot be members of the Protected Users' security group. These accounts can be protected using different features, such as policy silos, which I will explain later in this chapter.[/su_note]
To start with, we can review the Protected Users security group using the following command:
Get-ADGroup -Identity "Protected Users"
The following screenshot shows the output for the preceding command:
We can add users to the Protected Users group using ADAC, ADUC MMC, and PowerShell. This group is located in the default Users container in AD.
In here, we are going to add the user account Adam in to the Protected Users group using the following command:
Get-ADGroup -Identity "Protected Users" | Add-ADGroupMember –Members "CN=Adam,CN=Users,DC=rebeladmin,DC=com"
The first part of the command will retrieve the group and the second part will add the user Adam to it.
After the user is added to the group, we can verify group membership using the following command:
Get-ADGroupMember -Identity "Protected Users"
The following screenshot shows the output for the preceding command:
In order to test this, we are going to use a tool called mimikatz (https://github.com/gentilkiwi/mimikatz/blob/master/README.md), which can be used to do experiments with Windows security.
I logged in to a computer as user liam , and he is not part of the Protected Users group. When I list keys from LSASS for users, I can see Liam's NTLM hash clearly:
