{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/active-directory-protected-users-pilot/", "item": { "id": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/", "slug": "active-directory-protected-users-pilot", "url": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot.md", "json": "https://update.dsesecurity.com/api/v1/posts/active-directory-protected-users-pilot/" }, "title": "Pilot the Active Directory Protected Users group before placing privileged accounts inside it", "summary": "Protected Users applies nonconfigurable credential protections that can also break NTLM, delegation, offline sign-in, and other dependencies. Prove each account's authentication paths before membership expands.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-25T21:35:10+00:00", "modified_at": "2026-08-25T21:43:55+00:00", "reviewed_on": "2026-08-25", "reading_minutes": 3, "word_count": 573, "potentially_affected": "Active Directory user accounts, privileged administrators, Kerberos and NTLM dependencies, delegated administration, remote management, cached sign-in, domain controllers, and support recovery procedures.", "dse_recommendation": "Inventory each candidate account's authentication dependencies, confirm AES readiness, pilot membership with recoverable test accounts, enable the documented event logs, and expand only after both normal work and emergency access are verified.", "primary_source": { "name": "Protected Users security group", "url": "https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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.

\n

Source fact: what Microsoft documents

\n

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.

\n

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.

\n

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.

\n

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.

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n
    \n
  1. Export current membership and assign an owner for every proposed addition and exception.
    2. \n
  2. Trace representative sign-ins and administrative tasks to find NTLM, delegation, RC4, offline, and cached-credential dependencies.
    3. \n
  3. Confirm domain, controller, workstation, and AES prerequisites before changing membership.
    4. \n
  4. Enable the documented authentication logs on pilot systems and forward relevant events to protected monitoring.
    5. \n
  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. \n
  6. Expand in small waves with a defined rollback operator who is not dependent on the account being changed.
    7. \n
\n

Verification and evidence

\n\n

Official references

\n", "content_text": "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.\nSource fact: what Microsoft documents\nMicrosoft’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.\nAt 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.\nMicrosoft 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.\nThe 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.\nWhat the source does not establish\nGroup 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.\nApplicability questions\n\nWhich human accounts are candidates, and are any service or computer identities mixed into the list?\nDo candidate accounts have AES keys and reach domain controllers that meet the documented prerequisites?\nWhich applications, scripts, remote tools, file services, or devices still require NTLM or delegation?\nDoes any approved work require cached offline sign-in?\nWhich independently protected account can reverse membership if a test user is locked out?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nExport current membership and assign an owner for every proposed addition and exception.\nTrace representative sign-ins and administrative tasks to find NTLM, delegation, RC4, offline, and cached-credential dependencies.\nConfirm domain, controller, workstation, and AES prerequisites before changing membership.\nEnable the documented authentication logs on pilot systems and forward relevant events to protected monitoring.\nAdd one recoverable test account, then exercise local, remote, delegated, and emergency workflows. Remove the account if a required dependency fails and document the result.\nExpand in small waves with a defined rollback operator who is not dependent on the account being changed.\n\nVerification and evidence\n\nPreserve approved membership changes and their owners.\nCapture successful Kerberos ticket events and investigated failure events.\nProve required administration paths work without NTLM, RC4, or disallowed delegation.\nTest removal from the group and restoration of required access.\nRecord unresolved dependencies, exceptions, and their retirement dates.\n\nOfficial references\n\nProtected Users security group — Microsoft", "content_markdown": "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.\n\n## Source fact: what Microsoft documents\n\nMicrosoft’s [Protected Users security group guidance](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group) 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.\n\nAt 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.\n\nMicrosoft 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.\n\nThe 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.\n\n## What the source does not establish\n\nGroup 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.\n\n## Applicability questions\n\n- Which human accounts are candidates, and are any service or computer identities mixed into the list?\n\n- Do candidate accounts have AES keys and reach domain controllers that meet the documented prerequisites?\n\n- Which applications, scripts, remote tools, file services, or devices still require NTLM or delegation?\n\n- Does any approved work require cached offline sign-in?\n\n- Which independently protected account can reverse membership if a test user is locked out?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\n- Export current membership and assign an owner for every proposed addition and exception.\n\n- Trace representative sign-ins and administrative tasks to find NTLM, delegation, RC4, offline, and cached-credential dependencies.\n\n- Confirm domain, controller, workstation, and AES prerequisites before changing membership.\n\n- Enable the documented authentication logs on pilot systems and forward relevant events to protected monitoring.\n\n- 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.\n\n- Expand in small waves with a defined rollback operator who is not dependent on the account being changed.\n\n## Verification and evidence\n\n- Preserve approved membership changes and their owners.\n\n- Capture successful Kerberos ticket events and investigated failure events.\n\n- Prove required administration paths work without NTLM, RC4, or disallowed delegation.\n\n- Test removal from the group and restoration of required access.\n\n- Record unresolved dependencies, exceptions, and their retirement dates.\n\n## Official references\n\n- [Protected Users security group](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group) — Microsoft" }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/", "url": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-25" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Pilot the Active Directory Protected Users group before placing privileged accounts inside it", "item": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/#article", "identifier": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/", "url": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/", "headline": "Pilot the Active Directory Protected Users group before placing privileged accounts inside it", "description": "Protected Users applies nonconfigurable credential protections that can also break NTLM, delegation, offline sign-in, and other dependencies. Prove…", "abstract": "Protected Users applies nonconfigurable credential protections that can also break NTLM, delegation, offline sign-in, and other dependencies. Prove each account's authentication paths before membership expands.", "articleBody": "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.\nSource fact: what Microsoft documents\nMicrosoft’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.\nAt 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.\nMicrosoft 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.\nThe 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.\nWhat the source does not establish\nGroup 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.\nApplicability questions\n\nWhich human accounts are candidates, and are any service or computer identities mixed into the list?\nDo candidate accounts have AES keys and reach domain controllers that meet the documented prerequisites?\nWhich applications, scripts, remote tools, file services, or devices still require NTLM or delegation?\nDoes any approved work require cached offline sign-in?\nWhich independently protected account can reverse membership if a test user is locked out?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nExport current membership and assign an owner for every proposed addition and exception.\nTrace representative sign-ins and administrative tasks to find NTLM, delegation, RC4, offline, and cached-credential dependencies.\nConfirm domain, controller, workstation, and AES prerequisites before changing membership.\nEnable the documented authentication logs on pilot systems and forward relevant events to protected monitoring.\nAdd one recoverable test account, then exercise local, remote, delegated, and emergency workflows. Remove the account if a required dependency fails and document the result.\nExpand in small waves with a defined rollback operator who is not dependent on the account being changed.\n\nVerification and evidence\n\nPreserve approved membership changes and their owners.\nCapture successful Kerberos ticket events and investigated failure events.\nProve required administration paths work without NTLM, RC4, or disallowed delegation.\nTest removal from the group and restoration of required access.\nRecord unresolved dependencies, exceptions, and their retirement dates.\n\nOfficial references\n\nProtected Users security group — Microsoft", "datePublished": "2026-08-25T21:35:10+00:00", "dateModified": "2026-08-25T21:43:55+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Pilot the Active Directory Protected Users group before placing privileged accounts inside it" }, "articleSection": [ "Cybersecurity", "IT", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "IT", "Microsoft 365 & Identity", "Guide", "Important priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 573, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Protected Users security group", "url": "https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group" } } ] } }