Resolving Error 0xC000035B: LmCompatibility Issues in Windows Server

Table of Contents

Connecting to remote systems via Remote Desktop Protocol (RDP) is a fundamental operation in modern IT environments. However, users occasionally encounter perplexing errors that prevent successful connections. This article addresses a specific connection issue, Error 0xC000035B, which typically arises when a Terminal Services client using RDP 8.0 attempts to connect through a Windows Server 2012 RD Gateway server. Understanding the root cause and implementing the correct resolution is crucial for maintaining seamless remote access and ensuring robust security.

RDP 8.0, introduced with Windows Server 2012, brought significant enhancements in performance and security. The RD Gateway acts as a crucial proxy, allowing users to connect to internal network resources from outside the corporate firewall without requiring a Virtual Private Network (VPN). When these components encounter configuration discrepancies, particularly concerning authentication protocols, connection failures like 0xC000035B can occur.

Understanding the Symptoms¶

The primary symptom of this issue is the inability of an RDP 8.0 client to establish a connection through a Windows Server 2012 RD Gateway. Users attempting to connect will receive a generic, yet frustrating, error message indicating a connection failure. This message typically states: “This computer can’t connect to the remote computer.”

Beyond the client-side notification, the critical diagnostic information is logged on the RD Gateway server itself. Event 4625, an Audit Failure event, will be recorded in the Security log. This event provides granular details about the failed logon attempt, and most importantly, it will explicitly report the 0xC000035B error code. This specific error code is a key indicator that the problem lies with authentication or channel binding integrity.

The Event 4625 log entry will contain specific fields that pinpoint the failure. You will observe details such as “Logon Type: 3” (network logon), and under “Failure Information,” you’ll find “Failure Reason: An Error occurred during Logon.” Crucially, the “Status” field will show “0xC000035B” and “Sub Status: 0x0.” This confirms that the authentication attempt failed specifically due to issues with Security Support Provider Interface (SSPI) channel bindings.

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          <DateTime>
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      RDGW.CONTOSO.COM
Description:
An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       Myuser
    Account Domain:     Contoso

Failure Information:
    Failure Reason:     An Error occured during Logon.
    Status:         0xC000035B
    Sub Status:     0x0

This detailed event log entry is instrumental for administrators to quickly identify the nature of the problem, distinguishing it from other common RDP connection issues like network connectivity problems or incorrect credentials. The “Sub Status” being 0x0 further narrows down the problem to a specific aspect of the authentication negotiation.

Delving into the Cause: LmCompatibility and Channel Bindings¶

The root cause of Error 0xC000035B lies in the interplay between an outdated authentication protocol, NTLMv1, and a modern security feature, channel bindings, enforced by RDP 8.0 on Windows Server 2012. This issue surfaces when the LmCompatibility registry value on the client machine is configured to force the use of NTLMv1. Any LmCompatibility value less than 3 compels the system to default to the less secure NTLMv1 protocol.

By default, Windows Server 2012, when processing RDP 8.0 connections, mandates the presence of channel bindings as a security measure. Channel bindings serve to cryptographically bind the inner authentication channel (e.g., NTLM or Kerberos) to the outer secure channel (e.g., TLS/SSL). This mechanism is a critical defense against relay attacks, where an attacker intercepts and replays authentication credentials. When NTLMv1 is used for authentication, these essential channel bindings are not transmitted as part of the protocol exchange. Consequently, the authentication process fails, leading to the “Client’s supplied Security Support Provider Interface (SSPI) channel bindings were incorrect” error, which manifests as 0xC000035B.

Understanding LmCompatibilityLevel¶

The LmCompatibilityLevel registry setting dictates the type of authentication protocol used by the client when negotiating with servers. This setting determines which LAN Manager and NTLM authentication methods are negotiated. The values range from 0 to 5, with lower values indicating older, less secure protocols, and higher values indicating modern, more secure protocols.

LmCompatibilityLevel Value	Description	Security Implications
0	Send LM and NTLM responses.	Least secure; allows LM and NTLMv1 authentication.
1	Send LM and NTLM responses. Use NTLMv2 session security if negotiated.	Slightly better, but still vulnerable to LM and NTLMv1 attacks.
2	Send NTLM response only.	Prevents LM authentication but still uses NTLMv1 by default.
3	Send NTLMv2 response only. Refuse LM and NTLM.	Recommended baseline. Forces NTLMv2, improving security significantly.
4	Send NTLMv2 response only. Refuse LM. Accept NTLM.	Similar to 3 but allows NTLMv1 if the server doesn’t support NTLMv2. Avoid if possible.
5	Send NTLMv2 response only. Refuse LM and NTLM.	Most secure. Forces NTLMv2 and prevents any fallback to older protocols.

When LmCompatibilityLevel is set to 0, 1, or 2, the client is either forced to use NTLMv1 or allows it as a fallback. This is problematic because NTLMv1 is susceptible to various attacks, including brute-force attacks and relay attacks, due to its weak hashing algorithm and lack of channel binding support.

The Significance of Channel Bindings¶

Channel binding tokens (CBTs) are a crucial security feature that helps prevent authentication relay attacks. In the context of RDP, when a client authenticates to a server, the authentication process (e.g., NTLMv2) occurs over a secure transport layer, typically TLS/SSL. Channel bindings ensure that the authentication credentials presented are inextricably linked to that specific secure transport channel.

If a client uses NTLMv1 for authentication, it does not generate or transmit the necessary channel binding tokens. When the Windows Server 2012 RD Gateway, which by default expects and enforces these bindings for RDP 8.0 connections, does not receive them, it interprets this as a potential security risk or an invalid authentication attempt. This mismatch between the client’s protocol capabilities (or enforced settings) and the server’s security requirements leads directly to the 0xC000035B error.

Comprehensive Resolution Strategies¶

To resolve Error 0xC000035B, you have two primary methods. Both involve adjusting registry settings, so it’s paramount to exercise caution. Before making any changes, it is highly recommended to back up the registry or create a system restore point. For information about how to edit the registry, consult the “Changing Keys And Values” Help topic in Registry Editor.

Method 1: Adjust LmCompatibilityLevel on the Client¶

This method is generally preferred as it enhances the client’s security posture by promoting the use of more robust authentication protocols. By adjusting the LmCompatibilityLevel registry value on the client machine, you ensure that it does not force NTLMv1, allowing NTLMv2 to be negotiated, which includes channel binding support.

Steps to Modify LmCompatibilityLevel:

1. Open Registry Editor:

   • Press Windows Key + R to open the Run dialog box.
   • Type regedit and press Enter. Click “Yes” if prompted by User Account Control.

2. Navigate to the LmCompatibilityLevel Key:

   • In Registry Editor, navigate to the following path:
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3. Locate or Create LmCompatibilityLevel:

   • In the right-hand pane, look for a DWORD (32-bit) Value named LmCompatibilityLevel.
   • If it exists, proceed to the next step.
   • If it does not exist, right-click on an empty space in the right pane, select New > DWORD (32-bit) Value, and name it LmCompatibilityLevel.

4. Modify the Value Data:

   • Double-click LmCompatibilityLevel.
   • In the “Value data” field, enter 3 or a higher value (e.g., 5). Setting it to 3 configures the client to send NTLMv2 responses only and refuse LM and NTLMv1.
   • Ensure “Base” is set to Decimal.
   • Click OK.

5. Restart the Client Machine:

   • For the changes to take effect, you must restart the client computer.

After restarting, the client machine will attempt to use NTLMv2 for authentication, which includes the necessary channel bindings, thereby allowing the connection through the RD Gateway server. This approach is recommended as it aligns with modern security best practices.

Method 2: Disable EnforceChannelBinding on the RD Gateway Server¶

This method involves relaxing the security requirements on the RD Gateway server by instructing it to ignore missing channel bindings. While it resolves the immediate connection error, it’s generally considered less secure than Method 1 because it disables a valuable protection against relay attacks. Use this method only if Method 1 is not feasible or as a temporary workaround.

Steps to Modify EnforceChannelBinding:

1. Open Registry Editor on the RD Gateway Server:

   • Log on to the Windows Server 2012 RD Gateway server.
   • Press Windows Key + R, type regedit, and press Enter. Click “Yes” if prompted by User Account Control.

2. Navigate to the RDP-Tcp Key:

   • In Registry Editor, navigate to the following path:
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

3. Locate or Create EnforceChannelBinding:

   • In the right-hand pane, look for a DWORD (32-bit) Value named EnforceChannelBinding.
   • If it exists, proceed to the next step.
   • If it does not exist, right-click on an empty space in the right pane, select New > DWORD (32-bit) Value, and name it EnforceChannelBinding.

4. Modify the Value Data:

   • Double-click EnforceChannelBinding.
   • In the “Value data” field, enter 0 (zero). This value instructs the server to ignore missing channel bindings.
   • Ensure “Base” is set to Decimal.
   • Click OK.

5. Restart the Remote Desktop Gateway Service:

   • For the changes to take effect, you must restart the Remote Desktop Gateway service.
   • Open Services (type services.msc in Run dialog or search).
   • Locate “Remote Desktop Gateway” service, right-click it, and select Restart.

This modification tells the RD Gateway to proceed with authentication even if channel bindings are not present. While it resolves the connectivity issue, it is vital to understand that it reduces the overall security of your remote access infrastructure. If you use this method, you should plan to implement Method 1 on client machines as a long-term solution and revert the EnforceChannelBinding setting on the server.

Best Practices and Security Considerations¶

While resolving the immediate error is the priority, it’s equally important to consider the security implications of your chosen solution. Always strive for the most secure configuration possible.

• Prioritize Method 1 (Client-Side LmCompatibilityLevel): This is the superior long-term solution. By configuring clients to use NTLMv2, you enhance their security and ensure compatibility with modern server security requirements without compromising the gateway’s defenses.
• Avoid NTLMv1: NTLMv1 is an outdated authentication protocol with known vulnerabilities. It should be deprecated in favor of NTLMv2 or, ideally, Kerberos authentication where possible. Regularly review your network’s LmCompatibilityLevel settings on all machines.
• Maintain Channel Binding Enforcement: Channel bindings are a vital security mechanism. Disabling EnforceChannelBinding on the RD Gateway server should only be a temporary measure. Once all problematic clients have been updated to use NTLMv2 (via Method 1), revert EnforceChannelBinding back to its default or recommended value (e.g., 1 or 2, depending on specific server version defaults, but generally, enforcement should be enabled).
• Keep Systems Updated: Regularly apply security updates and patches to both client and server operating systems. These updates often include critical security fixes and improvements to authentication protocols.
• Monitor Security Logs: Continue to monitor Event 4625 and other security-related events on your RD Gateway servers. This vigilance helps in detecting other potential authentication issues or security threats early.

```mermaid
graph TD
A[RDP Client (LmCompatibility < 3)] → B{Attempt RDP 8.0 Connection};
B → C[RD Gateway Server (Win Server 2012)];
C → D{NTLMv1 Authentication Negotiation};
D – No Channel Bindings → E[RD Gateway Enforces Channel Bindings];
E – Mismatch → F[Authentication Fails];
F → G[Event 4625 (0xC000035B) Logged];
G → H[Client Displays “Cannot Connect” Error];

I[Resolution Method 1: Set Client LmCompatibility >= 3] --> J[Client Uses NTLMv2];
J -- Sends Channel Bindings --> K[RD Gateway Receives Channel Bindings];
K --> L[Authentication Successful];

M[Resolution Method 2: Set Server EnforceChannelBinding = 0] --> N[RD Gateway Ignores Missing Channel Bindings];
N --> L;

```
Flowchart: Lifecycle of Error 0xC000035B and its Resolutions

For a deeper understanding of NTLM authentication and its evolution, consider researching official Microsoft documentation or educational videos on the topic. Understanding the nuances of these protocols is key to maintaining a secure and functional remote access environment.

Conclusion¶

Error 0xC000035B, while seemingly complex, is fundamentally an authentication mismatch problem stemming from the use of NTLMv1 with RDP 8.0’s channel binding enforcement. By understanding the roles of LmCompatibilityLevel and EnforceChannelBinding, administrators can effectively resolve this issue. Prioritizing client-side adjustments to enforce NTLMv2 is the recommended approach for both connectivity and security. Always remember to implement changes cautiously and validate their effectiveness while upholding robust security practices.

If you’ve encountered this error, what method did you find most effective? Do you have any additional tips or considerations regarding RDP security and authentication protocols? Share your experiences and insights in the comments below!