Security Log

The Security log is unlike the Application and System event logs in two important respects. First, in the default configuration it is protected by a strong access control list (ACL) and privilege checks, which limits the set of individuals who can read its contents to local system, administrators, and holders of the Security privilege. Second, and most important, only one entity is allowed to write to the Security log—the Local Security Authority (LSA). This effectively means that every time you attempt to call the RegisterEventSource API for the Security log, you will get an ACCESS_DENIED error, even if you're running as Local System!

On the other hand, any interactively logged on user can read both Application and System logs and write to the Application log.

The Security log write access limitation was relaxed somewhat in Windows Server 2003 without changing the fundamental design by the introduction of a special set of APIs. These APIs use Local Procedure Calls (LPCs) internally to interact with LSA, instructing it to generate audit logs on the application's behalf.

Do not be surprised if you don't see anything in the Security log after successfully invoking the auditing API. The messages will only appear in the Security log if you turn on the Audit Object Access setting.

The caller of AuthzRegisterSecurityEventSource must possess the Audit privilege. Generally, the Audit privilege is held not by individual users (including administrators), but by accounts used for hosting services on the system. By default, this privilege is given only to local service and network service accounts; it can also be assigned by administrators to other service accounts that are used to run the trusted components of the system.

This entire process requires the administrator to set up the security event source in the first place. Assuming that auditing will be performed by a particular application, the security event source would be installed by the administrator at the application's install time, and removed when the application is removed from the system. Although this installation can be performed by direct manipulation of certain registry keys, the recommended approach is to use the predefined APIs AuthzInstallSecurityEventSource and AuthzUninstallSecurityEventSource. Naturally, only administrators are allowed to call these APIs, but the caller does not require the Audit privilege in this case.

In order to obtain the Security event log handle, the caller of the AuthzRegisterSecurityEventSource API must be a process with the executable file path registered for a given event source name at install time.

Adopted from Stay Alert: Use Managed Code to Generate a Secure Audit Trail by Mark Pustilnik.