Я только что развернул новую интрасеть для всей компании - у компании есть 6 сайтов в Великобритании, у каждого есть локальный домен, называемый (например) london.local, derby.local, thatlotupnorth.local и т. Д. И т. Д., И у каждого есть свой собственный сервер AD. (Сайты подключены через MPLS через Virgin, но это должно быть прозрачно для проблемы)
Сервер интрасети (Server 2008 R2, IIS 7.5) основан, скажем, на london.local и использует аутентификацию Windows для аутентификации и доступа к сайту на сервере интрасети.
Это отлично работает на всех сайтах, кроме одного.
Дальнейшее расследование показывает, что пользователь, который является участником этого сайта, скажем derby.local, не может войти в свою учетную запись из другого домена, например, я создал учетную запись в домене derby.local и попытался войти в систему из Лондона. .local, я получаю сообщение об ошибке «В настоящее время нет серверов входа в систему, доступных для обслуживания входа в систему», что означает, что сервер AD недоступен, однако я МОГУ его пропинговать.
Я совершенно уверен, что причина аутентификации Windows в интрасети заключается в том, что сервер не может получить доступ к серверу AD на другом сайте.
nslookup сообщает, что один домен «несуществующий», все остальные серверы AD сообщают свои данные. Однако я могу пинговать derby.local.
любые указания о том, с чего начать поиск неисправностей, очень ценятся!
Если сайт находится в зоне надежных сайтов и эта зона настроена для «автоматического входа в систему с текущим именем пользователя и паролем», а IIS настроен с учетной записью пула приложений, которая может олицетворять пользователя, Internet Explorer должен иметь возможность представить токен аутентификации как часть заголовка HTTP-запроса и IIS для использования этого токена для аутентификации и авторизации.
Зона интрасети также может использоваться, если URL-адрес представляет собой одинарное / короткое имя.
Эта «интегрированная проверка подлинности», в отличие от запроса учетных данных (возможно, в виде обычного текста), обычно является предпочтительным механизмом проверки подлинности.
Один из способов определить, правильно ли он настроен, - это загрузить утилиту DelegConfig и добавить ее в качестве виртуального каталога на веб-сайт. Когда вы откроете ссылку на этот виртуальный каталог, он запустит несколько тестов и покажет, что, если что-то, может быть настроено неправильно.
Обычно для этого требуется, чтобы компьютер IIS был «доверенным для делегирования» на вкладке делегирования учетной записи компьютера, или, если пул приложений использует учетную запись домена, эта учетная запись должна быть доверенной таким же образом, хотя вкладка «Делегирование» не по умолчанию показывать для учетных записей пользователей, поэтому вам нужно будет использовать setspn.exe.
Иногда заголовок HTTP-запроса очень велик из-за членства в многих группах. Это потребует настройки параметра реестра IIS для MaxRequestBytes.
Параметры реестра Http.sys для IIS
http://support.microsoft.com/kb/820129
DelegConfig Скачать:
http://blogs.iis.net/brian-murphy-booth/archive/2009/04/22/delegconfig-v2-beta.aspx