Система автентифікації в інформаційній системі на базі протоколу Kerberos

 

 

Продовження таблиці 2.1

renew-till	Найбільше значення поля endtime, яке може бути задано за допомогою прапора RENEWABLE (поле необов'язкове).
Caddr	Один або декілька адрес, з яких може використовуватися  даний білет. Поле необов'язкове. Якщо воно не заповнено, білетом можна скористатися з будь-якої адреси.
Authorization-data	Атрибути привілеїв  клієнта. Поле необов'язкове. Його вміст Kerberos не обробляє - воно інтерпретується  службою.

 

Вміст поля flags адресується  по бітно. Включення і вимикання прапорів тут виробляється зміною значення (0 або 1) відповідного біта. Довжина поля - 32 розряду, проте для адміністратора Kerberos інтерес представляють тільки 9 прапорів білета (таблиця 2.2).

Таблиця 2.2 - Прапори білета

Прапор	Опис
FORWARDABLE	Вказує, що на підставі даного білета TGT служба видачі білетів може генерувати новий білет TGT з іншим мережевим адресою (поле є тільки у білетах TGT).
FORWARDED	Вказує на те, що даний білет TGT був переадресований або згенерує на основі іншого білета TGT, що пройшов переадресацію.
PROXIABLE	Вказує, що служба видачі білетів може генерувати білети, мережеву адресу яких буде відрізнятися від наведеного в даному білету TGT (поле є тільки у білетах TGT).
PROXY	Вказує на те, що мережеву адресу в даному білету відрізняється від адреси, наведеного в білету TGT, на підставі якого він виданий.

 

 

Продовження таблиці 2.2

RENEWABLE	Використовується в  поєднанні з полями endtime і renew-till, дозволяючи періодичне оновлення службою KDC білетів з підвищеним терміном дії
INITIAL	Вказує, що даний білет є білетом видачі білетів (поле є тільки у білетах TGT).

 

• Дані з білета відомі клієнту

Клієнту необхідно знати  частину інформації, що міститься як у звичайних білетах, так і у білетах TGT, щоб управляти своєю кеш-пам'яттю посвідчень. Повертаючи білет і сеансовий ключ в рамках під протоколів AS Exchange або TGS Exchange, служба KDC упаковує клієнтську копію сеансового ключа до структури даних, де вже можуть бути заповнені поля flags, authtime, starttime, endtime і renew-till. Вся ця структура шифрується за допомогою ключа клієнта, включається в пакет KRB_AS_REP або KRB_TGS_REP і повертається на робочу станцію клієнта.

Служба KDC обмежує термін дії білета

У білету вказується час початку і кінця його дії. Протягом цього проміжку клієнт, якому виданий даний білет, може необмежену кількість разів представити його для отримання доступу до служби. Щоб зменшити ризик компрометації білета або відповідного сеансового ключа, адміністратор має право обмежити максимальний термін дії білета. Цей термін є одним з елементів політики Kerberos.

Запитуючи в центрі KDC білет для доступу до служби, клієнт може вказати конкретний час початку його дії. Якщо цього не зроблено або заданий час вже минуло, центр KDC зазначає у полі starttime поточний час.

Але незалежно від  того, вказав клієнт час початку  дії білета чи ні, запит обов'язково повинен містити час припинення строку його дії. Отримавши такий запит, служба KDC розраховує значення поля endtime. Для цього вона підсумовує найбільший термін дії білета, передбачений політикою Kerberos, зі значенням поля starttime, а потім порівнює отриманий результат з часом припинення дії білета, зазначеним у запиті клієнта. Якщо вони не збігаються, в полі endtime заноситься той час, що настане раніше.

 

• Що відбувається після закінчення терміну дії білета

Про закінчення терміну  дії сеансового білета або білета TGT служба KDC не повідомляє клієнта. Не стежить вона і за транзакціями з клієнтом, якщо не вважати короткострокових записів, головна мета яких - запобігти повторне використання перехоплених пакетів.

Якщо клієнт, намагаючись підключитися до сервера, передасть прострочений сеансовий білет, то у відповідь він отримає повідомлення про помилку. У цьому випадку клієнтові доведеться знову звертатися до служби KDC і замовляти новий сеансовий білет. Однак після автентифікації підключення термін дії сеансового білета перестає грати якусь роль, оскільки він потрібний тільки для підключення до сервера. Навіть якщо термін дії сеансового білета припиниться під час проведення сеансу, це ніяк не позначиться на ході поточних операцій.

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

 

• Оновлюванні білети TGT

Один з методів захисту  сеансових ключів полягає в частій їх зміні. З цією метою в політиці Kerberos можна передбачити відносно невеликий максимальний термін дії білетів. Але є й інший спосіб - використовувати поновлювані білети. При цьому забезпечується періодичне оновлення сеансових ключів без необхідності запитувати новий білет. Якщо політика Kerberos дозволяє застосування відновлювальних білетів, служба KDC включає в кожен генерований білет прапор RENEWABLE і вказує два терміни закінчення його дії. Перший з них обмежує життя поточного екземпляра білета, а другий визначає загальний час, протягом якого може використовуватися білет з урахуванням його оновлення.

Поле endtime вказує, коли закінчується термін дії поточного екземпляра білета. Як і у випадку з неоновлюваної білетами, значення цього поля дорівнює сумі значення з поля starttime і найбільшого терміну дії білетів, визначеного політикою Kerberos. Клієнт, який використовує оновлюваний білет, повинен представити його в службу KDC для оновлення до часу, вказаного в полі endtime. Одночасно з білетом в центр розподілу ключів спрямовується і новий автентифікатор. Отримавши білет, який потрібно оновити, служба KDC, перш за все, перевіряє загальний строк його дії, зазначений в полі renew-till. Це час задається при первинній генерації білета. Воно визначається шляхом підсумовування значення з поля starttime з максимально допустимим політикою Kerberos терміном дії білета з урахуванням всіх оновлень. Якщо зазначена в полі renew-till час ще не настав, служба KDC генерує новий екземпляр білета, де зазначає більш пізній час endtime і замінює сеансовий ключ.

Це дає адміністратору можливість передбачити в політиці Kerberos порівняно часте оновлення білетів, наприклад, щодня. Зміна сеансових ключів при оновленні білета набагато знижує ризик їх компрометації. У той же час адміністратор може задати досить тривалий загальний час використання білета - тиждень, місяць, чи більше. Після закінчення цього терміну білет стає повністю непридатним для подальшого використання і оновлення не підлягає.

 

 

• Делегування автентифікації

Певну складність для  протоколу Kerberos створюють багаторівневі  клієнт-серверні додатки. Тут клієнт може підключатися до сервера, який, у  свою чергу, повинен буде підключитися до іншого сервера більш високого рівня. Для цього першому серверу знадобиться білет на підключення до другого. В ідеалі такий білет повинен обмежувати доступ першого сервера до другого лише тими функціями, на які клієнт має права.

Для вирішення цієї проблеми в протоколі Kerberos є спеціальний  механізм - так зване делегування автентифікації. По суті, в такій ситуації клієнт доручає свою автентифікацію серверу. З цією метою він повідомляє службу KDC про те, що даний сервер має право представляти клієнта.

Делегування автентифікації можливо двома способами. По-перше, клієнт може отримати білет на підключення до сервера вищого рівня, а потім передати його найближчому серверу. Білети, отримані таким способом - клієнтом для найближчого сервера - називаються представницькими (proxy tickets). Однак на цьому шляху є одна серйозна трудність: щоб отримати представницький білет, клієнтові потрібно знати ім'я сервера вищого рівня. Вирішити проблему допомагає другий спосіб делегування автентифікації. Тут клієнт передає на найближчий до нього сервер свій білет TGT, який той у міру необхідності використовує для запиту власних білетів. Білети TGT, отримані таким чином, тобто, за посвідченням клієнта, називаються переданими (forwarded tickets). Який з описаних способів застосовується службою KDC, залежить від політики Kerberos.

 

• Представницькі білети

Коли служба KDC приступає  до формування білета TGT, вона, перш за все, звертається до політики Kerberos і перевіряє, чи допускається застосування представницьких білетів. Якщо так, центр управління білетами виставляє у білету TGT, який він готує клієнту, прапор PROXIABLE.

Щоб отримати представницький білет, клієнт пересилає свій білет TGT в службу видачі білетів і запитує в неї білет на підключення до сервера вищого рівня. У запиті виставляється спеціальний прапор, який свідчить про те, що потрібен представницький білет, а також вказується ім'я сервера, який буде представником клієнта. Отримавши такий запит, служба KDC створює білет на доступ до сервера вищого рівня, виставляє в ньому прапор PROXY і відсилає в такому вигляді клієнту. Клієнт потім направляє отриманий білет на сервер, який буде його представляти, а той, у свою чергу, використовує цей білет для доступу до сервера вищого рівня.

 

• Передані білети

Клієнт, який має намір  делегувати свої права на отримання білета для доступу до сервера вищого рівня, повинен запросити у служби KDC передаваємий білет TGT. Це робиться за допомогою під протоколу AS Exchange. У запит обов'язково включається ім'я сервера, який буде представляти клієнта. Якщо політика Kerberos допускає використання передаваємих білетів, служба KDC генерує білет TGT на доступ даного клієнта до сервера вищого рівня, виставляє в ньому прапор FORWARDABLE і в такому вигляді направляє клієнту. Клієнт, у свою чергу, пересилає отриманий білет TGT того сервера, з яким працює безпосередньо.

Цей сервер, направляючи білет на сервер вищого рівня, представляє в службу KDC білет TGT, отриманий від клієнта. Виявивши в ньому прапор FORWARDABLE, центр управління білетами виставляє в новому білету прапор FORWARDED і повертає його першому серверу.

 

• Центр розподілу ключів KDC

В операційній системі Windows KDC реалізований як служба домену. У якості бази даних облікових записів він використовує Active Directory. Крім того, деякі дані про користувачів надходять в нього з глобального каталогу (Global Catalog).

Як і в інших реалізаціях  протоколу Kerberos, центр KDC Windows  представляє  собою єдиний процес, що поєднує  дві служби:

• Служба автентифікації Authentication Service (AS). Ця служба видає білети на видачу білетів (білети TGT). Перш, ніж отримати білет на обслуговування, мережевий клієнт повинен запросити початковий білет TGT, звернувшись для цього до служби автентифікації того домену, де знаходиться обліковий запис користувача.
• Служба видачі білетів Ticket-Granting Service (TGS). Ця служба видає білети на доступ до інших служб свого домену або до служби видачі білетів довіреному домену. Щоб звернутися до служби TGS, клієнтові потрібно спочатку увійти в контакт зі службою видачі білетів того домену, де знаходиться обліковий запис служби, представити свій білет TGT і запитати потрібний білет. Якщо у клієнта немає білета TGT, який відкриває доступ до даної службі видачі білетів, він може скористатися процесом переадресації (referral process). Початковою точкою цього процесу є служба того домену, де знаходиться обліковий запис користувача, а кінцевою - служба видачі білетів домену, де знаходиться обліковий запис необхідної служби.

Центр KDC, як і служба каталогів Active Directory, є в кожному домені. Обидві служби автоматично запускаються підсистемою LSA (Local Security Authority - розпорядник локальної безпеки), яка встановлена на контролері домену. Вони працюють у просторі процесів цього розпорядника. Жодну з цих служб зупинити неможливо. Щоб гарантувати постійний доступ до KDC і Active Directory, в Windows є можливість розгортання в кожному домені кількох рівноправних контролерів домену. При цьому запити на автентифікацію і на видачу білета, адресовані службі KDC даного домену, може приймати будь який контролер домену.

У доменах Windows служба KDC є абонентом безпеки. В цій якості вона виступає під ім'ям krbtgt. Обліковий запис абонента безпеки для неї створюється автоматично при організації нового домену; цей запис не можна ні змінити, ні перейменувати. Пароль облікового запису KDC також присвоюється автоматично, а потім регулярно змінюється на плановій основі разом з паролями довірених облікових записів домену (domain trust account). Пароль облікового запису KDC використовується при обчисленні секретного ключа, необхідного для шифрування і розшифрування генеруючи цією службою білетів TGT. Пароль довіреного облікового запису домену необхідний для розрахунку Міждоменних (міжобласних) ключів, які використовуються для шифрування білетів переадресації.