IIS пропонує багато різних технологій автентифікації. Одна з них — інтеграція автентифікації Windows. Інтегрована автентифікація Windows використовує переговорну систему Kerberos або NTLM для автентифікації користувачів на основі зашифрованих повідомлень тикетів, що передаються між браузером і сервером.
Найпоширенішим сценарієм застосування автентифікації NTLM, ймовірно, є автентифікація, що використовується в браузерах (протокол http). Але насправді NTLM вказує лише процес автентифікації та формат повідомлень. Це не пов'язано з конкретними угодами. Отже, зв'язку з http не обов'язково. Браузер переносить лише повідомлення NTLM у заголовку протоколу http і передає автентифікацію. Ми знаємо, що http зазвичай використовується у відкритому тексті, тому якщо пряма передача паролів дуже небезпечна, NTLM ефективно запобігає цій проблемі.
Процес сертифікації
Автентифікація NTLM вимагає трьох кроків, і детальний процес запиту можна переглянути через інструментарію Fiddler.
Крок 1
Користувач входить на клієнтський хостинг, вводячи номер облікового запису Windows та пароль. Перед входом клієнт кешує хеш введеного пароля, і оригінальний пароль відкидається ("оригінальний пароль не може бути кешований за жодних обставин", це базова рекомендація безпеки). Користувач, який успішно увійшов у клієнтський Windows, повинен надіслати запит іншій стороні, якщо той намагається отримати доступ до серверних ресурсів. Запит містить ім'я користувача у відкритому тексті.
Крок 2
Коли сервер отримує запит, він генерує 16-бітне випадкове число. Це випадкове число називається викликом або нонцем. Виклик зберігається до того, як сервер надсилає його клієнту. Виклики надсилаються у відкритому тексті.
Крок 3
Після отримання виклику, надісланого сервером, клієнт шифрує його хешом пароля, збереженим на першому кроці, а потім надсилає зашифрований виклик на сервер.
Крок 4
Після отримання зашифрованого виклику, надісланого клієнтом, сервер надсилає запит на автентифікацію клієнту до DC (домену). Запит переважно включає такі три вмісти: ім'я користувача клієнта; Виклик і оригінальний виклик із зашифрованим хешем паролів клієнта.
Кроки 5 і 6
DC шифрує початковий виклик, отримуючи хеш пароля акаунта на основі імені користувача. Якщо зашифрований виклик збігається з тим, що надісланий сервером, це означає, що користувач має правильний пароль і верифікація проходить, інакше перевірка не проходить. DC надсилає результати верифікації на сервер, а потім зворотний сигнал клієнту.
Довідкові статті:
Вхід за гіперпосиланням видно.
Вхід за гіперпосиланням видно.
Вхід за гіперпосиланням видно.
|
Опубліковано 2020-9-5 13:28:14
|
|
|
|
