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

Ссылки на другие материалы из этой серии:

•  Certificate Autoenrollment от А до Я — подведение итогов

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

Group Policy settings

Как и в случае с 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, которые значительно расширяют наши возможности управления сертификатами.

Что бы почитать?

• Certificate Autoenrollment in Windows Server 2003
• [MS-WCCE]
• [MS-CAESO]