{
	"id": "ba54fa2c-70df-4b0a-9cfc-91f126396563",
	"created_at": "2026-04-06T01:32:08.589168Z",
	"updated_at": "2026-04-10T13:11:20.016968Z",
	"deleted_at": null,
	"sha1_hash": "697d474c3743e7201019cd3ca36b5ba630b4800e",
	"title": "Protected Users Security Group in Windows Server",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 56026,
	"plain_text": "Protected Users Security Group in Windows Server\r\nBy robinharwood\r\nArchived: 2026-04-06 01:00:23 UTC\r\nProtected Users is a global security group for Active Directory that's designed to protect against credential theft\r\nattacks. The group triggers nonconfigurable protection on devices and host computers to prevent credentials from\r\nbeing cached when group members sign in.\r\nYour system must meet the following prerequisites before you can deploy a Protected Users group:\r\nHosts must be running one of the following operating systems:\r\nWindows 10 or Windows 11\r\nWindows Server 2012 R2 or later with the most recent security updates installed\r\nThe domain functional level must be Windows Server 2012 R2 or later. For more information about\r\nfunctional levels, see Forest and domain functional levels.\r\nNote\r\nThe built-in domain Administrator, S-1-5-\u003cdomain\u003e-500 , is always exempt from authentication policies, even\r\nwhen they're assigned to an authentication policy silo. For more information, see How to Configure Protected\r\nAccounts.\r\nProtected Users global security group memberships restrict members to only use Advanced Encryption\r\nStandard (AES) for Kerberos. Members of the Protected Users group must be able to authenticate by using\r\nAES.\r\nBecoming a member of the Protected Users group means Active Directory automatically applies certain\r\npreconfigured controls that the users won't be able to change unless they stop being group members.\r\nWhen the signed in user is a member of the Protected Users group, the group provides the following protections:\r\nCredential delegation (CredSSP) doesn't cache the user's plain text credentials even when the user enables\r\nthe Allow delegating default credentials Group Policy setting.\r\nWindows Digest doesn't cache the user's plaintext credentials even when they've enabled Windows Digest.\r\nNTLM stops caching the user's plaintext credentials or NT one-way function (NTOWF).\r\nKerberos stops creating Data Encryption Standard (DES) or RC4 keys. Kerberos also doesn't cache the\r\nuser's plaintext credentials, or long-term keys after acquiring the initial Ticket Granting Ticket (TGT).\r\nThe system doesn't create a cached verifier at user sign-in or unlock, so member systems no longer support\r\noffline sign-in.\r\nhttps://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group\r\nPage 1 of 5\n\nAfter you add a new user account to the Protected Users group, these protections activate when the new Protected\r\nUser signs in to their device.\r\nProtected User accounts that authenticate to a domain running Windows Server are unable to do the following:\r\nAuthenticate with NTLM authentication.\r\nUse DES or RC4 encryption types in Kerberos preauthentication.\r\nDelegate with unconstrained or constrained delegation.\r\nRenew Kerberos TGTs beyond their initial four-hour lifetime.\r\nThe Protected Users group applies nonconfigurable settings to TGT expiration for every member account.\r\nNormally, the domain controller sets the TGT lifetime and renewal based on the following two domain policies:\r\nMaximum lifetime for user ticket\r\nMaximum lifetime for user ticket renewal\r\nFor Protected Users members, the group automatically sets these lifetime limits to 240 minutes. The user can't\r\nchange this limit unless they leave the group.\r\nYou can add users to the Protected Users group by using the following methods:\r\nUI tools, such as Active Directory Administrative Center or Active Directory Users and Computers.\r\nPowerShell, by using the Add-ADGroupMember cmdlet.\r\nImportant\r\nNever add accounts for services and computers to the Protected Users group. For those accounts,\r\nmembership doesn't provide local protections because the password and certificate is always available on\r\nthe host.\r\nDon't add accounts that are already members of highly privileged groups, such as the Enterprise Admins or\r\nDomain Admins groups, until you can guarantee that adding them won't have negative consequences.\r\nHighly privileged users in Protected Users are subject to the same limitations and restrictions as regular\r\nusers, and it's not possible to work around or change those settings. If you add all members of those groups\r\nto the Protected Users group, it's possible to accidentally lock out their accounts. It's important to test your\r\nsystem to make sure the mandatory setting changes won't interfere with account access for these privileged\r\nuser groups.\r\nMembers of the Protected Users group can only authenticate using Kerberos with AES. This method requires AES\r\nkeys for the account in Active Directory. The built-in Administrator doesn't have an AES key unless the password\r\nfor the domain running Windows Server 2008 or later changes. Any account that has its password changed by a\r\ndomain controller running an earlier version of Windows Server is locked out of authentication.\r\nTo avoid lockouts and missing AES keys, we recommend that you follow these guidelines:\r\nhttps://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group\r\nPage 2 of 5\n\nDon't run tests in domains unless all domain controllers run Windows Server 2008 or later.\r\nIf you have migrated accounts from other domains, you need to reset the password so the accounts have\r\nAES hashes. Otherwise, these accounts become unable to authenticate.\r\nUsers need to change passwords after switching to a domain functional level of Windows Server 2008 or\r\nlater. Doing so ensures that they have AES password hashes after they become members of the Protected\r\nUsers group.\r\nThe following table specifies the Active Directory properties of the Protected Users group.\r\nAttribute Value\r\nWell-known SID/RID S-1-5-21-\u003cdomain\u003e-525\r\nType Domain Global\r\nDefault container CN=Users, DC=\u003cdomain\u003e, DC=\r\nDefault members None\r\nDefault member of None\r\nProtected by AdminSDHolder? No\r\nSafe to move out of default container? Yes\r\nSafe to delegate management of this group to non-service admins? No\r\nDefault user rights No default user rights\r\nTwo operational administrative logs are available to help troubleshoot events that are related to Protected Users.\r\nThese new logs are located in Event Viewer and are disabled by default. They're located under Applications and\r\nServices Logs\\Microsoft\\Windows\\Authentication.\r\nTo enable capturing these logs:\r\n1. Right-click Start and then select Event Viewer.\r\n2. Open Applications and Services Logs\\Microsoft\\Windows\\Authentication.\r\n3. For each log that you want to enable, right-click the log name and then select Enable Log.\r\nEvent ID and log Description\r\n104\r\nProtectedUser-Client\r\nReason: The security package on the client doesn't contain the credentials.\r\nThe error is logged in the client computer when the account is a member of\r\nthe Protected Users security group. This event indicates that the security\r\nhttps://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group\r\nPage 3 of 5\n\nEvent ID and log Description\r\npackage doesn't cache the credentials that are needed to authenticate to the\r\nserver.\r\nDisplays the package name, user name, domain name, and server name.\r\n304\r\nProtectedUser-Client\r\nReason: The security package doesn't store the protected user's credentials.\r\nAn informational event is logged in the client to indicate that the security\r\npackage doesn't cache the user's sign-in credentials. It's expected that Digest\r\n(WDigest), Credential Delegation (CredSSP), and NTLM fail to have sign-on credentials for Protected Users members. Applications can still succeed if\r\nthey prompt for credentials.\r\nDisplays the package name, user name, and domain name.\r\n100\r\nProtectedUserFailures-DomainController\r\nReason: An NTLM sign-in failure occurs for an account in the Protected\r\nUsers security group.\r\nAn error is logged in the domain controller to indicate that NTLM\r\nauthentication failed because the account was a member of the Protected\r\nUsers security group.\r\nDisplays the account name and device name.\r\n104\r\nProtectedUserFailures-DomainController\r\nReason: DES or RC4 encryption types are used for Kerberos authentication\r\nand a sign-in failure occurs for a user in the Protected Users security group.\r\nKerberos preauthentication failed because DES and RC4 encryption types\r\ncan't be used when the account is a member of the Protected Users security\r\ngroup.\r\n(AES is acceptable.)\r\n303\r\nProtectedUserSuccesses-DomainController\r\nReason: A Kerberos TGT was successfully issued for a member of the\r\nProtected Users group.\r\nCredentials Protection and Management\r\nAuthentication Policies and Authentication Policy Silos\r\nHow to Configure Protected Accounts\r\nhttps://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group\r\nPage 4 of 5\n\nSource: https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group\r\nhttps://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group"
	],
	"report_names": [
		"protected-users-security-group"
	],
	"threat_actors": [],
	"ts_created_at": 1775439128,
	"ts_updated_at": 1775826680,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/697d474c3743e7201019cd3ca36b5ba630b4800e.pdf",
		"text": "https://archive.orkl.eu/697d474c3743e7201019cd3ca36b5ba630b4800e.txt",
		"img": "https://archive.orkl.eu/697d474c3743e7201019cd3ca36b5ba630b4800e.jpg"
	}
}