Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
|Type: Failure Audit|
Privileged Service Called:
Server: <authentication process>
Service: <service name>
Primary User Name: <computer name>$
Primary Domain: <domain or workgroup name>
Primary Logon ID: <client logon id>
Client User Name: <computer name>$
Client Domain: <domain or workgroup name>
Client Logon ID: <logon id>
Privileges: <privilege string>
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is an authentication protocol?
TD772724 provides details on the audit of sensitive privilege use for Windows 7 and Windows Server 2008.
The "Privileges" part of the event description provides a clue as to what privilege was requested by the specified service (and denied since this is a Failure Audit). If the privilege name is not self explanatory, one can search the Internet for additional information about that particular type of privilege. For example, if this type of audit is enabled, changing the system time may cause this event to be recorded (see TD277459) - the requested privilege would be SeSystemTimePrivilege.
Another common privilege recorded with this event is SeTcbPrivilege. It means that the service requested to "Act as part of the operation system". As one can imagine, this is a very powerful privilege and if used by same malware, it can seriously compromise the security of that system.
I received EventID 577 on a Win2k server in application terminal server mode, after adjusting Domain Policy. After doing some research, it turned out that terminal server users need access to the user right “Create Global Objects”. The problem was fixed by adding a GPO with the necessary rights assigned to the group containing terminal server users.
As per Microsoft: "This problem may occur when all the following conditions are true:
1. A program that is installed on your Windows XP-based computer makes a call to the SetProcessWorkingSetSize function to release the working set.
2. Auditing of the Audit privilege use category is turned on.
3. Your user account does not have the SeIncreaseBasePriorityPrivilege user right, also known as Increase Scheduling Priority”. See ME831905 for a hotfix.
See MSW2KDB for additional information on this event.
We have found that users who had this problem have been infected with spyware. You may want to run Spybot-S&D to check for this possibility.
Thing can also happen if a user tries to load or unload a driver. Most users do not have the permission to do this, so the driver loading will fail its attempt and log this in the security log. I got this to go away by giving the users the "Load and Unload Device Drivers" right in the local security policy.
As per ME238182: "The security audit occurs while the RPC subsystem acquires the user's credentials for authenticated RPC. There are two ways for the code to do this. If the first method does not succeed, the second method is tried. In this case, the first method (calling the local security authority [LSA] directly) does not succeed and generates an Audit Failure entry". See the article for a hotfix.
If this is recorded when users attempt to change their password (and they get "Unable to change the password on this account (C00000BE") then see ME176978.
|Private comment: Subscribers only. See example of private comment|
|Links: ME176978, ME238185, ME831905, Online Analysis of Security Event Log, Spybot-S&D, MSW2KDB, T957132, TD772724, TD277459|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated