The Nightmare of renewing NDES Enrollment Agent Certificates
First introduced in Windows Server 2008, NDES spent many years as a niche technology. Over recent years, it has made an unexpected comeback driven by certificate enrollment on Intune-managed devices. Despite many articles describing its initial configuration, our daily professional experience shows that many NDES implementations are incorrectly or insecurely configured, or fail to work because of expired Enrollment Agent (EA) certificates. For this reason, this article explains how to design and configure custom EA certificate templates that enable secure automatic renewal.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.Protect Tier 1. Sleep well at Night.
In case you have not yet protected Tier 0, consider reviewing our article about protecting Tier 0 the modern way. Tier 1 is more difficult to outline as there are typically different security levels, from highly critical (e.g. personal data or business secrets) to informative, or even public information. What remains the same is the “assume breach” approach: no matter which (Tier 1) system gets compromised, the infection must not spread. What causes us a lot of headaches is something we call “Permanently privileged Tier 1 accounts”: accounts which are members of the Local Administrators group on most (or even all) Tier 1 servers and left there indefinitely. This type of accounts draws attackers like moths to the flame, because by compromising a single account, attackers can gain full control of Tier 1. Optional Refresher: Lateral Movement (in Tier 1) In general, the term “lateral movement” refers to a group of techniques cyber criminals use to explore an infected network to find vulnerabilities, escalate and cement access privileges, and finally reach their ultimate target. It is called “lateral movement” because of the way the attackers move sideways from their initial point of entry to device, to application and so forth. The illustration below depicts how attackers move laterally across Tier 1: Attackers compromised T1-Server-01. Thanks to LAPS, lateral movement to other Tier 1 servers using the (local) Administrator account and password is unsuccessful. T1-Admin-01 logs on to T1-Server-01 to perform some administrative tasks, thereby exposing reusable credentials to the attackers waiting for their chance. Attackers steal reusable credentials from the server’s memory. Attackers move laterally to all T1-Servers accessible with the credentials stolen in step (3). Tackling the Security Challenge of standing Privileges Just-in-time (JIT) administration in Active Directory is a security practice that temporarily elevates user privileges only when needed, which massively reduces the risk of misuse. It works by granting privileged access for a limited time, ensuring that users can elevate only on a limited number of devices at the same time and are automatically removed from privileged groups after a defined period. By introducing JiT, we can get rid of identities which hold permanently privileged access to many systems at the same time. Let’s be very clear on this: JiT will not prevent a single server or account from being compromised, but it can prevent the attack from spreading by minimizing the window of opportunity for attackers to exploit elevated privileges. By limiting the duration and scope of privileged access, JIT administration reduces the chances of attackers moving laterally across the network and gaining control over critical systems. Due to complexity, pricing, and environmental overhead of many commercial JiT solutions, we were looking for an easier way to achieve secure JiT on a budget. The solution developed by Andreas Lucas and Andreas Luy is based on a PowerShell scripts, comes with a graphical user interface and is published on Github. So, what is still holding you back from protecting Tier 1? JiT on a Budget Please note: This is not an "official" Microsoft solution, but a project created and developed by people working in Microsoft Security Enterprise Services (which used to be known as Microsoft Consulting Services some time ago). The tool is written in PowerShell. Please review carefully before introducing in your environment. When doing that you will find some not yet documented features. We are working on improving the documentation. We also want to emphasize that implementing this tool is only one part of the journey to protect Tier 1 against today's attacks. JiT Configuration The configuration for the JiT solution will be stored in Active Directory. To make this possible an Active Directory Schema extension must be implemented. Even though most AD admins do not enjoy schema updates, AD turned out to be the perfect location for storing the JiT configuration: it is highly available by default, is less likely to be messed up (or even deleted) than config files. The solution uses an Active Directory object to save the general JiT configuration (like OU locations for T1-Servers or maximum allowed elevation time). In addition to that, an individual object is created for each T1-Server and a Container is used to hold individual objects for allowed delegations (in other words: which user is allowed to request elevation on which server/OU). JiT Automation After the JiT solution has been installed and configured, a Scheduled Task will be running on the JiT Management Server every few minutes (step 1 in the illustration below). This task runs in the security context of a gMSA (group Managed Service Account) and monitors Active Directory for newly added Tier 1 servers (step 2). In case a new T1 server is found, the Scheduled Task creates an individual AD group for each new Tier 1 server (step 3, e.g. T1-Admin#Server-01). The group is automatically added to the according Tier 1 server’s (local) Administrators group through Group Policy (step 4). All these “Jit administrative groups” created are Tier 0 groups and cannot be modified by Tier 1 assets. At this point no T1-Admin is yet a local Administrator on any Tier 1 server. T1-Admins who want to self-elevate to local Administrator on a Tier 1 Server, must log on to the JiT Management Server (step 1 in the illustration below). Please note that the JiT Management Server is classified as a Tier 0 system. There they start a PowerShell-based elevation UI Tool and select the Tier 1 Server they want to request elevation for (step 2). A Scheduled Task running in the security context of a gMSA then adds their T1-Admin account to the T1 Server’s specific domain group (e.g. T1-Admin#Server-02) together with the requested time-to-live (TTL) (step 3). Now the T1-Admin-01 is an indirect member of the (local) Administrator’s group on the T1-Server-02 and can log on to this server to fulfill his admin tasks (step 4 in the illustration above). After a defined time span (TTL), the Privileged Access Management (PAM) optional feature ensures that the T1-JiT-Admin’s account is removed from the T1-Admins#T1-Server-02 group. In addition, the gMSA-based task ensures that the Jit-Administrator Groups will not contain ANY permanent membership in the (local) Administrators groups. The PAM optional feature essentially unlocks two new capabilities in the AD Forest: Temporary time-based group memberships, and shadow principals. Both were introduced to allow the implementation of a Red (or bastion) Active Directory Forest, using a MIM (Microsoft Identity Manager) for requesting temporary privileged access. However, our JiT solution only leverages the former to ensure that after the specified time has elapsed, the user will be automatically removed from the security group (without administrator intervention). Find more information about possible drawbacks when enabling the PAM option feature, check out our colleague's blog: https://ryanries.github.io/?title=possible_performance_pitfall_privileged_access_management.html Let’s get started Now is the time to protect Tier 1. For too long, this critical layer has remained vulnerable—not because it’s unimportant, but because safeguarding it seemed too complex or resource-intensive. That’s no longer the case. With a simple and effective solution now available, there are no more excuses. Protecting Tier 1 is not just a technical necessity—it’s a strategic imperative. Let’s take this opportunity to secure what matters most, before it’s too late. The code and detailed documentation are provided at https://github.com/Kili69/Just-in-time.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.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.
