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

Merge pull request #9959 from MicrosoftDocs/main

Browse Source 
publish main to live, 3:30 PM, 6/20/24
This commit is contained in:
Jeff Borsecnik 2024-06-20 15:45:27 -07:00 committed by GitHub
commit d4afd12820
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 156 additions and 110 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,5 +1,5 @@
---
ms.date: 08/31/2023
ms.date: 06/20/2024
title: Additional mitigations
description: Learn how to improve the security of your domain environment with additional mitigations for Credential Guard and sample code.
ms.topic: reference
@ -46,8 +46,8 @@ Kerberos armoring is part of RFC 6113. When a device supports Kerberos armoring,
To enable Kerberos armoring for restricting domain users to specific domain-joined devices:
- Users need to be in domains that are running Windows Server 2012 R2 or higher
- All the domain controllers in these domains must be configured to support Kerberos armoring. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**.
- All the devices with Credential Guard that the users will be restricted to must be configured to support Kerberos armoring. Enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** Group Policy settings under **Computer Configuration** -> **Administrative Templates** -> **System** -> **Kerberos**.
- All the domain controllers in these domains must be configured to support Kerberos armoring. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**
- All the devices with Credential Guard that the users will be restricted to must be configured to support Kerberos armoring. Enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** Group Policy settings under **Computer Configuration** > **Administrative Templates** > **System** > **Kerberos**.
### Protect domain-joined device secrets
@ -56,7 +56,7 @@ Since domain-joined devices also use shared secrets for authentication, attacker
Domain-joined device certificate authentication has the following requirements:
- Devices' accounts are in Windows Server 2012 domain functional level or higher.
- All domain controllers in those domains have KDC certificates which satisfy strict KDC validation certificate requirements:
- All domain controllers in those domains have KDC certificates that satisfy strict KDC validation certificate requirements:
- KDC EKU present
- DNS domain name matches the DNSName field of the SubjectAltName (SAN) extension
- Windows devices have the CA issuing the domain controller certificates in the enterprise store.
@ -70,19 +70,19 @@ For example, let's say you wanted to use the High Assurance policy only on these
**Create a new certificate template**
1. From the Certificate Manager console, right-click **Certificate Templates > Manage**
1. Right-click **Workstation Authentication > Duplicate Template**
1. Right-click the new template, and then select **Properties**
1. On the **Extensions** tab, select **Application Policies > Edit**
1. Select **Client Authentication**, and then select **Remove**
1. Add the ID-PKInit-KPClientAuth EKU. Select **Add > New**, and then specify the following values:
- Name: Kerberos Client Auth
- Object Identifier: 1.3.6.1.5.2.3.4
1. On the **Extensions** tab, select **Issuance Policies > Edit**
1. Under **Issuance Policies**, select **High Assurance**
1. On the **Subject name** tab, clear the **DNS name** check box, and then select the **User Principal Name (UPN)** check box
1. From the Certificate Manager console, right-click **Certificate Templates > Manage**
1. Right-click **Workstation Authentication > Duplicate Template**
1. Right-click the new template, and then select **Properties**
1. On the **Extensions** tab, select **Application Policies > Edit**
1. Select **Client Authentication**, and then select **Remove**
1. Add the ID-PKInit-KPClientAuth EKU. Select **Add > New**, and then specify the following values:
- Name: Kerberos Client Auth
- Object Identifier: 1.3.6.1.5.2.3.4
1. On the **Extensions** tab, select **Issuance Policies > Edit**
1. Under **Issuance Policies**, select **High Assurance**
1. On the **Subject name** tab, clear the **DNS name** check box, and then select the **User Principal Name (UPN)** check box
Then on the devices that are running Credential Guard, enroll the devices using the certificate you just created.
Then on the devices that are running Credential Guard, enroll the devices using the certificate you created.
**Enroll devices in a certificate**
@ -123,12 +123,13 @@ So we now have completed the following:
- Created a special certificate issuance policy to identify devices that meet the deployment criteria required for the user to be able to sign on
- Mapped that policy to a universal security group or claim
- Provided a way for domain controllers to get the device authorization data during user sign-on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies.
- Provided a way for domain controllers to get the device authorization data during user sign-on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies
Authentication policies have the following requirements:
- User accounts are in a Windows Server 2012 domain functional level or higher domain.
**Creating an authentication policy restricting users to the specific universal security group**
- User accounts are in a Windows Server 2012 domain functional level or higher domain
#### Create an authentication policy restricting users to the specific universal security group
1. Open Active Directory Administrative Center
1. Select **Authentication > New > Authentication Policy**
@ -154,7 +155,7 @@ To learn more about authentication policy events, see [Authentication Policies a
## Appendix: Scripts
Here is a list of scripts mentioned in this topic.
Here's a list of scripts mentioned in this article.
### <a href="" id="bkmk-getscript"></a>Get the available issuance policies on the certificate authority
@ -195,7 +196,7 @@ displayName = displayName : {0}
Name = Name : {0}
dn = distinguishedName : {0}
InfoName = Linked Group Name: {0}
InfoDN = Linked Group DN: {0}
InfoDN = Linked Group DN: {0}
NonLinkedIPs = The following Issuance Policies are NOT linked to groups:
'@
}
@ -221,7 +222,7 @@ $getIP_strings.help8
""
$getIP_strings.help10
""
""
""
$getIP_strings.help11
" " + '$' + "myIPs = .\get-IssuancePolicy.ps1 -LinkedToGroup:All"
" " + '$' + "myLinkedIPs = .\get-IssuancePolicy.ps1 -LinkedToGroup:yes"
@ -272,7 +273,7 @@ write-host $errormsg -ForegroundColor Red
if (($LinkedToGroup -eq "yes") -or ($LinkedToGroup -eq "all")) {
$LDAPFilter = "(&(objectClass=msPKI-Enterprise-Oid)(msDS-OIDToGroupLink=*)(flags=2))"
$LinkedOIDs = get-adobject -searchBase $configNCDN -LDAPFilter $LDAPFilter -properties *
write-host ""
write-host ""
write-host "*****************************************************"
write-host $getIP_strings.LinkedIPs
write-host "*****************************************************"
@ -317,11 +318,11 @@ write-host "There are no issuance policies that are mapped to a group"
return $LinkedOIDs
break
}
}
if (($LinkedToGroup -eq "no") -or ($LinkedToGroup -eq "all")) {
}
if (($LinkedToGroup -eq "no") -or ($LinkedToGroup -eq "all")) {
$LDAPFilter = "(&(objectClass=msPKI-Enterprise-Oid)(!(msDS-OIDToGroupLink=*))(flags=2))"
$NonLinkedOIDs = get-adobject -searchBase $configNCDN -LDAPFilter $LDAPFilter -properties *
write-host ""
write-host ""
write-host "*********************************************************"
write-host $getIP_strings.NonLinkedIPs
write-host "*********************************************************"
@ -385,7 +386,7 @@ confirmOUcreation = Warning: The Organizational Unit that you specified does not
OUCreationSuccess = Organizational Unit "{0}" successfully created.
OUcreationError = Error: Organizational Unit "{0}" could not be created.
OUFoundSuccess = Organizational Unit "{0}" was successfully found.
multipleGroups = Error: More than one group with name "{0}" was found in Organizational Unit "{1}".
multipleGroups = Error: More than one group with name "{0}" was found in Organizational Unit "{1}".
confirmGroupCreation = Warning: The group that you specified does not exist. Do you want to create it?
groupCreationSuccess = Univeral Security group "{0}" successfully created.
groupCreationError = Error: Univeral Security group "{0}" could not be created.
@ -445,12 +446,12 @@ break
$searchBase = [String]$root.configurationnamingcontext
$OID = get-adobject -searchBase $searchBase -Filter { ((displayname -eq $IssuancePolicyName) -or (name -eq $IssuancePolicyName)) -and (objectClass -eq "msPKI-Enterprise-Oid")} -properties *
if ($OID -eq $null) {
$tmp = $ErrorMsg.NoIP -f $IssuancePolicyName, $searchBase
$tmp = $ErrorMsg.NoIP -f $IssuancePolicyName, $searchBase
write-host $tmp -ForeGroundColor Red
break;
}
elseif ($OID.GetType().IsArray) {
$tmp = $ErrorMsg.MultipleIPs -f $IssuancePolicyName, $searchBase
$tmp = $ErrorMsg.MultipleIPs -f $IssuancePolicyName, $searchBase
write-host $tmp -ForeGroundColor Red
break;
}

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

@ -1,7 +1,7 @@
---
title: Configure Credential Guard
ms.date: 06/20/2024
title: Configure Credential Guard
description: Learn how to configure Credential Guard using MDM, Group Policy, or the registry.
ms.date: 08/31/2023
ms.topic: how-to
---
@ -11,19 +11,17 @@ This article describes how to configure Credential Guard using Microsoft Intune,
## Default enablement
Starting in **Windows 11, version 22H2**, 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 Guard remotely, if needed.
> [!IMPORTANT]
> Windows Server 2025 is in preview. This information relates to a prerelease product that may be substantially modified before it's released. Microsoft makes no warranties, expressed or implied, with respect to the information provided here.
If 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.
Starting in Windows 11, 22H2 and Windows Server 2025 (preview), Credential Guard is [enabled by default on devices which meet the requirements](index.md#default-enablement).
While the default state of Credential Guard changed, system administrators can [enable](#enable-credential-guard) or [disable](#disable-credential-guard) it using one of the methods described in this article.
System administrators can explicitly [enable](#enable-credential-guard) or [disable](#disable-credential-guard) Credential Guard using one of the methods described in this article. Explicitly configured values overwrite the default enablement state after a reboot.
If a device has Credential Guard explicitly turned off before updating to a newer version of Windows where Credential Guard is enabled by default, it will remain disabled even after the update.
> [!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 Credential Guard automatically enabled if they meet the other requirements for default enablement, and have previously run Credential Guard. For example if 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 Credential Guard, follow the instructions to [disable Virtualization-based Security](#disable-virtualization-based-security). If you wish to disable Credential Guard only, without disabling VBS, use the procedures to [disable Credential Guard](#disable-credential-guard).
> For information about known issues related to default enablement, see [Credential Guard: known issues](considerations-known-issues.md).
## Enable Credential Guard
@ -124,7 +122,7 @@ You can use PowerShell to determine whether Credential Guard is running on a dev
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
```
The command generates the following output:
The command generates the following output:
- **0**: Credential Guard is disabled (not running)
- **1**: Credential Guard is enabled (running)
@ -225,7 +223,7 @@ There are different options to disable Credential Guard. The option you choose d
- Credential Guard running in a virtual machine can be [disabled by the host](#disable-credential-guard-for-a-virtual-machine)
- If Credential Guard is enabled **with UEFI Lock**, follow the procedure described in [disable Credential Guard with UEFI Lock](#disable-credential-guard-with-uefi-lock)
- If 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:
- If Credential Guard is enabled **without UEFI Lock**, or as part of the [default enablement update](index.md#default-enablement), use one of the following options to disable it:
- Microsoft Intune/MDM
- Group policy
- Registry
@ -256,7 +254,7 @@ Once the policy is applied, restart the device.
#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **GPO**](#tab/gpo)
### Disable Credential Guard with group policy
### Disable Credential Guard with group policy
If Credential Guard is enabled via Group Policy and without UEFI Lock, disabling the same group policy setting disables Credential Guard.

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

@ -1,40 +1,51 @@
---
ms.date: 08/31/2023
ms.date: 06/20/2024
title: Considerations and known issues when using Credential Guard
description: Considerations, recommendations and known issues when using Credential Guard.
description: Considerations, recommendations, and known issues when using Credential Guard.
ms.topic: troubleshooting
---
# Considerations and known issues when using Credential Guard
It's recommended that in addition to deploying Credential Guard, organizations move away from passwords to other authentication methods, such as Windows Hello for Business, FIDO 2 security keys or smart cards.
Microsoft recommends that in addition to deploying Credential Guard, organizations move away from passwords to other authentication methods, such as Windows Hello for Business, FIDO 2 security keys, or smart cards.
## Upgrade considerations
> [!IMPORTANT]
> Windows Server 2025 is in preview. This information relates to a prerelease product that may be substantially modified before it's released. Microsoft makes no warranties, expressed or implied, with respect to the information provided here.
As Credential Guard evolves and enhances its security features, newer versions of Windows running Credential Guard might affect previously functional scenarios. For instance, Credential Guard could restrict the use of certain credentials or components to thwart malware exploiting vulnerabilities.
It's advisable to thoroughly test operational scenarios within an organization before updating devices that utilize Credential Guard.
Upgrades to Windows 11, version 22H2, and Windows Server 2025 (preview) have Credential Guard [enabled by default](index.md#default-enablement) unless explicitly disabled.
## Wi-fi and VPN considerations
When you enable 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.
When Credential Guard is enabled, you can no longer use NTLM classic authentication (NTLMv1) for single-sign-on (SSO). 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
## Delegation considerations
When you enable 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.
When Credential Guard is enabled, certain types of identity delegation are unusable, as their underlying authentication schemes are incompatible with Credential Guard or require supplied credentials.
When Credential Guard is enabled, [Credential Security Support Provider ("CredSSP")](/windows/win32/secauthn/credential-security-support-provider) is no longer able to use saved or SSO credentials, though cleartext credentials can still be supplied. CredSSP-based Delegation requires cleartext credentials to be supplied on the destination machine, and doesn't work with SSO once Credential Guard is enabled and blocks cleartext credential disclosure. Usage of [CredSSP for delegation](/windows/win32/secauthn/credential-security-support-provider), and in general, isn't recommended due to the risk of credential theft.
Kerberos Unconstrained delegation and DES are blocked by Credential Guard. [Unconstrained delegation](/defender-for-identity/security-assessment-unconstrained-kerberos#what-risk-does-unsecure-kerberos-delegation-pose-to-an-organization) isn't a recommended practice.
Instead [Kerberos](/windows-server/security/kerberos/kerberos-authentication-overview) or [Negotiate SSP](/windows/win32/secauthn/microsoft-negotiate) are recommended for authentication generally, and for delegation, [Kerberos Constrained Delegation](/windows-server/security/kerberos/kerberos-constrained-delegation-overview) and [Resource-Based Kerberos Constrained Delegation](/windows-server/security/kerberos/kerberos-constrained-delegation-overview#resource-based-constrained-delegation-across-domains) are recommended. These methods provide greater credential security overall, and are also compatible with Credential Guard.
## Non-Microsoft Security Support Providers considerations
Some non-Microsoft Security Support Providers (SSPs and APs) might not be compatible with Credential Guard because it doesn't allow non-Microsoft 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.\
Some non-Microsoft Security Support Providers (SSPs and APs) might not be compatible with Credential Guard because it doesn't allow non-Microsoft 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 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 Credential Guard are increased, new releases of Windows with Credential Guard running may affect scenarios that were working in the past. For example, 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 Credential Guard.
## Saved Windows credentials considerations
*Credential Manager* allows you to store three types of credentials:
@ -86,7 +97,7 @@ On domain-joined devices, DPAPI can recover user keys using a domain controller
>[!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.
Auto VPN configuration is protected with user DPAPI. User might 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:
@ -110,34 +121,39 @@ Credential Guard blocks certain authentication capabilities. Applications that r
This article describes known issues when Credential Guard is enabled.
### Single sign-on for Network services breaks after upgrading to Windows 11, version 22H2
### Live migration with Hyper-V breaks when upgrading to Windows Server 2025 (preview)
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 Credential Guard is running.
> [!IMPORTANT]
> Windows Server 2025 is in previeww. This information relates to a prerelease product that may be substantially modified before it's released. Microsoft makes no warranties, expressed or implied, with respect to the information provided here.
#### Affected devices
Devices that use CredSSP-based Delegation might no longer be able to use [Live Migration with Hyper-V](/windows-server/virtualization/hyper-v/manage/live-migration-overview) after upgrading to Windows Server 2025 (preview). Applications and services that rely on live migration (such as [SCVMM](/system-center/vmm/overview)) might also be affected. CredSSP-based delegation is the default for Windows Server 2022 and earlier for live migration.
Any device with Credential Guard enabled may encounter the issue. As part of the Windows 11, version 22H2 update, eligible devices that didn't disable 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).
||Description|
|-|-|
| **Affected devices**|Any server with Credential Guard enabled might encounter this issue. Starting in Windows Server 2025 (preview), [Credential Guard is enabled by default](index.md#default-enablement-on-windows-server) on all domain-joined servers that aren't domain controllers. Default enablement of Credential Guard can be [preemptively blocked](configure.md#default-enablement) before upgrade.|
| **Cause of the issue**|Live Migration with Hyper-V, and applications and services that rely on it, are affected by the issue if one or both ends of a given connection try to use CredSSP with Credential Guard enabled. With Credential Guard enabled, CredSSP can only utilize supplied credentials, not saved or SSO credentials. <br><br>If the source machine of a Live Migration uses CredSSP for delegation with Credential Guard enabled, the Live Migration fails. In most cases, Credential Guard's enablement state on the destination machine won't impact Live Migration. Live Migration also fails in cluster scenarios (for example, SCVMM), since any device might act as a source machine.|
| **Resolution**|Instead of CredSSP Delegation, [Kerberos Constrained Delegation and Resource-Based Kerberos Constrained Delegation](/windows-server/security/kerberos/kerberos-constrained-delegation-overview) are recommended. These forms of delegation provide greater credential protections, in addition to being compatible with Credential Guard. Administrators of Hyper-V can [configure these types of delegation](/windows-server/virtualization/hyper-v/deploy/set-up-hosts-for-live-migration-without-failover-clustering#BKMK_Step1) manually or with the help of automated scripts.|
All Windows Pro devices that previously ran 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.
### Single sign-on for Network services breaks after upgrading to Windows 11, version 22H2 or Windows Server 2025 (preview)
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 reauthenticate in every new Windows session when Credential Guard is running.
||Description|
|-|-|
| **Affected devices**|Any device with Credential Guard enabled might encounter the issue. Starting in Windows 11, version 22H2, and Windows Server 2025 (preview), eligible devices that didn't disable Credential Guard, have it [enabled by default](index.md#default-enablement). This affects all devices on Enterprise (E3 and E5) and Education licenses, and some Pro licenses, as long as they meet the [minimum hardware requirements](index.md#hardware-and-software-requirements).<br><br>All Windows Pro devices that previously ran 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), receive default enablement.|
| **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 Credential Guard blocks them. Affected protocols include:<br><br>- Kerberos unconstrained delegation (both SSO and supplied credentials are blocked)<br>- Kerberos when PKINIT uses RSA encryption instead of Diffie-Hellman (both SSO and supplied credentials are blocked)<br>- MS-CHAP (only SSO is blocked)<br>- WDigest (only SSO is blocked)<br>- NTLM v1 (only SSO is blocked) <br><br>**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.|
| **Resolution**|Microsoft recommends moving away from MSCHAPv2-based connections (for example, PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (for example, PEAP-TLS or EAP-TLS). Credential Guard doesn't block certificate-based authentication.<br><br>For a more immediate, but less secure fix, [disable Credential Guard](configure.md#disable-credential-guard). Credential Guard doesn't have per-protocol or per-application policies, and it can either be turned on or off. If you disable Credential Guard, you leave stored domain credentials vulnerable to theft.|
> [!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 Credential Guard after the update.
> To prevent default enablement, configure your devices [to disable Credential Guard](configure.md#disable-credential-guard) before updating to a version which [received default enablement](index.md#default-enablement). 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.
>
> You can Credential Guard can be disabled after upgrade by following the [disablement instructions](configure.md#disable-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 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)
> If Credential Guard is explicitly disabled, the device won't automatically enable Credential Guard after the update.
> [!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.
> To determine if a Windows Pro device receives default enablement when upgraded to **Windows 11, version 22H2** or **Windows Server 2025 (preview)**, 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 Credential Guard after the update.
>
> Credential Guard can be disabled after upgrade by following the [disablement instructions](configure.md#disable-credential-guard).
#### How to confirm the issue
@ -186,22 +202,11 @@ MS-CHAP and NTLMv1 are relevant to the SSO breakage after the Windows 11, versio
:::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. Credential Guard doesn't block certificate-based authentication.
For a more immediate, but less secure fix, [disable Credential Guard](configure.md#disable-credential-guard). Credential Guard doesn't have per-protocol or per-application policies, and it can either be turned on or off. If you disable Credential Guard, you leave stored domain credentials vulnerable to theft.
> [!TIP]
> To prevent default enablement, configure your devices [to disable Credential Guard](configure.md#disable-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 Credential Guard is explicitly disabled, the device won't automatically enable Credential Guard after the update.
### Issues with non-Microsoft 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).
- [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:

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

@ -1,5 +1,5 @@
---
ms.date: 08/31/2023
ms.date: 06/20/2024
title: How Credential Guard works
description: Learn how Credential Guard uses virtualization to protect secrets, so that only privileged system software can access them.
ms.topic: concept-article
@ -7,18 +7,26 @@ ms.topic: concept-article
# How Credential Guard works
Kerberos, NTLM, and Credential Manager isolate secrets by using Virtualization-based security (VBS). Previous versions of Windows stored secrets in its process memory, in the Local Security Authority (LSA) process `lsass.exe`. With Credential Guard enabled, the LSA process in the operating system talks to a component called the *isolated LSA process* that stores and protects those secrets, `LSAIso.exe`. Data stored by the isolated LSA process is protected using VBS and isn't accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.
Kerberos, NTLM, and Credential Manager isolate secrets by using Virtualization-based security (VBS). Previous versions of Windows stored secrets in its process memory, in the Local Security Authority (LSA) process `lsass.exe`.
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 the binaries are signed with a certificate that VBS trusts, and the signatures are validated before launching the file in the protected environment.
:::row:::
:::column span="2":::
With Credential Guard enabled, the LSA process in the operating system talks to a component called the *isolated LSA process* that stores and protects those secrets, `LSAIso.exe`. Data stored by the isolated LSA process is protected using VBS and isn't accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.
Here's a high-level overview on how the LSA is isolated by using Virtualization-based security:
:::image type="content" source="images/credguard.png" alt-text="Diagram of the Credential Guard architecture.":::
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 the binaries are signed with a certificate that VBS trusts, and the signatures are validated before launching the file in the protected environment.
:::column-end:::
:::column span="2":::
:::image type="content" source="images/credential-guard-architecture.png" alt-text="Diagram of the Credential Guard architecture." lightbox="images/credential-guard-architecture.png" border="false":::
:::column-end:::
:::row-end:::
## Credential Guard protection limits
Some ways to store credentials aren't protected by Credential Guard, including:
- When 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 Credential Guard with any of these protocols
> [!CAUTION]
> It's recommended that valuable credentials, such as the sign-in credentials, aren't used with NTLMv1, MS-CHAPv2, Digest, or CredSSP protocols.
- Software that manages credentials outside of Windows feature protection
- Local accounts and Microsoft Accounts
- 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
@ -26,9 +34,6 @@ Some ways to store credentials aren't protected by Credential Guard, including:
- 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
- Non-Microsoft security packages
- When 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 Credential Guard with any of these protocols
> [!CAUTION]
> It's recommended that valuable credentials, such as the sign-in credentials, aren't used with NTLMv1, MS-CHAPv2, Digest, or CredSSP protocols. If these protocols must be used by domain or Microsoft Entra users, secondary credentials should be provisioned for these use cases.
- 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 protected
- When 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

BIN
windows/security/identity-protection/credential-guard/images/credential-guard-architecture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 575 KiB

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

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 59 KiB

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

@ -1,7 +1,7 @@
---
ms.date: 06/20/2024
title: Credential Guard overview
description: Learn about Credential Guard and how it isolates secrets so that only privileged system software can access them.
ms.date: 08/31/2023
ms.topic: overview
---
@ -14,28 +14,64 @@ Credential Guard uses [Virtualization-based security (VBS)](/windows-hardware/de
When enabled, 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
- **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 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.
## Default enablement
> [!IMPORTANT]
> Starting in Windows 11, version 22H2, VBS and 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).
> Windows Server 2025 is in preview. This information relates to a prerelease product that may be substantially modified before it's released. Microsoft makes no warranties, expressed or implied, with respect to the information provided here.
Starting in **Windows 11, 22H2** and **Windows Server 2025 (preview)**, VBS and Credential Guard are enabled by default on devices that meet the requirements.
The default enablement is **without UEFI Lock**, thus allowing administrators to disable Credential Guard remotely if needed.
When Credential Guard is enabled, [VBS](#system-requirements) is automatically enabled too.
> [!NOTE]
> If Credential Guard is explicitly [disabled](configure.md#disable-credential-guard) *before* a device is updated to Windows 11, version 22H2 / Windows Server 2025 (preview) or later, default enablement does not overwrite the existing settings. That device will continue to have Credential Guard disabled even after updating to a version of Windows that enables Credential Guard by default.
### Default enablement on Windows
Devices running Windows 11, 22H2 or later have Credential Guard enabled by default if they:
- Meet the [license requirements](#windows-edition-and-licensing-requirements)
- Meet the [hardware and software requirements](#system-requirements)
- Aren't [explicitly configured to disable Credential Guard](configure.md#default-enablement)
> [!NOTE]
> Devices running Windows 11 Pro/Pro Edu 22H2 or later may have Virtualization-based Security (VBS) and/or Credential Guard automatically enabled if they meet the other requirements for default enablement, and have previously run Credential Guard. For example if 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 Credential Guard, follow the instructions to [disable Virtualization-based Security](configure.md#disable-virtualization-based-security). If you wish to disable Credential Guard only, without disabling VBS, use the procedures to [disable Credential Guard](configure.md#disable-credential-guard).
### Default enablement on Windows Server
Devices running Windows Server 2025 (preview) or later have Credential Guard enabled by default if they:
- Meet the [license requirements](#windows-edition-and-licensing-requirements)
- Meet the [hardware and software requirements](#system-requirements)
- Aren't [explicitly configured to disable Credential Guard](configure.md#default-enablement)
- Are joined to a domain
- Aren't a domain controller
> [!IMPORTANT]
> For information about known issues related to default enablement, see [Credential Guard: known issues](considerations-known-issues.md#known-issues).
## System requirements
For Credential Guard to provide protection, the devices must meet certain hardware, firmware, and software requirements.
For Credential Guard to provide protection, the device 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.
Devices that exceed the minimum hardware and firmware qualifications receive additional protections and are more hardened against certain threats.
### Hardware and software requirements
Credential Guard requires the features:
- Virtualization-based security (VBS)
>[!NOTE]
> [!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)
@ -64,7 +100,7 @@ The requirements to run Credential Guard in Hyper-V virtual machines are:
When 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.
Applications should be tested before deployment to ensure compatibility with the reduced functionality.
> [!WARNING]
> Enabling Credential Guard on domain controllers isn't recommended.
@ -77,16 +113,17 @@ Applications break if they require:
- Kerberos DES encryption support
- Kerberos unconstrained delegation
- Extracting the Kerberos TGT
- Kerberos TGT extraction
- NTLMv1
Applications prompt and expose credentials to risk if they require:
Applications ask and expose credentials to risk if they require:
- Digest authentication
- Credential delegation
- MS-CHAPv2
- CredSSP
Applications may cause performance issues when they attempt to hook the isolated Credential Guard process `LSAIso.exe`.
Applications might cause performance issues when they attempt to hook the isolated 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 Credential Guard.
@ -95,4 +132,4 @@ Services or protocols that rely on Kerberos, such as file shares or remote deskt
- Learn [how Credential Guard works](how-it-works.md)
- Learn [how to configure Credential Guard](configure.md)
- Review the advice and sample code for making your environment more secure and robust with Credential Guard in the [Additional mitigations](additional-mitigations.md) article
- Review [considerations and known issues when using Credential Guard](considerations-known-issues.md)
- Review [considerations and known issues when using Credential Guard](considerations-known-issues.md)