Nobody trusts anybody anymore. So it’s not surprising when Active Directory administrators feel they have to have total granular control over every class, object, and attribute in the directory. Recently, I was talking with an administrator of an organization that uses Active Directory and wanted to grant someone permission to read the Directory Service event log on a Windows Server 2012 domain controller but be able to do absolutely nothing else on the system. That posed an interesting challenge! After pondering this for a while, the admin reached out to several people including myself who then engaged with other colleagues to try and come up with a solution that could meet his needs. In this article I’ll briefly walk you through our discussion as we tried and ultimately found an easy way to implement this scenario.
Well, it’s sort of easy. And as usual these tips and solutions are presented to you “as is,” so be sure to try them out in your test environment before using them in a production environment.
Event Log Readers group
The first thing this motley assembly of IT pros thought up was to add the target user to the Event Log Readers group, which is one of the default security groups in Active Directory. This group is created when you promote a Windows Server system to the role of domain controller and it’s also present as a built-in group on all of the member servers in each domain of a forest. Members of this group are granted permissions to read the event logs on the local computer. You can read more details about this particular security group on TechNet. When this solution was suggested to the administrator, he pushed back and said it wasn’t granular enough because he didn’t want the user to be able to read all of the event logs on the domain controller, just the Directory Service event log. Of course we tried to convince him otherwise since it was the simplest solution, but no joy. But for any of you who think that this solution might suffice in your environment, you should also take a look at this thread in the Windows Server Directory Services forum on TechNet.
Group Policy
Our second attempt at solving his problem was to recommend the use of Group Policy. A little searching around led one of us to the following TechNet blog from 2010 which deals with giving non-admins permission to read event logs on Windows Server 2003 and Windows Server 2008:
One of our crew had some spare cycles and found that the approach outlined in this post seemed to succeed in modifying the SDDL (security descriptor definition language) of the channel access permissions for each of the event logs on the system. Whew! It did involve a hack, however, as it required taking ownership of %WinDir%\inf\sceregvl.inf to modify the content of this text file, so the question arose as to whether this solution was supportable or not. A quick chat with someone who knew a Premier Field Engineer (PFE) at Microsoft quickly returned an answer: Don’t use this method! We were informed that the security model had changed since Windows Server 2008 and that ADMX/ADML policies and wevtutil were now the way to go on matters like this one.
ADMX/ADML
Back once again to the drawing board. This time a colleague reached out to another colleague who had some sort of inside track with Microsoft, and the answer came back that the proper way to delegate read permissions to the Directory Service event log and to no other logs on the domain controller was to begin by creating a new ADMX file and a corresponding ADML file that include a Group Policy policy setting for ChannelAccess defined by the following registry key:
HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\Directory Service
This step is necessary because the ADMX file for Windows Server 2012 doesn’t have Directory Services under Windows Components/Event Log Service/ in the policy tree. Then deploy the ChannelAccess policy to the domain controllers using a Group Policy Object (GPO). Note that this policy will be applied to all domain controllers in the domain.
For a minute this looked like the way forward until another approach was suggested to us by a different colleague who had a different inside channel at Microsoft…
Wevtutil
The other solution to allowing access to the Directory Service event log that was offered to us was to execute the command wevtutil sl “directory service” /ca:”<SDDL>” where <SDDL> is the SDDL the administrator would want to use for configuring security on his domain controller. Note that this approach would have to involve running this command on each domain controller in the domain. This particular solution, however, was offered to us as a caveat as it allowed for the possibility that as time progressed the security configuration of the domain controllers could diverge from one another. That’s probably not very good, so by now we were scratching our heads and wondering if any of us really knew what we were doing with this stuff. Maybe go back to pushing the Event Log Readers group as a solution?
Group Policy Preferences
One colleague wouldn’t give up, however, and persisted in asking around until finally he found someone who knew someone who said he knew somebody inside Microsoft who had a simple solution for implementing the desired scenario. The solution he was offered involved using Group Policy Preferences (GPP) to push out a specific registry setting to the domain controller that the admin wanted to give the user access to its Directory Services Event log. This simple solution involved using the Set-GPPrefRegistryValue cmdlet of Windows PowerShell, which can be used to configure a registry preference item under either Computer Configuration or User Configuration in a GPO (the syntax for this command can be found here). And here is the actual PowerShell command that was recommended to us:
Set-GPPrefRegistryValue -Action Update -Context Computer -Key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Directory Service” -Name “Domain Controller Delegations” -Type String -Value “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)(A;;0x1;;S-1-5-21-3193938542-858056337-3914692633-1104)” -ValueName CustomSD
Now just imagine what havoc might ensure should one execute this command with a single typo in the syntax — yikes! But hey, no one ever said administering Active Directory was supposed to be easy! Anyway, be sure to try this out in a test environment before you consider running this command in your production environment. Or better yet, just use the Event Log Readers group instead. Or even better, don’t give any non-admins permission to read the Directory Service event log on your domain controllers!
