We help IT Professionals succeed at work.

Windows Network logon (Type 3) failure internal to workstation by disabled "Guest" account.

Fred Marshall
I'm still chasing 4625 failed logons (Type 3) as in:
and, more recently, as in:

We are seeing Event 4625 failed logon type 3 reports:
Reported Username is Guest on a computer where the Guest account is inactivated.
Event reports: "Remote Device" is the workstation computername itself - not another one.
Event reports: "Domain" is the same workstation computername - not another one and not the domain that the workstation is joined.

So, yes, attempts to logon with Guest should fail because Guest is inactivated.
But why would a workstation be having logon attempts unto itself when I think if Guest as being a Network logon attempt.
And, yes, these are "network logons" (Type 3, right?).
So why are they coming from within the workstation?

In this case, it happened on Friday starting around time for people to come to work at 8:30  and it persisted until 11:50.  There were over 400 events, some of which occurred within the same second - spaced variably with gaps up to an hour.

This is happening on a few workstations, although not to this degree.
In this case, it's not an "old credential".and yet the results are very similar to the earlier question's situation.

I still haven't found the smoking gun.  It occurs to me that a "network" logon attempt by what is identified as Guest may be coming from a loopback or .... ?  That is, it *appears* to be coming from the network and the attempt isn't being identified but, rather, translated to Guest.  But I'm way out of my depth in taking this idea any further.
Watch Question

We had a lot of these recently for certain machines and was related we believe to having in shared folders "Everyone" in the NTFS permissions rather than "Users", "Authenticated Users" or ther groups.   They seemed to go away after removing that though also turned off file & print sharing later on anyway so may or not have been full solution.  Worth a look though if there have been some local shares on there?

@65td - yes that covers the issue we found, was ages back I needed to did it but seemed to solve to problem on this recent machine too.  Not sure if that also causes same issue with, say, a shared printer to Everyone etc?


That's very interesting.  These computers were in a Workgroup that has been converted to a Domain.
So, having Everyone in shares was common in the past.
Are we talking here about Share permissions or Security permissions or both?

Just NTFS permissions in our case, we have got shares with "Everyone" in elsewhere without the issue.



Curious, did you find that there too and did it help?  We still have some other similar ones that are proving hard to track down - they don't matter too much when almost certainly coming from something that doesn't matter but then end up masking real attempts at login brute force etc.