Understanding the ‘Protected Users’ group in Active Directory: When to use it and when not to

Active Directory (AD) is packed with powerful security features designed to reduce the risk of identity compromise. One such feature is the Protected Users group. Introduced with Windows Server 2012 R2, the Protected Users group offers an additional layer of security for high-risk and high-privilege accounts by enforcing strict authentication policies. However, this group is not suitable for all users and requires careful consideration before implementation.

In this article, we’ll delve into what the Protected Users group is, its benefits, limitations, and guidelines for determining when to use it and when to avoid it.

What is the Protected Users Group?

The Protected Users group is a built-in security group designed to enhance the security of user accounts by applying additional protections against credential theft and attacks like Pass-the-Hash and Pass-the-Ticket. When a user is added to this group, a set of restrictions are automatically enforced to mitigate the risk of compromise.

Key security enhancements for members of the Protected Users group:

1. No Kerberos Ticket-Granting Ticket (TGT) Caching:
   • Kerberos tickets are not cached, reducing the risk of offline ticket theft.
2. No NTLM Authentication:
   • NTLM (NT LAN Manager) authentication is blocked, making it impossible to use weaker, more vulnerable protocols.
3. No Use of DES or RC4 for Kerberos Pre-authentication:
   • Only AES encryption is used, preventing attackers from exploiting weaker encryption types.
4. No Delegation:
   • Protected Users cannot be used for unconstrained or constrained delegation, reducing the risk of privilege abuse.
5. Enforced User Ticket Lifetime:
   • Kerberos tickets for Protected Users are limited to a maximum of 4 hours, minimizing the risk exposure.
6. No Use of Plaintext Passwords:
   • Passwords for members of this group cannot be stored in plaintext within the Local Security Authority (LSA), reducing credential exposure.

These enhancements make the Protected Users group particularly useful for high-value targets, such as administrators and service accounts that require elevated privileges.

When to Use the Protected Users Group

The Protected Users group is not a one-size-fits-all solution. It’s most effective when used to protect high-risk accounts that are likely to be targeted by attackers.

Recommended Scenarios for Using the Protected Users Group:

1. Domain Admins and Other High-Privilege Accounts:
   • Accounts with elevated permissions, such as those in the Domain Admins, Enterprise Admins, or Schema Admins groups, should be prioritized for this protection.
2. Accounts with Access to Sensitive Data or Critical Systems:
   • Users who have direct access to confidential data, financial systems, or intellectual property are prime candidates for membership.
3. Service Accounts Running on Critical Systems:
   • If a service account is used to run a mission-critical service or application, adding it to this group can prevent unauthorized access and credential abuse.
4. Accounts Frequently Used in Remote or Untrusted Locations:
   • If a user regularly logs in from potentially untrusted devices or networks, adding them to the Protected Users group can reduce the risk of credential theft in those scenarios.
5. Privileged Access Workstations (PAWs):
   • Admins using PAWs should be included in the Protected Users group to ensure that even if a workstation is compromised, the admin’s credentials remain secure.

When NOT to Use the Protected Users Group

While the Protected Users group offers robust protection, its restrictions can cause operational issues if applied to the wrong accounts. Misuse of this group can lead to authentication failures and service disruptions.

Scenarios Where Using the Protected Users Group is Not Recommended:

1. Regular User Accounts:
   • Standard users who do not require elevated privileges or have limited access to sensitive data should not be included. This can cause issues with applications that rely on older protocols or need delegation.
2. Legacy Application Accounts:
   • Many older applications require NTLM or DES encryption. Adding such service accounts to the Protected Users group can cause authentication failures and disrupt services.
3. Accounts Used for Delegation:
   • Protected Users cannot be used for either unconstrained or constrained delegation. If a service or user account needs to delegate credentials (e.g., for single sign-on), it should not be in this group.
4. Accounts That Require Offline Access:
   • Because TGT caching is disabled, offline access is problematic for users in this group. If a user needs to access domain resources while disconnected from the network, they should not be in the Protected Users group.
5. Third-Party Integrations:
   • If the account is used by third-party tools or services that may rely on weaker authentication methods, it’s best to avoid using the Protected Users group unless the integrations can be updated.
6. Service Accounts Not Running on Windows Server 2012 R2 and Later:
   • The Protected Users group is only fully supported on domain controllers running Windows Server 2012 R2 or newer. Adding accounts to this group in older environments can lead to unpredictable behaviour.

How to Add Users to the Protected Users Group

If you’ve identified the appropriate users for the Protected Users group, follow these steps to implement it:

Step-by-Step Guide:

1. Open Active Directory Users and Computers (ADUC):
   • Log in to a domain controller or a management workstation with AD tools installed.
2. Navigate to the Built-In Groups:
   • Go to DomainName > Users.
3. Find the Protected Users Group:
   • Locate the Protected Users group, which is a built-in group in the Users container.
4. Add a User to the Group:
   • Right-click on Protected Users and select Properties.
   • Go to the Members tab and click Add.
   • Search for and add the desired users or groups.
5. Apply and Confirm:
   • Click OK to apply the changes. The selected users will now be subject to the security restrictions enforced by the Protected Users group.

Monitoring and Testing the Protected Users Group Implementation

After adding users to the Protected Users group, it’s crucial to monitor and test to ensure that there are no unintended disruptions. Use the following tools and techniques:

1. Event Logs:
   • Check the Security and System event logs for any authentication errors or warnings.
2. Active Directory Replication Status Tool (ADREPLSTATUS):
   • Use this tool to ensure there are no replication issues impacting the enforcement of group membership changes.
3. Azure AD and Hybrid Environments:
   • If you’re running a hybrid environment, ensure that Azure AD users are also configured correctly to work with the restrictions of the Protected Users group.
4. Test Key Applications:
   • Verify that key applications used by Protected Users can still authenticate and perform as expected.

Final Considerations

The Protected Users group is a powerful tool for securing high-privilege accounts, but it should be used with caution. Implement it thoughtfully, start with a small subset of accounts, and monitor for potential issues. If implemented correctly, it significantly reduces the risk of attacks like Pass-the-Hash and Pass-the-Ticket, ensuring a safer AD environment.