Share via

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

Serge Caron 25 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
  1. VPHAN 25,000 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

    1 person found this answer helpful.
    0 comments

44 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Serge Caron 25 Reputation points
    2025-12-19T18:13:25.0266667+00:00

    Hello VPHAN,

    Success! (At least for this Server 2022 domain ;-)

    It seems the kerberos WireShark trace submitted before viloated the code of conduct.

    Before I attack the Server 2025 domain, is there a way to detect the kind of hashes stored in AD for machine / user accounts ? I am thinking of something along the way of "Get-ADObject ..." and testing the type of hashes stored in the account.

    I will do my best to diagnose the Server 2025.

    Regards,

    0 comments
  2. Serge Caron 25 Reputation points
    2025-12-19T16:04:41.09+00:00

    Hello VPHAN,

    Success! (At least for this Server 2022 domain ;-)

    Below is the kerberos WireShark trace.

    Before I attack the Server 2025 domain, is there a way to detect the kind of hashes stored in AD for machine / user accounts ? I am thinking of something along the way of "Get-ADUser -Identity scaron -Properties info ..." and testing the type of hashes stored in the account.

    I will do my best to diagnose the Server 2025.

    Regards,

    No. Time Source Destination Protocol Length Info

    1592 47.922385 192.168.18.10 192.168.18.9 KRB5 226 AS-REQ

    1593 47.923196 192.168.18.9 192.168.18.10 KRB5 246 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED

    1605 47.949861 192.168.18.10 192.168.18.9 KRB5 308 AS-REQ

    1607 47.950915 192.168.18.9 192.168.18.10 KRB5 459 AS-REP

    1624 47.966341 192.168.18.10 192.168.18.9 KRB5 533 TGS-REQ

    1627 47.967915 192.168.18.9 192.168.18.10 KRB5 559 TGS-REP

    1655 47.985278 192.168.18.10 192.168.18.9 KRB5 283 AS-REQ

    1656 47.985865 192.168.18.9 192.168.18.10 KRB5 268 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED

    1663 47.995811 192.168.18.10 192.168.18.9 KRB5 363 AS-REQ

    1665 47.996577 192.168.18.9 192.168.18.10 KRB5 324 AS-REP

    1674 47.997259 192.168.18.10 192.168.18.9 KRB5 325 TGS-REQ

    1677 47.998455 192.168.18.9 192.168.18.10 KRB5 359 TGS-REP

    1683 47.999074 192.168.18.10 192.168.18.9 LDAP 487 bindRequest(30) "<ROOT>" sasl

    1686 47.999924 192.168.18.9 192.168.18.10 LDAP 265 bindResponse(30) success

    1708 48.021773 192.168.18.10 192.168.18.9 KRB5 190 TGS-REQ

    1711 48.022692 192.168.18.9 192.168.18.10 KRB5 221 TGS-REP

    1720 48.023339 192.168.18.10 192.168.18.9 KRB5 367 TGS-REQ

    1723 48.027016 192.168.18.9 192.168.18.10 KRB5 339 TGS-REP

    1748 48.064138 192.168.18.10 192.168.18.9 KRB5 226 AS-REQ

    1749 48.064844 192.168.18.9 192.168.18.10 KRB5 246 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED

    1759 48.080314 192.168.18.10 192.168.18.9 KRB5 308 AS-REQ

    1761 48.081328 192.168.18.9 192.168.18.10 KRB5 459 AS-REP

    1776 48.085892 192.168.18.10 192.168.18.9 KRB5 536 TGS-REQ

    1779 48.087365 192.168.18.9 192.168.18.10 KRB5 565 TGS-REP

    1809 48.124972 192.168.18.10 192.168.18.9 KRB5 319 TGS-REQ

    1812 48.126659 192.168.18.9 192.168.18.10 KRB5 560 TGS-REP

    2243 50.569414 192.168.18.10 192.168.18.9 KRB5 296 AS-REQ

    2244 50.570036 192.168.18.9 192.168.18.10 KRB5 246 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED

    2251 50.575856 192.168.18.10 192.168.18.9 KRB5 376 AS-REQ

    2253 50.576707 192.168.18.9 192.168.18.10 KRB5 512 AS-REP

    2262 50.577180 192.168.18.10 192.168.18.9 KRB5 411 TGS-REQ

    2265 50.578343 192.168.18.9 192.168.18.10 KRB5 497 TGS-REP

    2868 51.005913 192.168.18.10 192.168.18.9 KRB5 274 AS-REQ

    2869 51.006604 192.168.18.9 192.168.18.10 KRB5 246 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED

    2876 51.007574 192.168.18.10 192.168.18.9 KRB5 354 AS-REQ

    2879 51.008508 192.168.18.9 192.168.18.10 KRB5 512 AS-REP

    3028 51.037100 192.168.18.10 192.168.18.9 KRB5 549 TGS-REQ

    3031 51.038504 192.168.18.9 192.168.18.10 KRB5 569 TGS-REP

    3037 51.038826 192.168.18.10 192.168.18.15 SMB2 825 Session Setup Request

    3039 51.039716 192.168.18.15 192.168.18.10 SMB2 315 Session Setup Response

    3135 51.080294 192.168.18.10 192.168.18.9 KRB5 586 TGS-REQ

    3139 51.081723 192.168.18.9 192.168.18.10 KRB5 623 TGS-REP

    3147 51.082656 192.168.18.10 192.168.18.9 DCERPC 903 Alter_context: call_id: 13, Fragment: Single, 1 context items: DRSUAPI V4.0 (64bit NDR)

    3151 51.083309 192.168.18.9 192.168.18.10 DCERPC 287 Alter_context_resp: call_id: 13, Fragment: Single, max_xmit: 5840 max_recv: 5840, 1 results:

    Acceptance

    3152 51.083529 192.168.18.10 192.168.18.9 DCERPC 274 Alter_context: call_id: 13, Fragment: Single, 1 context items: DRSUAPI V4.0 (64bit NDR)

    3179 51.090744 192.168.18.10 192.168.18.9 LDAP 641 bindRequest(298) "<ROOT>" sasl

    3181 51.091385 192.168.18.9 192.168.18.10 LDAP 266 bindResponse(298) success

    3189 51.096915 192.168.18.10 192.168.18.9 LDAP 883 bindRequest(302) "<ROOT>" sasl

    3191 51.097609 192.168.18.9 192.168.18.10 LDAP 266 bindResponse(302) success

    3212 51.105810 192.168.18.10 192.168.18.9 DCERPC 773 Bind: call_id: 2, Fragment: Single, 3 context items: DRSUAPI V4.0 (32bit NDR), DRSUAPI V4.0

    (64bit NDR), DRSUAPI V4.0 (6cb71c2c-9812-4540-0300-000000000000)

    3214 51.106472 192.168.18.9 192.168.18.10 DCERPC 339 Bind_ack: call_id: 2, Fragment: Single, max_xmit: 5840 max_recv: 5840, 3 results: Provider

    rejection, Acceptance, Negotiate ACK

    3215 51.106650 192.168.18.10 192.168.18.9 DCERPC 274 Alter_context: call_id: 2, Fragment: Single, 1 context items: DRSUAPI V4.0 (64bit NDR)

    3231 51.109268 192.168.18.10 192.168.18.9 KRB5 586 TGS-REQ

    3234 51.110826 192.168.18.9 192.168.18.10 KRB5 623 TGS-REP

    3243 51.111409 192.168.18.10 192.168.18.9 KRB5 378 TGS-REQ

    3246 51.112095 192.168.18.9 192.168.18.10 KRB5 406 TGS-REP

    3251 51.112536 192.168.18.10 192.168.18.9 SMB2 1226 Session Setup Request

    3260 51.113679 192.168.18.9 192.168.18.10 SMB2 315 Session Setup Response

    C:\Users\ADMINI~2\AppData\Local\Temp\2\wireshark_Ethernet5Z6LH3.pcapng 18885 paques totales, 85 affichés

    3300 51.116166 192.168.18.10 192.168.18.9 SMB2 1226 Session Setup Request

    3303 51.116223 192.168.18.10 192.168.18.9 SMB2 1226 Session Setup Request

    3309 51.116324 192.168.18.10 192.168.18.9 SMB2 1226 Session Setup Request

    3312 51.117112 192.168.18.9 192.168.18.10 SMB2 315 Session Setup Response

    6326 77.923369 192.168.18.10 192.168.18.9 LDAP 882 bindRequest(3) "<ROOT>" sasl

    6328 77.924341 192.168.18.9 192.168.18.10 LDAP 265 bindResponse(3) success

    6341 77.929770 192.168.18.10 192.168.18.9 KRB5 569 TGS-REQ

    6344 77.931186 192.168.18.9 192.168.18.10 KRB5 605 TGS-REP

    6350 77.931526 192.168.18.10 192.168.18.9 LDAP 829 bindRequest(7) "<ROOT>" sasl

    6352 77.932349 192.168.18.9 192.168.18.10 LDAP 265 bindResponse(7) success

    6357 77.935500 192.168.18.10 192.168.18.9 KRB5 569 TGS-REQ

    6360 77.936982 192.168.18.9 192.168.18.10 KRB5 605 TGS-REP

    6367 77.937459 192.168.18.10 192.168.18.9 SMB2 1173 Session Setup Request

    6369 77.938449 192.168.18.9 192.168.18.10 SMB2 315 Session Setup Response

    6381 77.940491 192.168.18.10 192.168.18.9 SMB2 1173 Session Setup Request

    6385 77.940501 192.168.18.10 192.168.18.9 SMB2 1173 [Illegal Segments]

    6388 77.940573 192.168.18.10 192.168.18.9 SMB2 1173 [Illegal Segments]

    6395 77.941365 192.168.18.9 192.168.18.10 SMB2 315 Session Setup Response

    6402 77.948642 192.168.18.10 192.168.18.9 LDAP 882 bindRequest(10) "<ROOT>" sasl

    6404 77.949566 192.168.18.9 192.168.18.10 LDAP 265 bindResponse(10) success

    11102 113.493789 192.168.18.10 192.168.18.9 DCERPC 773 Bind: call_id: 2, Fragment: Single, 3 context items: DRSUAPI V4.0 (32bit NDR), DRSUAPI V4.0

    (64bit NDR), DRSUAPI V4.0 (6cb71c2c-9812-4540-0300-000000000000)

    11104 113.495969 192.168.18.9 192.168.18.10 DCERPC 339 Bind_ack: call_id: 2, Fragment: Single, max_xmit: 5840 max_recv: 5840, 3 results: Provider

    rejection, Acceptance, Negotiate ACK

    11105 113.496799 192.168.18.10 192.168.18.9 DCERPC 273 Alter_context: call_id: 2, Fragment: Single, 1 context items: DRSUAPI V4.0 (64bit NDR)

    11130 113.505429 192.168.18.10 192.168.18.9 LDAP 664 bindRequest(3) "<ROOT>" sasl

    11132 113.506167 192.168.18.9 192.168.18.10 LDAP 265 bindResponse(3) success

    11143 113.509296 192.168.18.10 192.168.18.9 LDAP 664 bindRequest(9) "<ROOT>" sasl

    11145 113.510012 192.168.18.9 192.168.18.10 LDAP 265 bindResponse(9) success

    0 comments
  3. VPHAN 25,000 Reputation points Independent Advisor
    2025-12-19T04:27:51.5533333+00:00

    It tells a story of two different identities trying to authenticate, and the difference in their success explains the entire behavior (including the self-signed certificate).

    Here is the breakdown of the capture and the solution:

    The Trace Analysis: Machine vs. User: You are seeing a "Success then Fail" pattern because Packet 16797 through 16828 is NOT your User. It is the RD Gateway Server itself (Machine Account).

    The Success Block (RDG Machine Account):

    • Packets 16797 - 16819 (AS-REQ/REP & TGS-REQ/REP): The RD Gateway (MYSERVER$) requests a TGT and a Service Ticket.
    • Packets 16825 - 16828 (LDAP Bind): The RD Gateway uses that Service Ticket to bind to the DC via LDAP. It must do this to look up the incoming user's properties (RAP/CAP policies).
    • Why it works: The Machine Account likely negotiated RC4 (since you enabled 0x1C on the DC). The DC is happy, the Machine is happy.

    The Failure Block (The User):

    • Packet 16878 (AS-REQ): This is the User (MyAdmin) attempting to authenticate via the KDC Proxy.
    • The Context: Your Client (Workstation) is hardcoded to AES-256 via the ksetup script. Therefore, this AS-REQ Pre-Auth data is encrypted with the user's AES key.
    • Packet 16879 (Error): KRB5KDC_ERR_ETYPE_NOSUPP. The DC says: "I received an AES timestamp, but I do not have a valid AES key for this user in my database to decrypt it."

    Why the Keys are Missing (The "Red Zone" Aftermath)? You reset the user passwords, but you likely did it before you re-enabled RC4 (0x1C) or while the DC was in its "Private Network" zombie state. When the DC is unhealthy or "Private," password changes sometimes fail to generate the full suite of supplementalCredentials (the attribute holding the keys) correctly, or they default to the lowest common denominator (RC4) if the KDC service wasn't fully initialized.

    The User Account currently holds an RC4 hash (which is why you might see tickets if you relaxed the client config), but it effectively has Null/Corrupt AES keys.

    The solution: You must regenerate the AES keys for the user now that the DC is healthy.

    Verify the User Object: In AD Users & Computers (or PowerShell), ensure the user MyAdmin has msDS-SupportedEncryptionTypes set to 24 (0x18) or 28 (0x1C). (Recommendation: Set it to 0x18 to force AES compliance, matching your client).

    The "Magic" Reset: Reset the MyAdmin password one more time.

    Crucial: Do this on the DC itself to avoid any replication latency or RPC/Firewall weirdness.

    This action forces the KDC to take the cleartext password and compute the AES-128 and AES-256 keys i__ediatel__

    Validate with Wireshark: Start a new capture. Retry the connection.

    You should see Packet 16878 (User AS-REQ) receive an AS-REP instead of an Error.

    Once the User gets the TGT, the RD Gateway will complete the NLA handshake, and the Self-Signed Certificate warning will disappear, replaced by the secure session.

    One Final Check: Look at Packet 16878 in your current trace. Expand Kerberos > as-req > req-body > cname. It will almost certainly confirm the failing identity is the User.

    VP

    0 comments
  4. Serge Caron 25 Reputation points
    2025-12-19T01:49:14.0466667+00:00

    OOPS! (Once again ;-)

    Here is the Wireshark capture of a logon attempt:

    No. Time Source Destination Protocol Length Info

    16746 215.371899 192.168.18.10 192.168.18.9 KRB5 226 AS-REQ

    16747 215.372616 192.168.18.9 192.168.18.10 KRB5 201 KRB Error: KRB5KDC_ERR_ETYPE_NOSUPP

    16797 215.517956 192.168.18.10 192.168.18.9 KRB5 283 AS-REQ

    16798 215.518440 192.168.18.9 192.168.18.10 KRB5 268 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED

    16805 215.527402 192.168.18.10 192.168.18.9 KRB5 363 AS-REQ

    16807 215.528133 192.168.18.9 192.168.18.10 KRB5 324 AS-REP

    16816 215.528713 192.168.18.10 192.168.18.9 KRB5 325 TGS-REQ

    16819 215.529947 192.168.18.9 192.168.18.10 KRB5 359 TGS-REP

    16825 215.530498 192.168.18.10 192.168.18.9 LDAP 487 bindRequest(21) "<ROOT>" sasl

    16828 215.531269 192.168.18.9 192.168.18.10 LDAP 265 bindResponse(21) success

    16854 215.543272 192.168.18.10 192.168.18.9 KRB5 367 TGS-REQ

    16857 215.544707 192.168.18.9 192.168.18.10 KRB5 339 TGS-REP

    16878 215.642572 192.168.18.10 192.168.18.9 KRB5 226 AS-REQ

    16879 215.643241 192.168.18.9 192.168.18.10 KRB5 201 KRB Error: KRB5KDC_ERR_ETYPE_NOSUPP

    17441 218.276608 192.168.18.10 192.168.18.9 KRB5 296 AS-REQ

    17442 218.277201 192.168.18.9 192.168.18.10 KRB5 201 KRB Error: KRB5KDC_ERR_ETYPE_NOSUPP

    53836 602.821248 192.168.18.10 192.168.18.9 SMB2 746 Session Setup Request

    53838 602.822452 192.168.18.9 192.168.18.10 SMB2 315 Session Setup Response

    Regards,

    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.