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

Hello,

Thank you for posting in Microsoft Community forum.

If an insecure RDP connection is attempted and the encrypted Oracle remediation policy settings on the server or client block the insecure RDP connection, the CredSSP level does not match, the remote connection encounters an error that the CredSSP function is not supported:: CredSSP updates for CVE-2018-0886 (microsoft.com)

You can try the following workarounds:

1. Update the double-ended to the latest patch
2. How to modify the registry (please back up before modifying)

To modify the CredSSP registry of an RDP client, you need to restart it to take effect.

Open cmd with administrator privileges and run the following command to set the settings:

reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2 /f

Modification commands for this registry will not be affected in any way if your machine is in an intranet environment.

You can also change the value of AllowEncryptionOracle to 1 (mitigation) on the client side, and RDP will work unless the server side is unpatched.

3. This issue is mainly caused by a mismatch between the CredSSP levels of the double-ended, so there is no guarantee that installing a patch will fix this issue. Just keep the patch versions as close as possible on both the client and server sides (within 2-3 months apart) to ensure that the CredSSP levels on the client and server are the same so that they can communicate properly.

You can open PowerShell with administrator privileges on both ends and enter the following command line:

Get-Item -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters"

This command line checks the value of 'AllowEncryptionOracle': '0' = Force Updated Clients; 1 = Mitigated； 2 = Vulnerable

Then, according to the following figure, check whether the double-ended CredSSP level can allow RDP connections.

尝试 RDP 到 Azure 中的 Windows VM 时，出现 CredSSP 加密 oracle 修正错误 - Virtual Machines | Microsoft Learn

Hello,

you've misunderstood the reported problem.

We don't want make insecure RDP connetion.

Therefore our domain computer has forced policies. And non-domain computers (managed laptops or BYOD) has forced VPNs and setup "addkdc" command, which ads a Key Distribution Center (KDC) address for the given Kerberos realm.

So that managed laptops or BYOD can establish Kerberos authentication to their computer by RDP connection.

Of course, we make sure that both the client and the target have everything updated and set up on the latest versions.

Including RDP client versions and settings like CredSSP\Parameters

It's simply a problem of the new version deployed since 24H2. When up to 23H2 everything works with the same settings.

Even when trying to leave the latest version of 23H2 on the client side and the target side where the RDP client connects is the latest version of 24H2.

This way we can completely rule out a misconfiguration or version split in CredSSP\Parameters.

Of course we tried your recommended settings AllowEncryptionOracle': '0' = Force Updated Clients; 1 = Mitigated； 2 = Vulnerable

This does not solve anything, because even on one of the three set values (the same on both sides) the same error message occurs after entering the authentication credentials.

This problem is in 24H2, which we believe ingor "the ksetup /addkdc setting", which tells non-domain clients where to request a Kerberos ticket and thus fails to secure authentication.

I have exactly the same problem getting the same error message when trying to connect with a (non domain) Windows 11 24H2 client to a domain computer. The problem started after upgrade to 24H2, after a downgrade to 23H2 everything worked fine as before.

The new information is, that I have 3 non domain computers on 24H2: with two of them I have no problems connecting per RDP to domain computers, the problem appears only in the third client. So it seems to me, that there is a bug in 24H2, that is only virulent together with another "condition", probably some setting.

Any idea?

PS: Setting the recommended registry key (reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2 /f) was not helpful.

Hello,

I now understand what you mean. From the screenshot of your error, the NTLM authentication method on the remote computer is blocked. Microsoft has announced that it will gradually deprecate the NTLM authentication protocol starting with Windows 11 24H2, so it is recommended to use the kerberos authentication method in the future.

However, you used this command line on a non-domain computer, win11 24H2：ksetup/addkdc OURDOMAIN.COM dc1.ourdomain.com，to provide a Key Distribution Center (KDC) address for the given Kerberos realm. So that managed laptops or BYOD can establish Kerberos authentication to their computer by RDP connection. When you log in with the computer name, you will use Kerberos authentication first, and then the Kerberos authentication fails, and then it will fall back to NTLM, but the specific reason why Kerberos fails to fallback to NTLM is unknown.

In general, you used kerberos authentication when the client established the connection, but fell back to NTLM authentication, which was blocked by the remote computer, causing the error to occur.

You can view Group Policy for a remote computer by navigating to: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options, see if any configuration has been made to block NTLM authentication.

authentication, the client needs to directly access the domain controller for authentication, ensure that the DNS of the clientcan be properly resolved to the domain controller record, and enable the relevant port. You canperform a basic troubleshooting of DNS resolution and ports.

The following ports need to be enabled by default:

 Active Directory and Active Directory Domain Services Port Requirements | Microsoft Learn

Protocol and Port	AD and AD DS Usage	Type of traffic
TCP and UDP 389	Directory, Replication, User and Computer Authentication, Group Policy, Trusts	LDAP
TCP 636	Directory, Replication, User and Computer Authentication, Group Policy, Trusts	LDAP SSL
TCP 3268	Directory, Replication, User and Computer Authentication, Group Policy, Trusts	LDAP GC
TCP 3269	Directory, Replication, User and Computer Authentication, Group Policy, Trusts	LDAP GC SSL
TCP and UDP 88	User and Computer Authentication, Forest Level Trusts	Kerberos
TCP and UDP 53	User and Computer Authentication, Name Resolution, Trusts	DNS
TCP and UDP 445	Replication, User and Computer Authentication, Group Policy, Trusts	SMB,CIFS,SMB2, DFSN, LSARPC, NbtSS, NetLogonR, SamR, SrvSvc
TCP 25	Replication	SMTP
TCP 135	Replication	RPC, EPM
TCP Dynamic<br><br>49152 – 65535(windows server 2008 later.	Replication, User and Computer Authentication, Group Policy, Trusts	RPC, DCOM, EPM, DRSUAPI, NetLogonR, SamR, FRS
UDP 123	Windows Time, Trusts	Windows Time
TCP and UDP 464	Replication, User and Computer Authentication, Trusts	Kerberos change/set password
UDP Dynamic	Group Policy	DCOM, RPC, EPM
UDP 138	DFS, Group Policy	DFSN, NetLogon, NetBIOS Datagram Service
UDP 137	User and Computer Authentication,	NetLogon, NetBIOS Name Resolution
TCP 139	User and Computer Authentication, Replication	DFSN, NetBIOS Session Service, NetLogon

If you need to use the kerberos authentication method and know what caused the kerberos authentication failure to fall back to NTLM authentication, you need to collect logs related to the verification to troubleshoot the cause.

Hello,

Let me try to summarize the facts:

1, We have been using only Kerberos authentication for a long time.

2, NTLM we have GPOs disabled for domain computers - also for a long time (using GPO MSFT Security Baselines - Computer).

3, We have not made any changes on the domain controller side, domain computers and GPO policies, firewalls etc.

4, Managed laptops or BYOD can success fully establish Kerberos authentication to their computer by RDP connection until managed laptops or BOYD was on Win 11 23H2.

5,

Test A:

Client (Managed laptops or BYOD) = with Win11 23H2

Target (Domain PC) = with Win11 24H2

RDP kerberos authentication Works!

Test B:

Client (Managed laptops or BYOD) = with Win11 24H2

Target (Domain PC) = with Win11 24H2

RDP kerberos authentication FAILED - not working.

Test C:

Client (Managed laptops or BYOD) = with MacOS

Target (Domain PC) = with Win11 24H2

RDP kerberos authentication Works too!

NOTE: MacOS has similar settings to Windows (ksetup /addkdc)

/etc/krb5.conf

[libdefaults]

default_realm = OURDOAMIN.COM

[realms]

OURDOMAIN.COM = {

kdc = dc1.ourdomain.com

}

This allows us to rule out incorrect settings, e.g. firewall, DNS forwarding, etc.

The problem is only between the latest versions of Windows 11 from 24H2 to 24H2.

If I enable debug log

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Registry Value: LogLevel

Value Type: REG_DWORD

Value Data: 0x1

The logos are not telling because they are exactly the same even though RDP works or not

RDP kerberos auth. working combination (23H2 -> 23H2, 23H2 -> 24H2)

RDP kerberos auth not working combination (24H2 -> 24H2, 24H2 -> 23H2)

Logs PC-BOYD from 24H2 to 24H2 - RDP Kerberos not working

A Kerberos error message was received:

on logon session PC-BYOD\testuser

Client Time:

Server Time: 5:47:23.0000 12/20/2024 Z

Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED

Extended Error:

Client Realm:

Client Name:

Server Realm: OURDOMAIN.COM

Server Name: krbtgt/OURDOMAIN.COM

Target Name: krbtgt/******@OURDOMAIN.COM

Error Text:

File: onecore\ds\security\protocols\kerberos\client2\logonapi.cxx

Line: 10a7

Error Data is in record data.

A Kerberos error message was received:

on logon session PC-BYOD\testuser

Client Time:

Server Time: 5:47:23.0000 12/20/2024 Z

Error Code: 0x34 KRB_ERR_RESPONSE_TOO_BIG

Extended Error:

Client Realm:

Client Name:

Server Realm: OURDOMAIN.COM

Server Name: krbtgt/OURDOMAIN.COM

Target Name: krbtgt/******@OURDOMAIN.COM

Error Text:

File: onecore\ds\security\protocols\kerberos\client2\logonapi.cxx

Line: 10a7

Error Data is in record data.

A Kerberos error message was received:

on logon session

Client Time:

Server Time: 5:47:23.0000 12/20/2024 Z

Error Code: 0x34 KRB_ERR_RESPONSE_TOO_BIG

Extended Error:

Client Realm:

Client Name:

Server Realm: OURDOMAIN.COM

Server Name: TERMSRV/pc-n3z.OURDOMAIN.COM

Target Name: TERMSRV/pc-n3z.******@OURDOMAIN.COM

Error Text:

File: onecore\ds\security\protocols\kerberos\client2\kerbtick.cxx

Line: 135a

Error Data is in record data.

Logs NB-MANAGED from 23H2 to 23H2 - RDP kerberos auth Working

A Kerberos error message was received:

on logon session NB-MANAGED\Test

Client Time:

Server Time: 7:33:40.0000 12/20/2024 Z

Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED

Extended Error:

Client Realm:

Client Name:

Server Realm: OURDOMAIN.COM

Server Name: krbtgt/OURDOMAIN.COM

Target Name: krbtgt/******@OURDOMAIN.COM

Error Text:

File: onecore\ds\security\protocols\kerberos\client2\logonapi.cxx

Line: e35

Error Data is in record data.

A Kerberos error message was received:

on logon session NB-MANAGED\Test

Client Time:

Server Time: 7:33:40.0000 12/20/2024 Z

Error Code: 0x34 KRB_ERR_RESPONSE_TOO_BIG

Extended Error:

Client Realm:

Client Name:

Server Realm: OURDOMAIN.COM

Server Name: krbtgt/OURDOMAIN.COM

Target Name: krbtgt/******@OURDOMAIN.COM

Error Text:

File: onecore\ds\security\protocols\kerberos\client2\logonapi.cxx

Line: e35

Error Data is in record data.

A Kerberos error message was received:

on logon session

Client Time:

Server Time: 7:33:40.0000 12/20/2024 Z

Error Code: 0x34 KRB_ERR_RESPONSE_TOO_BIG

Extended Error:

Client Realm:

Client Name:

Server Realm: OURDOMAIN.COM

Server Name: TERMSRV/pc-5q0.OURDOMAIN.COM

Target Name: TERMSRV/pc-5q0.******@OURDOMAIN.COM

Error Text:

File: onecore\ds\security\protocols\kerberos\client2\kerbtick.cxx

Line: 1300

Error Data is in record data.

It is possible that this is a bug in version 24H2.
But your development team should know what is technologically new and find out the cause of this behavior.
I have exhausted all possibilities.