Настройка Kerberos авторизации на сайте IIS | Windows для системных администраторов

Аутентификация в web-приложениях на примере internet explorer – портал технической поддержки

В данной статье рассмотрим способы аутентификации пользователей на различных web-ресурсах предприятия.
Скриншоты в статье будут c IE11 и IIS 8 (русскоязычные) и IE8/IIS7(англоязычные)

Вход по логину и паролю
Самый простой и очевидный способ. Прежде, чем дать доступ, сервер просит пользователя подтвердить себя:

http://cdn.indeed-id.com/community.indeed-id.com_screens/CM_Auth/CredRU_EN.png

Вводите логин и пароль пользователя, имеющего права доступа к приложению и выполняется вход в приложение.
Каждый раз вводить пароль (логин можно запомнить, поставив соответствующую галочку) не очень удобно. Следующий способ позволяет не вводить и пароль.

Вход без ввода логина и пароля
Если пароль вводить лень, значит нужно сделать так, чтобы он вводился сам. Вот как это делается:
В настройках IE открыть Свойства обозревателя -> Безопасность (Internet Options -> Secutiry). Выбираете зону, к которой принадлежит используемый сайт. Обычно это зона Интернета, но можно добавить сайт и в зону местной интрасети (Local intranet) или Надежных сайтов (Ttusted sites).

Все в той же вкладке Безопасность выбираем уровень безопасности для указанной зоны: Другой… (Custom Level…). В окне параметров безопасности в разделе Проверка подлинности пользователя (User Authentication) ставимАвтоматический вход в  сеть с текущим именем пользователя и паролем (Automatic logon with current user name and password):

http://cdn.indeed-id.com/community.indeed-id.com_screens/CM_Auth/AutomaticLogon_RU_EN.png
Сохраняем изменения. Теперь при входе на сайт запрос учетных данных появляться не будет.

Вход с использованием сертификата пользователя
Раз уж Indeed CM позволяет управлять устройствами аутентификации (смарт-картами, usb-ключами) и записывать на них сертификаты, то почему бы не аутентифицироваться по смарт-карте?

Для этого необходим настроенный SSL в IIS, где расположен сайт. Для аутентификации по смарт-карте необходимо в IIS выставить следующие настройки для приложений:

  • Сертификаты клиента: Принимать(Accept) или Требовать(Require).

Если используется Принимать, значит аутентификация может осуществляться как по вводу логина/пароля, так и по сертификату, если он предоставлен пользователем.

Похожее:  Детализация счета | Услуги частным клиентам | Официальный сайт МТС - Владивосток и Приморский край

Если используется Требовать, значит вход на сайт возможен только по сертификату пользователя и никак иначе:

http://cdn.indeed-id.com/community.indeed-id.com_screens/CM_Auth/IIS8_RU.png

http://cdn.indeed-id.com/community.indeed-id.com_screens/CM_Auth/IIS7_EN.png

Теперь необходимо настроить браузер для аутнетификации по карте. Добавьте сайт в зону местной интрасети, а в параметрах безопасности зоны укажите Автоматический вход в сеть только в зоне интрасети (Automatic logon only in Intranet zone)

Теперь, при входе на сайт, появится предложение использовать данные смарт-карты:

http://cdn.indeed-id.com/community.indeed-id.com_screens/CM_Auth/IE11_Smartcard.png

http://cdn.indeed-id.com/community.indeed-id.com_screens/CM_Auth/IE8_Smartcard.png

Настройка kerberos авторизации на сайте iis | windows для системных администраторов

Пошаговая инструкция по настройке на веб-сайте IIS на Windows Server 2022 R2 прозрачной авторизации доменных пользователей в режиме SSO (Single Sign-On) по протоколу Kerberos.

На веб сервере запустите консоль IIS Manager, выберите нужный сайт и откройте раздел Authentication. Как вы видите, по умолчанию разрешена только анонимная аутентификация (Anonymous Authentication). Отключаем ее и включаем Windows Authentication (IIS всегда сначала пытается выполнить анонимную аутентификацию).

IIS - Windows AuthenticationОткрываем список провайдеров, доступных для Windows аутентификации (Providers). По умолчанию доступны два провайдера: Negotiate и NTLM. Negotiate – это контейнер, который в качестве первого метода проверки подлинности использует Kerberos, если эта аутентификация не удается, используется NTLM. Необходимо, чтобы в списке провайдеров метод Negotiate стоял первым.

Провайдеры включаем Windows Authentication

Следующий этап – регистрация 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 пустой).

Пустой атрибут servicePrincipalName Предположим, что сайт должен отвечать по адресам _http://webportal and _http://webportal.contoso.loc. Мы должны прописать эти адреса в SPN атрибут служебной учетной записи

Setspn /s HTTP/webportal contosoiis_service
Setspn /s HTTP/webportal.contoso.loc contosoiis_service

Setspn /s HTTP/webportal.contoso.loc contosoiis_serviceТаким образом, мы разрешим этой учетной записи расшифровывать тикеты Kerberos при обращении пользователей к данным адресам и аутентифицировать сессии.

Проверить настройки SPN у учетной записи можно так:

setspn /l iis_service

setspn /l iis_service

Совет. Kerberos не будет работать корректно при наличии дублирующих SPN у разных записей домена. С помощью следующей команды, убедитесь, что дубликатов SPN в домене нет:
setspn –x

Следующий этап – настройка в IIS Application Pool для запуска из-под созданной сервисной учетной записи.

Выберите Application Pool сайта (в нашем примере это DefaultAppPool).

DefaultAppPoolОткройте раздел настроек Advanced Settings и перейдите к параметру Identity.

Расширенные настройки пула IISИзмените его с ApplicationPoolIdentity на contosoiis_service.

identity

Затем в консоли IIS Manager перейдите на свой сайт и выберите секцию Configuration Editor.

В выпадающем меню перейдите в раздел system.webServer > security > authentication > windowsAuthentication

useAppPoolCredentials

Измените useAppPoolCredentials на True.

Тем самым мы разрешим IIS использовать доменную учетку для расшифровки билетов Kerberos от клиентов.

Перезапустим IIS командой:

iisreset

iisresetАналогичную настройку нужно выполнить на всех серверах веб-фермы.

Протестируем работу Kerberos авторизации, открыв в браузере клиента (браузер нужно предварительно настроить для использования Kerberos) адрес _http://webportal.contoso.loc

Убедится, что для авторизации на сайте используется Kerberos можно с помощью инспектирования HTTP трафика утилитой Fiddler.

Запускаем Fiddler, в браузере открываем целевой сайт. В левом окне находим строку обращения к сайте. Справа переходим на вкладку Inspectors. Строка Authorization Header (Negotiate) appears to contain a Kerberos ticket, говорит о том, что для авторизации на IIS сайте использовался протокол Kerberos.

Похожее:  Личный кабинет Ваш репетитор: официальный сайт

Authorization Header (Negotiate) appears to contain a Kerberos ticket

Выводы:

  • При аутентификации Negotiate:
    сначала используется протокол Kerberos
    используется протокол NTLM, если Kerberos возвращает ошибку
    проваливается аутентификация при недоступности контроллера домена.
  • При аутентификации Kerberos:
    аутентификационные данные между веб сервером и клиентом не передаются
    требуется подключение клиента и веб сервера к контроллеру домена
    требуется наличие корректного SPN у учетной записи, под которой работает веб сервер
    SPN не требует включения порта для веб сервера
    SPN может требовать включение порта для других сервисов.
  • При аутентификации NTLM:
    аутентификационные данные передаются от клиента к веб серверу
    не требуется подключение клиента к контроллеру домена.
  • Если клиент не в домене, то используется NTLM аутентификация.
  • При использовании NTLM протокола учетные данные в зашифрованном виде передаются напрямую между сервером и клиентом. Поскольку NTLM хранит хешированные пароли на сервере, то завладев хешем пароля, можно аутентифицироваться на других серверах не зная самого пароля:
    • Если используется локальная учетная запись, то хеш пароля храниться на локальной машине.
    • Если используется доменная учетная запись, то хеш пароля храниться на контроллере домена. Однако, если зайти на клиент под доменной учетной записью, ее аутентифицированные данные закешируются. Этот кеш используется для механизма Single Sign-On (для доступа к другим доменным ресурсам без запроса пароля) и для входа на рабочую станцию при недоступном контроллере домена. Если у атакующего получится расшифровать кеш учетной записи, то он получит ее хеш пароля. Существует групповая политика, чтобы указать, сколько последних зашедших пользователей кешировать. Сам кеш не имеет срока истечения и остается рабочим до того момента, пока рабочая станция не соединиться с контроллером домена.

Источник 1Источник 2Источник 3Источник 4Источник 5Источник 6Источник 7Источник 8Источник 9Источник 10Источник 11Источник 12Источник 13

Поддержать блог

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 4,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector