Event banner
Event details
25 Comments
Thank you for joining us this week for the Windows Server Summit! Q&A is now closed, but all sessions are available on demand so you can watch and learn when it is convenient for you. We hope you enjoyed the event.
- Which Version of the Windows Client will include Local KDC nad IAKerb? Thx
- Local KDC looks very interesting but will it be backported? Server 2019 and W10 ltsc 2019 will be in use to at least 2029, the 22 editions even longer (IoT for W10) Without local KDC for them , we will have to remain on NTLM...................
- Hi Mats, as I responded to Marc below, we’re not able to talk about backport publicly yet, but we’d appreciate hearing any feedback you have around downlevel need and requirements. Please feel free to message me directly through Tech Community, or email us at ntlm@microsoft.com.
- While options have been added to properly disable NTLM in SMB, will there be an effort to add similar options for the RDP client? There is currently no good way to disable outbound NTLM in the RDP client specifically, and to make matters worse, things like server validation happen *after* the NTLM/Kerberos exchange in CredSSP right now. While RDP responder attacks are not as popular as with other protocols using Windows authentication, there is a lot of area for improvement for RDP client hardening. Again, I would be more than happy to point you to the places where this could be improved, most of which would need to be done in mstsc.
- Yes, we are expanding policies to allow you to control NTLM on a per-protocol basis.
- 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.
- For the local KDC solution, will it support anything other than password-based authentication? From previous presentations on NTLM deprecation, the information I've received is that no thought was put into supporting the Kerberos PKINIT extension required for smartcard authentication. I would really like to see smartcard authentication become an option for workgroup machines and I would be more than willing to test it.
- We have no plans to support PKINIT for workgroup at this time. PKINIT requires a non-trivial infrastructure deployment for PKI and if customers want to use PKI, they should consider deploying AD.
- While Remote Desktop supports Kerberos today, it will fall back to NTLM in IP-based scenarios or when the target is not joined to a domain. Will the RDP client and server be adopting IAKerb to replace NTLM? To expand on that, it would be very beneficial to modern authentication scenarios to see the RDP gateway be able to redirect clients to Azure AD or ADFS for rich authentication at the gateway level then permit the client to authenticate to the target with IAKerb.
- For the RDP client and server, excluding the RD Gateway scenario, my understanding is that with IAKerb and TryIPSPN, Kerberos will work in cases where there is no KDC line-of-sight, using either the IP address or FQDN, where it would have normally failed without the KDC line-of-sight, or when using the IP address without manually enabling the TryIPSPN solution that exists in previous versions of Windows, but isn't enabled by default. For the RD Gateway scenario, I am also looking for more information. We've got customers that start using cloud Entra Joined Windows 11 to connect through hybrid-joined RD Gateway servers for the same domain, which is getting really, really weird in terms of authentication. While the Windows client can do outbound Kerberos, the Entra ID joined part of the RD Gateway doesn't do inbound Kerberos, so what we're seeing is an NTLM downgrade. It really isn't clear how this is all supposed to work and how this is going to keep working without NTLM in the future.
- This is what I was getting at. Kerberos support for AzureAD joined machines, connecting through the RDP gateway to on-prem servers when "cloud trust" authentication is setup. I can use Windows Hello auth for most everything except for RDP through the gateway which still reverts to NTLM.
- I have a list of bug fixes and minor improvements around KDC proxying in the Windows Kerberos client, but also the Microsoft RDP client that would go a long way to make KDC proxying a suitable option to provide a KDC line-of-sight alongside the IAKerb effort. I don't see them as mutually exclusive, especially since KDC proxying is already supported in many non-Windows Kerberos client stacks, while IAKerb isn't. This is more of an open offer than a question, since you've asked for feedback, I would really like to point you in the right direction for a few quick wins there.
- Thanks for the feedback! This is something we are interested in doing.
- How far back will IAKerb be backported? My main issue with IAKerb is that it is an alternative approach to KDC proxying, and unless IAKerb is backported to *all* previous versions of Windows Server that are still supported, then I will need to use both IAKerb and KDC proxying to ensure a KDC line-of-sight.
- Hi Marc, we’re not able to talk about backport publicly yet, but we’d definitely appreciate any feedback you have around downlevel need and requirements. Please feel free to message me directly on this forum, or email us at ntlm@microsoft.com.
- With MS’s move to get away from NTLM, will Kerberos be coming to RDP and RDP gateway in server 2025?
- Hi Joseph - yes, RDP will receive these features.
