Protected Users and protected accounts
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/windowsserverdocs · commit 2b47373 · +23 −17 lines · also on GitHub
⋯ 3 unchanged lines
44
title: Guidance about how to configure protected accounts
55
author: robinharwood
66
ms.author: roharwoo
7
−manager: daveba
8
−ms.date: 05/12/2025
7
+ms.date: 07/09/2025
98
ms.topic: how-to
109
---
1110
1211
# Guidance about how to configure protected accounts
1312
14
−Through Pass-the-hash (PtH) attacks, an attacker can authenticate to a remote server or service by using the underlying NTLM hash of a user's password (or other credential derivatives). Microsoft has previously [published guidance](https://www.microsoft.com/download/details.aspx?id=36036) to mitigate pass-the-hash attacks. Windows Server 2012 R2 includes new features to help mitigate such attacks further. For more information about other security features that help protect against credential theft, see [Credentials Protection and Management](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn408190(v=ws.11)). This topic explains how to configure the following new features:
13
+Through Pass-the-hash (PtH) attacks, an attacker can authenticate to a remote server or service by using the underlying NTLM hash of a user's password (or other credential derivatives). Microsoft has previously [published guidance](https://www.microsoft.com/download/details.aspx?id=36036) to mitigate pass-the-hash attacks. Windows Server 2012 R2 includes new features to help mitigate such attacks further. For more information about other security features that help protect against credential theft, see [Credentials Protection and Management](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn408190(v=ws.11)). This article explains how to configure the following new features:
1514
1615
- [Protected Users](../../ad-ds/manage/How-to-Configure-Protected-Accounts.md#BKMK_AddtoProtectedUsers)
1716
⋯ 1 unchanged line
1918
2019
- [Authentication policy silos](../../ad-ds/manage/How-to-Configure-Protected-Accounts.md#BKMK_CreateAuthNPolicySilos)
2120
22
−There are additional mitigations built in to Windows 8.1 and Windows Server 2012 R2 to help protect against credential theft, which are covered in the following topics:
21
+There are additional mitigations built in to Windows 8.1 and Windows Server 2012 R2 to help protect against credential theft, which are covered in the following articles:
2322
2423
- [Restricted Admin mode for Remote Desktop](/archive/blogs/kfalde/restricted-admin-mode-for-rdp-in-windows-8-1-2012-r2)
2524
⋯ 14 unchanged lines
4039
4140
- Sign-on offline - the cached logon verifier is not created
4241
43
−If the domain functional level is Windows Server 2012 R2 , members of the group can no longer:
42
+If the domain functional level is Windows Server 2012 R2, members of the group can no longer:
4443
4544
- Authenticate by using NTLM authentication
4645
⋯ 19 unchanged lines
6665
### <a name="BKMK_Prereq"></a>Requirements for using protected accounts
6766
Protected accounts have the following deployment requirements:
6867
69
−- To provide client-side restrictions for Protected Users, hosts must run Windows 8.1 or Windows Server 2012 R2 . A user only has to sign-on with an account that is a member of a Protected Users group. In this case, the Protected Users group can be created by [transferring the primary domain controller (PDC) emulator role](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc816944(v=ws.10)) to a domain controller that runs Windows Server 2012 R2 . After that group object is replicated to other domain controllers, the PDC emulator role can be hosted on a domain controller that runs an earlier version of Windows Server.
68
+- To provide client-side restrictions for Protected Users, hosts must run Windows 8.1 or Windows Server 2012 R2. A user only has to sign-on with an account that is a member of a Protected Users group. In this case, the Protected Users group can be created by [transferring the primary domain controller (PDC) emulator role](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc816944(v=ws.10)) to a domain controller that runs Windows Server 2012 R2. After that group object is replicated to other domain controllers, the PDC emulator role can be hosted on a domain controller that runs an earlier version of Windows Server.
7069
71
−- To provide domain controller-side restrictions for Protected Users, that is to restrict usage of NTLM authentication, and other restrictions, the domain functional level must be Windows Server 2012 R2 . For more information about functional levels, see [Understanding Active Directory Domain Services (AD DS) Functional Levels](../active-directory-functional-levels.md).
70
+- To provide domain controller-side restrictions for Protected Users, that is to restrict usage of NTLM authentication, and other restrictions, the domain functional level must be Windows Server 2012 R2. For more information about functional levels, see [Understanding Active Directory Domain Services (AD DS) Functional Levels](../active-directory-functional-levels.md).
7271
7372
> [!NOTE]
7473
> The builtin domain Administrator (`S-1-5-<domain>-500`) is always exempt from Authentication Policies, even when they are assigned to an Authentication Policy Silo.
⋯ 47 unchanged lines
122121
## <a name="BKMK_CreateAuthNPolicies"></a>Authentication policies
123122
Authentication Policies is a new container in AD DS that contains authentication policy objects. Authentication policies can specify settings that help mitigate exposure to credential theft, such as restricting TGT lifetime for accounts or adding other claims-related conditions.
124123
125
−In Windows Server 2012 , Dynamic Access Control introduced an Active Directory forest-scope object class called Central Access Policy to provide an easy way to configure file servers across an organization. In Windows Server 2012 R2 , a new object class called Authentication Policy (objectClass msDS-AuthNPolicies) can be used to apply authentication configuration to account classes in Windows Server 2012 R2 domains. Active Directory account classes are:
124
+In Windows Server 2012, Dynamic Access Control introduced an Active Directory forest-scope object class called Central Access Policy to provide an easy way to configure file servers across an organization. In Windows Server 2012 R2, a new object class called Authentication Policy (objectClass msDS-AuthNPolicies) can be used to apply authentication configuration to account classes in Windows Server 2012 R2 domains. Active Directory account classes are:
126125
127126
- User
128127
⋯ 33 unchanged lines
162161
163162
You can restrict service ticket requests through a ticket-granting service (TGS) exchange by configuring:
164163
165
−- Access control conditions which must be met by the client (user, service, computer) or device from which the TGS exchange is coming
164
+- Access control conditions that must be met by the client (user, service, computer) or device from which the TGS exchange is coming
166165
167166
### <a name="BKMK_ReqForAuthnPolicies"></a>Requirements for using authentication policies
168167
169168
|Policy|Requirements|
170169
|----------|----------------|
171170
|Provide custom TGT lifetimes| Windows Server 2012 R2 domain functional level account domains|
172
−|Restrict user sign-on|- Windows Server 2012 R2 domain functional level account domains with Dynamic Access Control support<br />- Windows 8, Windows 8.1, Windows Server 2012 or Windows Server 2012 R2 devices with Dynamic Access Control support|
171
+|Restrict user sign-on|- Windows Server 2012 R2 domain functional level account domains with Dynamic Access Control support<br />- Windows 8, Windows 8.1, Windows Server 2012, or Windows Server 2012 R2 devices with Dynamic Access Control support|
173172
|Restrict service ticket issuance that is based on user account and security groups| Windows Server 2012 R2 domain functional level resource domains|
174173
|Restrict service ticket issuance based on user claims or device account, security groups, or claims| Windows Server 2012 R2 domain functional level resource domains with Dynamic Access Control support|
175174
176175
### Restrict a user account to specific devices and hosts
177176
A high-value account with administrative privilege should be a member of the **Protected Users** group. By default, no accounts are members of the **Protected Users** group. Before you add accounts to the group, configure domain controller support and create an audit policy to ensure that there are no blocking issues.
178177
178
+> [!WARNING]
179
+> Authentication policies and silos have some limitations. To maximize their effectiveness and maintain network security, consider these best practices:
180
+>
181
+> - Ensure client machines and domain controllers remain connected to the network at all times.
182
+> - Change the passwords of protected accounts after configuring authentication policies to invalidate any previously cached credentials on client machines.
183
+> - Disable cached logon where possible to further reduce the risk of credential reuse.
184
+
179185
#### Configure domain controller support
180186
181
−The user's account domain must be at Windows Server 2012 R2 domain functional level (DFL). Ensure all the domain controllers are Windows Server 2012 R2 , and then use Active Directory Domains and Trusts to [raise the DFL](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753104(v=ws.11)) to Windows Server 2012 R2 .
187
+The user's account domain must be at Windows Server 2012 R2 domain functional level (DFL). Ensure all the domain controllers are Windows Server 2012 R2, and then use Active Directory Domains and Trusts to [raise the DFL](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753104(v=ws.11)) to Windows Server 2012 R2.
182188
183189
**To configure support for Dynamic Access Control**
184190
⋯ 4 unchanged lines
189195
2. Under **Options**, in the drop-down list box, select **Always provide claims**.
190196
191197
> [!NOTE]
192
− > **Supported** can also be configured, but because the domain is at Windows Server 2012 R2 DFL, having the DCs always provide claims will allow user claims-based access checks to occur when using non-claims aware devices and hosts to connect to claims-aware services.
198
+ > **Supported** can also be configured, but because the domain is at Windows Server 2012 R2 DFL, having the DCs always provide claims allows user claims-based access checks to occur when using non-claims aware devices and hosts to connect to claims-aware services.
193199
194200
195201
196202
> [!WARNING]
197
− > Configuring **Fail unarmored authentication requests** will result in authentication failures from any operating system which does not support Kerberos armoring, such as Windows 7 and previous operating systems, or operating systems beginning with Windows 8, which have not been explicitly configured to support it.
203
+ > Configuring **Fail unarmored authentication requests** results in authentication failures from any operating system that does not support Kerberos armoring, such as Windows 7 and previous operating systems, or operating systems beginning with Windows 8, which have not been explicitly configured to support it.
198204
199205
#### Create a user account audit for authentication policy with ADAC
200206
⋯ 2 unchanged lines
203209
204210
205211
> [!NOTE]
206
− > The selected **Authentication** node is visible for domains which are at Windows Server 2012 R2 DFL. If the node does not appear, then try again by using a domain administrator account from a domain that is at Windows Server 2012 R2 DFL.
212
+ > The selected **Authentication** node is visible for domains that are at the Windows Server 2012 R2 DFL. If the node does not appear, then try again by using a domain administrator account from a domain that is at Windows Server 2012 R2 DFL.
207213
208214
2. Click **Authentication Policies**, and then click **New** to create a new policy.
209215
⋯ 60 unchanged lines
270276
271277
272278
273
−7. When done, then click **OK** and the defined conditions will appear for the computer account.
279
+7. When done, then click **OK** and the defined conditions appear for the computer account.
274280
275281
276282
⋯ 9 unchanged lines
286292
287293
288294
289
−3. When done, then click OK and the box will show the conditions defined.
295
+3. When done, then click OK and the box shows the conditions defined.
290296
291297
292298
⋯ 37 unchanged lines
330336
331337
332338
#### Use the Authentication Policy Failures - Domain Controller administrative log
333
−A new **Authentication Policy Failures - Domain Controller** administrative log under **Applications and Services Logs** > **Microsoft** > **Windows** > **Authentication** has been created to make it easier to discover failures due to Authentication Policies. The log is disabled by default. To enable it, right-click the log name and click **Enable Log**. The new events are very similar in content to the existing Kerberos TGT and service ticket auditing events. For more information about these events, see [Authentication Policies and Authentication Policy Silos](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn486813(v=ws.11)).
339
+A new **Authentication Policy Failures - Domain Controller** administrative log under **Applications and Services Logs** > **Microsoft** > **Windows** > **Authentication** has been created to make it easier to discover failures due to Authentication Policies. The log is disabled by default. To enable it, right-click the log name and click **Enable Log**. The new events are similar in content to the existing Kerberos TGT and service ticket auditing events. For more information about these events, see [Authentication Policies and Authentication Policy Silos](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn486813(v=ws.11)).
334340
335341
### <a name="BKMK_ManageAuthnPoliciesUsingPSH"></a>Manage authentication policies by using Windows PowerShell
336342
This command creates an authentication policy named **TestAuthenticationPolicy**. The **UserAllowedToAuthenticateFrom** parameter specifies the devices from which users can authenticate by an SDDL string in the file named someFile.txt.
⋯ 130 unchanged lines
Microsoft's Markdown source from MicrosoftDocs/windowsserverdocs, © Microsoft Corporation, under CC BY 4.0. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 09:08 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.