Troubleshooting stories from the field are the best. That’s why I like writing them down. Although, sometimes they might appear as straight cases of schadenfreude, I feel there are lessons to be learned for anyone, if you’re willing to look closely and listen carefully.

This week I experienced an issue at an organization, while they were transitioning their Domain Controllers from Windows Server 2019 to Windows Server 2025. It turned out they were following Microsoft’s recommendations, except for one…

The situation

The organization has an Active Directory Domain Services (AD DS) environment with Domain Controllers running Windows Server 2019. Recently, they have added Windows Server 2025-based Domain Controllers with the intent to decommission the Windows Server 2019-based Domain Controllers. The Domain and Forest Functional Level are both Windows Server 2016. (This is actually a requirement for introducing Windows Server 2025-based Domain Controllers.)

Admin accounts are members of the Protected Users security group and typically sign into the Domain Controllers using RDP from devices joined to a trusted Active Directory forest.

To optimize the hardening of the new Domain Controllers, the identity admin team has configured separate (CIS benchmark-based) Group Policy objects (GPOs) for hardening.

To align with the upcoming public certificate lifetime changes, the Public Key Infrastructure (PKI) admin, managing Active Directory Certificate Services (AD CS), also created a new certificate template for the Windows Server 2025-based Domain Controllers, based on the Kerberos Authentication template.

The issue

After decommissioning the last Windows Server 2019-based Domain Controller, admins can no longer sign into Domain Controllers using RDP.

When removing the admin accounts from the Protected Users security group, they can sign in again.

The cause

In this case, the cause wasn’t Windows Server 2025’s default settings. The hardened settings in the new Group Policy object also didn’t contribute to the situation.

The issue also isn't caused by any of the protections that Microsoft documented for signed-in Protected Users: RDP didn't use NTLM as the same approach to contacting the servers worked on Windows Server 2019 before. The new Domain Controllers were addressed with their fully-qualified domain names (FQDNs).

However, when reviewing the certificates issued to the new Windows Server 2025-based Domain Controllers, I noticed that only Server Authentication (1.3.6.1.5.5.7.3.1) and Client Authentication (1.3.6.1.5.5.7.3.2) were specified as enhanced key usage (EKU) extensions. EKUs are object identifiers (OIDs) that indicate the applications that use the key.

Smart Card Logon (1.3.6.1.4.1.311.20.2.2) was missing.

When I asked the PKI admin, his response was that he removed the Smart Card Logon EKU, as “smart cards are old technology and the organization doesn’t use smart cards.”…

The solution

We ended up creating a new certificate template based on the built-in Kerberos Authentication template with the recommended changes for Domain Controllers running Windows Server 2016, and up.

A certutil.exe -pulse on the Domain Controllers sealed the deal.

After enrolling the new certificate template, admins were able to sign into Domain Controllers using RDP while being members of the Protected Users group.

Concluding

The Smart Card Logon enhanced key usage enables a lot of strong authentication scenarios. Don’t remove it from your Domain Controller certificates.