Event Logging policy settings in Windows Server 2008 and Vista

Event Logging policy settings in Windows Server 2008 and Vista

  • Comments 13
  • Likes

 Mike here again. Today I’m focusing on policy settings for the Event Logging Service.

For clarity, these settings control the Event Logging service; the service responsible for capturing and writing events throughout Windows. These policy settings do not affect the Event Viewer application.

These are some powerful policy settings that allow you to configure five settings for Application, Security, Setup, and System event logs. These categories and their policy settings are located under Computer Configuration\Policies\Administrative Templates\Windows Components\Event Log Service.

The Log File Path policy setting, when enabled, allows you to provide a specific location where the Event Log service writes its log file. You must provided path and filename when relocating where Windows writes the log file.

Next is the Maximum Log file size policy. When enabled, this policy allows you to specify the maximum size of the event log. It supports sizes between one megabyte and two terabytes and uses one-kilobyte increments.

image

Figure 1 Event Log Service Policy Settings

The next two policy settings are related. The Event Logging service uses the Retain old events and Backup log automatically when full policy settings when the event log reaches the maximum file size (defaults to 20 MB or the value specified in the Maximum Log size policy setting). With the Retain Old Events policy setting enabled, the Event Logging service stops writing new events to the event log when the log file reaches or exceeds the maximum value and you lose all new events. With this policy setting disabled, new events overwrite old events. When you enabling the Backup log automatically when full and the Retain old events policy settings, the Event Log service closes the current event log, renames it, and then creates a new log. The Backup log automatically when full policy setting works only when you enable Retain old events policy setting.

image

Figure 2 Maximum Log Size Policy Setting

The last setting and one that I think is the most beneficial is the Log Access setting. Enabling this setting allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log. You enter the security descriptor using Security Definition Description Language (SDDL), which is document on MSDN(http://msdn.microsoft.com/library/en-us/secauthz/security/security_descriptor_string_format.asp). Also, my esteemed colleague Jim provides a two-part blog series about SDDL (http://blogs.technet.com/askds/archive/2008/04/18/the-security-descriptor-definition-language-of-love-part-1.aspx and http://blogs.technet.com/askds/archive/2008/05/07/the-security-descriptor-definition-language-of-love-part-2.aspx).

Finally, I should mention that these new policy settings have precedence over the older Windows Server 2003 and Windows XP security policy setting that manage Event Logs. Both settings can exist in the same Group Policy object and apply only to the respective operating systems for the policy setting.

image

These new policy settings for the Event Logging service provide more flexibility and control from earlier versions. Using Group Policy to control where event logs are written, how large they can grow, how they are preserved, and who can manage them are key to change control and security auditing. You can implement these policy settings in your existing Group Policy objects and they will not affect operating systems earlier than Windows Vista.

- Mike Stephens

  • Hi

    In the article you are wrote about option LogFilePath:

    "You only provide a path location; Windows maintains the file name."

    I checked this and if name of log file not entered - option does not working. In my lab this is working if option LogFilePath has a value:

    LogFilePath = c:\<folder_name>\<file_name>.evtx

    If value is:

    LogFilePath = c:\<folder_name>\

    it not working.

    Thanks

    P.S. sorry for my english

  • Hi Botler,

    Nice catch! That has been corrected in the blog post. Thanks very much for bringing that to us.

    - Ned

  • Ask the Directory Services Team : MCS Talks Infrastructure Architecture joeware - never stop exploring…

  • 135 Microsoft Team blogs searched, 70 blogs have new articles in the past 7 days. 177 new articles found

  • Hi

    I have a problem with option 'Log Access'.

    What I doing:

    1. With CACLS tool I detect the SDDL string for security log in default location:

    CACLS c:\windows\system32\winevt\logs\security.evtx /S

    result is:

    D:AI(A;ID;FA;;;S-1-5-80-880578595-1860270145-482643319-2788375705-1540778122)(A;ID;FA;;;SY)(A;ID;FA;;;BA)

    2. Open option 'Log Access' in 'Default Domain Controllers Policy' and writing this value.

    3. Restart DC.

    After that I login as administrator and run Event Viewer. I get error when open Security log:

    'Event Viewer cannot open the eventlog or custom view. Verify that Event Log service is running. The security descriptor structure is invalid (1338)'

    and events doesn't displayed.

    Also I try to get a SDDL string for security log with ICACLS tool:

    icacls c:\windows\system32\winevt\logs\security.evtx /save c:\sddl.txt

    result in file:

    D:AI(A;ID;FA;;;S-1-5-80-880578595-1860270145-482643319-2788375705-1540778122)(A;ID;FA;;;SY)(A;ID;FA;;;BA)

    In Event Viewer the same error occured.

    Where is mistake in my workflow?

    Thaks.

    P.S. Sorry for my english.

  • Hi,

    There's a slight misunderstanding here - you are trying to set permissions for the EVTX file itself, when actually you should be setting permissions used by the event log system. The permissions on the EVTX file are not correct for what would be used in the CustomSD value that gets written.

    The following KB gives an example of the correct SDDL syntax you will need to be testing with:

    323076 How to set event log security locally or by using Group Policy in Windows Server 2003

    http://vkbexternal/VKBWebService/ViewContent.aspx?scid=KB;EN-US;323076

    (Ignore the 2003-theme of the aticle and just focus on the section starting with "The following sample SDDL")

    - Ned

  • Hi Ned.

    Thank You for comment - it is very usefull for me. I solved my previous problem, but new questions occured.

    I have a domain user account with name 'adm1' and he is member of the following groups: Domain Admins, Domain Guests, Domain Users, Users, Guests. His SID is 'S-1-5-21-2843397318-35701858-1184183407-1106'.

    1. In group policy 'Default Domain Policy' in option 'Log Access' for Security and Application log I writed the following string:

    O:BAG:SYD:(D;;0xf0007;;;S-1-5-21-2843397318-35701858-1184183407-1106)

    After that i restarted a member server, login as 'adm1' on it and run Event Viewer. When I try to open Application Log I have a correct error:

    'Event Viewer cannot open the eventlog or custom view. Verify that Event Log service is running. Access is denied (5).'

    Security log is opened without errors and events are visible. Why the Security log is visible?

    2. In above scenario I writed a Windows Command Script (.cmd) file:

    eventcreate.exe /L application /id 999 /T error /D "Test"

    When I run this "as administrator" (additional credentials are not answered and command running under 'adm1' user) - event created successfully in Application log. Does it correct?  

    Thanks

    P.S. Sorry for my English.

  • (Whoops - I gave a bad link last time - should have been:

    http://support.microsoft.com/kb/323076)

    I'm not 100% sure about your repro. It's possible that members of Administrators are special-cases to prevent them from being locked out of reading critical log info. Try again with your test user being *only* a domain user and not a member of all those other groups.

  • Good info - thanks.

    When I look at the properties of newly-built Windows 2008 server, the maximum log size dialog shows as 2048KB (2MB) and not 20MB as you indicate above.

    Tony

  • Hi

    Is there a policy GPO for a file ForwardedEvents.evtx? Or have to use the regedit? I want to move it to another disk.

    Thanks

    P.S. sorry for my english

  • You will need to edit the registry (in theory at least; I have no idea if this event log is allowed to be moved). But like all things, you could use Group Policy Preferences to handle this.

  • Hi there,

    Thanks for the interesting article.

    I'm having problems with allowing a domain user to read the security event log on the DC's on a 2008 domain.

    I have set up a user (called readonly) which is a completely standard user, then I've added this user to the Event Log Readers group.

    I have then added the following SDDL string to the Log Access entry under the Security section of the Event Log Service, as you've described above:

    O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x3;;;BO)(A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x3;;;SU)(A;;0x1;;;S-1-5-3)(A;;0x2;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)

    The last part of it uses the SID of the Event Log Readers group (S-1-5-32-573).  I've rebooted but still I'm unable to access the event log from my C# application - I get a permission denied error.  I can access it fine from the Event Viewer running on my machine (Win7) and connecting to the DC.

    My C# code is quite striaght forward I think:

    if (DomainUserName != null && DomainUserName != string.Empty)

    {

       co.Username = DomainUserName;

       co.Password = DomainUserPassword;

       co.Impersonation = ImpersonationLevel.Impersonate;

    }

    ManagementScope scope = new ManagementScope(@"\\" + DomainControllerName + @"\root\cimv2", co);

    scope.Connect();

    Have I missed something?  Any guidance you could provide would be very gratefully received.

    Thanks.

  • Hi,

    You will need to ask someone familiar with C# coding to debug your code. Since you've gotten the steps working with just the event viewer, I know the permissions are correct overall, or it would fail also.