Discussion Locked

Security Log Failure Audits

0 helpful
6 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Recieving multiple instances per day of these failure audits in the security logs on every computer on my domain.

EVENT ID 578 FAILURE
Catagory: Privelege Use

Privileged object operation:
Object Server: Security
Object Handle: 4294967295
Process ID: 168
Primary User Name: *USERNAME*$
Primary Domain: *DOMAIN*
Primary Logon ID: (0x0,0x3E7)
Client User Name: *USERNAME*
Client Domain: *DOMAIN*
Client Logon ID: (0x0,0x427FE10)
Privileges: SeIncreaseBasePriorityPrivilege

EVENT ID 578 FAILURE
Catagory: Privelege Use

Privileged Service Called:
Server: Security
Service: -
Primary User Name: *USERNAME*
Primary Domain: *DOMAIN*
Primary Logon ID: (0x0,0x194414)
Client User Name: - Client Domain: -
Client Logon ID: -
Privileges: SeIncreaseBasePriorityPrivilege

are they safe to ignore or turn off failure logging?

Also getting alot of

EVENT ID 643 SUCCESS
Catagory: Account Management

Domain Policy Changed:Password Policy modified
Domain: *COMPUTERNAME*
Domain ID: *COMPUTERNAME*\
Caller User Name: *COMPUTERNAME*$
Caller Domain: *DOMAIN*
Caller Logon ID: (0x0,0x3E7)
Privileges: -

Any explanations would be appreciated

6 replies

by joseph moore

Event id 577:

When you are using a Remote Procedure Call-based (RPC-based) client/server program, the following entry may be logged in the Security event log:

Event ID: 577 Source: Security Type: Failure Audit Category: Privilege Use
User: User Computer: Computer
Text:
Privileged Service Called:
Server: NT Local Security Authority / Authentication Service
Service: LsaRegisterLogonProcess()
Primary User Name: SYSTEM
Primary Domain: NT AUTHORITY
Primary Logon ID: (0x0,0x3E7)
Client User Name: User
Client Domain: Domain
Client Logon ID: (0x0,0x1234)
Privileges: SeTcbPrivilege

CAUSE
The security audit occurs while the RPC subsystem acquires the user's credentials for authenticated RPC. There are two waysfor 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.

Note that thisaudit does not indicate a security breach; you can safely ignore it.

by joseph moore

Event ID 578

SYMPTOMS
Event 578 may be logged in the Security event log when auditing is enabled for tracking Privilege Use problems. This event is logged twice during logoff and Windows 2000 shutdown.

CAUSE
During logoff and shutdown, Csrss.exe tries to increase its priority. After it has notified all of the running processes of the shutdown, it tries to decrease its priority. Since it is running in the System context, this does not succeed and generates the audit event.

RESOLUTION
You can ignore these events because they are logged in error.

by joseph moore

Now, the EventID 643 is interesting. From eventid.net, they say that "This event indicates a succesful change to the Windows 2000 AD security policies."
So, I would check the computer that the error is recording this came from (the computer name that was replaced by %computername% you posted in the error message).

hope this helps

by joseph moore

I think as long as you trust your admins (and they aren't "experimenting" with rights that they shouldn't be messing with" then it is ok.
You can always Audit the changes to security rights, and then check the Security log on a domain controller (or PDC for NT4) to see a little more data.

by able-admin

I checked and the 643 event is logged daily by the computers used by users with domain admin privileges (although they do no more than a standard user). the event is logged under the usere "system".

would you say that it's safe to ignore this one also?

Thanks a lot for you help!

This discussion is closed to new replies.