Pilot the Active Directory Protected Users group before placing privileged accounts inside it

Bottom line: Active Directory’s Protected Users group reduces the credential material and authentication methods available to member accounts. Those protections are mandatory while an account is a member. They can also expose old NTLM, delegation, encryption, offline sign-in, and remote-administration dependencies, so adding every privileged user at once can create an avoidable lockout.

Source fact: what Microsoft documents

Microsoft’s Protected Users security group guidance describes a domain global group designed to protect against credential theft. On supported devices, membership prevents several forms of credential caching. Windows does not create a cached verifier for member sign-in or unlock, so offline sign-in is unavailable. Credential delegation, Windows Digest, NTLM, and Kerberos caching behavior are also restricted as documented by Microsoft.

At the domain controller, Protected Users cannot authenticate with NTLM, use DES or RC4 for Kerberos preauthentication, or use constrained or unconstrained Kerberos delegation. Members require Kerberos with AES. Their ticket-granting ticket lifetime and renewal are constrained to four hours by the group’s nonconfigurable settings.

Microsoft lists prerequisites that include supported Windows hosts and a Windows Server 2012 R2 or later domain functional level. It warns not to add service or computer accounts because the group does not provide the intended local protection for those accounts. It also warns against moving all highly privileged accounts into the group without testing because the restrictions have no workaround while membership remains.

The page identifies ProtectedUser client and domain-controller event logs under Applications and Services Logs → Microsoft → Windows → Authentication. Those logs are disabled by default. Documented events include client credential-package failures, domain-controller failures involving DES or RC4, and successful Kerberos ticket issuance for a protected user.

What the source does not establish

Group membership does not prove that an account is least privileged, that its workstation is trusted, or that every credential-theft path is prevented. The Microsoft page does not inventory an organization’s legacy applications, remote tools, delegation chains, offline work requirements, disaster-recovery accounts, or help-desk procedures. A successful interactive sign-in alone does not demonstrate that the user’s complete administrative workflow remains functional.

Applicability questions

• Which human accounts are candidates, and are any service or computer identities mixed into the list?
• Do candidate accounts have AES keys and reach domain controllers that meet the documented prerequisites?
• Which applications, scripts, remote tools, file services, or devices still require NTLM or delegation?
• Does any approved work require cached offline sign-in?
• Which independently protected account can reverse membership if a test user is locked out?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Export current membership and assign an owner for every proposed addition and exception.
2. Trace representative sign-ins and administrative tasks to find NTLM, delegation, RC4, offline, and cached-credential dependencies.
3. Confirm domain, controller, workstation, and AES prerequisites before changing membership.
4. Enable the documented authentication logs on pilot systems and forward relevant events to protected monitoring.
5. Add one recoverable test account, then exercise local, remote, delegated, and emergency workflows. Remove the account if a required dependency fails and document the result.
6. Expand in small waves with a defined rollback operator who is not dependent on the account being changed.

Verification and evidence

• Preserve approved membership changes and their owners.
• Capture successful Kerberos ticket events and investigated failure events.
• Prove required administration paths work without NTLM, RC4, or disallowed delegation.
• Test removal from the group and restoration of required access.
• Record unresolved dependencies, exceptions, and their retirement dates.

Official references

• Protected Users security group — Microsoft