Cause and elimination of failed self-generated WIndows logons

Which hex code do you get?

Status Codes      Description
0xC0000064      The username is misspelled or does not exist.
0xC000006A   The user's password is wrong.
0xC000006D   The username or authentication information is incorrect.
0xC0000234      The user is currently locked out.
0xC0000072      The user account is currently disabled.
0xC000006F      The user tried to log on outside authorized hours.
0xC0000070      The user tried to log on from an unauthorized workstation.
0xC0000193      The user's account has expired.
0xC0000071      The user's password has expired.
0xC0000133      The domain controller and computer's times are out of sync.
0xC0000224      The user is required to change their password at the next logon.
0xc000015b      The user has not been granted the requested logon type on that machine.

Which logon type do you get? If you get 5, you should be fine.

Logon Type      Description

• 2                      Interactive logon - Occurs when a user logs on using a computer's local keyboard and screen.
• 3                      Network logon - Occurs when a user accesses remote file shares or printers. Also, most logons to Internet Information Services (IIS) are classified as network logons (except for IIS logons which are logged as logon type 8).
• 4                      Batch logon - Occurs during scheduled tasks, i.e. when the Windows Scheduler service starts a scheduled task.
• 5                      Service logon - Occurs when services and service accounts log on to start a service.
• 7                      Unlock logon - Occurs when a user unlocks their Windows machine.
• 8                      NetworkClearText logon - Occurs when a user logs on over a network and the password is sent in clear text. Most often indicates a logon to IIS using "basic authentication."
• 9                      NewCredentials logon - Occurs when a user runs an application using the RunAs command and specifies the /netonly switch.
• 10                      RemoteInteractive logon - Occurs when a user logs on to their computer using RDP-based applications like Terminal Services, Remote Desktop, or Remote Assistance.
• 11                      CachedInteractive logon - Occurs when a user logs on to their computer using network credentials that were stored locally on the computer (i.e. the domain controller was not contacted to verify the credentials).

from the timing it is probably their mobile device with an obsolete password.

There are no mobile devices involved.
This is happening on a large fraction of 60 computers.
Per the report, these are all Type 3.

I can't find an action in the Task Scheduler at 12:00 noon.  Yet, these almost all happen just after that by a minute or 2 or 3.

Here is Event Log information:

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:            BREAKROOM$
      Account Domain:            NET

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:      BREAKROOM
      Source Network Address:      fe80::d0ef:e87c:cd0e:5d36
      Source Port:            60031
      Caller Process ID:      0x0
      Caller Process Name:      -

Network Information:
      Workstation Name:      BREAKROOM
      Source Network Address:      fe80...
      Source Port:            60031

Detailed Authentication Information:
      Logon Process:            
      Authentication Package:      NTLM
      Transited Services:      -
      Package Name (NTLM only):      -
      Key Length:            0

And, here is some more:

- System

  - Provider

   [ Name]  Microsoft-Windows-Security-Auditing
   [ Guid]  {54849625-5478-4994-a5ba-3e3b0328c30d}
 
   EventID 4625
 
   Version 0
 
   Level 0
 
   Task 12544
 
   Opcode 0
 
   Keywords 0x8010000000000000
 
  - TimeCreated

   [ SystemTime]  2020-03-03T20:03:03.999599400Z
 
   EventRecordID 17873606
 
  - Correlation

   [ ActivityID]  {926ac30b-eccf-0000-63c3-6a92cfecd501}
 
  - Execution

   [ ProcessID]  696
   [ ThreadID]  8396
 
   Channel Security
 
   Computer breakroom.[domain]
   Security
 

- EventData

  SubjectUserSid S-1-0-0
  SubjectUserName -
  SubjectDomainName -
  SubjectLogonId 0x0
  TargetUserSid S-1-0-0
  TargetUserName BREAKROOM$
  TargetDomainName NET
  Status 0xc000006d
  FailureReason %%2304
  SubStatus 0x0
  LogonType 3
  LogonProcessName  
  AuthenticationPackageName NTLM
  WorkstationName BREAKROOM
  TransmittedServices -
  LmPackageName -
  KeyLength 0
  ProcessId 0x0
  ProcessName -
  IpAddress fe80::d0ef:e87c:cd0e:5d36
  IpPort 60030

Type 3 + 0XC000006D
This means that a user or computer tries to log in from the network, however, he/it cannot due to a bad username or authentication information.

I can see IpAddress fe80::d0ef:e87c:cd0e:5d36. Can you find the source?

You mentioned 60 computers. Can you confirm that all of them get failed logon events after 12AM?

Also, see the solution in this discussion. Isn't this the case?
https://community.spiceworks.com/topic/1969968-audit-failure-4625-null-sid-0xc000006d-0xc0000064

Hello There:   Thank you!
 
I think I was careful to say "many" and not "all".  Anyway, that's the case.

The source fe80::d0ef:e87c:cd0e:5d36 is the same computer on which the error was logged.  The original report reflects that in referring to it as the "Remote Device".

I read the spiceworks thread and ended up with as many questions as answers:
- what will we break if we take this advice?  The implication is that nothing would be broken but that's always the question.
- what is the implication of the advice re: implementation?  Is this a DC setting or a Domain Computer setting requiring a broadcast method?

Thanks Scott!!

ok so your BREAKROOM computer around noon daily you get a failed network logon to some resource. Try rejoining this computer to the domain.  Set to workgroup and without rebooting rejoin domain and now reboot.. 

David Johnson:  OK I'm doing that now and we shall see later today perhaps.
In the mean time, what am I trying to accomplish from a technical point of view?
As above, this is one of 40 or so computers with the issue each day.

David Johnson:  OK.  Well BREAKROOM didn't have failed logins yesterday.  They would normally happen after I'd followed the unjoin/join process.  So, it's possible that this had an effect.  But, these don't always happen so another day or two of experience is likely to be telling.

Let's move ahead and say that this process worked.  There are so many computers affected that I'd like to have a more efficient process.  Any ideas?
I'm still not sure what we changed in doing this.

Running this Powershell command could work:

Test-ComputerSecureChannel -Repair

Select allOpen in new window

From the infomration provided I thought it was only 1 computer and only happening daily around a specific time.  
It appears that you've had a breakdown in communication between various computers and the domain controller and have been using cached logins for a period of time.

It happens sometimes.. perhaps you should run the scripts from https://4sysops.com/archives/repair-the-domain-trust-relationship-with-test-computersecurechannel/ and test your network.

David Johnson:  OK.  Sorry you missed that...  I'll check out the link!

So, I ran this:
PS>Test-ComputerSecureChannel
on one of the offending computers and the result comes back
True

So, does that suggest this is OK and not the problem?

True means it can connect securely

Yes.  This is all about communication with the DC, right?  But the failed logons are from itself.  So I'm not sure this is the issue.  Might it be likely nonetheless?

The Powershell command with the /Repair switch removes and then rebuilds the channel established by the NetLogon service between the computer and a domain controller. Since removing the computer from the domain and joining it back maybe worked for you (you will see), this command could be the solution for other computers.

Please help me understand the connection between the failures I'm seeing and this fix.
The computer is trying to log into itself - that's what fails as reported.
Does that require an interaction with the DC?

where are you viewing the security logs? On the DC? or on the Workstation?

The logs are taken from the individual workstations and collected in our SIEM database and reported as failed Windows logons of all types.
These appear to be self-generated by computername$ of Type 3.

Nothing has changed.  The BREAKROOM$ logon persists after the attempted fix.
This remains the one outstanding set of items in the failed logons report that we generate and tends to obscure things that may be more important.
So, I would like to eliminate these items for real.

It certainly appears that GFI Languard settings are somehow involved in causing these failed logons.
We haven't figured out why just yet.
But, they happen very shortly after GFI Languard is supposed to collect data.  Proven by changing the time of the FGI Languard collection does change the logon failures on the affected workstations directly.

Update:  The correlation with GFI Languard now seems less connected overall.  We're still getting a number of these each day - generally 1 or 2 per computer (but sometimes many more on any one computer in a day).  
To boil it down:
We get, for each computer named COMPUTERNAME (an alias here), a report section called:
Unsuccessful User Logons for COMPUTERNAME
The "Username" is COMPUTERNAME$  (so that's the account name for the same computer logging the failed logons.
The "Remote Device" is COMPUTERNAME (so that's the same computer logging the failed logons).
The "Domain" is the appropriate domain name.
The Event ID is 4625 - failed logon.
The type is NETWORK (type 3).

The only thing that I can think of is that there are services whose properties are set up to Log On as:
Local System Account (and, generally "Allow service to interact with desktop" is NOT selected).
Well, COMPUTERNAME$ *is* the Local System Account, right?
If I assume all this is a useful path of investigation then I'm tempted to ask:
"Why does a service logging on with the Local Sysem Account generate a failed logon?"

To be honest I am not sure how to continue in troubleshooting this.

You said that this happens on approx. 60 computers. I would ask why them and not others? What do they have in common? A software installed that tries to report/communicate? Maybe the same settings specific for these computers?
Maybe antivirus?

Hello There:  Thanks for considering this further!
There are 60 computers in total.
30-40 of them have this issue.
I don't know of anything that's different between them - certainly not antivirus.
But it's good forensics to try to differentiate those that show this and those that don't.  I've not tried very hard at that angle.

As I look at this, I'm looking at Services that may log on with LocalAccount - which includes COMPUTERNAME$.  I'm looking at one right now and find there are *so many* that do.  So that seems an unlikely approach.  But I still think that Services is a likely place to look - particularly in view of the earlier correlation with GFI Languard.
The big question here is:
"Why would the all-powerful LocalAccount ever fail to log on?"  That could be a clue.  And I'm without a clue.  :-)

Today I worked with GFI Languard tech support and made some changes to logon credentials for certain services on the "server".  We'll see if this doesn't have an effect on the outcomes.  We won't know until we see tomorrow's log of failed logons.