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.
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