2
votes

The background of this question is that my current task is to develope an application page which enables users to create site collections. The properties of the site collection are read from a list item. My solution works in most cases. However, there is one configuration of application pool identities where it throws an access denied and I'd like to understand why this is happening.

A (very) stripped-down version of my code looks like this:

SPSecurity.RunWithElevatedPrivileges(delegate { try 
{
  SPWebApplication webApp = this.Web.Site.WebApplication;
  SPSiteCollection siteColl = webApp.Sites;

  SPSite newSite = siteColl.Add(mngPath + siteUrl, siteName, siteDesc, LocaleId, 
                                null, primarySiteAdmin, String.Empty, 
                                String.Empty));
});

The UnauthorizedAccessException is thrown when the Identities are set as following:


SharePoint Central Administration v4 --> localdomain\adminaccount

SharePoint - 80 --> NetworkService


All other combinations of NetworkService and domain\adminaccount do work. Dose someone have an explenation for that?

UPDATE

I guess that you have to run your sharepoint app pool using the same user as the central administration app pool in order to have sufficient rights on the DB. But that still does not explain why it works under the following configuration:


SharePoint Central Administration v4 --> NetworkService

SharePoint - 80 --> localdomain\adminaccount


BTW, another question on SA provides a solution (and some more details of the problem). See Permission to provision new site collection through workflow.

3

3 Answers

2
votes

code under RunWithElevatedPrivileges is executed by using the credentials of th apppool account of the web application under which your code is being executed. best practice is to always use service domain accounts for application-pool. In your case one of account must be missing entry into some of the groups created by the sharepoint on your server or may not be having the proper rights on the database

1
votes

Ok the problem were the DB access rights for the user running my application page's host web applications app pool. The Farm account (obviously) has db_owner rights on the AdminContent and _Config databases. Thats why it works when both application pools are run using the same user.

The reason why it also worked using the following configuration...


SharePoint Central Administration v4 --> NetworkService

SharePoint - 80 --> localdomain\adminaccount


... is that my local admin account also had db_owner rights. I have no idea why it has those rights, I never fiddled with DB access rights on my own. I only set it once to be the Farm account but I changed that soon after.

0
votes

I'd look into the following 1) privileges for the elevated user to the target contedb 2) grant the elevated user (the application page's host web applications app pool account) rights as dbcreator if the script creates databases.