Contents of this directory is archived and no longer updated.

Posts on this page:

Устанавливаем Certification Authority (часть 1) — Введение
AppLocker — порядок работы правил
Планирование расширений CDP и AIA
Немного про Web Enrollment Pages
Новый блог

Устанавливаем Certification Authority (часть 1) — Введение

Update 11.11.2010: Windows Server 2008 R2 Standard не поддерживает роль OCSP Responder.

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

Устанавливаем Certification Authority — Подведение итогов

Prologue

Одной из самых больших проблем при внедрении PKI на предприятии является отсутствие навыков планирования и установки Certification Authority. Как я уже неоднократно отмечал, потребность в PKI возрастает с каждым днём, а вот понимания вопроса у людей не увеличивается. К чему это приводит? В лучшем случае это приводит к установке вида Next –> Next –> ????? –> PROFIT и последующей нетривиальной и болезненной переконфигурации инфраструктуры под бизнес-задачи. Но чаще это заканчивается смачным эпик-фейлом в виде абсолютно неработающей PKI. Вот один из примеров: Помогите установить и настроить службу сертификации. Пробояню себя ещё раз, сказав, что для многих планирование, установка и поддержка PKI кажется задачей не сложнее администрирования нотепада и укладывается по времени в промежуток обеденного перерыва. При этом они глубоко заблуждаются, поскольку даже книга Брайана Комара и Пола Адаре по PKI (Windows Server® 2008 PKI and Certificate Security) не даёт полного и детального представления о работе PKI, хотя там ТЗ хватит на не один год. В реальности для полного понимания материала ещё необходимо прочитать десяток вайтпеперов и всяческие RFC. Я не претендую на попытку устранить этот пробел, поскольку это нереально, но стараюсь дать какие-то полезные понятия и какие-то другие вещи в соответствии с бест-практисами.

PKI tasks

Во-первых, нужно определиться с задачами, которые могут потребовать внедрения PKI:

Внедрение защищённых механизмов аутентификации — смарт-карты, сертификаты для аутентификации в IIS/VPN;
Внедрение защищённых сетевых протоколов — L2TP, SSL, IPsec;
Внедрение защищённой почты с шифрованием и/или подписью писем;
Внедрение цифровых подписей документов и файлов, что гарантирует их целостность и альтернативу ручной подписи.
Внедрение защищённых файловых хранилищ с шифрованием особо конфиденциальной информации.

Если из всего вышеперечисленного вам не нужно, PKI вам не нужна так же.

Planning CA hierarchy

В одном из своих предыдущих постов я вёл дискуссию об иерархиях PKI: Обсуждение схем иерархии Certification Authority. На основе этого материала мы подбеёрм схему для нашей инсталляции, которая будет описана в данном материале. Исходя из написанного по ссылке мы сразу отметаем вариант одноуровневой иерархии. Двухуровневая иерархия выглядит крайне привлекательно:

2-tier CA hierarchy

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

2-tier CA hierarchy

Создание 3-х уровневой иерархии уже будет подразумевать разделение иерерхии на области действий CPS (Certificate Practice Statement) и будут подвержены различным политикам управления серверами CA. Это достаточно долгая песня и о ней говорить не будем. Поэтому мы остановимся на двухуровневой иерархии с одним корневым центром сертификации (Root CA) и одним издающим центром сертификации (Issuing CA).

Planning CA types

Microsoft поддерживает два типа центров сертификации — Standalone и Enterprise. Обычно администраторы привыкли устанавливать Enterprise CA и по очевидным причинам не используют Standalone CA. Чем они отличаются?

Standalone

Характеризуются нетребовательностью к наличию домена Active Directory. Так же Standalone CA не использует шаблоны, следовательно вы не можете запрашивать сертификаты на таком CA через оснастку Certificates консоли MMC. Что означает, что вы не можете пользоваться функциями autoenrollment'а. Так же при выдаче сертификатов, Standalone CA не может автоматически публиковать сертификаты в свойства учётной записи пользователя или компьютера. Энролить сертификаты в Standalone CA можно только через Enrollment Web Pages, либо вручную генерируя запросы (файлы с расширением .req) и отправляя их через оснастку CertSrv.msc. Причём отправка запросов через оснастку CertSrv.msc является новой возможностью в Windows Server 2008. В связи с этим необходимость в Enrollment Web Pages отпала совсем.

По своим возможностям Standalone CA выглядит убогим чуть более, чем полностью. Но этот тип CA имеет одно сильное преимущество — он не зависит от наличия домена. Кажется — фигня. Домены даже рулят и педалят и всё, что работает без домена не нужно! Но давайте посмотрим на ситуацию немного с другой стороны. Центры сертификации верхних уровней (корневые и подчинённые центры сертификации первого уровня) имеют как правило очень большой срок действия — от 10 до 20 лет. При этом очень часто домены и леса AD живут значительно меньше, поскольку они постоянно реструктуирутся, переименовываются, мигрируются и т.д. А центр сертификации в домене (Enteprprise CA) лишает нас некоторых возможностей, как переименование домена и усложняют процессы реструктуризации доменов и лесов. По этой причине, Enterprise CA имеет небольшой срок действия своих сертификатов — от 5 до 10 лет максимум. В принципе, если есть независимый от домена AD центр сертификации (Standalone CA в рабочей группе) гораздо проще проводить миграцию и реструризацию лесов AD, поскольку эти процессы не затрагивают корневой CA и избавляют от проблем построения новой иерархии PKI. В такой ситуации достаточно только сменить центры сертификации 2-го и 3-го уровней (последний обычно является Enterprise CA). Именно по этой причине корневые центры сертификаций целесообразно устанавливать вне домена, в рабочей группе.

Enterprise

Центр сертификации уровня предприятия (как это следует из названия) совершенно не похож на Standalone CA по своим возможностям. Во-первых Enterprise CA требует наличия домена для хранения там своей информации и шаблонов сертификатов. Данный тип CA имеет очень большие возможности по выдаче и обслуживанию сертификатов. Enterprise CA не требует генерации файлов запросов со стороны клиентов, а позволяет подавать заявки на сертификаты через оснастку Certificates консоли MMC и автоматически распространять сертификаты в масштабах целого леса AD при минимальном участии конечного пользователя. Чаще всего это участие сводится к настройке администратором политик autoenrollment'а и всё. Плюс, Enterprise CA может публиковать сертификаты в свойства учётных записей пользователей и компьютеров.

Однако, зависимость от домена вносит некоторые ограничения в свою жизнь. Поскольку домены достаточно подвижные единицы и подвержены изменениям, Enterprise CA имеют достаточно короткий срок действия своих сертификатов — от 5 до 10 лет максимум. В случае Enterprise Root CA, удаление домена автоматически ведёт к краху всей иерархии PKI и её придётся строить с нуля, что может вылиться в большие трудности в довесок к текущим проблемам удаления домена. Именно поэтому компании никогда не устанавливают корневой центр сертификации на Enterprise CA, а только Issuing CA, которые уже издают сертификаты конечным потребителям, где и восстребованы все возможности Enterprise CA. Хотя, в очень небольших компаниях этого будет вполне достаточно, когда корневой CA устанавливается на Enterprise CA и имеет срок действия сертификата 5 лет.

В данном цикле статей мы будем использовать преимущества обоих типов CA. Для корневого CA будем использовать Standalone CA в рабочей группе и для издающего CA будем использовать Enterprise CA в домене Active Directory. При этом Standalone CA не будет издавать сертификаты конечным потребителям, а только для других центров сертификации.

Planning validity periods

На какой срок будем выдавать сертификаты для каждого типа CA? 20 лет мне кажется слишком круто, ведь через 20 лет в вашей компании может всё круто поменяться и если ваш бизнес не завязан на предоставлении услуг цифровых сертификатов, 20 лет, наверное, слишком большой срок. А вот 10 лет для корневого и издающего будет вполне достаточно. Не надо думать, что через 10 лет всё умрёт. Просто через 10 лет (фактически чуть раньше, через 8-9 лет) вам придётся обновить сертификаты обоих CA и всё, жизнь будет продолжаться дальше. Издержки на обновлении сертификатов CA минимальные, поскольку никаких изменений в конфигурации производить не придётся.

Planning CDP/AIA extensions

Об этом у меня написано уже достаточно много:

Исходя из описанного по ссылкам (читать обязательно!) мы полностью откажемся от LDAP-ссылок и в сертификатах будем публиковать только ссылки на HTTP. Для этой цели нам потребуется веб-сервер, который будет хранить наши CRL/CRT файлы и поддерживать работоспособность ссылок. Поскольку корневой CA не будет издавать сертификаты конечным потребителям, а только для других CA, риск компрометации которых невелик (но всё же существует) и он большую часть времени будет выключен, мы отключим публикацию Delta CRL для корневого CA, но включим для Issuing CA. Основной CRL (Base CRL) мы будем публиковать каждые 3 месяца для корневого сертификата и каждые 5 дней для Issuing CA. Для обеспечения более быстрой реакции на отзыв сертификатов, для Issuing CA будем публиковать Delta CRL каждые 12 часов.

Так же можно предусмотреть использование OCSP (Online Certificate Status Protocol). Хоть обычно OCSP и используется только для Enterprise CA, ничего не мешает использовать его для корневого CA. С учётом роста количества клиентов под управлением Windows Vista и выше, это будет хороший экспериенс и я расскажу, как это можно будет реализовать.

Conclusion

Исходя из вышесказанного мы можем сформулировать программные требования для нашей иерархии PKI:

Windows Server 2008/2008 R2 Standard Edition.
Компьютер является членом рабочей группы WORKGROUP, с именем хоста RootCA. Компьютер не подключен к локальной сети или к интернетам. В принципе, для это задачи можно использовать и Enterprise/Datacenter редакции, но от них вы никакого профита не получите в случае использования роли ADCS (Active Directory Certificate Services). Редакции Standard хватит вполне.
Windows Server 2008 Enterprise/Datacenter или Windows Server 2008 R2 Standard/Enterprise/Datacenter.
Компьютер является членом домена Adatum.com с именем хоста Issuing CA. Компьютер не должен держать роль контроллера домена.
Домен Adatum.com содержит выделенный веб-сервер под управлением любой ОС и который доступен из интернета (только для обслуживания внешних клиентов).
Домен Adatum.com содержит сервер способный выполнять роль OCSP Responder'а. Если это будет Windows Server, требования к версии будут такие же, как и для Enterprise CA. Т.е. Windows Server 2008 R2 Standard/Enterprise/Datacenter или Windows Server 2008 Enterprise/Datacenter.

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

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)

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

Новый блог

Наверное, мало кто знает, что я стал поддерживать ещё один блог. Да, вот такой я непостоянный, сначала спейсы, потом dasblog и теперь ещё один. Со временем изменяются какие-то обстоятельства, появляется прозрение или ещё что-нибудь и появляется необходимость в новом блоге. На этот раз блог будет (на самом деле уже) работать под управлением SharePoint:

>> en-us.sysadmins.lv <<

Как видно из названия, новый блог будет содержать материал только на английском языке. Для чего он мне нужен? Наверное, стоит рассказать немного предыстории. Как некоторым, наверняка, известно, я вплоть до сентября прошлого года был достаточно активным участником форумов TechNet-RU. С сентбря прошлого года я прекратил свою деятельность на этих форумах и полностью перебрался на буржуйские (англоязычные) форумы TechNet, а на русскоязычных технетах появляюсь только в случае обнаружения дикой ереси в интересующих меня топиках (как пример, вот — Помогите установить и настроить службу сертификации). В остальных случаях я не принимаю участия в дискуссиях. Почему именно буржуйские технеты? С горьким сожалением приходится констатировать, что на русскоязычных технетах практически делать нечего. Нет действительно интересных и нетривиальных тем по областях, в которых я специализируюсь (PowerShell и PKI). Если по PowerShell на форумах хватает специалистов, то по PKI элементарно не хватает вопросов и нет возможности развития своих знаний в этой области. Плюс, отечественный менталитет не очень радует. Слишком часто люди не удосуживаются даже прочитать элементарный how to, FAQ или ещё чего-нибудь подобного рода. Ссылка на топик лишний раз это подтверждает. Именно по этой причине основная форумная мозговая деятельность мигрировала на буржуйские технеты. Потусовавшись там несколько месяцев, начал понимать их специфику вопросов и наиболее частые пробелы в знаниях. Основываясь на этой информации я планирую заполнять эти пробелы в новом бложике.

Теперь у меня будет 2 бложика, что станет с текущим? Пока что в обозримом будущем с ним ничего не станет, будет жить и развиваться в том же ключе, что и раньше. Что касается контента — пока не определился. Вполне вероятно, что часть ТЗ (Тайное Знание) будет публиковаться только в англоязычном блоге, поскольку там потребность в ТЗ будет выше, чем в русскоязычном по очевидным причинам. Дублировать контент, имхо, бессмысленно, да и тяжеловато будет. Потому что его надо будет придумать сначала на одном языке, потом перевести на другой. Это отнимает достаточно много времени. Поэтому полного дубляжа не будет. Хотя, что-то будет действительно размещаться в обоих блогах.

Но это всё пока планы. Сейчас я просто сделал попытку вести 2 блога для 2-х разных аудиторий. Так что периодически можно будет проверять мой англоязычный бложик на предмет нового контента или просто подписавшись на RSS.

Устанавливаем Certification Authority (часть 1) — Введение

Prologue

PKI tasks

Planning CA hierarchy

Planning CA types

Planning validity periods

Planning CDP/AIA extensions

Conclusion

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

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

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

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

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

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

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

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

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

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

История Web Enrollment Pages

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

Новый блог

>> en-us.sysadmins.lv <<