Event banner
Event details
The TryIPSPN solution is only suitable in cases where DNS is not available, but direct IP addresses are usable. There is one major use case not properly covered by this: port forwarding and any kind of network tunneling that doesn't work like a traditional VPN. There was literally a demo yesterday for RDP over SSH using Azure Arc where TryIPSPN wouldn't work as mstsc connects through a localhost random port, so from the RDP client's point of view, the target is "localhost", not one of the IP addresses known by both the client and server, and certainly not the expected FQDN for the target as DNS is also not possible in such a scenario. I currently fix this through API hooking of mstsc to set a user-provided server name different from the one used for the network connection. Is there a plan to properly cover use cases where a protocol like RDP can correctly use Kerberos through a connection tunnel, meaning the true target host name has to be provided separately?
Kerberos does not have a hard requirement for target names to be bound to any protocol, it just needs a name that a user can verify. The RDP mechanism is potentially possible, it'd likely involve some other teams, but we have some security-related reservations. IP address-based security is fraught with issues, and we would prefer not to encourage it, particularly the use of IP addresses over domain names.
- Just to be clear - I also don't like the usage of IP addresses in cases where the server name can be provided explicitly. When DNS is not available, or when using a localhost connection tunnel, the server name used for the connection is the first thing that won't validate properly. Rather than make it work with localhost and IP addresses, some use cases like RDP can easily accept an explicit server name to use for the validation different from the one used for the connection, and that's what I'm suggesting we fix here. I've got it implemented using API hooking in mstsc using MsRdpEx (https://github.com/Devolutions/MsRdpEx) to expose the internal UserSpecifiedServerName RDP ActiveX properly which is already used for this purpose with the RD Gateway protocol, otherwise server name validation would be done using the RD Gateway host instead of the destination RDP server host. The real issue here is the lack of a .RDP "UserSpecifiedServerName" file option and corresponding RDP ActiveX officially-supported extended property. Solutions already exist in the Microsoft RDP client, but they are tied to the RD Gateway protocol. We just need to enable the same mechanisms for non-RDG transport types, which would greatly enhance the ability to support Kerberos with all the non-RDG connection tunneling solutions on the market today, including the recent SSH tunneling demo with Azure Arc to connect with RDP using localhost and a random port. In our case, we implement a similar solution using Devolutions Gateway, but the problem is the same as SSH tunneling: we need to manually inject the expected server name for validation alongside our injected KDC proxy for Kerberos to fully work without a name mismatch error.