Пошаговая инструкция по настройке на веб-сайте IIS на Windows Server 2012 R2 прозрачной авторизации доменных пользователей в режиме SSO (Single Sign-On) по протоколу Kerberos.
На веб сервере запустите консоль IIS Manager, выберите нужный сайт и откройте раздел Authentication. Как вы видите, по умолчанию разрешена только анонимная аутентификация (Anonymous Authentication). Отключаем ее и включаем Windows Authentication (IIS всегда сначала пытается выполнить анонимную аутентификацию).
Открываем список провайдеров, доступных для Windows аутентификации (Providers). По умолчанию доступны два провайдера: Negotiate и NTLM. Negotiate – это контейнер, который в качестве первого метода проверки подлинности использует Kerberos, если эта аутентификация не удается, используется NTLM. Необходимо, чтобы в списке провайдеров метод Negotiate стоял первым.
Следующий этап – регистрация Service Principal Name (SPN) записей для имени сайта, к которому будут обращаться пользователи. В том случае, если сайт IIS должен быть доступен только по имени сервера, на котором он расположен (http://server-name или http://server-name.contoso.com), создавать дополнительные SPN записи не нужно (SPN записи уже имеются в учетной записи сервера в AD). При использовании адреса сайта, отличного от имени хоста, или при построении веб-фермы с балансировкой, придется привязывать дополнительные записи SPN к учётной записи сервера или пользователя.
Предположим, у нас имеется ферма IIS серверов. В этом случае оптимально создать отдельную учетную запись в AD и привязать SPN записи к ней. Из-под этой же учетной записи будут запускать целевой Application Pool нашего сайта.
Создадим доменную учетную запись iis_service. Убедимся, что SPN записи для этого объекта не назначены (атрибут servicePrincipalName пустой).
Предположим, что сайт должен отвечать по адресам _http://webportal and _http://webportal.contoso.loc. Мы должны прописать эти адреса в SPN атрибут служебной учетной записи
Setspn /s HTTP/webportal contoso\iis_service
Setspn /s HTTP/webportal.contoso.loc contoso\iis_service
Таким образом, мы разрешим этой учетной записи расшифровывать тикеты Kerberos при обращении пользователей к данным адресам и аутентифицировать сессии.
Проверить настройки SPN у учетной записи можно так:
setspn /l iis_service
setspn –x
Следующий этап – настройка в IIS Application Pool для запуска из-под созданной сервисной учетной записи.
Выберите Application Pool сайта (в нашем примере это DefaultAppPool).
Откройте раздел настроек Advanced Settings и перейдите к параметру Identity.
Измените его с ApplicationPoolIdentity на contoso\iis_service.
Затем в консоли IIS Manager перейдите на свой сайт и выберите секцию Configuration Editor.
В выпадающем меню перейдите в раздел system.webServer > security > authentication > windowsAuthentication
Измените useAppPoolCredentials на True.
Тем самым мы разрешим IIS использовать доменную учетку для расшифровки билетов Kerberos от клиентов.
Перезапустим IIS командой:
iisreset
Аналогичную настройку нужно выполнить на всех серверах веб-фермы.
Протестируем работу Kerberos авторизации, открыв в браузере клиента (браузер нужно предварительно настроить для использования Kerberos) адрес _http://webportal.contoso.loc

Убедится, что для авторизации на сайте используется Kerberos можно с помощью инспектирования HTTP трафика утилитой Fiddler.
Запускаем Fiddler, в браузере открываем целевой сайт. В левом окне находим строку обращения к сайте. Справа переходим на вкладку Inspectors. Строка Authorization Header (Negotiate) appears to contain a Kerberos ticket, говорит о том, что для авторизации на IIS сайте использовался протокол Kerberos.
В каких группах должна состоять учётка iis_service
Учетка должна быть как минимум в группе Domain Users
добрый день
немного не в тему вопрос, но похож.
Есть у нас ПО в котором для входа пользователя используется сквозная доменная авторизация.
Все работает, но только если пользователь состоит в стандартном OU USERS.
Стоит его переместить в другую OU и все приехали, ни сквозной ни даже по логину паролю.
Понимаю что вопрос простой, но по неопытности не хватает понимания.
Смотрите какие групповые политики навешаны на OU Users, одна из них разрешает SSO.
Соответсвенно, на другую OU она не применяется. Нужно разобраться и залинковать
Добрый день!
Все вышеуказанные настройки сделаны.
Но аутентификация не проходит,
Fiddler пишет: «No Authorization Header is present.»
В чем может быть проблема?
Получается в заголовке нет инфомации об авторизации. Т.е. возможно связано браузером и с реализацией самого web приложения?
С каким приложением играетесь?
Попробуйте настроить kerberos авторизацию для простой статической страницы (сайта) на IIS и Internet Explorer.
Играюсь с сервером 1C и IIS 🙂
Есть отдельный сервер IIS, есть отдельный сервер 1С. На IIS настроена Windows аутентификация.
В AD серверу IIS включены делегирование kerberos.
Далее, когда переходим внутри сети по адресу сервера http :// сервер01, windows auth пробрасывается до сервера 1С, аутентификация проходит.
Далее, когда переходим по веб адресу https :// веб-адрес. домен. ру, IIS запрашивает имя пользователя/пароль.
Если ввести корректные имя пользователя/пароль, то пускает дальше, но до 1С не пробрасывается имя пользователя.
Следующим шагом настроили в пуле приложений удостоверение от доменного пользователя.
которому так же через setspn прописали значения в атрибут «servicePrincipalName» https :// веб-адрес. домен. ру.
Т.е. через setspn все заработало?
имеется такая же проблема. у вас получилось победить? если да. подскажите куда копать.
Добрый день!
Удалось ли решить проблему? Сейчас столкнулся с похожей.
Есть ферма серверов из 3х штук: для IIS и один с контроллером фермы. Если обращаться в контроллеру по http, то сквозная авторизация работает. Если по HTTPS — то запрашивает логин\пароль
Такая же проблема, как решили, если решили?)
Нет, после проведенных настроек все осталось по прежнему.
Покажите все записи для вашего сервера:
Setspn –l servernamr1
)))У меня работает, только в IE, но не в хроме
проделал всё по статье, с самого сервера где установлен IIS авторизация проходит. и фидлер показывает что авторизация идёт по протоколу kerberos. но вот если я пытаюсь из другой сети войти на сайт, то там уже почему то вот это вижу я: No Proxy-Authorization Header is present.
Authorization Header is present: Negotiate
4E 54 4C 4D 53 53 50 00 03 00 00 00 18 00 18 00 NTLMSSP
не подскажите в чем причина может быть? всю голову сломал
Из другой сети…. т.е. компьютер в другом домене, доверительных отношений с вашим AD нет? В этом случае вы идете на сайт по NTLM, не по Kerberos.
внешний веб сервер находится в сети 10.*.*.* а AD в сети 192.168. (домен не другой) всё в пределах одного домена. если проверять сквозную аутентификацию с самого сервера IIS всё работает отлично. но если пробовать с другой машины подключиться к серверу то сквозная аутентификация не проходит. и да это тоже 1с((
спасибо, вопрос решен. всё работало. это просто 1С)))
Получается из другой сети нет возможности в аутентификации по Kerberos?
Слышал такое понятие, как double hop. Это не про эту ситуацию?
double hop это вроде про ситуацию с двумя сетевыми интерфейсами на неком сервере-шлюзе в двух сетях.
В обычном домене. пусть даже и построенном на разных сетях (без NAT), kerberos должен работать.
Кстати время на сервере и клиенте совпадает? расхождение должно быть не более 5 минут.
Здравствуйте, подскажите пожалуйста, какие порты должны быть открыты на сервере IIS для того чтобы работала kerberos авторизация пользователей на сайте?
От пользователей достаточно открыть 80/443 порт TCP
А что будет если Анонимная авторизация не будет отключена?
Можно ли сделать так что сначала была попытка доменной по керберос, и в случае неудачи, разрешалась анонимная?
Вот нашел в документации что в IIS сначала будет исопользоваться анонимная аутентфикация (_https://learn.microsoft.com/en-us/previous-versions/commerce-server/ee825205(v=cs.10)?redirectedfrom=MSDN)
If Anonymous authentication is enabled, IIS will always try to authenticate using it first, even if other methods are enabled.
Там хоть статья довольно старая, но не думаю что подход изменился.
Kerberos это не авторизация, а аутентификация. Это не одно и тоже.
Привет! А зачем регистрировать SPN для имени сайта? Керберос на сайтах IIS и так работает же по умолчанию в рамках домена, достаточно включить в IIS — Windows Authentication.