Как сказал @Michael Levy, это проблема двойного прыжка. Это означает, что до тех пор, пока вы не настроите Kerberos (Negotiate), NTLM, вероятно, будет использоваться в среде Windows, в которой работает IIS, при этом клиент с браузером на компьютере A, пытающийся получить доступ к веб-сайту на компьютере B, будет иметь доступ к сайту, НО, когда сайт попытается связаться со службой на компьютере C, вместо этого следует использовать учетные данные пула.
То же самое относится и к веб-сайту A, вызывающему услугу B, которая, в свою очередь, вызывает услугу C.
При настройке Kerberos для веб-сайтов необходимо учитывать несколько факторов. Во-первых, нужно знать, ферма это или нет. Если это так, вы должны определить общего пользователя для пула для всех машин, входящих в ферму. Это необходимо, потому что Kerberos использует доменное имя для идентификации принципала, используемого для шифрования токенов безопасности. Если у вас есть разные пользователи на разных компьютерах одной фермы, так как все они будут доступны через одно и то же доменное имя, все запросы будут искать та же запись. Более подробную информацию можно найти здесь на Kerberos и балансировке нагрузки .
Например, скажем, у вас есть сайт с myApp.intranet в качестве URL. В AD вы должны иметь имя участника-службы, скажем, myUser в домене MyDomain (setspn -S MyDomain \ myUser HTTP / myapp.intranet). Когда запрос отправляется в KDN (см. Ссылки Kerberos в конце для получения дополнительной информации о KDN), он всегда будет возвращать токен, зашифрованный с помощью myUser, но IIS будет пытаться расшифровать его другими пользователями. Может быть заманчиво создать несколько SPN для одной и той же службы (HTTP / myapp.intranet), но это приведет к ошибке KRB.
Кроме того, если вы работаете в IIS 7+, вам нужно будет указать немного деталей в своем ApplicationHost.config, если вы хотите оставить аутентификацию в режиме ядра включенной (что настоятельно рекомендуется): useAppPoolCredentials = верно. Это значение должно быть установлено в файле configuration \ system.webServer \ security \ authentication \ windowsAuthentication. Это связано с тем, что по умолчанию аутентификация в режиме ядра будет использовать учетную запись компьютера , а не учетную запись пула, и это вернет нас к многопользовательскому сценарию.
Во всех случаях Доверяйте этому пользователю для ... вкладки Делегирование субъекта AD должно быть разрешено для работы делегирования. Затем вы должны решить, хотите ли вы использовать общее или ограниченное делегирование.
Как я уже говорил ранее, вам также нужно установить имя участника-службы для подходящего пользователя и нужного сервиса. Пользователь довольно легко определить, так как это будет тот, который вы определили для своего пула, но служба может быть немного хитрой в зависимости от вашей конфигурации. DNS, браузер и, возможно, другие переменные могут изменить то, что следует использовать. Наши испытания и ошибки показали следующее:
- Если ваша DNS-запись является записью A, вы используете ее напрямую
- Если ваша запись является CName, в наших тестах использовалась связанная с ней запись A
- У нас были случаи, когда использовалось CName, и оно, похоже, было связано с версией браузера.
Обратите внимание, что если имя SPN не задано и вы обращаетесь к своему веб-сайту через имя NetBIOS, будет запрошена служба HTTP / машина, и по умолчанию служба HOST (поиск дополнительных) может быть используется вместо HTTP, поэтому будет использоваться HOST / machine. Это может быть полезно для простой настройки в небольшой сети.
Также следует иметь в виду, что если вы хотите ограничить время простоя при переходе от NTLM к Kerberos, вам следует сначала изменить ApplicationHost, а затем использовать SetSPN. Вы также можете отключить согласование перед любым действием и оставить только NTLM, пока все не будет настроено, а затем, если возможно, включить только согласование (без NTLM). Это должно заставить клиентов изменить способ доступа к вашему веб-сайту. Если вы этого не сделаете, механизм кэширования, похоже, будет некоторое время поддерживать NTLM.
Надеясь, что это может помочь. Если вам все еще не удается настроить Kerberos, WireShark - ваш самый верный друг Вы можете найти информацию о том, как отлаживать Kerberos, на следующих страницах:
- Отладка Kerberos для веб-сайта
- Отладка проблем AD с Kerberos (одним из них является максимальный размер токена)
- Kerberos инструменты и другие ссылки
- Общий захват сети Отладка Kerberos