Executing SPWebApplication.Update with System account throws SecurityException

Question

I`m doing some web.config modifications with SPWebConfigModification class. When adding them to WebApplication and calling Update to it, it throws me SecurityException, although

• I run code with elevated privilages (and open new instance of SPSite)
• my assembly is in GAC
• application pool account is from wss_admin_wpg group and web.config file has wss_admin_wpg write permissins.

Code

SPSecurity.RunWithElevatedPrivileges(delegate()
{
    addProviderProxy(properties);
});

where addProviderProxy(SPItemEventProperties properties)

using (SPSite site = new SPSite(properties.SiteId))
using (SPWeb web = site.OpenWeb())
{
  ensureSectionGroup(web);
  ...
}

where ensureSectionGroup(SPWeb web)

  SPWebApplication webApp = web.Site.WebApplication; 
  ...
  webApp.Update(); <--Throws exception here

Exception Details

System.Security.SecurityException was caught
  Message="Piekļuve liegta." //(Translates to something like "Access Denied")
  Source="Microsoft.SharePoint"
  StackTrace:
       at Microsoft.SharePoint.Administration.SPPersistedObject.Update()
       at Microsoft.SharePoint.Administration.SPWebApplication.Update()
       at Balticovo.SharePoint.AdjustWebConfigForOutlook.ensureSectionGroup(SPWeb web)
  InnerException: 

Answer 1

Try running this in a PowerShell script, then retry your update:

$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.RemoteAdministratorAccessDenied = $false
$contentService.Update()

I'm still getting the hang of 2010 permissions, so take it for what it's worth. According to Paul Kotlyar, that'll help.

Answer 2

As the "Access Denied" error is occurring at SPPersistedObject.Update(), this obviously indicates that there is a problem persisting the object. This is very likely to be a permissions error writing to the SharePoint configuration database (or maybe another SP database).

If possible check the SQL logs or run a SQL Profiler trace to get more information on what account is causing the problem. Check that the account your code is running under has access to the configuration database.

Update:

You can give permission to the configuration database by adding the user to the Farm Administrator's group. This gives them db_owner permission on that database which isn't ideal as that means the account can do anything. However there is no other way (that I know of) that can give access to this database.

If this is a major concern, you could change the permissions yourself via SQL Server Management Studio. Ideally use SQL Profiler and devise a new role that gives just the permissions required. Alternatively try adding the account to the WSS_Content_Application_Pools role and/or the data_reader and data_writer roles.