Continuous Logon Failure (0xC000006D) for machine account

Question

Hi All,
Greetings!

We've been noticing continuous login failures from a machine account (file server). Both the source and destination (IP & Host) are itself. We've tried clearing the cache, re-establishing the trust using "nltest /sc_reset", rejoined the device to domain and updated all the patches. But still having the same issue. And no issues for any other users during login or accessing files.

As of my understanding, this logon failure is due to one service, which I can't find any trace of it in the logs (event viewer). Because I can see login success for the same account every day.
Frequency: Continuously during the office hours.

Below are the details,

Log source: Microsoft-Windows-Security-Auditing

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:		file-server$

Account Domain:		contoso

Failure Information:

Failure Reason:		An Error occured during Logon.

Status:			0xC000006D

Sub Status:		0x0

Process Information:

Caller Process ID:	0x0

Caller Process Name:	-

Network Information:

Workstation Name:	file-server

Source Network Address:	10.0.0.5  
Source Port:		63808

Detailed Authentication Information:

Logon Process:		

Authentication Package:	NTLM

Transited Services:	-

Package Name (NTLM only):	-

Key Length:		0  

Log source : Microsoft-Windows-SMBServer/Security
SMB Session Authentication Failure

Client Name: \10.0.0.5

Client Address: 10.0.0.5:63808

User Name:

Session ID: 0x7C156400058D

Status: The attempted logon is invalid. This is either due to a bad username or authentication information. (0xC000006D)

SPN: session setup failed before the SPN could be queried

SPN Validation Policy: SPN optional / no validation

I've referred many forums with this error code and scenario, but unable to solve this. Hoping for a solution here.

Answer 1

Hi,

The issue resolved.

Due to a error, "SearchIndexer" service tried to save the index in the mentioned share location. But it was blocked by default due to this patch ,https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/accessing-server-locally-with-fqdn-cname-alias-denied

Since, the mentioned changes to the registry is not recommended and disabling search indexer won't cause much hindrance, I stopped the WSearch service and hence resolved.

Note: Use ProcMon, it will help you to check who/what accessed the resource.
Thanks.

Answer 2

hi,

dig deeper into the SMB logs or enable detailed Kerberos logging to catch the root cause

rgds

alex