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

Hello VPHAN,

Here is the answer to the conumdrum: there is an exception for the builtin domain administrator.

When the client computer from which the connection is made is not a member of the same AD forest ("SOMEDOMAIN.TLD") as the target computer and when the credentials are for any other user account, the target DC issues two DNS requests for "_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.SOMEDOMAIN.TLD: type SRV, class IN" and "_kerberos._tcp.dc._msdcs.SOMEDOMAIN.TLD" where " .

Upon receiving the "No such name" answer from the SOA public DNS servers of "somedomain.tld", the connection is downgraded to NTLMv1.2.

I do not know if exposing the builtin domain administrator account to RD connections is documented as an additionnal security risk.

A domain user no wanting to leave the current session can connect a domain-joined computer to a target computer using Kerberos by invoking a local account. In PowerShell 5.1, the command

Start-Process mstsc.exe -ArgumentList PathToConnector.rdp `
    -Credential $(Get-Credential -Message "Specify a Local user account:")

The connection is made in the context of the selected local user, meaning operations such as cut and paste are restricted.

However, the RDP session is Kerberos protected and the target user can be a member of the Protected Users group.

I will try to document this here.

Regards,

Hello VPHAN,

Approximately one third of the world population in 160 countries will celebrate Christmas today, either by conviction or by convention. Merry Christmas to you!

Here is the conumdrum: connections to the test rig (Server 2025) always succeed using "prompt for credentials:i:0", wheter from a local account or a domain joined account on the same workstation.

There is a vocabulary issue here but before I get to this, let's review the hardwired setup of these Server 2025. We have:

Internet --> Firewall External IPv4 --> Firewall Internal IPv4 --> Switch --> Server 2025 Static IPv4

The only incoming traffic NATed to the Server 2025 is on TCP port 443. Using UDP port 3391 has no bearing on the issue.

KdcProxy is an application as far as IIS is concerned. I posted question https://learn.microsoft.com/en-us/answers/questions/5678882/what-are-the-risks-of-exposing-the-windows-kerbero with the exact IIS parameters used in both Server 2025.

With this in mind, we have:

• "full address:s:myserver.mydomain.local" resolves to the internal IP address of the Server 2025
• "gatewayhostname:s:myserver.mydomain.tld" resolves to the external IP address of the firewall
• "prompt for credentials:i:1" should be set bnut this is not a necessary requirement
• "rdgiskdcproxy:i:1" is required to glue the proxy to the DC

Which leaves us with "kdcproxyname:s:...": what is the name space used here ? By construction, the firewall will not reflect anyting to the server if the server attemps to connect using this value. The client will not connect directly to anything inside the realm. Finally, if this should be an SPN (HTTP, TERMSVR, etc) what is expected here ?

Right now, this is not going the way you present it.

Regards,

Hello VPHAN,

I now have krbtgt encrypted with AES-256-CTS-HMAC-SHA1-96 instead of RC4 and I can see that this has no bearing on the issue.

If I force my production server to always present the myserver.mydomain.tld certificate (using SSLCertificateSHA1Hash), I can see the certificate mismatch when the client (joined to a domain that has no trust relationship with the target) connects.

mstsc.exe displays the name of the target machine myserver.mydomain.local and the subject name of the certificate rdg.mydomain.tld and ask to confirm the connection which will then be downgraded to NTLM.

This does not happen if the client is not domain joined: this can be a local account on the same machine.

I do not observe this behavior with my test Server 2025: kerberos succeeds whether the client is local or domain joined to some other domain. A tedious compare of the SPNs on both servers yields no indication of the reason for which a mismatch occurs.

The mismatch is created on purpose. Why does mstsc.exe succeeds in one case and not the other ?

Regards,

OOPS! That's not quite it. There seems to be a dependency on the remote DC support for RC4. No RC4 = pass, RC4 = downgrade, both DC Server 2025 with the RDG role installed.Back to your valuable knowledge ;-)

Regards,