Исследуем аутентификацию в IIS

Протокол аутентификации Kerberos уже затрагивался в этом блоге ранее. В этом посте пойдет речь про аутентификацию

Kerberos
NTLM
Negotiate

в веб-сервере IIS. Будет проверено на практике какой протокол аутентификации используется в том или ином случае. Для этого будет проведен несколько тестов в каждом из которых будет сделан вывод. Все выводы можно прочитать в конце поста.

Kerberos

Начнем с общего описания аутентификации Kerberos.

Пользователь заходит на рабочую станцию (клиент) в домене. Для аутентификации клиент связывается с центром выдачи ключей (key distribution center, KDC), для Windows это контроллер домена.
Контроллер домена проверяет, что логин и хеш пароля, введенные пользователем, совпадают с хранящимися в базе KDC. Если учетные данные корректны, центр выдает удостоверение (ticket-granting ticket, TGT), подписанное особенным доменным пользователем krbtgt. TGT используется для подтверждения, что пользователь прошел аутентификацию.
После этого пользователь подключается к какому-либо ресурсу в домене, например, общей папке на файловом сервере.
Клиент обращается к KDC, прилагая TGT, за выдачей удостоверения запрашиваемого сервиса (service ticket, TGS).
Контроллер домена проверяет, что такой сервис совпадает с хранящимся в базе KDC и выдает клиенту TGS.
После этого клиент обращается к файловому серверу, прилагая TGS.
Файловый сервер видит, что TGS выдан контроллером домена и принимает подключение пользователя.

Процесс показан на рисунке

Подключившись доменным пользователем можно вывести как TGT:

klist tgt

Так и TGS:

klist

SPN

При запросе доступа к сервису вводится понятие название службы (service principal name, SPN). SPN позволяет клиенту однозначно указать к какому сервису запрашивает доступ пользователь. Название уникально в рамках леса.

Таким образом при обращении к сервису клиент включает TGS, для того, чтобы сервис увидел, что пользователь получил разрешение от KDC. Получив ответ от сервиса, пользователь удостоверяется, что сервис работает под учетной записью ассоциированной с SPN, потому что он смог расшифровать TGS.

Существуют два вида SPN:

по имени компьютера
пользователя.

Когда компьютер вводится в домен Active Directory, его учетной записи присваивается стандартный список SPN.

Шаблон SPN:

<Название сервиса>/<Имя Компьютера>:<Порт>

Существует особый вид компьютерной службы HOST. Он включает себя несколько сервисов, например, HTTP.

Таким образом при доступе к веб сайту на компьютере iis.example.org

пользователь запрашивает SPN с названием http/iis.example.org у KDC.
Соединяясь с веб сайтом, клиент показывает TGS.
Поскольку сервер доверяет центру, он доверяет удостоверениям, выданным центром.

Напрямую между веб сайтом и пользователем обмен паролем в открытом или зашифрованном виде не происходит. Для прохождения аутентификации Kerberos необходимо чтобы у компьютера пользователя и веб сервера была связь с контроллером домена.

В рамках настройки IIS, сайт (а точнее AppPool) может запускаться от локальной записи (например, Network Service) или от доменной учетной записи пользователя. В первом случае SPN следует прописать в доменной учетной записи компьютера, во втором - пользователя.

Подготовка к тестам.

Используется три компьютера: dc.example.org - контроллер домена EXAMPLE.ORG iis.example.org - веб сервер IIS win10.example.org - клиент с установленным Chrome.
Все машины введены в домен
Создана DNS запись тестового веб-сайта на котроллере домена website.example.org
Создан доменный пользователь, который будет подключаться к сайту win10user
Создан доменный пользователь, под которым будет запускаться IIS AppPool iisapppool
Создан сайт в IIS со страницей default.aspx взятой отсюда.
Создана привязка сайта (binding) для iis.example.org и website.example.org
Включаена Windows аутентификация в IIS с провайдерами Negotiate и NTLM
Устанавлен пользователь iisapppool для запуска IIS AppPool
Настроена Windows аутентификация, включена аутентификация ядра и учетной записи AppPool
```
system.webServer/security/authentication/windowsAuthentication
useAppPoolCredentials true
useKernelMode true
```
Даны пользователю iisapppool права на папку с сайтом
На клиенте в Internet Explorer включены в список доверенных сайтов iis.example.org и website.example.org. И включаем автоматический вход под текущим пользователем
На клиенте добавляем в hosts записи iis.example.org и website.example.org

Тесты.

Аутентификация в обычном режиме провайдеры Negotiate, NTLM

Сервер включен с Windows аутентификацией с провайдерами Negotiate и NTLM
Клиент в домене Клиент имеет полную связь с контроллером домена и веб сервером
Клиент подключается к сайту iis.example.org Сервер подключается к контроллеру домена на порт TCP 88 AS REQ для iisapppool
Контроллер домена отвечает PREAUTH REQUIRED
Сервер подключается к контроллеру домена AS REQ для iisapppool
Контроллер домена отвечает AS REP
Сервер подключается к контроллеру домена TGS REQ для HOST/iis.example.org
Контроллер домена отвечает TGS REP
Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate, NTLM
Клиент подключается к контроллеру домена на порт TCP 88 AS REQ для win10user
Контроллер домена отвечает PREAUTH REQUIRED
Клиент подключается к контроллеру домена AS REQ для win10user
Контроллер домена отвечает AS REP
Клиент подключается к контроллеру домена TGS REQ для HTTP/iis.example.com
Контроллер домена отвечает TGS REP
Клиент подключается с HTTP заголовком Authorization: Negotiate
Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate

ВЫВОД

клиент подключается к контроллеру домена;
клиент передает свои аутентифицированные данные контроллеру домена;
сервер подключается к контроллеру домена

Аутентификация в обычном режиме провайдер NTLM

Север включен с Windows аутентификацией с провайдером NTLM Клиент подключается к сайту iis.example.org Сервер отвечает с HTTP заголовком WWW-Authenticate: NTLM
Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE
Сервер отвечает с HTTP заголовком WWW-Authenticate: NTLM включающим NTLMSSP_CHALLENGE
Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_AUTH
Сервер подключается к контроллеру домена NetrLogonSamLogonEx
Контроллер домена отвечает NetrLogonSamLogonEx
Сервер отвечает с HTTP кодом 200

ВЫВОД:

- клиент не подключается к контроллеру домена;
- клиент передает свои аутентификационные данные серверу;
- сервер подключается к контроллеру домена и аутентифицирует пользователя (`Pass-Through Authentication`).

Аутентификация с отсутствующим SPN

Клиент подключается к сайту website.example.org Клиент подключается к контроллеру домена TGS REQ для HTTP/website.example.org
Контроллер домена отвечает `KRB ERR SPN UNKOWN
Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE
Происходит аутентификация NTLM

ВЫВОД:

- аутентификация Kerberos требует наличия корректного SPN на контрлере домена;
- без SPN происходит автоматическое переключение на NTLM.

Аутентификация с нестандартным портом

Сервер IIS запущен на порту 8080.
Клиент подключается к сайту iis.example.org:8080
Клиент подключается к контроллеру домена TGS REQ для HTTP/iis.example.com
Происходит аутентификация Kerberos

ВЫВОД:

- веб-браузер запрашивает SPN без номера порта;
- для аутентификации Kerberos на веб-сервере не обязательно указывать порт в SPN учетной записи, под которой запущен веб-сайт;
- другие протоколы могут указывать порт в запросе SPN.

Аутентификация с пользователем IIS AppPool

Сервер переключен IIS AppPool с использования iisapppool на Network Service
Клиент подключается к сайту iis.example.org
Происходит аутентификация Kerberos
Сервер переключен с использования Network Service на iisappool
У iisapppool убраны все SPN
Клиент подключается к сайту iis.example.org
Клиент подключается к контроллеру домена TGS REQ для HTTP/iis.example.com
Контроллер домена отвечает TGS REP
Клиент подключается с HTTP заголовком Authorization: Negotiate
Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate KRB ERR MODIFIED
Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE

ВЫВОД:

- клиенту без разницы под какой учетной записью запущен веб-сайт; 
- для Kerberos аутентификации важно чтобы у учетной записи веб-сайта был установлен SPN;
- по умолчанию у учетной записи компьютера есть HOST SPN;
- HOST SPN включает в себя несколько сервисов;
- HTTP покрывается HOST SPN;
- запрашивая HTTP SPN клиент получает TGS от компьютерной учетной записи;
- если на контроллере домена существует учетная запись с `HTTP` SPN на то же имя, TGS отправляется от этой учетной записи;
- получив ответ `Kerberos Error` клиент автоматически переключается на NTLM.

Аутентификация с ограниченным доступом и провайдеры Negotiate, NTLM

Клиент имеет связь только с веб сервером по порту 80
Сервер включен с Windows аутентификацией с провайдерами Negotiate и NTLM
Клиент подключается к сайту iis.example.org
Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate, NTLM
Клиент запрашивает DNS SRV запись _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.EXAMPLE.ORG
Клиент не получает ответ Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE Происходит аутентификация NTLM

ВЫВОД:

при ограниченном соединении аутентификация Kerberos не работает.

Аутентификация с ограниченным доступом и провайдер Negotiate

Клиент имеет связь только с веб сервером по порту 80
Сервер включен с Windows аутентификацией с провайдером Negotiate
Клиент подключается к сайту iis.example.org
Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate
Клиент запрашивает DNS SRV запись _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.EXAMPLE.ORG
Клиент не получает ответ Клиент показывает в браузере HTTP ошибку с кодом 401 Unauthorized

ВЫВОД:

- Провайдер Negotiate включает в себя два протокола: Kerberos и NTLM;
- получив ответ WWW-Authenticate Negotiate клиент сначала пробует Kerberos, затем NTLM;
- не получив никакого ответа Kerberos клиент не переключается на NTLM.

Аутентификация с клиента в рабочей группе

Сервер включен с Windows аутентификацией с провайдерами Negotiate и NTLM
Клиент в рабочей группе
Клиент имеет полную связь с контроллером домена и веб сервером
Клиент подключается к сайту iis.example.org
Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate, NTLM
Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE

ВЫВОД

если клиент не в домене, то используется NTLM аутентификация.

Выводы:

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