Access denied when activating a feature

This is the title of a question posted at SharePoint Overflow and got my attention.
I checked out the issue and I had a suspicion it had to do with the user not being a farm administrator. But before answering the post I had to make sure and tested it on my dev machine.

I fired up Visual Studio, create a feature with a feature receiver and wrote some code in the FeatureActivated method to update the web.config file en deployed it from Visual Studio to the SharePoint environment. All went well and the web.config received the modification.

To really make sure I tested this with another user (no farm administrator) by activating the feature from the browser. I received the error described in the post at SharePoint overflow:

<System>
  <Provider Name="Microsoft-SharePoint Products-SharePoint Foundation" Guid="{6FB7E0CD-52E7-47DD-997A-241563931FC2}" />
  <EventID>6615</EventID>
  <Version>14</Version>
  <Level>2</Level>
  <Task>10</Task>
  <Opcode>0</Opcode>
  <Keywords>0x4000000000000000</Keywords>
  <TimeCreated SystemTime="2011-02-02T12:43:36.717773400Z" />
  <EventRecordID>12679</EventRecordID>
  <Correlation ActivityID="{E64F5E21-D27E-46B5-99A6-1366EBD456F5}" />
  <Execution ProcessID="1768" ThreadID="7100" />
  <Channel>Application</Channel>
  <Computer>SP2010</Computer>
  <Security UserID="S-1-5-21-3420107791-3555115667-1280696338-1015" />
</System>
<EventData>
  <Data Name="string0">Access denied.</Data>
</EventData>

and the ULS log mentioned:
The SPPersistedObject, SPWebService, could not be updated because the current user is not a Farm Administrator.

To really really be sure I made the user a farm administrator and tried to activate the feature from the browser: Access denied.
Well, this user is a Farm Administrator now, so why the error?
I removed the user from the Farm Administrators group because I though I did something wrong and tested the activation of the feature in the browser with the farm administrator account: Access denied.
Oww, what’s this?
Suddenly it seemed broken, probably it was broken all the time, because I deployed it from Visual Studio directly and never tested it by activating the feature from the browser with this account.
Deploying and activating the feature from Visual Studio went well and the web.config modification was there, but as soon I activated the feature from the browser I received an Access denied message.

Maybe a timerjob had to run or something, so I checked and waited for a while. Nothing changed.
IISReset, application pool recycle. Nothing changed.
Restarting the server. Nothing changed.

When Googling on the ULS log message this post came up:
http://unclepaul84.blogspot.com/2010/06/sppersistedobject-xxxxxxxxxxx-could-not.html

It was a different matter, but the behaviour seemed to be the same.
A summary of that post:
“Upon detailed investigation of Microsoft.SharePoint.dll  I discovered that SharePoint guys added a new security feature to all objects inheriting from SPPersistedObject in the Microsoft.SharePoint.Administration namespace. This feature explicitly disallows modification of the above stated objects from content web applications, which is where our web part is running. The error message thrown is therefore very misleading. After some more tracing through the code I found a property in SharePoint API which controls this behavior:

Microsoft.SharePoint.Administration.SPWebService.ContentService.RemoteAdministratorAccessDenied”

A PowerShell script is added to that post which turns off the remote administration security.

That did the trick!
The feature which modified the web.config could be activated from the browser again and the Access denied messages were not occurring anymore.

The ultimate test: a regular user was turned into a farm administrator and a site collection owner. This user is now also able to activate the feature from the browser to make a web.config modification.

Serious considerations

There are some serious considerations on this:
The Feature created was a Web scoped feature. When turning off the remote administration security this feature can be activated from any site. But when modifying web.config keys it’s the question if you want to be able to do this from any site.
I think Central Administration is the place to keep features like this. When deploying a feature which modifies web.config keys it’s an administration thing and not a users thing. By the way: if you’re not a farm administrator you get an Access denied message anyway when trying to activate such features if remote administration security is turned on.

So I really doubt it if you have to turn off remote administration security in this example. Rather deploy the feature to the Central Administration.