mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-21 21:33:38 +00:00
updates
This commit is contained in:
Paolo Matarazzo
@ -22,21 +22,21 @@ Kerberos armoring is part of RFC 6113. When a device supports Kerberos armoring,
|
||||
|
||||
**To enable Kerberos armoring for restricting domain users to specific domain-joined devices**
|
||||
|
||||
- Users need to be in domains that are running Windows Server 2012 R2 or higher
|
||||
- All the domain controllers in these domains must be configured to support Kerberos armoring. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**.
|
||||
- All the devices with Windows Defender Credential Guard that the users will be restricted to must be configured to support Kerberos armoring. Enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** Group Policy settings under **Computer Configuration** -> **Administrative Templates** -> **System** -> **Kerberos**.
|
||||
- Users need to be in domains that are running Windows Server 2012 R2 or higher
|
||||
- All the domain controllers in these domains must be configured to support Kerberos armoring. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**.
|
||||
- All the devices with Windows Defender Credential Guard that the users will be restricted to must be configured to support Kerberos armoring. Enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** Group Policy settings under **Computer Configuration** -> **Administrative Templates** -> **System** -> **Kerberos**.
|
||||
|
||||
### Protecting domain-joined device secrets
|
||||
|
||||
Since domain-joined devices also use shared secrets for authentication, attackers can steal those secrets as well. By deploying device certificates with Windows Defender Credential Guard, the private key can be protected. Then authentication policies can require that users sign on to devices that authenticate using those certificates. This prevents shared secrets stolen from the device to be used with stolen user credentials to sign on as the user.
|
||||
|
||||
Domain-joined device certificate authentication has the following requirements:
|
||||
- Devices' accounts are in Windows Server 2012 domain functional level or higher.
|
||||
- All domain controllers in those domains have KDC certificates which satisfy strict KDC validation certificate requirements:
|
||||
- KDC EKU present
|
||||
- DNS domain name matches the DNSName field of the SubjectAltName (SAN) extension
|
||||
- Windows devices have the CA issuing the domain controller certificates in the enterprise store.
|
||||
- A process is established to ensure the identity and trustworthiness of the device in a similar manner as you would establish the identity and trustworthiness of a user before issuing them a smartcard.
|
||||
- Devices' accounts are in Windows Server 2012 domain functional level or higher.
|
||||
- All domain controllers in those domains have KDC certificates which satisfy strict KDC validation certificate requirements:
|
||||
- KDC EKU present
|
||||
- DNS domain name matches the DNSName field of the SubjectAltName (SAN) extension
|
||||
- Windows devices have the CA issuing the domain controller certificates in the enterprise store.
|
||||
- A process is established to ensure the identity and trustworthiness of the device in a similar manner as you would establish the identity and trustworthiness of a user before issuing them a smartcard.
|
||||
|
||||
#### Deploying domain-joined device certificates
|
||||
|
||||
@ -69,54 +69,54 @@ CertReq -EnrollCredGuardCert MachineAuthentication
|
||||
|
||||
> [!NOTE]
|
||||
> You must restart the device after enrolling the machine authentication certificate.
|
||||
|
||||
|
||||
#### How a certificate issuance policy can be used for access control
|
||||
|
||||
Beginning with the Windows Server 2008 R2 domain functional level, domain controllers support for authentication mechanism assurance provides a way to map certificate issuance policy OIDs to universal security groups. Windows Server 2012 domain controllers with claim support can map them to claims. To learn more about authentication mechanism assurance, see [Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd378897(v=ws.10)) on TechNet.
|
||||
|
||||
**To see the issuance policies available**
|
||||
|
||||
- The [get-IssuancePolicy.ps1](#bkmk-getscript) shows all of the issuance policies that are available on the certificate authority.
|
||||
From a Windows PowerShell command prompt, run the following command:
|
||||
- The [get-IssuancePolicy.ps1](#bkmk-getscript) shows all of the issuance policies that are available on the certificate authority.\
|
||||
From a Windows PowerShell command prompt, run the following command:
|
||||
|
||||
```powershell
|
||||
.\get-IssuancePolicy.ps1 –LinkedToGroup:All
|
||||
```
|
||||
```powershell
|
||||
.\get-IssuancePolicy.ps1 -LinkedToGroup:All
|
||||
```
|
||||
|
||||
**To link an issuance policy to a universal security group**
|
||||
|
||||
- The [set-IssuancePolicyToGroupLink.ps1](#bkmk-setscript) creates a Universal security group, creates an organizational unit, and links the issuance policy to that Universal security group.
|
||||
From a Windows PowerShell command prompt, run the following command:
|
||||
- The [set-IssuancePolicyToGroupLink.ps1](#bkmk-setscript) creates a Universal security group, creates an organizational unit, and links the issuance policy to that Universal security group.\
|
||||
From a Windows PowerShell command prompt, run the following command:
|
||||
|
||||
```powershell
|
||||
.\set-IssuancePolicyToGroupLink.ps1 –IssuancePolicyName:"<name of issuance policy>" –groupOU:"<Name of OU to create>" –groupName:”<name of Universal security group to create>"
|
||||
```
|
||||
```powershell
|
||||
.\set-IssuancePolicyToGroupLink.ps1 -IssuancePolicyName:"<name of issuance policy>" -groupOU:"<Name of OU to create>" -groupName:"<name of Universal security group to create>"
|
||||
```
|
||||
|
||||
### Restricting user sign-on
|
||||
|
||||
So we now have completed the following:
|
||||
|
||||
- Created a special certificate issuance policy to identify devices that meet the deployment criteria required for the user to be able to sign on
|
||||
- Mapped that policy to a universal security group or claim
|
||||
- Provided a way for domain controllers to get the device authorization data during user sign-on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies.
|
||||
- Created a special certificate issuance policy to identify devices that meet the deployment criteria required for the user to be able to sign on
|
||||
- Mapped that policy to a universal security group or claim
|
||||
- Provided a way for domain controllers to get the device authorization data during user sign-on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies.
|
||||
|
||||
Authentication policies have the following requirements:
|
||||
- User accounts are in a Windows Server 2012 domain functional level or higher domain.
|
||||
- User accounts are in a Windows Server 2012 domain functional level or higher domain.
|
||||
|
||||
**Creating an authentication policy restricting users to the specific universal security group**
|
||||
|
||||
1. Open Active Directory Administrative Center.
|
||||
2. Click **Authentication**, click **New**, and then click **Authentication Policy**.
|
||||
3. In the **Display name** box, enter a name for this authentication policy.
|
||||
4. Under the **Accounts** heading, click **Add**.
|
||||
5. In the **Select Users, Computers, or Service Accounts** dialog box, type the name of the user account you wish to restrict, and then click **OK**.
|
||||
6. Under the **User Sign On** heading, click the **Edit** button.
|
||||
7. Click **Add a condition**.
|
||||
8. In the **Edit Access Control Conditions** box, ensure that it reads **User** > **Group** > **Member of each** > **Value**, and then click **Add items**.
|
||||
9. In the **Select Users, Computers, or Service Accounts** dialog box, type the name of the universal security group that you created with the set-IssuancePolicyToGroupLink script, and then click **OK**.
|
||||
10. Click **OK** to close the **Edit Access Control Conditions** box.
|
||||
11. Click **OK** to create the authentication policy.
|
||||
12. Close Active Directory Administrative Center.
|
||||
1. Open Active Directory Administrative Center.
|
||||
1. Click **Authentication**, click **New**, and then click **Authentication Policy**.
|
||||
1. In the **Display name** box, enter a name for this authentication policy.
|
||||
1. Under the **Accounts** heading, click **Add**.
|
||||
1. In the **Select Users, Computers, or Service Accounts** dialog box, type the name of the user account you wish to restrict, and then click **OK**.
|
||||
1. Under the **User Sign On** heading, click the **Edit** button.
|
||||
1. Click **Add a condition**.
|
||||
1. In the **Edit Access Control Conditions** box, ensure that it reads **User** > **Group** > **Member of each** > **Value**, and then click **Add items**.
|
||||
1. In the **Select Users, Computers, or Service Accounts** dialog box, type the name of the universal security group that you created with the set-IssuancePolicyToGroupLink script, and then click **OK**.
|
||||
1. Click **OK** to close the **Edit Access Control Conditions** box.
|
||||
1. Click **OK** to create the authentication policy.
|
||||
1. Close Active Directory Administrative Center.
|
||||
|
||||
> [!NOTE]
|
||||
> When the authentication policy enforces policy restrictions, users will not be able to sign on using devices that do not have a certificate with the appropriate issuance policy deployed. This applies to both local and remote sign on scenarios. Therefore, it is strongly recommended to first only audit policy restrictions to ensure you don't have unexpected failures.
|
||||
@ -321,7 +321,7 @@ write-host "There are no issuance policies which are not mapped to groups"
|
||||
```
|
||||
> [!NOTE]
|
||||
> If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
|
||||
|
||||
|
||||
### <a href="" id="bkmk-setscript"></a>Link an issuance policy to a group
|
||||
|
||||
Save the script file as set-IssuancePolicyToGroupLink.ps1.
|
||||
@ -602,4 +602,4 @@ write-host $tmp -Foreground Red
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
|
||||
> If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
|
||||
|
||||
@ -6,7 +6,6 @@ ms.topic: article
|
||||
appliesto:
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
|
||||
ms.technology: itpro-security
|
||||
---
|
||||
|
||||
# Considerations when using Windows Defender Credential Guard
|
||||
@ -87,4 +86,4 @@ When data protected with user DPAPI is unusable, then the user loses access to a
|
||||
|
||||
**Related videos**
|
||||
|
||||
[What is virtualization-based security?](https://www.linkedin.com/learning/microsoft-cybersecurity-stack-advanced-identity-and-endpoint-protection/what-is-virtualization-based-security)
|
||||
[What is virtualization-based security?](https://www.linkedin.com/learning/microsoft-cybersecurity-stack-advanced-identity-and-endpoint-protection/what-is-virtualization-based-security)
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
---
|
||||
title: How Windows Defender Credential Guard works
|
||||
description: Learn how Windows Defender Credential Guard uses virtualization to protect secrets, so that only privileged system software can access them.
|
||||
ms.topic: article
|
||||
ms.date: 08/17/2017
|
||||
ms.topic: conceptual
|
||||
appliesto:
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
|
||||
ms.technology: itpro-security
|
||||
---
|
||||
|
||||
# How Windows Defender Credential Guard works
|
||||
|
||||
@ -1,56 +1,68 @@
|
||||
---
|
||||
title: Windows Defender Credential Guard - Known issues (Windows)
|
||||
title: Windows Defender Credential Guard - Known issues
|
||||
description: Windows Defender Credential Guard - Known issues in Windows Enterprise
|
||||
ms.date: 01/26/2022
|
||||
ms.topic: article
|
||||
ms.date: 11/28/2022
|
||||
appliesto:
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
|
||||
ms.technology: itpro-security
|
||||
---
|
||||
# Windows Defender Credential Guard: Known issues
|
||||
|
||||
Windows Defender Credential Guard has certain application requirements. Windows Defender Credential Guard blocks specific authentication capabilities. So applications that require such capabilities won't function when it's enabled. For more information, see [Application requirements](credential-guard-requirements.md#application-requirements).
|
||||
|
||||
The following known issues have been fixed in the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4):
|
||||
## Known Issue: Single Sign-On (SSO) for Network services breaks after upgrading to **Windows 11, version 22H2**
|
||||
|
||||
- Scheduled tasks with domain user-stored credentials fail to run when Credential Guard is enabled. The task fails and reports Event ID 104 with the following message:
|
||||
### Symptoms of the issue:
|
||||
Devices that use 802.1x wireless or wired network, RDP, or VPN connections that rely on insecure protocols with password-based authentication will be unable to use SSO to log in and will be forced to manually re-authenticate in every new Windows session when Windows Defender Credential Guard is running.
|
||||
|
||||
```console
|
||||
Task Scheduler failed to log on '\Test'.
|
||||
Failure occurred in 'LogonUserExEx'.
|
||||
User Action: Ensure the credentials for the task are correctly specified.
|
||||
Additional Data: Error Value: 2147943726. 2147943726: ERROR\_LOGON\_FAILURE (The user name or password is incorrect).
|
||||
```
|
||||
### Affected devices:
|
||||
Any device that enables Windows Defender Credential Guard may encounter this issue. As part of the Windows 11, version 22H2 update, eligible devices which had not previously explicitly disabled Windows Defender Credential Guard had it enabled by default. This affected all devices on Enterprise (E3 and E5) and Education licenses, as well as some Pro licenses*, as long as they met the [minimum hardware requirements](credential-guard-requirements.md#hardware-and-software-requirements).
|
||||
|
||||
\* All Pro devices which previously ran Windows Defender Credential Guard on an eligible license and later downgraded to Pro, and which still meet the [minimum hardware requirements](credential-guard-requirements.md#hardware-and-software-requirements), will receive default enablement.
|
||||
|
||||
- When you enable NTLM audit on the domain controller, an Event ID 8004 with an indecipherable username format is logged. You also get a similar user name in a user logon failure event 4625 with error 0xC0000064 on the machine itself. For example:
|
||||
> [!TIP]
|
||||
> To determine if your Pro device will receive default enablement when upgraded to **Windows 11, version 22H2**, do the following **before** upgrading:
|
||||
> Check if the registry key `IsolatedCredentialsRootSecret` is present in `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0`. If it is present, the device will have Windows Defender Credential Guard enabled after upgrading. Note that Windows Defender Credential Guard can be disabled after upgrade by following the [disablement instructions](credential-guard-manage.md#disable-windows-defender-credential-guard).
|
||||
|
||||
```console
|
||||
Log Name: Microsoft-Windows-NTLM/Operational
|
||||
Source: Microsoft-Windows-Security-Netlogon
|
||||
Event ID: 8004
|
||||
Task Category: Auditing NTLM
|
||||
Level: Information
|
||||
Description:
|
||||
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
|
||||
Secure Channel name: <Secure Channel Name>
|
||||
User name:
|
||||
@@CyBAAAAUBQYAMHArBwUAMGAoBQZAQGA1BAbAUGAyBgOAQFAhBwcAsGA6AweAgDA2AQQAMEAwAANAgDA1AQLAIEADBQRAADAtAANAYEA1AwQA0CA5AAOAMEAyAQLAYDAxAwQAEDAEBwMAMEAwAgMAMDACBgRA0HA
|
||||
Domain name: NULL
|
||||
```
|
||||
### Why this is happening:
|
||||
Applications and services are affected by this issue when they rely on insecure protocols that use password-based authentication. Windows Defender Credential Guard blocks the use of these insecure protocols by design. These protocols are considered insecure because they can lead to password disclosure on the client and the server, which is in direct contradiction to the goals of Windows Defender Credential Guard. Affected procols include:
|
||||
- Kerberos unconstrained delegation (both SSO and supplied credentials are blocked)
|
||||
- Kerberos when PKINIT uses RSA encryption instead of Diffie-Hellman (both SSO and supplied credentials are blocked)
|
||||
- MS-CHAP (only SSO is blocked)
|
||||
- WDigest (only SSO is blocked)
|
||||
- NTLM v1 (only SSO is blocked)
|
||||
|
||||
Since only SSO is blocked for MS-CHAP, WDigest, and NTLM v1, these protocols can still be used by prompting the user to supply credentials.
|
||||
|
||||
- This event stems from a scheduled task running under local user context with the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4) or later and happens when Credential Guard is enabled.
|
||||
- The username appears in an unusual format because local accounts aren't protected by Credential Guard. The task also fails to execute.
|
||||
- As a workaround, run the scheduled task under a domain user or the computer's SYSTEM account.
|
||||
> [!NOTE]
|
||||
> MS-CHAP and NTLMv1 are particularly relevant to the observed SSO breakage after the Windows 11, version 22H2 update. To confirm whether Windows Defender Credential Guard is blocking either of these protocols, check the NTLM event logs in Event Viewer at `Application and Services Logs\Microsoft\Windows\NTLM\Operational` for the following warning and/or error:
|
||||
>
|
||||
> **Event ID 4013** (Warning)
|
||||
> ```
|
||||
> <string
|
||||
> id="NTLMv1BlockedByCredGuard"
|
||||
> value="Attempt to use NTLMv1 failed.
|
||||
> Target server: %1%nSupplied user: %2%nSupplied domain: %3%nPID of client process: %4%nName of client process: %5%nLUID of client process: %6%nUser identity of client process: %7%nDomain name of user identity of client process: %8%nMechanism OID: %9%n%nThis device does not support NTLMv1. For more information, see https://go.microsoft.com/fwlink/?linkid=856826."
|
||||
> />
|
||||
> ```
|
||||
>
|
||||
> **Event ID 4014** (Error)
|
||||
> ```
|
||||
> <string
|
||||
> id="NTLMGetCredentialKeyBlockedByCredGuard"
|
||||
> value="Attempt to get credential key by call package blocked by Credential Guard.%n%nCalling Process Name: %1%nService Host Tag: %2"
|
||||
> />
|
||||
> ```
|
||||
|
||||
The following known issues have been fixed by servicing releases made available in the Cumulative Security Updates for April 2017:
|
||||
### Options to fix the issue:
|
||||
|
||||
- [KB4015217 Windows Defender Credential Guard generates double bad password count on Active Directory domain-joined Windows machines](https://support.microsoft.com/topic/april-11-2017-kb4015217-os-build-14393-1066-and-14393-1083-b5f79067-98bd-b4ec-8b81-5d858d7dc722)
|
||||
Microsoft recommends that organizations move away from MSCHAPv2-based connections such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, to certificate-based authentication such as PEAP-TLS or EAP-TLS. Windows Defender Credential Guard will not block certificate-based authentication.
|
||||
|
||||
This issue can potentially lead to unexpected account lockouts. For more information, see the following support articles:
|
||||
For a more immediate but less secure fix, [disable Windows Defender Credential Guard](credential-guard-manage.md#disable-windows-defender-credential-guard). Note that Windows Defender Credential Guard does not have per-protocol or per-application policies, and must either be completely on or off. Disabling Windows Defender Credential Guard will leave some stored domain credentials vulnerable to theft. Windows Defender Credential Guard can be disabled after it has already been enabled, or it can be explicitly disabled prior to updating to Windows 11, version 22H2, which will prevent default enablement from occurring.
|
||||
|
||||
- [KB4015219](https://support.microsoft.com/topic/april-11-2017-kb4015219-os-build-10586-873-68b8e379-aafa-ea6c-6b29-56d19785e657)
|
||||
- [KB4015221](https://support.microsoft.com/topic/april-11-2017-kb4015221-os-build-10240-17354-743f52bc-a484-d23f-71f5-b9957cbae0e6)
|
||||
> [!TIP]
|
||||
> To _prevent_ default enablement, [use Group Policy to explicitly disable Windows Defender Credential Guard](credential-guard-manage.md#disabling-windows-defender-credential-guard-using-group-policy) before updating to Windows 11, version 22H2. If the GPO value is not configured (which is the default state), the device will receive default enablement after updating, if eligible. If the GPO value is set to "disabled", it will not be enabled after updating. This process can also be done via Mobile Device Management (MDM) policy rather than Group Policy if the devices are currently being managed by MDM.
|
||||
|
||||
## Known issues involving third-party applications
|
||||
|
||||
@ -102,3 +114,45 @@ Windows Defender Credential Guard isn't supported by the following products, pro
|
||||
This list isn't comprehensive. Check whether your product vendor, product version, or computer system supports Windows Defender Credential Guard on systems that run Windows or specific versions of Windows. Specific computer system models may be incompatible with Windows Defender Credential Guard.
|
||||
|
||||
Microsoft encourages third-party vendors to contribute to this page by providing relevant product support information and by adding links to their own product support statements.
|
||||
|
||||
## Previous known issues that have been fixed
|
||||
|
||||
The following known issues have been fixed in the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4):
|
||||
|
||||
- Scheduled tasks with domain user-stored credentials fail to run when Credential Guard is enabled. The task fails and reports Event ID 104 with the following message:
|
||||
|
||||
```console
|
||||
Task Scheduler failed to log on '\Test'.
|
||||
Failure occurred in 'LogonUserExEx'.
|
||||
User Action: Ensure the credentials for the task are correctly specified.
|
||||
Additional Data: Error Value: 2147943726. 2147943726: ERROR\_LOGON\_FAILURE (The user name or password is incorrect).
|
||||
```
|
||||
|
||||
- When you enable NTLM audit on the domain controller, an Event ID 8004 with an indecipherable username format is logged. You also get a similar user name in a user logon failure event 4625 with error 0xC0000064 on the machine itself. For example:
|
||||
|
||||
```console
|
||||
Log Name: Microsoft-Windows-NTLM/Operational
|
||||
Source: Microsoft-Windows-Security-Netlogon
|
||||
Event ID: 8004
|
||||
Task Category: Auditing NTLM
|
||||
Level: Information
|
||||
Description:
|
||||
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
|
||||
Secure Channel name: <Secure Channel Name>
|
||||
User name:
|
||||
@@CyBAAAAUBQYAMHArBwUAMGAoBQZAQGA1BAbAUGAyBgOAQFAhBwcAsGA6AweAgDA2AQQAMEAwAANAgDA1AQLAIEADBQRAADAtAANAYEA1AwQA0CA5AAOAMEAyAQLAYDAxAwQAEDAEBwMAMEAwAgMAMDACBgRA0HA
|
||||
Domain name: NULL
|
||||
```
|
||||
|
||||
- This event stems from a scheduled task running under local user context with the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4) or later and happens when Credential Guard is enabled.
|
||||
- The username appears in an unusual format because local accounts aren't protected by Credential Guard. The task also fails to execute.
|
||||
- As a workaround, run the scheduled task under a domain user or the computer's SYSTEM account.
|
||||
|
||||
The following known issues have been fixed by servicing releases made available in the Cumulative Security Updates for April 2017:
|
||||
|
||||
- [KB4015217 Windows Defender Credential Guard generates double bad password count on Active Directory domain-joined Windows machines](https://support.microsoft.com/topic/april-11-2017-kb4015217-os-build-14393-1066-and-14393-1083-b5f79067-98bd-b4ec-8b81-5d858d7dc722)
|
||||
|
||||
This issue can potentially lead to unexpected account lockouts. For more information, see the following support articles:
|
||||
|
||||
- [KB4015219](https://support.microsoft.com/topic/april-11-2017-kb4015219-os-build-10586-873-68b8e379-aafa-ea6c-6b29-56d19785e657)
|
||||
- [KB4015221](https://support.microsoft.com/topic/april-11-2017-kb4015221-os-build-10240-17354-743f52bc-a484-d23f-71f5-b9957cbae0e6)
|
||||
|
||||
@ -8,13 +8,15 @@ ms.topic: article
|
||||
appliesto:
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
|
||||
ms.technology: itpro-security
|
||||
---
|
||||
|
||||
# Manage Windows Defender Credential Guard
|
||||
|
||||
## Default Enablement
|
||||
|
||||
Starting in **Windows 11 Enterprise, version 22H2** and **Windows 11 Education, version 22H2**, compatible systems have Windows Defender Credential Guard turned on by default. This feature changes the default state of the feature in Windows, though system administrators can still modify this enablement state. Windows Defender Credential Guard can still be manually [enabled](#enable-windows-defender-credential-guard) or [disabled](#disable-windows-defender-credential-guard) via the methods documented below.
|
||||
Starting in **Windows 11 Enterprise, version 22H2** and **Windows 11 Education, version 22H2**, compatible systems have Windows Defender Credential Guard turned on by default. This feature changes the default state of the feature in Windows, though system administrators can still modify this enablement state. Windows Defender Credential Guard can still be manually [enabled](#enable-windows-defender-credential-guard) or [disabled](#disable-windows-defender-credential-guard) via the methods documented below.
|
||||
|
||||
Known issues arising from default enablement are documented in [Windows Defender Credential Guard: Known issues](credential-guard-known-issues.md#known-issue-single-sign-on-sso-for-network-services-breaks-after-upgrading-to-windows-11-version-22h2).
|
||||
|
||||
### Requirements for automatic enablement
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
---
|
||||
title: Windows Defender Credential Guard protection limits & mitigations (Windows)
|
||||
description: Scenarios not protected by Windows Defender Credential Guard in Windows, and additional mitigations you can use.
|
||||
ms.date: 08/17/2017
|
||||
ms.topic: article
|
||||
ms.date: 08/17/2017
|
||||
appliesto:
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
|
||||
@ -15,16 +15,16 @@ in the Deep Dive into Windows Defender Credential Guard video series.
|
||||
|
||||
Some ways to store credentials are not protected by Windows Defender Credential Guard, including:
|
||||
|
||||
- Software that manages credentials outside of Windows feature protection
|
||||
- Local accounts and Microsoft Accounts
|
||||
- Windows Defender Credential Guard does not protect the Active Directory database running on Windows Server 2016 domain controllers. It also does not protect credential input pipelines, such as Windows Server 2016 servers running Remote Desktop Gateway. If you're using a Windows Server 2016 server as a client PC, it will get the same protection as it would when running Windows 10 Enterprise.
|
||||
- Key loggers
|
||||
- Physical attacks
|
||||
- Does not prevent an attacker with malware on the PC from using the privileges associated with any credential. We recommend using dedicated PCs for high value accounts, such as IT Pros and users with access to high value assets in your organization.
|
||||
- Third-party security packages
|
||||
- Digest and CredSSP credentials
|
||||
- When Windows Defender Credential Guard is enabled, neither Digest nor CredSSP have access to users' logon credentials. This implies no Single Sign-On use for these protocols.
|
||||
- Supplied credentials for NTLM authentication are not protected. If a user is prompted for and enters credentials for NTLM authentication, these credentials are vulnerable to be read from LSASS memory. Note that these same credentials are vulnerable to key loggers as well.-
|
||||
- Software that manages credentials outside of Windows feature protection
|
||||
- Local accounts and Microsoft Accounts
|
||||
- Windows Defender Credential Guard does not protect the Active Directory database running on Windows Server 2016 domain controllers. It also does not protect credential input pipelines, such as Windows Server 2016 servers running Remote Desktop Gateway. If you're using a Windows Server 2016 server as a client PC, it will get the same protection as it would when running Windows 10 Enterprise.
|
||||
- Key loggers
|
||||
- Physical attacks
|
||||
- Does not prevent an attacker with malware on the PC from using the privileges associated with any credential. We recommend using dedicated PCs for high value accounts, such as IT Pros and users with access to high value assets in your organization.
|
||||
- Third-party security packages
|
||||
- Digest and CredSSP credentials
|
||||
- When Windows Defender Credential Guard is enabled, neither Digest nor CredSSP have access to users' logon credentials. This implies no Single Sign-On use for these protocols.
|
||||
- Supplied credentials for NTLM authentication are not protected. If a user is prompted for and enters credentials for NTLM authentication, these credentials are vulnerable to be read from LSASS memory. Note that these same credentials are vulnerable to key loggers as well.-
|
||||
- When Windows Defender Credential Guard is deployed on a VM, Windows Defender Credential Guard protects secrets from attacks inside the VM. However, it does not provide additional protection from privileged system attacks originating from the host.
|
||||
- Windows logon cached password verifiers (commonly called "cached credentials")
|
||||
do not qualify as credentials because they cannot be presented to another computer for authentication, and can only be used locally to verify credentials. They are stored in the registry on the local computer and provide validation for credentials when a domain-joined computer cannot connect to AD DS during user logon. These “cached logons”, or more specifically, cached domain account information, can be managed using the security policy setting **Interactive logon: Number of previous logons to cache** if a domain controller is not available.
|
||||
@ -43,21 +43,21 @@ Kerberos armoring is part of RFC 6113. When a device supports Kerberos armoring,
|
||||
|
||||
**To enable Kerberos armoring for restricting domain users to specific domain-joined devices**
|
||||
|
||||
- Users need to be in domains that are running Windows Server 2012 R2 or higher
|
||||
- All the domain controllers in these domains must be configured to support Kerberos armoring. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**.
|
||||
- All the devices with Windows Defender Credential Guard that the users will be restricted to must be configured to support Kerberos armoring. Enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** Group Policy settings under **Computer Configuration** -> **Administrative Templates** -> **System** -> **Kerberos**.
|
||||
- Users need to be in domains that are running Windows Server 2012 R2 or higher
|
||||
- All the domain controllers in these domains must be configured to support Kerberos armoring. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**.
|
||||
- All the devices with Windows Defender Credential Guard that the users will be restricted to must be configured to support Kerberos armoring. Enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** Group Policy settings under **Computer Configuration** -> **Administrative Templates** -> **System** -> **Kerberos**.
|
||||
|
||||
#### Protecting domain-joined device secrets
|
||||
|
||||
Since domain-joined devices also use shared secrets for authentication, attackers can steal those secrets as well. By deploying device certificates with Windows Defender Credential Guard, the private key can be protected. Then authentication policies can require that users sign on devices that authenticate using those certificates. This prevents shared secrets stolen from the device to be used with stolen user credentials to sign on as the user.
|
||||
|
||||
Domain-joined device certificate authentication has the following requirements:
|
||||
- Devices' accounts are in Windows Server 2012 domain functional level or higher.
|
||||
- All domain controllers in those domains have KDC certificates which satisfy strict KDC validation certificate requirements:
|
||||
- KDC EKU present
|
||||
- DNS domain name matches the DNSName field of the SubjectAltName (SAN) extension
|
||||
- Windows 10 devices have the CA issuing the domain controller certificates in the enterprise store.
|
||||
- A process is established to ensure the identity and trustworthiness of the device in a similar manner as you would establish the identity and trustworthiness of a user before issuing them a smartcard.
|
||||
- Devices' accounts are in Windows Server 2012 domain functional level or higher.
|
||||
- All domain controllers in those domains have KDC certificates which satisfy strict KDC validation certificate requirements:
|
||||
- KDC EKU present
|
||||
- DNS domain name matches the DNSName field of the SubjectAltName (SAN) extension
|
||||
- Windows 10 devices have the CA issuing the domain controller certificates in the enterprise store.
|
||||
- A process is established to ensure the identity and trustworthiness of the device in a similar manner as you would establish the identity and trustworthiness of a user before issuing them a smartcard.
|
||||
|
||||
##### Deploying domain-joined device certificates
|
||||
|
||||
@ -67,17 +67,17 @@ For example, let's say you wanted to use the High Assurance policy only on these
|
||||
|
||||
**Creating a new certificate template**
|
||||
|
||||
1. From the Certificate Manager console, right-click **Certificate Templates**, and then click **Manage.**
|
||||
2. Right-click **Workstation Authentication**, and then click **Duplicate Template**.
|
||||
3. Right-click the new template, and then click **Properties**.
|
||||
4. On the **Extensions** tab, click **Application Policies**, and then click **Edit**.
|
||||
5. Click **Client Authentication**, and then click **Remove**.
|
||||
6. Add the ID-PKInit-KPClientAuth EKU. Click **Add**, click **New**, and then specify the following values:
|
||||
- Name: Kerberos Client Auth
|
||||
- Object Identifier: 1.3.6.1.5.2.3.4
|
||||
7. On the **Extensions** tab, click **Issuance Policies**, and then click **Edit**.
|
||||
8. Under **Issuance Policies**, click**High Assurance**.
|
||||
9. On the **Subject name** tab, clear the **DNS name** check box, and then select the **User Principal Name (UPN)** check box.
|
||||
1. From the Certificate Manager console, right-click **Certificate Templates**, and then click **Manage.**
|
||||
1. Right-click **Workstation Authentication**, and then click **Duplicate Template**.
|
||||
1. Right-click the new template, and then click **Properties**.
|
||||
1. On the **Extensions** tab, click **Application Policies**, and then click **Edit**.
|
||||
1. Click **Client Authentication**, and then click **Remove**.
|
||||
1. Add the ID-PKInit-KPClientAuth EKU. Click **Add**, click **New**, and then specify the following values:
|
||||
- Name: Kerberos Client Auth
|
||||
- Object Identifier: 1.3.6.1.5.2.3.4
|
||||
1. On the **Extensions** tab, click **Issuance Policies**, and then click **Edit**.
|
||||
1. Under **Issuance Policies**, click**High Assurance**.
|
||||
1. On the **Subject name** tab, clear the **DNS name** check box, and then select the **User Principal Name (UPN)** check box.
|
||||
|
||||
Then on the devices that are running Windows Defender Credential Guard, enroll the devices using the certificate you just created.
|
||||
|
||||
@ -90,15 +90,15 @@ CertReq -EnrollCredGuardCert MachineAuthentication
|
||||
|
||||
> [!NOTE]
|
||||
> You must restart the device after enrolling the machine authentication certificate.
|
||||
|
||||
|
||||
##### How a certificate issuance policy can be used for access control
|
||||
|
||||
Beginning with the Windows Server 2008 R2 domain functional level, domain controllers support for authentication mechanism assurance provides a way to map certificate issuance policy OIDs to universal security groups. Windows Server 2012 domain controllers with claim support can map them to claims. To learn more about authentication mechanism assurance, see [Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd378897(v=ws.10)) on TechNet.
|
||||
|
||||
**To see the issuance policies available**
|
||||
|
||||
- The [get-IssuancePolicy.ps1](#bkmk-getscript) shows all of the issuance policies that are available on the certificate authority.
|
||||
From a Windows PowerShell command prompt, run the following command:
|
||||
- The [get-IssuancePolicy.ps1](#bkmk-getscript) shows all of the issuance policies that are available on the certificate authority.\
|
||||
From a Windows PowerShell command prompt, run the following command:
|
||||
|
||||
```powershell
|
||||
.\get-IssuancePolicy.ps1 –LinkedToGroup:All
|
||||
@ -106,7 +106,7 @@ Beginning with the Windows Server 2008 R2 domain functional level, domain contro
|
||||
|
||||
**To link an issuance policy to a universal security group**
|
||||
|
||||
- The [set-IssuancePolicyToGroupLink.ps1](#bkmk-setscript) creates a Universal security group, creates an organizational unit, and links the issuance policy to that Universal security group.
|
||||
- The [set-IssuancePolicyToGroupLink.ps1](#bkmk-setscript) creates a Universal security group, creates an organizational unit, and links the issuance policy to that Universal security group.
|
||||
From a Windows PowerShell command prompt, run the following command:
|
||||
|
||||
```powershell
|
||||
@ -117,12 +117,12 @@ Beginning with the Windows Server 2008 R2 domain functional level, domain contro
|
||||
|
||||
So we now have completed the following:
|
||||
|
||||
- Created a special certificate issuance policy to identify devices that meet the deployment criteria required for the user to be able to sign on
|
||||
- Mapped that policy to a universal security group or claim
|
||||
- Provided a way for domain controllers to get the device authorization data during user sign-on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies.
|
||||
- Created a special certificate issuance policy to identify devices that meet the deployment criteria required for the user to be able to sign on
|
||||
- Mapped that policy to a universal security group or claim
|
||||
- Provided a way for domain controllers to get the device authorization data during user sign-on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies.
|
||||
|
||||
Authentication policies have the following requirements:
|
||||
- User accounts are in a Windows Server 2012 domain functional level or higher domain.
|
||||
- User accounts are in a Windows Server 2012 domain functional level or higher domain.
|
||||
|
||||
**Creating an authentication policy restricting users to the specific universal security group**
|
||||
|
||||
@ -346,7 +346,7 @@ write-host "There are no issuance policies which are not mapped to groups"
|
||||
```
|
||||
> [!NOTE]
|
||||
> If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
|
||||
|
||||
|
||||
#### <a href="" id="bkmk-setscript"></a>Link an issuance policy to a group
|
||||
|
||||
Save the script file as set-IssuancePolicyToGroupLink.ps1.
|
||||
@ -633,4 +633,4 @@ write-host $tmp -Foreground Red
|
||||
|
||||
**Deep Dive into Windows Defender Credential Guard: Related videos**
|
||||
|
||||
[Protecting privileged users with Windows Defender Credential Guard](https://mva.microsoft.com/en-us/training-courses/deep-dive-into-credential-guard-16651?l=JNbjYMJyC_8104300474)
|
||||
[Protecting privileged users with Windows Defender Credential Guard](https://mva.microsoft.com/en-us/training-courses/deep-dive-into-credential-guard-16651?l=JNbjYMJyC_8104300474)
|
||||
|
||||
@ -16,11 +16,13 @@ Windows Defender Credential Guard uses virtualization-based security to isolate
|
||||
|
||||
By enabling Windows Defender Credential Guard, the following features and solutions are provided:
|
||||
|
||||
- **Hardware security** NTLM, Kerberos, and Credential Manager take advantage of platform security features, including Secure Boot and virtualization, to protect credentials.
|
||||
- **Virtualization-based security** Windows NTLM and Kerberos derived credentials and other secrets run in a protected environment that is isolated from the running operating system.
|
||||
- **Better protection against advanced persistent threats** When Credential Manager domain credentials, NTLM, and Kerberos derived credentials are protected using virtualization-based security, the credential theft attack techniques and tools used in many targeted attacks are blocked. Malware running in the operating system with administrative privileges cannot extract secrets that are protected by virtualization-based security. While Windows Defender Credential Guard is a powerful mitigation, persistent threat attacks will likely shift to new attack techniques and you should also incorporate other security strategies and architectures.
|
||||
- **Hardware security** NTLM, Kerberos, and Credential Manager take advantage of platform security features, including Secure Boot and virtualization, to protect credentials.
|
||||
- **Virtualization-based security** Windows NTLM and Kerberos derived credentials and other secrets run in a protected environment that is isolated from the running operating system.
|
||||
- **Better protection against advanced persistent threats** When Credential Manager domain credentials, NTLM, and Kerberos derived credentials are protected using virtualization-based security, the credential theft attack techniques and tools used in many targeted attacks are blocked. Malware running in the operating system with administrative privileges cannot extract secrets that are protected by virtualization-based security. While Windows Defender Credential Guard is a powerful mitigation, persistent threat attacks will likely shift to new attack techniques and you should also incorporate other security strategies and architectures.
|
||||
|
||||
> [!NOTE]
|
||||
> As of Windows 11, version 22H2, Windows Defender Credential Guard has been enabled by default on all devices which meet the minimum requirements as specified in the [Default Enablement](credential-guard-manage.md#default-enablement) section. For information about known issues related to default enablement, see [Credential Guard: Known Issues](credential-guard-known-issues.md#known-issue-single-sign-on-sso-for-network-services-breaks-after-upgrading-to-windows-11-version-22h2).
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
- [Protecting network passwords with Windows Defender Credential Guard](https://www.microsoft.com/itshowcase/Article/Content/831/Protecting-network-passwords-with-Windows-10-Credential-Guard)
|
||||
|
||||
@ -1,24 +1,14 @@
|
||||
---
|
||||
title: How User Account Control works (Windows)
|
||||
description: User Account Control (UAC) is a fundamental component of Microsoft's overall security vision. UAC helps mitigate the impact of malware.
|
||||
ms.prod: windows-client
|
||||
author: paolomatarazzo
|
||||
ms.author: paoloma
|
||||
ms.reviewer: sulahiri
|
||||
manager: aaroncz
|
||||
ms.collection:
|
||||
- M365-identity-device-management
|
||||
- highpri
|
||||
ms.topic: article
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 09/23/2021
|
||||
appliesto:
|
||||
- ✅ <b>Windows 10</b>
|
||||
- ✅ <b>Windows 11</b>
|
||||
- ✅ <b>Windows Server 2016</b>
|
||||
- ✅ <b>Windows Server 2019</b>
|
||||
- ✅ <b>Windows Server 2022</b>
|
||||
ms.technology: itpro-security
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
|
||||
---
|
||||
|
||||
# How User Account Control works
|
||||
@ -27,7 +17,7 @@ User Account Control (UAC) is a fundamental component of Microsoft's overall sec
|
||||
|
||||
## UAC process and interactions
|
||||
|
||||
Each app that requires the administrator access token must prompt for consent. The one exception is the relationship that exists between parent and child processes. Child processes inherit the user's access token from the parent process. Both the parent and child processes, however, must have the same integrity level. Windows protects processes by marking their integrity levels. Integrity levels are measurements of trust. A "high" integrity application is one that performs tasks that modify system data, such as a disk partitioning application, while a "low" integrity application is one that performs tasks that could potentially compromise the operating system, such as a Web browser. Apps with lower integrity levels cannot modify data in applications with higher integrity levels. When a standard user attempts to run an app that requires an administrator access token, UAC requires that the user provide valid administrator credentials.
|
||||
Each app that requires the administrator access token must prompt for consent. The one exception is the relationship that exists between parent and child processes. Child processes inherit the user's access token from the parent process. Both the parent and child processes, however, must have the same integrity level. Windows protects processes by marking their integrity levels. Integrity levels are measurements of trust. A "high" integrity application is one that performs tasks that modify system data, such as a disk partitioning application, while a "low" integrity application is one that performs tasks that could potentially compromise the operating system, such as a Web browser. Apps with lower integrity levels cannot modify data in applications with higher integrity levels. When a standard user attempts to run an app that requires an administrator access token, UAC requires that the user provide valid administrator credentials.
|
||||
|
||||
To better understand how this process happens, let's look at the Windows logon process.
|
||||
|
||||
@ -41,17 +31,17 @@ By default, standard users and administrators access resources and run apps in t
|
||||
|
||||
When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token. The standard user access token contains the same user-specific information as the administrator access token, but the administrative Windows privileges and SIDs are removed. The standard user access token is used to start apps that do not perform administrative tasks (standard user apps). The standard user access token is then used to display the desktop (explorer.exe). Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all apps run as a standard user unless a user provides consent or credentials to approve an app to use a full administrative access token.
|
||||
|
||||
A user that is a member of the Administrators group can log on, browse the Web, and read e-mail while using a standard user access token. When the administrator needs to perform a task that requires the administrator access token, Windows 10 or Windows 11 automatically prompts the user for approval. This prompt is called an elevation prompt, and its behavior can be configured by using the Local Security Policy snap-in (Secpol.msc) or Group Policy. For more info, see [User Account Control security policy settings](user-account-control-security-policy-settings.md).
|
||||
A user that is a member of the Administrators group can log on, browse the Web, and read e-mail while using a standard user access token. When the administrator needs to perform a task that requires the administrator access token, Windows automatically prompts the user for approval. This prompt is called an elevation prompt, and its behavior can be configured by using the Local Security Policy snap-in (Secpol.msc) or Group Policy. For more info, see [User Account Control security policy settings](user-account-control-security-policy-settings.md).
|
||||
|
||||
### The UAC User Experience
|
||||
|
||||
When UAC is enabled, the user experience for standard users is different from that of administrators in Admin Approval Mode. The recommended and more secure method of running Windows 10 or Windows 11 is to make your primary user account a standard user account. Running as a standard user helps to maximize security for a managed environment. With the built-in UAC elevation component, standard users can easily perform an administrative task by entering valid credentials for a local administrator account. The default, built-in UAC elevation component for standard users is the credential prompt.
|
||||
When UAC is enabled, the user experience for standard users is different from that of administrators in Admin Approval Mode. The recommended and more secure method of running Windows, is to make your primary user account a standard user account. Running as a standard user helps to maximize security for a managed environment. With the built-in UAC elevation component, standard users can easily perform an administrative task by entering valid credentials for a local administrator account. The default, built-in UAC elevation component for standard users is the credential prompt.
|
||||
|
||||
The alternative to running as a standard user is to run as an administrator in Admin Approval Mode. With the built-in UAC elevation component, members of the local Administrators group can easily perform an administrative task by providing approval. The default, built-in UAC elevation component for an administrator account in Admin Approval Mode is called the consent prompt.
|
||||
|
||||
**The consent and credential prompts**
|
||||
|
||||
With UAC enabled, Windows 10 or Windows 11 prompts for consent or prompts for credentials of a valid local administrator account before starting a program or task that requires a full administrator access token. This prompt ensures that no malicious software can be silently installed.
|
||||
With UAC enabled, Windows prompts for consent or prompts for credentials of a valid local administrator account before starting a program or task that requires a full administrator access token. This prompt ensures that no malicious software can be silently installed.
|
||||
|
||||
**The consent prompt**
|
||||
|
||||
@ -69,14 +59,14 @@ The following is an example of the UAC credential prompt.
|
||||
|
||||
**UAC elevation prompts**
|
||||
|
||||
The UAC elevation prompts are color-coded to be app-specific, enabling for immediate identification of an application's potential security risk. When an app attempts to run with an administrator's full access token, Windows 10 or Windows 11 first analyzes the executable file to determine its publisher. Apps are first separated into three categories based on the file's publisher: Windows 10 or Windows 11, publisher verified (signed), and publisher not verified (unsigned). The following diagram illustrates how Windows determines which color elevation prompt to present to the user.
|
||||
The UAC elevation prompts are color-coded to be app-specific, enabling for immediate identification of an application's potential security risk. When an app attempts to run with an administrator's full access token, Windows first analyzes the executable file to determine its publisher. Apps are first separated into three categories based on the file's publisher: Windows 10 or Windows 11, publisher verified (signed), and publisher not verified (unsigned). The following diagram illustrates how Windows determines which color elevation prompt to present to the user.
|
||||
|
||||
The elevation prompt color-coding is as follows:
|
||||
|
||||
- Red background with a red shield icon: The app is blocked by Group Policy or is from a publisher that is blocked.
|
||||
- Blue background with a blue and gold shield icon: The application is a Windows 10 and Windows 11 administrative app, such as a Control Panel item.
|
||||
- Blue background with a blue shield icon: The application is signed by using Authenticode and is trusted by the local computer.
|
||||
- Yellow background with a yellow shield icon: The application is unsigned or signed but is not yet trusted by the local computer.
|
||||
- Red background with a red shield icon: The app is blocked by Group Policy or is from a publisher that is blocked.
|
||||
- Blue background with a blue and gold shield icon: The application is a Windows 10 and Windows 11 administrative app, such as a Control Panel item.
|
||||
- Blue background with a blue shield icon: The application is signed by using Authenticode and is trusted by the local computer.
|
||||
- Yellow background with a yellow shield icon: The application is unsigned or signed but is not yet trusted by the local computer.
|
||||
|
||||
**Shield icon**
|
||||
|
||||
@ -88,7 +78,7 @@ The shield icon on the **Change date and time** button indicates that the proces
|
||||
|
||||
**Securing the elevation prompt**
|
||||
|
||||
The elevation process is further secured by directing the prompt to the secure desktop. The consent and credential prompts are displayed on the secure desktop by default in Windows 10 and Windows 11. Only Windows processes can access the secure desktop. For higher levels of security, we recommend keeping the **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting enabled.
|
||||
The elevation process is further secured by directing the prompt to the secure desktop. The consent and credential prompts are displayed on the secure desktop by default in Windows 10 and Windows 11. Only Windows processes can access the secure desktop. For higher levels of security, we recommend keeping the **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting enabled.
|
||||
|
||||
When an executable file requests elevation, the interactive desktop, also called the user desktop, is switched to the secure desktop. The secure desktop dims the user desktop and displays an elevation prompt that must be responded to before continuing. When the user clicks **Yes** or **No**, the desktop switches back to the user desktop.
|
||||
|
||||
@ -134,9 +124,9 @@ To better understand each component, review the table below:
|
||||
|
||||
The slider will never turn UAC completely off. If you set it to **Never notify**, it will:
|
||||
|
||||
- Keep the UAC service running.
|
||||
- Cause all elevation request initiated by administrators to be auto-approved without showing a UAC prompt.
|
||||
- Automatically deny all elevation requests for standard users.
|
||||
- Keep the UAC service running.
|
||||
- Cause all elevation request initiated by administrators to be auto-approved without showing a UAC prompt.
|
||||
- Automatically deny all elevation requests for standard users.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> In order to fully disable UAC you must disable the policy **User Account Control: Run all administrators in Admin Approval Mode**.
|
||||
@ -148,17 +138,17 @@ The slider will never turn UAC completely off. If you set it to **Never notify**
|
||||
|
||||
Because system administrators in enterprise environments attempt to secure systems, many line-of-business (LOB) applications are designed to use only a standard user access token. As a result, you do not need to replace the majority of apps when UAC is turned on.
|
||||
|
||||
Windows 10 and Windows 11 include file and registry virtualization technology for apps that are not UAC-compliant and that require an administrator's access token to run correctly. When an administrative apps that is not UAC-compliant attempts to write to a protected folder, such as Program Files, UAC gives the app its own virtualized view of the resource it is attempting to change. The virtualized copy is maintained in the user's profile. This strategy creates a separate copy of the virtualized file for each user that runs the non-compliant app.
|
||||
Windows 10 and Windows 11 include file and registry virtualization technology for apps that are not UAC-compliant and that require an administrator's access token to run correctly. When an administrative apps that is not UAC-compliant attempts to write to a protected folder, such as Program Files, UAC gives the app its own virtualized view of the resource it is attempting to change. The virtualized copy is maintained in the user's profile. This strategy creates a separate copy of the virtualized file for each user that runs the non-compliant app.
|
||||
|
||||
Most app tasks operate properly by using virtualization features. Although virtualization allows a majority of applications to run, it is a short-term fix and not a long-term solution. App developers should modify their apps to be compliant as soon as possible, rather than relying on file, folder, and registry virtualization.
|
||||
|
||||
Virtualization is not an option in the following scenarios:
|
||||
|
||||
- Virtualization does not apply to apps that are elevated and run with a full administrative access token.
|
||||
- Virtualization does not apply to apps that are elevated and run with a full administrative access token.
|
||||
|
||||
- Virtualization supports only 32-bit apps. Non-elevated 64-bit apps simply receive an access denied message when they attempt to acquire a handle (a unique identifier) to a Windows object. Native Windows 64-bit apps are required to be compatible with UAC and to write data into the correct locations.
|
||||
- Virtualization supports only 32-bit apps. Non-elevated 64-bit apps simply receive an access denied message when they attempt to acquire a handle (a unique identifier) to a Windows object. Native Windows 64-bit apps are required to be compatible with UAC and to write data into the correct locations.
|
||||
|
||||
- Virtualization is disabled if the app includes an app manifest with a requested execution level attribute.
|
||||
- Virtualization is disabled if the app includes an app manifest with a requested execution level attribute.
|
||||
|
||||
### Request execution levels
|
||||
|
||||
@ -168,22 +158,22 @@ All UAC-compliant apps should have a requested execution level added to the appl
|
||||
|
||||
### Installer detection technology
|
||||
|
||||
Installation programs are apps designed to deploy software. Most installation programs write to system directories and registry keys. These protected system locations are typically writeable only by an administrator in Installer detection technology, which means that standard users do not have sufficient access to install programs. Windows 10 and Windows 11 heuristically detect installation programs and requests administrator credentials or approval from the administrator user in order to run with access privileges. Windows 10 and Windows 11 also heuristically detect updates and programs that uninstall applications. One of the design goals of UAC is to prevent installations from being run without the user's knowledge and consent because installation programs write to protected areas of the file system and registry.
|
||||
Installation programs are apps designed to deploy software. Most installation programs write to system directories and registry keys. These protected system locations are typically writeable only by an administrator in Installer detection technology, which means that standard users do not have sufficient access to install programs. Windows 10 and Windows 11 heuristically detect installation programs and requests administrator credentials or approval from the administrator user in order to run with access privileges. Windows 10 and Windows 11 also heuristically detect updates and programs that uninstall applications. One of the design goals of UAC is to prevent installations from being run without the user's knowledge and consent because installation programs write to protected areas of the file system and registry.
|
||||
|
||||
Installer detection only applies to:
|
||||
|
||||
- 32-bit executable files.
|
||||
- Applications without a requested execution level attribute.
|
||||
- Interactive processes running as a standard user with UAC enabled.
|
||||
- 32-bit executable files.
|
||||
- Applications without a requested execution level attribute.
|
||||
- Interactive processes running as a standard user with UAC enabled.
|
||||
|
||||
Before a 32-bit process is created, the following attributes are checked to determine whether it is an installer:
|
||||
|
||||
- The file name includes keywords such as "install," "setup," or "update."
|
||||
- Versioning Resource fields contain the following keywords: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
|
||||
- Keywords in the side-by-side manifest are embedded in the executable file.
|
||||
- Keywords in specific StringTable entries are linked in the executable file.
|
||||
- Key attributes in the resource script data are linked in the executable file.
|
||||
- There are targeted sequences of bytes within the executable file.
|
||||
- The file name includes keywords such as "install," "setup," or "update."
|
||||
- Versioning Resource fields contain the following keywords: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
|
||||
- Keywords in the side-by-side manifest are embedded in the executable file.
|
||||
- Keywords in specific StringTable entries are linked in the executable file.
|
||||
- Key attributes in the resource script data are linked in the executable file.
|
||||
- There are targeted sequences of bytes within the executable file.
|
||||
|
||||
> [!NOTE]
|
||||
> The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.
|
||||
|
||||
@ -1,24 +1,13 @@
|
||||
---
|
||||
title: User Account Control Group Policy and registry key settings (Windows)
|
||||
description: Here's a list of UAC Group Policy and registry key settings that your organization can use to manage UAC.
|
||||
ms.prod: windows-client
|
||||
author: paolomatarazzo
|
||||
ms.author: paoloma
|
||||
ms.reviewer: sulahiri
|
||||
manager: aaroncz
|
||||
ms.collection:
|
||||
- M365-identity-device-management
|
||||
- highpri
|
||||
ms.topic: article
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 04/19/2017
|
||||
appliesto:
|
||||
- ✅ <b>Windows 10</b>
|
||||
- ✅ <b>Windows 11</b>
|
||||
- ✅ <b>Windows Server 2016</b>
|
||||
- ✅ <b>Windows Server 2019</b>
|
||||
- ✅ <b>Windows Server 2022</b>
|
||||
ms.technology: itpro-security
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
|
||||
---
|
||||
|
||||
# User Account Control Group Policy and registry key settings
|
||||
|
||||
@ -1,24 +1,13 @@
|
||||
---
|
||||
title: User Account Control (Windows)
|
||||
description: User Account Control (UAC) helps prevent malware from damaging a PC and helps organizations deploy a better-managed desktop.
|
||||
ms.prod: windows-client
|
||||
ms.localizationpriority: medium
|
||||
author: paolomatarazzo
|
||||
ms.author: paoloma
|
||||
ms.reviewer: sulahiri
|
||||
manager: aaroncz
|
||||
ms.collection:
|
||||
- M365-identity-device-management
|
||||
- highpri
|
||||
ms.topic: article
|
||||
ms.date: 09/24/2011
|
||||
appliesto:
|
||||
- ✅ <b>Windows 10</b>
|
||||
- ✅ <b>Windows 11</b>
|
||||
- ✅ <b>Windows Server 2016</b>
|
||||
- ✅ <b>Windows Server 2019</b>
|
||||
- ✅ <b>Windows Server 2022</b>
|
||||
ms.technology: itpro-security
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
|
||||
---
|
||||
|
||||
# User Account Control
|
||||
|
||||
@ -1,23 +1,11 @@
|
||||
---
|
||||
title: User Account Control security policy settings (Windows)
|
||||
description: You can use security policies to configure how User Account Control works in your organization.
|
||||
ms.prod: windows-client
|
||||
author: paolomatarazzo
|
||||
ms.author: paoloma
|
||||
ms.reviewer: sulahiri
|
||||
manager: aaroncz
|
||||
ms.collection:
|
||||
- M365-identity-device-management
|
||||
ms.topic: article
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 09/24/2021
|
||||
appliesto:
|
||||
- ✅ <b>Windows 10</b>
|
||||
- ✅ <b>Windows 11</b>
|
||||
- ✅ <b>Windows Server 2016</b>
|
||||
- ✅ <b>Windows Server 2019</b>
|
||||
- ✅ <b>Windows Server 2022</b>
|
||||
ms.technology: itpro-security
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
|
||||
---
|
||||
|
||||
# User Account Control security policy settings
|
||||
|
||||
Reference in New Issue
Block a user