Service and Computer Accounts in Protected Users Lose NTLM, RC4 and Kerberos Delegation

Protected Users is the Active Directory global security group designed to protect user accounts against credential theft. Microsoft’s reference for it carries a blunt instruction: never add accounts for services and computers to the Protected Users group. When a service account or computer account ends up there anyway, usually through a hardening sweep that added “every privileged account”, domain controllers start refusing that account’s NTLM authentication and RC4 Kerberos preauthentication, block it from unconstrained and constrained delegation, and cap its ticket-granting tickets at four hours. Membership buys nothing for these accounts, because the password and certificate are always available on the host. The fix is to take them out of the group, carefully and in a recorded order.

Symptom

After a privileged-access hardening change, a service that ran for years starts failing authentication. Typical reports are an application pool or scheduled job that can no longer reach a file share or database, a web tier that stops passing users through to a back end, or a legacy client that uses NTLM failing for one account only. The account is not locked out, its password has not changed and other accounts on the same host still work. If the Protected Users logs on the domain controllers are enabled, they show event 100 (an NTLM sign-in failure for a Protected Users member) or event 104 (Kerberos preauthentication failed because DES or RC4 was used) for that account.

False Assumption

The assumption is that Protected Users is a stronger tier that suits any account worth protecting, so a privileged service account belongs there as much as an administrator does. Microsoft documents the opposite. The group’s device protections stop a signed-in user’s credentials from being cached; a service or computer account’s secret is held on the host by design, so there is nothing for the group to protect locally. What remains are the domain controller restrictions, and those apply to every member without exception.

Root Cause

Membership applies non-configurable controls that the account cannot change unless it leaves the group. According to Microsoft, a Protected Users account that authenticates to the domain cannot:

• authenticate with NTLM;
• use DES or RC4 encryption types in Kerberos preauthentication;
• delegate with unconstrained or constrained delegation;
• renew Kerberos TGTs beyond their initial four-hour lifetime. The group sets both the ticket lifetime and the renewal limit to 240 minutes, overriding the domain’s Maximum lifetime for user ticket and Maximum lifetime for user ticket renewal policies.

Members can authenticate only with Kerberos using AES, which needs AES keys on the account. Microsoft notes that accounts migrated from other domains need a password reset before they have AES hashes. A long-lived service account whose password predates AES support, or that is still used by an RC4-only client, fails outright. The encryption-type side of this is covered in msDS-SupportedEncryptionTypes: RC4 Still Wins Kerberos.

Impact

The failure lands on production services, not on people, so it surfaces as an application outage rather than a sign-in complaint. Microsoft lists constrained and unconstrained delegation among the things a member cannot do, so multi-tier applications that rely on Kerberos delegation involving the account are at particular risk. Because the restriction cannot be tuned, there is no partial setting to fall back to: the account is either a member, with every restriction, or it is not. Microsoft also warns that adding all members of highly privileged groups such as Domain Admins or Enterprise Admins without testing can accidentally lock those accounts out, so the same sweep that caught service accounts may have put administrators at risk.

Diagnosis

These steps are read-only. Run them with the ActiveDirectory PowerShell module from an administrative workstation or a domain controller.

1. List every member of the group, including members that arrive through nested groups. -Recursive returns all members in the group’s hierarchy that do not themselves contain child objects:

   Get-ADGroupMember -Identity "Protected Users" -Recursive

2. Read the objectClass of each member. Any computer object is a misconfiguration. For user-class members, compare the SamAccountName values against your inventory of service accounts (accounts configured as the logon identity of services, application pools and scheduled tasks).
3. Run the command again without -Recursive to see whether each unwanted member was added directly or through a nested group, because that decides which group you change.
4. On each domain controller, open Event Viewer, go to Applications and Services Logs\Microsoft\Windows\Authentication, right-click each Protected Users log and select Enable Log; Microsoft ships them disabled. Then look for events 100 and 104 in the ProtectedUserFailures-DomainController log naming the suspect account.

A service or computer account in the recursive membership, together with failures logged for it, confirms the trap.

Correction

The fix is to remove the service and computer accounts from Protected Users, or remove the nested group that brought them in, and leave genuine interactive administrator accounts where they are.

Preconditions. You need rights to modify the Protected Users group membership; Microsoft rates delegating management of this group to non-service admins as unsafe, so expect this to be a domain administrator task. Run the change against a writable domain controller: Remove-ADGroupMember does not work with a read-only domain controller. Agree a maintenance window with the service owners, and rehearse in a test domain first.

Backup. Save the full output of Get-ADGroupMember -Identity "Protected Users", with and without -Recursive, in your change record. That list is the state you restore from.

1. Preview the removal with -WhatIf, which the cmdlet supports:

   Remove-ADGroupMember -Identity "Protected Users" -Members <ServiceAccount> -WhatIf

2. Remove the member. Leave the default confirmation prompt in place so each removal is acknowledged:

   Remove-ADGroupMember -Identity "Protected Users" -Members <ServiceAccount>

   If the account arrived through a nested group, remove that group from Protected Users, or the account from that group, rather than every account inside it.

3. Allow for replication to your other domain controllers, then restart the affected service, or the host for a computer account, in the maintenance window so it authenticates again.

Stop condition. If a service still fails after its account has left the group and re-authenticated, stop removing further accounts. The cause is then something else, such as missing AES keys or an RC4-only client, and the event logs show which.

Validation

Validation proves the account is out of the group and that the service works. Re-run Get-ADGroupMember -Identity "Protected Users" -Recursive and confirm the service or computer account no longer appears. Exercise the service end to end, including any path that uses delegation. Watch the ProtectedUserFailures-DomainController log: no new event 100 or 104 should name the account, and event 303 (TGT issued for a member) should no longer appear for it.

Rollback

Rollback puts the account back into the group and restores every restriction, including the outage, so use it only if the removal itself causes a problem you cannot otherwise explain. Re-add the member from your saved list:

Add-ADGroupMember -Identity "Protected Users" -Members <ServiceAccount>

For a nested group you removed, add that group back the same way. Re-run the recursive membership check and compare it with the saved output.

Prevention: Keep Protected Users for People, Not Services

• Scope Protected Users to interactive accounts, and test privileged administrators before adding them, as Microsoft advises, so the change cannot lock them out.
• Never nest broad groups such as Domain Admins into Protected Users; a nested group carries any service account that is, or later becomes, a member of it.
• Add the recursive membership check to your regular Active Directory review, next to requiring LDAP signing on domain controllers, and alert on any computer or service account that appears.
• Keep the Protected Users domain controller logs enabled so the next failure names its account immediately.
• Protect service accounts with controls designed for them rather than a group whose own documentation excludes them. Group-scoped settings have their own traps, as fine-grained password policies applied to groups show.

Microsoft’s Protected Users reference applies to Windows Server 2016 to 2025 and requires a domain functional level of Windows Server 2012 R2 or later. Check it against your domain controllers’ versions before changing production membership.