New SharePoint Subscription Edition Farm got errors WEB01’s machine account was refused at SP_CONFIG Event 3351 and SQL Exception 15404

Question

New SharePoint Subscription Edition Farm got errors WEB01’s machine account was refused at SP_CONFIG Event 3351 and SQL Exception 15404

adil 1,431

Hi

In newly SPSE Farm i got attached error messag how to resolve this?

Environment

New, freshly built PRODUCTION farm. It is not internet-facing, and it has strict Active Directory Group Policies and security hardening.
SharePoint Subscription Edition, version June 2026 Patches installed
OS: Windows Server 2022 AUG 2026 patch level
SQL Server: 2022 Standard,
Servers: 4 total
- WEB01 and WEB02: Front-end with Distributed Cache role
- APP01 and APP02: Application servers, Custom role
Account model: Setup account [name], Farm account [name], SQL service account [name], managed accounts [yes]
Domain: [multi-domain], DC OS version WIndows Serve 2022
Network: firewall between SQL and DCs and Between Application servers and web servers

Error Messages:

SharePoint Foundation Event 3351

SQL database login for 'SP_CONFIG' failed.

Login failed for user 'DOMAIN\WEB01$'

SharePoint Foundation Event 5586

SQL Exception 15404

Could not obtain information about Windows NT group/user 'DOMAIN\FarmAcc'

Error code 0x5 (Access Denied)

error 5586 DB.png

Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-18T21:16:49.0166667+00:00

Here is a partial analysis: (I know SQL Server, but I know nothing about Sharepoint.)

The attempt to login as DOMAIN\WEB01$ seems to be from something running on a local account on WEB01. That is an account like LocalService or NT Service\Something. You should not grant access to DOMAIN\WEB01$, but that service should run under a domain account or a gMSA.

The error "Could not obtain information about Windows NT group/user" with access denied, suggest that the service account lacks sufficient permission in the AD.

2 answers

Your answer

Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-18T21:16:49.0166667+00:00

Here is a partial analysis: (I know SQL Server, but I know nothing about Sharepoint.)

The attempt to login as DOMAIN\WEB01$ seems to be from something running on a local account on WEB01. That is an account like LocalService or NT Service\Something. You should not grant access to DOMAIN\WEB01$, but that service should run under a domain account or a gMSA.

The error "Could not obtain information about Windows NT group/user" with access denied, suggest that the service account lacks sufficient permission in the AD.

Answer 1

Hi adil,

The errors point to SQL Server being unable to resolve or authenticate AD accounts, not to a SharePoint fault:

Event 5586 / SQL 15404: could not obtain information about 'DOMAIN\FarmAcc', error 0x5 (access denied)
Event 3351: login failed for 'DOMAIN\WEB01$' (machine account) on SP_CONFIG

Please run the following and verify on the SQL Server (use the farm account's domain for <domain>):

DC discovery and secure channel (elevated prompt): nltest /dsgetdc:<domain> nltest /sc_verify:<domain> The second should end with NERR_Success.
DNS: nslookup <domain> nslookup <dc_fqdn>
Reproduce the lookup in SSMS: EXEC xp_logininfo 'DOMAIN\FarmAcc'; If this returns 0x5, the issue is SQL-to-AD, independent of SharePoint.
Ports to the DC (TCP only; UDP 53/88/389 are not covered by this test): 53,88,135,389,445,3268 | ForEach-Object { Test-NetConnection <DCName> -Port $_ } Also confirm the RPC dynamic range (49152-65535) is open between SQL and the DCs.
SQL service identity (needs VIEW SERVER SECURITY STATE on SQL 2022): SELECT servicename, service_account FROM sys.dm_server_services;

On WEB01 (and WEB02), check for SharePoint services running as the machine account:

Get-CimInstance Win32_Service | Where-Object { $_.Name -match '^(SPTimerV4|SPAdminV4|SPTraceV4|SPWriterV4|AppFabricCachingService)$' } | Select-Object Name, StartName

Any service showing LocalSystem or NetworkService should be moved to a domain account.

If the farm account is in a different domain from SQL, please also confirm the trust direction and any selective authentication. Please also review the GPOs applied to the SQL Server for restrictions on remote SAM calls or NTLM.

For the failures, check the SQL ERRORLOG (login failure state), the Security log on SQL and the DC, and the SharePoint ULS logs around the event timestamps.

For reference:

MSSQLSERVER_15404 - SQL Server | Microsoft Learn

Nltest - SQL Sever

However, if the issue persists, please create a ticket online or contact our support by signing in to Engage Center.

This route ensures that a Microsoft support engineer can initiate a remote session to investigate backend configurations, run advanced diagnostic tools, and, if necessary, you can request to escalate the case to specialized teams with access to internal systems and logs. These backend resources are essential for resolving issues that go beyond what’s visible in the user interface.

As community moderators, we’re here to guide you, but due to privacy and security limitations, we don’t have access to the backend tools required for a full resolution. For this reason, contacting Microsoft Support via the Engage Center is the most secure and efficient way forward.

I hope this helps you resolve the issue quickly. I’m glad to assist and truly hope the information provided has been useful. Please feel free to reach out anytime if you need further assistance.

Thank you for your kindness and contributions to the forum.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

If Microsoft Monitoring Service is installed on WEB01, temporarily stop it and check whether only the WEB01$ Event 3351 stops; a matching SharePoint Subscription Edition case isolated the machine-account login attempts to that service.^1^

Do not grant DOMAIN\WEB01$ access to SP_CONFIG merely to suppress the event. Treat the two identities separately:

DOMAIN\WEB01$: a process on WEB01 is connecting under the computer identity.
DOMAIN\FarmAcc: SQL Server is failing to obtain directory information for the farm account. SQL error 15404 identifies an invalid/unresolvable principal or a failed impersonation/trust lookup; code 0x5 alone does not establish which policy or network control denied it.^2^

1. Isolate the WEB01$ connection

Requires local administrator rights on WEB01.

Open Services and look for Microsoft Monitoring Service.
If present, record its current startup state, then stop it during a controlled test.
Wait through the normal event interval or reproduce the operation.
Check whether new Event 3351 entries for DOMAIN\WEB01$ stop.
Start the service again after testing.

If the event stops, inspect and reconfigure or remove the monitoring workflow that probes SP_CONFIG; stopping monitoring permanently is not the preferred remediation. If it continues—or the service is absent—correlate the timestamp with WEB01 services, scheduled tasks, monitoring agents, and ULS entries rather than adding a SQL login for the computer.

A SharePoint farm administrator can filter the ULS log as follows:^3^

Get-SPLogEvent |
  Where-Object {
    $_.Area -eq "SharePoint Foundation" -and
    ($_.Message -match "WEB01\$|SP_CONFIG|3351|5586|15404")
  } |
  Select-Object Timestamp, Process, Area, Category, Level, Message |
  Format-List

2. Resolve FarmAcc error 15404 independently

Requires local administrator rights on SQL Server and assistance from the AD/firewall administrators.

In SQL Server Configuration Manager → SQL Server Services, record the Log On As identity for the Database Engine.
Confirm that DOMAIN\FarmAcc exists, is spelled correctly, and remains an enabled domain-user account. The SharePoint farm account must be a domain user; SharePoint services do not support MSA or gMSA identities.^4^
On the SQL server, test discovery and name resolution for the domain containing FarmAcc:

nltest /dsgetdc:<FarmAccDomain> /force /kdc
nslookup <FarmAccDomain>
w32tm /query /status
Test-NetConnection <DC-FQDN> -Port 53
Test-NetConnection <DC-FQDN> -Port 88
Test-NetConnection <DC-FQDN> -Port 389
Test-NetConnection <DC-FQDN> -Port 135
Test-NetConnection <DC-FQDN> -Port 445

Fixed-port tests do not validate dynamic RPC. Windows Server 2008 and later uses TCP dynamic ports 49152–65535 for RPC services including LSA, SAM, and Netlogon; validate those with firewall logs or a network trace.^5^

Conditional SQL resolutions

Apply the matching branch only after establishing the condition:

SQL uses a domain account that is locked: unlock it and verify its domain connectivity.
The SQL service identity lacks a full trust relationship with FarmAcc’s domain: use a SQL service account from the same domain as FarmAcc, or repair the required inter-domain trust.
SQL runs as Local System or Network Service: ensure the SQL server’s machine account is trusted by the domain containing FarmAcc.

These are the documented resolutions for error 15404.^2^ Change the Database Engine account only through SQL Server Configuration Manager, not services.msc; schedule a maintenance window because restarting the service makes the instance’s databases temporarily unavailable.^6^

If hardening blocks the directory lookup

Generate effective Group Policy reports on the SQL server and relevant DC. Check Network access: Restrict clients allowed to make remote calls to SAM on the system enforcing the denied call—especially the DC handling the lookup.

Do not disable this policy or delete RestrictRemoteSam based only on error 15404. First identify the denied caller through DC security logs, SQL logs, or a network trace. If that policy is confirmed as the source, modify the authoritative DC GPO with the AD security team, granting only the approved identity or group required for remote access. Microsoft documents that restrictive Remote SAM policy on DCs can cause access-denied failures and recommends applying a consistent DC policy.^7^

References