Delegating read only access to Domain Controller Event Logs

Something AD administrators used to dread was the inevitable request for access to Domain Controller event logs for monitoring purposes.

The lazy admin (Rob Field) approach was to give the service account Domain Admins. More dedicated staff would fiddle around with the SDDL security descriptors until they got it right.

Well that’s not needed anymore… Delegating read only permission to the event logs cannot be easier with 2008.

There is an Active Directory built-in group called ‘Event Log Readers’. All you need to do is drop the service account that needs this privilege into the Event Log Readers group and your monitoring software should be happy.

Note this gives access to all event logs. However if you do not want to give them access to all event logs you still have to resort to using SDDL. There is a good post here.

This also works with Member Servers. Just drop the service accounts into the Event Log Readers group on each member server.


Event ID 10154 after promoting 2008 R2 Domain Controller

Fark. What a day. Another spurious event log error.

What’s worse than getting event log errors after deploying an OS… How about after promoting a domain controller. It creates far too many questions and far too few answers!

After building out a new Active Directory forest I noticed the following event log errors in the 2008 R2 Domain Controllers:

The WinRM service failed to create the following SPNs: WSMAN/servername.fqdn; WSMAN/servername 
Additional Data 
The error received was 1355: %%1355.
User Action 
The SPN can be created by an administrator using setspn.exe utility.

This appears to be caused by the NETWORK SERVICE not being given the necessary permissions on the domain controller AD object to make write changes.

I tried a number of things to get this to work and I think I have found the solution.

Adding the necessary values with SETSPN manually does not resolve the issue because the NETWORK SERVICE attempts to write the WSMAN SPN values each time the WinRM service is started.

You can apply the necessary permissions manually with ADSIEDIT or via the command line with dsacls.

The domain controller AD object resides in the Domain Controllers OU. If you apply permissions directly to the domain controller object they will (should!) be replaced by the permissions held on the AdminSDHolder object. In my testing this what not the case, however all the documentation I’ve read indicates differently.

Anyhow, the AdminSDHolder object resides in the System container in every domain and is used to secure privileged users, groups and objects from modification. A background process on the PDC emulator runs every 60 minutes and compares the ACL of the AdminSDHolder object with the ACL of the protected users, group and computers. If there are any differences it overwrites them. Read more about this here.

When I applied the necessary permissions to the AdminSDHolder object only, I could not get the permissions to overwrite on the domain controller object. I waited a couple of hours and even forced the SDPROP process to run. No joy.

I used adfind.exe as described in the Technet article above and confirmed that the \Users\Domain Controllers group is a protected group and as the domain controller objects reside in the Domain Controllers group they should be protected.

I can see the AdminSDHolder ACL being applied to the Domain Controllers group, but not the objects contained with the Domain Controllers. Weird.

I don’t yet know why the ACL of the domain controller object wasnt overwritten , but this was consistent across multiple domains I tested this on. This will need further investigation as all evidence points to the domain controller objects being protected. I also recreated the issue on a vanilla Windows 2008 R2 SP1 ISO to eliminate any other potential causes. When testing with the vanilla ISO, I also received the same error as above, just with a different error code in the message ‘The error received was 8344: %%8344.

To work around this issue I applied permissions directly to the domain controller and AdminSDHolder objects with dsacls:

dsacls “CN=AdminSDHolder,CN=System,DC=domain,DC=com” /G “NETWORK SERVICE:WS;Validated write to service principal name”

dsacls “CN=domaincontroller,OU=Domain Controllers,DC=domain,DC=com” /G “NETWORK SERVICE:WS;Validated write to service principal name”

After that just stop and start the WinRM service and check the System log. Event ID 10154 should be gone.