locked
System.UnauthorizedAccessException on writting to registy – ASP.NET running on IIS RRS feed

  • Question

  • User-1392776802 posted

    Hi,

    I am getting System.UnauthorizedAccessException running code bellow on ASP.NET and IIS.

    var currentUserStr = "someUser"
    using (var eventLongKey = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(@"SYSTEM\CurrentControlSet\services\eventlog"))
    { 
      var rs = eventLongKey.GetAccessControl(); rs.AddAccessRule(new RegistryAccessRule(currentUserStr, RegistryRights.WriteKey | RegistryRights.ReadKey | RegistryRights.Delete | RegistryRights.FullControl, AccessControlType.Allow));
      eventLongKey.SetAccessControl(rs);
    }
    

    My goal is to allow ASP.NET to write to Event Log in general way so after running in different environment (different Application Pool Identity or Name, etc.) no action is needed from user. If ASP.NET is not permitted in registry it will throw System.Security.SecurityException on eventLog.WriteEntry(string, string).

    Thursday, May 17, 2018 8:45 AM

Answers

  • User283571144 posted

    Hi User919,

    What account is using ASP.NET on Azure? If there will be enough rights on Azure other developers will simply run some script under elevated rights.

    Could you please tell me which azure service you have used? 

    Azure VM or Azure web app?

    If you use Azure VM, it works as same as your local environment.

    We could use administrator account or the account which has the administrator permission.

    Besides, if your application hosted in the IIS, we could set the application pool permission to has the full control for the VM.

    Like below:

    More details, you could refer to below article.

    https://docs.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities 

    If you use azure web app, there are no permission for us to work as administrator.

    We could only use third party logs like application insight.

    More details about how to use application insight in the web app.

    https://docs.microsoft.com/en-us/azure/application-insights/app-insights-profiler 

    Best Regards,

    Brando

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 22, 2018 2:40 AM

All replies

  • User753101303 posted

    Hi,

    Rather than dealing directly with the registry, I would use the built-in .NET classes to register the source. See for example https://www.developer.com/net/asp/article.php/3805646/Writing-to-the-EventLog-from-a-Web-Application.htm

    You'll still have to do that one time at setup as an account is not supposed to be able to give himself permissions it doesn't have already. Would have to see but you could likely do that as well using PowerShell.

    Thursday, May 17, 2018 9:07 AM
  • User-1392776802 posted

    Hi,

    it is just illusion that source creation will solve the problem since upon write to event log the sources are listed to check if the source exists but ASP.NET has by default no read right to event log sources so the exception comes anyway.

    To be correct it is not ASP.NET problem. Running EventLog.WriteEnty on IIS Express will create the source instantly since I am running VS as administrator but via IIS there is need for application pool identity rights. At least read rights if the source is created other way.

    Thursday, May 17, 2018 10:30 AM
  • User753101303 posted

    Yes anyway it is a permission issue. What if you move this code to a console app so that you can run this with an authorized account?

     You are trying to write to the Application log or to a custom log? I'll have to check again to make sure which steps are required.

    Thursday, May 17, 2018 11:26 AM
  • User-1392776802 posted

    Yes, it is about permissions.

    I suppose running console app will need the rights also so still will be invoking user action.

    Thursday, May 17, 2018 11:28 AM
  • User753101303 posted

    It should be run by someone who is allowed to write to this key. It is part of the initial site install and shoould NOT be part of the application itself (at least this is what I'm doing).

    I've done a quick check and I don't see any special permission. "AuthenticatedUsers" have read access and it should cover your application pool identities (I'm using domain accounts but I really don't think it should make a difference). You just need to add the key once for all using whatever authorized account you want.

    For now the issue is that you are trying to do that from within the app which have only read access (and IMO there is no reason to grant write access there to an IIS app).

    Edit: and looking at https://referencesource.microsoft.com/ it seems what CreateEventSource does behing the scene.

    Thursday, May 17, 2018 11:51 AM
  • User-1392776802 posted

    Yes, thank that I know but still thanks.

    There is also issue how to set up this on Azure.

    Thursday, May 17, 2018 11:53 AM
  • User753101303 posted

    Hi,

    This is an Azure VM? From what I'm seeing so far you have no way around this ie by design :
    - only "SERVER\Administrators" (and SYSTEM) have full control
    - "Authenticated Users" have read access

    So for now my approach would be to let an administrative user do that once for all using a console app (or nowadays maybe a PowerShell script)
    Then whatever account is used by IIS should have read access and so it should work.

    Changing permissions is IMO not needed at all and anyway it would require also this operation to be done by a member of the "administrators" group.

    If you are not allowed to do that you have IMO no other option than to see that with a person that have this access level.

    BTW : by default ASP.NET already log exceptions to the Application log. So if you want to write to this log it I believe it should be possible. Another option would be use something else to log your information.

    Thursday, May 17, 2018 1:58 PM
  • User-1392776802 posted

    Hi,

    it is intended to custom logging, i.e. logging catched exceptions with custom info.

    Generally it is normal app so every developer in that case would have to change registry manually. I have locally all rights needed.

    What account is using ASP.NET on Azure? If there will be enough rights on Azure other developers will simply run some script under elevated rights.

    Friday, May 18, 2018 10:55 AM
  • User283571144 posted

    Hi User919,

    What account is using ASP.NET on Azure? If there will be enough rights on Azure other developers will simply run some script under elevated rights.

    Could you please tell me which azure service you have used? 

    Azure VM or Azure web app?

    If you use Azure VM, it works as same as your local environment.

    We could use administrator account or the account which has the administrator permission.

    Besides, if your application hosted in the IIS, we could set the application pool permission to has the full control for the VM.

    Like below:

    More details, you could refer to below article.

    https://docs.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities 

    If you use azure web app, there are no permission for us to work as administrator.

    We could only use third party logs like application insight.

    More details about how to use application insight in the web app.

    https://docs.microsoft.com/en-us/azure/application-insights/app-insights-profiler 

    Best Regards,

    Brando

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 22, 2018 2:40 AM
  • User-1392776802 posted

    Hi User919,

    User919

    What account is using ASP.NET on Azure? If there will be enough rights on Azure other developers will simply run some script under elevated rights.

    Could you please tell me which azure service you have used? 

    Azure VM or Azure web app?

    … 

    Hi Brando,

    thanks for reply. I am not sure about Azure kind. I am not responsible for deployment etc. As I get this information I shall take proper steps.

    Tuesday, May 22, 2018 10:54 AM