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

Anonymous
2024-12-14T07:01:01+00:00

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

}

Windows for business | Windows Client for IT Pros | User experience | Remote desktop clients

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.

0 comments No comments
{count} votes

23 answers

Sort by: Most helpful
  1. Anonymous
    2024-12-17T06:38:49+00:00

    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.

    1. 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

    0 comments No comments
  2. Anonymous
    2024-12-17T17:58:33+00:00

    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.

    0 comments No comments
  3. Anonymous
    2024-12-18T13:22:56+00:00

    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.

    0 comments No comments
  4. Anonymous
    2024-12-20T02:50:30+00:00

    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.

    0 comments No comments
  5. Anonymous
    2024-12-20T08:08:58+00:00

    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.

    0 comments No comments