Share via

Delegating Access to the Security Log

  • Article

I often get the question, how do I allow a group of auditors read access to my security logs without making them admins and without letting them clear the logs?

To answer this, first you need to know, for what version of Windows? Prior to Windows Server 2003, there was only one access control mechanism for security event log management: SeSecurityPrivilege (aka "Manage Auditing and Security Logs"). This privilege conveys the following rights:

  • Read the security log
  • Clear the security log
  • View SACLs
  • Set SACLs
  • View audit policy
  • Set audit policy

Obviously this is much more access than many organizations want to grant, but there it is. Additionally to properly translate events in the event log, you need access to the registry (HKLM\System\CurrentControlSet\Services\EventLog\Security) of the machine where the log resides. This may mean remote registry access. Without registry access, the event message files on the viewing machine will be used, and sometimes events are mis-translated- it's common to see data in the wrong fields, etc., if you're viewing the log from a different version of Windows than where the log was generated.

In Windows Server 2003 a log delegation mechanism was introduced that can solve most of the problems. You'll still need registry access for the reasons above, but this makes it possible to give read access and nothing else, for example. See this KB article for more information.

Comments