Contents of this directory is archived and no longer updated.

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


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

Продолжаем тему автоэнроллмента и сегодня рассмотрим принцип т.н. «классической» модели автоматической подачи заявок на сертификаты. Данная модель поддерживается клиентами начиная с 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 обязательна!

В общем смысле, автоэнроллмент работает примерно так:

Autoenrollment behavior

Но дальше мы рассмотрим весь этот процесс более подробно.

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

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


Share this article:

Comments:

Дмитрий
Дмитрий 24.06.2010 04:17 (GMT+3) Certificate Autoenrollment от А до Я (часть 4) — user certificate autoenrollment

>>в редакторе групповой политики (Group Policy Management) создать новый объект групповой политики или отредактировать существующую политику по адресу: Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Certificate Services Client — Autoenrollment В пути указан лишний не существующий контейнер, правильный путь: Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Autoenrollment Для выдачи пользовательских сертификатов не требуется включать автоэнрол на машине, достаточно включить его в профиле, т.е. здесь User Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Autoenrollment Для любого энролмента также необходимо распространение сертификата корневого ЦС через политику Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Trusted Root Certification Authorities Есть еще подозрение, что XP не запрашивает пользовательских сертификатов, пока не будет получен сертификат на компьютер, но это пока только предположение. На Win7 компьютерный сертификат для получения пользовательского точно не требуется.

Дмитрий
Дмитрий 24.06.2010 04:46 (GMT+3) Certificate Autoenrollment от А до Я (часть 4) — user certificate autoenrollment

Есть еще нюанс с шаблонами. При дублировании шаблона, визард задает вопрос, какой минимальный уровень ЦС (Win2008 или Win2003) требуется для данного шаблона. По логике это относится только к ЦС, но на практике получается так: Если у вас ЦС на Win2008R2, для шаблона выбрали минимальный уровень Win2008, то XP не сможет использовать этот шаблон. Наверно в визарде было бы правильнее спросить, какой минимальный уровень ЦС и клиентов требуется для использования шаблона :)

Vadims Podāns
Vadims Podāns 24.06.2010 22:19 (GMT+3) Certificate Autoenrollment от А до Я (часть 4) — user certificate autoenrollment

> В пути указан лишний не существующий контейнер нет, пути к элементам политики у меня указаны правильные (справедливые для GPMC версии Vista/2008). > Для любого энролмента также необходимо распространение сертификата корневого ЦС через политику не требуется. Откуда вы это взяли? > Есть еще подозрение, что XP не запрашивает пользовательских сертификатов, пока не будет получен сертификат на компьютер, но это пока только предположение вы о том, какая секция политик (компьютерная или пользовательская) отрабатывает первее? В таком случае порядок обработки разделов одной политики значения не имеет.

Vadims Podāns
Vadims Podāns 24.06.2010 22:22 (GMT+3) Certificate Autoenrollment от А до Я (часть 4) — user certificate autoenrollment

> По логике это относится только к ЦС ну, вобщем-то да, так и есть. Т.е. выбираете версию 2 или 3. Шаблоны версии 3 могут издавать только CA под управлением не ниже Windows Server 2008 EE/DC, а клиенты начиная с Windows Vista. Логично предположить, что клиенты Windows XP/Server 2003 не будут поддерживать такие шаблоны. Так что проблем с мастером я не вижу.

Дмитрий
Дмитрий 28.06.2010 07:30 (GMT+3) Certificate Autoenrollment от А до Я (часть 4) — user certificate autoenrollment

>> Для любого энролмента также необходимо распространение сертификата корневого ЦС через политику >не требуется. Откуда вы это взяли? У меня не получилось заставить компьютер запросить автоэнролмент, если он не доверяет ЦС. Хотя возможно причины были в другом. У вас это получалось? >> Есть еще подозрение, что XP не запрашивает пользовательских сертификатов, пока не будет получен сертификат на компьютер, но это пока только предположение >вы о том, какая секция политик (компьютерная или пользовательская) отрабатывает первее? В таком случае порядок обработки разделов одной политики значения не имеет. Нет, у меня никак не шёл автоэнрол для пользовательского сертификата (на машину я специально не настраивал автоэнрол), даже попыток по логам не было, как только выдал машине сертификат, тутже получил и пользовательский. На самом деле, проблемы была в чем-то другом, сейчас у меня выдаются пользовательские сертификаты на XP не имеющих сертификатов компьютера.

Vadims Podāns
Vadims Podāns 28.06.2010 22:35 (GMT+3) Certificate Autoenrollment от А до Я (часть 4) — user certificate autoenrollment

> У меня не получилось заставить компьютер запросить автоэнролмент, если он не доверяет ЦС технически это возможно. Но в целом, я корневой сертификат распространяю через публикацию в Active Directory, в контейнере Certification Authorities. > На самом деле, проблемы была в чем-то другом действительно, проблема была в чём-то другом, поскольку эти вещи никак не взаимосвязаны (т.е. пользовательские сертификаты будут энролиться даже при отсутствии компьютерных). Безусловно, в ситуации стоило бы разобраться.

Di
Di 14.05.2012 10:40 (GMT+3) Certificate Autoenrollment от А до Я (часть 4) — user certificate autoenrollment

Вадим, здравствуйте. Подскажите, автоэнроллмент отвечает только за получение/обновление сертификатов в хранилище клиента? заменять сертификаты служб надо вручную?

Vadims Podāns
Vadims Podāns 14.05.2012 14:11 (GMT+3) Certificate Autoenrollment от А до Я (часть 4) — user certificate autoenrollment

Автоэнроллмент только доставляет сертификаты. А каждая конкретная служба сама должна выбирать себе сертификат из имеющихся (например, IPsec) или как-то добывать себе иным путём (как это может делать служба RDS). Некоторые службы (как IIS) не может автоматически выбирать сертификаты и их приходится назначать вручную.

Comments are closed.