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

Merge branch 'main' into add_new_LAPS_CSP_docs

Browse Source
This commit is contained in:
Stephanie Savell 2022-09-20 10:31:33 -05:00 committed by GitHub
commit e89e6ee90c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
13 changed files with 309 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.openpublishing.redirection.json
View File

@ -19644,6 +19644,11 @@
"source_path": "windows/security/identity-protection/access-control/dynamic-access-control.md", "source_path": "windows/security/identity-protection/access-control/dynamic-access-control.md",
"redirect_url": "/windows-server/identity/solution-guides/dynamic-access-control-overview", "redirect_url": "/windows-server/identity/solution-guides/dynamic-access-control-overview",
"redirect_document_id": false "redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md",
"redirect_url": "windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md",
"redirect_document_id": false
} }
] ]
} }

229
windows/client-management/mdm/policy-csp-kerberos.md
View File

@ -31,6 +31,18 @@ manager: aaroncz
</dd> </dd>
<dd> <dd>
<a href="#kerberos-pkinithashalgorithmconfiguration">Kerberos/PKInitHashAlgorithmConfiguration</a> <a href="#kerberos-pkinithashalgorithmconfiguration">Kerberos/PKInitHashAlgorithmConfiguration</a>
</dd>
<dd>
<a href="#kerberos-pkinithashalgorithmsha1">Kerberos/PKInitHashAlgorithmSHA1</a>
</dd>
<dd>
<a href="#kerberos-pkinithashalgorithmsha256">Kerberos/PKInitHashAlgorithmSHA256</a>
</dd>
<dd>
<a href="#kerberos-pkinithashalgorithmsha384">Kerberos/PKInitHashAlgorithmSHA384</a>
</dd>
<dd>
<a href="#kerberos-pkinithashalgorithmsha512">Kerberos/PKInitHashAlgorithmSHA512</a>
</dd> </dd>
<dd> <dd>
<a href="#kerberos-requirekerberosarmoring">Kerberos/RequireKerberosArmoring</a> <a href="#kerberos-requirekerberosarmoring">Kerberos/RequireKerberosArmoring</a>
@ -231,22 +243,20 @@ ADMX Info:
This policy setting controls hash or checksum algorithms used by the Kerberos client when performing certificate authentication. This policy setting controls hash or checksum algorithms used by the Kerberos client when performing certificate authentication.
If you enable this policy, you'll be able to configure one of four states for each algorithm: If you enable this policy, you'll be able to configure one of four states for each hash algorithm (SHA1, SHA256, SHA384, and SHA512) using their respective policies.
* **Default**: This state sets the algorithm to the recommended state.
* **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
* **Audited**: This state enables usage of the algorithm and reports an event (ID 205) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
* **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
If you disable or don't configure this policy, each algorithm will assume the **Default** state. If you disable or don't configure this policy, each algorithm will assume the **Default** state.
* 0 - **Disabled**
* 1 - **Enabled**
More information about the hash and checksum algorithms supported by the Windows Kerberos client and their default states can be found https://go.microsoft.com/fwlink/?linkid=2169037. More information about the hash and checksum algorithms supported by the Windows Kerberos client and their default states can be found https://go.microsoft.com/fwlink/?linkid=2169037.
<!--/Description--> <!--/Description-->
<!--ADMXBacked--> <!--ADMXBacked-->
ADMX Info: ADMX Info:
- GP Friendly name: *Introducing agility to PKINIT in Kerberos protocol* - GP Friendly name: *Configure Hash algorithms for certificate logon*
- GP name: *PKInitHashAlgorithmConfiguration* - GP name: *PKInitHashAlgorithmConfiguration*
- GP path: *System/Kerberos* - GP path: *System/Kerberos*
- GP ADMX file name: *Kerberos.admx* - GP ADMX file name: *Kerberos.admx*
@ -256,6 +266,209 @@ ADMX Info:
<hr/> <hr/>
<!--Policy-->
<a href="" id="kerberos-pkinithashalgorithmsha1"></a>**Kerberos/PKInitHashAlgorithmSHA1**
<!--SupportedSKUs-->
|Edition|Windows 10|Windows 11|
|--- |--- |--- |
|Home|No|No|
|Pro|Yes|Yes|
|Windows SE|No|Yes|
|Business|Yes|Yes|
|Enterprise|Yes|Yes|
|Education|Yes|Yes|
<!--/SupportedSKUs-->
<hr/>
<!--Scope-->
[Scope](./policy-configuration-service-provider.md#policy-scope):
> [!div class = "checklist"]
> * Device
<hr/>
<!--/Scope-->
<!--Description-->
This policy setting controls the configuration of the SHA1 algorithm used by the Kerberos client when performing certificate authentication. This policy is only enforced if Kerberos/PKInitHashAlgorithmConfiguration is enabled. You can configure one of four states for this algorithm:
* 0 - **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
* 1 - **Default**: This state sets the algorithm to the recommended state.
* 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
* 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
If you don't configure this policy, the SHA1 algorithm will assume the **Default** state.
<!--/Description-->
<!--ADMXBacked-->
ADMX Info:
- GP Friendly name: *Configure Hash algorithms for certificate logon*
- GP name: *PKInitHashAlgorithmConfiguration*
- GP path: *System/Kerberos*
- GP ADMX file name: *Kerberos.admx*
<!--/ADMXBacked-->
<!--/Policy-->
<hr/>
<!--Policy-->
<a href="" id="kerberos-pkinithashalgorithmsha256"></a>**Kerberos/PKInitHashAlgorithmSHA256**
<!--SupportedSKUs-->
|Edition|Windows 10|Windows 11|
|--- |--- |--- |
|Home|No|No|
|Pro|Yes|Yes|
|Windows SE|No|Yes|
|Business|Yes|Yes|
|Enterprise|Yes|Yes|
|Education|Yes|Yes|
<!--/SupportedSKUs-->
<hr/>
<!--Scope-->
[Scope](./policy-configuration-service-provider.md#policy-scope):
> [!div class = "checklist"]
> * Device
<hr/>
<!--/Scope-->
<!--Description-->
This policy setting controls the configuration of the SHA256 algorithm used by the Kerberos client when performing certificate authentication. This policy is only enforced if Kerberos/PKInitHashAlgorithmConfiguration is enabled. You can configure one of four states for this algorithm:
* 0 - **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
* 1 - **Default**: This state sets the algorithm to the recommended state.
* 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
* 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
If you don't configure this policy, the SHA256 algorithm will assume the **Default** state.
<!--/Description-->
<!--ADMXBacked-->
ADMX Info:
- GP Friendly name: *Configure Hash algorithms for certificate logon*
- GP name: *PKInitHashAlgorithmConfiguration*
- GP path: *System/Kerberos*
- GP ADMX file name: *Kerberos.admx*
<!--/ADMXBacked-->
<!--/Policy-->
<hr/>
<!--Policy-->
<a href="" id="kerberos-pkinithashalgorithmsha384"></a>**Kerberos/PKInitHashAlgorithmSHA384**
<!--SupportedSKUs-->
|Edition|Windows 10|Windows 11|
|--- |--- |--- |
|Home|No|No|
|Pro|Yes|Yes|
|Windows SE|No|Yes|
|Business|Yes|Yes|
|Enterprise|Yes|Yes|
|Education|Yes|Yes|
<!--/SupportedSKUs-->
<hr/>
<!--Scope-->
[Scope](./policy-configuration-service-provider.md#policy-scope):
> [!div class = "checklist"]
> * Device
<hr/>
<!--/Scope-->
<!--Description-->
This policy setting controls the configuration of the SHA384 algorithm used by the Kerberos client when performing certificate authentication. This policy is only enforced if Kerberos/PKInitHashAlgorithmConfiguration is enabled. You can configure one of four states for this algorithm:
* 0 - **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
* 1 - **Default**: This state sets the algorithm to the recommended state.
* 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
* 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
If you don't configure this policy, the SHA384 algorithm will assume the **Default** state.
<!--/Description-->
<!--ADMXBacked-->
ADMX Info:
- GP Friendly name: *Configure Hash algorithms for certificate logon*
- GP name: *PKInitHashAlgorithmConfiguration*
- GP path: *System/Kerberos*
- GP ADMX file name: *Kerberos.admx*
<!--/ADMXBacked-->
<!--/Policy-->
<hr/>
<!--Policy-->
<a href="" id="kerberos-pkinithashalgorithmsha512"></a>**Kerberos/PKInitHashAlgorithmSHA512**
<!--SupportedSKUs-->
|Edition|Windows 10|Windows 11|
|--- |--- |--- |
|Home|No|No|
|Pro|Yes|Yes|
|Windows SE|No|Yes|
|Business|Yes|Yes|
|Enterprise|Yes|Yes|
|Education|Yes|Yes|
<!--/SupportedSKUs-->
<hr/>
<!--Scope-->
[Scope](./policy-configuration-service-provider.md#policy-scope):
> [!div class = "checklist"]
> * Device
<hr/>
<!--/Scope-->
<!--Description-->
This policy setting controls the configuration of the SHA512 algorithm used by the Kerberos client when performing certificate authentication. This policy is only enforced if Kerberos/PKInitHashAlgorithmConfiguration is enabled. You can configure one of four states for this algorithm:
* 0 - **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
* 1 - **Default**: This state sets the algorithm to the recommended state.
* 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
* 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
If you don't configure this policy, the SHA512 algorithm will assume the **Default** state.
<!--/Description-->
<!--ADMXBacked-->
ADMX Info:
- GP Friendly name: *Configure Hash algorithms for certificate logon*
- GP name: *PKInitHashAlgorithmConfiguration*
- GP path: *System/Kerberos*
- GP ADMX file name: *Kerberos.admx*
<!--/ADMXBacked-->
<!--/Policy-->
<hr/>
<!--Policy--> <!--Policy-->
<a href="" id="kerberos-requirekerberosarmoring"></a>**Kerberos/RequireKerberosArmoring** <a href="" id="kerberos-requirekerberosarmoring"></a>**Kerberos/RequireKerberosArmoring**
@ -456,4 +669,4 @@ Devices joined to Azure Active Directory in a hybrid environment need to interac
## Related topics ## Related topics
[Policy configuration service provider](policy-configuration-service-provider.md) [Policy configuration service provider](policy-configuration-service-provider.md)

10
windows/security/identity-protection/hello-for-business/hello-deployment-guide.md
View File

@ -35,7 +35,7 @@ This guide assumes that baseline infrastructure exists which meets the requireme
- Multi-factor Authentication is required during Windows Hello for Business provisioning - Multi-factor Authentication is required during Windows Hello for Business provisioning
- Proper name resolution, both internal and external names - Proper name resolution, both internal and external names
- Active Directory and an adequate number of domain controllers per site to support authentication - Active Directory and an adequate number of domain controllers per site to support authentication
- Active Directory Certificate Services 2012 or later (Note: certificate services are not needed for cloud trust deployments) - Active Directory Certificate Services 2012 or later (Note: certificate services are not needed for cloud Kerberos trust deployments)
- One or more workstation computers running Windows 10, version 1703 or later - One or more workstation computers running Windows 10, version 1703 or later
If you are installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server. If you are installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server.
@ -44,23 +44,23 @@ Do not begin your deployment until the hosting servers and infrastructure (not r
## Deployment and trust models ## Deployment and trust models
Windows Hello for Business has three deployment models: Azure AD cloud only, hybrid, and on-premises. Hybrid has three trust models: *Key trust*, *certificate trust*, and *cloud trust*. On-premises deployment models only support *Key trust* and *certificate trust*. Windows Hello for Business has three deployment models: Azure AD cloud only, hybrid, and on-premises. Hybrid has three trust models: *Key Trust*, *Certificate Trust*, and *cloud Kerberos trust*. On-premises deployment models only support *Key Trust* and *Certificate Trust*.
Hybrid deployments are for enterprises that use Azure Active Directory. On-premises deployments are for enterprises who exclusively use on-premises Active Directory. Remember that the environments that use Azure Active Directory must use the hybrid deployment model for all domains in that forest. Hybrid deployments are for enterprises that use Azure Active Directory. On-premises deployments are for enterprises who exclusively use on-premises Active Directory. Remember that the environments that use Azure Active Directory must use the hybrid deployment model for all domains in that forest.
The trust model determines how you want users to authenticate to the on-premises Active Directory: The trust model determines how you want users to authenticate to the on-premises Active Directory:
- The key-trust model is for enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates. - The key-trust model is for enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates.
- The cloud-trust model is also for hybrid enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and does not require Active Directory Certificate Services. We recommend using cloud trust instead of key trust if the clients in your enterprise support it. - The cloud-trust model is also for hybrid enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and does not require Active Directory Certificate Services. We recommend using **cloud Kerberos trust** instead of **Key Trust** if the clients in your enterprise support it.
- The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today. - The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today.
- The certificate trust model also supports enterprises which are not ready to deploy Windows Server 2016 Domain Controllers. - The certificate trust model also supports enterprises which are not ready to deploy Windows Server 2016 Domain Controllers.
> [!Note] > [!Note]
> RDP does not support authentication with Windows Hello for Business key trust or cloud trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business key trust and cloud trust can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md). > RDP does not support authentication with Windows Hello for Business Key Trust or cloud Kerberos trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business Key Trust and cloud Kerberos trust can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
Following are the various deployment guides and models included in this topic: Following are the various deployment guides and models included in this topic:
- [Hybrid Azure AD Joined Cloud Trust Deployment](hello-hybrid-cloud-trust.md) - [Hybrid Azure AD Joined cloud Kerberos trust Deployment](hello-hybrid-cloud-kerberos-trust.md)
- [Hybrid Azure AD Joined Key Trust Deployment](hello-hybrid-key-trust.md) - [Hybrid Azure AD Joined Key Trust Deployment](hello-hybrid-key-trust.md)
- [Hybrid Azure AD Joined Certificate Trust Deployment](hello-hybrid-cert-trust.md) - [Hybrid Azure AD Joined Certificate Trust Deployment](hello-hybrid-cert-trust.md)
- [Azure AD Join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md) - [Azure AD Join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md)

4
windows/security/identity-protection/hello-for-business/hello-faq.yml
View File

@ -29,9 +29,9 @@ sections:
- name: Ignored - name: Ignored
questions: questions:
- question: What is Windows Hello for Business cloud trust? - question: What is Windows Hello for Business cloud Kerberos trust?
answer: | answer: |
Windows Hello for Business cloud trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid Cloud Trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust). Windows Hello for Business cloud Kerberos trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid cloud Kerberos trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
- question: What about virtual smart cards? - question: What about virtual smart cards?

4
windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
View File

@ -96,8 +96,8 @@ Using Group Policy, Microsoft Intune or a compatible MDM solution, you can confi
|--- |--- |--- | |--- |--- |--- |
|**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. For more information on how to deploy the Microsoft PIN reset service and client policy, see [Connect Azure Active Directory with the PIN reset service](#connect-azure-active-directory-with-the-pin-reset-service). During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.| |**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. For more information on how to deploy the Microsoft PIN reset service and client policy, see [Connect Azure Active Directory with the PIN reset service](#connect-azure-active-directory-with-the-pin-reset-service). During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.|
|**Windows editions and versions**|Reset from settings - Windows 10, version 1703 or later, Windows 11. Reset above Lock - Windows 10, version 1709 or later, Windows 11.|Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903. Enterprise Edition and Pro edition with Windows 10, version 1903 and newer Windows 11.| |**Windows editions and versions**|Reset from settings - Windows 10, version 1703 or later, Windows 11. Reset above Lock - Windows 10, version 1709 or later, Windows 11.|Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903. Enterprise Edition and Pro edition with Windows 10, version 1903 and newer Windows 11.|
|**Azure Active Directory Joined**|Cert Trust, Key Trust, and Cloud Trust|Cert Trust, Key Trust, and Cloud Trust| |**Azure Active Directory Joined**|Cert Trust, Key Trust, and cloud Kerberos trust|Cert Trust, Key Trust, and cloud Kerberos trust|
|**Hybrid Azure Active Directory Joined**|Cert Trust and Cloud Trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and Cloud Trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.| |**Hybrid Azure Active Directory Joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.|
|**On Premises**|If ADFS is being used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it is only available for Hybrid Azure Active Directory Joined and Azure Active Directory Joined devices.| |**On Premises**|If ADFS is being used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it is only available for Hybrid Azure Active Directory Joined and Azure Active Directory Joined devices.|
|**Additional Configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature On-board the Microsoft PIN reset service to respective Azure Active Directory tenant Configure Windows devices to use PIN reset using Group *Policy\MDM*.| |**Additional Configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature On-board the Microsoft PIN reset service to respective Azure Active Directory tenant Configure Windows devices to use PIN reset using Group *Policy\MDM*.|
|**MSA/Enterprise**|MSA and Enterprise|Enterprise only.| |**MSA/Enterprise**|MSA and Enterprise|Enterprise only.|

10
windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
View File

@ -21,10 +21,10 @@ Windows Hello for Business authentication is passwordless, two-factor authentica
Azure Active Directory-joined devices authenticate to Azure during sign-in and can optionally authenticate to Active Directory. Hybrid Azure Active Directory-joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background. Azure Active Directory-joined devices authenticate to Azure during sign-in and can optionally authenticate to Active Directory. Hybrid Azure Active Directory-joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.
- [Azure AD join authentication to Azure Active Directory](#azure-ad-join-authentication-to-azure-active-directory) - [Azure AD join authentication to Azure Active Directory](#azure-ad-join-authentication-to-azure-active-directory)
- [Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud trust preview)](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos-cloud-trust-preview) - [Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud Kerberos trust)](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos-cloud-kerberos-trust)
- [Azure AD join authentication to Active Directory using a key](#azure-ad-join-authentication-to-active-directory-using-a-key) - [Azure AD join authentication to Active Directory using a key](#azure-ad-join-authentication-to-active-directory-using-a-key)
- [Azure AD join authentication to Active Directory using a certificate](#azure-ad-join-authentication-to-active-directory-using-a-certificate) - [Azure AD join authentication to Active Directory using a certificate](#azure-ad-join-authentication-to-active-directory-using-a-certificate)
- [Hybrid Azure AD join authentication using Azure AD Kerberos (cloud trust preview)](#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview) - [Hybrid Azure AD join authentication using Azure AD Kerberos (cloud Kerberos trust)](#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-kerberos-trust)
- [Hybrid Azure AD join authentication using a key](#hybrid-azure-ad-join-authentication-using-a-key) - [Hybrid Azure AD join authentication using a key](#hybrid-azure-ad-join-authentication-using-a-key)
- [Hybrid Azure AD join authentication using a certificate](#hybrid-azure-ad-join-authentication-using-a-certificate) - [Hybrid Azure AD join authentication using a certificate](#hybrid-azure-ad-join-authentication-using-a-certificate)
@ -43,7 +43,7 @@ Azure Active Directory-joined devices authenticate to Azure during sign-in and c
|D | The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.| |D | The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
|E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| |E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
## Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud trust preview) ## Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud Kerberos trust)
![Azure Active Directory join authentication to Azure AD.](images/howitworks/auth-aadj-cloudtrust-kerb.png) ![Azure Active Directory join authentication to Azure AD.](images/howitworks/auth-aadj-cloudtrust-kerb.png)
@ -78,13 +78,13 @@ Azure Active Directory-joined devices authenticate to Azure during sign-in and c
> [!NOTE] > [!NOTE]
> You may have an on-premises domain federated with Azure AD. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Azure AD to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation. > You may have an on-premises domain federated with Azure AD. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Azure AD to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation.
## Hybrid Azure AD join authentication using Azure AD Kerberos (cloud trust preview) ## Hybrid Azure AD join authentication using Azure AD Kerberos (cloud Kerberos trust)
![Hybrid Azure AD join authentication using Azure AD Kerberos](images/howitworks/auth-haadj-cloudtrust.png) ![Hybrid Azure AD join authentication using Azure AD Kerberos](images/howitworks/auth-haadj-cloudtrust.png)
| Phase | Description | | Phase | Description |
| :----: | :----------- | | :----: | :----------- |
|A | Authentication begins when the user dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to winlogon. Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud trust is enabled. If cloud trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Azure Active Directory. Azure AD returns a nonce. |A | Authentication begins when the user dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to winlogon. Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Azure Active Directory. Azure AD returns a nonce.
|B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Azure AD. |B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Azure AD.
|C | Azure AD validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Azure AD Kerberos and returns them to Cloud AP. |C | Azure AD validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Azure AD Kerberos and returns them to Cloud AP.
|D | Cloud AP receives the encrypted PRT with session key. Using the device's private transport key, Cloud AP decrypts the session key and protects the session key using the device's TPM (if available). Cloud AP returns a successful authentication response to lsass. Lsass caches the PRT and the Partial TGT. |D | Cloud AP receives the encrypted PRT with session key. Using the device's private transport key, Cloud AP decrypts the session key and protects the session key using the device's TPM (if available). Cloud AP returns a successful authentication response to lsass. Lsass caches the PRT and the Partial TGT.

8
windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
View File

@ -26,7 +26,7 @@ List of provisioning flows:
- [Azure AD joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment) - [Azure AD joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment)
- [Azure AD joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment) - [Azure AD joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)
- [Hybrid Azure AD joined provisioning in a cloud trust (preview) deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-trust-preview-deployment-in-a-managed-environment) - [Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment)
- [Hybrid Azure AD joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment) - [Hybrid Azure AD joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
- [Hybrid Azure AD joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment) - [Hybrid Azure AD joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
- [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment) - [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)
@ -62,9 +62,9 @@ List of provisioning flows:
[Return to top](#windows-hello-for-business-provisioning) [Return to top](#windows-hello-for-business-provisioning)
## Hybrid Azure AD joined provisioning in a cloud trust (preview) deployment in a managed environment ## Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment
![Hybrid Azure AD joined provisioning in a cloud trust deployment in a Managed environment.](images/howitworks/prov-haadj-cloudtrust-managed.png) ![Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a Managed environment.](images/howitworks/prov-haadj-cloudtrust-managed.png)
[Full size image](images/howitworks/prov-haadj-cloudtrust-managed.png) [Full size image](images/howitworks/prov-haadj-cloudtrust-managed.png)
| Phase | Description | | Phase | Description |
@ -74,7 +74,7 @@ List of provisioning flows:
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. | | C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. |
> [!NOTE] > [!NOTE]
> Windows Hello for Business Cloud Trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to Azure Active Directory and AD after provisioning their credential. > Windows Hello for Business cloud Kerberos trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to Azure Active Directory and AD after provisioning their credential.
[Return to top](#windows-hello-for-business-provisioning) [Return to top](#windows-hello-for-business-provisioning)

110
windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md → windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
View File

@ -1,6 +1,6 @@
--- ---
title: Hybrid Cloud Trust Deployment (Windows Hello for Business) title: Hybrid cloud Kerberos trust Deployment (Windows Hello for Business)
description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid cloud trust scenario. description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario.
ms.prod: m365-security ms.prod: m365-security
author: paolomatarazzo author: paolomatarazzo
ms.author: paoloma ms.author: paoloma
@ -11,37 +11,39 @@ ms.topic: article
localizationpriority: medium localizationpriority: medium
ms.date: 2/15/2022 ms.date: 2/15/2022
appliesto: appliesto:
- ✅ <b>Windows 10 21H2 and later</b> - ✅ <b>Windows 10, version 21H2 and later</b>
- ✅ <b>Windows 11</b> - ✅ <b>Windows 11</b>
- ✅ <b>Hybrid deployment</b>
- ✅ <b>Cloud Kerberos trust</b>
--- ---
# Hybrid Cloud Trust Deployment (Preview) # Hybrid Cloud Kerberos Trust Deployment (Preview)
Windows Hello for Business replaces username and password Windows sign-in with strong authentication using an asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid cloud trust scenario. Windows Hello for Business replaces username and password Windows sign-in with strong authentication using an asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario.
## Introduction to Cloud Trust ## Introduction to Cloud Kerberos Trust
The goal of the Windows Hello for Business cloud trust is to bring the simplified deployment experience of [on-premises SSO with passwordless security keys](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises) to Windows Hello for Business. This deployment model can be used for new Windows Hello for Business deployments or existing deployments can move to this model using policy controls. The goal of the Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of [on-premises SSO with passwordless security keys](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises) to Windows Hello for Business. This deployment model can be used for new Windows Hello for Business deployments or existing deployments can move to this model using policy controls.
Windows Hello for Business cloud trust uses Azure Active Directory (AD) Kerberos to address pain points of the key trust deployment model: Windows Hello for Business cloud Kerberos trust uses Azure Active Directory (AD) Kerberos to address pain points of the key trust deployment model:
- Windows Hello for Business cloud trust provides a simpler deployment experience because it doesn't require the deployment of public key infrastructure (PKI) or changes to existing PKI. - Windows Hello for Business cloud Kerberos trust provides a simpler deployment experience because it doesn't require the deployment of public key infrastructure (PKI) or changes to existing PKI.
- Cloud trust doesn't require syncing of public keys between Azure AD and on-premises domain controllers (DCs) for users to access on-premises resources and applications. This change means there isn't a delay between the user provisioning and being able to authenticate. - Cloud Kerberos trust doesn't require syncing of public keys between Azure AD and on-premises domain controllers (DCs) for users to access on-premises resources and applications. This change means there isn't a delay between the user provisioning and being able to authenticate.
- Deploying Windows Hello for Business cloud trust enables you to also deploy passwordless security keys with minimal extra setup. - Deploying Windows Hello for Business cloud Kerberos trust enables you to also deploy passwordless security keys with minimal extra setup.
> [!NOTE] > [!NOTE]
> Windows Hello for Business cloud trust is recommended instead of key trust if you meet the prerequisites to deploy cloud trust. Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios. > Windows Hello for Business cloud Kerberos trust is recommended instead of key trust if you meet the prerequisites to deploy cloud Kerberos trust. cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios.
## Azure Active Directory Kerberos and Cloud Trust Authentication ## Azure Active Directory Kerberos and Cloud Kerberos Trust Authentication
Key trust and certificate trust use certificate authentication based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD-joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. Cloud trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT. Key trust and certificate trust use certificate authentication based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD-joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. cloud Kerberos trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT.
With Azure AD Kerberos, Azure AD can issue TGTs for one or more of your AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business and use the returned TGT for logon or to access traditional AD-based resources. Kerberos service tickets and authorization continue to be controlled by your on-premises AD DCs. With Azure AD Kerberos, Azure AD can issue TGTs for one or more of your AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business and use the returned TGT for logon or to access traditional AD-based resources. Kerberos service tickets and authorization continue to be controlled by your on-premises AD DCs.
When you enable Azure AD Kerberos in a domain, an Azure AD Kerberos Server object is created in your on-premises AD. This object will appear as a Read Only Domain Controller (RODC) object but isn't associated with any physical servers. This resource is only used by Azure Active Directory to generate TGTs for your Active Directory Domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object. When you enable Azure AD Kerberos in a domain, an Azure AD Kerberos Server object is created in your on-premises AD. This object will appear as a Read Only Domain Controller (RODC) object but isn't associated with any physical servers. This resource is only used by Azure Active Directory to generate TGTs for your Active Directory Domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object.
More details on how Azure AD Kerberos enables access to on-premises resources are available in our documentation on [enabling passwordless security key sign-in to on-premises resources](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). There's more information on how Azure AD Kerberos works with Windows Hello for Business cloud trust in the [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview). More details on how Azure AD Kerberos enables access to on-premises resources are available in our documentation on [enabling passwordless security key sign-in to on-premises resources](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). There's more information on how Azure AD Kerberos works with Windows Hello for Business cloud Kerberos trust in the [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-kerberos-trust).
If you're using the hybrid cloud trust deployment model, you _must_ ensure that you have adequate (one or more, depending on your authentication load) Windows Server 2016 or later read-write domain controllers in each Active Directory site where users will be authenticating for Windows Hello for Business. If you're using the hybrid cloud Kerberos trust deployment model, you _must_ ensure that you have adequate (one or more, depending on your authentication load) Windows Server 2016 or later read-write domain controllers in each Active Directory site where users will be authenticating for Windows Hello for Business.
## Prerequisites ## Prerequisites
@ -51,26 +53,26 @@ If you're using the hybrid cloud trust deployment model, you _must_ ensure that
| Patched Windows 10 version 21H2 or patched Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD-joined devices. | | Patched Windows 10 version 21H2 or patched Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD-joined devices. |
| Fully patched Windows Server 2016 or later Domain Controllers | Domain controllers should be fully patched to support updates needed for Azure AD Kerberos. If you're using Windows Server 2016, [KB3534307](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534307-os-build-14393-3474-b181594e-2c6a-14ea-e75b-678efea9d27e) must be installed. If you're using Server 2019, [KB4534321](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534321-os-build-17763-1012-023e84c3-f9aa-3b55-8aff-d512911c459f) must be installed. | | Fully patched Windows Server 2016 or later Domain Controllers | Domain controllers should be fully patched to support updates needed for Azure AD Kerberos. If you're using Windows Server 2016, [KB3534307](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534307-os-build-14393-3474-b181594e-2c6a-14ea-e75b-678efea9d27e) must be installed. If you're using Server 2019, [KB4534321](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534321-os-build-17763-1012-023e84c3-f9aa-3b55-8aff-d512911c459f) must be installed. |
| Azure AD Kerberos PowerShell module | This module is used for enabling and managing Azure AD Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).| | Azure AD Kerberos PowerShell module | This module is used for enabling and managing Azure AD Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).|
| Device management | Windows Hello for Business cloud trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. | | Device management | Windows Hello for Business cloud Kerberos trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. |
### Unsupported Scenarios ### Unsupported Scenarios
The following scenarios aren't supported using Windows Hello for Business cloud trust: The following scenarios aren't supported using Windows Hello for Business cloud Kerberos trust:
- On-premises only deployments - On-premises only deployments
- RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container) - RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container)
- Scenarios that require a certificate for authentication - Scenarios that require a certificate for authentication
- Using cloud trust for "Run as" - Using cloud Kerberos trust for "Run as"
- Signing in with cloud trust on a Hybrid Azure AD joined device without previously signing in with DC connectivity - Signing in with cloud Kerberos trust on a Hybrid Azure AD joined device without previously signing in with DC connectivity
> [!NOTE] > [!NOTE]
> The default security policy for AD does not grant permission to sign high privilege accounts on to on-premises resources with Cloud Trust or FIDO2 security keys. > The default security policy for AD does not grant permission to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys.
> >
> To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (CN=AzureADKerberos,OU=Domain Controllers,\<domain-DN\>). > To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (CN=AzureADKerberos,OU=Domain Controllers,\<domain-DN\>).
## Deployment Instructions ## Deployment Instructions
Deploying Windows Hello for Business cloud trust consists of two steps: Deploying Windows Hello for Business cloud Kerberos trust consists of two steps:
1. Set up Azure AD Kerberos in your hybrid environment. 1. Set up Azure AD Kerberos in your hybrid environment.
1. Configure Windows Hello for Business policy and deploy it to devices. 1. Configure Windows Hello for Business policy and deploy it to devices.
@ -79,11 +81,11 @@ Deploying Windows Hello for Business cloud trust consists of two steps:
If you've already deployed on-premises SSO for passwordless security key sign-in, then you've already deployed Azure AD Kerberos in your hybrid environment. You don't need to redeploy or change your existing Azure AD Kerberos deployment to support Windows Hello for Business and you can skip this section. If you've already deployed on-premises SSO for passwordless security key sign-in, then you've already deployed Azure AD Kerberos in your hybrid environment. You don't need to redeploy or change your existing Azure AD Kerberos deployment to support Windows Hello for Business and you can skip this section.
If you haven't deployed Azure AD Kerberos, follow the instructions in the [Enable passwordless security key sign-in to on-premises resources by using Azure AD](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module) documentation. This page includes information on how to install and use the Azure AD Kerberos Powershell module. Use the module to create an Azure AD Kerberos Server object for the domains where you want to use Windows Hello for Business cloud trust. If you haven't deployed Azure AD Kerberos, follow the instructions in the [Enable passwordless security key sign-in to on-premises resources by using Azure AD](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module) documentation. This page includes information on how to install and use the Azure AD Kerberos Powershell module. Use the module to create an Azure AD Kerberos Server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust.
### Configure Windows Hello for Business Policy ### Configure Windows Hello for Business Policy
After setting up the Azure AD Kerberos Object, Windows Hello for business cloud trust must be enabled using policy. By default, cloud trust won't be used by Hybrid Azure AD joined or Azure AD-joined devices. After setting up the Azure AD Kerberos Object, Windows Hello for business cloud Kerberos trust must be enabled using policy. By default, cloud Kerberos trust won't be used by Hybrid Azure AD joined or Azure AD-joined devices.
#### Configure Using Group Policy #### Configure Using Group Policy
@ -93,14 +95,14 @@ The Enable Windows Hello for Business Group Policy setting is used by Windows to
You can configure the Enable Windows Hello for Business Group Policy setting for computers or users. Deploying this policy setting to computers results in all users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence. You can configure the Enable Windows Hello for Business Group Policy setting for computers or users. Deploying this policy setting to computers results in all users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence.
Cloud trust requires setting a dedicated policy for it to be enabled. This policy is only available as a computer configuration. cloud Kerberos trust requires setting a dedicated policy for it to be enabled. This policy is only available as a computer configuration.
> [!NOTE] > [!NOTE]
> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune](/mem/intune/protect/identity-protection-windows-settings) and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources) > If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune](/mem/intune/protect/identity-protection-windows-settings) and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources)
##### Update Group Policy Objects ##### Update Group Policy Objects
You may need to update your Group Policy definitions to be able to configure the cloud trust policy. You can copy the ADMX and ADML files from a Windows 10 21H2 or Windows 11 device that supports cloud trust to their respective language folder on your Group Policy management server. Windows Hello for Business settings are in the Passport.admx and Passport.adml files. You may need to update your Group Policy definitions to be able to configure the cloud Kerberos trust policy. You can copy the ADMX and ADML files from a Windows 10 21H2 or Windows 11 device that supports cloud Kerberos trust to their respective language folder on your Group Policy management server. Windows Hello for Business settings are in the Passport.admx and Passport.adml files.
You can also create a Group Policy Central Store and copy them their respective language folder. For more information, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store). You can also create a Group Policy Central Store and copy them their respective language folder. For more information, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store).
@ -116,23 +118,23 @@ Sign-in a domain controller or management workstations with *Domain Admin* equiv
1. In the navigation pane, expand **Policies** under **Device Configuration**. 1. In the navigation pane, expand **Policies** under **Device Configuration**.
1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**. 1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**.
1. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**. 1. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**.
1. In the content pane, double-click **Use cloud trust for on-premises authentication**. Click **Enable** and click **OK**. 1. In the content pane, double-click **Use cloud Kerberos trust for on-premises authentication**. Click **Enable** and click **OK**.
1. *Optional but recommended*: In the content pane, double-click **Use a hardware security device**. Click **Enable** and click **OK**. 1. *Optional but recommended*: In the content pane, double-click **Use a hardware security device**. Click **Enable** and click **OK**.
This group policy should be targeted at the computer group that you've created for that you want to use Windows Hello for Business. This group policy should be targeted at the computer group that you've created for that you want to use Windows Hello for Business.
> [!Important] > [!Important]
> If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud trust have this policy not configured or disabled. > If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud Kerberos trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud Kerberos trust have this policy not configured or disabled.
#### Configure Using Intune #### Configure Using Intune
Windows Hello for Business can be enabled using device enrollment or device configuration policy. Device enrollment policy is only applied at device enrollment time. Any modifications to the configuration in Intune won't apply to already enrolled devices. Device configuration policy is applied after device enrollment. Changes to this policy type in Intune are applied to already enrolled devices. Windows Hello for Business can be enabled using device enrollment or device configuration policy. Device enrollment policy is only applied at device enrollment time. Any modifications to the configuration in Intune won't apply to already enrolled devices. Device configuration policy is applied after device enrollment. Changes to this policy type in Intune are applied to already enrolled devices.
The cloud trust policy needs to be configured using a custom template and is configured separately from enabling Windows Hello from Business. The cloud Kerberos trust policy needs to be configured using a custom template and is configured separately from enabling Windows Hello from Business.
##### Create a user Group that will be targeted for Windows Hello for Business ##### Create a user Group that will be targeted for Windows Hello for Business
If you have an existing group you want to target with Windows Hello for Business cloud trust policy, you can skip this step. If you have an existing group you want to target with Windows Hello for Business cloud Kerberos trust policy, you can skip this step.
1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/).
1. Browse to **Groups** and select **New group**. 1. Browse to **Groups** and select **New group**.
@ -140,13 +142,13 @@ If you have an existing group you want to target with Windows Hello for Business
1. Group type: "Security" 1. Group type: "Security"
1. Group name: "WHFBCloudTrustUsers" or a group name of your choosing 1. Group name: "WHFBCloudTrustUsers" or a group name of your choosing
1. Membership type: Assigned 1. Membership type: Assigned
1. Select **Members** and add users that you want to target with Windows Hello for Business cloud trust. 1. Select **Members** and add users that you want to target with Windows Hello for Business cloud Kerberos trust.
You can also create a group through the Azure portal instead of using the Microsoft Endpoint Manager admin center. You can also create a group through the Azure portal instead of using the Microsoft Endpoint Manager admin center.
##### Enable Windows Hello for Business ##### Enable Windows Hello for Business
If you already enabled Windows Hello for Business for a target set of users or devices, you can skip below to configuring the cloud trust policy. Otherwise, follow the instructions at [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello) to create a Windows Hello for Business device enrollment policy. If you already enabled Windows Hello for Business for a target set of users or devices, you can skip below to configuring the cloud Kerberos trust policy. Otherwise, follow the instructions at [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello) to create a Windows Hello for Business device enrollment policy.
You can also follow these steps to create a device configuration policy instead of a device enrollment policy: You can also follow these steps to create a device configuration policy instead of a device enrollment policy:
@ -162,25 +164,25 @@ You can also follow these steps to create a device configuration policy instead
1. Select Next to move to **Assignments**. 1. Select Next to move to **Assignments**.
1. Under Included groups, select **Add groups**. 1. Under Included groups, select **Add groups**.
1. Select the user group you would like to use Windows Hello for Business cloud trust. This group may be WHFBCloudTrustUsers or a group of your choosing. 1. Select the user group you would like to use Windows Hello for Business cloud Kerberos trust. This group may be WHFBCloudTrustUsers or a group of your choosing.
1. Select Next to move to the Applicability Rules. 1. Select Next to move to the Applicability Rules.
1. Select Next again to move to the **Review + create** tab and select the option to create the policy. 1. Select Next again to move to the **Review + create** tab and select the option to create the policy.
Windows Hello for Business settings are also available in the settings catalog. For more information, see [Use the settings catalog to configure settings on Windows and macOS devices - preview](/mem/intune/configuration/settings-catalog). Windows Hello for Business settings are also available in the settings catalog. For more information, see [Use the settings catalog to configure settings on Windows and macOS devices - preview](/mem/intune/configuration/settings-catalog).
##### Configure Cloud Trust policy ##### Configure Cloud Kerberos Trust policy
To configure the cloud trust policy, follow the steps below: To configure the cloud Kerberos trust policy, follow the steps below:
1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/).
1. Browse to Devices > Windows > Configuration Profiles > Create profile. 1. Browse to Devices > Windows > Configuration Profiles > Create profile.
1. For Platform, select Windows 10 and later. 1. For Platform, select Windows 10 and later.
1. For Profile Type, select **Templates** and select the **Custom** Template. 1. For Profile Type, select **Templates** and select the **Custom** Template.
1. Name the profile with a familiar name. For example, "Windows Hello for Business cloud trust". 1. Name the profile with a familiar name. For example, "Windows Hello for Business cloud Kerberos trust".
1. In Configuration Settings, add a new configuration with the following settings: 1. In Configuration Settings, add a new configuration with the following settings:
- Name: "Windows Hello for Business cloud trust" or another familiar name - Name: "Windows Hello for Business cloud Kerberos trust" or another familiar name
- Description: Enable Windows Hello for Business cloud trust for sign-in and on-premises SSO. - Description: Enable Windows Hello for Business cloud Kerberos trust for sign-in and on-premises SSO.
- OMA-URI: ./Device/Vendor/MSFT/PassportForWork/*tenant ID*/Policies/UseCloudTrustForOnPremAuth - OMA-URI: ./Device/Vendor/MSFT/PassportForWork/*tenant ID*/Policies/UseCloudTrustForOnPremAuth
>[!IMPORTANT] >[!IMPORTANT]
@ -193,22 +195,22 @@ To configure the cloud trust policy, follow the steps below:
1. Select Next to navigate to **Assignments**. 1. Select Next to navigate to **Assignments**.
1. Under Included groups, select **Add groups**. 1. Under Included groups, select **Add groups**.
1. Select the user group you would like to use Windows Hello for Business cloud trust. This group may be WHFBCloudTrustUsers or a group of your choosing. 1. Select the user group you would like to use Windows Hello for Business cloud Kerberos trust. This group may be WHFBCloudTrustUsers or a group of your choosing.
1. Select Next to move to the Applicability Rules. 1. Select Next to move to the Applicability Rules.
1. Select Next again to move to the **Review + create** tab and select the option to create the policy. 1. Select Next again to move to the **Review + create** tab and select the option to create the policy.
> [!Important] > [!Important]
> If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud trust have this policy not configured or disabled. > If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud Kerberos trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud Kerberos trust have this policy not configured or disabled.
## Provisioning ## Provisioning
The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business cloud trust adds a prerequisite check for Hybrid Azure AD-joined devices when cloud trust is enabled by policy. The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business cloud Kerberos trust adds a prerequisite check for Hybrid Azure AD-joined devices when cloud Kerberos trust is enabled by policy.
You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs\Microsoft\Windows**. This information is also available using the [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) command from a console. You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs\Microsoft\Windows**. This information is also available using the [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) command from a console.
![Cloud trust prerequisite check in the user device registration log](./images/cloud-trust-prereq-check.png) ![cloud Kerberos trust prerequisite check in the user device registration log](./images/cloud-trust-prereq-check.png)
The cloud trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Azure AD Kerberos is set up for the user's domain and tenant. If Azure AD Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud trust is not being enforced by policy or if the device is Azure AD joined. The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Azure AD Kerberos is set up for the user's domain and tenant. If Azure AD Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust is not being enforced by policy or if the device is Azure AD joined.
This prerequisite check isn't done for provisioning on Azure AD-joined devices. If Azure AD Kerberos isn't provisioned, a user on an Azure AD joined device will still be able to sign in. This prerequisite check isn't done for provisioning on Azure AD-joined devices. If Azure AD Kerberos isn't provisioned, a user on an Azure AD joined device will still be able to sign in.
@ -228,11 +230,11 @@ After a successful MFA, the provisioning flow asks the user to create and valida
### Sign-in ### Sign-in
Once a user has set up a PIN with cloud trust, it can be used immediately for sign-in. On a Hybrid Azure AD joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached logon can be used for subsequent unlocks without line of sight or network connectivity. Once a user has set up a PIN with cloud Kerberos trust, it can be used immediately for sign-in. On a Hybrid Azure AD joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached logon can be used for subsequent unlocks without line of sight or network connectivity.
## Troubleshooting ## Troubleshooting
If you encounter issues or want to share feedback about Windows Hello for Business cloud trust, share via the Windows Feedback Hub app by following these steps: If you encounter issues or want to share feedback about Windows Hello for Business cloud Kerberos trust, share via the Windows Feedback Hub app by following these steps:
1. Open **Feedback Hub**, and make sure that you're signed in. 1. Open **Feedback Hub**, and make sure that you're signed in.
1. Submit feedback by selecting the following categories: 1. Submit feedback by selecting the following categories:
@ -241,24 +243,24 @@ If you encounter issues or want to share feedback about Windows Hello for Busine
## Frequently Asked Questions ## Frequently Asked Questions
### Does Windows Hello for Business cloud trust work in my on-premises environment? ### Does Windows Hello for Business cloud Kerberos trust work in my on-premises environment?
This feature doesn't work in a pure on-premises AD domain services environment. This feature doesn't work in a pure on-premises AD domain services environment.
### Does Windows Hello for Business cloud trust work in a Windows login with RODC present in the hybrid environment? ### Does Windows Hello for Business cloud Kerberos trust work in a Windows login with RODC present in the hybrid environment?
Windows Hello for Business cloud trust looks for a writeable DC to exchange the partial TGT. As long as you have at least one writeable DC per site, login with cloud trust will work. Windows Hello for Business cloud Kerberos trust looks for a writeable DC to exchange the partial TGT. As long as you have at least one writeable DC per site, login with cloud Kerberos trust will work.
### Do I need line of sight to a domain controller to use Windows Hello for Business cloud trust? ### Do I need line of sight to a domain controller to use Windows Hello for Business cloud Kerberos trust?
Windows Hello for Business cloud trust requires line of sight to a domain controller for some scenarios: Windows Hello for Business cloud Kerberos trust requires line of sight to a domain controller for some scenarios:
- The first sign-in or unlock with Windows Hello for Business after provisioning on a Hybrid Azure AD joined device - The first sign-in or unlock with Windows Hello for Business after provisioning on a Hybrid Azure AD joined device
- When attempting to access an on-premises resource from an Azure AD joined device - When attempting to access an on-premises resource from an Azure AD joined device
### Can I use RDP/VDI with Windows Hello for Business cloud trust? ### Can I use RDP/VDI with Windows Hello for Business cloud Kerberos trust?
Windows Hello for Business cloud trust cannot be used as a supplied credential with RDP/VDI. Similar to key trust, cloud trust can be used for RDP with [remote credential guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose. Windows Hello for Business cloud Kerberos trust cannot be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [remote credential guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose.
### Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud trust? ### Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud Kerberos trust?
No, only the number necessary to handle the load from all cloud trust devices. No, only the number necessary to handle the load from all cloud Kerberos trust devices.

4
windows/security/identity-protection/hello-for-business/hello-identity-verification.md
View File

@ -31,7 +31,7 @@ This article lists the infrastructure requirements for the different deployment
The table shows the minimum requirements for each deployment. For key trust in a multi-domain/multi-forest deployment, the following requirements are applicable for each domain/forest that hosts Windows Hello for business components or is involved in the Kerberos referral process. The table shows the minimum requirements for each deployment. For key trust in a multi-domain/multi-forest deployment, the following requirements are applicable for each domain/forest that hosts Windows Hello for business components or is involved in the Kerberos referral process.
| Requirement | Cloud trust (Preview)<br/>Group Policy or Modern managed | Key trust<br/>Group Policy or Modern managed | Certificate trust<br/>Mixed managed | Certificate trust<br/>Modern managed | | Requirement | cloud Kerberos trust<br/>Group Policy or Modern managed | Key trust<br/>Group Policy or Modern managed | Certificate Trust<br/>Mixed managed | Certificate Trust<br/>Modern managed |
| --- | --- | --- | --- | --- | | --- | --- | --- | --- | --- |
| **Windows Version** | Windows 10, version 21H2 with KB5010415; Windows 11 with KB5010414; or later | Windows 10, version 1511 or later| **Hybrid Azure AD Joined:**<br> *Minimum:* Windows 10, version 1703<br> *Best experience:* Windows 10, version 1709 or later (supports synchronous certificate enrollment).<br/>**Azure AD Joined:**<br> Windows 10, version 1511 or later| Windows 10, version 1511 or later | | **Windows Version** | Windows 10, version 21H2 with KB5010415; Windows 11 with KB5010414; or later | Windows 10, version 1511 or later| **Hybrid Azure AD Joined:**<br> *Minimum:* Windows 10, version 1703<br> *Best experience:* Windows 10, version 1709 or later (supports synchronous certificate enrollment).<br/>**Azure AD Joined:**<br> Windows 10, version 1511 or later| Windows 10, version 1511 or later |
| **Schema Version** | No specific Schema requirement | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | | **Schema Version** | No specific Schema requirement | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema |
@ -44,7 +44,7 @@ The table shows the minimum requirements for each deployment. For key trust in a
| **Azure AD License** | Azure AD Premium, optional | Azure AD Premium, optional | Azure AD Premium, needed for device write-back | Azure AD Premium, optional. Intune license required | | **Azure AD License** | Azure AD Premium, optional | Azure AD Premium, optional | Azure AD Premium, needed for device write-back | Azure AD Premium, optional. Intune license required |
> [!Important] > [!Important]
> - Hybrid deployments support non-destructive PIN reset that works with certificate trust, key trust and cloud trust models. > - Hybrid deployments support non-destructive PIN reset that works with Certificate Trust, Key Trust and cloud Kerberos trust models.
> >
> **Requirements:** > **Requirements:**
> - Microsoft PIN Reset Service - Windows 10, versions 1709 to 1809, Enterprise Edition. There is no licensing requirement for this service since version 1903 > - Microsoft PIN Reset Service - Windows 10, versions 1709 to 1809, Enterprise Edition. There is no licensing requirement for this service since version 1903

4
windows/security/identity-protection/hello-for-business/hello-overview.md
View File

@ -94,9 +94,9 @@ For details, see [How Windows Hello for Business works](hello-how-it-works.md).
## Comparing key-based and certificate-based authentication ## Comparing key-based and certificate-based authentication
Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud trust for hybrid deployments, which uses Azure AD as the root of trust. Cloud trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller. Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Azure AD as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
Windows Hello for Business with a key, including cloud trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md). Windows Hello for Business with a key, including cloud Kerberos trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
## Learn more ## Learn more

2
windows/security/identity-protection/hello-for-business/hello-planning-guide.md
View File

@ -93,7 +93,7 @@ It's fundamentally important to understand which deployment model to use for a s
A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory. There are two trust types: key trust and certificate trust. A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory. There are two trust types: key trust and certificate trust.
> [!NOTE] > [!NOTE]
> Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). More information will be available on Windows Hello for Business cloud trust once it is generally available. > Windows Hello for Business introduced a new trust model called cloud Kerberos trust, in early 2022. This model enables deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). For more information, see ./hello-hybrid-cloud-kerberos-trust.md.
The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more. The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.

4
windows/security/identity-protection/hello-for-business/index.yml
View File

@ -65,8 +65,8 @@ landingContent:
url: hello-identity-verification.md url: hello-identity-verification.md
- linkListType: how-to-guide - linkListType: how-to-guide
links: links:
- text: Hybrid Cloud Trust Deployment - text: Hybrid Cloud Kerberos Trust Deployment
url: hello-hybrid-cloud-trust.md url: hello-hybrid-cloud-kerberos-trust.md
- text: Hybrid Azure AD Joined Key Trust Deployment - text: Hybrid Azure AD Joined Key Trust Deployment
url: hello-hybrid-key-trust.md url: hello-hybrid-key-trust.md
- text: Hybrid Azure AD Joined Certificate Trust Deployment - text: Hybrid Azure AD Joined Certificate Trust Deployment

4
windows/security/identity-protection/hello-for-business/toc.yml
View File

@ -35,8 +35,8 @@
href: hello-prepare-people-to-use.md href: hello-prepare-people-to-use.md
- name: Deployment Guides - name: Deployment Guides
items: items:
- name: Hybrid Cloud Trust Deployment - name: Hybrid Cloud Kerberos Trust Deployment
href: hello-hybrid-cloud-trust.md href: hello-hybrid-cloud-kerberos-trust.md
- name: Hybrid Azure AD Joined Key Trust - name: Hybrid Azure AD Joined Key Trust
items: items:
- name: Hybrid Azure AD Joined Key Trust Deployment - name: Hybrid Azure AD Joined Key Trust Deployment