Твій чорний лицар як цербер з Ада,
Знову нацькував своїх відданих псів ...
Кожен хитрий і спритний, ось драма,
Тільки не страшний вже брязкіт зубів!
У попередній статті даного циклу я почав вас знайомити з можливостями протоколу перевірки автентичності Kerberos. Ви дізналися про те, що собою являє Kerberos, про творців перших версій цього протоколу, про нові можливості інтерфейсу SSPI, а також про основні поліпшення протоколу перевірки автентичності Kerberos в порівнянні з NTLM. Але, швидше за все, після першої статті даного циклу у читача може виникнути ще більше питань, пов'язаних з даним протоколом перевірки автентичності.
У цій статті я покажу, що, насправді, брязкіт зубів Цербера не так вже й страшно. Іншими словами, ви дізнаєтеся, як я сподіваюся, дещо нове про центр поширення ключів (KDC), а також про службу надання квитків. Крім цього, буде розглянуто процес перевірки автентичності Kerberos.
Для чого потрібен KDC?
Ще в першій статті цього циклу я мигцем згадав, що одним з основних компонентів протоколу перевірки автентичності Kerberos виступає центр поширення ключів (Key Distribution Center, KDC) - центральне сховище даних користувача для перевірки автентичності користувачів. Зараз же детальніше розглянемо цей основний компонент Kerberos.
У тому випадку, якщо виконується перевірка справжності згідно моделі із загальним секретом, щоб цей секрет нікому не був відомий, для шифрування пакету використовується хеш пароля користувача. Відразу, як тільки центр розподілу ключів отримує такий пакет, виконується розшифровка інформації за допомогою хеш-кодування, який був збережений в доменних службах Active Directory, причому, як користувач, так і сервер повинні спільно використовувати цей секрет. У свою чергу, KDC, розташовуючись на контролері домену, управляє всіма загальними секретами користувачів в організації, які, як мигцем було згадано вище, знаходяться в одній базі даних. До речі, в термінології Kerberos кордон, яка визначається базою даних користувачів в одному KDC, прийнято називати сферою. в той час як в Active Directory така межа називається доменом.
Сам KDC виконується як окремий процес, заснований на наступних двох службах:
Службапроверкіподлінності (Authentication Service, AS). Дана служба видає квиток надання квитка (Ticket-Granting Ticket, TGT) для підключення до служби надання квитків в своєму або в довіреному домені. Саме посвідчення TGT дозволяє отримувати квитки для всіх служб, які використовуються для отримання доступу до ресурсів. У свою чергу, перед тим як користувач запросить квиток на іншому комп'ютері, він повинен запитати у служби перевірки справжності TGT для облікового запису клієнта. Далі служба перевірки справжності повертає службі надання квитків TGT для цільового доменного комп'ютера. Самі квитки TGT можуть бути використані до закінчення свого терміну дії, проте, при першому підключенні до служби TGS, користувачеві потрібно буде надавати свої облікові дані, щоб здійснювати;
Служба надання квитків (Ticket-GrantingService, TGS). На відміну від служби перевірки автентичності, дана служба видає квитки для підключення до комп'ютерів в домені. Коли клієнтам потрібно підключитися до будь-якого комп'ютера, він звертається до служби TGS, надає TGT, а потім запитує квиток на цільовий комп'ютер. Як і у всіх випадках, квитки можуть бути використані до закінчення свого терміну дії, але, при першому підключенні до TGS, доведеться надати свої облікові дані.
Обидві служби запускаються всередині процесу локальної системи безпеки (Local Security Authority, LSA). До речі, як клієнтські комп'ютери, так і будь-які додатки ніколи не повинні мати можливості отримання прямого доступу до самої бази даних облікових записів. Крім цих двох служб, всередині процесу LSA також запускається системний агент каталогу (Directory System Agent - DSA, агент, за допомогою якого управляється база банних), через який повинні проходити всі запити.
Мал. 1. Визначення порогового розміру квитка
Крім усього зазначеного вище в даному розділі, слід пам'ятати, що якщо з якоїсь причини центр KDC буде недоступний, контролер домену, на якому був розташований KDC, більше не буде контролером домену, та й з доступом до доменних службам Active Directory у вас можуть бути проблеми. Саме з цієї причини будь-який контролер домену може приймати запити на перевірку справжності та видачу квитків, володіючи роллю центру KDC.
Процес перевірки автентичності Kerberos
Раніше я буквально в двох словах говорив про сам процес перевірки автентичності Kerberos, і виглядало це наступним чином: користувач вводить свої облікові дані, на клієнтському комп'ютері виконується хешування пароля за допомогою локальної підсистеми безпеки LSA, потім дані передаються постачальнику підтримки безпеки, а вже після цього йдуть на контролер домену.
Більш ніж очевидно, що на цьому нічого не закінчується. Отже, які ж дії виконуються під час перевірки автентичності Kerberos:
Перш за все, постачальник SSP пересилає центру поширення ключів повідомлення перевірки автентичності, що включає в себе ім'я та домен користувача, а також запит TGT з секретним ключем, який, як ви вже знаєте, витягується з пароля користувача. Між іншим, секретний ключ може використовуватися як для перевірки автентичності клієнта, так і для перевірки автентичності сервера. З огляду на те, що квиток буде відправлений в чистому вигляді, що загрожує впливу зловмисників, частина запиту обов'язково шифрується;
Мал. 2. Встановлення максимальної похибки синхронізації годинника комп'ютера
Після того як перевірка справжності вдало буде завершена, контролер домену пересилає на клієнтський комп'ютер повідомлення з сеансовим ключем TGS та квитком TGT, який і буде надавати користувачеві доступ до TGS. Сеансовий ключ являє собою ключ шифрування, який використовується для аутентифікації клієнта і може додатково використовуватися для аутентифікації сервера, замість секретного ключа клієнта для взаємодії з KDC. Тепер, якщо користувачеві протягом життєвого циклу TGT, знадобиться надати свої облікові дані будь-якого ресурсу або додатком, клієнт весь час буде надавати службі TGS цей квиток TGT. У квитку, крім всієї необхідної інформації ще передаються ідентифікатори безпеки користувача і груп безпеки, в які входить користувач, що називається сертифікатом атрибутів привілеїв (Privilege Attribute Certificate, PAC). Квиток TGT, який пересилається користувачеві в тілі KRB_AS_REP, зашифрований ключем KDC, який користувачеві не відомий і не повинен бути відомий. Тобто користувач отримує TGT в зашифрованому вигляді і розшифрувати його не може.
Час життя квитка користувача можна визначити, знову ж таки, за допомогою групової політики. Для цього слід скористатися можливостями параметра політики «Максимальний термін життя квитка користувача» з вузла Конфігурація компьютераПолітікіПараметриWindowsПараметри безопасностіПолітікі облікових запісейKerberos. Тут ви можете вказати максимальний інтервал часу, протягом якого може бути використаний квиток уявлення квитка. Після закінчення терміну дії квитка TGT необхідно відновити існуючий квиток або запросити новий. Діалогове вікно властивостей поточного параметра політики можна побачити нижче:
Мал. 3. Максимальний термін життя квитка користувача
На цьому етапі пакет повертається на комп'ютер користувача і його знову слід розшифрувати. За процес розшифровки сеансового ключа TGS на клієнтському комп'ютері відповідає секретний ключ користувача. Як і на другому кроці даного процесу, якщо клієнту вдалося розшифрувати сеансовий ключ, і тимчасова мітка виявилася дійсною, клієнт вважає, що центр KDC є дійсним і йому можна довіряти. Сеансовий ключ кешируєтся на комп'ютер користувача до закінчення свого терміну дії, причому, для підключень до центру поширення ключів тепер буде використовуватися саме цей ключ. А так як клієнтові більш не потрібен секретний ключ - він просто видаляється з кешу;
Користувач вже пройшов перевірку автентичності, тобто, можна сказати, один з найважливіших етапів вже пройдено. Однак, залишилося отримати доступ до ресурсів мережі, що було ключовим завданням всієї розглянутої процедури. Якщо для надання доступу до служби TGS використовується квиток TGT отриманий користувачем, то для доступу до решти ресурсів мережі користувачеві ще належить від служби TGS отримати квиток доступу до служби. Відповідно, на цьому кроці клієнт відправляє запит квитка доступу до служби на TGS, куди входить така інформація, як ім'я та домен користувача, його SPN, квиток TGT, про який йшлося вище, UPN, а також тимчасова мітка, зашифрована сеансовим ключем;
KDC знову розшифровує квиток TGT за допомогою довгострокового ключа, витягує сеансовий ключ TGS та з тимчасової мітці перевіряє, коректний чи використовується сеансовий ключ. Якщо все витягнуті дані валідність, центр розповсюдження ключів виконує LDAP-запит для пошуку облікового запису користувача і готує квиток доступу до служби. Як і в випадку з часом життя квитка користувача, за допомогою параметра політики «Максимальний термін життя квитка служби». ви можете визначити максимальну кількість хвилин, протягом якого отриманий квиток сеансу дозволяється використовувати для доступу до конкретної службі. Квитки сеансів застосовуються тільки для перевірки справжності на нових підключеннях до серверів. Після того як підключення пройде перевірку справжності, термін дії квитка втрачає сенс. Якщо ви вкажете значення, рівне 0 хвилин, термін життя квитка не має терміну дії. Діалогове вікно властивостей даного параметра політики зображено на наступній ілюстрації:
Мал. 4. Максимальний термін життя квитка служби
Тепер клієнтський комп'ютер кешируєт у себе в пам'яті обидві частини сеансового квитка. Для надання доступу клієнтський комп'ютер надає мережевий службі квиток сеансу;
В останню чергу, мережева служба, до якої підключається користувач, розшифровує квиток доступу до служби, використовуючи свій секретний ключ, а потім робиться розшифровка тимчасової мітки, де можна знайти і сам запит. Якщо все вийшло, мережева служба починає довіряти центру KDC і визначає, чи взаємна перевірка достовірності для клієнта. Якщо така необхідна, тимчасова мітка із запиту шифрується і відправляється відповідь на клієнтський комп'ютер. Після цього знову клієнту потрібно виконувати розшифровку тимчасової мітки, використовуючи свій сеансовий ключ. Якщо все тимчасові мітки зійшлися - відбувається загальне довіру;
Так виглядає процес перевірки автентичності Kerberos, але якщо ви хочете познайомитися з цим процесом більш детально, включаючи процес формування повідомлень і організацію обміну повідомленнями, рекомендую вам ознайомитися з RFC1510.
І на останок
Хотілося б відзначити, що в даній статті були виділені не всі можливі нюанси, пов'язані з центром поширення ключів і процесом перевірки автентичності Kerberos, однак, викладений матеріал дозволить вам отримати загальні знання, пов'язані з ним. У статті не розглядалася проксі-служба KDC, процес шифрування квитків, різні повідомлення, зазначені у квитках, не розглянули перевірка справжності між доменами.