With Windows Server 2012 R2 and Windows 8.1, Microsoft introduced a feature in Active Directory Domain Services called the Protected Users group. You can use it to limit the availability of outdated authentication protocols, weak encryption algorithms and delegation to sensitive user accounts.
Interesting stuff, but I feel there’s some things you should know about this feature…
When you want to go and put the Protected Users group to good use in your environment, I feel you should be aware of these things:
1. Take care of client-side requirements
No matter how you look at this wonderful feature, you won’t escape the fact that to get the protection, your users need to log on to Windows 8.1 (or up) devices or Windows Server 2012 R2 (or up) hosts. Even if you’ve upgraded all the Domain Controllers to Windows Server 2012 R2 and upgraded the Domain Functional Level to Windows Server 2012 R2, when your colleagues use Windows 7 as their client Operating System (OS) or Windows Server 2008 R2 as their Terminal Servers, they won’t benefit from the protections offered by membership of the Protected Users group.
2. Take care of server-side requirements (sorta)
According to the official documentation, the Protected Users group requires the Windows Server 2012 R2 Domain Functional Level (DFL). However, the Protected Users group can be applied to Active Directory domains that are set to a Domain Functional Level (DFL) for an operating system earlier than Windows Server 2012 R2.
This allows the added security that is achieved by using the Protected Users group to be applied throughout the domain. To do this, promote the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role to Windows Server 2012 R2, and then allow the upgraded PDC to replicate the Protected Users group to other Domain Controllers. When the replication completes, the PDC can be set back to any available Domain Functional Level (if desired), and the Domain Controller-based protections are automatically applied.
3. Protect users only
Accounts for services and computers should not be members of the Protected Users group. This group provides no local protection to these types of accounts because the password or certificate is always available on the host. Also, since Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs) use Kerberos Constrained Delegation (KCD), do not add these accounts to the Protected Users group, since their functionality will break.
4. Make Protected Users change their passwords on Windows Server 2008 Domain Controllers (or up) first
Members of the Protected Users group must be able to authenticate by using Kerberos with Advanced Encryption Standards (AES). This method requires AES keys for the account object in Active Directory. The built-in Administrator does not have an AES key unless the password was changed on an Active Directory Domain Controller that runs Windows Server 2008 or later. Additionally, any account object, which has a password that was changed at an Active Directory Domain Controller that runs an earlier version of Windows Server, is locked out.
5. You may lock yourself out
The authentication restrictions have no workarounds, which means that members of highly privileged groups such as the Enterprise Admins group or the Domain Admins group are subject to the same restrictions as other members of the Protected Users group. If all members of such groups are added to the Protected Users group, it is possible for all of those accounts to be locked out. My advice is to never add all highly privileged accounts to the Protected Users group, until you have thoroughly tested the potential impact.
6. The protection is non-configurable
The protection triggered by membership of the Protected Users group is non-configurable.
However, most of the same protection can be achieved using more configurable methods like Group Policies and Authentication Policies (to configure TGT lifetimes more granularly) and NTLM block policies.
The inability to use DES to encrypt Kerberos pre-authentication, on the other hand is automatically enforced by Windows Server 2012 R2-based Active Directory Domain Controllers, so this protection mechanism may already be applied.
The inability to delegate can also be configured on a per account basis through the Account is sensitive and cannot be delegated setting in Active Directory.
7. Group membership changes need token refreshes
It may take longer than expected for the protection triggered by membership of the Protected Users group kicks in. This is because group memberships are enumerated during logon. For the protection to kick in, immediately, log off and log back on with the user account you’ve added to the Protected Users group.
8. Membership of the Protected Users does not meddle with AdminCount
In many organizations, sensitive accounts are accumulated by running a script that checks for objects with the AdminCount attribute set to 1. Membership of the Protected Users group does not change the value for the AdminCount attribute. This might lead to incomplete reports of accounts, marked as sensitive.
9. Troubleshooting delegation
One of the protections triggered by membership of the Protected Users group is the inability to, technically, be trusted for delegation. In a situation where delegation would be failing, the first response is to check to see if Account is sensitive and cannot be delegated is set for an account. However, the graphical user interfaces (GUIs) for Active Directory Users and Computers (dsa.msc) and Active Directory Administrative Center (dsac.exe) do not reflect an inability to delegate due to membership of the Protected Users group. Next to checking the setting on the account, check for the event IDs in Event Viewer (eventvwr.msc) indicating a member of the Protected Users group has logged on.
10. Protected Users are not 100% protected
When you add user accounts to the Protected Users group, it’s not yet time to sit back, zip a coffee and enjoy the show. Membership of the Protected Users group offers protection, but it’s no 100% protection. In fact, it’s not even close to 70%, because membership of the Protected Users group doesn’t protect against a whole range of other attack vectors, like the Privilege Escalation based on Exploitation of Unauthorized Grants vector.
Otherwise, I strongly urge you to use the Protected Users group functionality, because it adds a layer of protection in most environments.
If some of the points above are true showstoppers in your environment, Authentication Policies and Authentication Policy Silos might be a good solution. More on those, soon.
I have a question. Can computer objects in the Protected Users group still use NTLMv2 authentication?
Computer objects in the Protected Users group cannot be used at all.
Authentication on these devices will fail with the error "the user name or password is incorrect".
So we've just started to attempt using the Protected Users group for a couple of reasons. It seems to be one of those it works well when it works sort of situations.
What I ran into most recently however has to do with passing credentials within a powershell script. Simply doing '$creds = Get-Credential' and then 'Get-ADUser *username* -credential $creds' seems to fail and I've not found a workaround yet.
Actually, how I stumbled on your blog was trying to search for a solution.
Is it best practice to put the domain admin group into the procted users group? I mean you don't want those credentials laying around cached on a computer out in the wild?
It is a best practice to block members of the domain admins and enterprise admins groups from signing in any other place but Domain Controllers and Privileged Access Workstations (PAWs) following the Active Directory Administrative Tier model. However, in smaller organizations, this might prove difficult, costly and/or cumbersome. In those situations, memberships to the Protected Users group may prove useful for credential containment.
As far as you know, are there issues with LDAPS as an identity source in vCenter, when the users connecting are in the Protected Users group?
The service account is not in the Protected Users group and so we're able to create the IS just fine, but when we connect with Protected Users it fails. I remove them from the Protected Users group and we connect just fine. For now we've reverted back to ISA, and created a ticket with VMware, but I'm having trouble finding anywhere why it doesn't work.
From what I understand, in order for Protected Users group to work, LAN Manager authentication level must allow NTLM v2. Otherwise authentication of members in this group will be denied. Should it allow only NTLM v2, or are lower tier responses allowed (for compatibility reasons)?
When a user account is a member of the Protected Users security group, and the Active Directory Domain Functional Level (FFL) is configured as Windows Server 2012 R2, or above, NTLM authentication is blocked for that user account, altogether (both NTLMv1 and NTLMv2). I encountered this in the real world.
Is it advisable to add all users of the active directory domain to the Protected Users security group?
Advisable? Perhaps. Doable? Not really.
I'd start with granular adding admin accounts to the Protected Users security group.