Unable to Protect Rapid Recovery Agent Due to NTLM Restrictions Enforced by Local or Domain Policy (4378979)

Attempts to protect or pair with a Rapid Recovery Agent fail.

In the user interface, the following error is shown:

Service Host Error: Service error while handling request [POST https://localhost:8006/apprecovery/api/core/agents/validateAgentProtectionAbility]: Failed to connect to remote machine using provided credentials. This can be caused by one of the following:
    - Destination host name is incorrect or host is offline.
    - Destination host is behind firewall or similar protection software that prevents connection.
    - If you are trying to connect to Windows machine:
        - WMI service is not started or blocked by firewall.
    - If you are trying to connect to Linux machine:
        - SSH service is not started or blocked by firewall.
        - Provided SSH port is incorrect.

In the Core logs (C:\ProgramData\AppRecovery\Logs\AppRecovery.log), a related internal error appears:

ERROR - Replay.Agent.Client.AgentPairManagementAgentClient () Error while deserialize ServerError object. GET https://[AgentName]:8006/apprecovery/api/agent/pair/connect/?useNtlmOnly=True failed with HTTP status code InternalServerError: 

This indicates the Core attempted to connect to the agent using NTLM authentication, but the connection was blocked or failed on the agent side.

Symptoms

• Unable to protect or pair a Rapid Recovery Agent from the Core

• UI displays: Failed to connect to remote machine using provided credentials

• Core logs show: useNtlmOnly=True and InternalServerError

• Remote WMI tests (wbemtest or Get-WmiObject) return Access Denied

• Local WMI tests on the agent using \\localhost\root\cimv2 may succeed

• The protected machine is often a Domain Controller or hardened Windows Server

• Windows Event Viewer may show WMI/DCOM errors (e.g., Event ID 10028 or 10036)

The failure is typically caused by security policy configurations on the agent and/or the Core server:

1. NTLM Restrictions:
   • An incoming traffic policy on the agent machine explicitly denies NTLM authentication.
   • An outgoing traffic policy on the Core server prevents it from sending NTLM authentication to remote servers.
2. Network Access Denial: The service account used by the Core for protection is explicitly listed in the "Deny access to this computer from the network" policy on the agent machine.

Step 1: Check NTLM Restriction Policies

This step involves checking two related policies. Start by checking the incoming policy on the agent machine. If the issue persists, check the outgoing policy on the Core server.

1. Open the Local Security Policy editor (secpol.msc) or, for domain settings, the Group Policy Management Console (gpmc.msc).
2. Navigate to Local Policies > Security Options.
3. Locate and check the following policies:
   • On the AGENT machine:
     • Policy: Network security: Restrict NTLM: Incoming NTLM traffic
     • Problem: This policy is set to Deny all accounts.
     • Solution: Change it to Audit incoming NTLM traffic or Not Defined.
   • On the CORE server (if the first check doesn't solve it):
     • Policy: Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
     • Problem: This policy is set to Deny all.
     • Solution: Change it to Audit outgoing NTLM traffic or Not Defined.

Step 2: Check the "Deny Network Access" Policy

1. On the agent machine, go to the policy editor (secpol.msc or gpmc.msc).
2. Navigate to Local Policies > User Rights Assignment.
3. Find and open the policy Deny access to this computer from the network.
4. Verify that the user account the Core is using for protection is NOT on this list. If the account is present, remove it.

Step 3: Apply Changes

1. After making policy adjustments on any machine, open a Command Prompt as an Administrator.
2. Run the command gpupdate /force to apply the changes immediately.
3. Attempt to protect the agent again from the Rapid Recovery Core Console.

Additional Information

• For background, see KB 4033596 – NTLM and Pass-Through Authentication

• Related WMI troubleshooting KB: KB 4033088 – Using wbemtest to Test DCOM and WMI Connections