Share via

How to run the WinRM service as a different AD user.

Denis Pasternak 40 Reputation points
2026-02-08T20:44:29.8933333+00:00

Hello.

I need two or more WEF servers combined into an NLB cluster.

After preparing NLB and WEF, I started configuring WinRM access. Because when accessing the cluster name, I was getting a Kerberos error.

What I did:

Created a domain account

Registered an SPN

Setspn -s HTTP/nlb-01:5985 CONTOSO\wef-nlb-account

Setspn -s HTTP/nlb-01.contoso.local:5985 CONTOSO\wef-nlb-account

Now I'm getting the error: WinRM cannot process the request. The following error occurred while using Kerberos authentication:

Cannot find the computer nlb-01.contoso.local. Verify that the computer exists on the network and that the name

provided is spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.

Many instructions mention that the service must run under the user that was created for the spn. The WinRM service needs to be run under the CONTOSO\wef-nlb-account user. Alos in my test environment, the WEF servers are domain controllers.

For test I tried the following:

Add the domain administrators group

Add the CONTOSO\wef-nlb-account account to the domain controllers policy in "Generate security audits" and "Log on as service."

I'm unsuccessfully receiving error 1297 when trying to start the service.

vmconnect_PMxbLbylOS

Please help me understand what I can do to get WinRM working using a load balancer.

This is likely the final step toward using WEF with a load balancer. So, the immediate question is how to run the WinRM service as a different user.

Thank you.

Windows for business | Windows Server | User experience | PowerShell
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. VPHAN 25,000 Reputation points Independent Advisor
    2026-02-08T21:18:32.3066667+00:00

    Hi Denis Pasternak,

    You are encountering Error 1297 because the Windows Remote Management (WS-Management) service is a privileged subsystem that requires the SeTcbPrivilege ("Act as part of the operating system") to function. Standard domain accounts, and even Domain Admin accounts, do not hold this privilege by default in a service context, and simply granting "Log on as a service" is insufficient.

    However, attempting to run the native WinRM service as a specific domain user is technically unsupported and highly discouraged, especially on Domain Controllers. Doing so breaks the integration with HTTP.SYS, disrupts the default SDDLs (Security Descriptor Definition Languages), and opens a significant security hole by requiring you to grant a service account TCB (Trusted Computing Base) rights.

    The correct architectural solution to load-balance WEF without breaking Kerberos or modifying the WinRM service identity is to switch the transport to HTTPS.

    Here is the precise technical path to resolve this:

    1. First, you must undo the changes that caused Error 1297.

    Open services.msc.

    Locate Windows Remote Management (WS-Management).

    Reset the "Log On" account back to Network Service.

    Restart the service to ensure it is healthy.

    1. You were trying to register the SPN HTTP/nlb-01 to a user account (CONTOSO\wef-nlb-account) so that both nodes could decrypt the Kerberos ticket. While this logic applies to SQL Server or IIS Application Pools, it does not apply to WinRM.
    • WinRM runs as Network Service (the computer account).
    • If you map the SPN to a user, the computer account cannot decrypt the service ticket presented by the client.
    • You cannot change WinRM to run as that user because WinRM requires SeTcbPrivilege, SeAuditPrivilege, SeAssignPrimaryTokenPrivilege, and SeImpersonatePrivilege. Granting these to a domain user on a Domain Controller is a severe security risk. 3.

    To use WEF behind an NLB, you must use HTTPS. This encapsulates the authentication traffic within a TLS tunnel, bypassing the requirement for a shared Kerberos SPN on the "Cluster Name."

    Perform the following on both WEF collector nodes:

    Issue a Web Server Certificate:

    Request a certificate from your internal CA.

    Common Name (CN): The FQDN of the specific node (e.g., node1.contoso.local).

    Subject Alternative Name (SAN): Must include the node FQDN and the Cluster FQDN (e.g., nlb-01.contoso.local).

    Create the WinRM HTTPS Listener: Run this command in an elevated PowerShell prompt on each node to bind the certificate to port 5986:

    # Replace with your actual Certificate Thumbprint
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbprint "YOUR_CERT_THUMBPRINT_HERE" -Force
    1. Update the Firewall: Ensure port 5986 (TCP) is allowed inbound on the WEF servers and through the load balancer.
    2. Update the Subscription Manager GPO: Change the stricture in your Group Policy for the forwarders (clients) to use the HTTPS path:
      • Old: Server=http://nlb-01.contoso.local:5985/wsman/SubscriptionManager/WEC...
      • New: Server=https://nlb-01.contoso.local:5986/wsman/SubscriptionManager/WEC...

    By using HTTPS, the client validates the server identity via the Certificate (which contains the cluster name), and the authentication (Kerberos/NTLM) occurs securely inside the tunnel without requiring a shared user SPN.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    VP

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.