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

I performed a clean install of Windows 11 24H2 on the client-side managed laptop/BYOD and on the target-side Windows domain computer.

RDP is experiencing the same problem authenticating Kerberos, showing the same error.

We use computers that are shipped with Windows 11.

"So, it doesn't seem to be a problem with upgrading from Windows 10 to Windows 11."

Answer 2

Hello

Two changes I know of for Windows 24H2/WS 2025 that could affect this.

1. The RDS connection for 24H2 pr Windows Server 2025 are only supported with TCP and not UDP.
2. NTLMv1 was disabled in Windows 24H2 and Windows Server 2025

Darrell

Answer 3

Hello Darrell,

Thanks for the answer, but I've mentioned several times here that we only use Kerberos.

1. We haven't used NTLM in years.
2. We've also been using TCP for a long time.

We're not addressing the connection between 24H2 and the RDS server here.

Answer 4

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.

Answer 5

This issue is killing us right now - Almost the exact same scenario as described in the OP. Remote, VPN-connected non domain-joined machines trying to access a domain via Kerberos authentication. We access a client's SMB shares this way. NTLM is not an option and the client is not going to make radical adjustments to their security posture just to accomodate us.

23H2 and earlier -every machine works.

24H2 - not a single machine works.

We have spent a week scouring local policy, group policy and registry settings with no luck or change. Even better is that after 10 days you cannot rollback, so our only option seems to be wiping almost 30 PCs and laptops to get them back to 23H2 or earlier.

Microsoft is not acknowledging that this is an issue or bug but at this point it clearly is in my opinion. Client-side Kerberos authentication is failing in 24H2 and if you cannot fall back to NTLM authentication then the connection is simply dead.