4

Here is what I'm currently trying to do -

1.Create a new instance of a timer job from a web part

2.Add a new site collection to the current web application again from a web part

Each time the code in question fails with the following SQL error message:

Insufficient SQL database permissions for user '' in database 'MOSS_Config' on SQL Server instance 'MYVM'. Additional error information from SQL Server is included below. The EXECUTE permission was denied on the object 'proc_putObject', database 'MOSS_Config', schema 'dbo'.

I have tried every form of impersonation I can think of within the code and yes I have instantiated my SPSite/SPWeb objects within the elevated code -

  • SPSecurity.RunWithElevatedPrivaleges
  • Running as SHAREPOINT\System User
  • Token Using .NET Impersonation

Each time it still fails with the same error. I have used SQL Profiler and each time the code executes it is always trying to run under the Application Pool account - therefore it fails as of course the app pool account does not have sufficient privileges on the config database.

All my research has led me to only one answer - making the application pool account a member of the Farm Admin group (http://www.hezser.de/blog/archive/2008/05/20/using-the-propertybag.aspx)

Is this really the only solution? and more importantly is a supported modification? as I would guess it violates best practices?

Thanks,

Alex

||improve this question
1

The application pool account of content Web applications does not have write permissions to the SharePoint configuration database - only read. You need to execute your code in the context of the Central Administration application pool account or in the context of a timer job. Yes, it is definitely not best practice to grant write access to application pools of content Web applications. It will increase the attack surface in your farm by an order of magnitude!

||improve this answer
  • Very true but this is not a 'default' you are assuming that the farm was configured correctly (which it sounds as though it was anyway) but you cannot just say: "the application pool account of content Web applications does not have write permissions to the SharePoint configuration database" It may well have, but it shouldn't! – Charles Lee Oct 7 '10 at 15:38
  • Thanks Charles for pointing this out as this is also what I implied - sorry for not being specific enough. Application pool accounts does of course have write access to the configuration database if for instance an admin account or the configuration database owner account was also specified for the content application pools. This is of course not best practice and applications should never be designed to rely on this! – Lars Fastrup Oct 8 '10 at 8:08
0

By elevating using SPUserToken you should be able to use the specific account that has proper access to the database in question (SPFarm account would be a good guess).

http://solutionizing.net/2009/01/06/elegant-spsite-elevation/

Adding your app pool account to the farm administrative group is definetely not a best practice!

||improve this answer
  • Thanks Anders - I previously tryed using SPSite.SystemAccount.UserToken but still failed. Guess I would need to get the user token of the specific account - e.g. farm account as you say but I would need to know the user name then which is not appropriate for production environment. Any other ideas? – Anonymous Oct 7 '10 at 13:20
  • I do not think the UserToken will work - the SharePoint object model will at the end of the day still access the database with the credentials of the application pool account. The UserToken is merely used to test the access permissions for objects before they are returned through the object model. – Lars Fastrup Oct 7 '10 at 13:40
  • Thanks Lars - that's what I thought. I have been trying with UserToken for a while now and it still doesn't work. As per this MSDN post - social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/… it seems I would need to set the 'Account operates as System' in the policy for web application. This is not ideal for a production environment. Any other ideas how I could execute the code in question? – Anonymous Oct 7 '10 at 13:50
  • Using the best practice of least privilege accounts for content application pools it will just not be possible to update the config database directly from here. One work-around could be to store change requests in a regular list and then let a SharePoint Timer job pick up the request and make the appropriate changes. You can let the timer job run every minute or so to check for new change reuqests. – Lars Fastrup Oct 7 '10 at 14:11
  • Thanks Lars - that's not a bad idea - looks like a timer job might be the way to go then. Thanks for clearing up that's it not possible whilst keeping to best practices. – Anonymous Oct 7 '10 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy