1. Client bahavior
2. Certificate template sorting
3. Pended request processing
4. Certificate update and enrollment
5. Epilogue
6. Що далі?

Update 25.01.2010: додано обов'язкове включення галочки Update certificates that use certificate templates.

Посилання на інші матеріали з цієї серії:

Продовжуємо тему автоенроллмента і сьогодні розглянемо принцип т.зв. «Класичної» моделі автоматичної подачі заявок на сертифікати. Дана модель підтримується клієнтами починаючи з Windows XP і які є членами домену Active Directory.

Як і у випадку з Automatic Certificate Request (ACR), тригер автоенроллмента встановлюється в групових. Для його установки необхідно в редакторі групової політики вимкнути такі опції:

• в оснащенні CertSrv.msc будь-якого Enterprise CA в секції Certificate Templates переконатися, що в списку присутній потрібний шаблон версії 2 або 3. Якщо немає, то All Tasks -> New -> Certificate Template to issue і додати шаблон;
• в редакторі групової політики (Group Policy Management) створити новий об'єкт групової політики або змінити існуючу політику за адресою:
  Computer Configuration -> Windows Settings -> Security Settings -> Public Key Policies -> Certificate Services Client - Autoenrollment
  даний елемент політики слід встановити в стан Enabled, поставити галочку Update certificates that use certificate templates і при необхідності вибрати автоматичне оновлення прострочених сертифікатів і видаленні відкликаних сертифікатів зі сховища.
• Ті ж параметри налаштовуються і в секції User Configuration, щоб забезпечити автоматичне поширення сертифікатів користувача. Це можуть бути сертифікати EFS, підписи електронної пошти або сертифікати для аутентифікації користувачів:
  User Configuration -> Windows Settings -> Security Settings -> Public Key Policies -> Certificate Services Client - Autoenrollment
• прілінкуйте створену або відредаговану політику до потрібного OU (найчастіше її застосовують для всього домену).

Примітка: для успішного енроллмента сертифікатів на основі нових шаблонів (для яких у клієнта немає ще жодного сертифікату) галочка Update certificates that use certificate templates обов'язкове!

У загальному сенсі, автоенроллмент працює приблизно так:

Але далі ми розглянемо весь цей процес більш докладно.

Client bahavior

Коли спрацьовує тригер автоенроллмента, клієнт зчитує параметри з реєстру:

• HKLM \ SOFTWARE \ Policies \ Microsoft \ Cryptography \ Autoenrollment
• HKCU \ SOFTWARE \ Policies \ Microsoft \ Cryptography \ Autoenrollment

Дані розділи реєстру містять настройки автоенроллмента для конфігурації комп'ютера і користувача, відповідно (більш детальніше про вміст цих розділів реєстру читайте у другій частині ). Наступним кроком клієнт зчитує дані з Active Directory:

• сертифікати CA з контейнера за адресою:
  CN = AIA, CN = Public Key Services, CN = Services, CN = Configuration, DC = ForestRootDomain
• сертифікати кореневих CA з контейнера за адресою:
  CN = Certification Authorities, CN = Public Key Services, CN = Services, CN = Configuration, DC = ForestRootDomain
• сертифікати агентів відновлення з контейнера за адресою:
  CN = KRA, CN = Public Key Services, CN = Services, CN = Configuration, DC = ForestRootDomain
• сертифікати CA, які можуть видавати сертифікати для аутентифікації по Kerberos із запису NTAuthCertificates за адресою:
  CN = Public Key Services, CN = Services, CN = Configuration, DC = ForestRootDomain

На основі цих сертифікатів, клієнт оновлює свої локальні сховища. Далі, зчитуються всі шаблони і відомості про Enterprise CA з наступних контейнерів:

• CN = Certificate Templates, CN = Public Key Services, CN = Services, CN = Configuration, DC = ForestRootDomain
• CN = Enrollment Services, CN = Public Key Services, CN = Services, CN = Configuration, DC = ForestRootDomain

Після чого клієнт зчитує сертифікати з контейнера Personal і поміщає їх в процесинговий список, а так само генерує списки ToBeAdded і ToBeDeleted. У ці списки потраплять всі сертифікати, які будуть додані до локального сховища і видалені з нього, відповідно.

Примітка: в процесинговий список потрапляють тільки сертифікати засновані на шаблонах. Наприклад, самоподпісанного сертифікати EFS не потрапляють в цей список.

Certificate template sorting

І ось тут починається процес організації порядку обробки сертифікатів. Клієнт з отриманих шаблонів сертифікатів вибирає тільки ті, на які у користувача або комп'ютера (в залежності від контексту) є повне право: Read, Enroll і Autoenroll. Якщо ж хоч одного права не вистачає, то шаблон виключається зі списку. Для решти шаблонів перевіряється вміст Superseded Templates. Як я вже говорив в попередній частині, будь-який шаблон версії 2 або 3 може замінювати застарілий шаблон. Наприклад, новий шаблон Advanced EFS може замінювати шаблон Basic EFS. В такому випадку шаблон Advanced EFS вважається більш новим і всі власники сертифікатів шаблону Basic EFS отримають новий сертифікат шаблону Advanced EFS. Оскільки список Superseded Templates містить застарілі і невикористовувані більш шаблони, то вони так само виключаються зі списку. Наступним етапом виключаються шаблони, в настройках яких міститься:

• число This Number Of Authorized Signatures (у вкладці Issuance Requirements) більше 1;
• виставлений чек-бокс Supply in the request (у вкладці Subject name);
• виставлений чек-бокс Prompt the user during enrollment (у вкладці Request handling комп'ютерних шаблонів).

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

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

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

Pended request processing

Як і у випадку з ACR, клієнт після всіх підготовчих процедур намагається отримати сертифікати у відповідь на запити. Як ми вже знаємо, запити зберігаються в контейнері Certificate Enrollment Requests. Спершу клієнт видаляє всі запити, які старше 60 днів, а потім надсилає запит на CA для з'ясування статусу кожного запиту. Якщо у відповідь на запит був отриманий сертифікат, то він поміщається в список ToBeAdded. Якщо статус запиту Denied, то запит буде видалено. Якщо статус невідомий, клієнт переходить до наступного запиту.

Certificate update and enrollment

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

Примітка: прострочені сертифікати будуть поміщені в цей список тільки якщо в груповій політиці виставлений прапор Renew expired certificates, update pending certificates, and remove revoked certificates і сертифікат не використовується для шифрування.

Якщо термін дії сертифіката подолав позначку 80% і шаблон цього сертифіката знаходиться в списку доступних шаблонів (який був отриманий після декількох рівнів фільтрації в попередніх кроках), клієнт відправляє запит на оновлення сертифіката. При цьому запит підписується поточним сертифікатом. Якщо у відповідь на запит був отриманий сертифікат, клієнт поміщає його в список ToBeAdded.

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

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

Якщо версія шаблону (Major Version), який використовувався при попередньому енроллменте відрізняється від поточного Major Version шаблону, клієнт посилає запит на оновлення сертифіката. При цьому запит підписується поточним сертифікатом. Якщо у відповідь на запит був отриманий сертифікат, клієнт поміщає його в список ToBeAdded.

Примітка: при кожному редагуванні шаблону (крім вкладки Security) змінюється тільки Minor Version. І власники сертифікатів цього шаблону не побачать, що шаблон змінений, оскільки вони перевіряють лише Major Version. У разі, якщо після внесення змін до шаблону необхідно перевидати всі сертифікати цього шаблону, адміністратор повинен змінити Major Version. Для цього адміністратор в оснащенні certtmpl.msc повинен вибарть потрібний шаблон, натиснути правою кнопкою і вибарть Reenroll All Certificate Holders. Цей крок змінить Major Version шаблону і всі клієнти, які вже мають сертифікат даного шаблону його оновлять, отримавши новий сертифікат з новими змінами.

Якщо шаблон, який використовувався при попередньому енроллменте був замінений більш новим (вкладка Superseded Templates нового шаблону містить застарілий шаблон), клієнт відправляє запит на оновлення сертифіката. При цьому запит підписується поточним сертифікатом. Якщо у відповідь на запит був отриманий сертифікат, клієнт поміщає його в список ToBeAdded.

Для необроблених шаблонів клієнт відправляє запити на отримання сертифікатів на основі цих шаблону. Якщо у відповідь на запит був отриманий сертифікат, клієнт поміщає його в список ToBeAdded.

Epilogue

Коли всі запити, сертифікати та шаблони були оброблені, тригер автоенроллмента очищає список ToBeDeleted і всі сертифікати зі списку ToBeAdded копіює в контейнер Personal.

Як ви бачите, процес автоенроллмента в дуже ступеня схожий на процес Automatic Certificate Request і відрізняється лише додатковими кроками обробки шаблонів версії 2 і 3.

Що далі?

У цій та попередніх частинах ми розглянули основні концепції та особливості роботи Automatic Certificate Request і autoenrollment'а при використанні протоколу MS-WCCE , Заснованому на DCOM повідомленнях. В наступній частині буде розглянута концепція і порядок роботи автоенроллмента з використанням більш нового набору протоколів: MS-XCEP і MS-WSTEP / WS-TRUST, які значно розширюють наші можливості управління сертифікатами.

Що б почитати?