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

Serge Caron 65 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
Answer accepted by question author
VPHAN 44,620 Reputation points Independent Advisor
2025-12-19T17:36:53.1433333+00:00

Hi Serge Caron,

How was the issue? It seems your previous answer has been deleted. I could not read it.

VP

Was this answer helpful?

1 person found this answer helpful.
0 comments

44 additional answers

Sort by: Newest
Most helpful Newest Oldest
  1. Serge Caron 65 Reputation points
    2025-12-20T20:35:27.12+00:00

    Hello VPHAN,

    I am going to answer my own question here.

    On a domain joined active session, when "promptcredentialonce:i:1" is set in the RDP connection file, I get a Kerberos session. If local credentials are allowed, "promptcredentialonce:i:0", the session is downgraded to NTLMv1.2.

    This does not happen when the connection is issued from a local session.

    It will be interesting to see what happens when NTLM is dasabled on this domain.

    This completes the BYOD scenario.

    So, all that remains is to know if the default Kerberos policies are mirrored in the WoW... system keys.

    Regards,

    Was this answer helpful?

    0 comments
  2. Serge Caron 65 Reputation points
    2025-12-20T14:06:27.3133333+00:00

    Hello VPHAN,

    I did a small cosmetic change in the configuration script for the RD gateway: the actual encryption types supported by the object is displayed. In small environments like those I am targetting, this is sort of a progress indicator toward AES only encryption.

    As for the domain-joined question, I want to make sure that I understand your request.

    I am talking about cross domain access between domains which don't have trust relationships. To be concise, if I configure my workstation for the Windows 2025 realm, my RDP connection is downgraded to NTLM; if I log as a local user on the same workstation using the same RDP file and same setup, I get a Kerberos authenticated logon.

    In my mind, this is a BYOD scenario. In yours, the user's domain mechanic will take over the mstsc.exe parameters and there will be a failure to create an independent tunnel for this RDP connection. Am I reading your request correctly?

    Finally, there is a small anomaly in the client script: the default Kerberos policies for the client computer are taken from "HKLM:\SOFTWARE\WOW6432Node\Microsoft\..." rather than "HKLM:\SOFTWARE\Microsoft\...". I can't remember why this key was taken from WOW6432Node : is there an automatic mirroring of these Kerberos parameters and should I simply remove the WOW6432Node reference ?

    Regards,

    PS: Sorry for the split questions ;-)

    Was this answer helpful?

    0 comments
  3. Serge Caron 65 Reputation points
    2025-12-20T00:34:28.17+00:00

    Hello VPHAN,

    Kerberos tickets were issued with AES as soon as AES was enabled for the server and rebooted.

    The script works to my satisfaction (with one little detail but I am being difficult).

    Here is a sample output:

    PS C:\Users\MyAdmin> .\Desktop\RDGatewayConfigKerberos.ps1
This script made possible with the kind assistance of VPHAN
You can follow development here : https://learn.microsoft.com/en-us/answers/questions/5649813/
The Network Service user name is: AUTORITE NT\SERVICE RÉSEAU
Using myserver.mydomain.tld [Certify] - 2025-11-16 05:05:35 to 2026-02-14 05:05:34
Remote Desktop Gateway is  myserver.mydomain.tld
SPN HTTP/myserver.mydomain.tld is properly registered to MYSERVER
SPN HTTP/myserver.mydomain.local is properly registered to MYSERVER
AVERTISSEMENT : Resetting Proxy Service Parameters to default values
AVERTISSEMENT : Encryption type RC4 is still supported on these AD objects:
Name        ObjectClass ObjectGUID
----        ----------- ----------
[ ... ]
MYSERVER       computer    e2cf1df9-xxxx-yyyy-zzzz-b3f06e799954
[ ... ]
AVERTISSEMENT :
AVERTISSEMENT : These AD objects only support Kerberos type encryption:
Name              ObjectClass ObjectGUID
----              ----------- ----------
[ ... ]
MYSERVER          computer    e2cf1df9-xxxx-yyyy-zzzz-b3f06e799954
MyAdmin           user        6dd456be-aaaa-bbbb-cccc-d785376ebb21
[ ... ]
AVERTISSEMENT :
AVERTISSEMENT : URL kdcproxy is already reserved.
AVERTISSEMENT : URL remoteDesktopGateway is already reserved.

    The non-domain joined client connects to all three RDGs using Kerberos.

    I have one last question regarding domain joined clients: do we open a new question or do we continue with this one ?

    Regards,

    Was this answer helpful?

  4. Serge Caron 65 Reputation points
    2025-12-19T22:23:04.3233333+00:00

    Hello VPHAN,

    Sorry, I got caught in the crossfire with the AI supervising this site ;-(.

    As suspected, the production Server 2025 did not have AES enabled.

    I am rebooting the DC and will report later or tomorrow.

    In the meantime, you can check https://github.com/SergeCaron/MSRDGatewayKerberos containing the two scripts developped in this conversation. Please note that credits are given to you the best I could: if you don't like the idea or would like a more proper designation, please advise.

    Regards,

    Was this answer helpful?

    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.