After update to latest Win 11 24H2 RDP kerberos authentication from non-domain PC to domain joined PC stop working

Question

After update to latest Win 11 24H2 RDP kerberos authentication from non-domain PC to domain joined PC stop working:

Error message:

An authentication error has occurred.

The function requested is not supported.

Remote Computer : computer.ourdomain.com

This cloud be due to NTLM authentication being blocked on the remote computer.

This could also be due to CredSSP encryption oracle remediation.

Error code: 0x0

Extended error code: 0x0

Setup - Non-domain computer:

( home office users BYOD device with Win11 Pro updated to 24H2 )

1, ksetup /addkdc OURDOMAIN.COM dc1.ourdomain.com

2, reboot

3, Dialed VPN to company internal network

4, mstsc - RDP Connection from nondomain (BYOD) to company domain joined computer:

Computer: testcomputer.ourdomain.com
User name: OURDOMAIN.COM\testuser

5, Error (attached screenshot)

Setup – Domain computer:

Domain computer has Kerberos Authentication and valid RDP certificate. 

GPO settings:

Set client connection encryption lever = High Level

Require use of specific security layer for remote (RDP) connections: Security Layer = SSL

Require user authentication for remote connections by using Network Level Authentication = Enable

---

This setup work until fully updated 23H2, after upgrade to 24H2, mstsc (RDP) stop working with the same setup.

 As a workaround, NLA can be turned off in the GPO for domain computers, but this is a security degradation.

or as admin run before RDP command: klist add_bind OURDOAMIN.COM dc1.ourdomain.com but for this has user no rights.

The funny thing is that for example tested from MacOs (non-joined) RDP authenticated with kerberos works.

MacOS has for example this settings:

 /etc/krb5.conf

[libdefaults]

default_realm = OURDOAMIN.COM

[realms]

OURDOMAIN.COM = {

kdc = dc1.ourdomain.com

}

Answer 1

We discovered this issue when we upgraded several systems to Windows 11 24H2 for testing. In the past for Kerberos to work properly we always had to use username @ domain.FQDN.com in order to connect cross domain or from non-domain to domain. For some reason MS in their infinite wisdom BROKE this with 24H2. We now have to use domain.FQDN.com\username as the login username for RDP to work again with Kerberos. This is seriously frustrating as all of our user guides have users doing it the other way that's always worked.

This was an extremely helpful post. I had a machine connected to EntraID but that accessed a file share (so not RDS related, but definitely Kerberos related) that was cross-domain, and this solved my problem.

Answer 2

This solved it for us. Notably for our use previously kerberos realms were mapped with ksetup /addhosttorealmmap. But after 24H2 that has stopped mapping the domain at all. As in it shows no change in the output of ksetup, which appears broken.

If I understand this correctly, I may just be manually mapping to the right realm by adding the domain.com/username, although I also added a registry key-value manually in \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm.

TBH, its finally working again so I don't want to fiddle with it. But theoretically, if I had the realm mapping right, I may just be able to provide the username without any domain.com/* or *@domain.com, which potentially may have been why they changed it in the first place. 🤷

We have a ticket open with MS because we also found 24H2 breaks sysvol access in kerberos only domains because there's some sort of regression in 24H2 that FORCES NTLM usage to talk to the domain sysvol. If you have the setting enabled to block outbound NTLM on Windows 11 24H2 the system stops being able to pull GPOs and other content from the domain. The workaround we found was to turn back on allowing outbound NTLM by editing the registry on each broken machine manually. Once we did this we found our issues with RDP also stopped and we could go back to using the UPN style name. Microsoft has clearly borked something with 24H2 regarding NTLM...

Answer 3

That's a great link, and I was very hopeful until I opened the Group Policy editor and navigated to:

Computer Configuration > Administrative Templates > Windows Components > Windows Update

But there isn't a section for "Manage updates offered from Windows Update"

Instead I see "Manage updates offered from Windows Server Update Service". I don't remember, but it could be that this machine was originally part of the domain, but then I left the domain when the server was updated to v2019.