1. Перевірка автентичності
2. Отримання квитка служби
3. Доступ до служб
4. огляд процесу
5. Прозора перевірка справжності

Замість того щоб передавати через мережу власне пароль, Kerberos працює з послідовністю квитків. На високому рівні це виглядає так: при реєстрації користувача на комп'ютері формується серія обмінів даними з контролером домену (DC), і в разі успіху користувачеві призначається квиток на право отримання квитків (TGT). Згодом при кожному зверненні до служби, такий як загальна папка або додаток, TGT використовується, щоб отримати квиток для доступу до служби або додатком.

Перевірка автентичності

Коли комп'ютер виконує перевірку автентичності при реєстрації, в контролер домену відправляється повідомлення AS_REQ або Authentication Service Request. У Kerberos контролер домену іменується центром поширення ключів Key Distribution Center (KDC). На малюнку 1 показані найважливіші елементи запиту AS_REQ. Ім'я клієнта є основне ім'я користувача (UPN) або успадковане ім'я користувача (sAMAccountName). Ім'я служби в цьому випадку завжди одне і те ж, запит до служби krbtgt в контексті домену або користувача. Щоб запобігти атакам з повторною пакетів, в ході якої зловмисник повторно використовує повідомлення AS_REQ, поточний час шифрується з використанням хешу пароля користувача. Допустиме розходження при цьому - п'ять хвилин. Якщо зашифрована відмітка часу відрізняється від поточного часу більш ніж на п'ять хвилин, то запит відкидається.

Коли KDC отримує повідомлення AS_REQ, в першу чергу робиться спроба розшифрувати позначку часу з використанням локальної копії хешу пароля користувача. Якщо спроба закінчується невдачею, клієнт отримує повідомлення про помилку, і обробка запиту припиняється. Якщо дешифрування проходить вдало, а значення позначки часу знаходиться в прийнятних межах, KDC видає користувачеві повідомлення AS_REP (Authentication Service Reply) від служби перевірки автентичності з вбудованим квитком TGT. На малюнку 2 показано вміст повідомлення AS_REP. На даному етапі комп'ютер користувача зберігає в кеші квиток TGT і сеансовий ключ на час існування TGT і видаляє пароль користувача. За замовчуванням час існування квитків TGT, сформованих центрами KDC AD, спливає через десять годин.

В AD для Kerberos потрібно зашифрована відмітка часу в повідомленні AS_REQ. Початковий обмін відомий як попередня перевірка справжності. У Kerberos в стандартному вигляді не обов'язково шифрувати позначки часу; цілком достатньо повідомлення AS_REQ, що містить ім'я клієнта і ім'я служби. Недолік такого підходу полягає в уразливості для атаки методом перебору по словнику, так як кожен запит, який містить унікальне ім'я клієнта, буде повертати помилку, яке вказує, що клієнт не виявлено, або видасть дійсний TGT даному користувачеві.

Як показано на малюнку 2, повідомлення AS_REP містить два блоки зашифрованих даних. Перший шифрується із застосуванням хешу пароля користувача і містить сеансовий ключ і позначку часу закінчення існування квитка. Сеансовий ключ використовується для шифрування майбутніх з'єднань з центром KDC. Другий компонент, квиток TGT, шифрується за допомогою секрету KDC. Секрет KDC в реалізації Kerberos в AD зберігається як пароль облікового запису користувача krbtgt, існуючої в кожному домені AD. Обліковий запис krbtgt створюється, коли призначається перший DC в домені; цього облікового запису належить вирішальна роль у функціонуванні домену.

Отримання квитка служби

У Kerberos будь-який об'єкт, до якого потрібно отримати доступ, називається службою. До службам відносяться сервери файлів і друку, сервери бази даних і внутрішні веб-додатки. Для доступу до служби користувач надає квиток служби. Перший крок - визначити ім'я учасника служби service principal name (SPN), до якої потрібно отримати доступ. Завдання формування SPN покладається на комп'ютер або додаток користувача.

У випадку з сервером файлів з ім'ям srv01.contoso.com, SPN служби файлів буде cifs / srv01.contoso.com. Аналогічно для веб-додатки на сайті web01.contoso.com ім'я SPN може бути http / web01.contoso.com. Типова проблема, з якою стикаються адміністратори AD, - дублювання імен SPN, при якому більше одного користувача або комп'ютера в каталозі мають одне і те ж ім'я SPN, зареєстроване в атрибуті servicePrincipalName. В цьому випадку центру KDC невідомо, як відповідати на запит квитка служби, так як існує кілька служб з одним ім'ям.

Якщо поглянути на атрибут servicePrincipalName в AD, можна помітити, що жодне з двох згаданих зразкових імен SPN не визначено в один обліковий запис комп'ютера в AD. Щоб зменшити кількість дубльованих даних, збережених в каталозі, AD забезпечує зіставлення на рівні лісу стандартних імен SPN для кожного облікового запису комп'ютерів в каталозі. Буквально десятки вбудованих імен SPN застосовуються до кожного комп'ютера, визначеному в атрибуті. Дані зберігаються в атрибуті spnMappings об'єкта Directory Service в розділі Configuration (= Directory Service, CN = Windows NT, CN = Services, CN = Configuration); цей атрибут зіставляє службу HOST об'єкта з безліччю інших служб, серед яких служби CIFS і HTTP. Якщо потрібно визначити конкретну службу для кожної системи в лісі, не складає труднощів змінити цей атрибут, щоб додати службу до списку заздалегідь визначених служб.

На малюнку 3 показано вміст повідомлення TGS_REQ (Ticket Granting Service Request), яке KDC отримує від клієнта, якщо той намагається звернутися до служби. Перший фрагмент інформації - ім'я SPN служби, для якої клієнт запитує квиток. Ім'я клієнта і відмітка часу зашифровані за допомогою сеансового ключа, отриманого клієнтом в переданому раніше повідомленні AS_REP. Ця інформація повторно використовується для запобігання атак, в ході яких зловмисник повторно задіє повідомлення запиту. Також додається екземпляр квитка TGT, раніше отриманого клієнтом.

Якщо KDC отримує повідомлення TGS_REQ і вказано один елемент для SPN, відмітка часу знаходиться в допустимих межах і квиток TGT дійсний (не прострочений), то клієнту надається квиток служби як частина повідомлення TGS_REP (рисунок 4). Повідомлення TGS_REP містить всі дані, необхідні клієнту для доступу до служби.

За допомогою секрету служби (наприклад, пароля облікового запису комп'ютера або облікового запису служби) шифрується квиток служби, який клієнт кешируєт і використовує завжди, коли необхідний доступ до служби. Так само як у квитків TGT, час, протягом якого дозволено повторно використовувати квитки служби, обмежена (десять годин за замовчуванням в реалізації Kerberos в AD). Маючи квиток служби, клієнт може запросити доступ до неї.

Доступ до служб

Після того як клієнт отримує квиток служби, додаток, що звертається до служби, може пред'явити цей квиток службі і запросити доступ. Механіка пред'явлення квитка служби не так стандартизована, як отримання квитка, через відмінності, властивих додатків. У випадку зі службою HTTP квиток служби вбудовується в заголовки запиту HTTP.

Квиток служби пред'являється з додатком у формі повідомлення AP_REQ Kerberos, як показано на малюнку 5. Служба дешифрує квиток служби і отримує сеансовий ключ, який можна використовувати для дешифрування полів позначки часу і імені клієнта, які в свою чергу використовуються для перевірки справжності квитка служби. Навіть якщо служба приймає квиток служби, на даному етапі клієнт просто пройшов перевірку в службі. Виконати завдання авторизації службі належить на основі інформації про клієнта.

В квиток служби також зазвичай входять дані, відомі як сертифікат атрибута привілеїв Privilege Attribute Certificate (PAC). На малюнку 5 сертифікат PAC іменується інформацією маркера Token Information. Це та ж інформація маркера, яку KDC включає в квиток TGT користувача (рисунок 2). Сертифікат PAC складений з такої інформації, як ідентифікатор безпеки (SID) користувача, відомості про членство в групі і правах безпеки / привілеї користувача. Коли користувач пред'являє квиток TGT в центр KDC, щоб запросити квиток служби, KDC копіює інформацію маркера з TGT і вставляє в поле PAC квитка служби. Служба використовує цю інформацію, щоб підготувати маркер доступу для користувача і перевірити авторизацію користувача, зазвичай на основі членства в групі.

Допускається передача додаткового повідомлення Kerberos, відомого як AP_REP або Application Reply, після того як користувач пред'являє квиток служби в повідомленні AP_REQ, показаному на малюнку 5. Повідомлення Application Reply - необов'язкове; як правило, програма не відправляє таке повідомлення, якщо не відбувається помилки. Приклад ситуації, коли формується повідомлення AP_REP: клієнт запитує (у повідомленні AP_REQ) у служби підтвердження справжності через процес, відомий як обопільна перевірка справжності.

огляд процесу

На малюнку 6 показана схема потоку повідомлень, коли користувач вирішує звернутися до служби на сервері додатків. Користувач реєструється на своїй робочій станції, яка видає послідовність повідомлень AS_REQ і AS_REP в центр KDC, звідки користувач отримує квиток TGT, якщо облікові дані вірні. Потім TGT користувача кешируєтся в пам'яті, і кожен раз, коли користувачеві потрібно отримати доступ до служби (наприклад, до сервера файлів, серверу друку, веб-додатку), користувач пред'являє TGT центру KDC і запитує квиток служби для служби. Користувач отримує квиток служби і пред'являє його з додатком, щоб запросити доступ.

Якщо використовуються контролери домену тільки для читання (RODC), потік повідомлень трохи відрізняється від показаного на малюнку 6, в залежності від політик реплікації паролів і місця кешування паролів. Слід мати на увазі, що центру KDC потрібен доступ до секретів служби і користувача або комп'ютера, щоб видавати квитки служби або квитки TGT відповідно. За замовчуванням RODC НЕ кешируєт паролі, тому у нього немає доступу до необхідних секретам.

Якщо RODC отримує запит для TGT або квитка служби, який контролер не може виконати (через некешірованного пароля), запит передається доступному для запису контролера домену, котрий володіє необхідними секретами для шифрування відповіді. Доступний для запису DC відправляє відповідь в RODC, який в свою чергу передає його клієнту. Якщо RODC має кешуватися паролем для користувача або служби, до якої користувач хоче отримати доступ, то RODC просто видає квиток TGT і / або служби таким же способом, як показано на малюнку 6.

Якщо повернутися до малюнка 2, можна побачити, що квиток TGT користувача зашифровано за допомогою секрету KDC. Цей секрет - пароль для облікового запису krbtgt, яка є у всіх доменах AD. З огляду на положення, закладені в основу RODC (тобто його вразливість за замовчуванням), було б потенційно небезпечно зберігати в RODC пароль доменної облікового запису krbtgt. Якщо RODC буде скомпрометований, зломщик зможе самостійно видавати квитки TGT. З метою зниження ризику кожен RODC у своєму розпорядженні власну обліковим записом krbtgt і ніколи не обізнаний про паролі облікових записів домену або іншого RODC. Доступні для запису контролери домену мають доступ до паролів всіх облікових записів krbtgt, тому вони можуть розшифрувати квитки TGT, видані будь-яким RODC в домені.

Прозора перевірка справжності

Kerberos майже прозорий для адміністраторів AD. На відміну від багатьох схем перевірки автентичності, в Kerberos ніколи не потрібно передавати паролі через мережу, як і немає необхідності зберігати пароль користувача в пам'яті після початкового процесу реєстрації. Завдяки цим перевагам істотно знижується вразливість, властива іншим протоколам перевірки автентичності.

Брайан Десмонд ( [email protected] ) - старший консультант компанії Moran Technology Consulting (Чикаго). Має сертифікат Directory Services MVP. Автор книги «Active Directory», веде блог www.briandesmond.com