Windows Protected Users Security Group: How to Harden Privileged Accounts Against Credential Theft Without Complex Configuration

Understanding each enforcement prevents surprises during deployment:

1. No NTLM authentication Members cannot authenticate using NTLM regardless of client or server NTLM settings. Any application, service, or authentication path that falls back to NTLM fails for Protected Users members. This is the most impactful compatibility constraint.

2. No credential caching Windows does not cache the credentials of Protected Users members on local machines. This means: if the account is used to log in to a laptop and the laptop loses connectivity to a DC, the user cannot log in. This is by design -- a stolen laptop does not contain a cached credential that can be extracted.

3. No Kerberos delegation Members cannot be configured for unconstrained or constrained Kerberos delegation. Any service that impersonates a Protected Users account via delegation receives an error.

4. AES-only Kerberos encryption Kerberos tickets for Protected Users members use only AES128 or AES256. RC4 (the cipher used in Kerberoasting because it has a known hash format) is not used. If an attacker Kerberoasts a Protected Users member's service ticket, they receive an AES-encrypted ticket -- significantly harder to offline crack than RC4.

5. Ticket lifetime and renewal TGTs for Protected Users are limited to the Maximum Ticket Lifetime (default 10 hours) and cannot be renewed. Standard domain users can renew Kerberos tickets for up to 7 days without re-authenticating.

Check current members:

Get-ADGroupMember -Identity 'Protected Users' -Recursive |
    Select-Object Name, SamAccountName, ObjectClass

Add immediately (tier 0 accounts):

• Domain Admins members
• Enterprise Admins members
• Schema Admins members
• krbtgt account (the Kerberos ticket-granting account)
• ADFS service accounts
• Azure AD Connect sync accounts (check NTLM usage first)
• Your own admin account
• Privileged Access Workstation (PAW) accounts

Add after testing (tier 1 accounts):

• Server administrators
• Backup operator accounts
• PKI/CA administrator accounts
• Virtualization administrator accounts

Do not add:

• Computer accounts (breaks services running as the machine account)
• Service accounts that use NTLM for authentication (breaks the service)
• Service accounts configured for Kerberos delegation (breaks delegation)
• Accounts used on offline/field laptops where cached credentials are needed for operation
• The local Administrator account (Protected Users has no effect on local accounts)

Add a tier 0 account:

# Add a single account
Add-ADGroupMember -Identity 'Protected Users' -Members 'jsmith-admin'

# Add all current Domain Admins to Protected Users
Get-ADGroupMember -Identity 'Domain Admins' | ForEach-Object {
    Add-ADGroupMember -Identity 'Protected Users' -Members $_.SamAccountName
    Write-Host "Added: $($_.SamAccountName)"
}

The most common failures after adding an account to Protected Users:

NTLM authentication failure:

Error: NTLM authentication is not allowed for user 'DOMAIN\username'
# Or: 'The user account is configured to prevent delegation'

Identify what is using NTLM: enable NTLM audit logging on DCs (Network Security: Restrict NTLM > Audit NTLM in this domain) and check Event ID 8004 (NTLM blocked) in the operational log.

Service account failure:

# Event ID 4769 on DC with Failure Code 0x12 or 0x18
# Or: Service fails to start with 'Logon failure: unknown user name or bad password'

If a service account is in Protected Users and the service uses NTLM, you must either remove the account from Protected Users or change the service to use Kerberos with an SPN.

Offline login failure: Users in Protected Users who cannot reach a DC at login receive: 'There are currently no logon servers available to service the logon request.' This is expected -- remove the account from Protected Users if offline access is required.

Delegation failure:

# Find services failing due to delegation blocked by Protected Users
# Event ID 4768/4769 on DC with result code 0x1D (KDC_ERR_BADOPTION)
# Or application event: 'The Kerberos client received a KRB_AP_ERR_BAD_INTEGRITY error'

Diagnostic command:

# Test if an account is affected by Protected Users
Get-ADUser 'jsmith-admin' -Properties MemberOf |
    Select-Object -ExpandProperty MemberOf |
    Where-Object { $_ -match 'Protected Users' }
# If this returns a DN, the account is in Protected Users