Аутентификация AD использует два основных протокола: Kerberos и NTLM
NTLM
Процесс сертификации выглядит следующим образом:
- Клиент генерирует хэш NTLM локально, и это значение — это хеш-значение пароля пользователя.
- Клиент отправляет имя пользователя на сервер приложений.
- Сервер приложения генерирует случайное значение для клиента, которое обычно называется nonce или challenge.
- Клиент шифрует NONCE с помощью NTLM-хэша и отправляет его на сервер приложений.
- После получения её сервер приложения отправляет его на сервер AD вместе с именем пользователя и nonce.
- AD генерирует хэш NTLM на основе пароля пользователя, шифрует nonce и затем сравнивает сообщение клиента.
- Если значения совпадают, аутентификация проходит, а если они разные — аутентификация не проходит.
Керберос
Ключевые термины:
- KDC: Центр распределения ключей, который предоставляет две услуги: сервис аутентификации (AS) и сервис выдачи билетов (TGS). Домен генерирует доменную учётную запись под названием krbtgt для KDC, а TGT использует пароль для шифрования и расшифровки. Когда пользователь домена обращается впервые к нему, он хочет, чтобы AS аутентифицировался, а после передачи AS запрашивает TGS предоставить заявку (TGT) пользователю домена.
- SPN:Service Principal Name。 Помимо учетных записей пользователей, аккаунты AD также имеют сервисные аккаунты. К приложению также будет связанная сервисная запись, что облегчит доступ к серверным ресурсам, таким как exchange, SQL, IIS и др. SPN — это сервис, используемый для связи сервиса, активированного приложением, с сервисной записью в AD.
Процесс сертификации:
1. Когда пользователь домена входит, в DC отправляется AS-запрос (AS_REQ), который содержит зашифрованную временную метку, зашифрованную с хэшем пароля пользователя и именем пользователя.
2. После получения запроса DC использует хэш имени пользователя и пароля пользователя для его расшифровки. DC отвечает клиенту AS (AS_REP), который включает сессионный ключ и TGT (Ticket Granting Ticket). Ключ сессии шифруется с хэшем пароля пользователя. TGT содержит членство в группе, домен, метку времени, IP клиента и ключ сессии. TGT также зашифрован, зашифрован паролем от аккаунта KDC, и клиент не может его расшифровать. (TGT по умолчанию действует 10 часов, и обновления, происходящие после этого, не требуют повторного ввода пароля)
3. Когда пользователь запрашивает ресурс в домене, отправляется запрос на сервис предоставления билетов (TGS_REQ), включающий имя пользователя, метку времени, TGT и SPN. Временные метки и имена пользователей шифруются сессионным ключом.
4. После получения запроса KDC сначала определяет, есть ли в запросе SPN, затем расшифровывает TGT, извлекает сессионный ключ и временную метку в TGT и использует сессионный ключ в TGT для расшифровки зашифрованного имени пользователя и временной метки. Проведите несколько проверок:
(1) Временная метка, расшифрованная TGT, должна быть действительной. (Если происходит повторная атака, временная метка недействительна.) ）
(2) Соответствует ли имя пользователя в TGT с именем пользователя в запросе.
(3) Совпадает ли IP-адрес в TGT с IP-адресом в запросе.
Проверка будет отвечать на Ticketing Granting ServiceReply(TGS_REP клиента, который содержит авторизованный доступ SPN, новый сессионный ключ для доступа между клиентом и SPN, а также новый сервисный тикет Service Ticket (включая новый сессионный ключ, имя пользователя и группу пользователей). И авторизованный SPN, и сессионный ключ, обращающийся к SPN, шифруются сессионным ключом в TGT. Сервисный тикет шифруется паролем соответствующего аккаунта SPN.
1. После вышеуказанного процесса пользователь получает ключ сессии и сервисный тикет, связанные с сервисом приложения. Пользователь отправляет запрос приложения (AP_REQ) в службу приложения, который содержит имя пользователя и метку времени, и шифруется сессионным ключом.
2. Сервис использует хэш пароля аккаунта для расшифровки тикета и извлечения пользователя, группы пользователей и ключа сессии. Расшифруйте имя пользователя и временную метку в AP_REQ с помощью расшифрованного сессионного ключа. AP_REQ Если да, запрос принимается, и служба приложения присваивает права на основе информации пользовательской группы в сервисном тикете, после чего пользователь может получить доступ к запрошенному сервису.
Оригинальный адрес:Вход по гиперссылке виден.
|
Опубликовано 22.08.2023 19:16:28
|
|
|
|
