- nike air max 90 pas cher
- 16373
|
IIS предоставляет несколько различных методов аутентификации. Один из них - интегрированная аутентификация Windows. Интегрированная аутентификация Windows использует согласованный Kerberos или NTLM для аутентификации пользователей на основе зашифрованных сообщений, передаваемых между браузером и сервером.
Наиболее распространенным сценарием применения аутентификации NTLM, вероятно, является аутентификация, используемая в браузерах (протокол http). Но на самом деле NTLM определяет только процесс аутентификации и формат сообщений аутентификации. Он не связан с конкретными протоколами. Поэтому он не обязательно связан с http. Браузер просто переносит сообщение NTLM в заголовок протокола http и проходит аутентификацию. Мы знаем, что по протоколу http обычно передается открытый текст, поэтому если прямая передача пароля очень небезопасна, NTLM эффективно предотвращает эту проблему.
Процесс аутентификации
NTLM-аутентификация требует в общей сложности трех шагов для завершения, вы можете использовать инструмент fiddler для захвата пакетов, чтобы увидеть подробный процесс запроса.
Шаг 1
Пользователь входит на клиентский хост, вводя учетную запись Windows и пароль. Перед входом в систему клиент кэширует хэш введенного пароля, а оригинальный пароль отбрасывается ("оригинальный пароль не должен кэшироваться ни при каких обстоятельствах" - это базовое правило безопасности). Пользователь, успешно вошедший в клиентскую Windows, должен отправить запрос другой стороне, если он пытается получить доступ к ресурсам сервера. Этот запрос содержит имя пользователя в открытом виде.
Шаг 2
Сервер получает запрос и генерирует 16-битное случайное число. Это случайное число называется Challenge или Nonce. Сервер сохраняет Challenge перед отправкой клиенту. Challenge отправляется в виде открытого текста.
Шаг 3
После получения Challenge от сервера клиент шифрует его с помощью хэша пароля, сохраненного на шаге I. Зашифрованный Challenge отправляется на сервер.
Шаг 4
После того как сервер получает зашифрованный вызов, отправленный клиентом, он отправляет запрос на аутентификацию клиента в DC (домен). Запрос содержит следующие три основных элемента: имя пользователя клиента; Challenge, зашифрованный хэшем пароля клиента, и оригинальный Challenge.
Шаги 5 и 6
DC получает хэш пароля учетной записи на основе имени пользователя и шифрует оригинальный вызов. Если зашифрованный Challenge совпадает с тем, что прислал сервер, это означает, что пользователь ввел правильный пароль и аутентификация пройдена, в противном случае аутентификация не пройдена. DC отправляет результат аутентификации на сервер и в конечном итоге передает его клиенту.
См. статью:
h ttps:// www.cnblogs.com/artech/archive/2011/01/25/NTLM.html
h ttps:// www.insecurity.be/blog/2018/01/21/retrieving-ntlm-hashes-and-what-changed-technical-writeup/
h ttps:// docs.microsoft.com/en-us/windows/win32/secauthn/microsoft-ntlm
|
Предыдущая статьяAzure DevOps 2020 (III) Ограничение использования памяти при поиске (ES)Следующая статьяУчебник по установке Azure DevOps 2020 (II) Azure DevOps Server Express 2020 RC2
|
发表于 2020-9-5 13:28:14
избранное0 