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

Hello VPHAN,

On this client, there is no "delrealm" option in ksetup. There is a "RemoveRealm" which I used to remove the MYDOMAIN.LOCAL realm followed by a "DumpState" to verify that no mapping is defined.

The command "ksetup /addkdc MYDOMAIN.LOCAL MyServer.MyDomain.TLD" completes successfully and I can verify the result with "DumpState".

I can also verify with regedit that the key HKLM\SYSTEM\CurrentControlSet\Control\LSA\Kerberos\Domains\MYDOMAIN.LOCAL has an item "KdcNames" of type MultiString with value "MyServer.MyDomain.TLD".

At this point, the other subkeys of the "Kerberos" key ("HostToRealm" and "Parameters") are empty.

Any attempt to manipulate the encryption attributes, whether "ksetup /SetEncTypeAttr MYDOMAIN.LOCAL AES256-CTS-HMAC-SHA1-96" or a simple "ksetup /GetEncTypeAttr MYDOMAIN.LOCAL" results in error 0xc0000034.

I also repeated these tests after using "ksetup /SetRealm MYDOMAIN.LOCAL" and rebooting: this basically substitute the workgroup for a default domain. Again, any attempt to manipulate the encryption attributes fail with the same error code.

I have no clue of what the missing object may be ;-)

Regards,

Hi,

You have successfully identified the root cause with that Event ID 100 on the client. The error code 0x7 (KDC_ERR_S_PRINCIPAL_UNKNOWN) is the definitive blocker here.

Your Windows 10 client connects to https://MyServer.MyDomain.TLD (The Gateway/Proxy). Because you are enforcing Kerberos, the client must obtain a Service Ticket for that specific endpoint to prove its identity before the Proxy will talk to it. The client asks the KDC (your server) for a ticket for the Service Principal Name (SPN) HTTP/MyServer.MyDomain.TLD. The Active Directory responds: "I have no record of any computer with that name." Authentication stops immediately. The encryption types (AES vs RC4) don't even matter yet because the account lookup failed first.

To fix the SPN and the ksetup error.

Step 1: Register the SPN (Must be done on the SERVER)

You can't run setspn on the non-domain joined client because it lacks write permissions to your Active Directory. You must run this command on the Windows Server 2025 domain controller.

Open an Administrator Command Prompt on the Server and run: setspn -S HTTP/MyServer.MyDomain.TLD MyServer

Replace MyServer at the end with the actual SAMAccountName of your server computer object if it differs. This tells Active Directory: "When a client asks for HTTP/MyServer.MyDomain.TLD, that traffic belongs to the computer account MyServer."

Step 2: Fix the ksetup 0xc0000034 Error (Client Side)

The error 0xc0000034 (STATUS_OBJECT_NAME_NOT_FOUND) on the client indicates that the registry key for the Realm MYDOMAIN.LOCAL was not fully or correctly initialized during the ksetup /addkdc step, or there is a casing mismatch (ksetup is case-sensitive).

To fix this, we will perform a clean reset of the KDC configuration on the client.

On the Client (Administrator Command Prompt):

Remove the existing configuration (Clean Slate): ksetup /delrealm MYDOMAIN.LOCAL

Re-add the Realm (Ensure UPPERCASE for the Realm): ksetup /addkdc MYDOMAIN.LOCAL MyServer.MyDomain.TLD

Re-apply the Encryption Type (Now the object should exist): ksetup /SetEncTypeAttr MYDOMAIN.LOCAL AES256-CTS-HMAC-SHA1-96

Re-apply the Host Mapping: ksetup /addhosttorealmmap .MyDomain.local MYDOMAIN.LOCAL

Step 3: Verify and Connect

Once the SPN is registered on the server and the client configuration is refreshed:

Run klist purge on the client.

Attempt the RDP connection again.

Run klist on the client. You should now see a ticket for HTTP/MyServer.MyDomain.TLD.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VPHAN

Hello VPHAN,

Thank you for explaining that it is the client that is downgrading the authentification protocol.

Most of what follows is translated from French and may not be the exact wording you are used to.

The client Security-Kerberos is recording event ID 100:

The service principal name (SPN) HTTP/MyServer.MyDomain.TLD@MYDOMAIN.LOCAL is not registered, which caused the Kerberos authentication to fail: 0x7. Use the setspn command-line tool to register the service principal name.

ksetup shows the current configuration and notes that the client is not domain registered. However it fails to record the encoding types:

C:\WINDOWS\system32>ksetup /DumpState

The computer is not configured to log on to an external KDC. Probably a member of a workgroup.

MYDOMAIN.LOCAL:

kdc = MyServer.MyDomain.TLD

Domain indicators = 0x0No domain indicators

No user mapping defined.

C:\WINDOWS\system32>ksetup /SetEncTypeAttr MYDOMAIN.LOCAL AES256-CTS-HMAC-SHA1-96

Definition of the encoding types for the domain MYDOMAIN.LOCAL on: AES256-CTS-HMAC-SHA1-96

The definition of the coding types on MYDOMAIN.LOCAL failed with 0xc0000034

/SetEncTypeAttr failed: 0xc0000034

0xc0000034 is NTSTATUS "STATUS_OBJECT_NAME_NOT_FOUND" and documented as "The object name is not found.".

Please note that the command "ksetup /addhosttorealmmap .MyDomain.local MYDOMAIN.LOCAL" does not generate any output and can be repeated without any error message to the effect that this mapping is already recorded.

All attempts to use setspn on the client have failed with error LDAP 0x51.

Clearly I am still missing a piece of that puzzle.

Regards,

The fact that you see KDC_ERR_PREAUTH_REQUIRED (Event ID 4768 or 4771) on the Server means the Client -> Proxy -> DC path is working perfectly. The "Pipe" is open.

The "Downgrade to NTLM" is happening because the Client receives the KDC's "Pre-Auth" challenge (which says: "I see you, now encrypt a timestamp with your password hash so I know it's really you") and the Client refuses to answer, dropping the conversation and switching to NTLM.

As for the trace method you asked to find the "Why," here is the procedure to pinpoint the failure on the client side, along with the solution for a Server 2025 / Windows 10 mismatch.

1. How to Trace the "Silent Downgrade" (Client Side)

The server logs won't tell you why the client quit. You must look at the Windows 10 client's decision-making process.

On your Windows 10 Client: Open Event Viewer (eventvwr.msc). Navigate to Applications and Services Logs > Microsoft > Windows > Security-Kerberos > Operational. Right-click Operational and select Enable Log. Clear the log to remove noise. Attempt the RDP connection again. Refresh the log.

What to look for:

Event ID 202 (KDC Proxy): This will show if the proxy handshake (HTTPS) failed.

Event ID 108: This indicates a generic KDC error.

Error Code 0x10 (KDC_ERR_PADATA_TYPE_NOSUPP): This is the most common cause in your specific scenario (see "The Solution" below).

Error Code 0xe (KDC_ERR_ETYPE_NOSUPP): Encryption type mismatch.

2. Solution: Encryption Type Mismatch

You are connecting to Windows Server 2025 (which hardens security by disabling RC4 and prioritizing AES) from a non-domain joined Windows 10 client.

When you use ksetup to add a manual realm, Windows 10 defaults to a "Compatibility Mode" that often fails to negotiate AES-256 with a hardened KDC unless explicitly told that the Realm supports it. When the Server 2025 DC responds to the Pre-Auth request demanding AES encryption, the client panics and drops to NTLM.

=> To fix, run this command on your Windows 10 Client (Admin Command Prompt) to force it to speak AES-256 with your test domain:

ksetup /SetEncTypeAttr MYDOMAIN.LOCAL AES256-CTS-HMAC-SHA1-96

After running this, run klist purge and try the connection again.

3. Verify the Host Mapping

Even if the UPN is correct (Administrator@MYDOMAIN.LOCAL), the RDP client (mstsc.exe) validates the target server's identity against the realm. If mstsc thinks MyServer.MyDomain.local belongs to the "Public Internet" and not "MYDOMAIN.LOCAL", it won't send the Kerberos reply.

Verify you have mapped the DNS suffix to the Realm on the client:

ksetup /addhosttorealmmap .MyDomain.local MYDOMAIN.LOCAL