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

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

В первой части мы рассмотрели общие положения по системе автоматической подачи заявок на сертификаты — autoenrollment и сегодня поговорим об одной составляющей этой системы — Automatic Certificate Request (или сокращённо просто ACR). Пержде чем начать экшн, следует поговорить о шаблонах версии 1.

Шаблоны версии 1 (V1 Templates)

При установке в лесу Enterprise Certification Authority, в Active Directory устанавливаются и преднастроенные шаблоны сертификатов. Зачем они нужны? Поскольку сертификаты у нас могут использоваться для решения различного рода задач, например, для SSL или аутентификации смарт-картой или для установки цифровой подписи файлов. В связи с этим конечные сертификаты будут очень сильно различаться по настройкам. Безусловно, очень трудно запомнить все требования для каждого типа сертификатов и вручную их заполнять. Для этого Microsoft с ролью CA поставляет ряд преднастроенных шаблонов, которые отвечают требованиям наиболее частых случаев использования. Чтобы посмотреть доступные шаблоны в лесу необходимо запустить оснастку Certificate Templates (certtmpl.msc) и получите примерно такое окно:

Здесь мы видим несколько колонок:

• Template Display Name — это отображаемое и понятное имя шаблона. Как правило используется только для отображения. Внутренние механизмы используют сокращённое common name;
• Minimum Supported CAs — указывает версию и редакцию ОС, под которой должна работать служба Certification Authority для выдачи такого сертификата.
• Version — внутренняя версия ревизии шаблона. Ревизия состоит из Major revision (число до точки) и Minor revision (число после точки). Имеет достаточно важное значение, о котором поговорим чуть ниже;
• Windows XP Autoenrollment — указывает, может ли данный шаблон использоваться для классического автоэнроллмента (только для шаблонов версии 2 и 3);
• Intended Purposes — уазывает целевое назначение сертификатов данного шаблона.

В настоящее время существует 3 версии шаблонов: 1, 2 и 3 версии. Важно понимать, что эти версии не имеют  ничего общего с внутренней версией конкретного шаблона, которая показана в оснастке. Что такое шаблоны версии 1? Это стандартные и неуправляемые шаблоны. Их можно отличить по одному из 2-х признаков:

• В колонке Minimum Supported CAs указано Windows 2000;
• Major revision является числом от 1 до 9.

шаблоны версии 1 являются преднастроенными и не поддерживают какую-либо модификацию, кроме назначения прав во вкладке Security. Microsoft в своё время хорошенько пожадничало (вплоть до выхода Windows Server 2008 R2), заставляя кастомеров приобретать Windows Server 2003/2008 Enterprise или Datacenter Edition редакции для серверов CA, поскольку только эти редакции могли издавать сертификаты на основе управляемых шаблонов версии 2 или 3 и использовать все возможности автоэнроллмента. И даже Windows Server 2008 Standard в этом плане был почти такой же, как и Windows 2000 Server. Но это было изменено с выходом Windows server 2008 R2, потому что PKI всё больше и больше входила в сектор малого бизнеса и адекватные инструменты им стали столь же необходимы как и более крупным компаниям. Именно по этой причине Windows Server 2008 R2 Standard Edition обладает большинством тех возможностей, которые раньше были доступны только в Enterprise и Datacenter редакциях.

Поскольку шаблоны версии 1 неуправляемы, поэтому тут говорить особо не о чем, поэтому продолжим дальше.

Automatic Certificate Request

Примечание: данный материал не охватывает всех особенностей, которые присущи для Windows 7 и Windows Server 2008 R2. О них пойдёт речь в следующих частях.

Но для кого-то это может стать секретом, но даже Windows 2000 (и Windows Server 2003/2008/2008R2 Std, EE, DC) поддерживали базовый автоэнроллмент — Automatic Certificate Request. Это позволяло автоматически распространять сертификаты для компьютеров на основе шаблонов версии 1. Для включения данного режима нужно сделать следующее:

• в оснастке CertSrv.msc любого Enterprise CA в секции Certificate Templates убедиться, что в списке присутствует нужный шаблон версии 1 (например, шаблон Computer или IPsec). Если нет, то All Tasks –> New –> Certificate Template to issue и добавить шаблон;
• в редакторе групповой политики (Group Policy Management) создать новый объект групповой политики или отредактировать существующую политику по адресу:
  Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Certificate Services Client — Autoenrollment
  данный элемент политики следует установить в состояние Enabled и при необходимости выбрать автоматическое обновление просроченных сертификатов и удалении отозванных сертификатов из хранилища. Этим самым мы включим сам Autoenrollment engine, который используется для ACR.
• в редакторе групповой политики (обычно в той же самой, где включали движок автоэнроллмента) по адресу:
  Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Automatic Certificate Request Settings
  создать необходимые запросы сертификатов. При этом в каждый элемент вы можете включить только один шаблон версии 1.
• прилинкуйте созданную или отредактированную политику к нужному OU (чаще всего её применяют для всего домена).

Примечание: опция Renew expired certificates, update pending certificates, and remove revoked certificates не позволяет удалять отозванные и/или просроченные сертификаты, у которых во вкладке Request Handling в списке Purposes содержится Encryption.

И как это работает.

При срабатывании триггера автоэнроллмента клиент считывает групповую политику с контроллера домена и определяет настройки политики. Эти настройки записываются в DWORD значение реестра AEFlags по адресу: HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Autoenrollment; Флаги могут иметь следующие значения или сумму следующих значений:

Примечание: триггер автоэнроллмента срабатывает при следующих действиях:

• обновление групповой политики;
• добавление машины в домен любым доступным способом.

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

Далее клиент скачивает сертификаты из 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.

На основе этих сертификатов обновляется локальное хранилище сертификатов. Теперь осталось получить список шаблонов из Active Directory по адресу:

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

После чего читается следующий раздел реестра:

HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ACRS\CTLs\<HashOfData>

в котором хранятся шаблоны для ACR (которые мы указали в политике). Шаблоны хранятся в BLOB формате. Когда шаблоны для ACR получены, клиент читает разрешения на шаблоны и из шаблонов выбирает только те, которые указаны в реестре и для которых у учёной записи компьютера есть права Read и Enroll.

Примечание: это частая ошибка, когда на компьютерные шаблоны не выданы права для учётной записи компьютера. И для успешного энроллмента, учётная запись компьютера или группа, в которой он состоит, должен иметь оба права: Read и Enroll.

Следующим этапом клиент генерирует 2 списка:

• ToBeAdded — в этот список попадут все сертификты, которые получены в результате последующих операций.
• ToBeDeleted — в этот список попадут все сертификаты, срок которых истёк и/или истекает (прошло более 80% срока жизни сертификата). А так же отозванные сертификаты.

Примечание: как я уже говорил, сертификаты у которых в Purpose содержится Encryption не помещаются в список ToBeRemoved.

Примечание: список ToBeDeleted будет создаваться только если выставлен чек-бокс Renew expired certificates, update pending certificates, and remove revoked certificates. В действительности процесс обработки этого списка отличается от написанного. Это сделано для лучшего понимания его работы. В реальности все сертификаты из контейнера Personal попадают в этот список, после чего за счёт фильтрации необходимые сертификаты удаляются из этого списка.

Клиент обновляет данные из контейнера Certificate Enrollment Requests локального хранилища сертификатов. В этом контейнере хранятся копии запросов на сертификаты, которые требуют ручного одобрения администратора CA и клиент удаляет те запросы, которые старше 60 дней. И клиент пытается получить сертификаты для каждого из запросов. Если статус запроса остаётся Pending (т.е. ещё не одобрен администратором), то переходит к следующему запросу. Если статус запроса Issued — клиент посылает запрос на получение сертификата. По получении сертификата, он помещается в список ToBeAdded. Если статус запроса Denied, то запрос удаляется из контейнера.

Примечание: эту операцию клиент будет делать только при условии, что в политике выставлен чек-бокс на Renew expired certificates, update pending certificates, and remove revoked certificates.

Когда запросы в ожидании обработаны, клиент обрабатывает контейнер Personal и список ToBeDeleted. Если сертификат на основе шаблона(-ов) политики ACR находится в контейнере Personal и содержится в списке ToBeDeleted, или вообще отсутствует в контейнере Personal, то для этих сертификатов генерируется новый запрос. Если сертификат есть в контейнере Personal, но не содержится в списке ToBeDeleted, то данный шаблон пропускается.

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

Сегодня мы посмотрели два интересных момента: особенности шаблонов версии 1 и работу Automatic Certificate Request. В следующих частях мы рассмотрим шаблоны версии 2 и 3 и классический автоэнроллмент. Так что не отключайтесь.

Сегодня начинаю публикацию достаточно обширного и объёмного материала про автоматическую подачу заявок на сертификаты (autoenrollment). Данная тема настолько проста и на столько же сложна. И я постараюсь заполнить все пробелы в этой теме и повторить то, что мы уже знаем. Безусловно можно надеяться на ТЗ (Тайное Знание), так что кроме очевидных вещей, немного треша ожидается.

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

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

Autoenrollment background

Цифровые сертификаты и службы управления ими достаточно плотно вошли в нашу повседневную жизнь. Многие компании внедряют у себя инфраструктуру цифровых сертификатов, чтобы получить высокий уровень безопасности. Сертификаты применяются для большого количества задач и из них наиболее популярные:

• шифрование данных;
• подпись данных;
• аутентификация.

При помощи сертификатов мы можем шифровать файлы, почту, сетевой трафик, удостоверять личность пользователя с применением двухфакторной аутентификации, подпись документов, почты для предотвращения несанкционированного изменения и подлога. Поэтому компании развёртывающие инфраструктуру PKI задаются вопросом максимально быстрого и удобного способа распространения сертификатов между пользователями и компьютерами. Начиная с Windows Server 2003, Microsoft предлагает унифицированное решение этой задачи — autoenrollment. С его помощью клиенты сами без участия людей подают заявки для получения сертификата на сервер CA и устанавливают выданные сертификаты во внутреннее хранилище сертификатов. Это позволяет распространить сертификаты на огромное количество компьютеров затратив на это минимум усилий. Даже в условиях небольших компаний (до 50 машин) ручной запрос и установка сертификатов будет крайне утомительным делом, поскольку недостаточно запросить сертификат, но и нужно вовремя его обновить. В обычных условиях пришлось бы держать выделенного человека, который будет следить за всеми сертификатов всех пользователей и компьютеров и платить ему зарплату. Именно для устранения этой проблемы и ускорению ввода PKI в эксплуатацию и был разработан автоэнроллмент.

Autoenrollment requirements

Примечание: данный цикл статей не будет затрагивать особенности эксплуатации автоэнроллмента для Windows 2000.

Для успешного внедрения автоэнроллмента требуются следующие компоненты:

• домен Active Directory;
• объект групповой политики;
• клиент под управлением Windows 2000 и выше. Клиент должен быть членом домена;
• Enterprise Certification Authority под управлением Windows Server 2003 и выше.

Примечание: не для всех операционных систем требуется жёсткое удовлетворение этим требованиям. Для более точных требований к ОС для каждого метода смотрите в таблице ниже.

Автоэнроллмент различает 2 метода автоматического распространения сертификатов:

• Automatic Certificate Request (ACR) — поддерживает автоматическое распространение сертификатов для компьютеров на основе шаблонов версии 1.
• Autoenrollment — поддерживает автоматическое распространение сертификатов для компьютеров и пользователей на основе шаблонов версии 2 и 3.
• XCEP Autoenrollment — поддерживает автоматическое распространение сертификатов для недоменных пользователей и компьютеров на основе шаблонов версии 2 и 3 с использованием HTTP в качестве транспорта.

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

Таблица 1: возможности использования автоэнроллмента для клиентов.

* Out of domain показывает возможность использование автоэнроллмента без членства клиента в домене Active Directory.
** Home редакции Windows XP и Windows Vista не поддерживают функции автоэнроллмента.

Данная таблица показывает, что клиенты под управлением Windows 2000 могут автоматически запрашивать сертификаты только на основе шаблонов версии 1 и только для компьютеров (ACR). Windows XP/2003 могут автоматически запрашивать сертификаты на основе шаблонов версии 1 и только для компьютеров (ACR) и шаблонов версии 2 для пользователей и компьютеров. Windows Vista/2008 позволяют автоматически запрашивать сертификаты на основе шаблонов версий 1, 2 и 3 с учётом общих ограничений шаблонов версии 1. А Windows 7/2008 R2 плюс к предыдущему могут использовать автоматическую подачу заявок без членства в домене с использованием технологии XCEP Autoenrollment.

Таблица 2: возможности Enterprise CA для реализации возможностей автоэнроллмента.

* колонка XCEP показывает возможность установки компонента HTTP-enrollment. Данный компонент может работыть на сервере без установки роли Certification Authority.
** Веб служба, реализующая возможности использования HTTP-enrollment должна работыть под управлением Windows Server 2008 R2 EE/DC.
*** Std означает Standard Edition, EE — Enterprise Edition; DC — Datacenter Edition. Itanium-based системы не поддерживают роль CA.

Данная таблица демонстрирует возможности Certification Authority в зависимости от версии и редакции ОС на которой эта роль установлена. Например, Windows Server 2003 и 2008 Std могут использовать только ACR и распространять сертификаты на основе шаблонов версии 1 и только для компьютеров. Windows Server 2003 EE/DC могут использовать как ACR, так и классический автоэнроллмент, автоматически распространяя сертификаты на основе шаблонов версии 2 как компьютерам, так и пользователям. А Windows Server 2008 EE/DC и редакции Windows Server 2008 R2 Std/EE/DC могут автоматически распространять сертификаты для пользователей и компьютеров на основе шаблонов версии 1 (ACR), 2 и 3.

Для общего введения этого должно быть более, чем достаточно. В ближайших частях мы кратко посмотрим на шаблоны сертификатов и более детально разберём работу ACR (Automatic Certificate Request).

продолжение следует…