Після цього інформація упаковується в запит так, як вказана адміністратором. Модуль правил може бути настроєний на вставку будь-яких розширень сертифікатів, що зажадалися клієнтським додатком (наприклад, дані для оцінки купівельних можливостей клієнта).
Коли модуль правил повертає запит на надання сертифіката назад у виконавчий модуль, оновлюються черга, шифрування і цифровий підпис сертифіката, а також запис транзакції. У журнал заносяться не тільки всі запити, але і те, чи були вони задоволені або знехтувані. Там же з метою подальшого аудиту зберігаються всі видані сертифікати і списки відгуку сертифікатів.
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.
Модель безпеки Windows NT забезпечує однорідний і уніфікований механізм контролю за доступом до ресурсів домена на основі членства в групах. Компоненти безпеки Windows NT довіряють інформації, що зберігається в каталозі про захист. Наприклад, сервіс аутентификація Windows NT зберігає зашифровані паролі користувачів в безпечній частині каталога об'єктів користувача. За замовчанням операційна система «вважає», що правила безпеки захищені і не можуть бути змінені будь-ким несанкціоновано. Загальна політика безпеки домена також зберігається в каталозі Active Directory.
Довірчі відносини між доменами
У Windows NT 5.0 домени можуть бути організовані у вигляді ієрархічних дерев. Між доменами встановлюються довірчі відносини, Підтримуються два види таких відносин:
• явні однонаправлені довірчі відносини з доменами Windows NT 4.0;
• двосторонні транзитивні довірчі відносини між всіма доменами, що входять в дерево.
Явні відносини довір'я встановлюються не тільки з доменами старого типу, але і в тому випадку, коли неявні двосторонні відносини не придатні для використання: наприклад, для домена фінансового відділу або бухгалтерії. Встановлення явних односторонніх довірчих відносин автоматично відміняє неявні довірчі відносини Kerberos.
Проте, у великій організації явні односторонні відносини потрібні не так уже часто. Неявні двосторонні довірчі відносини значно полегшують управління обліковими записами з декількох доменів, оскільки всі домени в дереві неявно довіряють один одному.
Делегування адміністративних повноважень
Делегування адміністративних повноважень - гнучкий інструмент обмеження адміністративної діяльності рамками частини домена. Цей метод дозволяє надати окремим співробітникам можливість управління користувачами або групами в заданих межах і, в той же час, не дає їм прав на управління обліковими записами, що відносяться до інших підрозділів.
Права на визначення нових користувачів або створення груп користувачів делегуються на рівні OU або контейнера, в якому створений обліковий запис. Адміністратори груп однієї організаційної одиниці не завжди мають можливість створювати облікові записи того ж самого домена, що відносяться до іншої організаційної одиниці або управляти ними. Однак доменні правила і права доступу, визначені на більш високих рівнях каталога, можуть бути застосовані по всьому дереву за допомогою механізму успадкування.
Існує три способи делегування адміністративних повноважень:
• на зміну властивостей певного контейнера, наприклад, LocalDomainPolicies самого домена;
• на створення і видалення дочірніх об'єктів певного типу (користувачі, групи, принтери і ін.) всередині OU;
• на оновлення певних властивостей деяких дочірніх об'єктів всередині OU (наприклад, право встановлювати пароль для об'єктів типу User).
Делегувати повноваження просто. Досить вибрати особу, якій будуть делеговані повноваження, і указати, які саме повноваження передаються. Інтерфейс програми адміністрування Active Directory дозволяє без ускладнень переглядати інформацію про делегування, визначену для контейнерів.
Детальне призначення прав доступу
Звичайно у великій організації за забезпечення безпеки і підтримки інфраструктури мережі відповідають декілька чоловік або груп. Отже, повинна існувати можливість надавати таким особам або групам права на виконання певних операцій без права створення додаткових облікових записів і впливу на властивості інших облікових записів.
Архітектурою безпеки об'єктів Active Directory використовуються дескриптори захисту Windows NT для контролю за доступом до об'єктів. Кожний об'єкт в каталозі має унікальний дескриптор захисту. Вхідний в дескриптор список контролю доступу ACL (Access Control List), містить рядки, що визначають дозвіл або заборону на певні види доступу для окремих осіб або груп. Права доступу можуть бути надані або заборонені в різній мірі. Існують рівні прав доступу, що розрізнюються застосуванням до:
• об'єкту загалом (при цьому зачіпаються всі властивості об'єкта);
• групі властивостей, визначеній наборами властивостей всередині об'єкта;
• окремій властивості об'єкта.
За умовчанням доступ для читання і запису до всіх властивостей об'єкта отримує творець об'єкта.
Заборона або надання доступу до групи властивостей зручна для визначення родинних властивостей. Групування властивостей виконується відповідним атрибутом властивості в схемі. Взаємовідносини наборів властивостей можна змінювати, модифікуючи схему.
Нарешті, призначення прав доступу до окремих властивостей являє собою найвищий рівень деталізування, застосовний до всіх об'єктів Active Directory.
Контейнерні об'єкти в каталозі також підтримують детализація доступу, регламентуючи, хто має право створювати дочірні об'єкти і якого типу. Наприклад, правило доступу, визначене на рівні організаційної одиниці, може визначати, хто має право створювати об'єкти типу User (користувачі) в цьому контейнері. Інше правило в цієї ж OU може визначати, хто має право створювати об'єкти типу Printer.
Страницы: 1, 2, 3, 4, 5, 6, 7
