Share via

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

Serge Caron 0 Reputation points
2025-12-06T19:48:13.38+00:00

In order to reduce complexity, I am using a test domain consisting of a single domain controller ON PREMISES and a single user, the domain administrator.

There is a single role installed: Remote Desktop Gateway. None of the other 5 RDS roles are installed. Direct Access and/or VPNs are not allowed in this test.

The AD domain is MyDomain.local and the internal FQDN is MyServer.MyDomain.local

There is a Let's Encrypt certificate installed on this server for MyServer.MyDomain.TLD.

Finally, there is a single port 443 forwarded to the server from the firewall.

I can RDP into this server from the Internet to MyServer.MyDomain.local via RDG MyServer.MyDomain.TLD.

However, all logons are downgraded to NTLMv2 even if I set

rdgiskdcproxy:i:1

kdcproxyname:s:MyServer.Mydomain.TLD

In this test case, I am using a non domain joined Windows 10 Pro client (even if I know it is deprecated): we need to demonstrate RDG working with BYOD, including non Windows devices.

Is there a way to do this in Windows Server 2025 ?

Windows for business | Windows Server | Directory services | User logon and profiles
0 comments

11 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. VPHAN 10,640 Reputation points Independent Advisor
    2025-12-12T03:11:28.3866667+00:00

    Hi Serge Caron,

    You've done a great job!! However, the solution is staring us in the face within the setspn output you provided. If you look closely at the command you ran and the subsequent output, the issue is not a technical mystery of Windows Server 2025, but a simple syntax oversight during the registration attempt.

    In your console output, you executed: setspn -S HTTP/MyServer.MyDomain.local MYSERVER. The system correctly responded with "Duplicate SPN detected, operation aborted" because, as shown in the dump lines immediately preceding it, HTTP/MyServer.MyDomain.local already exists on the object.

    Crucially, HTTP/MyServer.MyDomain.TLD is completely missing from that list.

    The RD Gateway / KDC Proxy authentication process is extremely strict regarding the "Front Door." When the client connects, it does not care about the internal AD name yet; it is talking to the public URL defined in the gateway settings. The client requests a ticket for HTTP/MyServer.MyDomain.TLD. Active Directory looks at the CN=MYSERVER object, sees HTTP/Internal, TERMSRV/Internal, and HOST/Internal, but it does not find HTTP/ExternalTLD. Consequently, it returns 0x7 (Principal Unknown), and the client correctly aborts the Kerberos exchange.

    You must run the command specifically for the external address. Please open the Administrator Command Prompt on your DC and run: setspn -S HTTP/MyServer.MyDomain.TLD MYSERVER

    Once you run this, verify it immediately with setspn -L MYSERVER. You must see the TLD variant explicitly listed in the output. As soon as that entry appears, your Windows 10 client, with its current registry configuration, will successfully obtain the service ticket for the proxy, establish the tunnel, and then proceed to obtain the TERMSRV ticket for the RDP session.

    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 then. Should you have more questions, feel free to leave a message. Have a nice day!

    VP

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.