5

We're currently trying to integrate existing classic ASP pages into our new method of logging to the event log. We're achieving this by calling a .NET assembly exposed as a COM object which does the actual logging to event log. This all works correctly, however when we try to write to the event log we get an error "Cannot open log for source 'SourceName'. You may not have write access.". The logging code itself works when calling from an aspx page. This obviosuly appears to be a permissions problem with the IUSR_machinename account, however, from looking into a number of other related posts we've tried a number of solutions without any success.

  • Editing HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/EventLog/Application/RestrictGuestAccess - setting this to 0
  • Adding IUSR_machinename to local admin groups and removing the guest group
  • Editing CustomSD and appending (A;;0x0002;;;AU) to the value here

The only success we have had is when using ASP.NET impersonation to use a newly created local admin account on the server. With this user it works, however, this is a workaround rather than solving the initial permissions problem. Is there anything else that we can try to get the permissions working with the IUSR_machinename account?

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
whudson05
  • 469
  • 1
  • 3
  • 9
  • What exactly is "SourceName" and how/when do you create it? – H H Jul 21 '10 at 15:27
  • what about change the IUSR to administrator in the security of the iis website? – Y.G.J Jul 22 '10 at 09:47
  • SourceName is the name of the Source in the event log. We create it when we install the application by creating a key in the registy. – whudson05 Jul 22 '10 at 14:19
  • We effectively changed the IUSR to administrator and it works as mentioned in the question, but this gives the .NET impersonation user far more rights than we would like to. – whudson05 Jul 22 '10 at 14:21
  • "by creating a key in the registy" - why not use the API for eventsources? – H H Jul 23 '10 at 19:50
  • The only reason we did it this way was for consistency. As our installer handles all the registry key creation we chose to also create the keys for the event sources here. – whudson05 Aug 03 '10 at 09:48

3 Answers3

4

Got this solved by setting the impersonate tag in web.config to false:

<identity impersonate="false"/>
jcs
  • 611
  • 2
  • 9
  • 22
  • You have to temporarily disable impersonation in your code, for more details Check this **[The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.](https://debug.to/2683/source-found-but-some-all-event-logs-could-not-searched-inaccessible-logs-security)** – Mohamed Nov 19 '21 at 22:58
2

We managed to solve this problem in the end by giving guest users access to the event log. You can carry this out by adding (A;;0xf0002;;;BG) to the customSD or replacing (D;;0xf0007;;;BG) if it is present. Then by setting RestrictGuestAccess to 0.

whudson05
  • 469
  • 1
  • 3
  • 9
0

If you have impersonation set to true in the web config, the impersonated user will be the one trying to access the event logs. In this case you will need to grant access to authenticated users.

Jacob Holm
  • 33
  • 4