Event banner
The evolution of Windows authentication
Event Ended
Wednesday, Mar 27, 2024, 03:30 PM PDTEvent details
As the security landscape evolves, Windows must continue to change to protect users and organizations. Foundational to this is user authentication. In Windows Server 2025 and Windows vNext, we have c...
Heather_Poulsen
Updated Dec 27, 2024
ZakWhitt
Apr 10, 2024Copper Contributor
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.
mamoreau
Apr 10, 2024Iron Contributor
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.