With Server 2025, how do you avoid NTLM authentication for a RDP session originating from a non domain workstation ?

OOPS! I left one important detail.

The DC is not exposed to the Internet and does not have a public certificate like the RDG has.

Regards,

Hello VPHAN,

I went through this DC with a fine tooth comb. However, I must report that Kerberos no longer initialize on the DC itself.

Right now, I need the DC, the RDG, one internal workstation, and two (admin) users to monitor the non-domain joined workstation logging through this RDG.

I can verify with Get-ADObject -Filter " msDS-supportedEncryptionTypes -eq 0x18" that the domain computers and users are correctly listed.

The password of both users were reset, the workstation was removed from and rejoined to the domain, and the RDG machine password was reset.

Unfortunately, kerberos now fail to initialize on the DC. On startup, the DC reports a dozen Event 200 and later reports six Event 302 reporting that cannot access itself.

This is the only DNS server for this domain and there are no error to report. I did find an obsolete IPv6 record dating from 2021 for gc._msdcs.mydomain.tld which I removed.

Active Directory returns the expected information:

PS C:\Windows\system32> nltest /dclist:mydomain
Obtenez la liste des contrôleurs du domaine « mydomain» à partir de « \\MYSERVER».
    MyServer.mydomain.tld[PDC]  [DS] Site : Default-First-Site-Name
La commande a été correctement exécutée

However, the Network Conection Profile is set to Private, an indication that the DC does not agree with itself even if the netlogon and sysvol shares are accessible from the network.

At this point, I really don't know how to look at this issue but I understand it must be fixed before anything else goes ;-(

Regards,

You have successfully pivoted from a network routing troubleshooting session to a cryptographic negotiation analysis. The Wireshark trace confirms that the network transport (KDC Proxy) is working perfectly, the packet is reaching the DC. The rejection is logic-based, not connectivity-based.

The error KRB5KDC_ERR_ETYPE_NOSUPP (Encryption Type Not Supported) in response to an AS-REQ containing AES types typically points to a discrepancy between the configured attributes of the user account and the actual key material stored in the Active Directory database (ntds.dit).

You mentioned "On the UPN account, AES256 and AES128 are enabled." I assume you verified this in the Account tab of AD Users and Computers (or via msDS-SupportedEncryptionTypes).

However, ticking those boxes (or modifying the attribute) acts only as a filter. It tells the KDC: "You are allowed to use AES for this user." It does not generate the AES keys.

If the user's password was last set before those AES options were enabled (or before the Domain Functional Level fully supported them), the Active Directory database does not hold the AES hashes for that password. It only has the RC4 (NTLM) hash and possibly DES (if old).

The Sequence of Failure:

• Client: Sends AS-REQ with Pre-Authentication data encrypted using AES-256 (because the Client is configured for AES).
• DC: Receives the request. Looks up the User.
• DC Logic: The User object allows AES (checkbox is set). The DC attempts to decrypt the timestamp using its stored AES key for that user.
• Database: Returns "Null" or "Key Missing" for AES.
• Result: The DC cannot validate the Pre-Auth. It checks if it can downgrade.

If the Client sent only AES (due to your ksetup restriction), the DC has no common key.

If the Client included DES, but the DC policy (Server 2025 default) blocks DES, the DC ignores it.

Error: KRB5KDC_ERR_ETYPE_NOSUPP ("I cannot support the encryption type you used to sign this, because I don't have that key").

=> You must force Active Directory to calculate and store the AES keys for that user account.

Reset the Password: Right-click the User account in AD Users and Computers and select Reset Password. (You can set it to the same password if history allows, but a change is preferred). This action forces the KDC to take the cleartext input and hash it into RC4, AES-128, and AES-256 formats and store them all.

Verify the "DES" Distraction: You mentioned DES is enabled "for testing." Ensure that on the User Account > Account Tab, the box "Use Kerberos DES encryption types for this account" is UNCHECKED.

If Checked: It forces the account to only use DES. Since Server 2025 likely disables DES at the Global Policy level, this creates a "deny all" condition.

The AES checkboxes should be the only ones checked (or none, relying on default).

Check the Computer Account (RDG): Although less likely to cause a User AS-REQ failure, ensure the RD Gateway's Computer Account in AD also has a fresh password (reset computer account) if it was joined prior to Server 2025 AES enforcement.

VP

Hello VPHAN,

Looking at your answer, I realized that we are probably looking at something much more mundane than what you are exploring. As stated, the DNS server configured on the RDG is the single DC and name resolution for the local domain stops there, unless KPSSVC uses an external DNS server. However, there is no external DNS record for the DC itself. Time to break WireShark.

When, the RDG receives the request, I can see going to the DC on port 88 a KRB5 packet of type AS-REQ for the UPN specified on the logon screen of the RDP client and encryption types AES256, AES128, and DES. The response from the DC is KRB Error: KRB5KDC_ERR_ETYPE_NOSUPP.

AES256, AES128 and DES encryption are enabled on the DC (DES is just for testing). On the UPN account, AES256 and AES128 are enabled. The client remains unchanged.

So the question is: Why is the AES-REQ rejected immediately on reception of the packet?

Regards,