Как HTTP-запросы работают с Active Directory?

Question

У меня есть приложение ASP.NET MVC, которое аутентифицирует пользователей в Active Directory.

Насколько я понимаю, этот процесс происходит, когда пользователь входит в систему на своем компьютере:

1. Пользователь вводит учетные данные на локальном компьютере.

2. Локальный компьютер проверяет, есть ли у него уже билет проверки подлинности для этих учетных данных.

3. Еслинет, он связывается с первым сервером ADS, который может найти, который предлагает функции аутентификации kerberos

4. Машина ADS проверяет учетные данные в базе данных LDAP.

5. Если они проверяют, kerberos возвращает TGT (билет на выдачу билетов) клиентскому компьютеру

6. В течение определенного периода времени, установленного в AD (обычно 8 ~ 10 часов), этот TGT будетобойти любую проверку учетных данных в случае, если пользователь локального компьютера желает подключиться к ресурсам, для которых требуются разрешения, отсутствующие в его учетной записи (например, членство в группах, дополнительный доступ к компьютеру и общему ресурсу, etc.)

Мой вопрос: как IIS узнает о TGT, когда браузер запрашивает его для моего приложения?Отправляет ли операционная система его при каждом исходящем http-запросе на каждый сайт?

Answer 1

Сервер (IIS) сообщит клиенту (браузеру), что ему необходимо пройти аутентификацию, вернув код ошибки HTTP 401 с заголовком WWW-Authenticate. Клиент обнаруживает это и определяет, может ли он правильно проходить аутентификацию. Это работает следующим образом:

1. Определите, кто запрашивающий, проверив его имя участника службы. Он существует как {type}/{fully.qualified.domain}, например HTTP/resource.domain.com. Это имя участника-службы сопоставляется с учетной записью компьютера или службы в AD. Если это имя участника-службы не зарегистрировано, клиент возвращается к меньшему протоколу, например NTLM.
2. Локальный компьютер использует TGT для запроса служебного билета из AD. AD проверяет TGT и ищет SPN в запросе и, если он найден, создает служебный билет, зашифрованный паролем учетной записи, связанной с SPN.
3. Клиент отправляет сервисный билет на сервер через заголовок Authorization: Negotiate YII....
4. Сервер расшифровывает билет службы, используя предоставленный пароль, через присоединение к домену, конфигурацию запуска службы Windows или таблицу ключей.
5. Сервер преобразует содержимое дешифрованного билета в удостоверение Windows.
6. Идентификационные данные представлены в заявке.

Этот поток по сути не является веб-ориентированным. Вот как все сервисы аутентифицируются при использовании Kerberos.