deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 05:17:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

added cred guard refreshed files

Browse Source
This commit is contained in:
Paolo Matarazzo 2023-08-08 07:40:03 +02:00
parent df09a3b9ad
commit 883b6029db
14 changed files with 839 additions and 368 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
windows/security/identity-protection/credential-guard/additional-mitigations.md
View File

@ -1,5 +1,5 @@
--- ---
ms.date: 08/17/2017 ms.date: 06/20/2023
title: Additional mitigations title: Additional mitigations
description: Advice and sample code for making your domain environment more secure and robust with Windows Defender Credential Guard. description: Advice and sample code for making your domain environment more secure and robust with Windows Defender Credential Guard.
ms.topic: article ms.topic: article
@ -7,9 +7,35 @@ ms.topic: article
# Additional mitigations # Additional mitigations
Windows Defender Credential Guard can provide mitigation against attacks on derived credentials and prevent the use of stolen credentials elsewhere. However, PCs can still be vulnerable to certain attacks, even if the derived credentials are protected by Windows Defender Credential Guard. These attacks can include abusing privileges and use of derived credentials directly from a compromised device, re-using previously stolen credentials prior to Windows Defender Credential Guard, and abuse of management tools and weak application configurations. Because of this, additional mitigation also must be deployed to make the domain environment more robust. Windows Defender Credential Guard offers mitigations against attacks on derived credentials, preventing the use of stolen credentials elsewhere. However, devices can still be vulnerable to certain attacks, even if the derived credentials are protected by Windows Defender Credential Guard. These attacks can include abusing privileges and use of derived credentials directly from a compromised device, re-using stolen credentials prior to the enablement of Windows Defender Credential Guard, and abuse of management tools and weak application configurations. Because of this, additional mitigation also must be deployed to make the domain environment more robust.
## Restricting domain users to specific domain-joined devices ## Additional security qualifications
All devices that meet baseline protections for hardware, firmware, and software can use Windows Defender Credential Guard.\
Devices that meet more qualifications can provide added protections to further reduce the attack surface.
The following table list qualifications for improved security. We recommend meeting the additional qualifications to strengthen the level of security that Windows Defender Credential Guard can provide.
|Protection |Requirements|Security Benefits|
|---|---|---|
|**Secure Boot configuration and management**|- BIOS password or stronger authentication must be supported</br> - In the BIOS configuration, BIOS authentication must be set</br> - There must be support for protected BIOS option to configure list of permitted boot devices (for example, *Boot only from internal hard drive*) and boot device order, overriding `BOOTORDER` modification made by the operating system | - Prevent other operating systems from starting <br> -Prevent changes to the BIOS settings|
|**Hardware Rooted Trust Platform Secure Boot**|- Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby</br> - Hardware Security Test Interface (HSTI) must be implemented. See [Hardware Security Testability Specification](/windows-hardware/test/hlk/testref/hardware-security-testability-specification)|- Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware. </br> - HSTI provides security assurance for correctly secured silicon and platform|
|**Firmware Update through Windows Update**|- Firmware must support field updates through Windows Update and UEFI encapsulation update|Helps ensure that firmware updates are fast, secure, and reliable.|
|**Securing Boot Configuration and Management**|- Required BIOS capabilities: ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time </br> - Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should use ISV-provided certificates or OEM certificate for the specific UEFI software|- Enterprises can choose to allow proprietary EFI drivers/applications to run </br> - Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots|
|**VBS enablement of No-Execute (NX) protection for UEFI runtime services**|- VBS enables NX protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable. UEFI runtime service must meet the following requirements: </br>&emsp; - Implement UEFI 2.6 `EFI_MEMORY_ATTRIBUTES_TABLE`. All UEFI runtime service memory (code and data) must be described by this table </br>&emsp; - PE sections must be page-aligned in memory (not required for in non-volatile storage). </br>&emsp; - The Memory Attributes Table needs to correctly mark code and data as `RO/NX` for configuration by the OS </br>&emsp; - All entries must include attributes `EFI_MEMORY_RO`, `EFI_MEMORY_XP`, or both. </br>&emsp; - No entries may be left with neither of the above attributes, indicating memory that is both executable and writable. Memory must be either readable and executable or writable and non-executable </br> (**SEE IMPORTANT INFORMATION AFTER THIS TABLE**)|- Vulnerabilities in UEFI runtime, if any, are blocked from compromising VBS (such as in functions like *UpdateCapsule* and *SetVariable*) </br> - Reduces the attack surface to VBS from system firmware.|
|**Firmware support for SMM protection**|- The [Windows SMM Security Mitigations Table (WSMT) specification](https://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based features.|- Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)<br>- Reduces the attack surface to VBS from system firmware<br>- Blocks additional security attacks against SMM|
> [!IMPORTANT]
>
> Regarding **VBS enablement of NX protection for UEFI runtime services**:
>
> - It only applies to UEFI runtime service memory, and not UEFI boot service memory
> - The protection is applied by VBS on OS page tables
> - Don't use sections that are both writable and executable
> - Don't attempt to directly modify executable system memory
> - Don't use dynamic code
## Restrict domain users to specific domain-joined devices
Credential theft attacks allow the attacker to steal secrets from one device and use them from another device. If a user can sign on to multiple devices then any device could be used to steal credentials. How do you ensure that users only sign on with devices that have Windows Defender Credential Guard enabled? By deploying authentication policies that restrict them to specific domain-joined devices that have been configured with Windows Defender Credential Guard. For the domain controller to know what device a user is signing on from, Kerberos armoring must be used. Credential theft attacks allow the attacker to steal secrets from one device and use them from another device. If a user can sign on to multiple devices then any device could be used to steal credentials. How do you ensure that users only sign on with devices that have Windows Defender Credential Guard enabled? By deploying authentication policies that restrict them to specific domain-joined devices that have been configured with Windows Defender Credential Guard. For the domain controller to know what device a user is signing on from, Kerberos armoring must be used.
@ -27,6 +53,7 @@ Kerberos armoring is part of RFC 6113. When a device supports Kerberos armoring,
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. 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: Domain-joined device certificate authentication has the following requirements:
- Devices' accounts are in Windows Server 2012 domain functional level or higher. - 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: - All domain controllers in those domains have KDC certificates which satisfy strict KDC validation certificate requirements:
- KDC EKU present - KDC EKU present
@ -88,7 +115,7 @@ From a Windows PowerShell command prompt, run the following command:
.\set-IssuancePolicyToGroupLink.ps1 -IssuancePolicyName:"<name of issuance policy>" -groupOU:"<Name of OU to create>" -groupName:"<name of Universal security group to create>" .\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 ### Restrict user sign-on
So we now have completed the following: So we now have completed the following:
@ -117,7 +144,7 @@ Authentication policies have the following requirements:
> [!NOTE] > [!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. > 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.
#### Discovering authentication failures due to authentication policies #### Discover authentication failures due to authentication policies
To make tracking authentication failures due to authentication policies easier, an operational log exists with just those events. To enable the logs on the domain controllers, in Event Viewer, navigate to **Applications and Services Logs\\Microsoft\\Windows\\Authentication, right-click AuthenticationPolicyFailures-DomainController**, and then click **Enable Log**. To make tracking authentication failures due to authentication policies easier, an operational log exists with just those events. To enable the logs on the domain controllers, in Event Viewer, navigate to **Applications and Services Logs\\Microsoft\\Windows\\Authentication, right-click AuthenticationPolicyFailures-DomainController**, and then click **Enable Log**.

406
windows/security/identity-protection/credential-guard/configure.md Normal file
View File

@ -0,0 +1,406 @@
---
title: Configure Windows Defender Credential Guard
description: Learn how to configure Windows Defender Credential Guard using MDM, Group Policy, or the registry.
ms.date: 06/20/2023
ms.collection:
- highpri
- tier2
ms.topic: how-to
---
# Configure Windows Defender Credential Guard
This article describes how to configure Windows Defender Credential Guard using Microsoft Intune, Group Policy, or the registry.
## Default enablement
Starting in **Windows 11, version 22H2**, Windows Defender Credential Guard is turned on by default on devices that [meet the requirements](index.md#hardware-and-software-requirements). The default enablement is **without UEFI Lock**, which allows administrators to disable Credential Gurad remotely, if needed.\
If Windows Defender Credential Guard or VBS are disabled *before* a device is updated to Windows 11, version 22H2 or later, default enablement doesn't overwrite the existing settings.
While the default state of Credential Guard changed, system administrators can [enable](#enable-and-configure-windows-defender-credential-guard) or [disable](#disable-windows-defender-credential-guard) it using one of the methods described in this article.
> [!IMPORTANT]
> For information about known issues related to default enablement, see [Credential Guard: known issues](considerations-known-issues.md#single-sign-on-for-network-services-breaks-after-upgrading-to-windows-11-version-22h2).
> [!NOTE]
> Devices running Windows 11 Pro/Pro Edu 22H2 or later may have Virtualization-based Security (VBS) and/or Windows Defender Credential Guard automatically enabled if they meet the other requirements for default enablement, and have previously run Windows Defender Credential Guard. For example if Windows Defender Credential Guard was enabled on an Enterprise device that later downgraded to Pro.
>
> To determine whether the Pro device is in this state, check if the following registry key exists: `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret`. In this scenario, if you wish to disable VBS and Windows Defender Credential Guard, follow the instructions to [disable Virtualization-based Security](#disable-virtualization-based-security). If you wish to disable Windows Defender Credential Guard only, without disabling VBS, use the procedures to [disable Windows Defender Credential Guard](#disable-windows-defender-credential-guard).
## Enable and configure Windows Defender Credential Guard
Windows Defender Credential Guard should be enabled before a device is joined to a domain or before a domain user signs in for the first time. If Windows Defender Credential Guard is enabled after domain join, the user and device secrets may already be compromised.
To enable and configure Windows Defender Credential Guard, you can use:
- Microsoft Intune/MDM
- Group policy
- Registry
[!INCLUDE [tab-intro](../../../../includes/configure/tab-intro.md)]
#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune)
### Configure Credential Guard with Intune
[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
| Category | Setting name | Value |
|--|--|--|
| Device Guard | Credential Guard | Select one of the options:<br>&emsp;- **Enabled with UEFI lock**<br>&emsp;- **Enabled without lock** |
>[!IMPORTANT]
> If you want to be able to turn off Windows Defender Credential Guard remotely, choose the option **Enabled without lock**.
[!INCLUDE [intune-settings-catalog-2](../../../../includes/configure/intune-settings-catalog-2.md)]
> [!TIP]
> You can also configure Credential Guard by using an *account protection* profile in endpoint security. For more information, see [Account protection policy settings for endpoint security in Microsoft Intune](/mem/intune/protect/endpoint-security-account-protection-profile-settings).
Alternatively, you can configure devices using a [custom policy][INT-1] with the [DeviceGuard Policy CSP][CSP-1].\
The policy settings are located under: `./Device/Vendor/MSFT/Policy/Config/DeviceGuard/`.
| Setting |
|--|
| **Setting name**: Turn On Virtualization Based Security<br>**Policy CSP name**: `EnableVirtualizationBasedSecurity` |
| **Setting name**: Credential Guard Configuration<br>**Policy CSP name**: `LsaCfgFlags` |
Once the policy is applied, restart the device.
#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
### Configure Credential Guard with group policy
[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)] `Computer Configuration\Administrative Templates\System\Device Guard`:
| Group policy setting | Value |
| - | - |
|Turn On Virtualization Based Security | **Enabled** and select one of the options listed under the **Credential Guard Configuration** dropdown:<br>&emsp;- **Enabled with UEFI lock**<br>&emsp;- **Enabled without lock**|
>[!IMPORTANT]
> If you want to be able to turn off Windows Defender Credential Guard remotely, choose the option **Enabled without lock**.
[!INCLUDE [gpo-settings-2](../../../../includes/configure/gpo-settings-2.md)]
Once the policy is applied, restart the device.
#### [:::image type="icon" source="../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg)
### Configure Credential Guard with registry settings
To configure devices using the registry, use the following settings:
| Setting |
|--|
| **Key path:** `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard` <br>**Key name:** `EnableVirtualizationBasedSecurity`<br>**Type:** `REG_DWORD`<br>**Value:** `1` (to enable Virtualization Based Security)|
| **Key path:** `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard` <br>**Key name:** `RequirePlatformSecurityFeatures`<br>**Type:** `REG_DWORD`<br>**Value:**<br>&emsp;`1` (to use Secure Boot)<br>&emsp;`3` (to use Secure Boot and DMA protection) |
| **Key path:** `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa` <br>**Key name:** `LsaCfgFlags`<br>**Type:** `REG_DWORD`</li><li><br>**Value:**&emsp;`1` (to enable Credential Guard with UEFI lock)<br>&emsp;`2` (to enable Credential Guard without lock)|
Restart the device to enable Credential Guard.
> [!TIP]
> You can enable Windows Defender Credential Guard by setting the registry entries in the [*FirstLogonCommands*](/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-firstlogoncommands) unattend setting.
---
### Verify if Windows Defender Credential Guard is running
Checking the task list or Task Manager if `LsaIso.exe` is running is not a recommended method for determining whether Windows Defender Credential Guard is running. Instead, use one of the following methods:
- System Information
- PowerShell
- Event Viewer
#### System Information
You can use *System Information* to determine whether Credential Guard is running on a device.
1. Select **Start**, type `msinfo32.exe`, and then select **System Information**
1. Select **System Summary**
1. Confirm that **Credential Guard** is shown next to **Virtualization-based Security Services Running**
#### PowerShell
You can use PowerShell to determine whether Credential Guard is running on a device. From an elevated PowerShell session, use the following command:
```powershell
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
```
The command generates the following output:
- **0**: Windows Defender Credential Guard is disabled (not running)
- **1**: Windows Defender Credential Guard is enabled (running)
#### Event viewer
Perform regular reviews of the devices that have Windows Defender Credential Guard enabled, using security audit policies or WMI queries.\
Open the Event Viewer (`eventvwr.exe`) and go to `Windows Logs\System` and filter the event sources for *WinInit*:
:::row:::
:::column span="1":::
**Event ID**
:::column-end:::
:::column span="3":::
**Description**
:::column-end:::
:::row-end:::
:::row:::
:::column span="1":::
13 (Information)
:::column-end:::
:::column span="3":::
```logging
Windows Defender Credential Guard (LsaIso.exe) was started and will protect LSA credentials.
```
:::column-end:::
:::row-end:::
:::row:::
:::column span="1":::
14 (Information)
:::column-end:::
:::column span="3":::
```logging
Windows Defender Credential Guard (LsaIso.exe) configuration: [**0x0** | **0x1** | **0x2**], **0**
```
- The first variable: **0x1** or **0x2** means that Windows Defender Credential Guard is configured to run. **0x0** means that it's not configured to run.
- The second variable: **0** means that it's configured to run in protect mode. **1** means that it's configured to run in test mode. This variable should always be **0**.
:::column-end:::
:::row-end:::
:::row:::
:::column span="1":::
15 (Warning)
:::column-end:::
:::column span="3":::
```logging
Windows Defender Credential Guard (LsaIso.exe) is configured but the secure kernel isn't running;
continuing without Windows Defender Credential Guard.
```
:::column-end:::
:::row-end:::
:::row:::
:::column span="1":::
16 (Warning)
:::column-end:::
:::column span="3":::
```logging
Windows Defender Credential Guard (LsaIso.exe) failed to launch: [error code]
```
:::column-end:::
:::row-end:::
:::row:::
:::column span="1":::
17
:::column-end:::
:::column span="3":::
```logging
Error reading Windows Defender Credential Guard (LsaIso.exe) UEFI configuration: [error code]
```
:::column-end:::
:::row-end:::
The following event indicates wether TPM is used for key protection. Path: `Applications and Services logs > Microsoft > Windows > Kernel-Boot`
:::row:::
:::column span="1":::
**Event ID**
:::column-end:::
:::column span="3":::
**Description**
:::column-end:::
:::row-end:::
:::row:::
:::column span="1":::
51 (Information)
:::column-end:::
:::column span="3":::
```logging
VSM Master Encryption Key Provisioning. Using cached copy status: 0x0. Unsealing cached copy status: 0x1. New key generation status: 0x1. Sealing status: 0x1. TPM PCR mask: 0x0.
```
:::column-end:::
:::row-end:::
If you're running with a TPM, the TPM PCR mask value will be something other than 0.
## Disable Windows Defender Credential Guard
There are different options to disable Windows Defender Credential Guard. The option you choose depends on how Windows Defender Credential Guard is configured:
- Windows Defender Credential Guard running in a virtual machine can be [disabled by the host](#disable-windows-defender-credential-guard-for-a-virtual-machine)
- If Windows Defender Credential Guard is enabled **with UEFI Lock**, follow the procedure described in [disable Windows Defender Credential Guard with UEFI Lock](#disable-credential-guard-with-uefi-lock)
- If Windows Defender Credential Guard is enabled **without UEFI Lock**, or as part of the automatic enablement in the Windows 11, version 22H2 update, use one of the following options to disable it:
- Microsoft Intune/MDM
- Group policy
- Registry
[!INCLUDE [tab-intro](../../../../includes/configure/tab-intro.md)]
#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune)
### Disable Credential Guard with Intune
If Windows Defender Credential Guard is enabled via Intune and without UEFI Lock, disabling the same policy setting will disable Windows Defender Credential Guard.
[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
| Category | Setting name | Value |
|--|--|--|
| Device Guard | Credential Guard | **Disabled** |
[!INCLUDE [intune-settings-catalog-2](../../../../includes/configure/intune-settings-catalog-2.md)]
Alternatively, you can configure devices using a [custom policy][INT-1] with the [DeviceGuard Policy CSP][CSP-1].\
The policy settings is located under: `./Device/Vendor/MSFT/Policy/Config/DeviceGuard/`.
| Setting |
|--|
| **Setting name**: Credential Guard Configuration<br>**Policy CSP name**: `LsaCfgFlags` |
Once the policy is applied, restart the device.
#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
### Disable Credential Guard with group policy
If Windows Defender Credential Guard is enabled via Group Policy and without UEFI Lock, disabling the same group policy setting will disable Windows Defender Credential Guard.
[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)] `Computer Configuration\Administrative Templates\System\Device Guard`:
| Group policy setting | Value |
| - | - |
|Turn On Virtualization Based Security | **Disabled** |
[!INCLUDE [gpo-settings-2](../../../../includes/configure/gpo-settings-2.md)]
Once the policy is applied, restart the device.
#### [:::image type="icon" source="../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg)
### Disable Credential Guard with registry settings
If Windows Defender Credential Guard is enabled without UEFI Lock and without Group Policy, it's sufficient to edit the registry keys as described below to disable Windows Defender Credential Guard.
1. Change the following registry settings to 0:
- `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LsaCfgFlags`
- `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\LsaCfgFlags`
> [!NOTE]
> Deleting these registry settings may not disable Windows Defender Credential Guard. They must be set to a value of 0.
1. Restart the device
---
For information on disabling Virtualization-based Security (VBS), see [disable Virtualization-based Security](#disable-virtualization-based-security).
### Disable Credential Guard with UEFI lock
If Windows Defender Credential Guard is enabled with UEFI lock, follow this procedure since the settings are persisted in EFI (firmware) variables.
> [!NOTE]
> This scenario requires physical presence at the machine to press a function key to accept the change.
1. Follow the steps in [Disable Windows Defender Credential Guard](#disable-windows-defender-credential-guard)
1. Delete the Windows Defender Credential Guard EFI variables by using bcdedit. From an elevated command prompt, type the following commands:
```cmd
mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d
```
1. Restart the device. Before the OS boots, a prompt will appear notifying that UEFI was modified, and asking for confirmation. The prompt must be confirmed for the changes to persist.
### Disable Windows Defender Credential Guard for a virtual machine
From the host, you can disable Credential Guard for a virtual machine with the following command:
```powershell
Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true
```
## Disable Virtualization-based Security
If you disable Virtualization-based Security (VBS), you'll automatically disable Windows Defender Credential Guard and other features that rely on VBS.
> [!IMPORTANT]
> Other security features beside Credential Guard rely on VBS. Disabling VBS may have unintended side effects.
Use one of the following options to disable VBS:
- Microsoft Intune/MDM
- Group policy
- Registry
[!INCLUDE [tab-intro](../../../../includes/configure/tab-intro.md)]
#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune)
### Disable VBS with Intune
If VBS is enabled via Intune and without UEFI Lock, disabling the same policy setting will disable VBS.
[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
| Category | Setting name | Value |
|--|--|--|
| Device Guard | Enable Virtualization Based Security | **Disabled** |
[!INCLUDE [intune-settings-catalog-2](../../../../includes/configure/intune-settings-catalog-2.md)]
Alternatively, you can configure devices using a [custom policy][INT-1] with the [DeviceGuard Policy CSP][CSP-1].\
The policy settings is located under: `./Device/Vendor/MSFT/Policy/Config/DeviceGuard/`.
| Setting |
|--|
| **Setting name**: Credential Guard Configuration<br>**Policy CSP name**: `EnableVirtualizationBasedSecurity` |
Once the policy is applied, restart the device.
#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
### Disable VBS with group policy
1. Configure the policy used to enable VBS to **Disabled**. The policy setting path is: `Computer Configuration\Administrative Templates\System\Device Guard\Turn on Virtualization Based Security`
1. Once the policy is applied, restart the device
#### [:::image type="icon" source="../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg)
### Disable VBS with registry settings
1. Delete the following registry keys:
| Setting |
|--|
| Key path: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard` <br>Key name: `EnableVirtualizationBasedSecurity` |
| Key path: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard` <br>Key name: `RequirePlatformSecurityFeatures`|
> [!IMPORTANT]
> If you manually remove the registry settings, make sure to delete them all, otherwise the device might go into BitLocker recovery.
1. Restart the device
---
If Windows Defender Credential Guard is enabled with UEFI Lock, the EFI variables stored in firmware must be cleared using the command `bcdedit.exe`. From an elevated command prompt, run the following commands:
```cmd
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
bcdedit /set vsmlaunchtype off
```
## Next steps
- Review the advices and sample code for making your environment more secure and robust with Windows Defender Credential Guard in the [Additional mitigations](additional-mitigations.md) article
- Review [considerations and known issues when using Windows Defender Credential Guard](considerations-known-issues)
<!--links-->
[CSP-1]: /windows/client-management/mdm/policy-csp-deviceguard#enablevirtualizationbasedsecurity
[INT-1]: /mem/intune/configuration/settings-catalog

236
windows/security/identity-protection/credential-guard/considerations-known-issues.md Normal file
View File

@ -0,0 +1,236 @@
---
ms.date: 01/06/2023
title: Considerations and known issues when using Windows Defender Credential Guard
description: Considerations, recommendations and known issues when using Windows Defender Credential Guard.
ms.topic: troubleshooting
---
# Considerations when using Windows Defender Credential Guard
It's recommended that in addition to deploying Windows Defender Credential Guard, organizations move away from passwords to other authentication methods, such as Windows Hello for Business, FIDO 2 security keys or smart cards.
## Wi-fi and VPN considerations
When you enable Windows Defender Credential Guard, you can no longer use NTLM classic authentication for single sign-on. You'll be forced to enter your credentials to use these protocols and can't save the credentials for future use.\
If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1.
For WiFi and VPN connections, it's recommended to move from MSCHAPv2-based connections (such as PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (such as PEAP-TLS or EAP-TLS).
## Kerberos considerations
When you enable Windows Defender Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process.\
Use constrained or resource-based Kerberos delegation instead.
## Third party Security Support Providers considerations
Some third party Security Support Providers (SSPs and APs) might not be compatible with Windows Defender Credential Guard because it doesn't allow third-party SSPs to ask for password hashes from LSA. However, SSPs and APs still get notified of the password when a user logs on and/or changes their password. Any use of undocumented APIs within custom SSPs and APs aren't supported.\
It's recommended that custom implementations of SSPs/APs are tested with Windows Defender Credential Guard. SSPs and APs that depend on any undocumented or unsupported behaviors fail. For example, using the KerbQuerySupplementalCredentialsMessage API isn't supported. Replacing the NTLM or Kerberos SSPs with custom SSPs and APs.
For more information, see [Restrictions around Registering and Installing a Security Package](/windows/win32/secauthn/restrictions-around-registering-and-installing-a-security-package).
## Upgrade considerations
As the depth and breadth of protections provided by Windows Defender Credential Guard are increased, new releases of Windows with Windows Defender Credential Guard running may affect scenarios that were working in the past. For example, Windows Defender Credential Guard may block the use of a particular type of credential or a particular component to prevent malware from taking advantage of vulnerabilities.
Test scenarios required for operations in an organization before upgrading a device using Windows Defender Credential Guard.
## Saved Windows credentials protected
Domain credentials that are stored in *Credential Manager* are protected with Windows Defender Credential Guard. Credential Manager allows you to store three types of credentials:
- Windows credentials
- Certificate-based credentials
- Generic credentials
Generic credentials, such as user names and passwords that you use to sign in websites, aren't protected since the applications require your clear-text password. If the application doesn't need a copy of the password, they can save domain credentials as Windows credentials that are protected. Windows credentials are used to connect to other computers on a network.
The following considerations apply to the Windows Defender Credential Guard protections for Credential Manager:
- Windows credentials saved by the Remote Desktop client can't be sent to a remote host. Attempts to use saved Windows credentials fail, displaying the error message *Logon attempt failed.*
- Applications that extract Windows credentials fail
- When credentials are backed up from a PC that has Windows Defender Credential Guard enabled, the Windows credentials can't be restored. If you need to back up your credentials, you must do so before you enable Windows Defender Credential Guard. Otherwise, you can't restore those credentials
## Clearing TPM considerations
Virtualization-based Security (VBS) uses the TPM to protect its key. When the TPM is cleared, the TPM protected key used to encrypt VBS secrets is lost.
>[!WARNING]
> Clearing the TPM results in loss of protected data for all features that use VBS to protect data.
>
> When a TPM is cleared, **all** features that use VBS to protect data can no longer decrypt their protected data.
As a result, Credential Guard can no longer decrypt protected data. VBS creates a new TPM protected key for Credential Guard. Credential Guard uses the new key to protect new data. However, the previously protected data is lost forever.
>[!NOTE]
> Credential Guard obtains the key during initialization. The data loss will only impact persistent data and occur after the next system startup.
### Windows credentials saved to Credential Manager
Since Credential Manager can't decrypt saved Windows Credentials, they're deleted. Applications should prompt for credentials that were previously saved. If saved again, then Windows credentials are protected Credential Guard.
### Domain-joined device's automatically provisioned public key
Active Directory domain-joined devices automatically provision a bound public key, for more information about automatic public key provisioning, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
Since Credential Guard can't decrypt the protected private key, Windows uses the domain-joined computer's password for authentication to the domain. Unless other policies are deployed, there shouldn't be a loss of functionality. If a device is configured to only use public key, then it can't authenticate with password until that policy is disabled. For more information on Configuring devices to only use public key, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
Also if any access control checks including authentication policies require devices to have either the KEY TRUST IDENTITY (S-1-18-4) or FRESH PUBLIC KEY IDENTITY (S-1-18-3) well-known SIDs, then those access checks fail. For more information about authentication policies, see [Authentication Policies and Authentication Policy Silos](/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos). For more information about well-known SIDs, see [[MS-DTYP] Section 2.4.2.4 Well-known SID Structures](/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab).
### Breaking DPAPI on domain-joined devices
On domain-joined devices, DPAPI can recover user keys using a domain controller from the user's domain. If a domain-joined device has no connectivity to a domain controller, then recovery isn't possible.
>[!IMPORTANT]
> Best practice when clearing a TPM on a domain-joined device is to be on a network with connectivity to domain controllers. This ensures DPAPI functions and the user does not experience strange behavior.
Auto VPN configuration is protected with user DPAPI. User may not be able to use VPN to connect to domain controllers since the VPN configurations are lost.
If you must clear the TPM on a domain-joined device without connectivity to domain controllers, then you should consider the following.
Domain user sign-in on a domain-joined device after clearing a TPM for as long as there's no connectivity to a domain controller:
|Credential Type | Behavior
|---|---|---|
| Certificate (smart card or Windows Hello for Business) | All data protected with user DPAPI is unusable and user DPAPI doesn't work at all. |
| Password | If the user signed in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected. |
Once the device has connectivity to the domain controllers, DPAPI recovers the user's key and data protected prior to clearing the TPM can be decrypted.
#### Impact of DPAPI failures on Windows Information Protection
When data protected with user DPAPI is unusable, then the user loses access to all work data protected by Windows Information Protection. The impact includes: Outlook is unable to start and work protected documents can't be opened. If DPAPI is working, then newly created work data is protected and can be accessed.
**Workaround:** Users can resolve the problem by connecting their device to the domain and rebooting or using their Encrypting File System Data Recovery Agent certificate. For more information about Encrypting File System Data Recovery Agent certificate, see [Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate](/windows/threat-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate).
## Known issues
Windows Defender Credential Guard blocks certain authentication capabilities. Applications that require such capabilities won't function when Credential Guard is enabled.
This article describes known issues when Windows Defender Credential Guard is enabled.
## Single sign-on for Network services breaks after upgrading to Windows 11, version 22H2
Devices that use 802.1x wireless or wired network, RDP, or VPN connections that rely on insecure protocols with password-based authentication are unable to use SSO to sign in and are forced to manually re-authenticate in every new Windows session when Windows Defender Credential Guard is running.
### Affected devices
Any device with Windows Defender Credential Guard enabled may encounter the issue. As part of the Windows 11, version 22H2 update, eligible devices that didn't disable Windows Defender Credential Guard, have 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](index.md#hardware-and-software-requirements).
All Windows Pro devices that previously ran Windows Defender Credential Guard on an eligible license and later downgraded to Pro, and which still meet the [minimum hardware requirements](index.md#hardware-and-software-requirements), will receive default enablement.
> [!TIP]
> To determine if a Windows Pro device receives default enablement when upgraded to **Windows 11, version 22H2**, check if the registry key `IsolatedCredentialsRootSecret` is present in `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0`.
> If it's' present, the device enables Windows Defender Credential Guard after the update.
>
> You can Windows Defender Credential Guard can be disabled after upgrade by following the [disablement instructions](configure.md#disable-windows-defender-credential-guard).
### Cause of the issue
Applications and services are affected by the issue when they rely on insecure protocols that use password-based authentication. Such protocols are considered insecure because they can lead to password disclosure on the client or the server, and Windows Defender Credential Guard blocks them. Affected protocols 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)
> [!NOTE]
> 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.
### How to confirm the issue
MS-CHAP and NTLMv1 are relevant to the SSO breakage after the Windows 11, version 22H2 update. To confirm if Windows Defender Credential Guard is blocking MS-CHAP or NTLMv1, open the Event Viewer (`eventvwr.exe`) and go to `Application and Services Logs\Microsoft\Windows\NTLM\Operational`. Check the following logs:
:::row:::
:::column span="1":::
**Event ID (type)**
:::column-end:::
:::column span="3":::
**Description**
:::column-end:::
:::row-end:::
:::row:::
:::column span="1":::
4013 (Warning)
:::column-end:::
:::column span="3":::
```logging
<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%n
This device doesn't support NTLMv1.
/>
```
:::column-end:::
:::row-end:::
:::row:::
:::column span="1":::
4014 (Error)
:::column-end:::
:::column span="3":::
```logging
<string
id="NTLMGetCredentialKeyBlockedByCredGuard"
value="Attempt to get credential key by call package blocked by Credential Guard.%n%n
Calling Process Name: %1%nService Host Tag: %2"
/>
```
:::column-end:::
:::row-end:::
### How to fix the issue
We recommend moving away from MSCHAPv2-based connections, such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, to certificate-based authentication, like PEAP-TLS or EAP-TLS. Windows Defender Credential Guard doesn't block certificate-based authentication.
For a more immediate, but less secure fix, [disable Windows Defender Credential Guard](configure.md#disable-windows-defender-credential-guard). Windows Defender Credential Guard doesn't have per-protocol or per-application policies, and it can either be turned on or off. If you disable Windows Defender Credential Guard, you leave stored domain credentials vulnerable to theft.
> [!TIP]
> To prevent default enablement, configure your devices [to disable Windows Defender Credential Guard](configure.md#disable-windows-defender-credential-guard) before updating to Windows 11, version 22H2. If the setting is not configured (which is the default state) and if the device is eligible, the device automatically enable Credential Guard after the update.
>
> If Windows Defender Credential Guard is explicitly disabled, the device won't automatically enable Credential Guard after the update.
## Issues with third-party applications
The following issue affects MSCHAPv2:
- [Credential guard doesn't work with MSCHAPv2 configurations, of which Cisco ISE is a common enterprise implementation](https://quickview.cloudapps.cisco.com/quickview/bug/CSCul55352).
The following issue affects the Java GSS API. See the following Oracle bug database article:
- [JDK-8161921: Windows Defender Credential Guard doesn't allow sharing of TGT with Java](http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8161921)
When Windows Defender Credential Guard is enabled on Windows, the Java GSS API doesn't authenticate. Windows Defender Credential Guard blocks specific application authentication capabilities and doesn't provide the TGT session key to applications, regardless of registry key settings. For more information, see [Application requirements](index.md#application-requirements).
The following issue affects McAfee Application and Change Control (MACC):
- [KB88869 Windows machines exhibit high CPU usage with McAfee Application and Change Control (MACC) installed when Windows Defender Credential Guard is enabled](https://kcm.trellix.com/corporate/index?page=content&id=KB88869) <sup>[Note 1](#bkmk_note1)</sup>
The following issue affects Citrix applications:
- Windows machines exhibit high CPU usage with Citrix applications installed when Windows Defender Credential Guard is enabled. <sup>[Note 1](#bkmk_note1)</sup>
<a name="bkmk_note1"></a>
> [!NOTE]
> **Note 1**: Products that connect to Virtualization Based Security (VBS) protected processes can cause Windows Defender Credential Guard-enabled devices to exhibit high CPU usage. For technical and troubleshooting information, see [KB4032786 High CPU usage in the LSAISO process on Windows](/troubleshoot/windows-client/performance/lsaiso-process-high-cpu-usage).
>
> For more technical information on LSAISO.exe, see [Isolated User Mode (IUM) Processes](/windows/win32/procthread/isolated-user-mode--ium--processes).
### Vendor support
The following products and services don't support Windows Defender Credential Guard :
- [Support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard on Windows with McAfee encryption products](https://kcm.trellix.com/corporate/index?page=content&id=KB86009KB86009)
- [Check Point Endpoint Security Client support for Microsoft Windows Defender Credential Guard and Hypervisor-Protected Code Integrity features](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk113912)
- [*VMware Workstation and Device/Credential Guard aren't compatible* error in VMware Workstation on Windows 10 host (2146361)](https://kb.vmware.com/s/article/2146361)
- [ThinkPad support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard in Microsoft Windows](https://support.lenovo.com/in/en/solutions/ht503039)
- [Windows devices with Windows Defender Credential Guard and Symantec Endpoint Protection 12.1](https://www.symantec.com/connect/forums/windows-10-device-guard-credentials-guard-and-sep-121)
>[!IMPORTANT]
>This list isn't comprehensive. Check whether your product vendor, product version, or computer system supports Windows Defender Credential Guard on systems that run a specific version of Windows. Specific computer system models may be incompatible with Windows Defender Credential Guard.

102
windows/security/identity-protection/credential-guard/credential-guard-considerations.md
View File

@ -1,102 +0,0 @@
---
ms.date: 01/06/2023
title: Considerations when using Windows Defender Credential Guard
description: Considerations and recommendations for certain scenarios when using Windows Defender Credential Guard.
ms.topic: article
---
# Considerations when using Windows Defender Credential Guard
It's recommended that in addition to deploying Windows Defender Credential Guard, organizations move away from passwords to other authentication methods, such as Windows Hello for Business, FIDO 2 security keys or smart cards.
## Wi-fi and VPN considerations
When you enable Windows Defender Credential Guard, you can no longer use NTLM classic authentication for single sign-on. You'll be forced to enter your credentials to use these protocols and can't save the credentials for future use.\
If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1.
For WiFi and VPN connections, it's recommended to move from MSCHAPv2-based connections (such as PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (such as PEAP-TLS or EAP-TLS).
## Kerberos considerations
When you enable Windows Defender Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process.\
Use constrained or resource-based Kerberos delegation instead.
## Third party Security Support Providers considerations
Some third party Security Support Providers (SSPs and APs) might not be compatible with Windows Defender Credential Guard because it doesn't allow third-party SSPs to ask for password hashes from LSA. However, SSPs and APs still get notified of the password when a user logs on and/or changes their password. Any use of undocumented APIs within custom SSPs and APs aren't supported.\
It's recommended that custom implementations of SSPs/APs are tested with Windows Defender Credential Guard. SSPs and APs that depend on any undocumented or unsupported behaviors fail. For example, using the KerbQuerySupplementalCredentialsMessage API isn't supported. Replacing the NTLM or Kerberos SSPs with custom SSPs and APs.
For more information, see [Restrictions around Registering and Installing a Security Package](/windows/win32/secauthn/restrictions-around-registering-and-installing-a-security-package).
## Upgrade considerations
As the depth and breadth of protections provided by Windows Defender Credential Guard are increased, new releases of Windows with Windows Defender Credential Guard running may affect scenarios that were working in the past. For example, Windows Defender Credential Guard may block the use of a particular type of credential or a particular component to prevent malware from taking advantage of vulnerabilities.
Test scenarios required for operations in an organization before upgrading a device using Windows Defender Credential Guard.
## Saved Windows credentials protected
Domain credentials that are stored in *Credential Manager* are protected with Windows Defender Credential Guard. Credential Manager allows you to store three types of credentials:
- Windows credentials
- Certificate-based credentials
- Generic credentials
Generic credentials, such as user names and passwords that you use to sign in websites, aren't protected since the applications require your clear-text password. If the application doesn't need a copy of the password, they can save domain credentials as Windows credentials that are protected. Windows credentials are used to connect to other computers on a network.
The following considerations apply to the Windows Defender Credential Guard protections for Credential Manager:
- Windows credentials saved by the Remote Desktop client can't be sent to a remote host. Attempts to use saved Windows credentials fail, displaying the error message *Logon attempt failed.*
- Applications that extract Windows credentials fail
- When credentials are backed up from a PC that has Windows Defender Credential Guard enabled, the Windows credentials can't be restored. If you need to back up your credentials, you must do so before you enable Windows Defender Credential Guard. Otherwise, you can't restore those credentials
## Clearing TPM considerations
Virtualization-based Security (VBS) uses the TPM to protect its key. When the TPM is cleared, the TPM protected key used to encrypt VBS secrets is lost.
>[!WARNING]
> Clearing the TPM results in loss of protected data for all features that use VBS to protect data.
>
> When a TPM is cleared, **all** features that use VBS to protect data can no longer decrypt their protected data.
As a result, Credential Guard can no longer decrypt protected data. VBS creates a new TPM protected key for Credential Guard. Credential Guard uses the new key to protect new data. However, the previously protected data is lost forever.
>[!NOTE]
> Credential Guard obtains the key during initialization. The data loss will only impact persistent data and occur after the next system startup.
### Windows credentials saved to Credential Manager
Since Credential Manager can't decrypt saved Windows Credentials, they're deleted. Applications should prompt for credentials that were previously saved. If saved again, then Windows credentials are protected Credential Guard.
### Domain-joined device's automatically provisioned public key
Active Directory domain-joined devices automatically provision a bound public key, for more information about automatic public key provisioning, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
Since Credential Guard can't decrypt the protected private key, Windows uses the domain-joined computer's password for authentication to the domain. Unless other policies are deployed, there shouldn't be a loss of functionality. If a device is configured to only use public key, then it can't authenticate with password until that policy is disabled. For more information on Configuring devices to only use public key, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
Also if any access control checks including authentication policies require devices to have either the KEY TRUST IDENTITY (S-1-18-4) or FRESH PUBLIC KEY IDENTITY (S-1-18-3) well-known SIDs, then those access checks fail. For more information about authentication policies, see [Authentication Policies and Authentication Policy Silos](/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos). For more information about well-known SIDs, see [[MS-DTYP] Section 2.4.2.4 Well-known SID Structures](/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab).
### Breaking DPAPI on domain-joined devices
On domain-joined devices, DPAPI can recover user keys using a domain controller from the user's domain. If a domain-joined device has no connectivity to a domain controller, then recovery isn't possible.
>[!IMPORTANT]
> Best practice when clearing a TPM on a domain-joined device is to be on a network with connectivity to domain controllers. This ensures DPAPI functions and the user does not experience strange behavior.
Auto VPN configuration is protected with user DPAPI. User may not be able to use VPN to connect to domain controllers since the VPN configurations are lost.
If you must clear the TPM on a domain-joined device without connectivity to domain controllers, then you should consider the following.
Domain user sign-in on a domain-joined device after clearing a TPM for as long as there's no connectivity to a domain controller:
|Credential Type | Behavior
|---|---|---|
| Certificate (smart card or Windows Hello for Business) | All data protected with user DPAPI is unusable and user DPAPI doesn't work at all. |
| Password | If the user signed in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected. |
Once the device has connectivity to the domain controllers, DPAPI recovers the user's key and data protected prior to clearing the TPM can be decrypted.
#### Impact of DPAPI failures on Windows Information Protection
When data protected with user DPAPI is unusable, then the user loses access to all work data protected by Windows Information Protection. The impact includes: Outlook is unable to start and work protected documents can't be opened. If DPAPI is working, then newly created work data is protected and can be accessed.
**Workaround:** Users can resolve the problem by connecting their device to the domain and rebooting or using their Encrypting File System Data Recovery Agent certificate. For more information about Encrypting File System Data Recovery Agent certificate, see [Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate](/windows/threat-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate).

26
windows/security/identity-protection/credential-guard/credential-guard-how-it-works.md
View File

@ -1,26 +0,0 @@
---
ms.date: 08/17/2017
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: conceptual
---
# How Windows Defender Credential Guard works
Kerberos, NTLM, and Credential manager isolate secrets by using virtualization-based security. Previous versions of Windows stored secrets in the Local Security Authority (LSA). Prior to Windows 10, the LSA stored secrets used by the operating system in its process memory. With Windows Defender Credential Guard enabled, the LSA process in the operating system talks to a new component called the isolated LSA process that stores and protects those secrets. Data stored by the isolated LSA process is protected using Virtualization-based security and isn't accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.
For security reasons, the isolated LSA process doesn't host any device drivers. Instead, it only hosts a small subset of operating system binaries that are needed for security and nothing else. All of these binaries are signed with a certificate that is trusted by virtualization-based security and these signatures are validated before launching the file in the protected environment.
When Windows Defender Credential Guard is enabled, NTLMv1, MS-CHAPv2, Digest, and CredSSP can't use the signed-in credentials. Thus, single sign-on doesn't work with these protocols. However, applications can prompt for credentials or use credentials stored in the Windows Vault, which aren't protected by Windows Defender Credential Guard with any of these protocols. It is recommended that valuable credentials, such as the sign-in credentials, aren't to be used with any of these protocols. If these protocols must be used by domain or Azure AD users, secondary credentials should be provisioned for these use cases.
When Windows Defender Credential Guard is enabled, Kerberos doesn't allow unconstrained Kerberos delegation or DES encryption, not only for signed-in credentials, but also prompted or saved credentials.
Here's a high-level overview on how the LSA is isolated by using Virtualization-based security:
![Windows Defender Credential Guard overview.](images/credguard.png)
## See also
**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)

155
windows/security/identity-protection/credential-guard/credential-guard-known-issues.md
View File

@ -1,155 +0,0 @@
---
ms.date: 11/28/2022
title: Windows Defender Credential Guard - Known issues
description: Windows Defender Credential Guard - Known issues in Windows Enterprise
ms.topic: article
---
# 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).
## Known Issue: Single Sign-On (SSO) for Network services breaks after upgrading to **Windows 11, version 22H2**
### 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.
### 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.
> [!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).
### 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.
> [!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"
> />
> ```
### Options to fix the issue:
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.
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.
> [!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
The following issue affects MSCHAPv2:
- [Credential guard doesn't work with MSCHAPv2 configurations, of which Cisco ISE is a very popular enterprise implementation](https://quickview.cloudapps.cisco.com/quickview/bug/CSCul55352).
The following issue affects the Java GSS API. See the following Oracle bug database article:
- [JDK-8161921: Windows Defender Credential Guard doesn't allow sharing of TGT with Java](http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8161921)
When Windows Defender Credential Guard is enabled on Windows, the Java GSS API won't authenticate. This is expected behavior because Windows Defender Credential Guard blocks specific application authentication capabilities and won't provide the TGT session key to applications regardless of registry key settings. For more information, see [Application requirements](credential-guard-requirements.md#application-requirements).
The following issue affects Cisco AnyConnect Secure Mobility Client:
- [Blue screen on Windows computers running Hypervisor-Protected Code Integrity and Windows Defender Credential Guard with Cisco Anyconnect 4.3.04027](https://quickview.cloudapps.cisco.com/quickview/bug/CSCvc66692)
The following issue affects McAfee Application and Change Control (MACC):
- [KB88869 Windows machines exhibit high CPU usage with McAfee Application and Change Control (MACC) installed when Windows Defender Credential Guard is enabled](https://kcm.trellix.com/corporate/index?page=content&id=KB88869) <sup>[Note 1](#bkmk_note1)</sup>
The following issue affects Citrix applications:
- Windows machines exhibit high CPU usage with Citrix applications installed when Windows Defender Credential Guard is enabled. <sup>[Note 1](#bkmk_note1)</sup>
<a name="bkmk_note1"></a>
> [!NOTE]
> **Note 1**: Products that connect to Virtualization Based Security (VBS) protected processes can cause Windows Defender Credential Guard-enabled Windows 10, Windows 11, Windows Server 2016, or Windows Server 2019 machines to exhibit high CPU usage. For technical and troubleshooting information, see [KB4032786 High CPU usage in the LSAISO process on Windows](/troubleshoot/windows-client/performance/lsaiso-process-high-cpu-usage).
>
> For more technical information on LSAISO.exe, see [Isolated User Mode (IUM) Processes](/windows/win32/procthread/isolated-user-mode--ium--processes).
## Vendor support
For more information on Citrix support for Secure Boot, see [Citrix Support for Secure Boot](https://www.citrix.com/blogs/2016/12/08/windows-server-2016-hyper-v-secure-boot-support-now-available-in-xenapp-7-12/)
Windows Defender Credential Guard isn't supported by the following products, products versions, computer systems, or Windows 10 versions:
- [Support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard on Windows with McAfee encryption products](https://kcm.trellix.com/corporate/index?page=content&id=KB86009KB86009)
- [Check Point Endpoint Security Client support for Microsoft Windows Defender Credential Guard and Hypervisor-Protected Code Integrity features](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk113912)
- ["VMware Workstation and Device/Credential Guard are not compatible" error in VMware Workstation on Windows 10 host (2146361)](https://kb.vmware.com/s/article/2146361)
- [ThinkPad support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard in Microsoft Windows](https://support.lenovo.com/in/en/solutions/ht503039)
- [Windows devices with Windows Defender Credential Guard and Symantec Endpoint Protection 12.1](https://www.symantec.com/connect/forums/windows-10-device-guard-credentials-guard-and-sep-121)
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)

32
windows/security/identity-protection/credential-guard/credential-guard-protection-limits.md
View File

@ -1,32 +0,0 @@
---
title: Windows Defender Credential Guard protection limits
description: Some ways to store credentials are not protected by Windows Defender Credential Guard in Windows. Learn more with this guide.
ms.date: 08/17/2017
ms.topic: article
---
# Windows Defender Credential Guard protection limits
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 doesn't protect the Active Directory database running on Windows Server domain controllers. It also doesn't protect credential input pipelines, such as Windows Server running Remote Desktop Gateway. If you're using a Windows Server OS as a client PC, it will get the same protection as it would when running a Windows client OS.
- Key loggers
- Physical attacks
- Doesn't 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 aren't protected. If a user is prompted for and enters credentials for NTLM authentication, these credentials are vulnerable to be read from LSASS memory. These same credentials are vulnerable to key loggers as well.-
- Kerberos service tickets aren't protected by Credential Guard, but the Kerberos Ticket Granting Ticket (TGT) is.
- When Windows Defender Credential Guard is deployed on a VM, Windows Defender Credential Guard protects secrets from attacks inside the VM. However, it doesn't provide additional protection from privileged system attacks originating from the host.
- Windows logon cached password verifiers (commonly called "cached credentials")
don't qualify as credentials because they can't be presented to another computer for authentication, and can only be used locally to verify credentials. They're stored in the registry on the local computer and provide validation for credentials when a domain-joined computer can't 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 isn't available.
## See also
**Deep Dive into Windows Defender Credential Guard: Related videos**
[Microsoft Cybersecurity Stack: Advanced Identity and Endpoint Protection: Manage Credential Guard](https://www.linkedin.com/learning/microsoft-cybersecurity-stack-advanced-identity-and-endpoint-protection/manage-credential-guard?u=3322)
> [!NOTE]
> - Note: Requires [LinkedIn Learning subscription](https://www.linkedin.com/learning/subscription/products) to view the full video

35
windows/security/identity-protection/credential-guard/credential-guard.md
View File

@ -1,35 +0,0 @@
---
title: Protect derived domain credentials with Windows Defender Credential Guard
description: Windows Defender Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them.
ms.date: 11/22/2022
ms.topic: article
ms.collection:
- highpri
- tier2
---
# Protect derived domain credentials with Windows Defender Credential Guard
Windows Defender Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Windows Defender Credential Guard prevents these attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets, and credentials stored by applications as domain credentials.
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.
> [!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)
- [Enabling Strict KDC Validation in Windows Kerberos](https://www.microsoft.com/download/details.aspx?id=6382)
- [What's New in Kerberos Authentication for Windows Server 2012](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831747(v=ws.11))
- [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))
- [Trusted Platform Module](/windows/device-security/tpm/trusted-platform-module-overview)
- [Mitigating Credential Theft using the Windows 10 Isolated User Mode](/shows/seth-juarez/mitigating-credential-theft-using-windows-10-isolated-user-mode)
- [Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel](/shows/seth-juarez/isolated-user-mode-processes-features-in-windows-10-logan-gabriel)
- [More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert](/shows/seth-juarez/more-on-processes-features-in-windows-10-isolated-user-mode-dave-probert)
- [Isolated User Mode in Windows 10 with Dave Probert](/shows/seth-juarez/isolated-user-mode-in-windows-10-dave-probert)
- [Windows 10 Virtual Secure Mode with David Hepkin](/shows/seth-juarez/windows-10-virtual-secure-mode-david-hepkin)

57
windows/security/identity-protection/credential-guard/how-it-works.md Normal file
View File

@ -0,0 +1,57 @@
---
ms.date: 06/26/2023
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: conceptual
---
# How Windows Defender Credential Guard works
Kerberos, NTLM, and Credential manager isolate secrets by using virtualization-based security. Previous versions of Windows stored secrets in the Local Security Authority (LSA). Prior to Windows 10, the LSA stored secrets used by the operating system in its process memory. With Windows Defender Credential Guard enabled, the LSA process in the operating system talks to a new component called the isolated LSA process that stores and protects those secrets. Data stored by the isolated LSA process is protected using Virtualization-based security and isn't accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.
For security reasons, the isolated LSA process doesn't host any device drivers. Instead, it only hosts a small subset of operating system binaries that are needed for security and nothing else. All of these binaries are signed with a certificate that is trusted by virtualization-based security and these signatures are validated before launching the file in the protected environment.
When Windows Defender Credential Guard is enabled, NTLMv1, MS-CHAPv2, Digest, and CredSSP can't use the signed-in credentials. Thus, single sign-on doesn't work with these protocols. However, applications can prompt for credentials or use credentials stored in the Windows Vault, which aren't protected by Windows Defender Credential Guard with any of these protocols. It is recommended that valuable credentials, such as the sign-in credentials, aren't to be used with any of these protocols. If these protocols must be used by domain or Azure AD users, secondary credentials should be provisioned for these use cases.
When Windows Defender Credential Guard is enabled, Kerberos doesn't allow unconstrained Kerberos delegation or DES encryption, not only for signed-in credentials, but also prompted or saved credentials.
Here's a high-level overview on how the LSA is isolated by using Virtualization-based security:
![Windows Defender Credential Guard overview.](images/credguard.png)
## Windows Defender Credential Guard protection limits
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 doesn't protect the Active Directory database running on Windows Server domain controllers. It also doesn't protect credential input pipelines, such as Windows Server running Remote Desktop Gateway. If you're using a Windows Server OS as a client PC, it will get the same protection as it would when running a Windows client OS.
- Key loggers
- Physical attacks
- Doesn't 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 aren't protected. If a user is prompted for and enters credentials for NTLM authentication, these credentials are vulnerable to be read from LSASS memory. These same credentials are vulnerable to key loggers as well.-
- Kerberos service tickets aren't protected by Credential Guard, but the Kerberos Ticket Granting Ticket (TGT) is.
- When Windows Defender Credential Guard is deployed on a VM, Windows Defender Credential Guard protects secrets from attacks inside the VM. However, it doesn't provide additional protection from privileged system attacks originating from the host.
- Windows logon cached password verifiers (commonly called "cached credentials")
don't qualify as credentials because they can't be presented to another computer for authentication, and can only be used locally to verify credentials. They're stored in the registry on the local computer and provide validation for credentials when a domain-joined computer can't 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 isn't available.
## See also
**Deep Dive into Windows Defender Credential Guard: Related videos**
[Microsoft Cybersecurity Stack: Advanced Identity and Endpoint Protection: Manage Credential Guard](https://www.linkedin.com/learning/microsoft-cybersecurity-stack-advanced-identity-and-endpoint-protection/manage-credential-guard?u=3322)
> [!NOTE]
> - Note: Requires [LinkedIn Learning subscription](https://www.linkedin.com/learning/subscription/products) to view the full video
**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)
## Next steps
- Learn [how to configure Windows Defender Credential Guard](configure.md)
- Review the advices and sample code for making your environment more secure and robust with Windows Defender Credential Guard in the [Additional mitigations](additional-mitigations.md) article
- Review [considerations and known issues when using Windows Defender Credential Guard](considerations-known-issues)

BIN
windows/security/identity-protection/credential-guard/images/credguard-gp-disabled.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 200 KiB

BIN
windows/security/identity-protection/credential-guard/images/credguard-gp.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 270 KiB

BIN
windows/security/identity-protection/credential-guard/images/credguard-msinfo32.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

101
windows/security/identity-protection/credential-guard/index.md Normal file
View File

@ -0,0 +1,101 @@
---
title: Windows Defender Credential Guard overview
description: Learn about Windows Defender Credential Guard and how it isolates secrets so that only privileged system software can access them.
ms.date: 06/26/2023
ms.topic: conceptual
ms.collection:
- highpri
- tier1
---
# Windows Defender Credential Guard overview
Windows Defender Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials.
Windows Defender Credential Guard uses [Virtualization-based security (VBS)](/windows-hardware/design/device-experiences/oem-vbs) to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks like *pass the hash* and *pass the ticket*.
When enabled, Windows Defender Credential Guard provides the following benefits:
- **Hardware security**: NTLM, Kerberos, and Credential Manager take advantage of platform security features, including Secure Boot and virtualization, to protect credentials
- **Virtualization-based security**: NTLM, Kerberos derived credentials and other secrets run in a protected environment that is isolated from the running operating system
- **Protection against advanced persistent threats**: when credentials are protected using VBS, the credential theft attack techniques and tools used in many targeted attacks are blocked. Malware running in the operating system with administrative privileges can't extract secrets that are protected by VBS
> [!NOTE]
> 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.
> [!IMPORTANT]
> Starting in Windows 11, version 22H2, VBS and Windows Defender Credential Guard are enabled by default on all devices that meet the system requirements.\
> For information about known issues related to the default enablement of Credential Guard, see [Credential Guard: Known Issues](considerations-known-issues.md).
## System requirements
For Windows Defender Credential Guard to provide protection, the devices must meet certain hardware, firmware, and software requirements.
Devices that meet more hardware and firmware qualifications than the minimum requirements, receive additional protections and are more hardened against certain threats.
### Hardware and software requirements
Windows Defender Credential Guard requires the features:
- Virtualization-based security (VBS)
>[!NOTE]
> VBS has different requirements to enable it on different hardware platforms. For more information, see [Virtualization-based Security requirements](/windows-hardware/design/device-experiences/oem-vbs)
- [Secure Boot](../../operating-system-security/system-security/secure-the-windows-10-boot-process.md#secure-boot)
While not required, the following features are recommended to provide additional protections:
- Trusted Platform Module (TPM), as it provides binding to hardware. TPM versions 1.2 and 2.0 are supported, either discrete or firmware
- UEFI lock, as it prevents attackers from disabling Credential Guard with a registry key change
For detailed information on protections for improved security that are associated with hardware and firmware options, see [additional security qualifications](additional-mitigations.md#additional-security-qualifications).
#### Windows Defender Credential Guard in virtual machines
Credential Guard can protect secrets in Hyper-V virtual machines, just as it would on a physical machine. When Credential Guard is enabled on a VM, secrets are protected from attacks *inside* the VM. Credential Guard doesn't provide protection from privileged system attacks originating from the host.
The requirements to run Windows Defender Credential Guard in Hyper-V virtual machines are:
- The Hyper-V host must have an IOMMU
- The Hyper-V virtual machine must be generation 2
> [!NOTE]
> Credential Guard is not supported on Hyper-V or Azure generation 1 VMs. Credential Guard is available on generation 2 VMs only.
[!INCLUDE [windows-defender-credential-guard](../../../../includes/licensing/windows-defender-credential-guard.md)]
## Application requirements
When Windows Defender Credential Guard is enabled, certain authentication capabilities are blocked. Applications that require such capabilities break. We refer to these requirements as *application requirements*.
Applications should be tested prior to deployment to ensure compatibility with the reduced functionality.
> [!WARNING]
> Enabling Windows Defender Credential Guard on domain controllers isn't recommended.
> Windows Defender Credential Guard doesn't provide any added security to domain controllers, and can cause application compatibility issues on domain controllers.
> [!NOTE]
> Windows Defender Credential Guard doesn't provide protections for the Active Directory database or the Security Accounts Manager (SAM). The credentials protected by Kerberos and NTLM when Windows Defender Credential Guard is enabled are also in the Active Directory database (on domain controllers) and the SAM (for local accounts).
Applications break if they require:
- Kerberos DES encryption support
- Kerberos unconstrained delegation
- Extracting the Kerberos TGT
- NTLMv1
Applications prompt and expose credentials to risk if they require:
- Digest authentication
- Credential delegation
- MS-CHAPv2
Applications may cause performance issues when they attempt to hook the isolated Windows Defender Credential Guard process (LSAIso.exe).
Services or protocols that rely on Kerberos, such as file shares or remote desktop, continue to work and aren't affected by Windows Defender Credential Guard.
## Next steps
- Learn [how Windows Defender Credential Guard works](how-it-works.md)
- Learn [how to configure Windows Defender Credential Guard](configure.md)
- Review the advices and sample code for making your environment more secure and robust with Windows Defender Credential Guard in the [Additional mitigations](additional-mitigations.md) article
- Review [considerations and known issues when using Windows Defender Credential Guard](considerations-known-issues)

20
windows/security/identity-protection/credential-guard/toc.yml
View File

@ -1,17 +1,11 @@
items: items:
- name: Protect derived domain credentials with Credential Guard - name: Overview
href: credential-guard.md href: index.md
- name: How Credential Guard works - name: How Credential Guard works
href: credential-guard-how-it-works.md href: how-it-works.md
- name: Requirements - name: Configure Credential Guard
href: credential-guard-requirements.md href: configure.md
- name: Manage Credential Guard
href: credential-guard-manage.md
- name: Credential Guard protection limits
href: credential-guard-protection-limits.md
- name: Considerations when using Credential Guard
href: credential-guard-considerations.md
- name: Additional mitigations - name: Additional mitigations
href: additional-mitigations.md href: additional-mitigations.md
- name: Known issues - name: Considerations and known issues
href: credential-guard-known-issues.md href: considerations-known-issues.md