Почему я получаю исключение UnauthorizedAccessException с некоторыми идентификаторами пула приложений, если хочу использовать SPSiteCollection.Add в Sharepoint 2010?

Предыстория этого вопроса заключается в том, что моей текущей задачей является разработка страницы приложения, которая позволяет пользователям создавать семейства веб-сайтов. Свойства семейства веб-сайтов считываются из элемента списка. Мое решение работает в большинстве случаев. Тем не менее, есть одна конфигурация идентификаторов пула приложений, в которой отказано в доступе, и я хотел бы понять, почему это происходит.

(Очень) урезанная версия моего кода выглядит так:

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));
});

Исключение UnauthorizedAccessException выдается, когда Identities установлены следующим образом:


Центр администрирования SharePoint v4 --> локальный домен\учетная запись администратора

SharePoint - 80 --> Сетевая служба


Все остальные комбинации NetworkService и домен\учетная запись администратора работают. У кого-нибудь есть объяснение этому?

ОБНОВЛЕНИЕ

Я предполагаю, что вам нужно запустить свой пул приложений sharepoint, используя того же пользователя, что и пул приложений центрального администрирования, чтобы иметь достаточные права на БД. Но это все равно не объясняет, почему он работает в следующей конфигурации:


Центр администрирования SharePoint v4 --> NetworkService

SharePoint – 80 --> локальный домен\учетная запись администратора


Кстати, еще один вопрос по SA дает решение (и некоторые подробности проблемы). См. раздел Разрешение на предоставление нового семейства веб-сайтов через рабочий процесс.


person binford    schedule 15.12.2010    source источник


Ответы (3)


код в RunWithElevatedPrivileges выполняется с использованием учетных данных учетной записи apppool веб-приложения, под которым выполняется ваш код. рекомендуется всегда использовать учетные записи сервисного домена для пула приложений. В вашем случае у одной из учетных записей должна отсутствовать запись в некоторые из групп, созданных точкой доступа на вашем сервере, или она может не иметь надлежащих прав на базу данных.

person Ashutosh Singh-MVP SharePoint    schedule 15.12.2010
comment
Я предполагаю, что, установив NetworkServices в качестве учетной записи фермы, он получит достаточно прав для БД для создания семейства сайтов. Но почему это работает, когда мое веб-приложение работает под учетной записью localdomain\admin, а ЦС работает под NetworkService? Я сам никогда не трогал права доступа к БД. - person binford; 16.12.2010
comment
В порядке. Я узнал, почему это происходит. Смотрите мой ответ. - person binford; 16.12.2010

Хорошо, проблема заключалась в правах доступа к БД для пользователя, запускающего пул приложений веб-приложений хоста моей страницы приложения. Учетная запись фермы (очевидно) имеет права db_owner на базы данных AdminContent и _Config. Вот почему это работает, когда оба пула приложений запускаются с использованием одного и того же пользователя.

Причина, по которой он также работал, используя следующую конфигурацию...


Центр администрирования SharePoint v4 --> NetworkService

SharePoint – 80 --> локальный домен\учетная запись администратора


... в том, что у моей локальной учетной записи администратора также были права db_owner. Я понятия не имею, почему у него такие права, я никогда не возился с правами доступа к БД самостоятельно. Я только один раз установил его как учетную запись Farm, но вскоре изменил это.

person binford    schedule 16.12.2010

Я бы рассмотрел следующее: 1) привилегии для пользователя с повышенными правами для целевого contedb 2) предоставить пользователю с повышенными правами (учетной записи пула приложений веб-приложений на странице приложения) права в качестве dbcreator, если сценарий создает базы данных.

person UJ.    schedule 16.12.2010