Seamless Security: Smartcard Logon from Entra-Only Machines to domain-joined Servers or AVDs
There’s still life in the old dog yet: Even though many consider smart cards as obsolete, with MFA phishing becoming an increasing significant threat, this authentication method is experiencing a renaissance. In other scenarios, smart cards are regulatory requirements or simply a phishing-resistant MFA method which has already been deployed to every user in the organization and only needs to be extended to the cloud. However, the only method of authentication towards Active Directory using a smart card certificate is via the Kerberos PKINITextension (which obviously requires Kerberos authentication) and only works with “line of sight” to a Domain Controller (e.g. through VPN). This is because for security reasons, NLA (Network Level Authentication) for RDP is enforced. NLA falls back to NTLM when there is no line of sight between the client and the Domain Controller. To overcome this problem, we must implement a KDC proxy. Although there is documentation for KDC proxy, I stumbled into some traps when implementing it for the first time in a PAW (Privileged Access Workstation) to AVD (Azure Virtual Desktop) scenario, in which the PAW was Entra joined only and NOT domain-joined. That’s why I decided to write down my learnings. Please note It is irrelevant whether the client starting the authentication process is stand-alone, or Entra-joined, or domain-joined or even hybrid-joined. Without “line of sight” to a DC, smart card authentication to a domain-joined system (like an RDP server or Azure Virtual Desktop (AVD)) only works when a KDC proxy has been implemented. As announced in The evolution of Windows authentication, Windows 11 and Server 2025 will soon introduce an extension to the Kerberos protocol called IAKerb, which allows clients to authenticate with Kerberos in more diverse network topologies and will replace KDC proxy for most scenarios. WH4B (Windows Hello for Business) allows SSO from a client to a hybrid-joined AVD without KDC proxy. KDC Proxy in a Nutshell The KDC (Key Distribution Center) proxy is a service that runs a web listener at https://+:443/kdcproxy and relays Kerberos messages to a Domain Controller for the clients inside a TLS tunnel. Clients know that a proxy exists via a GPO/Intune/registry/RDP setting, so if they cannot reach a DC over Kerberos, they will try the proxy instead. Please note the KDC proxy was originally built for services like RD Gateway and DirectAccess and SMB over QUIC and although there are articles on the Internet describing how to use it with Windows Hello for Business, official support is limited to these services. we recommend publishing the KDC proxy via a reverse proxy (e.g. Entra Application Proxy), but will not cover this topic here to avoid publishing a TL;DR article. KDC Proxy & AVDs When it comes to KDC proxy and AVDs, there are two components to the Azure Virtual Desktop service that need to be authenticated: The feed in the Azure Virtual Desktop client that gives users a list of available desktops or applications they have access to. This authentication process happens in Microsoft Entra ID and allows us to apply modern protection mechanisms like Conditional Access or Identity Protection. However, this component isn't the focus of this article. The RDP session that results from a user selecting one of those available resources. This component uses Kerberos authentication and requires a KDC proxy as described above. Communication & Certificates Different certificates are involved in the logon process and as many folks struggle when it comes to certificates, the diagrams below show the key facts about the authentication flow and certificates involved: The KDC proxy relays Kerberos messages (authentication and change password messages) between client and DC. For obvious reasons these messages must travel through the Internet only inside a TLS tunnel (Fig.1 (1)). To terminate this tunnel the server hosting the KDC proxy must be accessible through port 443 from the Internet and present a certificate (Fig.1 (2))... which is trusted by the client (revocation checking and chain building must work from the view of the client as well as the KDC proxy server) with a SAN exactly matching EXACTLY the external URL of the KDC Proxy (Fig 1 (3)). which includes the “Server Authentication” EKU. It can be either issued by a public CA or by a properly configured internal CA (properly configured, which does not leak information to the Internet through the certificates it issues). An Admin configures the KDC proxy name (“kdc-proxy.fabrikam.com” in the diagram below) in the AVD’s properties (Fig.1 (3)). Fig.1 The user connects to AVD in the Windows app. After successful authentication to Entra ID (Fig.2 (4)) the user will authenticate to the KDC proxy using the smart card certificate (TLS client certificate authentication (Fig.2 (5))). The KDC proxy relies on DC location (MS-NRPC) to find KDCs and then relays the Kerberos messages coming from the client to the DC and back again (Fig.2 (6)). Fig.2 User authenticates with Kerberos-based smart card authentication (PKInit) to AD (Fig.3 (7)). PKInit is mutual authentication which is why the DC also needs a certificate (Fig.3 (8)). Finally, the user accesses the AVD via a TLS tunnel Fig.3 (9)). Fig.3 Implementation Prerequisite: Domain Controller Certificates Smart card authentication in Active Directory- regardless of the KDC proxy – is based on a Kerberos extension called PKInit and requires the DCs to have certificates in place. We recommend using the Kerberos Authentication certificate template when using AD Certificate Services. The DC certificates must meet the following certificate requirements and enumeration: The Certificate Revocation List (CRL) distribution point extension must point to an accessible and valid CRL, or an Authority Information Access (AIA) extension that points to an Online Certificate Status Protocol (OCSP) responder. Optionally, the certificate Subject section could contain the directory path of the server object (the distinguished name). The certificate SAN (Subject Alternative Name) section must contain the DC’s Domain Name System (DNS) name. The certificate Key Usage section must contain Digital Signature and Key Encipherment. Optionally, the certificate Basic Constraints section should contain: [Subject Type=End Entity, Path Length Constraint=None]. The DC certificate must either of the following extended key usage (EKU): a) Server Authentication (1.3.6.1.5.5.7.3.1), Client Authentication (1.3.6.1.5.5.7.3.2) and Smart Card Logon (1.3.6.1.4.1.311.20.2.2). b) Server Authentication (1.3.6.1.5.5.7.3.1) and KDC Authentication (1.3.6.1.5.2.3.5) à RECOMMENDED! c) ...or have the value DomainController, encoded as a BMPstring (NOT RECOMMENDED!) The DC certificate must be installed in the local computer's certificate store (and trusted by all domain members). The CA certificate signing the DC certificates must be published to the NTAuth store in AD. The NTAuth store is an object in the Services partition of AD. CA certificates which are trustworthy for AD authentication are published to the NTAuth object and from there replicated to the Enterprise certificate store on all members of the AD Forest. Smart card authentication or Windows Hello for Business (Key Trust or Certificate Trust) only work with the issuing CA certificate published to NTAuth. Whether it is about KDC proxy or not, we recommend enabling the following features for smart card authentication: PKInit Freshness Extension is an enhancement to the PKInit protocol which ensures that the client possesses the private key used for authentication in the moment of authentication. Otherwise, a client could generate requests with future time stamps and then send those requests at some time in future (e.g. when the user has removed the smart card from the device).. Strict KDC Validation is a security feature in Kerberos authentication that ensures the integrity and authenticity of the KDC. It involves a more restrictive set of criteria to validate the KDC's certificate, mainly it requires a KDC certificate with an EKU of “KDC Authentication” (see option b. above). KDC Proxy – Installation and Configuration The KDC proxy KDC service is a component which automatically comes with the Remote Desktop Services Gateway role in Windows Server 2016 and later. The installation of this role is described in detail at Deploy Remote Desktop Gateway role for Remote Desktop Services | Microsoft Learn. Some additional information you might find very helpful: Before configuring your internal CA for publishing “Server Authentication” certificates with custom subjects allowed, read The Nightmare of Validating Certificate Requests. The KDC Proxy must not be installed on a Domain Controller (which btw. doesn’t make any sense...). The server hosting the RD Gateway/KDC proxy must be accessible from the Internet via TCP port 443 (reverse proxy recommended, e.g. AzureAppProxy). The server needs a certificate to terminate the incoming TLS connection and for mutual authentication with the client (see “Communication & Certificates” section above for details). Additional recommendations to further improve security: By default, the dword DisallowUnprotectedPasswordAuth in HKLM\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings is set to 0. This means that the KDC proxy will allow the user to retrieve a krbtgt using username and password. For security reasons (e.g. preventing brute force attacks) we can either set this to 1 or delete the dword to ensure that password-based authentication is disallowed. The KDC proxy is performing authentication and therefore must be clearly threatened and secured as T0 system. KDC Proxy - Configuration in Azure AVD Settings Clients will use the Windows app to connect to the AVD session host (AVD access via the browser does not work with smart card authentication). What is configured in the AVD session host’s RDP Properties, will be pushed to the clients. To configure the KDC proxy: Sign in to the Azure portal as an administrator. Go to the Azure Virtual Desktop page. Select the host pool you want to enable the KDC proxy for, then select RDP Properties. Select the Connection information tab, then enter a value in the following format without spaces: kdcproxyname:s: <public KDC proxy name as registered in DNS> Fig.4 5. Select Save. 6. The selected host pool should now begin to issue RDP connection files that include the kdcproxyname value you provided in step 4. Please note: There is no need for configuration of the KDC Proxy URL on the client as it is pushed to the Windows app through the AVD settings. Client Configuration: Trust & Revocation Check The client must regard the KDC proxy’s certificate as trustworthy. This requires: importing the Root CA certificate into the Trusted Root Certification Authorities store ensuring that the CRL Distribution path (or OCSP) path points to accessible and valid revocation information is available In case the client is joined to an AD domain, the CA certificate which issued the DC certificate must be present in the client’s NTAuth store. In case the client is not joined to an AD domain, this is not required. Troubleshooting In case the smart card authentication via the KDC Proxy does not work, you will see the following error message in most scenarios: Unfortunately, it is very generic and to dig deeper into the problem, we need to investigate different locations in the Windows Event Log. Event Logs – Overview The following event logs can provide useful information for troubleshooting: component logging options client Eventviewer > Microsoft > Windows > CAPI2 (disabled by default) Eventviewer > Microsoft > Windows > Security-Kerberos (disabled by default) KDC proxy Eventviewer > Microsoft > Windows > Kerberos-KdcProxy/Operational (disabled by default) Eventviewer > Microsoft > Windows > CAPI2 (disabled by default) Schannel log (disabled by default). See Enable Schannel event logging in Windows - Internet Information Services | Microsoft Learn. Please note that Schannel events will be written to the System Eventlog. Some Troubleshooting Scenarios Please find some very common troubleshooting scenarios below. KDC Proxy: Port 443 not opened, wrong URL configured on Client, DNS issue... On the KDC Proxy, check Eventviewer à Microsoft à Windows à Kerberos-KdcProxy/Operational. Event ID 400 indicates that a client is talking to the KDC Proxy. You don’t see this event? Looks like nobody would be talking to your proxy. Check firewall, DNS resolution and the KDC proxy URL configured on the client. Client: KDC Proxy Certificate not trusted In case you see an error referring to the KDC Proxy public URL in CAPI2 log, the KDC proxy server’s certificate cannot chain up to a trusted Root CA. Ensure that the corresponding Root CA certificate is present in the client’s Trusted Root Certification Authorities store. Client: Revocation Check on the KDC Proxy Certificate failed CAPI2 This error indicates that the revocation checks on the KDC proxy failed. Please keep in mind that this is executed in system context (lsass.exe). Ensure that the CRL (or OCSP) is accessible in the security context of the client computer. Security-Kerberos In Eventviewer > Microsoft > Windows > Security-Kerberos the following event is logged. Credential Guard enabled on the Client With Credential Guard enabled on the client, proxying Kerberos messages will not work. In Eventviewer > Microsoft > Windows > Security-Kerberos on the client the following event is logged: Export of supplemental credentials attempted. This is unsupported with credential guard.Protecting Tier 0 the Modern Way
Almost every attack on Active Directory you hear about today – no matter if ransomware is involved or not – (ab)uses credential theft techniques as the key factor for successful compromise. Microsoft’s State of Cybercrime report confirms this statement: “The top finding among ransomware incident response engagements was insufficient privilege access and lateral movement controls.” Despite the fantastic capabilities of modern detection and protection tools (like the Microsoft Defender family of products), we should not forget that prevention is always better than cure (which means that accounts should be protected against credential theft proactively). Microsoft’s approach to achieving this goal is the Enterprise Access Model. It adds the aspect of hybrid and multi-cloud identities to the Active Directory Administrative Tier Model. Although first published almost 10 years ago, the AD Administrative Tier Model is still not obsolete. Not having it in place and enforced is extremely risky with today’s threat level in mind. Most attackers follow playbooks and whatever their final goal may be, Active Directory Domain domination (Tier 0 compromise) is a stopover in almost every attack. Hence, securing Tier 0 is the first critical step towards your Active Directory hardening journey and this article was written to help with it.The Nightmare of Validating Certificate Requests
At CRSP we help customers to recover from different types of cyber security incidents. This means that we help more or less with wherever help is needed (from hardening AD and AAD, to restoring Exchange). However, there are some things which are crucial to not getting re-compromised and therefore we don't let our customers come online without: Securing and hardening Active Directory and all kinds of Azure resources. During the last 1.5 years some papers and articles drew attention to risky misconfiguration of Active Directory Certificate Services (ADCS) and its potential for Active Directory (and Azure) dominance. Therefore, an essential part of our Compromise Recovery engagements deals with introducing unpopular measures like using PAWs (Privileged Access Workstations) or stopping unverified enrollment of certificates allowing custom subjects. The latter involves reviewing certificate template configuration and security settings in Active Directory. Please note that certificate templates are not the only aspect of securing ADCS, but the one we want to focus on in this article.
