Объектная модель клиента выдает 401 при олицетворении вошедшего в систему пользователя - приложение MVC

Question

У меня есть приложение ASP.NET MVC, которое подключается к SharePoint 2010 через клиент OM.Когда я бегу ExecuteQuery(), я получаю сообщение об ошибке HTTP 401 от SharePoint.

У меня есть приложение MVC, настроенное на выдачу себя за вошедшего в систему пользователя.

Параметр олицетворения в web.config (приложения MVC):

<configuration>
    <system.web>
        <identity impersonate="true" />
    </system.web>
</configuration>

Код:

Client Context ctx = new ClientContext("http://sharepoint.company.com/site");
ctx.Credentials = CredentialCache.DefaultNetworkCredentials;

Web web = ctx.Web;
ListCollection lists = web.Lists;

ctx.Load(web);
ctx.Load(lists);

ctx.ExecuteQuery();

Исключение:

Исключение System.Net.WebException:Удаленный сервер вернул сообщение об ошибке:(401) Несанкционированный доступ.в System.Net.HttpWebRequest.GetResponse() в Microsoft.SharePoint.Клиент.SPWebRequestExecutor.Выполнить() в Microsoft.SharePoint.Клиент.ClientContext.EnsureFormDigest() в Microsoft.SharePoint.Клиент.ClientContext.ExecuteQuery() в MVCApp.Services.SharePointService.Получить библиотеки ()

Когда я удаляю параметр олицетворения из web.config, клиент OM использует учетную запись пула приложений приложения MVC для подключения.Когда это происходит, подключение выполняется успешно (после предоставления разрешений учетной записи пула приложений).Кроме того, если я жестко закодирую учетные данные пользователя вместо использования DefaultNetworkCredentials, соединение также работает.

Приложение настроено для проверки подлинности Windows, а анонимная проверка подлинности отключена в IIS.

То, что мы уже пробовали:

1. убедитесь, что учетные записи пула приложений могут делегировать разрешения.
2. проверенная конфигурация kerberos (мы удалили некоторые дублирующиеся SPN)
3. подключайтесь с другого сервера (мы размещаем это приложение на сервере приложений SharePoint).Подключение с этого сервера означает, что мы не можем подключиться ни к ОДНОМУ экземпляру sharepoint.Подключение с другого сервера позволяет нам подключаться к нашей среде разработки, но не к этому серверу (QA) или нашей производственной среде.

Что я могу сделать, чтобы заставить клиентский OM делегировать разрешения пользователя при подключении к SharePoint?

---

Обновить

Интересно, что я попробовал простой веб-запрос к SharePoint с идентичными результатами, который говорит мне, что проблема вызвана не клиентом OM:

WebRequest request = WebRequest.Create("http://xxxxxxxxx");
request.Credentials = CredentialCache.DefaultNetworkCredentials;

using(WebResponse response = request.GetResponse())
using(StreamReader reader = new StreamReader(response.GetResponseStream()))
{
    return Content(reader.ReadToEnd(), "text/html");
}

Answer 1

Это звучит много, как будто вы попадаете в пресловутый NTLM Double Hop проблема И мне жаль говорить, что вокруг него нет никакого пути от изменения вашей аутентификации на претензию или Kerberos.Ни один из которых не следует воспринимать слегка.

Если ваш код работает на одной из машин на ферме SharePoint, вы пытаетесь вообще общаться, то вы, вероятно, можете обойти это, пропустив второй «прыжок» и взаимодействуя с помощью SharePoint непосредственно через модель объекта насервер, а не через веб-сервисы.

Answer 2

Прошло почти два года, но недавно у меня возникла та же проблема с SharePoint 2013 (на самом деле я обращался к SP2013 с библиотеками CSOM SP 2010).Наконец-то мне удалось во всем разобраться.

Во-первых, я предполагаю, что аутентификация Kerberos в вашем случае работала корректно.На всякий случай вы можете отключить проверку подлинности NTML в настройках IIS или отобразить на своей тестовой странице

Thread.CurrentPrincipal.Identity.AuthenticationType

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

Далее, обновление вашего вопроса.Это мне очень помогло, я понял, что нам не стоит беспокоиться о CSOM, когда простейшее делегирование с помощью WebRequest не работает.Проблема заключается вот в чем.

И, наконец, эта незаметная ссылка из S J ответ действительно может обеспечить решение – вы упомянули все шаги по настройке делегирования, за исключением разрешения делегирования для СЕРВЕР.Да, вы должны настроить то, чему вы доверяете и то , и другое учетная запись для делегирования (о которой вы упомянули) и эта конкретная машина для делегирования.

И еще одна совершенно очевидная вещь – сам SharePoint должен быть правильно настроен для проверки подлинности Kerberos.

Как только делегирование веб-запроса сработает (например,загрузка начальной страницы), вы можете сделать то же самое с CSOM.Я проверил это, работает как по волшебству.

Разница в том, что я (1) использовал SP2013 с 2010 CSOM, (2) включил делегирование только для определенного фрагмента, а не для всего запроса:

string ImpersonatedSpLogin = null, ImpersonatedSpMail = null;

WindowsIdentity identity = (WindowsIdentity)User.Identity;
using (var impersonationContext = identity.Impersonate())
{
    using (ClientContext context = new ClientContext("http://myServer.somewhere.com/"))
    {
        context.Load(context.Web.CurrentUser);
        context.ExecuteQuery();
        ImpersonatedSpLogin = context.Web.CurrentUser.LoginName;
        ImpersonatedSpMail = context.Web.CurrentUser.Email;
    }

    impersonationContext.Undo();
}
// now you can verify by checking  ImpersonatedSpLogin and ImpersonatedSpMail

Надеюсь, это кому-нибудь поможет.

Answer 3

У вас есть генеракодицетагкод там где-то?Я считаю, что это также требуется.

Ниженаженная ссылка имеет некоторую информацию о выходе нескольких переменных на основе настроек конфигурации Web.config и IIS

https://stackoverflow.com/a/1688220/1282079

Answer 4

Помогает ли ссылка ниже?Я также сталкиваюсь с аналогичной проблемой.

https://stackoverflow.com/questions/ 11691650.