EventLog.SourceExists fails on Windows Server 2019

Question

I am testing an ASP.NET application on Windows Server 2019 with .Net Framework 4.7.2. The IIS Application is setup to impersonate a user that does NOT have administrative privileges.

The application calls EventLog.SourceExists to check if a event log source exists before trying to create a new source. I understand this method requires administrative privileges in order to search existing event logs for the source [1]. Another way to accomplish this, I explicitly give my user read permissions to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog and all children.

This works on versions prior to Windows Server 2019 (2016, 2012 R2, 2018).

When testing, this same application fails on Windows Server 2019 with the exception.

The source was not found, but some or all event logs could not be searched. Inaccessible logs: State.

When running procmon, I see Access Denied when trying to open the registry key for the "State" eventlog HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\State

The "State" registry key appears new to Windows Server 2019. It's also protected - It's owned by SYSTEM, and Administrators is limited to read only. I get Access Denied when trying to give my user read permissions. As a result, my application running as my non-admin user fails with Inaccessible logs: State when calling EventLog.SourceExists.

I realize I could take ownership of the State registry key and add my user. However, before I do this, I would like to see if anyone has knowledge of this new registry key (eventlog) in Windows Server 2019.

Thanks.

[1] https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.eventlog.sourceexists?view=netframework-4.7.2

Answer 1

Root Cause:

The 'State' hive in the HKLM\SYSTEM\CCS\Services\EventLog tree has a weird security configuration. Due to this, any application trying to enumerate the Event Sources will eventually hit an "Access denied" exception and quit out.

Default Permissions are:

• SYSTEM (full control)
• EventLog (full control)
• Administrators (read key)

They are NOT inherited, in the same way as for example for the 'Security' hive. In contrast, the second new hive named 'Parameters' inherits permissions.

Enumerations are usually done in Applications like this:

[System.Diagnostics.EventLog]::SourceExists("Source Name")

Even when you try to enumerate using PowerShell, you will hit an "Access Denied"

PS C:\> (gci -Recurse HKLM:\System\CurrentControlSet\services\eventlog).Name

While I don't know what exactly the 'State' hive is doing (Microsoft is not very elaborative on it) I found a way to fix this.

Solution:

1. interactive solution, using REGEDIT:

   a) run REGEDIT as SYSTEM using 'PSexec' and b) using the UI of REGEDIT, grant read permissions to the 'State' hive for IIS_IUSRS or any arbitrary account that your service or IIS application pool runs with

2. scripted approach, using PowerShell:

   a) run PowerShell as SYSTEM using 'PSexec' and b) using 'Get-ACL' / 'Set-ACL' cmdlets, grant read permissions to the 'State' hive for IIS_IUSRS or any arbitrary account that your service or IIS application pool runs with

Running an application as the SYSTEM user is best achieved by using PSexec, which can be downloaded freely from the Microsoft SysInternals site (https://docs.microsoft.com/en-us/sysinternals/downloads/psexec)

PS C:\> PSexec.exe -accepteula -d -i -s powershell.exe

This opens up a PowerShell-Window running as NT AUTHORITY\System. From here, either use REGEDIT to change the permissions for your Service User Account or IIS Application Pool User on the 'State' hive. Alternatively, use the Get-ACL / Set-ACL cmdlets to do the same in a scripted manner. The "read key" permission is sufficient; no need for "full control".

PS C:\> $hive = HKLM:\System\CurrentControlSet\services\eventlog\state; $acl = Get-ACL $hive; $rule = New-Object System.Security.AccessControl.RegistryAccessRule ("IIS_IUSRS","ReadKey","ContainerInherit","None","Allow"); $acl.SetAccessRule($rule); $acl |Set-ACL $hive

Your application should now be able to both enumerate all Event Sources on the machine it runs on and create an Event Source, if enumeration does not find it.