Делегування аутентификації підтримується в протоколі Kerberos версії 5 шляхом використання в сеансових квитках прапорів proxy і forwarding. Сервер Windows NT застосовує делегування для отримання сеансового квитка на доступ від імені клієнта до іншого сервера.
Взаємодія Kerberos
Протокол Kerberos версії 5 реалізований в різних системах і використовується для одноманітності аутентификація в розподіленій мережі.
Під взаємодією Kerberos мається на увазі загальний протокол, що дозволяє обліковим записам аутентифікованих користувачів, що зберігаються в одній базі (що можливо тиражується) на всіх платформах підприємства, здійснювати доступ до всіх сервісів в гетерогенного середовищі. Взаємодія Kerberos засновується на наступних характеристиках:
• загальний протокол аутентификації користувача або сервісу на основне ім'я при мережевому підключенні;
• можливість визначення довірчих відносин між областями Kerberos і створення посилальний запитів квитків між областями;
• підтримка певних вимог в RFC 1510 до взаємодії, що відносяться до алгоритмів шифрування і контрольних сум, взаємної аутентификація і інших можливостей квитків;
• підтримка форматів маркера безпеки Kerberos версії 5 для встановлення контексту і обміну повідомленнями так, як це визначене робочою групою lETFCommon Authentication Technology.
Підтримка Kerberos відкритих ключів
У Windows NT також реалізовані розширення протоколу Kerberos, підтримуючий додатково до аутентификацію з секретним загальним ключем використовується аутентификація, засновану на парах відкритого (закритого) ключа. Підтримка відкритих ключів дозволяє клієнтам запитувати початковий ключ TGT за допомогою закритого ключа, в той час як KDC перевіряє запит за допомогою відкритого ключа, отриманого з сертифіката Х.509 (зберігається в призначеному для користувача об'єкті в каталозі Active Directory), Сертифікат користувача може бути виданий як стороннім уповноваженим сертифікації (Certification Authority), так і Microsoft Certificate Server, що входить в Windows NT. Після початкової аутентификація закритим ключем використовуються стандартні протоколи Kerberos для отримання сеансових квитків на доступ до мережевих служб,
Підтримка протоколом Kerberos відкритих ключів - основа аутентификація в мережі за допомогою смарт-карт. Користувачі Windows NT 5.0 можуть їх застосовувати для входу в систему.
Сервер сертифікатів Microsoft Certificate Server
Сервер сертифікатів Microsoft Certificate Server надає організаціям спрощений, без звернення до зовнішніх ВУС (уповноваженим сертифікації), процес видачі сертифікатів. З його допомогою досягається повний контроль над правилами видачі, управління і відгуку сертифікатів, а також над форматом і змістом самих сертифікатів. Реєстрація всіх транзакцій дозволяє адміністратору відстежувати запити на видачу сертифікатів і управляти ними.
Certificate Server виконується у вигляді сервісу Windows NT і обробляє всі запити сертифікатів, випадки їх видачі, а також всі списки відгуку. Статус кожної операції з сертифікатами відстежується за допомогою черги транзакцій. По завершенні операції інформація про неї заноситься в журнал транзакцій для подальшої перевірки адміністратором.
Клієнт і вхідний модуль
Запит сертифіката поступає від будь-якого, підтримуючого цифрові сертифікати, клієнтського додатку. Це можливо, наприклад, програма перегляду сторінок Web, поштовий клієнт або клієнт електронного магазина. Точку входу Certificate Server - так званий вхідний модуль можна настроїти на прийом запитів в багатьох стандартних форматах. Вхідні модулі виконують дві основні функції: розпізнають протокол або транспортний механізм, що використовується запитуючим додатком, а також встановлюють з'єднання з сервером сертифікатів для передачі запитів. Якщо треба забезпечити так специфічні потреби, що це не під силу вхідним модулям, що поставляються, можна написати свій власний модуль, використовуючи інтерфейс СОМ, що надається Certificate Server.
Модуль черг і правил
Вхідний модуль передає запит у виконавчу частину сервера сертифікатів, де відбувається введення запиту в чергу, а далі передача в модуль правил. Саме там на основі додаткової інформації, що міститься в запиті визначається можливість видачі запитаного сертифіката. Так само, як і вхідний модуль, модуль правил є повністю таким, що настроюється.
У процесі прийняття рішення про видачу сертифіката, модуль правил може звернутися до зовнішніх баз даних, таких як каталог Active Directory, або успадкована база даних, або кредитна інформація від стороннього джерела, щоб перевірити надану інформацію. Також він може посилати адміністраторам попередження про необхідність видачі їм дозволи.
Після цього інформація упаковується в запит так, як вказана адміністратором. Модуль правил може бути настроєний на вставку будь-яких розширень сертифікатів, що зажадалися клієнтським додатком (наприклад, дані для оцінки купівельних можливостей клієнта).
Коли модуль правил повертає запит на надання сертифіката назад у виконавчий модуль, оновлюються черга, шифрування і цифровий підпис сертифіката, а також запис транзакції. У журнал заносяться не тільки всі запити, але і те, чи були вони задоволені або знехтувані. Там же з метою подальшого аудиту зберігаються всі видані сертифікати і списки відгуку сертифікатів.
Certificate Server передає сертифікат у вихідний модуль, який упаковує його у відповідний транспортний механізм або протокол. Так, сертифікат може бути переданий поштою, по мережі або вміщений в службі каталогів, наприклад, Active Directory.
Подібно вхідному модулю, вихідного також повністю настроюємо. Більш того в одному сервері допустимі декілька вихідних модулів, і один і той же сертифікат може бути не тільки відправлений клієнту, але і вміщений, наприклад, в репозитарій сертифікатів для подальшого використання (в тому числі для перевірки інформації в призначеному для користувача сертифікаті).
Для конфігурування, моніторинга і управління операціями на сервері в склад Certificate Server включений ряд адміністративних інструментів. Вони дозволяють модифікувати правила, додавати нові вхідний і вихідний модулі, переглядати чергу. Переглядаючи чергу, адміністратор може або відкинути запит про сертифікат або, навпаки, ініціювати його негайну видачу.
Безпека і Active Directory
У всіх попередніх версіях Windows NT інформація про облікові записи зберігалася в захищених гілках реєстру на контроллерах домена. Довірчі відносини між доменами і наскрізна аутентификація в дворівневих ієрархіях доменів дозволяли досить гнучко управляти обліковими записами і серверами ресурсів. Однак всередині кожного домена простір імен був плоским і не мав ніякої внутрішньої організації.
Розподілені служби безпеки Windows NT 5.0 використовують Active Directory як сховище облікової інформації. Active Directory значно перевершує реєстр по продуктивності і масштабованості. Особливо вражають її адміністративні можливості.
Розглянемо переваги інтегрованого управління обліковими записами службою каталогів Active Directory.
• Облікові записи користувачів, груп і машин можуть бути організовані у вигляді контейнерів каталога, званих, як вже згадувалося, організаційними одиницями OU. У домені допустиме довільне число OU, організованих у вигляді деревовидного простору імен у відповідності зі структурою організації користувача. Також як і OU, облікові записи окремих користувачів є об'єктами каталога. При зміні співробітниками місця роботи або посади облікові записи всередині дерева доменів можуть бути легко переміщені, і, таким чином, приведені у відповідність з новим положенням.
• Каталог Active Directory дозволяє враховувати набагато більше об'єктів користувачів, ніж реєстр. Розмір одного домена вже не обмежений продуктивністю сервера, що зберігає облікові записи. Дерево пов'язаних між собою доменів Windows NT може підтримувати великі і складні організаційні структури.
• Адміністрування облікової інформації розширене за рахунок графічних коштів управління Active Directory, а також за рахунок підтримки OLE DS в мовах сценаріїв. Загальні задачі адміністрування можуть бути вирішені у вигляді сценаріїв, що дозволяє автоматизувати їх виконання.
• Служба тиражування каталогів дає можливість мати декілька списів облікової інформації, причому оновлюватися ця інформація може в будь-якій копії, а не тільки на виділених первинних контроллерах домена. Протокол LDAP і синхронізація каталогів забезпечують механізми зв'язку каталога Windows NT з іншими каталогами на підприємстві.
Зберігання облікової інформації в Active Directory означає, що користувачі і групи представлені там у вигляді об'єктів каталога. Права на читання і запис можуть бути надані окремим особам, як по відношенню до всього об'єкта цілком, так і по відношенню до окремих його властивостей. Адміністратори можуть точно задавати, хто саме правомочний модифікувати інформацію про користувачів, і яку саме. Наприклад, оператору телефонної служби дозволяється змінювати інформацію про телефонні номери користувачів, але при цьому він не володіє привілеями системного оператора або адміністратора.
Поняття груп спростилося, і місце локальних і глобальних груп тепер займають просто об'єкти гpynn. З їх допомогою можна управляти як доступом до ресурсів в масштабі всього домена, так і до локальних ресурсів контроллера домена.
Між Active Directory і службами безпеки Windows NT існують фундаментальні відносини. У Active Directory зберігаються правила безпеки домена, що визначають порядок використання системи (обмеження паролів, обмеження на доступ до системи і інш.). Об'єкти каталога, що відносяться до безпеки, повинні бути захищені від несанкціонованого доступу. У Windows NT реалізована об'єктна модель безпеки і контролю за доступом до всіх об'єктів в каталозі Active Directory. У кожного об'єкта є свій унікальний дескриптор захисту, що визначає дозволи на читання або оновлення властивостей об'єкта.
Для визначення прав даного клієнта прочитувати або модифікувати певний об'єкт в Active Directory служить імперсонація і верифікація доступу Windows NT. Іншими словами, при надходженні LDAP-запита від клієнта доступ до об'єктів каталога контролюється операційною системою, а не службою каталогів Active Directory.