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

Posted on 03.09.2017 | Оставьте комментарий

Протокол аутентификации 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

При запросе доступа к сервису вводится понятие название службы (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 следует прописать в доменной учетной записи компьютера, во втором — пользователя.

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

  1. Используется три компьютера:
    dc.example.org — контроллер домена EXAMPLE.ORG
    iis.example.org — веб сервер IIS
    win10.example.org — клиент с установленным Chrome.
  2. Все машины введены в домен
  3. Создана DNS запись тестового веб-сайта на котроллере домена
    website.example.org
  4. Создан доменный пользователь, который будет подключаться к сайту
    win10user
  5. Создан доменный пользователь, под которым будет запускаться IIS AppPool
    iisapppool
  6. Создан сайт в IIS со страницей default.aspx взятой отсюда.
  7. Создана привязка сайта (binding) для iis.example.org и website.example.org
  8. Включаена Windows аутентификация в IIS с провайдерами Negotiate и NTLM
  9. Устанавлен пользователь iisapppool для запуска IIS AppPool
  10. Настроена Windows аутентификация, включена аутентификация ядра и учетной записи AppPool 
    system.webServer/security/authentication/windowsAuthentication
useAppPoolCredentials true
useKernelMode true

  11. Даны пользователю iisapppool права на папку с сайтом
  12. На клиенте в Internet Explorer включены в список доверенных сайтов iis.example.org и website.example.org. И включаем автоматический вход под текущим пользователем
  13. На клиенте добавляем в hosts записи iis.example.org и website.example.org

Тесты.

  1. Аутентификация в обычном режиме провайдеры 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.kraftvaerk.com

    Контроллер домена отвечает TGS REP

    Клиент подключается с HTTP заголовком Authorization: Negotiate

    Сервер отвечает с HTTP заголовком WWW-Authenticate: Negotiate

    ВЫВОД:

    • клиент подключается к контроллеру домена;
    • клиент передает свои аутентифицированные данные контроллеру домена;
    • сервер подключается к контроллеру домена
  2. Аутентификация в обычном режиме провайдер 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).
  3. Аутентификация с отсутствующим SPN
    Клиент подключается к сайту website.example.org
    Клиент подключается к контроллеру домена TGS REQ для HTTP/website.example.org
    Контроллер домена отвечает KRB ERR SPN UNKOWN

    Клиент подключается с HTTP заголовком Authorization: NTLM включающим NTLMSSP_NEGOTIATE

    Происходит аутентификация NTLM
    ВЫВОД:

    • аутентификация Kerberos требует наличия корректного SPN на контрлере домена;
    • без SPN происходит автоматическое переключение на NTLM.
  4. Аутентификация с нестандартным портом
    Сервер IIS запущен на порту 8080.
    Клиент подключается к сайту iis.example.org:8080
    Клиент подключается к контроллеру домена TGS REQ для HTTP/iis.kraftvaerk.com
    Происходит аутентификация Kerberos
    ВЫВОД:

    • веб-браузер запрашивает SPN без номера порта;
    • для аутентификации Kerberos на веб-сервере не обязательно указывать порт в SPN учетной записи, под которой запущен веб-сайт;
    • другие протоколы могут указывать порт в запросе SPN.
  5. Аутентификация с пользователем IIS AppPool
    Сервер переключен IIS AppPool с использования iisapppool на Network Service
    Клиент подключается к сайту iis.example.org
    Происходит аутентификация Kerberos
    Сервер переключен с использования Network Service на iisappool
    У iisapppool убраны все SPN
    Клиент подключается к сайту iis.example.org
    Клиент подключается к контроллеру домена TGS REQ для HTTP/iis.kraftvaerk.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.
  6. Аутентификация с ограниченным доступом и провайдеры 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 не работает.
  7. Аутентификация с ограниченным доступом и провайдер 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.
  8. Аутентификация с клиента в рабочей группе
    Сервер включен с 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 (для доступа к другим доменным ресурсам без запроса пароля) и для входа на рабочую станцию при недоступном контроллере домена. Если у атакующего получится расшифровать кеш учетной записи, то он получит ее хеш пароля. Существует групповая политика, чтобы указать, сколько последних зашедших пользователей кешировать. Сам кеш не имеет срока истечения и остается рабочим до того момента, пока рабочая станция не соединиться с контроллером домена.

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

Реклама
Запись опубликована в рубрике Cтатьи с метками , . Добавьте в закладки постоянную ссылку.

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Gravatar
Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. ( Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. ( Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. ( Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. ( Выход /  Изменить )

Отмена

Connecting to %s