Сегодня хочу поговорить и обозначить неочевидные моменты, которые связаны с энроллментом сертификатов от имени другого пользователя. В определённых сценариях администратору (или агенту подачи заявок на сертификаты) требуется запрашивать сертификаты от имени другого пользователя. Как пример такого сценария — распространение смарт-карт на предприятии. В таком случае в организации выделяется специальный человек, который будет этим заниматься. Этот человек будет называться Enrollment Agent и в его задачи будет входить:

• регистрация, администрирование и замена смарт-карт;
• контроль выдачи смарт-карт. Смарт-карты могут выдаваться только после собеседования с сотрудниками, которым требуются смарт-карты;
• запрос и установка сертификатов на смарт-карты;
• выдача готовой к эксплуатации смарт-карты конечным пользователям.

Для решения этой задачи Windows CA (будь то Standalone или Enterprise CA и CA может работать под управлением любой версии Windows Server) предлагает возможность реализации данной задачи через использование Enroll On Behalf Of (EOBO). Суть метода заключается в том, что такой агент получает для себя специальный сертификат на основе шаблона Enrollment Agent (или любого другого шаблона), который отвечает двум требованиям:

1. в Request Handling тип использования ключа содержит Signature;
2. в 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'е тебе моём?

Это была реклама студентов ПТУ.