From 1f873c0e34d3f9a4fb9d99bf7b08c77e9279f3f4 Mon Sep 17 00:00:00 2001 From: Nagappan Veerappan Date: Wed, 21 Apr 2021 15:54:11 -0700 Subject: [PATCH 1/8] 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 2/8] 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 3/8] 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 4/8] 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 5/8] 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 387603e22ebcb7f83d952068ec1fc942df2940fc Mon Sep 17 00:00:00 2001 From: Nagappan Veerappan Date: Fri, 23 Apr 2021 19:07:26 -0700 Subject: [PATCH 6/8] 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 7/8] 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 8/8] 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