Назад | Перейти на главную страницу

IE HTTP Kerberos выдает проблемы с аутентификацией на сайте с полным доменным именем, не соответствующим домену AD

У меня есть сайт в корпоративном домене, который отлично проходит проверку подлинности с использованием автоматического входа в систему Kerberos из IE и Chrome, если DNS, используемый для доступа к нему, попадает под полное доменное имя AD.

Домен AD не является общедоступным, в этом примере можно назвать его company.internal.corp.net. Стандартное имя участника-службы настраивается с учетной записью пользователя домена IIS, например HTTP / somesite.company.internal.corp.net mycompany \ svc_iis, и IE настроен на просмотр этого сайта как сайта интрасети (с возможностью автоматического входа)

FQ AD Domain: company.internal.corp.net
NETBIOS domain name: MYCOMPANY
DNS for my website: somesite.company.internal.corp.net
IIS App Pool account: MYCOMPANY\svc_iis
SPN: HTTP/somesite.company.internal.corp.net MYCOMPANY\svc_iis

Я решил изменить DNS для этого сайта на другое имя somesite.mycompanypublic.com чтобы воспользоваться цепочкой сертификатов SSL на моем общедоступном сертификате. Я не планирую делать сайт доступным для внешних пользователей. Запись DNS будет указывать на тот же сервер только для внутреннего разрешения и доступа, а IE настроен на просмотр этого сайта как сайта интрасети (с возможностью автоматического входа). Итак, теперь у меня есть такая настройка:

FQ AD Domain: company.internal.corp.net
NETBIOS domain name: MYCOMPANY
DNS for my website: somesite.mycompanypublic.com  <-- new DNS name, not same as AD domain
IIS App Pool account: MYCOMPANY\svc_iis
SPN: HTTP/somesite.mycompanypublic.com MYCOMPANY\svc_iis  <-- new DNS name, not same as AD domain

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

После настройки, как указано выше, Kerberos больше не работает. IE запрашивает имя пользователя / пароль для NTLM, Chrome иногда запрашивает, а часто просто получает страницу сбоя. Трассировки Fiddler показывают, что билеты Kerberos проходят, но сервер отклоняет каждый раз с очередным 401 каждый раз. IE является настроен для просмотра этого сайта как сайта интрасети (с возможностью автоматического входа), так что проблема не в этом - я вижу, как проходят билеты.

Эта конфигурация поддерживается? Идеи по устранению неполадок?

Он ведет себя так, как будто SPN настроен неправильно. При желании я могу предоставить следы скрипачей или колпачки wirehark.

Имя участника-службы не обязательно должно соответствовать домену AD. У вас должно быть SPN, соответствующее имени, используемому для подключения. Я не совсем понимаю, что вы имеете в виду под «прохождением билетов Kerberos». Заголовок авторизации HTTP должен начинаться с «Negotiate Y», если на сервер передаются учетные данные Kerberos.

Вероятно, самый быстрый способ сделать это - настроить инструмент DelegConfig и использовать отчет / мастер для проверки вашей конфигурации.

http://blogs.msdn.com/b/chaun/archive/2013/09/15/some-tips-on-setting-up-the-delegconfig-tool.aspx

http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx

Устранение неполадок ASP.NET
http://support.microsoft.com/kb/891032

Проблема не имела ничего общего с другим доменом. Вы можете использовать любой домен вообще, если IE правильно настроен для передачи билета, а SPN правильно настроен в AD. Ответ Грега предоставил мне несколько ссылок, которые я рекомендую вам изучить, если вы собираетесь сюда для решения проблемы с SPN.

Я обнаружил, что мне нужно отключить аутентификацию в режиме ядра, что также требует, чтобы я разблокировал этот раздел конфигурации. Я также обнаружил, что если DNS-запись для сайта является CNAME, Internet Explorer (но не Chrome) будет использовать имя хоста, на который указывает CNAME, при создании билета SPN.


Мне пришлось настроить сервер для использования учетных данных пула приложений как таковых

<system.webServer>
   <security>
      <authentication>
         <windowsAuthentication enabled="true" useAppPoolCredentials="true" />
      </authentication>
   </security>
</system.webServer>

Понимание и настройка режима ядра


Но для изменения этого блока конфигурации требовалось следующее:

Коллега указал мне на значок «Делегирование функций» на корневом (компьютерном) уровне диспетчера IIS (спасибо, Райан). При нажатии на страницу «Делегирование функций» отображается список функций и их текущие настройки переопределения. За некоторыми исключениями каждую из функций можно изменить на чтение / запись, только чтение или отсутствие делегирования.

Разблокировка разделов конфигурации