Windows – Error 4673 audit failure filling security logs

authenticationSecuritywindows

I have an isolated desktop computer in my office that I run weekly security audits on. I check the logs for odd behavior then export and clear them out.

The logs are filled with "Audit failure Microsoft Windows Security Auditing Event ID 4673"

A privileged service was called

Subject:

 Security ID:          System

 Account Name:         Standalone_System_2$

 Account Domain:       WORKGROUP

 Logon ID:             0x307

Service:

 Server:               Security Account Manager

 Service Name:         Security Account Manager

Process:

 Process ID:           0x208

 Process Name:         C:\Windows\System32\lsass.ese

Service Request Information:

 Privileges:           SeTcbPrivilege

I found this Technet post which advised that I turn off "Audit Privilege Use"… Not the route I need to take.

Some have suggested that it could be the antivirus causing these log entries… I'm not sure how to identify the offending account or service. I checked services on the system and I see a service named "Security Accounts Manager", however this service is not named "Security Account Manager".

Not sure where to go but I want to get this audit log under control! All these useless entries make it nearly impossible to find actual events.

Best Answer

The last entry on this thread talks about using a specific tool to determine the user in question for this error (Login ID is unique since boot, but after a reboot changes so you need to see what account is connected to this request) and validate whether they should have permissions to do what they are attmepting: http://answers.microsoft.com/en-us/windows/forum/windows_xp-security/577-many-failures-pertaining-to-setcbprivilege-in/3944f31c-dda4-46d9-adbf-74a9953dedeb

Reproduced here because the forum is a bit hard to read:

I noticed that I was getting a BUNCH of these from LSASS. (like about 17k in ~ 2 hours... couldn't figure out why the event logger was requiring so much I/O... (it was logging alot of fails)...SeTCBPriv fails.

I used 'process hacker2', (a sup'ed up version of process explorer, now that procexp is controlled by MS, (sorta like letting the foxes own your tools for watching fox in your hen-house!)..

Then I could look at what account lsass(samss) was using to run under.(either in services or in process hacker2 -- on sourceforge.net, BTW).

Then using the Local security policy panel in the admin tools, and looking under the "User Rights Assignment", I could make sure all of the required privileges needed to run, (as stated on the service ACL were permitted (if they aren't, it won't run, so that's usually not an issue), BUT, ALSO make sure the account LSASS was running under had the "Act as part of the operating system' (trusted computing base/tcb) privilege.

Same goes for any other Service -- that is generating lots of audit fails... verify it has the privileges it needs on its ACL (something incredibly cryptic to do w/o a GUI...). If you aren't sure.... research it on the net and see if it should have that priv..if it is signed and certified by MS, then likely your system is misconfigured (at least from that service's perspective ;-)) Then you just need to give it the privs it needs -- ALSO a neat thing in PH2, you can just click an option as to whether or not the service runs with a bunch of other services or not. So far, have been been able to split out interactive stuff (audio/video/desktop) from background services so I could effectively prioritize them -- before this recent discovery, no way of turning down priority on some lower prior services w/o affecting audio and/or desktop...

Anyway, after making sure LSASS had the tcb privs.. the messages went away...

Related Topic