mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-29 13:47:23 +00:00
Merge pull request #3397 from MicrosoftDocs/FromPrivateRepo
From private repo
This commit is contained in:
commit
cd65242f44
@ -40,7 +40,6 @@ 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.|
|
||||||
|
|
||||||
[Return to top](#Windows-Hello-for-Business-and-Authentication)
|
|
||||||
## Azure AD join authentication to Active Directory using a Key
|
## Azure AD join authentication to Active Directory using a Key
|
||||||

|

|
||||||
|
|
||||||
@ -52,7 +51,6 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
|
|||||||
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it has not be revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it has not be revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
|
||||||
|
|
||||||
|
|
||||||
[Return to top](#Windows-Hello-for-Business-and-Authentication)
|
|
||||||
## Azure AD join authentication to Active Directory using a Certificate
|
## Azure AD join authentication to Active Directory using a Certificate
|
||||||

|

|
||||||
|
|
||||||
@ -62,7 +60,6 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
|
|||||||
|B | The Kerberos provider sends the signed pre-authentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is not self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and has not been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed pre-authentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|
|B | The Kerberos provider sends the signed pre-authentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is not self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and has not been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed pre-authentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|
||||||
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it has not be revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it has not be revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
|
||||||
|
|
||||||
[Return to top](#Windows-Hello-for-Business-and-Authentication)
|
|
||||||
## Hybrid Azure AD join authentication using a Key
|
## Hybrid Azure AD join authentication using a Key
|
||||||

|

|
||||||
|
|
||||||
@ -76,7 +73,6 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
|
|||||||
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce.|
|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce.|
|
||||||
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory. Azure Active Directory 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 returns it to the Cloud AP provider.<br>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.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory. Azure Active Directory 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 returns it to the Cloud AP provider.<br>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.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
|
||||||
|
|
||||||
[Return to top](#Windows-Hello-for-Business-and-Authentication)
|
|
||||||
## Hybrid Azure AD join authentication using a Certificate
|
## Hybrid Azure AD join authentication using a Certificate
|
||||||

|

|
||||||
|
|
||||||
@ -90,6 +86,3 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
|
|||||||
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce.|
|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce.|
|
||||||
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory. Azure Active Directory 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 returns it to the Cloud AP provider.<br>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.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory. Azure Active Directory 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 returns it to the Cloud AP provider.<br>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.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
|
||||||
|
|
||||||
[Return to top](#Windows-Hello-for-Business-and-Authentication)
|
|
||||||
|
|
||||||
|
|
||||||
|
@ -28,7 +28,7 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
|||||||
[Azure AD joined provisioning in a Federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)<br>
|
[Azure AD joined provisioning in a Federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)<br>
|
||||||
[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)<br>
|
[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)<br>
|
||||||
[Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Managed environment](#hybrid-azure-ad-joined-provisioning-in-a-certificate-trust-deployment-in-a-managed-environment)<br>
|
[Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Managed environment](#hybrid-azure-ad-joined-provisioning-in-a-certificate-trust-deployment-in-a-managed-environment)<br>
|
||||||
[Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Federated environment](#hybrid-azure-ad-joined-provisioning-in-a-certificate-trust-deployment-in-a-federated-environment)<br>
|
[Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Federated environment](#hybrid-azure-ad-joined-provisioning-in-a-certificate-trust-deployment-in-a-managed-environment)<br>
|
||||||
[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Managed environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-managed-environment)<br>
|
[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Managed environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-managed-environment)<br>
|
||||||
[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)<br>
|
[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)<br>
|
||||||
[Domain joined provisioning in an On-premises Key Trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)<br>
|
[Domain joined provisioning in an On-premises Key Trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)<br>
|
||||||
|
@ -53,7 +53,7 @@ If you are installing a server manually, such as a stand-alone server, then choo
|
|||||||
|
|
||||||
Additionally, lights out data centers can take advantage of the enhanced security of a second factor while avoiding the need for user intervention during reboots by optionally using a combination of BitLocker (TPM+PIN) and BitLocker Network Unlock. BitLocker Network Unlock brings together the best of hardware protection, location dependence, and automatic unlock, while in the trusted location. For the configuration steps, see [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md).
|
Additionally, lights out data centers can take advantage of the enhanced security of a second factor while avoiding the need for user intervention during reboots by optionally using a combination of BitLocker (TPM+PIN) and BitLocker Network Unlock. BitLocker Network Unlock brings together the best of hardware protection, location dependence, and automatic unlock, while in the trusted location. For the configuration steps, see [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md).
|
||||||
|
|
||||||
For more information, see the Bitlocker FAQs article and other useful links in [Related Articles](#articles).
|
For more information, see the Bitlocker FAQs article and other useful links in [Related Articles](#related-articles).
|
||||||
|
|
||||||
## PowerShell examples
|
## PowerShell examples
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user