Thursday, 10 October 2013

Event 4624 null sid - Repeated security log

I have several of security log entries with the event 4624 followed shortly by an event 4634. Since it seams the entries for anonymous logon, I had started to analyze whether it has legitimate reason or it is filling up as unwanted . After I have googled, I found following things

- Event 4624 null sid is the valid event but not the actual user's logon event.
- The reason for the no network information is it is just local system activity.  Windows talking to itself.
- The "anonymous" logon has been part of Windows domains for a long time--in short, it is the permission that allows other computers to find yours in the Network Neighborhood

Event ID 4624 null sid

An account was successfully logged on.

 Security ID:  NULL SID
 Account Name:  -
 Account Domain:  -
 Logon ID:  0x0

Logon Type:   3

New Logon:
 Security ID:  SYSTEM
 Account Name:  MyPC$
 Account Domain:  MyDomain
 Logon ID:  0x42c5ffa3
 Logon GUID:  {a17cec34-483b-2d22-04e7-5bc572fe8ebc}

Process Information:
 Process ID:  0x0
 Process Name:  -

Network Information:
 Workstation Name: 
 Source Network Address: -
 Source Port:  -

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

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
 - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
 - Transited services indicate which intermediate services have participated in this logon request.
 - Package name indicates which sub-protocol was used among the NTLM protocols.
 - Key length indicates the length of the generated session key. This will be 0 if no session key was requested. 

Get rid of event 4624 null sid

     The event 4624 is controlled by the audit policy setting Audit logon events.  In 2008 r2 and later versions and Windows 7 and later versions, this Audit logon events setting is extended into subcategory level.

Category: Audit logon events (Logon/Logoff)
Subcategory: Logon - ( In 2008 r2 or Windows 7 and later versions only)
Subcategory: Logoff - ( In 2008 r2 or Windows 7 and later versions only)

If these audit settings enabled as Success we will get the following event ids

4624: An account was successfully logged on
4634: An account was logged off
4647: User initiated logoff in the case of Interactive and RemoteInteractive (remote desktop) logons

If these audit settings enabled as failure we will get the following event id
4625: An account failed to log on

Possible solution: 1 -using Auditpol.exe

     If you would like to get rid of this event 4624 then you need to run the following commands in an elevated command prompt (Run As Administrator):
Auditpol /set /subcategory:"Logon" /Success:disable
Then update gpo by this command
gpupdate /force
Note: Use this command to disable both logon and logoff activity
Auditpol /set /category:"Logon/Logoff" /Success:disable
Possible solution: 2 -using Local Security Policy

     You can stop 4624 event by disabling the setting Audit Logon in Advanced Audit Policy Configuration of Local Security Policy.

    1. Press the key Windows + R
    2. Type command secpol.msc, click OK
    3. Then go to the node Advanced Audit Policy Configuration->Logon/Logoff.

    4. Check the audit setting Audit Logon If it is configured as Success, you can  revert it Not Configured and Apply the setting.

get rid of event 4624

Possible solution: 2 -using Group Policy Object

     If the setting is inherited from any other GPO to Local Security Policy,You need to edit the specific GPO which is configured with the setting Audit Logon/Logoff. You can find target GPO by running Resultant Set of Policy.
   1. Press the key Windows +
   2. Type command rsop.msc, click OK.

   3. Now you can the below result window. Then go to the node Computer Configuration ->Windows Settings ->Local Polices-> Audit Policy.

   4. Now, you can see the Source GPO of the setting Audit logon events which is the root Setting for the subcategory Audit Logon

get rid of event 4624 null sid

   5. Then you can edit the Audit logon events (Computer Configuration->Windows Settings ->Secuirty Settings->Local Polices-> Audit Policy) as Not defined in Default Domain Policy 
you can disable Audit Logon setting in Advanced Audit Policy Configuration (Computer Configuration ->Windows Settings ->Secuirty Settings-> Advanced Audit Policy Configuration->Audit Logon/Logoff)

    Note: You need run the command GPUpdate /force after every changes to apply group policy to system immediately.

Note : This article is applies to Windows Server 2008,Windows Server 2008 R2, Windows Server 2012, Windows 7 and Windows 8.

Software developer



  1. Hi, I've recently had a monitor repaired on a netbook. I'm very concerned that the repairman may have accessed/copied files. Is there an easy way to check this? I can't see that any files have been accessed in folders themselves. But the battery had depleted from 80% to 53% when I got the computer back - indicating the battery had been used for approximately 90 minutes, probably longer. The event viewer seems to indicate that the computer was logged on whilst the repairman had it, even though he assured me this wouldn't be necessary. Yet your above article seems to contradict some of the Anonymous logon info. I've been concerned about.
    Any help would be greatly appreciated :-)

  2. I think you can track it through file system audit ...check this link to enable file system audit

  3. This comment has been removed by the author.

  4. Hi, many thanks for your kind help. I had been previously looking at the Event Viewer. But it's difficult to follow so many different sections and to know what to look for. It appears that the Windows Firewall/Windows Security Center was opened. And I think I saw an entry re: Group Policy or Group Policy Management during the time that the repairman had the computer. Do you have any idea as to how I might check this area again please?
    Also, is it possible to check if files/folders have been copied/transferred in any way? Having checked the desktop folders I can see no signs of files having been accessed individually.
    Many thanks for your help :-)

  5. I think what I'm trying to check is if the person changed the settings - Group Policy, etc - in order to cover up what was being done? What is confusing to me is why the netbook was on for approx. 90 minutes whilst checking/repairing a monitor/monitor cable? And why he logged onto the computer - apparently under my username - even though he didn't have the Windows password. (Which I now understand is apparently easy to reset).

  6. I have Windows 7 Starter which may not allow the "gpmc.msc" command to work? Am not sure where to type this in other than in "search programs and files" box?

    1. Did you give the repair man a charger for the netbook? Keep in mind he probably had to boot the computer up multiple times and let it run to ensure the problem was fixed.

  7. I have had the same issue with a 2008 RD Gateway server accessing AD running on 2003 DC servers. This was found to be caused by Windows update KB3002657 with the update fix KB3002657-v2 resolving the problem. This relates to Server 2003 netlogon issues.