윈도우 2019에서 EventLog.SourceExists 에서 에러가 발생할 때

윈도우 EOS 작업등으로 2019로 업그레이드시에

IIS 셋팅후 갑자기 이벤트로그(eventlog) 관련 작업에서 에러가 발생한다.

이벤트로그 관련 권한 regedit 으로 권한을 NETWORK Service 를 주고,

폴더에서 권한 지급 등을 해도 똑같이 에러가 발생.. 

이리저리 알아보다가..

해외 stackoverflow 에서 관련 글을 찾음.

EventLog.SourceExists fails on Windows Server 2019

EventLog.SourceExists fails on Windows Server 2019

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

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.

 

추가로 한글 사이트에서도 동일한 내용을 찾음.

Windows Server 2019에서 EventLog.SourceExists가 실패 함

.Net Framework 4.7.2가 설치된 Windows Server 2019에서 ASP.NET 응용 프로그램을 테스트하고 있습니다. IIS 응용 프로그램은 관리자 권한이없는 사용자를 가장하도록 설정되어 있습니다.

응용 프로그램은 새 소스를 작성하기 전에 EventLog.SourceExists 를 호출하여 이벤트 로그 소스가 있는지 확인합니다. 소스에 대한 기존 이벤트 로그를 검색하려면이 방법에 관리 권한이 필요하다는 것을 알고 있습니다 [1]. 이 작업을 수행하는 또 다른 방법은 사용자에게 레지스트리 키 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog 및 모든 자식에 대한 읽기 권한을 명시 적으로 부여하는 것입니다.

Windows Server 2019 (2016, 2012 R2, 2018) 이전 버전에서 작동합니다.

테스트 할 때 Windows Server 2019에서도 동일한 응용 프로그램이 실패합니다.

소스를 찾을 수 없지만 일부 또는 모든 이벤트 로그를 찾을 수 없습니다 검색했습니다. 액세스 할 수없는 로그 : 상태.

procmon을 실행할 때 "상태"이벤트 로그 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\State 대한 레지스트리 키를 열려고하면 액세스가 거부됩니다.

"상태"레지스트리 키는 Windows Server 2019에 새로 나타납니다. 또한 보호되어 있습니다. SYSTEM이 소유하고 있으며 관리자는 읽기 전용으로 제한되어 있습니다. 사용자에게 읽기 권한을 부여하려고하면 액세스가 거부됩니다. 결과적으로 관리자가 아닌 사용자로 실행중인 응용 프로그램은 Inaccessible logs: State EventLog.SourceExists를 호출 할 때 Inaccessible logs: State 실패합니다.

State 레지스트리 키를 소유하고 사용자를 추가 할 수 있다는 것을 알고 있습니다. 그러나이 작업을 수행하기 전에 Windows Server 2019의 새로운 레지스트리 키 (이벤트 로그)에 대해 알고있는 사람이 있는지 확인하고 싶습니다.

감사.

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

Answers

근본 원인 :

HKLM \ SYSTEM \ CCS \ Services \ EventLog 트리의 'State'하이브에는 이상한 보안 구성이 있습니다. 이로 인해 이벤트 소스를 열거하려는 응용 프로그램은 결국 "액세스 거부"예외를 발생시키고 종료됩니다.

기본 권한은 다음과 같습니다.

• SYSTEM (모든 권한)
• EventLog (모든 권한)
• 관리자 (읽기 키)

예를 들어 '보안'하이브와 같은 방식으로 상속되지 않습니다. 반대로 'Parameters'라는 두 번째 새 하이브는 권한을 상속합니다.

열거는 일반적으로 다음과 같은 응용 프로그램에서 수행됩니다.

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

PowerShell을 사용하여 열거하려고해도 "액세스 거부"가 발생합니다.

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

'State'하이브가 정확히 무엇을하고 있는지 알지 못하지만 (Microsoft는 그다지 정교하지 않습니다)이 문제를 해결할 수있는 방법을 찾았습니다.

해결책:

1. REGEDIT를 사용하는 대화식 솔루션 :

   a) 'PSexec'를 사용하여 REGEDIT를 SYSTEM으로 실행 b) REGEDIT의 UI를 사용하여 IIS_IUSRS에 대한 'State'하이브 또는 서비스 또는 IIS 응용 프로그램 풀이 실행하는 임의의 계정에 대한 읽기 권한을 부여하십시오.

2. PowerShell을 사용한 스크립트 방식 :

   a) 'PSexec'를 사용하여 PowerShell을 SYSTEM으로 실행 b) 'Get-ACL'/ 'Set-ACL'cmdlet을 사용하여 IIS_IUSRS에 대한 'State'하이브 또는 서비스 또는 IIS 응용 프로그램 풀이 실행하는 임의의 계정에 대한 읽기 권한을 부여합니다.

Microsoft SysInternals 사이트 ( https://docs.microsoft.com/en-us/sysinternals/downloads/psexec )에서 무료로 다운로드 할 수있는 PSexec를 사용하면 SYSTEM 사용자로 응용 프로그램을 가장 잘 실행할 수 있습니다.

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

그러면 NT AUTHORITY \ System으로 실행되는 PowerShell 창이 열립니다. 여기에서 REGEDIT를 사용하여 'State'하이브에서 서비스 사용자 계정 또는 IIS 응용 프로그램 풀 사용자에 대한 권한을 변경하십시오. 또는 Get-ACL / Set-ACL cmdlet을 사용하여 스크립트 방식으로 동일하게 수행하십시오. "키 읽기"권한으로 충분합니다. "모든 권한"이 필요하지 않습니다.

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

이제 응용 프로그램은 실행중인 컴퓨터의 모든 이벤트 소스를 열거하고 열거가없는 경우 이벤트 소스를 작성할 수 있습니다.

참조 : https://ko.programqa.com/question/54874695/