Contents of this directory is archived and no longer updated.

Posts on this page:

AppLocker — порядок работы правил
Планирование расширений CDP и AIA
Немного про Web Enrollment Pages
Certificate Autoenrollment от А до Я — подведение итогов
Certificate Autoenrollment от А до Я (часть 6) — XCEP/WSTEP Autoenrollment

AppLocker — порядок работы правил

Примечание: для успешного освоения данного материала, необходимо прочитать мою предыдущую запись по теме: Встречаем – AppLocker!

Я в своё время написал пост о порядке сортировки правил в Software Restriction Policies (Секреты Software Restriction Policies (часть 4)). Некоторые вопросы в интернетах говорят мне о том, что с AppLocker'ом люди не особо разобрались и сильно путаются. Виной тому — полное отсутствие вменяемой документации по вопросам практической реализации и отсутствие серого вещества у некоторых администраторов. Сегодня я покажу как AppLocker выявляет результирующий статус для запускаемого приложения/скрипта.

В Software Restriction Policies правила достаточно простые, хотя и со своими тараканами. Например, у нас есть возможность использовать один из двух уровней по умолчанию — Disallowed и Unrestricted. Правила в SRP так же могут быть определены одним из двух уровней (на самом деле в SRP ещё есть Basic User, но я его опускаю, как незначительный момент). Т.е. правило либо однозначно запрещает, либо однозначно разрешает вне зависимости от уровня по умолчанию. А результирующий уровень определялся нехитрым методом сортировок правил.

С AppLocker'ом ситуация немного иная. Теперь уровень по умолчанию только Disallowed. Т.е. запрещено всё, что не разрешено. Вроде бы и просто, но сами правила стали немного сложнее — появились исключения. В результате этих исключений значительно усложнилась и изменилась методика определения результирующего уровня для запускаемого файла.

Примечание: под «файлом» я здесь подразумеваю файл с расширением, контролируемым в AppLocker'е.

Итак, AppLocker позволяет создавать правила с уровнем Deny или Allow. Каждое правило пути или издателя (Publisher), кроме правила хешей, могут содержать исключения. Поскольку правило издателя не может уникально идентифицировать конкретный файл, т.к. поле Subject сертификата достаточно абстрактное понятие и под одно такое правило может подпадать сотни различных файлов. Причём, ситуация усугубляется тем, что в Software Restriction Policies в правило сертификата указывался конкретный сертификат подписи, AppLocker их просто перестаёт различать! Т.е. область действия правила издателя становится ещё шире, чем с классическими правилами сертификатов в SRP. То же самое и с правилами пути, поскольку по указанному пути сегодня может быть один файл, а завтра уже другой. Но для AppLocker'а это будет всё один файл. А ещё могут быть ситуации, когда по некоторому пути нужно разрешить всё, кроме какого-то набора файлов. Недостатки (и достоинства одновременно) компенсируются наличием в правилах исключений. Исключения позволяют значительно сократить количество правил в AppLocker'е.

Примечание: Единственный способ уникальной идентификации файла в AppLocker'е (равно как и в SRP) может быть только правило хеша, поскольку хеш условно говоря уникально идентифицирует файл (в пределах коллизий хеша). Именно по этой причине правило хеша не поддерживает возможность использования исключений.

Основной сценарий, который многих сбивает с толку: создаём запрещающее правило по правилу издателя или правилу пути. Однако определённые файлы, подпадающие под этот запрет должны быть разрешены для запуска. Для этих целей мы можем смело воспользоваться исключениями. Поэтому мы вносим такие файлы в исключения по пути, хешу или издателю. И, казалось бы, исключение из запрета означает явное разрешение. На первый взгляд это так и есть. Однако, следует помнить, что AppLocker использует неотключаемое действие по умолчанию — Disallowed. И когда файл выпадает из явного запрета, он не разрешается автоматически, поскольку подпадает под действие по умолчанию, если нет явного разрешения. Вот такие пирожки. Следовательно, можно вывести общий постулат AppLocker'а: разрешённый файл не должен быть явно запрещён и должен быть явно разрешён. Этот постулат будет доказан и продемонстрирован чуть ниже.

Если SRP использовал сортировку правил по их типу, устанавливая заданный приоритет для каждого вида, AppLocker более не использует такой метод. Запрет по правилу пути не может быть перекрыт даже разрешением по хешу или правилу издателя, как это работает в SRP. AppLocker сортирует правила по их действию — Deny и Allow. Запреты отрабатываются в первую очередь и затем разрешения. Опираясь на мои исследования я составил примерно такой алгоритм работы правил аплокера:

Сначала проверяются все явные запреты (в произвольном порядке).
- Если файл подпал под явный запрет, то для этого запрета отрабатываются все исключения. Если файл всё ещё подпадает под явный запрет, то файл помещается в список «Denied» и блокируется для запуска. Остальные шаги проверки не производятся.
- Если после обработки исключений больше не подпадает под явный запрет, то берётся следующее запрещающее правило и так продолжается, пока не будут проверены все явные запреты.
- Если после отработки всех запретов, файл больше не подпадает под явный запрет, он помещается в список «Processing».
Если файл находится в списке «Processing», файл проходит через второй этап проверки. Если список «Processing» пуст, файл не проходит через второй этап и хмуро блокируется для запуска.

Если файл подпал под явное разрешение, то для этого разрешения отрабатываются все исключения. Если файл всё ещё подпадает под разрешение, файл помещается в список «Allowed» и разрешается для запуска. Остальные шаги проверки не производятся.
Если после обработки исключений файл больше не подпадает под явное разрешение, то берётся следующее разрешающее правило, и процесс повторяется для каждого разрешающего правила.
Если после отработки всех разрешений, файл всё ещё находится в списке «Processing», к файлу применяется действие по умолчанию. Т.е. файл блокируется для запуска.

Примечание: на самом деле никаких таких списков не существует, это я всё соврал. Я их придумал только для улучшения понимания.

Для наглядной демонстрации алгоритма я нарисовал следующую картинку:

AppLocker rule processing diagram

Ну и в качестве бонуса — практическая задача, которая продемонстрирует этот алгоритм в действии.

Задача:

На компьютере в каталог по умолчанию установлен пакет Microsoft Office, которым можно пользоваться всем. Но группе «Accountants» необходимо разрешить запускать только программы Word и Excel. Запуск остальных файлов из «Program Files» разрешён без ограничений.

Решение:

Для решения этой задачи мы должны разрешить весь каталог «Program Files» по правилу пути для группы «Everyone». Поскольку доступ к программам Microsoft Office будет ограничен только для группы «Accountants», мы создаём новое запрещающее правило (с действием «Deny»), которое применяется только к группе «Accountants». Теперь программы из пакета Microsoft Office будут разрешены для запуска всем, кроме группы «Accountants». Чтобы обеспечить запуск только необходимых приложений из этой папки, мы редактируем запрещающее правило и добавляем два исключения (по правилу пути, хеша или издателя) для файлов «Excel.exe» и «Winword.exe».

Проверка:

Исходя из диаграммы, посмотрим, что будет происходить, когда член группы Accountants запустит PowerPNT.exe (PowerPoint).

При запуске мы попадаем на первый условный переход: подпадает ли файл под какой-нибудь запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно выходим на следующий условный переход: указан ли PowerPNT.exe в исключениях? Правило запрета не предусматривает исключения для этого файла, следовательно мы выходим на действие «File is blocked to run». При этом алгоритм заканчивается.

А теперь член группы Accountants запускает Excel.exe (Excel). При запуске мы снова попадаем на первый условный переход: подпадает ли файл под запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно переходим на следующий условный переход: указан ли Excel.exe в исключениях данного правила? Да, указан в исключениях, поэтому переходим на третий условный переход: есть ли ещё запрещающие правила? Если нет, мы сразу попадаем на четвёртый условный переход, который уже отрабатывает разрешения. Если есть ещё запрещающие правила, в них Excel.exe никак не запрещается (по условию задачи это не подразумевается), мы прямиком с первого условного перехода попадаем на четвёртый условный переход: подпадает ли файл хоть под одно разрешающее правило? Да, файл подпадает под разрешающее правило всего каталога Program Files для группы Everyone, в которую входит и группа Accountants. В результате попадаем на пятый условный переход: есть ли исключение для Excel.exe в этом разрешающем правиле? Нет, исключений для правила не предусмотрено и мы выходим на действие «File is allowed to run».

Как видите, используя эту диаграмму, можно разбирать правила любой сложности в пошаговом режиме и теперь вы знаете, как сортируются и проверяются правила AppLocker'а.

Напоследок ещё хочется отметить ситуацию применения множественных политик. Так же как и в случае с Software Restriction Policies, правила никак не замещаются, а суммируются. Т.е. собираются в один список, после чего AppLocker оперирует правилами, собранных со всех политик, применённых к конкретному компьютеру.

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

Планирование расширений CDP и AIA

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

Примечание: перед проведением любых изменений, описываемых в этом посте, обязательно выполните бэкап.

Большинство администраторов при установки роли Active Directory Certificate Services (AD CS) делают очень просто Next –> Next –> ????? –> PROFIT. С одной стороны это и хорошо, но часто это не очень хорошо. Чем это хорошо — оно будет работать. Чем это плохо — при появлении каких-то специфических условий (например, внешние по отношению к текущему лесу клиенты) оно начинает работать хуже и даже перестаёт быть работоспособным. Сегодня я планирую рассмотреть эти вопросы, как нестанадртные клиенты (не поддерживающие LDAP) и внешние клиенты, тем более это достаточно распространённый сценарий.

Отсебятина 1 — именование файлов

Небольшой вбросик. Я думаю, что многие замечали как именуются файлы. Например, дефолтный CRT имеет имя следующего формата:

<ServerDNSName>_<CAName><CertificateName>.crt

Т.е. обычно это выглядит так: caserver.company.com_companyca.crt. Скажем, не всем нравится такой формат, поскольку имя файла достаточно длинное и раскрывает внутреннее имя сервера, на котором хостится служба CA. Лично мне нравится другой формат имён файлов — короткое имя компании и аббревиатурное значение роли конкретного сервера CA. Например: company_RCA.crt. Мне кажется, что это хороший выбор. Однако, ни стандартный интерфейс CertSrv.msc, ни реестр не предоставляют возможности изменять имя и путь публикации CRT файла. Учитывая, что сертификаты самих CA обновляются достаточно редко, эту операцию можно выполнить вручную или при помощи скрипта — это уже на ваш выбор. Так что с CRT ничего не остаётся как копировать его вручную на веб-сервер или гонять его по DFS и переименовывать самостоятельно. Однако, следует учесть, что если сертификат CA обновлялся с новой ключевой парой, в конце имени файла добавляется число в круглых скобках. Например: server.domain.com_CAName(1).crt. Вот эта циферка приходит из <CertificateName>. Именно поэтому когда вы будете имзенять ссылку (об этом чуть ниже), которая будет публиковаться в издаваемых сертификатах, не забудьте к имени файла добавить <CertificateName>.

То же самое будет касаться и CRL. В соответствии с параграфом § 3.2.5.1.6 спецификации протокола [MS-CSRA]:

1.When this method is invoked, the CA SHOULD create a new base and/or delta CRL for each CA key, as specified in the following steps 2, 3, 4, 5, 6, and 7. The type of CRL to create (base, delta, or both) for each CA key is determined as follows:<38>

The CA SHOULD create a new base CRL for each CA key.

If the CA has enabled delta CRLs, as indicated by a nonzero Config_Delta_CRL_Validity_Period value, the CA MUST create a new delta CRL in addition to a new base CRL, for each CA key.

If delta CRLs are currently disabled (Config_Delta_CRL_Validity_Period is 0) and were enabled previously (Previous_Delta_CRL_Validity_Period is not equal to zero), the CA MUST create a new delta CRL in addition to a new base CRL for each CA key.

отдельный CRL создаётся для каждой ключевой пары CA. Следовательно, в имени CRL файлов следует оставить значение <CRLNameSuffix>. Этим самым сервер CA при публикации CRL на это место установит версию сертификата, для которого публикуется CRL. Например: CAName(1).crl и CAName(1)+.crl (для Base и Delta CRL). Если сертификат CA ещё не обновлялся, <CRLNameSuffix> будет заменён на пустое значение.

История Web Enrollment Pages

В системах до Windows Vista/Server 2008 клиентская часть запроса сертификатов была уныла чуть более чем полностью. Из того, что вы могли делать:

запрашивать сертификаты только тех шаблонов, где Subject строился автоматически на основе данных в Active Directory учётной записи, от имени которой происходил запрос;
Если в шаблоне разрешено использовать несколько CSP (Cryptographic Service Provider), можно было выбирать тот, который нужен для конкретного сертификата или который вам просто больше нравится;
Изменять длину ключа;
Включать/выключать возможность экспорта сертификата вместе с закрытым ключом (в PKCS#12);
Включать/выключать функцю Private Key Strong Protection (только для пользовательских сертификатов).

Если хотите использовать шаблон, Subject которого должен указываться в запросе (обычно используется для недоменных клиентов или клиентов других лесов Active Directory) или что-то ещё, вам было необходимо решать данный вопрос иными путями. Например, использовать текстовый файл настроек policy.inf совместно с утилитой CertReq.exe, или Web Enrollment Pages. Web Enrollment Pages был неотъемлемой частью компонента Certification Authority. При установке Web Enrollment Pages устанавливалась роль IIS (в реальности, чаще приходилось его устанавливать заранее, чтобы потом не настраивать его вручную) и в систему копировался набор ASP файлов и элемент ActiveX под названием Xenroll. Этот ActiveX является «прослойкой» между клиентом и сервером и отвечал за cookies и много чего ещё. В этих cookies сохраняется некоторая служебная информация, например, номер запроса, который был отправлен на сервер CA и по которому вы потом могли получить сертификат.

И используя Web Enrollment Pages вы могли запрашивать сертификаты для недоменных компьютеров (или клиентов других лесов Active Directory):

Enrollment Web Page

У нас там есть поля, которые позволяют вручную указать информацию о владельце сертификата. И галочка, которая указывала, что сертификат будет установлен в компьютерное хранилище. Для выпуска сертификатов для смарт-карт мы могли использовать галочку Enroll On Behalf Of с указанием пользователей для которых предназначен сертификат для смарт-карт.

Так же, как и с консолью MMC, вы не могли переопределять какие-то вещи, например, экспорт закрытого ключа, если это не разрешено в шаблоне и другое. Вобщем, как альтернатива, Web Enrollment Pages была весьма полезная и зачастую нужная вещь.

С выходом Windows Vista и Windows Server 2008 ситуация круто изменилась и началась всеобщая шумиха (она ещё до сих пор не утихает), что это всё перестало работать. В связи с некоторыми проблемами безопасности (любой запрос сертификата выполнялся в контексте пользователя, который аутентифицировался в IIS) и изменением функциональности консоли MMC, некоторые вещи были удалены с Web Enrollment Pages и изменён элемент Activex, который теперь называется CertEnroll. В новой консоли MMC (оснастка Certificates) вы можете выполнять абсолютно любые запросы. В том числе в клиенте реализована возможность ручного указания поля Subject и многих других полей (добавлять Application Policies, управлять экспортом закрытого ключа, его длиной, CSP и многое другое), а так же реализована возможность запрашивать сертификаты для смарт-карт от имени другой учётной записи (Enroll On Behalf Of).

По указанным причинам даже необходимость в Web Enrollment Pages скатилась до отвратительно низкой отметки. Но ~~жадные дети~~пользователи продолжают негодовать: верните всё как было! Я не могу с ними согласиться, поскольку дублировать реализованный функционал совсем не обязательно, а повышение в безопасности лишним не будет. Просто случилась миграция необходимого функционала с серверной части (Web Enrollment Pages) в клиентскую (Certificates snap-in).

Дополнительная информация по проблеме находится здесь: http://support.microsoft.com/kb/922706

Web Enrollment Pages и сервер CA на раздельных компьютерах

Эта проблема появилась начиная с выходом Windows Server 2008, когда этот компонент стал необязательным при установке роли Certification Authority и появилась возможность установить его не на сервере CA. Чаще на выделенном веб-сервере для обслуживания внешних клиентов.

При установке компонента на Web Enrollment Pages вы указываете сервер CA, с которым они будут работать и устанавливаете необходимые компоненты IIS для этого. Однако, сразу это не будет работать. Если быть точнее, то будет, но криво. Итак, какие вещи нужно настроить для такой конфигурации:

Включить SSL для веб-сайта, в котором будут размещены Web Enrollment Pages:
- Для IIS 7 и IIS 7.5: How to Setup SSL on IIS 7.0
Отключить анонимную и ядерную (kernel) аутентификацию и включить только Integrated Authentication:

Для IIS 7 и IIS 7.5: Configure Windows Authentication (IIS 7)

Настроить делегирование для учётной записи, от имени которой работает пул, в котором работает веб-сайт с Enrollment Web Pages, как это описано здесь: Install Web Enrollment Support on Another Computer (Optional)

Надеюсь это будет полезным.

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

Этим постом я подвожу итоги эпик-проповеди в 6 частях, посвящённой такой занимательной теме как Certificate Autoenrollment. Это достаточно популярная технология, которая позволяет автоматически подавать заявки на получение сертифкатов, что значительно снижает нагрузку на пользователей и администраторов. Хоть эта технология и популярна, её принципы работы в деталях далеко не всем известны, а некоторые моменты даже не освещены в библиотеке TechNet. И вот что у нас есть на текущий момент:

Certificate Autoenrollment от А до Я (часть 1) — Autoenrollment Background

Вводная часть, которая описывает основные компоненты автоэнроллмента и требования к нему.

Certificate Autoenrollment от А до Я (часть 2) — V1 Templates и Automatic Certificate Request

Данный пост раскрывает основные особенности шаблонов версии 1 и работу механизма Automatic Certificate Request (ACR).

Certificate Autonerollment от А до Я (часть 3) — V2/V3 Templates

Здесь рассказывается о шаблонах версии 2 и 3, включая описание каждого свойства шаблона и его влияния на работу механизма автоэнроллмента.

Certificate Autoenrollment от А до Я (часть 4) — user certificate autoenrollment

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

Certificate Autoenrollment от А до Я (часть 5) — расширения в Windows 7/2008 R2

С выходом Windows 7/Windows Server 2008 R2 у нас появляются новые механизмы энроллмента сертификатов, которые значительно расширяют возможности и удобство распространения сертификатов.

Certificate Autoenrollment от А до Я (часть 6) — XCEP/WSTEP Autoenrollment

И, собственно, описание принципа и порядка работы клиентов Windows 7/Windows Server 2008 R2 с новыми механизмами XCEP/WSTEP как в доменной, так и не в доменной среде.

Enjoy, greetings!

Certificate Autoenrollment от А до Я (часть 6) — XCEP/WSTEP Autoenrollment

Примечание: материал данной статьи относится только к клиентам под управлении 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. В результате вы должны получить нечто вроде такого:

CEP URL validation fig.1

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

CEP policy collection

fig.2

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

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

CEP collection policy server list

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 обязательна!

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

Autoenrollment behavior using XCEP/WSTEP 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. Рассказал как умел и, мне кажется, материал получился достаточно исчерпывающим и у читателя должно появиться понимание принципа работы всех внутренних механизмов. Если что-то осталось непонятным или появились вопросы — комментарии внизу :)

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

AppLocker — порядок работы правил

Планирование расширений CDP и AIA

Рекомендация 1 — CA и IIS

Рекомендация 2 — CDP/AIA и LDAP

Отсебятина 1 — именование файлов

Рекомендация 3 — публикация файлов на Web-сервер

CDP — новая инсталляция

CDP — унаследованная инсталляция

AIA — новая и унаследованная инсталляции

Немного про Web Enrollment Pages