В настоящее время у меня возникают проблемы с аутентификацией на сайте SharePoint. Обычно учетные записи пользователей (только одна или несколько) будут заблокированы, и они получат 401 несанкционированную ошибку. Реализация SharePoint использует только локальные учетные записи пользователей, имеет аутентификацию SSL и NTLM. Я не уверен в точной конфигурации сети (я не администратор сети), но может быть задействован прокси. К тому времени, когда проблема будет исследована администратором сети, учетная запись снова будет работать. Так же прерывисто. Мои вопросы по этому поводу:
1.) Кто-нибудь сталкивался с этим раньше?
2.) Решит ли это переход на обычную аутентификацию? Когда задействован прокси, раздаются короткие слухи о том, что NTLM искажает WSS.
3.) Совместимость SSL и IWA - это вообще перебор? Я имею в виду, что пароль и логин все равно будут отправляться зашифрованными в Basic Auth с SSL, верно? И преимущества IWA в экстранете вне домена кажутся мне бесполезными.
Если бы это был Kerberos, я бы ожидал увидеть переговоры (или я ошибаюсь?)
Вести переговоры можно с помощью kerberos или ntlm. ntlm определенно означает ntlm.
Чтобы подтвердить используемый метод аутентификации, проверьте первый символ заголовка аутентификации. Если это буква "Т", это ntlm. Если это "Y", это kerberos.
http://support.microsoft.com/kb/891032
Обратите внимание, что вы можете настроить IIS так, чтобы он требовал NTLM, но это не работает наоборот (требуется Kerberos). Хотя было бы неплохо.
SSL не является излишним, если вам нужно зашифровать контент. Kerberos без SSL достаточно безопасен для аутентификации, но не шифрует контент.
Что вы подразумеваете под «локальными» учетными записями? У вас есть автономный / не являющийся доменом сервер sharepoint в экстрасети, и пользователи входят в систему с недоменными / локальными учетными записями?
Было бы хорошо проверить файлы журналов IIS, чтобы увидеть, есть ли шаблон - это конкретные ресурсы, получающие 401, или это общий.
Обычная проблема заключается в том, что определенные ресурсы могут находиться в папке сервера (файловой системы), и они могут быть недоступны для всех пользователей. На эти ресурсы можно ссылаться только с определенных страниц, поэтому ошибки могут возникать периодически. Помните, что по умолчанию SharePoint выполняет запросы в олицетворенном контексте.
Вот в чем дело. Sharepoint использует выдачу себя за другое лицо. Это означает, что вам НЕ следует использовать NTLM вообще - вы должны использовать Kerberos. Это очень большая разница. NTLM не означает «встроенная проверка подлинности Windows».
Итак, вот что вам нужно сделать. Перейдите на сервер Sharepoint под журналом событий безопасности. Там вы должны увидеть, что все ваши пользователи проходят аутентификацию с использованием «Kerberos», а не «NTLMSSP». Если вы видите, что людям предоставляется доступ с использованием NTLM, это, вероятно, означает (я бы сказал, в 80% случаев), что вам необходимо определить имя участника-службы для Sharepoint. Если вы запускаете свой сайт sharepoint под псевдонимом, вам нужно будет также установить имя участника-службы для этого псевдонима, потому что IE7 имеет ошибку в нем, когда он периодически запрашивает билеты для неправильных SPN.
Итак, мои три совета:
Есть ряд случаев, когда NTLM auth блокируется через прокси - хотя я надеюсь, что большинство прокси уже исправили это поведение.
Я бы хотел убедиться, что ваш сайт WSS настроен как надежный сайт / интрасеть, а настройки вашего браузера таковы, что учетные данные для аутентификации передаются автоматически. Возможно, это помогло бы, если бы он действительно находился в домене, но похоже, что это не так.
Вы всегда можете вернуться к базовой аутентификации, но обязательно используйте SSL, если вы идете по этому пути.