From 1f873c0e34d3f9a4fb9d99bf7b08c77e9279f3f4 Mon Sep 17 00:00:00 2001 From: Nagappan Veerappan Date: Wed, 21 Apr 2021 15:54:11 -0700 Subject: [PATCH 01/14] federation with AADJ updated --- .../hello-for-business/hello-how-it-works-authentication.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index cb21e54fe3..8f124ea552 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -51,6 +51,8 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c |B | The Kerberos provider sends the signed pre-authentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.
The 2016 domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed pre-authentication data using the public key from Active Directory. 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.| +!Note: You may have on-prem domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on the AADJ device. Any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT as well as it trigger authenticate against your DC (if LOS to DC available) to get kerberos.it no longer use ADFS to authenticate for WHFB signins. + ## Azure AD join authentication to Active Directory using a Certificate ![Azure AD join authentication to Active Directory using a Certificate](images/howitworks/auth-aadj-certtrust-kerb.png) @@ -61,6 +63,10 @@ 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.
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.| +!Note: You may have on-prem domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on. Any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT. as well as Authenticate against your DC (if LOS to DC available) to get kerberos as mentioned above. ADFS federation used only when Enterprise PRT calls are placed from client. you need to have device write back enabled to get "Enterprise PRT" from your federation. + + + ## Hybrid Azure AD join authentication using a Key ![Hybrid Azure AD join authentication using a Key](images/howitworks/auth-haadj-keytrust.png) From 85d172fb43d5b1e978cefa35aaa91233afe3c033 Mon Sep 17 00:00:00 2001 From: Nagappan Veerappan Date: Wed, 21 Apr 2021 17:05:52 -0700 Subject: [PATCH 02/14] Update windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md Co-authored-by: Trond B. Krokli <38162891+illfated@users.noreply.github.com> --- .../hello-for-business/hello-how-it-works-authentication.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index 8f124ea552..eb1d1585c6 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -51,7 +51,8 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c |B | The Kerberos provider sends the signed pre-authentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.
The 2016 domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed pre-authentication data using the public key from Active Directory. 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.| -!Note: You may have on-prem domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on the AADJ device. Any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT as well as it trigger authenticate against your DC (if LOS to DC available) to get kerberos.it no longer use ADFS to authenticate for WHFB signins. +> [!NOTE] +> You may have on-premises domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on the AADJ device. Any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT, as well as it trigger authenticate against your DC (if LOS to DC available) to get Kerberos. It no longer uses ADFS to authenticate for WHFB sign-ins. ## Azure AD join authentication to Active Directory using a Certificate From 7cc89e4a49eed7339710895235b95ddf597afc62 Mon Sep 17 00:00:00 2001 From: Nagappan Veerappan Date: Thu, 22 Apr 2021 12:45:13 -0700 Subject: [PATCH 03/14] Update windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md Co-authored-by: Trond B. Krokli <38162891+illfated@users.noreply.github.com> --- .../hello-for-business/hello-how-it-works-authentication.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index eb1d1585c6..411edf3dbe 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -64,7 +64,8 @@ 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.
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.| -!Note: You may have on-prem domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on. Any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT. as well as Authenticate against your DC (if LOS to DC available) to get kerberos as mentioned above. ADFS federation used only when Enterprise PRT calls are placed from client. you need to have device write back enabled to get "Enterprise PRT" from your federation. +> [!NOTE] +> You may have on-premises domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on, any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT, as well as Authenticate against your DC (if LOS to DC available) to get Kerberos as mentioned above. ADFS federation 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. From 9a9413f449f0500fb911b5f223c1f1e42fe397fd Mon Sep 17 00:00:00 2001 From: Nagappan Veerappan Date: Thu, 22 Apr 2021 12:45:19 -0700 Subject: [PATCH 04/14] Update windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md Co-authored-by: Trond B. Krokli <38162891+illfated@users.noreply.github.com> --- .../hello-for-business/hello-how-it-works-authentication.md | 1 - 1 file changed, 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index 411edf3dbe..cb941338ef 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -68,7 +68,6 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c > You may have on-premises domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on, any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT, as well as Authenticate against your DC (if LOS to DC available) to get Kerberos as mentioned above. ADFS federation 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 a Key ![Hybrid Azure AD join authentication using a Key](images/howitworks/auth-haadj-keytrust.png) From 0f716c0357e267c18c504cc5021694f9a2a058a1 Mon Sep 17 00:00:00 2001 From: Nagappan Veerappan Date: Thu, 22 Apr 2021 12:45:45 -0700 Subject: [PATCH 05/14] Update windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../hello-for-business/hello-how-it-works-authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index cb941338ef..d0647fff25 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -52,7 +52,7 @@ 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.| > [!NOTE] -> You may have on-premises domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on the AADJ device. Any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT, as well as it trigger authenticate against your DC (if LOS to DC available) to get Kerberos. It no longer uses ADFS to authenticate for WHFB sign-ins. +> You might have an on-premises domain federated with Azure AD. Once you have successfully provisioned WHFB PIN/Bio on the AADJ device, any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses ADFS to authenticate for WHFB sign-ins. ## Azure AD join authentication to Active Directory using a Certificate From 79baead0da39f0f95efc61892a22776e41fefb46 Mon Sep 17 00:00:00 2001 From: Sunny Zankharia <67922512+sazankha@users.noreply.github.com> Date: Fri, 23 Apr 2021 15:22:28 -0700 Subject: [PATCH 06/14] Update faq-md-app-guard.md --- .../microsoft-defender-application-guard/faq-md-app-guard.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.md b/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.md index 5d37b3aa5d..9a7f8f0ed3 100644 --- a/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.md +++ b/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.md @@ -143,7 +143,7 @@ In the Microsoft Defender Firewall user interface go through the following steps There is a known issue such that if you change the Exploit Protection settings for CFG and possibly others, hvsimgr cannot launch. To mitigate this issue, go to **Windows Security** > **App and Browser control** > **Exploit Protection Setting**, and then switch CFG to **use default**. -### How can I have ICS in enabled state yet still use Application Guard? +### How can I disable portions of ICS without breaking Application Guard? ICS is enabled by default in Windows, and ICS must be enabled in order for Application Guard to function correctly. We do not recommend disabling ICS; however, you can disable ICS in part by using a Group Policy and editing registry keys. @@ -184,4 +184,4 @@ Policy: Allow installation of devices using drivers that match these device setu ## See also -[Configure Microsoft Defender Application Guard policy settings](./configure-md-app-guard.md) \ No newline at end of file +[Configure Microsoft Defender Application Guard policy settings](./configure-md-app-guard.md) From 387603e22ebcb7f83d952068ec1fc942df2940fc Mon Sep 17 00:00:00 2001 From: Nagappan Veerappan Date: Fri, 23 Apr 2021 19:07:26 -0700 Subject: [PATCH 07/14] Update windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../hello-for-business/hello-how-it-works-authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index d0647fff25..41ee599349 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -52,7 +52,7 @@ 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.| > [!NOTE] -> You might have an on-premises domain federated with Azure AD. Once you have successfully provisioned WHFB PIN/Bio on the AADJ device, any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses ADFS to authenticate for WHFB sign-ins. +> You might have an on-premises domain federated with Azure AD. Once you have successfully provisioned Windows Hello for Business PIN/Bio on the Azure AD joined device, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Azure AD to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses AD FS to authenticate for Windows Hello for Business sign-ins. ## Azure AD join authentication to Active Directory using a Certificate From cc5989f5a5593c9442241f7425676b7d2c0dcfe0 Mon Sep 17 00:00:00 2001 From: Nagappan Veerappan Date: Fri, 23 Apr 2021 19:07:52 -0700 Subject: [PATCH 08/14] Update windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../hello-for-business/hello-how-it-works-authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index 41ee599349..7439db90b9 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -65,7 +65,7 @@ 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.| > [!NOTE] -> You may have on-premises domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on, any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT, as well as Authenticate against your DC (if LOS to DC available) to get Kerberos as mentioned above. ADFS federation 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 ppreviously. 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 a Key From 79b50f7fb3b48f346ac0cb221b4f38f390069ca0 Mon Sep 17 00:00:00 2001 From: Kateyanne <67609554+Kateyanne@users.noreply.github.com> Date: Mon, 26 Apr 2021 11:15:18 -0700 Subject: [PATCH 09/14] Update windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../hello-for-business/hello-how-it-works-authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index 7439db90b9..73e3d5e47f 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -65,7 +65,7 @@ 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.| > [!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 ppreviously. 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 a Key From 9deaa3f1d7c99570b618dbeb20ee19cac3801b66 Mon Sep 17 00:00:00 2001 From: Charles Inglis <32555877+cinglis-msft@users.noreply.github.com> Date: Mon, 26 Apr 2021 14:22:18 -0400 Subject: [PATCH 10/14] Adding compatible regions Update Compliance is only compatible with certain regions. Customers have run into issues configuring for newer Log Analytics regions that do not support Update Compliance. Adding the list of regions in onboarding for reference. --- .../update/update-compliance-get-started.md | 34 +++++++++++++++++-- 1 file changed, 32 insertions(+), 2 deletions(-) diff --git a/windows/deployment/update/update-compliance-get-started.md b/windows/deployment/update/update-compliance-get-started.md index e686447597..9298206139 100644 --- a/windows/deployment/update/update-compliance-get-started.md +++ b/windows/deployment/update/update-compliance-get-started.md @@ -41,11 +41,41 @@ Update Compliance is offered as an Azure Marketplace application which is linked 1. Go to the [Update Compliance page in the Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps/Microsoft.WaaSUpdateInsights?tab=Overview). You may need to login to your Azure subscription to access this. 2. Select **Get it now**. -3. Choose an existing or configure a new Log Analytics Workspace. While an Azure subscription is required, you will not be charged for ingestion of Update Compliance data. +3. Choose an existing or configure a new Log Analytics Workspace, ensuring it is in a **Compatible Log Analytics region** from the table below. While an Azure subscription is required, you will not be charged for ingestion of Update Compliance data. - [Desktop Analytics](/sccm/desktop-analytics/overview) customers are advised to use the same workspace for Update Compliance. - [Azure Update Management](/azure/automation/automation-update-management) customers are advised to use the same workspace for Update Compliance. 4. After your workspace is configured and selected, select **Create**. You will receive a notification when the solution has been successfully created. +|Compatible Log Analytics regions | +| ------------------------------- | +|Australia Central | +|Australia East | +|Australia Southeast | +|Brazil South | +|Canada Central | +|Central India | +|Central US | +|East Asia | +|East US | +|East US 2 | +|Eastus2euap(canary) | +|France Central | +|Japan East | +|Korea Central | +|North Central US | +|North Europe | +|South Africa North | +|South Central US | +|Southeast Asia | +|Switzerland North | +|Switzerland West | +|UK West | +|UK south | +|West Central US | +|West Europe | +|West US | +|West US 2 | + > [!NOTE] > It is not currently supported to programmatically enroll to Update Compliance via the [Azure CLI](/cli/azure) or otherwise. You must manually add Update Compliance to your Azure subscription. @@ -80,4 +110,4 @@ To download the script and learn what you need to configure and how to troublesh ### Configure devices manually -It is possible to manually configure devices to send data to Update Compliance, but the recommended method of configuration is to use the [Update Compliance Configuration Script](update-compliance-configuration-script.md). To learn more about configuring devices manually, see [Manually Configuring Devices for Update Compliance](update-compliance-configuration-manual.md). \ No newline at end of file +It is possible to manually configure devices to send data to Update Compliance, but the recommended method of configuration is to use the [Update Compliance Configuration Script](update-compliance-configuration-script.md). To learn more about configuring devices manually, see [Manually Configuring Devices for Update Compliance](update-compliance-configuration-manual.md). From b704f4e6228e31b3d56663679d6593e66d84c868 Mon Sep 17 00:00:00 2001 From: Jaime Ondrusek Date: Mon, 26 Apr 2021 11:28:31 -0700 Subject: [PATCH 11/14] Update update-compliance-get-started.md --- .../deployment/update/update-compliance-get-started.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/windows/deployment/update/update-compliance-get-started.md b/windows/deployment/update/update-compliance-get-started.md index 9298206139..f7bc296b2f 100644 --- a/windows/deployment/update/update-compliance-get-started.md +++ b/windows/deployment/update/update-compliance-get-started.md @@ -41,10 +41,10 @@ Update Compliance is offered as an Azure Marketplace application which is linked 1. Go to the [Update Compliance page in the Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps/Microsoft.WaaSUpdateInsights?tab=Overview). You may need to login to your Azure subscription to access this. 2. Select **Get it now**. -3. Choose an existing or configure a new Log Analytics Workspace, ensuring it is in a **Compatible Log Analytics region** from the table below. While an Azure subscription is required, you will not be charged for ingestion of Update Compliance data. - - [Desktop Analytics](/sccm/desktop-analytics/overview) customers are advised to use the same workspace for Update Compliance. - - [Azure Update Management](/azure/automation/automation-update-management) customers are advised to use the same workspace for Update Compliance. -4. After your workspace is configured and selected, select **Create**. You will receive a notification when the solution has been successfully created. +3. Choose an existing or configure a new Log Analytics Workspace, ensuring it is in a **Compatible Log Analytics region** from the following table. Although an Azure subscription is required, you won't be charged for ingestion of Update Compliance data. + - [Desktop Analytics](/sccm/desktop-analytics/overview) users should use the same workspace for Update Compliance. + - [Azure Update Management](/azure/automation/automation-update-management) users should use the same workspace for Update Compliance. +4. After your workspace is configured and selected, select **Create**. You'll receive a notification when the solution has been successfully created. |Compatible Log Analytics regions | | ------------------------------- | From 91892b35bacbae864fb2c2ed6a8b4350a07c96c7 Mon Sep 17 00:00:00 2001 From: Denise Vangel-MSFT Date: Mon, 26 Apr 2021 14:05:16 -0700 Subject: [PATCH 12/14] Update faq-md-app-guard.md --- .../faq-md-app-guard.md | 43 +++++++++++-------- 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.md b/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.md index 9a7f8f0ed3..61f3f7421b 100644 --- a/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.md +++ b/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.md @@ -8,7 +8,7 @@ ms.pagetype: security ms.localizationpriority: medium author: denisebmsft ms.author: deniseb -ms.date: 01/21/2021 +ms.date: 04/26/2021 ms.reviewer: manager: dansimp ms.custom: asr @@ -19,11 +19,12 @@ ms.technology: mde **Applies to:** [Microsoft Defender for Endpoint](https://go.microsoft.com/fwlink/p/?linkid=2069559) -Answering frequently asked questions about Microsoft Defender Application Guard (Application Guard) features, integration with the Windows operating system, and general configuration. +This article lists frequently asked questions with answers for Microsoft Defender Application Guard (Application Guard). Questions span features, integration with the Windows operating system, and general configuration. ## Frequently Asked Questions ### Can I enable Application Guard on machines equipped with 4-GB RAM? + We recommend 8-GB RAM for optimal performance but you can use the following registry DWORD values to enable Application Guard on machines that aren't meeting the recommended hardware configuration. `HKLM\software\Microsoft\Hvsi\SpecRequiredProcessorCount` (Default is four cores.) @@ -34,25 +35,25 @@ We recommend 8-GB RAM for optimal performance but you can use the following regi ### Can employees download documents from the Application Guard Edge session onto host devices? -In Windows 10 Enterprise edition 1803, users are able to download documents from the isolated Application Guard container to the host PC. This capability is managed by policy. +In Windows 10 Enterprise edition, version 1803, users are able to download documents from the isolated Application Guard container to the host PC. This capability is managed by policy. -In Windows 10 Enterprise edition 1709 or Windows 10 Professional edition 1803, it is not possible to download files from the isolated Application Guard container to the host PC. However, employees can use the **Print as PDF** or **Print as XPS** options and save those files to the host device. +In Windows 10 Enterprise edition, version 1709, or Windows 10 Professional edition, version 1803, it is not possible to download files from the isolated Application Guard container to the host computer. However, employees can use the **Print as PDF** or **Print as XPS** options and save those files to the host device. ### Can employees copy and paste between the host device and the Application Guard Edge session? Depending on your organization's settings, employees can copy and paste images (.bmp) and text to and from the isolated container. -### Why don't employees see their Favorites in the Application Guard Edge session? +### Why don't employees see their favorites in the Application Guard Edge session? -To help keep the Application Guard Edge session secure and isolated from the host device, we don't copy the Favorites stored in the Application Guard Edge session back to the host device. +To help keep the Application Guard Edge session secure and isolated from the host device, favorites that are stored in the Application Guard Edge session are not copied back to the host device. -### Why aren’t employees able to see their Extensions in the Application Guard Edge session? +### Why aren’t employees able to see their extensions in the Application Guard Edge session? -Currently, the Application Guard Edge session doesn't support Extensions. However, we're closely monitoring your feedback about this. +Currently, the Application Guard Edge session doesn't support extensions. However, we're closely monitoring your feedback about this. ### How do I configure Microsoft Defender Application Guard to work with my network proxy (IP-Literal Addresses)? -Microsoft Defender Application Guard requires proxies to have a symbolic name, not just an IP address. IP-Literal proxy settings such as `192.168.1.4:81` can be annotated as `itproxy:81` or using a record such as `P19216810010` for a proxy with an IP address of `192.168.100.10`. This applies to Windows 10 Enterprise edition 1709 or higher. These would be for the proxy policies under Network Isolation in Group Policy or Intune. +Application Guard requires proxies to have a symbolic name, not just an IP address. IP-Literal proxy settings such as `192.168.1.4:81` can be annotated as `itproxy:81` or using a record such as `P19216810010` for a proxy with an IP address of `192.168.100.10`. This applies to Windows 10 Enterprise edition, version 1709 or higher. These would be for the proxy policies under Network Isolation in Group Policy or Intune. ### Which Input Method Editors (IME) in 19H1 are not supported? @@ -102,7 +103,7 @@ Mandatory network isolation GP policy to deploy Application Guard: "DomainSubnet Mandatory network isolation CSP policy to deploy Application Guard: "EnterpriseCloudResources or (EnterpriseIpRange and EnterpriseNetworkDomainNames)" For EnterpriseNetworkDomainNames, there is no mapped CSP policy. -Microsoft Defender Application Guard accesses files from a VHD mounted on the host that needs to be written during setup. If an encryption driver prevents a VHD from being mounted or from being written to, Application Guard does not work and results in an error message (`0x80070013 ERROR_WRITE_PROTECT`). +Application Guard accesses files from a VHD mounted on the host that needs to be written during setup. If an encryption driver prevents a VHD from being mounted or from being written to, Application Guard does not work and results in an error message (`0x80070013 ERROR_WRITE_PROTECT`). ### Why did Application Guard stop working after I turned off hyperthreading? @@ -128,21 +129,24 @@ First rule (DHCP Server): Second rule (DHCP Client) This is the same as the first rule, but scoped to local port 68. In the Microsoft Defender Firewall user interface go through the following steps: -1. Right click on inbound rules, create a new rule. +1. Right-click on inbound rules, and then create a new rule. 2. Choose **custom rule**. -3. Program path: `%SystemRoot%\System32\svchost.exe`. -4. Protocol Type: UDP, Specific ports: 67, Remote port: any. -5. Any IP addresses. -6. Allow the connection. -7. All profiles. -8. The new rule should show up in the user interface. Right click on the **rule** > **properties**. -9. In the **Programs and services** tab, Under the **Services** section click on **settings**. Choose **Apply to this Service** and select **Internet Connection Sharing (ICS) Shared Access**. +3. Specify the following program path: `%SystemRoot%\System32\svchost.exe`. +4. Specify the following settings: + - Protocol Type: UDP + - Specific ports: 67 + - Remote port: any +6. Specify any IP addresses. +7. Allow the connection. +8. Specify to use all profiles. +9. The new rule should show up in the user interface. Right click on the **rule** > **properties**. +10. In the **Programs and services** tab, under the **Services** section, select **settings**. +11. Choose **Apply to this Service** and select **Internet Connection Sharing (ICS) Shared Access**. ### Why can I not launch Application Guard when Exploit Guard is enabled? There is a known issue such that if you change the Exploit Protection settings for CFG and possibly others, hvsimgr cannot launch. To mitigate this issue, go to **Windows Security** > **App and Browser control** > **Exploit Protection Setting**, and then switch CFG to **use default**. - ### How can I disable portions of ICS without breaking Application Guard? ICS is enabled by default in Windows, and ICS must be enabled in order for Application Guard to function correctly. We do not recommend disabling ICS; however, you can disable ICS in part by using a Group Policy and editing registry keys. @@ -161,6 +165,7 @@ ICS is enabled by default in Windows, and ICS must be enabled in order for Appli 5. Reboot the device. ### Why doesn't the container fully load when device control policies are enabled? + Allow-listed items must be configured as "allowed" in the Group Policy Object ensure AppGuard works properly. Policy: Allow installation of devices that match any of these device IDs From afd5531a0d2f9ed2ef54379810499489383aea3b Mon Sep 17 00:00:00 2001 From: Jaime Ondrusek Date: Mon, 26 Apr 2021 14:24:25 -0700 Subject: [PATCH 13/14] Update update-compliance-get-started.md Fixing (I think) link to Azure automation update management. It would have been broken in the original version of the article as well. --- windows/deployment/update/update-compliance-get-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/deployment/update/update-compliance-get-started.md b/windows/deployment/update/update-compliance-get-started.md index f7bc296b2f..9bd21c5fd2 100644 --- a/windows/deployment/update/update-compliance-get-started.md +++ b/windows/deployment/update/update-compliance-get-started.md @@ -43,7 +43,7 @@ Update Compliance is offered as an Azure Marketplace application which is linked 2. Select **Get it now**. 3. Choose an existing or configure a new Log Analytics Workspace, ensuring it is in a **Compatible Log Analytics region** from the following table. Although an Azure subscription is required, you won't be charged for ingestion of Update Compliance data. - [Desktop Analytics](/sccm/desktop-analytics/overview) users should use the same workspace for Update Compliance. - - [Azure Update Management](/azure/automation/automation-update-management) users should use the same workspace for Update Compliance. + - [Azure Update Management](/azure/automation/automation-intro#update-management) users should use the same workspace for Update Compliance. 4. After your workspace is configured and selected, select **Create**. You'll receive a notification when the solution has been successfully created. |Compatible Log Analytics regions | From 9164d2d0b399e3f8f7d443d92f44f0132f8ee9d3 Mon Sep 17 00:00:00 2001 From: Thomas Raya Date: Mon, 26 Apr 2021 14:32:24 -0700 Subject: [PATCH 14/14] Acrolinx fixes re-adding fixes made by a PR reviewer that were overwritten by a force-push --- .../hello-how-it-works-authentication.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index 73e3d5e47f..a90f1587c2 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -35,7 +35,7 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c | Phase | Description | | :----: | :----------- | -|A | Authentication begins when the users 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 passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.| +|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 passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.| |B | The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory.| |C | 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.| |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.| @@ -47,9 +47,9 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c | Phase | Description | | :----: | :----------- | -|A | Authentication to Active Directory from a Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After the provider locates an active 2016 domain controller, the provider uses the private key to sign the Kerberos pre-authentication data.| +|A | Authentication to Active Directory from an Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After the provider locates an active 2016 domain controller, the provider uses the private key to sign the Kerberos pre-authentication data.| |B | The Kerberos provider sends the signed pre-authentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.
The 2016 domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed pre-authentication data using the public key from Active Directory. 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 been 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.| > [!NOTE] > You might have an on-premises domain federated with Azure AD. Once you have successfully provisioned Windows Hello for Business PIN/Bio on the Azure AD joined device, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Azure AD to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses AD FS to authenticate for Windows Hello for Business sign-ins. @@ -60,9 +60,9 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c | Phase | Description | | :----: | :----------- | -|A | Authentication to Active Directory from a Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider use the private key to sign the Kerberos pre-authentication data.| +|A | Authentication to Active Directory from a Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider uses the private key to sign the Kerberos pre-authentication data.| |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.
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 been 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.| > [!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. @@ -73,9 +73,9 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c | Phase | Description | | :----: | :----------- | -|A | Authentication begins when the users 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 passes the collected credentials to the Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.| +|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 passes the collected credentials to the Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.| |B | The Kerberos provider sends the signed pre-authentication data and the user's public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.
The 2016 domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed pre-authentication data using the public key from Active Directory. 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. +|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 been 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. |D | After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.| |E | Lsass informs winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| |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.| @@ -89,9 +89,9 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c | Phase | Description | | :----: | :----------- | -|A | Authentication begins when the users 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 passes the collected credentials to the Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.| +|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 passes the collected credentials to the Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.| |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.
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. +|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 been 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. |D | After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.| |E | Lsass informs winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| |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.|