From 63ed3c92e22d2030cf7eb4918c71a2bcf5947f23 Mon Sep 17 00:00:00 2001 From: Matthew Palko Date: Thu, 21 Jan 2021 16:52:46 -0800 Subject: [PATCH 1/2] Add troubleshooting for DC certs from 3rd party CAs --- .../hello-deployment-issues.md | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md index 4dece74866..96f5181b12 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md @@ -45,6 +45,39 @@ After the initial logon attempt, the user's Windows Hello for Business public ke To resolve this behavior, upgrade Windows Server 2016 and 2019 domain controllers to with the latest patches. For Windows Server 2016, this behavior is fixed in build 14393.4104 ([KB4593226](https://support.microsoft.com/help/4593226)) and later. For Windows Server 2019, this behavior is fixed in build 17763.1637 ([KB4592440](https://support.microsoft.com/help/4592440)). +## Azure AD Joined Device Access to On-Premises Resources Using Key Trust and Third-Party Certificate Authority (CA) + +Applies to: + +- Azure AD joined key trust deployments +- Third-party certificate authority (CA) issuing domain controller certificates + +Windows Hello for Business uses smart card based authentication for many operations. Smart card has special guidelines when using a third-party CA for certificate issuance, some of which apply to the domain controllers. Not all Windows Hello for Business deployment types require these configurations. Accessing on-premises resources from an Azure AD Joined device does require special configuration when using a third-party CA to issue domain controller certificates. + +For more information, read [Guidelines for enabling smart card logon with third-party certification authorities]( +https://support.microsoft.com/topic/a34a400a-51d5-f2a1-c8c0-7a6c9c49cb78). + +### Identifying On-premises Resource Access Issues with Third-Party CAs + +This issue can be identified using network traces or Kerberos logging from the client. In the network trace, the client will fail to place a TGS_REQ request when a user attempts to access a resource. On the client, this can be observed in Kerberos event logs: + + The Kerberos client received a KDC certificate that does not have a matched domain name. + Expected Domain Name: ad.contoso.com + Error Code: 0xC000006D + +See [How to enable Kerberos event logging](https://docs.microsoft.com/troubleshoot/windows-server/identity/enable-kerberos-event-logging#enable-kerberos-event-logging-on-a-specific-computer) for information on enabling Kerberos logs on a client device. + +### Resolving On-premises Resource Access Issue with Third-Party CAs + +To resolve this issue, domain controller certificates need to be updated so the certificate subject contains directory path of the server object (distinguished name). +Example Subject: CN=DC1 OU=Domain Controller, DC=ad, DC=contoso, DC=com + +Alternatively, you can set the subject alternative name (SAN) of the domain controller certificate to contain the server object's fully qualified domain name and the NETBIOS name of the domain. +Example Subject Alternative Name: +dns=dc1.ad.contoso.com +dns=ad.contoso.com +dns=ad + ## Key Trust Authentication Broken for Windows Server 2019 Applies to: From 36c2c65cd728ce4e98098f23554b8acf27f1a4da Mon Sep 17 00:00:00 2001 From: Matthew Palko Date: Fri, 22 Jan 2021 09:57:40 -0800 Subject: [PATCH 2/2] updating logging information for 3rd party CA SSO issue --- .../hello-for-business/hello-deployment-issues.md | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md index 96f5181b12..2c22e05685 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md @@ -59,14 +59,23 @@ https://support.microsoft.com/topic/a34a400a-51d5-f2a1-c8c0-7a6c9c49cb78). ### Identifying On-premises Resource Access Issues with Third-Party CAs -This issue can be identified using network traces or Kerberos logging from the client. In the network trace, the client will fail to place a TGS_REQ request when a user attempts to access a resource. On the client, this can be observed in Kerberos event logs: +This issue can be identified using network traces or Kerberos logging from the client. In the network trace, the client will fail to place a TGS_REQ request when a user attempts to access a resource. On the client, this can be observed in the Kerberos operation event log under **Application and Services/Microsoft/Windows/Security-Kerberos/Operational**. These logs are default disabled. The failure event for this case will include the following information: + + Log Name: Microsoft-Windows-Kerberos/Operational + Source: Microsoft-Windows-Security-Kerberos + Event ID: 107 + GUID: {98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1} + Task Category: None + Level: Error + Keywords: + User: SYSTEM + Description: The Kerberos client received a KDC certificate that does not have a matched domain name. + Expected Domain Name: ad.contoso.com Error Code: 0xC000006D -See [How to enable Kerberos event logging](https://docs.microsoft.com/troubleshoot/windows-server/identity/enable-kerberos-event-logging#enable-kerberos-event-logging-on-a-specific-computer) for information on enabling Kerberos logs on a client device. - ### Resolving On-premises Resource Access Issue with Third-Party CAs To resolve this issue, domain controller certificates need to be updated so the certificate subject contains directory path of the server object (distinguished name).