Ошибка аутентификации при доступе к списку Sharepoint через веб-сервис - PullRequest
6 голосов
/ 25 ноября 2008

Несколько месяцев назад я написал службу Windows, которая пинговала бы список Sharepoint, используя функцию GetListItemChanges _vti_bin / lists.asmx. Он работал нормально до тех пор, пока несколько недель назад моя компания не обновила наш экземпляр Sharepoint до SP1.
Теперь, когда моя служба пытается получить доступ к Sharepoint, я получаю ошибку аутентификации 401.1:

Ошибка:

У вас нет прав для просмотра этой страницы
У вас нет прав для просмотрите этот каталог или страницу, используя предоставленные вами учетные данные.
Пожалуйста, попробуйте следующее: обратитесь в Интернет администратор сайта, если вы верите должен иметь возможность просматривать этот каталог или страница.
Ошибка HTTP 401.1 - Несанкционированный: доступ запрещен из-за неверные учетные данные.
Интернет Информационные службы (IIS)

Я проверил, и мои привилегии на сайте не изменились. Вот код, в котором я вызываю список:

Lists listsService = new Lists();
listsService.Credentials = new NetworkCredential("UserName", "Password", "domain");
Result = listsService.GetListItemChanges("List name", null, dTime.ToString(), null);

Мне также стало известно, что на нашей ферме может быть отключена базовая аутентификация. Я не верю, что использую это, но я могу ошибаться.

Ответы [ 4 ]

1 голос
/ 18 марта 2009

Я только что нашел очень похожую проблему и решил ее благодаря статье в MS KB: http://support.microsoft.com/kb/896861

Бит, который вы должны попробовать это:

Способ 2: отключить проверку петли Выполните следующие действия:

  1. Нажмите Пуск, нажмите Выполнить, введите regedit и нажмите кнопку ОК.
  2. В редакторе реестра найдите и щелкните следующий раздел реестра: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa
  3. Щелкните правой кнопкой мыши Lsa, выберите пункт Новый, а затем щелкните Значение DWORD.
  4. Введите DisableLoopbackCheck и нажмите клавишу ВВОД.
  5. Щелкните правой кнопкой мыши DisableLoopbackCheck и выберите Изменить.
  6. В поле «Значение» введите 1 и нажмите кнопку ОК.
  7. Закройте редактор реестра и перезагрузите компьютер.

Это решило ту же проблему в среде, в которой все обычные решения (добавление учетных данных к вызову веб-службы) не удалось.

1 голос
/ 15 декабря 2008

Основываясь на предоставленной информации, я сомневаюсь, что это ошибка программирования. Можно ли получить доступ к интерфейсу диспетчера IIS на сервере, на котором размещен сайт SharePoint? Если это так, проверьте допустимые технологии аутентификации. Разрешены ли анонимные подключения? Включена ли встроенная проверка подлинности Windows? HTTP Basic auth? Спросите свою инфраструктуру / сотрудников SharePoint о возможности двойного перехода (прокси). Если это так, это тоже может сработать, но это неудобно для настройки (делегирование Kerberos). Класс NetworkCredentials поддерживает все стандартные схемы аутентификации, поддерживаемые IIS (за исключением форм):

http://msdn.microsoft.com/en-us/library/system.net.networkcredential(VS.80).aspx

Может потребоваться, чтобы специалисты по инфраструктуре устанавливали имена участников-служб для веб-интерфейса SharePoint:

http://support.microsoft.com/kb/929650

Однако я не советую что-либо менять через IIS Manager. Попросите администратора SharePoint внести изменения в технологии проверки подлинности, разрешенные для сайта через центр администрирования SharePoint.

С уважением, Сэм

0 голосов
/ 26 ноября 2008

Если предположить, что это не проблемы с аутентификацией SSL или Basic / Windows, тогда я держу пари, что

Для проверки войдите на локальный сервер и попробуйте просмотреть ваш сайт. Если вы не можете успешно просматривать данные с помощью имени пользователя / pwd, указанного выше, но можете сделать это с удаленного компьютера, тогда эта статья для вас.

Вы получаете ошибку 401.1 при просмотре веб-сайта, который использует встроенную аутентификацию и размещен на IIS 5.1 или IIS 6

http://support.microsoft.com/default.aspx?scid=kb;en-us;896861

0 голосов
/ 25 ноября 2008

Есть ли у вас прокси во внутренней сети?

Я думаю в духе двойного прыжка, и что Basic Auth не склонен к этому, а NTLM. Если у вас есть прокси, то проблема двойного прыжка. Если вы обращаетесь к компьютеру напрямую и можете рассчитывать только один переход (услуга для веб-службы), тогда это не должно быть проблемой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...