Примечание: материал данной статьи относится только к клиентам под управлении Windows 7/Server 2008 R2 или выше.

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

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

В предыдущей части мы кратко просмотрели назначение новых протоколов [MS-XCEP] и [MS-WSTEP], которые позволяют автоматически подавать заявки на сертификаты без непосредственного подключения к домену. Сегодня мы посмотрим порядок работы клиента автоэнроллмента с этими протоколами.

Примечание: для недоменных клиентов доступна возможность использования только автоэнроллмента. ACR (Automatic Certificate Request) для не поддерживается.

Group Policy configuration

После установки службы CEP у вас появляется адрес HTTP, который указывает на сервер CEP и этот адрес имеет вид:

https://www.example.com/ADPolicyProvider_CEP_auth_protocol/service.svc/CEP

где auth_protocol указывает на протокол аутентификации клиента на сервере CEP. Это может быть Kerberos (только для доменных клиентов), Password или Certificate. Вот этот адрес нужно добавить в настройки групповой политики. Для этого откройте редактор групповой политики (gpmc.msc или gpedit.msc для недоменных машин) и в секции: Computer Configurtion\Windows Settings\Security Settings\Public Key Policies настроить параметр Certificate Services Client — Certificate Enrollment Policy. В свойствах следует включить эту политику и вы увидите окно Certificate Enrollment Policy list и в котором уже одна политика будет определена. Предопределённую политику следует удалить совсем и кнопкой Add добавить новую. В открывшемся окне вставить эту ссылку, указать нужный тип аутентификации и нажать Validate. В результате вы должны получить нечто вроде такого:

fig.1

Если вам это удалось сделать, значит клиент смог успешно пообщаться с сервером XCEP и CES. Причём, вы увидите, что клиент по этой ссылке смог найти название данной политики и вставить её в окошко:

fig.2

И таким образом вы можете добавлять несколько различных адресов политик, которые могут относиться к различным организациям. Причём, организация может развернуть несколько серверов XCEP для обеспечения высокой доступности, тогда вы можете добавлять несколько адресов серверов CEP и они будут линковаться к одной политике.

Следует чётко понимать, что на предыдущей картинке вы видите коллекцию серверов CEP (Policy collection). Каждое имя уникально идентифицирует политику, которая может поддерживаться несколькими серверами CEP. Чтобы посмотреть сколько серверов CEP обслуживают ту или иную политику, выделите нужную политику и нажмите Properties. В результате вы увидите нечто похожее на это:

fig.3

Уникальность политики определяется по её GUID'у. В этом окне может формироваться список всех серверов CEP, которые обслуживают одну и ту же политику (с одинаковым GUID'ом). По умолчанию для всех политик включается разрешение автоэнроллмента.

Примечание: галочка Enable for automatic enrollment and renewal не является самодостаточной и зависит от классической политики автоэнроллмента. Если автоэнроллмент отключен, то соответственно, автоматическая подача заявок на сертификаты производиться не будет.

Как обычно, триггер автоэнроллмента устанавливается в групповых политиках. Для его установки необходимо в редакторе групповой политики выключить следующие опции:

• создать новый объект групповой политики или отредактировать существующую политику по адресу:
  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 обязательна!

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

fig.4

Client behavior

Примечание: по причине громоздкости текста, я не буду приводить содержание ответа сервера XCEP. Но его cтруктуру можно увидеть в  §4.1.1.2 (GetPoliciesResponse Response) документа [MS-XCEP]. Поэтому я буду подразумевать, что вы ознакомились с его примерным содержанием.

Когда срабатывает триггер автоэнроллмента, клиент считывает параметры из реестра:

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

Данные разделы реестра содержат настройки автоэнроллмента для конфигурации компьютера и пользователя, соответственно (более подробней о содержимом этих разделов реестра читайте во второй части). А так же будет считывать следующие ключи реестра:

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

Данные ключи будут содержать подключи политик. Каждому подключу политики присваивается уникальный GUID и внутри него будет содержаться необходимая информация о каждой политике, как URI, метод аутентификации, «стоимость» политики и флаги автоэнроллмента. После этого происходит сортировка политик по следующим правилам:

• сортируются по «стоимости» политики. Политика с меньшей стоимостью будет более приоритетной и политика с большей стоимостью будет менее приоритетной, соответственно. Если 2 и более политик имеют одинаковую стоимость, то идёт второй уровень сортировок по методу аутентификации (в порядке приоритета):
  • используется аутентификация Kerberos;
  • используется анонимная аутентификация;
  • остальные политики используются в том порядке, в каком они записаны в реестре.

Когда политики отсортированы, клиент подключается к серверу XCEP из каждой политики по HTTPS. Если по какой-то ссылке не удаётся подключиться или сервер возвращает ошибку (SOAP), клиент переходит к следующей ссылке. Если в ответ получены политики, клиент извлекает следующие параметры:

• адрес или адреса серверов CES;
• список серверов CA, на работу с которыми настроен сервер CES. Один сервер CES должен быть настроен на работу с неболее, чем одним сервером CA;
• список шаблонов и их параметры.

Pended request processing

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

Certificate update and enrollment

После обработки всех ожидающих запросов, клиент проверяет статус каждого существующего сертификата. Если сертификат отозван или его срок истёк, он помещается в список ToBeDeleted.

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

Если срок действия сертификата преодолел отметку 80% и шаблон этого сертификата находится в списке доступных шаблонов (который был получен после нескольких уровней фильтрации в предыдущих шагах), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в реестре для текущего сертификата указан PolicyID, клиент будет пытаться найти тот же ID в списке политик CEP и запрос на обновление сертификата отправлять на сервер CES, который указан в политике. Если PolicyID для текущего сертификата не указан, то запрос будет отправляться на тот сервер CES, политика которого является по умолчанию (см fig.2). Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.

Примечание: здесь и далее. Если по каким-либо причинам запрос подписать невозможно, клиент вместо обновления сертификата выполняет стандартную процедуру запроса сертификата с генерацией новой ключевой пары.

Примечание: здесь и далее. Если необходимый шаблон находится в выдаче более одного CA, клиент по очереди посылает запрос на каждый сервер CES в соответствии с их сортировкой.

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

Примечание: при каждом редактировании шаблона (кроме вкладки Security) изменяется только Minor Version. И держатели сертификатов этого шаблона не увидят, что шаблон изменён, поскольку они проверяют только Major Version. В случае, если после внесения изменений в шаблон необходимо переиздать все сертификаты этого шаблона, администратор должен изменить Major Version. Для этого администратор в оснастке certtmpl.msc должен выбарть нужный шаблон, нажать правой кнопкой и выбарть Reenroll All Certificate Holders. Этот шаг изменит Major Version шаблона и все клиенты, которые уже имеют сертификат данного шаблона его обновят, получив новый сертификат с новыми изменениями.

Если шаблон, который использовался при предыдущем энроллменте был заменён более новым (вкладка Superseded Templates нового шаблона содержит устаревший шаблон), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в реестре для текущего сертификата указан PolicyID, клиент будет пытаться найти тот же ID в списке политик CEP и запрос на обновление сертификата отправлять на сервер CES, который указан в политике. Если PolicyID для текущего сертификата не указан, запрос будет отправляться на тот сервер CES, политика которого является по умолчанию (см fig.2). Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.

Для необработанных шаблонов клиент отправляет запросы на получение сертификатов на основе этих шаблонов.Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.

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

Epilogue

Вот, вроде и всё. На этом я завершаю цикл статей, посвящённых Certificate Autoenrollment во всех его вариациях и с рассказом о новых возможностях Windows 7 и Windows Server 2008 R2. Рассказал как умел и, мне кажется, материал получился достаточно исчерпывающим и у читателя должно появиться понимание принципа работы всех внутренних механизмов. Если что-то осталось непонятным или появились вопросы — комментарии внизу :)

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

• [MS-XCEP]
• [MS-WSTEP]
• Certificate Enrollment Web Services in Windows Server 2008 R2