Former blog - PKI Extensions
Сьогодні хочу поговорити і позначити неочевидні моменти, які пов'язані з енроллментом сертифікатів від імені іншого користувача. У певних сценаріях адміністратору (або агенту подачі заявок на сертифікати) потрібно запитувати сертифікати від імені іншого користувача. Як приклад такого сценарію - поширення смарт-карт на підприємстві. В такому випадку в організації виділяється спеціальна людина, яка буде цим займатися. Ця людина буде називатися Enrollment Agent і в його завдання буде входити:
- реєстрація, адміністрування і заміна смарт-карт;
- контроль видачі смарт-карт. Смарт-карти можуть видаватися тільки після співбесіди з співробітниками, яким потрібні смарт-карти;
- запит і установка сертифікатів на смарт-карти;
- видача готової до експлуатації смарт-карти кінцевим користувачам.
Для вирішення цього завдання Windows CA (будь то Standalone або Enterprise CA і CA може працювати під управлінням будь-якої версії Windows Server) пропонує можливість реалізації даного завдання через використання Enroll On Behalf Of (EOBO). Суть методу полягає в тому, що такий агент отримує для себе спеціальний сертифікат на основі шаблону Enrollment Agent (або будь-якого іншого шаблону), який відповідає двом вимогам:
- в Request Handling тип використання ключа містить Signature;
- в Application Policies (в минулому Extended Key Usage або просто EKU) виставлено Certificate Request Agent.
Примітка: з метою безпеки слід налаштувати обмеження для запиту сертифікатів на основі цього шаблону і після видачі сертифікатів за потрібне агентам, видалити його з видачі CA. Так само настійно рекомендується зробити шаблон версії 2 і використовувати CSP смарт-карти, щоб даний сертифікат не зберігати в профілі користувача, а на смарт-карті.
Після цього цей агент може запитувати сертифікати для інших користувачів. Для цього агент запускає оснащення certmgr.msc, в ній переходить на Personal -> Certificates -> Action -> All Tasks -> Advanced Operations -> Enroll On Behalf Of ... і починає процес подачі заявки на сертифікат. У другому вікні майстра агенту потрібно вказати свій сертифікат Enrollment Agent. Цей крок необхідний для того, щоб довести, що агент є Enrollment Agent'ом і цей сертифікат буде використовуватися для підписування запиту сертифіката. У вікні вибору шаблонів ви швидше за все побачите тільки доступні шаблони версії 1:
У мене є кілька шаблонів версії 2, але запитувати для них сертифікати я не можу. Повідомлення відмови в запиті таких сертифікатів дуже каламутне і не дуже зрозуміле. Оскільки шаблони версії 1 не можуть бути змінені, вони штатно підтримують режим EOBO. А шаблони версії 2 і 3 слід настроїти окремо. Для цього вам потрібно відкрити властивості шаблону, перейти на вкладку Issuance Requirements і відредагувати його так, щоб він виглядав як на зображенні:
Тобто ви повинні вказати, що запит повинен бути підписаний сертифікатом, Application Policies якого містить Certifcate Request Agent.
Взагалі тут розгулятися можна як слід. При наявності спеціальних вимог, ви можете створити певні робочі процеси (workflows). Наприклад, в шаблоні сертифіката Enrollment Agent, який вимагає зберігання сертифіката на смарт-карті (явно вказано тільки CSP смарт-карти) в Issuance Policies (Certificate Policies) можете створити окрему політику видачі, наприклад Smart Card Enrollment Agent, призначивши цій політиці свій OID. Таким чином у вас може бути 2 Enrollment Agent'а, один з яких видає смарт-карти з сертифікатами для цифрових підписів, а інший агент буде видавати сертифікати смарт-карт для шифрування файлів. При цьому перший агент буде зберігати свій сертифікат Enrollment Agent на смарт-карті, а другий в профілі користувача. У сертифікаті Enrollment Agent першого агента в Certificate Policies буде вказано OID, який ви привласнили політиці Smart Card Enrollment Agent. Сертифікат другого агента нічого очікувати утримувати особливих політик видачі (використовується стандартний шаблон Enrollment Agent версії 1).
Щоб розділити шаблони між агентами ви можете їх налаштувати ось так:
Ми тепер вимагаємо, щоб сертифікат агента подачі заявок не тільки містив певний Application Policy, а й Issuance Policy теж. Це означає, що агент подачі заявок, який зберігає свій сертифікат в профілі не матиме можливості запитувати сертифікати такого шаблону. Ось вам ще один сценарій використання OID'ов. Це на випадок, щоб ви не думали, що це якась міфічна нікому не потрібна фігня.
Власне, після цього налаштування шаблонів версії 2 і 3 ви можете їх використовувати в EOBO:
Крім цього, ви можете ще більше точно окреслити можливості агентів відновлення:
Починаючи з Windows Server 2008, ви можете задавати більш гранульовані права для enrollment agent'ов, вказуючи яким агентам які сертифікати можна запитувати з використанням EOBO.
Даний матеріал не претендує на статус ТЗ (Таємне Знання), але дає величезну поживу для роздумів адміністраторам середніх і великих компаній на предмет того, як можна розширити можливості використання PKI і створити більш чіткий поділ обов'язків агентів подачі заявок (Enrollment Agent) при використанні функції Enroll On Behalf Of (EOBO). Як ви бачите, Windows PKI навіть з коробки дозволяє досить просто масштабувати і керувати вашої інфраструктурою PKI. А так же ми майоріли міф про те, що інфраструктурою PKI може рулити студент-ПТУшнік (петушатнік?), Який піднімає CA на коліні в метро.
Для великих компаній існують ще більш потужні й гнучкі засоби для виконання подібних завдань, які є в таких продуктах як Identity Lifecycle Manager (ILM) 2007 або в Forefront Identity Manager, але про них ми говорити не будемо.
Додаткові матеріали: Що в OID'е тобі моєму?
Це була реклама студентів ПТУ.
Петушатнік?