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

Отримавши відповідь KDC, клієнт отримує з нього сеансовий білет і свою копію сеансового ключа, які поміщає в безпечне сховище (воно розташовується не на диску, а в оперативній пам'яті). Коли виникає необхідність зв'язатися з сервером, клієнт посилає йому повідомлення, що складається з білета, який як і раніше зашифрований із застосуванням довготривалого ключа цього сервера, і власним автентифікатором, зашифрованого за допомогою сеансового ключа. Цей білет в комбінації з автентифікатором якраз і складає посвідчення, за яким сервер визначає «особистість» клієнта (рисунок 2.4).

Размещено на http://www.allbest.ru/

Рисунок 2.4 - Взаємна автентифікація (клієнт-сервер)

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

Одна з переваг застосування сеансових білетів полягає в тому, що сервера не потрібно зберігати сеансові ключі для зв'язку з клієнтами. Вони зберігаються в кеш-пам'яті посвідчень (credentials cache) клієнта, який направляє білет на сервер кожного разу, коли хоче зв'язатися з ним. Сервер, зі свого боку, отримавши від клієнта білет, розшифровує його і витягує сеансовий ключ. Коли потреба в цьому ключі зникає, сервер може просто стерти його зі своєї пам'яті.

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

2.4.4 Білети на видачу білетів

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

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

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

На запит користувача KDC відповідає спеціальним сеансовим білетом для самого себе, так званий білет на видачу білетів (ticket-granting ticket), або білет TGT. Як і звичайний сеансовий білет, TGT містить копію сеансового ключа для зв'язку служби (в даному випадку-KDC) з клієнтом. У повідомлення з білетом TGT також включається копія сеансового ключа, за допомогою якої клієнт може зв'язатися з KDC. Білет TGT шифрується за допомогою довгострокового ключа служби KDC, а клієнтська копія сеансового ключа - за допомогою довгострокового ключа користувача.

Отримавши відповідь служби KDC на свій первинний запит, клієнт розшифровує свою копію сеансового ключа, використовуючи для цього копію довготривалого ключа користувача з своєї кеш-пам'яті. Після цього довготривалий ключ, отриманий з пароля користувача, можна видалити з пам'яті, оскільки він більше не знадобиться: весь подальший зв'язок з KDC буде шифруватися за допомогою сеансового ключа. Як і всі інші сеансові ключі, він має тимчасовий характер і є дійсним до закінчення терміну дії білета TGT, або до виходу користувача з системи. З цієї причини такий ключ називають сеансовим ключем реєстрації (logon session key).

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

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

2.4.5 Автентифікація за межами домену

Функції центру KDC можна розділити на дві категорії: службу автентифікації, у завдання якої входить генерація білетів TGT, і службу видачі білетів, створює сеансові білети. Такий поділ праці дозволяє застосовувати протокол Kerberos і за межами його «рідного» домену. Клієнт, який отримав білет TGT зі служби автентифікації одного домену, може скористатися ним для отримання сеансових білетів в службах видачі білетів інших доменів.

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

А тепер розглянемо, що відбувається, коли користувач з обліковим записом в домені «Схід» запитує доступ до сервера з домену «Захід». Перш за все, клієнт Kerberos, встановлений на робочій станції користувача, надсилає запит до служби видачі білетів свого домену, в якому просить видати сеансовий білет для доступу на потрібний сервер. Служба видачі білетів домену «Схід» перевіряє список своїх абонентів безпеки і переконується, що такого сервера серед них немає. Тому вона направляє клієнтові так званий білет переадресації (referral ticket), який представляє собою TGT, зашифрований за допомогою міждоменного ключа, спільного для служб KDC доменів «Схід» і «Захід». Отримавши білет переадресації, клієнт використовує його для підготовки іншого запиту на сеансовий ключ. Однак на цей раз запит пересилається в службу видачі білетів того домену, де знаходиться обліковий запис потрібного сервера, тобто, домену «Захід». Його служба видачі білетів намагається розшифрувати білет переадресації за допомогою власної копії Міждомена ключа. Якщо спроба вдається, центр KDC направляє клієнтові сеансовий білет на доступ до відповідного серверу свого домену.

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

В якості прикладу розглянемо мережу, що складається з трьох доменів: «Схід», «Захід» і «Штаб-квартира». У службі KDC домену «Схід» немає міждоменного ключа для аналогічної служби домену «Захід», але центри розподілу ключів обох доменів налагодили обмін білетами з доменом «Штаб-квартира». Коли користувач з обліковим записом в домені «Схід» хоче підключитися до сервера з домену «Захід», його запит буде переадресовано двічі. Спочатку він пройде через службу KDC «рідного» домену, потім - через проміжний домен «Штаб-квартира» і, нарешті, досягне центру розподілу ключів домену «Захід», якому відомий ключ потрібного сервера. Таким чином, клієнт тут посилає сеансові білети тричі на три різні служби KDC.

1. Клієнт запитує у служби KDC домену «Схід» білет на доступ до сервера домена «Захід».

Служба KDC домену «Схід» спрямовує клієнту білет переадресації в службу KDC домену «Штаб-квартира», зашифрований з міждоменним ключем, загальним для доменів «Схід» і «Штаб-квартира».

2. Клієнт звертається до служби KDC домену «Штаб-квартира» з проханням про білет на доступ до сервера домена «Захід».

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

3. Клієнт звертається до служби KDC домену «Захід» з проханням про білет на доступ до сервера домена «Захід».

Служба KDC домену «Захід» спрямовує клієнту білет на доступ до потрібного сервера.

2.5 Підпротоколи

Протокол Kerberos містить у собі три підпротоколи:

- Перший з них використовується службою KDC для передачі клієнту сеансового ключа реєстрації та білета TGT. Він називається Authentication Service Exchange (обмін зі службою автентифікації) або, скорочено AS Exchange.

- Другий подпротокол під назвою Ticket-Granting Service Exchange (обмін зі службою видачі білетів) або TGS Exchange служить для розсилки службових сеансових ключів і сеансових ключів самої служби KDC.

- Третій подпротокол, Client / Server Exchange (клієнт-серверний обмін) або CS Exchange, використовується клієнтом для пересилання сеансового білета доступу до служб.

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

2.5.1 Підпротокол AS Exchange

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

Після цього клієнт посилає в службу автентифікації центру KDC запит KRB_AS_REQ (Kerberos Authentication Service Request - запит до служби автентифікації Kerberos). Перша частина його повідомлення містить ідентифікатор користувача, тобто Олени, а також ім'я служби, для якої їй потрібно посвідчення, тобто служби видачі білетів. У другій частині вказуються дані попередньої автентифікації (pre-authentication data), які підтверджують, що Олена знає пароль. Зазвичай в якості таких даних використовується мітка часу, зашифрована з довготривалим ключем Олени, хоча Kerberos допускає і інші види предавтентіфікаціонних даних (рисунок 2.5).

Размещено на http://www.allbest.ru/

Рисунок 2.5 - Подпротокол AS Exchange

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

Після того, як перевірка особи Олени завершена, служба KDC генерує посвідчення, яке підтверджує, що клієнт Kerberos на її робочої станції має право звернутися до служби видачі білетів. Цей процес виконується в два етапи. По-перше, KDC створює сеансовий ключ реєстрації та шифрує його копію за допомогою довгострокового ключа Олени. По-друге, служба включає ще одну копію сеансового ключа реєстрації у білет TGT. Туди ж заноситься і інша інформація про Олену, наприклад, її дані авторизації. Потім KDC шифрує білет TGT з власним довготривалим ключем і, нарешті, включає зашифрований сеансовий ключ реєстрації разом з білетом TGT в пакет KRB_AS_REP (Kerberos Authentication Service Reply - відповідь служби автентифікації Kerberos), який направляє клієнту.

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

2.5.2 Підпротокол TGS Exchange

Клієнт Kerberos, встановлений на робочій станції Олени, запитує посвідчення на доступ до служби Сергій, для чого посилає в службу KDC повідомлення KRB_TGS_REQ (Kerberos Ticket-Granting Service Request - запит до служби видачі білетів Kerberos). У нього включається ім'я користувача, автентифікатор, зашифрований за допомогою сеансового ключа реєстрації Олени, білет TGT, який був отриманий за допомогою подпротокола AS Exchange, а також ім'я служби, на доступ до якої потрібен білет (рисунок 2.6).

Размещено на http://www.allbest.ru/

Рисунок 2.6 - Подпротокол TGS Exchange

Отримавши запит KRB_TGS_REQ, служба KDC за допомогою власного секретного ключа розшифровує білет TGT і витягує з нього сеансовий ключ реєстрації Олени, який тут же використовує для розшифровки автентифікатором. Якщо вміст автентифікатора витримує перевірку, служба KDC витягує з білета TGT реєстраційні дані Олени і генерує сеансовий ключ, загальний для клієнта Олени та служби Сергій. Одну копію цього ключа KDC шифрує за допомогою сеансового ключа реєстрації Олени, а іншу разом з даними авторизації Олени поміщає у білет, який шифрує за допомогою довгострокового ключа Сергія. Після цього посвідчення Олени включається в пакет KRB_TGS_REP (Kerberos Ticket-Granting Service Reply - відповідь служби видачі білетів Kerberos) і прямує на її робочу станцію.

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

2.5.3 Підпротокол CS Exchange

Клієнт Kerberos, встановлений на робочій станції Олени, звертається до служби Сергій, для чого посилає на неї запит KRB_AP_REQ (Kerberos Application Request - Запит програми Kerberos). Це повідомлення містить автентифікатор Олени, зашифрований за допомогою сеансового ключа для служби Сергій, білет, отриманий за допомогою протоколу TGS Exchange, а також прапор, який вказує про бажання клієнта провести взаємну автентифікацію (рисунок 2.7).

Размещено на http://www.allbest.ru/

Рисунок 2.7 - Подпротокол CS Exchange

Отримавши повідомлення KRB_AP_REQ, служба Сергій розшифровує білет, витягує з нього дані авторизації Олени і сеансовий ключ, за допомогою якого відразу ж розшифровує автентифікатор Олени. Якщо мітка часу, закладена в нього, витримує перевірку, Сергій шукає в запиті прапор взаємної автентифікації. Знайшовши його, Сергій шифрує мітку часу з автентифікатором Олени сеансовим ключем, включає отриманий результат в пакет KRB_AP_REP (Kerberos Application Reply - відповідь додатка Kerberos) і повертає його на робочу станцію Олени.

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

2.6 Білети

Перерахування полів білета і описання яке міститься в них (таблиця 2.1).



Таблиця 2.1

Поля білета

Назва поля	Опис
Перші три поля білета не шифруються. Інформація, що міститься тут інформація пересилається відкритим текстом, що дозволяє клієнту використовувати її для управління білетами, що зберігаються в кеш-пам'яті.
tkt-vno	Номер версії формату білета.
Realm	Ім'я області (домену), де згенеровано білет. Служба KDC може створювати білети тільки для серверів власної області, тому тут, по суті, вказується ім'я області, де розташований сервер.
Sname	Ім'я сервера.
Інші поля шифруються за допомогою секретного ключа сервера.
Flags	Прапори білета.
Key	Сеансовий ключ.
Crealm	Ім'я області (домену) клієнта.
Cname	Ім'я клієнта.
Transited	Список областей Kerberos, які брали участь в автентифікації клієнта, якій видано даний білет.
Authtime	Час первісної автентифікації клієнта. Служба KDC заповнює це поле в момент генерації білета TGT. При генерації білетів на основі білета TGT тимчасова мітка з поля authtime білета TGT копіюється в поле authtime генерується білета.
Starttime	Час вступу білета в силу.
Endtime	Час закінчення терміну дії білета.
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, на підставі якого він виданий.
RENEWABLE	Використовується в поєднанні з полями endtime і renew-till, дозволяючи періодичне оновлення службою KDC білетів з підвищеним терміном дії
INITIAL	Вказує, що даний білет є білетом видачі білетів (поле є тільки у білетах TGT).

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

Клієнту необхідно знати частину інформації, що міститься як у звичайних білетах, так і у білетах 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 заноситься той час, що настане раніше.

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

криптографічний безпека протокол kerberos

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

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

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



2.6.7 Центр розподілу ключів 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. Пароль довіреного облікового запису домену необхідний для розрахунку Міждоменних (міжобласних) ключів, які використовуються для шифрування білетів переадресації.

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

2.6.8 База даних облікових записів

База даних, яка необхідна службі KDC для отримання інформації щодо абонентів безпеки, зберігається в каталозі Active Directory. Кожен абонент тут представлений у вигляді профілю. Криптографічні ключі, застосовувані для зв'язку з користувачем, комп'ютером або службою, зберігаються у вигляді атрибутів об'єкта облікового запису конкретного абонента безпеки.

Серверами служби каталогу Active Directory є тільки контролери доменів. На кожному з них зберігається копія каталогу, в яку можна вносити зміни. Це дозволяє створювати нові облікові записи, змінювати паролі і коригувати склад груп, звернувшись на будь-який контролер домену. Зміни, внесені в одну репліку каталогу, автоматично переносяться на всі інші його репліки. Правда, Windows не використовує для цієї мети протокол реплікації Kerberos. Копіювання та поширення інформації, що зберігається в Active Directory, проводиться за допомогою власного протоколу децентралізованої реплікації (multi-master replication protocol), розробленого корпорацією Microsoft, причому пересилання її здійснюється по захищених каналах між контролерами доменів.

Фізичним зберіганням інформації про облікові записи управляє агент DSA (Directory System Agent - агент системи каталогу). Цей захищений процес інтегрований з підсистемою LSA, що працює на контролері домену. Клієнти служби каталогу ніколи не отримують прямого доступу до сховища з даними про облікові записи. Будь-який клієнт, якому потрібна інформація з каталогу, повинен скористатися для підключення до DSA інтерфейсом ADSI (Active Directory Service Interface - інтерфейс служб Active Directory). Лише після цього він може шукати, читати і записувати об'єкти і їхні атрибути.

Запити на доступ до об'єктів чи атрибутів каталогу підлягають перевірці в системі управління доступом Windows . Подібно об'єктам файлів і папок у файловій системі NTFS, об'єкти Active Directory захищаються за допомогою ACL (Access Control List - список контролю доступу), де міститься інформація про те, хто і яким способом має право звертатися до об'єктів. Правда, в об'єктах Active Directory, на відміну від файлів і папок, список контролю доступу є для кожного атрибута. Самим секретним елементом будь-якого облікового запису, є пароль. В об'єкті облікового запису атрибут пароля зберігає не сам пароль, а криптографічний ключ, отриманий на його основі, однак цей ключ представляє для зловмисника не меншу цінність. З цієї причини доступ до атрибуту пароля надається виключно власнику облікового запису. Такого права не має ніхто інший, навіть адміністратор. Прочитати інформацію про пароль або змінити її можуть тільки процеси з привілеєм Trusted Computer Base, які працюють в контексті безпеки LSA.

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

2.7 Політика Kerberos

У середовищі Windows політика Kerberos визначається на рівні домену та реалізується службою KDC домену. Вона зберігається в каталозі Active Directory як підмножина атрибутів політики безпеки домену. За замовчуванням вносити зміни в політику Kerberos мають право тільки члени групи адміністраторів домену.

У політиці Kerberos передбачаються:

- Максимальний термін дії користувальницького білета (Maximum user ticket lifetime). Під «користувальницьким білетом» тут мається на увазі білет на видачу білетів (білет TGT). Значення задається в годинах і за замовчуванням дорівнює 10 год.

- Максимальний час, протягом якого допускається оновлення користувацького білета (Maximum lifetime that a user ticket can be renewed). Задається в добі; за замовчуванням становить 7 діб.

- Максимальний термін дії службової білета (Maximum service ticket lifetime). Під «службовим білетом» тут мається на увазі сеансовий білет. Значення цього параметра має бути більше 10 хвилин, але менше значення Maximum user ticket lifetime. За замовчуванням воно дорівнює 10 год.

- Максимально допустиме відхилення в синхронізації комп'ютерних годин (Maximum tolerance for synchronization of computer clocks). Зазначається у хвилинах; за замовчуванням дорівнює 5 хв.

- Перевірка обмежень при вході користувача в систему (Enforce user logon restrictions). Якщо цей пункт позначено прапорцем, служба KDC аналізує кожен запит на сеансовий білет і перевіряє, чи має даний користувач право на локальний вхід в систему (привілей Log on Locally) чи на доступ до запитуваного комп'ютера через мережу (привілей Access this computer from network). Така перевірка займає додатковий час і може сповільнити надання мережевих послуг, тому адміністратору надається право її відключення. За умовчанням вона включена.

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

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

Попередня автентифікація

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

Постачальник підтримки безпеки Kerberos

Протокол автентифікації Kerberos реалізований у формі постачальника підтримки безпеки (security support provider, скорочено SSP) - динамічно підключає бібліотеки, що входить до складу операційної системи. У Windows передбачено також постачальника SSP для протоколу NTLM. За замовчуванням обидва ці компоненти завантажуються підсистемою LSA на комп'ютер Windows одночасно із завантаженням операційної системи. Кожен з цих постачальників дозволяє виробляти автентифікацію як входу в мережу, так і клієнт-серверних підключень. Який постачальник буде використаний у тому чи іншому конкретному випадку, залежить від можливостей комп'ютера, з яким встановлюється зв'язок, проте, в першу чергу система завжди намагається скористатися постачальником Kerberos SSP.

Після того, як підсистема LSA створить контекст безпеки для інтерактивного користувача, може знадобитися ще один примірник Kerberos SSP. Його завантаження виробляє процес, запущений в призначеному для користувача контексті безпеки, щоб забезпечити підтримку підпису та завірення повідомлень.

Системні служби і додатки транспортного рівня звертаються до SSP через інтерфейс SSPI (Security Support Provider Interface - інтерфейс постачальника підтримки безпеки). Він представляє собою інтерфейс Win32 ®, що дозволяє переглянути список доступних на системі постачальників, вибрати один з них і використовувати його для організації автентифікованим підключення. Виконання всіх цих функцій проводиться в SSPI стандартизованими методами, свого роду підпрограмами «чорного ящика», якими розробник може користуватися, навіть не розбираючись в тонкощах самого протоколу. Наприклад, при автентифікації клієнт-серверного підключення пересилання посвідчення клієнтського додатка на сервер проводиться за допомогою методу InitializeSecurityContext. Якщо постачальник Kerberos SSP, цей метод генерує на клієнтському комп'ютері повідомлення KRB_AP_REQ. У відповідь серверний додаток, використовуючи метод AcceptSecurityContext, направляє клієнтові повідомлення KRB_AP_REP. Коли автентифікація підключення завершена, серверна підсистема LSA генерує маркер доступу, заснований на інформації з клієнтського білета. Після цього сервер звертається до методу SSPI під назвою ImpersonateSecurityContext і з його допомогою прикріплює маркер доступу до потоку.

Кеш-пам'ять посвідчень

На комп'ютерах під управлінням Windows білети і ключі, отримані зі служби KDC, зберігаються у кеш-пам'яті посвідчень - області оперативної пам'яті, захищеної підсистемою LSA. Вміст кеш-пам'яті посвідчень ніколи не скидається у файл підкачки. Вихід абонента безпеки із системи і відключення самої системи призводять до знищення всіх об'єктів що тут зберігаються.

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

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

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

Дозвіл імен DNS

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

Служба KDC встановлюється на всіх контролерах домену Windows. Крім функцій серверів KDC ці контролери виконують ще й функції серверів LDAP (Lightweight Directory Access Protocol - полегшений протокол доступу до каталогів). Обидві ці служби реєструються в записах покажчика служб системи DNS (записах ресурсів SRV). Щоб знайти контролер домену, клієнтові досить запросити на DNS запис ресурсу SRV з ім'ям _ldap._tcp.dc._msdcs.ІмяДоменаDNS. А запросивши запис ресурсу SRV з ім'ям _kerberos._udp.ІмяДоменаDNS, клієнт отримає у відповідь адресу служби KDC. Комп'ютери під керуванням Windows можуть звертатися і в ті області Kerberos, які не входять в домени Windows. Тут служба KDC розміщується на доменних контролерах, що працюють під управлінням інших операційних систем, тому імена DNS для таких серверів KDC доводиться зберігати в реєстрі клієнтського комп'ютера. У цьому випадку Kerberos SSP спочатку знаходить в реєстрі доменне ім'я DNS області користувача, а потім запитує відповідний сервер DNS і перетворює це ім'я в IP-адресу.

У Windows є спеціальна інструментальна програма, яка допомагає налаштовувати клієнтів для роботи з областями Kerberos, які не входять в домени Windows. Вона запускається файлом ksetup.exe з каталогу Support на компакт-диску Windows.

Транспорт IP

Для підключення до служби KDC клієнт повинен надіслати дейтаграму UDP на порт 88 відповідного IP-адреси. Служба KDC відповідає дейтаграмою на той порт IP-адреси відправника, звідки надійшов запит.

UDP відноситься до транспортних протоколів, не встановлює логічного з'єднання, тому його застосування цілком виправдано в тих випадках, коли організація підключення передбачає попередній обмін службовими повідомленнями. Цей протокол добре підходить і там, де обмін обмежується єдиним запитом і єдиною відповіддю на нього, як це має місце в сеансах зв'язку між клієнтом і службою KDC. Важливо тільки, щоб кожне таке повідомлення повністю вміщувалося в одну дейтаграму. Але найкращі результати застосування протоколу UDP дає в тих випадках, коли дейтаграми передаються як єдине ціле, тобто, кожна з них повністю вписується в один кадр. Ємність ж кадру залежить від передавальної середовища. У кадрі Ethernet, наприклад, максимальний розмір передаваного блоку даних (MTU) дорівнює 1 500 октетів. Отже, у фізичних мережах Ethernet повідомлення Kerberos, що відправляються у вигляді дейтаграм, можуть містити до 1 500 октетів даних.

Повідомлення з білетами для комп'ютерів Windows часто перевищують межу в 1 500 байт, тому для їх передачі використовується протокол ТСР.

Дані авторизації

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

Контроль доступу в Windows

У середовищі Windows передбачені спеціальні заходи захисту файлів та інших ресурсів від несанкціонованого доступу. Тема кожного об'єкта містить дескриптор безпеки зі списком контролю доступу ACL. Останній знаходиться в повному віданні власника об'єкта, який має право дозволяти і забороняти доступ до нього будь-якого абонента безпеки, а також визначати межі повноважень абонентів, яким дозволений доступ до цього об'єкта. Щоб забезпечити виконання заданих умов, операційна система проводить перевірку повноважень кожного разу, коли від програми надходить запит на ідентифікатор захищеного об'єкта. Перед тим, як видати відповідь, вона звертається до списку ACL об'єкта і переконується, що абонент безпеки, що використовує програму, може звертатися до цього об'єкта. Якщо таке право користувачеві не надано, доступ забороняється.

Кожному абонентові привласнюється унікальний ідентифікатор безпеки SID (Security Identifier) - алфавітно-цифрова послідовність, за структурою нагадує телефонний номер. Першу її частину можна порівняти з кодом міста, так як вона вказує на домен, який видав SID. Друга частина ідентифікатора визначає обліковий запис всередині домену, подібно до того, як остання група телефонного номера - номер конкретного телефону в місті. Код домену унікальний для підприємства, а код облікового запису не повторюється всередині домену. На відміну від телефонних номерів ідентифікатор безпеки ніколи не використовується повторно. Можливість отримати SID, вже належав раніше іншому користувачеві, повністю виключена.

Повноваження суб'єкта визначаються не тільки за ідентифікатором користувача, а й за його приналежності до однієї або декількох груп безпеки. Такий підхід значно спрощує оновлення списків ACL в мережах з тисячами користувачів і мільйонами об'єктів. Членством в групах адміністратор може управляти централізовано: щоб змінити рівень доступу конкретного користувача до багатьох ресурсів, його досить включити в певну групу або виключити з неї.

Управління безпекою ресурсів у середовищі Windows ще більше полегшується за рахунок застосування вкладених груп. Групу, створену в одному домені, можна включити до групи іншого домену або до універсальної групу, яка діє по всьому дереву доменів. У результаті цього в адміністратора з'являється чудова можливість: коли співробітник організації переводиться на інше місце, рівень його доступу до ресурсів можна змінити відразу по всьому підприємству, не зачепивши при цьому ні єдиного списку ACL.

Як і індивідуальні абоненти безпеки, кожна група безпеки Windows отримує власний ідентифікатор SID. Таким чином, права користувача на доступ до об'єктів, його контекст безпеки, визначаються кількома ідентифікаторами - одного його особистого плюс по одному на кожну групу, членом якої полягає даний користувач.

Як KDC готує дані авторизації

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

Отримавши від користувача запит на білет TGT, служба KDC того домену, де знаходиться обліковий запис користувача, звертається до Active Directory. Один з атрибутів облікового запису користувача містить його власний ідентифікатор SID, а інший - ідентифікатори всіх груп безпеки домену, в які цей користувач входить. Всі виявлені ідентифікатори передаються в KDC, де включаються до поля білета TGT, відведений під дані авторизації. У мережі з декількома доменами служба KDC, крім того, звертається в глобальний каталог Global Catalog за інформацією про універсальні групах, в які входить сам користувач або групи безпеки домену, членом яких він складається. Якщо такі універсальні групи знайдено, їх ідентифікатори SID включаються в те саме поле білета TGT.

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

Як дані авторизації використовуються службами

У середовищі Windows служби функціонують у власному контексті безпеки тільки при доступі до тих ресурсів, які знаходяться в їх повному розпорядженні. У більшості випадків це відбувається лише тоді, коли вони виконують внутрішні завдання: звертаються до даних реєстру, підключаються до комунікаційних портів або виконують інші операції, не пов'язані з роботою конкретного клієнта. Коли ж служба починає діяти за запитами клієнта, вона персоніфікує його, після чого переходить в контекст безпеки цього клієнта. Таким чином, службам Windows доводиться не тільки ідентифікувати клієнтів, але і враховувати деякі їхні характеристики, в першу чергу, рівень повноважень на цій системі.

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