Windows 2003 Server Event Log Security

Posted by mkeadle


One of the reasons Netwatch progress has stalled is that it lost a lot of it’s tracking abilities when we upgraded our Windows servers to 2003. Suddenly our remote login script reporting stopped working and and I couldn’t immediately figure out why. Our login scripts didn’t change, the workstation configurations didn’t change, and we hadn’t made any specific manual security policy changes that could’ve broken things. The only thing that had changed was the server upgrade. There was a lot of buzz about a new, tighter out-of-the-box security design with Windows 2003 Server, and improved security involving the event logs was something that wouldn’t be suprising. I figured there was literature somewhere on the subject but I also figured it’d be more fun to track down the change on my own.


Testing things was fairly easy. From the beginning it was easy to notice that the login script reporting was working for me (administrator) but not for students (non-administrators). Windows XP comes with a few extra command line utilities to interface with event logs, local and remote, so shadowing a remote workstation I could rattle off a few commands and see immediate results:

Listing 1. Remote event log test as unprivileged user

C:\> eventcreate /s SERVER /t SUCCESS /id 1 /L APPLICATION /D "Test event"
Access Denied

Trying the same technique using WMI and vbscript gave the same results. This confirmed it was unlikely to be a code error and most definately a permissions issue.

The event log itself didn’t show anything about the failure, or anything else for that matter. The first thing I checked was the NTFS permissions on the directory that the logs are actually stored in, but that seemed to be unchanged since the previous version. Declaring filesystem issues non-suspect the next objects of inspection were a couple security policies. Local Security Policy, Default Domain Controller Policy, and others were looked at to no avail. There just didn’t seem to be anything relevant. All this searching was stretched across a period of a couple weeks, fitting it in to loose blocks of time, and I was starting to become less interested in the research and more interesting in a solution. Googling for different combinations of “windows 2003 event log security changes” was leading me to some interesting information but none of it had anything to do with what I was looking for. I even threw a few cuss words in there to spice it up, only to find forum posts from a few disgruntled admins.


I’m not sure how I first came across hints to the fix as I don’t really remember what happened next. It seems like I fell asleep in my chair and woke to find the kernel of knowledge birthed in front of me, but I’m sure it was just the result of massive searching. What I found was a forum post by an admin with a similar issue with a reply only mentioning he needed to edit the SDDL string related to the appropraite logs. A followup from the original author stated he got it working and thanked him for the advice, but neither gave any links or further info on how to change the SDDL string! However, it was just the search term needed to to uncover the answers.

May I present Microsoft Knowledge Base article 323076.

You can make your way through that article yourself, but I’ll go ahead and outline the path I took.


I suspected security might be tightened around event logs, but it was a bit suprising to find out that you had to manually enable the possibility to customize your setup. Apparently, that’s why it was so difficult find the correct option to tweak in the first place. The interface to the option wasn’t even available! So the first thing to do is make it so. This involved making a couple file edits.

Backup and then open in an editor C:\Windows\Inf\Sceregvl.inf. Find the [Strings] section and add the following lines immedately before that heading.

Listing 2. Initial Changes ToC:\Windows\Inf\Sceregvl.inf


Now, scroll to the very end of the file and append the following lines. (The following is only two lines, but it may wrap to fit better on the screen.)

Listing 3. Final Changes To C:\Windows\Inf\Sceregvl.inf

AppLogSD="Event log: Specify the security of the application log in Security Descriptor
Definition Language (SDDL) syntax"
SysLogSD="Event log: Specify the security of the System log in Security Descriptor
Definition Language (SDDL) syntax"

Once those changes are made, save the file, open up a cmd prompt and type the following.

Listing 4. Reregistering for Changes To Take Effect
C:\> regsvr32 scecli.dll

A dialog box should pop up that says ‘DllRegisterServer in scecli.dll succeeded’. Click ‘OK’ to clear it to clear it from the screen.


The changes above will have created a couple of new options you can edit in local security policies. I chose to make mine to the Domain Controller Security Policy in order to effect all DCs, however you could just as easily do the same to the Local Security Policy on a machine-by-machine basis.

Open your Domain Controller Security Policy and navigate to Local Policies -> Security Options. There should be two new entries here, both prefixed by “Event Logs:“. The first will let you adjust permission on the Application log and the second lets you adjust permission on the System log. Even at this point, once you check the box to “Define this policy setting” it gives you a simple text entry box and expects you to know what’s appropriate. What it’s asking for is a new SDDL string that defines the new security model for the logs. To start with, the default SDDL that Windows 2003 applies is (all one line):

Listing 5. Default SDDL String On Windows 2003 Event Logs

There’s a lot going on there, and at this time I’m not about to go into what it all means, but just know that it’s basically setting specific permissions for specific types of people. What’s missing, and what I wanted to add, are permissions allowing non-administrator to add entries from remote machines. As an aside, don’t bother getting the idea about a lecture on how insecure that can be. I understand the implications, every setup is different, and it’s not the point of this writeup. The nugget we’re looking for is is a piece that grants Authenticated Users write access to these logs:

Listing 6. SDDL Piece Allowing Authenticated Users Access

And if we nestle that into the default string we come up with this (emphasis on addition):

Listing 7. Modified SDDL for Application Logs

Paste that entire string in and click ‘OK’. If you added it to the Domain Controller Security Policy like I did, you only need to perform this on a single DC and it will replicate to all others. Once completed, Authenticated Users will have access to add entries into the application logs of your Domain Controllers.


I’d like to again say that I’m well aware that you might consider this a bad idea. Allowing non-privileged users write access to your logs can open you up to several types of nastiness. I keep a fairly healthy eye on our logs and I feel like the threat of any of those situations is minimal and easy to deflect in the event it comes up. In the mean time, Netwatch is much healthier again and is now back to reporting login events in realtime. Here’s a show of Netwatch back in action on a somewhat slow Friday:


(Click for full image. Names and addresses [except mine] masked.)

3 Responses to “Windows 2003 Server Event Log Security”

  1. Chuck says:

    Hi Matt,
    Thanks for the info! We were trying to deploy a Web application that used the Enterprise Library’s Data Access Application Block. It was developed and worked fine on a Windows XP box. When we put it on a 2003 box, we got a stack trace that indicated the current user didn’t have write privs on the Event Log. Somewhere in the bowels of the Data Access Application Block, it tries to write to the Event Log. Your post was exactly what we needed. Thanks for posting it.

  2. Fred Mastro says:

    I was searching all over the internet and fell asleep too, and woke up to find this article. Thanks Matt!! It was just what I was looking for.

  3. Hydrolyze says:

    Whats up! Excellent concept, but could this truly operate?


Leave a Reply