Этим постом я начинаю серию небольших заметок по не всегда очевидным фактам в PKI. И сегодня начну с первого факта — OCSP или CRL? OCSP и CRL — это 2 модели, которые могут использоваться для проверки сертификата на предмет его отзыва.

Сертификаты в случае когда в них больше не нуждаются или когда закрытый ключ от сертификата может быть доступен злоумышленникам подлежат отзыву. Этим самым полностью теряется доверие данному сертификату или человеку, который его предъявил, поскольку сертификат может предъявить злоумышленник, который его украл. Это достаточно важный момент в PKI, который позволяет достаточно однозначно сказать — можем ли мы доверять предъявителю конкретного сертификата или нет.

Модель CRL используется с самого начала существования PKI и выглядит следующим образом. Сервер CA отзывает некоторый сертификат и помещает о нём запись в специальный файл CRL. При этом туда помещается серийный номер сертификата, дата фактического отзыва (не обязательно совпадает со временем когда администратор отозвал сертификат) и причина отзыва. Клиенты при проверки сертификатов скачивают эти CRL и проверяют есть ли серийный номер этого сертификата в CRL. Логично, что чем больше сертификатов отозвано, тем больше файл, тем более нагружается сеть при частом скачивании относительно большого файла CRL.

В OCSP используется немного иной принцип. Клиент OCSP отправляет на сервер OCSP Responder специальный запрос, в котором содержится серийный номер проверяемого сертификата. OCSP Responder «пробивает номер по своей базе» и отвечает клиенту откликом. Этот отклик содержит однозначный ответ на вопрос: отозван или не отозван.

Казалось бы, если у вас и серверы и клиенты работают под управлением Windows Vista/2008 и выше, то ответ однозначный: OCSP — наше всё! Ну и вообще даже при наличии небольшого количества этих систем (а преимущественно используются устаревшие клиенты Windows XP/2003), то OCSP нам никак не помешает! Но на самом деле это не всегда так и в ряде ситуаций использование OCSP будет даже нежелательным. Давайте посмотрим почему. Сначала сделаем сравнительные характеристики обеих моделей проверки отзыва

• CRL

Исходный размер пустого CRL составляет порядка 600 байт (но это значение может отличаться в зависимости от длины полей и длины ключа подписи). На каждую запись отозванного сертификата в CRL отводится 80 байт. Это, как я уже говорил, серийный номер отозванного сертификата, дата фактического отзыва и числовое обозначение причины отзыва. Т.е. если у вас отозвано 10 сертификатов, то размер CRL будет 600 + 80 * 10 = 1400 байт. Если отозвано 100 сертификатов, то размер CRL будет порядка 9кб и т.д.

• OCSP

Каждая проверка статуса сертификата потребляет определённый размер трафика — 2кб. При этом неважно какого размера сам CRL. Даже если отозвано 100 000 сертификатов, то CRL будет размером примерно 8мб. И каждый устаревший клиент будет скачивать этот файл на 8 мегабайт. А с OCSP любой запрос и ответ на него займёт всего 2кб. Удобно? Безусловно.

Однако, в ряде случаев я бы не рекомендовал использовать OCSP для сертификатов, которые аутентифицируют клиентов. К ним относятся следующие типы сертификатов:

• сертификаты смарт-карт;
• сертификаты аутентификации в IIS;
• клиентские сертификаты компьютеров для VPN/L2TP и IPsec;
• сертификаты аутентификации пользователей в VPN (EAP-TLS).

Почему? Дело в том, что аутентифицирующий сервер кеширует все данные об отзыве. Сначала в памяти, потом на диске (когда происходит свопинг). И давайте посмотрим на типичный сценарий:

У вас на предприятии используется корпоративный веб-сайт с аутентификацией пользователей по сертификату. У вас 1000 пользователей и они все утром подключаются к веб-сайту. Веб-сервер при проверке подлинности каждого пользователя будет посылать OCSP запрос на OCSP Responder запросы с серийным номером каждого сертификата. Мы знаем, что размер каждого ответа составляет 2кб, следовательно сервер отправит 1000 HTTP запросов и закеширует у себя в памяти 2 мегабайта памяти.

А теперь представьте, что у вас не используется OCSP, а только CRL и на сервере CA отозвано 100 сертификатов. Как мы знаем сам контейнер CRL занимает 600 байт и каждая запись по 80 байт. В итоге файл CRL будет занимать 9 килобайт! И в этом случае сервер сделает только одну «ходку» за CRL файлом и уже всех клиентов будет проверять именно по скачанному CRL. Как видите, профит от использования CRL здесь очевиден. Серверу надо меньше тратить сетевого трафика и меньше данных кешируется в памяти. При этом OCSP целесообразно включать для серверных сертификатов, потому что клиентов обычно много и им выгодней использовать небольшии порции трафика OCSP.

Подводя итоги, мы можем кратко констатировать следующие вещи:

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

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

Ссылки по теме:

OCSP (часть 1)
OCSP (часть 2)
http://en.wikipedia.org/wiki/Certificate_revocation_list

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

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

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

1. в Request Handling тип использования ключа содержит Signature;
2. в Application Policies (в прошлом Extended Key Usage или просто EKU) выставлено Certificate Request Agent.

Примечание: в целях безопасности следует настроить ограничения для запроса сертификатов на основе этого шаблона и после выдачи сертификатов нужным агентам, удалить его из выдачи CA. Так же настоятельно рекомендуется сделать шаблон версии 2 и использовать CSP смарт-карты, чтобы данный сертификат не хранить в профиле пользователя, а на смарт-карте.

После этого этот агент может запрашивать сертификаты для других пользователей. Для этого агент запускает оснастку certmgr.msc, в ней переходит на Personal –> Certificates –> Action –> All Tasks –> Advanced Operations –> Enroll On Behalf Of… и начинает процесс подачи заявки на сертификат. Во втором окне мастера агенту потребуется указать свой сертификат Enrollment Agent. Этот шаг необходим для того, чтобы доказать, что агент является Enrollment Agent'ом и данный сертификат будет использоваться для подписывания запроса сертификата. В окне выбора шаблонов вы скорее всего увидите только доступные шаблоны версии 1:

У меня есть несколько шаблонов версии 2, но запрашивать для них сертификаты я не могу. Сообщение отказа в запросе таких сертификатов весьма мутное и не очень понятное. Поскольку шаблоны версии 1 не могут быть изменены, они штатно поддерживают режим EOBO. А шаблоны версии 2 и 3 следует сконфигурировать отдельно. Для этого вам нужно открыть свойства шаблона, перейти на вкладку Issuance Requirements и отредактировать его так, чтобы он выглядел как на картинке:

Т.е. вы должны указать, что запрос должен быть подписан сертификатом, Application Policies которого содержит Certifcate Request Agent.

Вообще тут разгуляться можно как следует. При наличии специальных требований, вы можете создать определённые рабочие процессы (workflows). Например, в шаблоне сертификата Enrollment Agent, который требует хранение сертификата на смарт-карте (явно указан только CSP смарт-карты) в Issuance Policies (Certificate Policies) можете создать отдельную политику выдачи, например Smart Card Enrollment Agent, назначив этой политике свой OID. Таким образом у вас может быть 2 Enrollment Agent'а, один из которых выдаёт смарт-карты с сертификатами для цифровых подписей, а другой агент будет выдавать сертификаты смарт-карт для шифрования файлов. При этом первый агент будет хранить свой сертификат Enrollment Agent на смарт-карте, а второй в профиле пользователя. В сертификате Enrollment Agent первого агента в Certificate Policies будет указан OID, который вы присвоили политике Smart Card Enrollment Agent. Сертификат второго агента не будет содержать особых политик выдачи (используется стандартный шаблон Enrollment Agent версии 1).

Чтобы разделить шаблоны между агентами вы можете их настроить вот так:

Мы теперь требуем, чтобы сертификат агента подачи заявок не только содержал определённый Application Policy, но и Issuance Policy тоже. Это означает, что агент подачи заявок, который хранит свой сертификат в профиле не будет иметь возможности запрашивать сертификаты такого шаблона. Вот вам ещё один сценарий использования OID'ов. Это на случай, чтобы вы не думали, что это какая-то мифическая никому не нужная фигня.

Собственно, после этой настройки шаблонов версии 2 и 3 вы можете их использовать в EOBO:

Помимо этого, вы можете ещё более точно очертить возможности агентов восстановления:

Начиная с Windows Server 2008, вы можете задавать более гранулированные права для enrollment agent'ов, указывая каким агентам какие сертификаты можно запрашивать с использованием EOBO.

Данный материал не претендует на статус ТЗ (Тайное Знание), но даёт огромную пищу для размышления администраторам средних и крупным компаний на предмет того, как можно расширить возможности использования PKI и создать более чёткое разделение обязанностей агентов подачи заявок (Enrollment Agent) при использовании функции Enroll On Behalf Of (EOBO). Как вы видите, Windows PKI даже из коробки позволяет достаточно просто масштабировать и управлять вашей инфраструктурой PKI. А так же мы развеваем миф о том, что инфраструктурой PKI может рулить студент-ПТУшник (петушатник?), который поднимает CA на коленке в метро.

Для больших компаний существуют ещё более мощные и гибкие средства для выполнения подобных задач, которые есть в таких продуктах как Identity Lifecycle Manager (ILM) 2007 или в Forefront Identity Manager, но о них мы говорить не будем.

Дополнительные материалы: Что в OID'е тебе моём?

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

Примечание: данный материал публикуется как обязательный для знания IT-специалистами, которые занимаются или только собираются заниматься темой PKI (Public Key Infrastructure).

Мне иногда задают вопрос про сущность этой опции Enable private strong protection, а так же встречаются любители обезопасить свои ключи данной опцией. Итак, что это такое? Private key strong protection позволяет вам шифровать ваш закрытый ключ отдельным паролем и является некоторым подобием поведения, когда сертификат находится на смарт-карте. Включить данную опцию вы можете при энроллменте или импорте сертификата. При энроллменте выберите нужный вам шаблон сертификата, нажмите Properties, перейдите на вкладку Private key, раскройте Key options и поставьте галочку на Strong private key protection:

после нажатия Ok, вылезет окошко, которое потребует у вас указать степень защиты и пароль (если выбран High):

Я выбрал уровень High и следующим окном меня попросили ввести пароль. Этот пароль не обязательно должен быть такой же как и пароль от учётной записи. Поэтому пароль можно указывать любой. И когда вы захотите использовать закрытый ключ от этого сертификата (например, подписать почтовое сообщение или аутентифицироваться по сертификату на веб-узле), то появится запрос для подтверждения использования закрытого ключа:

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

• сертификатов компьютера, которые хранятся в LocalMachine store

все сертификаты (например, SSL, IPsec), которые хранятся в компьютерном хранилище используются только учётной записью компьютера и диалоговое окошко с требованием подтвердить доступ к ключу появится у учётной записи LocalSystem, а вы не увидите этого запроса, в следствии чего сертификат невозможно будет использовать.

• для сертификатов EFS пользователей

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

1. Local Security Authority — LSA (lsass.exe) проверяет наличие сертификата EFS в профиле пользователя или на смарт-карте. Если не находит, то в зависимости от настроек политик может запросить новый сертификат у CA или сгенерировать самоподписанный. Самоподписанный сертификат генерируется если в доменной сети не зарегистрировано ни одного CA или машина находится в рабочей группе и в политиках не запрещено использование самоподписанных сертификатов EFS;
2. LSA генерирует симметричный ключ шифрования FEK (File Encryption Key) в закрытой и недоступной для пользователя области памяти;
3. LSA этим симметричным ключом шифрует сами данные;
4. LSA выбирает из профиля пользователя открытый ключ сертификата EFS и им шифрует симметричный ключ шифрования и записывает шифр в DEF (Data Encryption Field) файла.

Здесь как бы особого криминала нет, поскольку на данном этапе LSA ничего не знает про закрытый ключ, но при попытке расшифровать файл получается такая картина:

1. LSA читает DEF файла и выясняет Thumprint сертификата, который использовался при шифровании симметричного ключа (FEK);
2. LSA пытается взять закрытый ключ от сертификата, но его ожидаем облом. Закрытый ключ зашифрован паролем, который известен только пользователю. Т.к. lsass.exe — это системный процесс и работает в закрытой области памяти, не представляется возможным (по условиям безопасности) передать окно для ввода пароля в сессию пользователя. Просто это наиболее короткий путь к повышению своих привелегий

Поэтому окошка вы никакого не видите и, следовательно, доступ к данным сразу же теряете. Чтобы избежать этого было сделано хорошее решение — не шифровать файлы вообще, если сертификат EFS защищён отдельным паролем и запросить/сгенерировать новый сертификат не представляется возможным. Т.е. на стадии 1 LSA попутно проверяет статус закрытого ключа. И если он защищён, то пробует запросить новый сертификат EFS для пользователя. Если CA недоступен или нет шаблона Basic EFS, то пытается сгенерировать самоподписанный. Если политиками запрещено использовать самоподписанные сертификаты EFS, то получаете ошибку и никакого шифрования не производится.

Нужен ли этот Strong protection в реальной жизни? В реальной жизни есть смысл использовать смарт-карты, тем более сейчас всё больше приложений поддерживают их. И EFS в том числе. Тогда strong protection можно отключить на уровне политик:

Computer Configuration –> Policies –> Windows Settings Security Options –> System Cryptography: Force strong key protection for user keys stored on the computer

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

Продолжаем серию постов, которые посвящены базовому управлению объектами PKI в Active Directory. На данный момент мы рассмотрели сценарии публикации и просмотра сертификатов в Active Directory:

• Active Directory PKI object management с помощью PowerShell
• Active Directory PKI object management с помощью PowerShell (часть 2)

На данном этапе нам осталось последнее — удаление сертификатов из AD. Логика здесь очень простая: командой Get-ADPKIObject мы получаем коллекцию объектов, которые представляют собой сертификаты и через конвейер командой Remove-ADPKIObject указываем ID объектов, которые необходимо удалить. Если кто-то уже разбирал код предыдущих скриптов, то ему будет совсем нетрудно понять логику скрипта удаления объектов. Вот он, вместе с комментариями:

function Remove-ADPKIObject {
<#
.Synopsis
    Deletes certificates from Active Directory containers
.Description
    Deletes certificates from Active Directory containers by specifying particular ID or IDs
.Parameter ID
    Specifies certificate ID to delete that was set in Get-ADPKIObject command.
.EXAMPLE
    Get-ADPKIObject RootCA | Remove-ADPKIObject 2
    
    deletes certificate with ID = 2 in certificate viewer
.Outputs
    This command provide a resultant of operation.
#>
    param([int[]]$ID = $(throw "you must specify number of the object to delete"))
    # объявляем массив для хранения сертификатов из контейнера NTAuthCertificates
    begin {$sum = @()}
    process {
        # проверяем тип контейнера входящего объекта
        if ($_.Container -ne "NTAuthCertificates") {
            # если это не NTAuthCertificates, то проверяем, что ID текущего объекта
            # совпадает с ID, который нужно удалить
            if (@($ID) -contains $_.Id) {
                # если совпал, то собираем LDAP-запрос
                $ldap = [ADSI]"LDAP://CN=$($_.Container),$script:ConfigContext"
                # и удаляем текущий объект из AD
                $retn = $ldap.Delete("certificationAuthority", "CN=$($_.Subject)")
                if ($?) {
                    Write-Host "`'$($_.Subject)`' certificate was sucessfully deleted from `'$($_.Container)`' container"`
                    -ForegroundColor Green
                }
            }
        # если контейнер текущего объекта является NTAuthCertificates, то собираем их все в массив
        } else {$sum += $_}
    }
    end {
        # проверяем, что массив непустой (т.е. надо что-то удалять из NTAuthCertificates)
        if ($sum) {
            # если массив непустой, то выбираем те элементы, которые нужно сохранить
            # т.е. ID которых не содержится в аргументах скрипта
            $sum = @($sum |?{$ID -notcontains $_.Id})
            # делаем LDAP-запрос к этому контейнеру
            $ldap = [ADSI]"LDAP://CN=$($_.Container),$script:ConfigContext"
            # проверяем, что после фильтрации, хотя бы один сертификат нужно оставить
            if ($sum.count -ge 1) {
                # записываем первый сертификат. Это необходимо потому что ADSI не поддерживает запись
                # массива сертификатов в свойство cACertificate, а только один сертификат в виде byte[]
                $ldap.put("cACertificate", [byte[]]$sum[0].RawCertificate)
                # а вот простое добавление он поддерживает. Тогда ADSI сам пересоберёт объекты
                # в свойстве в нужный формат данных. На данном этапе я применил маленькую хитрость:
                # как видно, я первый сертификат записываю дважды - предыдущей строкой и в первой итерации
                # текущей строки. Но это не проблема, поскольку метод SetInfo() записывает только уникальные
                # объекты, а дублирующиеся просто отбросит.
                $sum | %{$ldap.cACertificate += ,[byte[]]$($_.RawCertificate)}
                $ldap.SetInfo()
                if ($?) {
                    Write-Host "`'$($_.Subject)`' certificate was sucessfully deleted from `'$($_.Container)`' container"`
                    -ForegroundColor Green
                }
            # а вот если после фильтрации объектов, у нас ничего не остаётся на запись, то это означает, что все
            # сертификаты из этого контейнера удаляются. Поэтому мы просто удаляем запись NTAuthCertificates.
            } else {
                ([ADSI]"LDAP://$script:ConfigContext").Delete("certificationAuthority", "CN=NTAuthCertificates")
                if ($?) {Write-Host "All certificates was sucessfully deleted from NTAuthCertificates entry ." -ForegroundColor Green
                    Write-Warning "This was last certificate in contaner. NTAuthCertificates entry is removed from Active Directory"
                }
            }
        }
    }
}

И теперь можно подвести краткие итоги. Мы смогли реализовать функционал certutil и других графических утилит (консоли MMC) в PowerShell значительно улучшив читабельность выходных объектов, адаптировали под работу из консоли (синтаксис стал значимо короче и более юзерфрендли) и шаг за шагом делаем из PowerShell единое консольное средство управления различными аспектами PKI.

Можно задать вопрос: а кто целевая аудитория всего этого? Целевая аудитория есть — администраторы PKI. Просто у вас не всегда будет возможность использовать графические консоли для решения этих задач (потому что их функционал далёк от идеального). Можно использовать certutil, который умеет много чего, но тоже имеет свои недостатки. Это и ужасный синтаксис, и вырвиглазный неуправляемый вывод результатов. Вобщем я надеюсь, что рано или поздно PowerShell сможет по-настоящему заменить certutil (который вообще-то ни в чём не виноват) и стать единой консолью всех Windows-администраторов. Вот не знаю на сколько это хорошо или плохо, потому что Microsoft всех насильно переводит на PowerShell (это очень показательно продемонстрировано в MS Exchange, где у вас по сути есть только PowerShell и всё). Обычно, насильно переводят на другой инструмент когда он является УГ и очень тяжело на него перевести людей посредством обычной рекламы. Но является ли PowerShell таким УГ? Я пока не готов ответить на этот вопрос. Моё мнение — PowerShell пока что особой революцией не стал. Даже не смотря на тонны рекламы, пеара и прочего, где восхваляют PowerShell, закидывают ногами CMD/WSH. Это обусловлено тем фактом, что не всегда PowerShell бывает удобней CMD/WSH, особенно в тривиальных задачах. Говорить, что синтаксис стал более простым и компактным тоже нельзя, потому что реально функционала из коробки хватает для решения процентов 10 задач. Всё остальное нужно скриптовать и программировать (да-да!) самому. Благо средств для этого в PowerShell хватает. Во что это обычно выливается? А в то, что в большинстве случаев результирующий объём кода будет не сильно меньше, чем в связке WSH + CMD. В любом случае преимущества PowerShell перед остальными очевидны, но они далеко не определяющие, ведь люди раньше решали свои задачи на WSH/CMD, пирожки продавались, бизнес шёл. С одной стороны Microsoft дал людям простор для творчества, т.е. делать в PowerShell всякие потрясающие штуки и всё такое. Но это не совсем то, что нужно было администраторам. Им нужна одна кнопка на весь экран с надписью «Сделать всё п**дато!». Пока что PowerShell и близко не готов стать такой кнопкой, а является «удочкой». Т.е. удочка у вас уже есть, а что касается конечной рыбы (результата), то дело осталось за малым — написать мега-скрипт. Мне вот интересно, что думают администраторы Exchange (поскольку пока что только они получили полноценную поддержку для своего продукта в PowerShell) — стало ли им жить легче с PowerShell или нет? Если да, то это может быть хорошим знаком, что однажды PowerShell станет такой кнопкой. И не будет более в системе certutil и всеми задачами будет рулить PowerShell (пока что это наиболее логичный сценарий развития событий). А вот если их жизнь не стала легче, то обещанной революции (которая по словам Microsoft уже наступила, как и вендекапец у луноходов) не будет, а будет просто какое-то логическое продолжение предыдущих инструментов для сценариев.

К чему я написал столько букв? К тому, что я ежедневно задаю себе один и тот же вопрос: а зачем я всё это делаю? А ответ найти очень непросто, потому что отмазы вида «проще, удобней, красивее» не годятся для серьёзного аргумента. На самом деле я не ищу ответ на него, а просто говорю себе «так надо» и делаю. Поэтому не надо меня использовать как пример «правильного пользователя PowerShell» и пытаться повторить что-то подобное астрономических масштабов на овер9000 строк — поверьте, оно не стоит того. Используйте его по мере сил. Если чего-то будет не хватать и его решение потребует значительных усилий — посмотрите на готовые утилиты, они наверняка будут уметь то, что вам надо.

Удачи!© One

В предыдущем посте мы ознакомились с основными контейнерами с объектами PKI в Active Directory и смогли изучить функциональный аналог ключа dspublish в утилите certutil. Если публикация сертификатов в AD задача простая даже для Certutil, то просмотр содержимого может быть весьма нетривиальным. Например, если вы хотите посмотреть содержимое записи NTAuthCertificates, то придётся выполнить вот такую команду:

certutil –viewstore "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration, ForestRootDomainDN"

такие вещи совершенно неприспособлены к командной строке, поскольку надо набирать много текста и ошибиться весьма просто. Одно хорошо, команда выводит графическое окошко, где мы можем посмотреть содержимое. Но тут есть несколько неудобных моментов: мы не можем посмотреть несколько контейнеров сразу, для каждого контейнера надо выполнять отдельную команду. В этом окошке мы можем только посмотреть на содержимое контейнера и всё. Ни добавить, ни удалить сертификат мы не можем. Для добавления сертификатов мы можем воспользоваться тем же certutil или моим скриптом, который был опубликован в предыдущем посте. Графика — хорошо и замечательно, но мы можем хотеть автоматизировать какие-то задачи или просто посмотреть информацию в консоли. Вы можете подумать, что это не нужно, но преимущество между консольным выводом и графическим диалоговым окном очевидное: из первого можно копировать информацию в буфер обмена. Есть ещё вариант — для просмотра и удаления сертификатов из AD, пользоваться консолью pkiview.msc. Но мы сразу же теряем главную нить — единое средство управления. Т.е. даже похожие операции мы должны выполнять в разных инструментах! Но с появлением PowerShell мы получили единый (хоть и консольный) инструмент, которым можно автоматизировать абсолютно всё! Даже сам PowerShell Вот, собственно код, который в разы упрощает процесс просмотра содержимого контейнеров:

function Get-ADPKIObject {
<#
.Synopsis
    Displays certificates info from Active Directory containers
.Description
    Displays info about certificates that are stored in AD PKI-related containers.
.Parameter Container
    Optional parameter. Specifies particular container to view. May contain one or
    more value from following possible values:
    
    RootCA - retrieves certificates from Certification Authorities container
    SubCA - retrieves certificates from AIA container
    NTAuthCA - retrieves certificates from NTAuthCertificate directory entry.
    
    if no parameter is set, command will return all certificates from all applicable
    containers.
.EXAMPLE
    Get-ADPKIObject RootCA
    
    Retrieves certificates from Certification Authorities container
.EXAMPLE
    Get-ADPKIObject RootCA, AIA
    
    Retrieves certificates from Certification Authorities and AIA containers
.Outputs
    Output AD PKI object collection
#>
[CmdletBinding()]
    param([string[]][ValidateSet("RootCA", "SubCA", "NTAuthCA", "")]$Container)
    # объявляем массив, который будет хранить выходные объекты
    $script:sum = @()
    # это весьма крутая штука будет. Каждый объект будет содержать свойство Id или просто
    # порядковый номер объекта. При дальнейших операциях с этими объектами вам достаточно
    # будет указать его Id вместо длинных и неудобных LDAP/Thumpbrint значений, как это делается
    # в certutil и подобных ему утилитах. Нумерацию начнём с единицы
    $script:n = 1
    # итоговая функция, которая будет разбирать бинарные массивы и готовить выходные объекты
    function _formatter_ ($certs, $type, $name) {
        # поскольку у нас все объекты в AD находятся в бинарном формате, мы импортируем каждый из них
        # в X509Certificate2 объект.
        $certs | %{
            $script:Cert.Import($_)
            # здесь мы создаём образец выходного объекта и обвязываем этот объект необходимыми свойстами и данными
            $current = "" | select @{n='Id';e={$script:n}}, Subject, @{n='Type';e={$type}}, @{n='Container';e={$name}},
                @{n='Thumbprint';e={$script:Cert.Thumbprint}}, @{n='SerialNumber';e={$script:Cert.SerialNumber}}, 
                @{n='ValidFrom';e={$script:Cert.NotBefore}}, @{n='ValidTo';e={$script:Cert.NotAfter}}, 
                @{n='RawCertificate';e={$script:Cert.RawData}}
            # чтобы не писать полный DN поля Subject, мы будем показывать только первую его часть
            # (которая отображается в самом сертификате)
            [void]($script:Cert.Subject -match 'CN=([^,]+)')
            $current.Subject = $matches[1]
            # добавляем объект в массив выходных объектов
            $script:sum += $current
            # очищаем X509Certificate2
            $script:Cert.Reset()
            # увеличиваем счётчик и обрабатываем следующий элемент
            $script:n++
        }
    }
    # ещё одна суб-функция, которая выдёргивает сертификаты из AD в бинарном виде и отправляет
    # их в _formatter_, который уже сформирует итоговые объекты.
    function _switcher_ ($name) {
        # подключаемся к нужному контейнеру
        $ldap = [ADSI]("LDAP://CN=$name,$script:ConfigContext")
        # как мы знаем, NTAuthCertificates не является контейнером, поэтому для него код будет немного
        # отличаться. А отличие будет состоять в том, что мы не будем залезать в контейнер, а сразу читать
        # свойства объекта NTAuthCA
        if ($name -eq "NTAuthCertificates") {
            # убеждаемся, что длина первого элемента свойства cACertificate больше единицы, т.е. содержит ненулевое
            # значение. Так же проверяем свойство crossCertificatePair, которое содержит Cross-certificates
            # и если оно не нулевое, то отправляем и его на формирование вывода
            if ($ldap.cACertificate[0].count -gt 1) {
                $certs = @($ldap.cACertificate)
                _formatter_ $certs "CA Certificate" $name
            }
            if ($ldap.crossCertificatePair[0].count -gt 1) {
                $certs = @($ldap.cACertificate)
                _formatter_ $certs "Cross CA Certificate" $name
            }
            # и переходим к следующему контейнеру
            return
        }
        # если контейнер указан как Certification Authority и/или AIA, то заглядываем
        # внутрь контейнера
        $ldap.psbase.children | %{
        # и заглядываем в каждую запись на исследование свойств cACetificate и crossCertificatePair
            $certs = @($_.cACertificate)
            $ccerts = @($_.crossCertificatePair)
            # проверяем, что свойство имеет ненулевое значение. Если так, то отправляем
            # содержимое этих свойств на формирование вывода
            if ($certs[0].count -gt 1) {_formatter_ $certs "CA Certificate" $name}
            if ($ccerts[0].count -gt 1) {_formatter_ $ccerts "Cross CA Certificate" $name}
        }
    }
    switch ($Container) {
        # конструкцией switch проверяем содержимое аргумента функции, чтобы определить какие именно
        # контейнеры надо обследовать.
        "RootCA" {_switcher_ "Certification Authorities"}
        "SubCA" {_switcher_ "AIA"}
        "NTAuthCA" {_switcher_ "NTAuthCertificates"}
        # если контейнер в аргументе не указан, то проверяем все контейнеры и записи
        "" {
            _switcher_ "Certification Authorities"
            _switcher_ "AIA"
            _switcher_ "NTAUthCertificates"
        }
    }
    # когда вывод будет полностью сформирован, выбрасываем все объекты в консоль
    $script:sum
}

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

и вывод у него вот такой красивый:

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

filter View-ADPKIObject {
<#
.Synopsis
    Displays certificates in certificate viewer
.Description
    Displays certificates in certificate viewer by selecting necessary certificates ID.
    Must be placed after Get-ADPKIObject command only.
.Parameter ID
    Specifies certificate ID that was set in Get-ADPKIObject command.
.EXAMPLE
    Get-ADPKIObject RootCA | ViewADPKIObject 1, 3
    
    displays certificate with ID = 2 in certificate viewer
.Outputs
    Script doesn't generate any output except errors
#>
    # судя по конструкции int[] мы можем указать несколько чисел, тогда все выбранные
    # сертификаты будут отображены. Номер указывать обязательно.
    param([int[]]$ID = $(throw "you must specify number of the object to display"))
    # и проверяем входные объекты с конвейера на предмет их ID. Если ID совпадает с
    # одним из ID в аргументах, обрабатываем его. Если ID не совпадает, ничего не делаем.
    if (@($ID) -contains $_.Id) {
        # генерируем в пользовательской папке Temp временный файл с рандомным расширением
        $TempFile = [System.IO.Path]::GetTempFileName() + ".cer"
        # записываем бинарный массив сертификата в файл в виде DER кодировки
        [System.IO.File]::WriteAllBytes($TempFile, $_.RawCertificate)
        # запускаем файл (просмоторщик сертификатов)
        & $TempFile
        # в санитарных целях ждём пол секунды
        Start-Sleep 0.5
        # и удаляем этот файл, чтобы не копился мусор
        del $TempFile -Force
    }
}

Как вы видите, ничего сверх-космического или магического в этом коде нет, самое трудное здесь — придумать логику работы. А остальное — накидать несколько строк кода и у нас PowerShell в лёгкую может соперничать с certutil за право называться единой утилитой управления PKI

Чтобы подкрутить рейтинг PowerShell в этой конкуренции, в следующий раз я покажу как мы можем легко и просто удалять сертификаты из контейнеров AD с использованием PowerShell

Подоспела ещё одна задачка для PowerShell'а — управление объектами PKI в Active Directory. Active Directory содержит целый раздел посвящённый PKI и вот из чего он состоит:

• CN=NTAuthCertificates, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain
• CN={CA name},CN=AIA, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain
• CN={CA name},CN=CDP, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain
• CN={CA name},CN=Certification Authority, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain

Вот о них мы сегодня и поговорим. В AD есть ещё несколько контейнеров, которые связаны с PKI, но они сегодня интереса представлять не будут. Как мы уже знаем, в:

• NTAuthCertificates публикуются все сертификаты CA, которые выдают сертификаты для аутентификации пользователей в домене. В том числе для логона смарт-картой, аутентификации в IIS или для аутентификации EAP-TLS в VPN. Все сертификаты в этой записи хранятся в виде массива;
• AIA публикуются сертификаты промежуточных (Intermediate) CA, за счёт чего можно значительно сократить время построения цепочек сертификатов. При этом не обязательно должен содержать сертификаты CA, которые зарегистрированы в текущем лесу. Это могут быть сертификаты промежуточных CA сторонних компаний, сертификаты которых вы используете. По большому счёту сюда должны публиковаться все сертификаты;
• CDP публикуются CRL списки CA для ускорения проверки сертификатов в цепочке. Так же, как и в случае с AIA не обязательно может содержать CRL'ы CA только текущего леса. Сюда могут публиковаться и CRL сторонних CA, сертификаты которых вы используете;
• Certification Authority публикуются сертификаты корневых CA, которым должен доверять весь лес.

Вы спросите, а зачем это всё, если то же самое можно сделать через групповые политики? Ответ тут достаточно очевиден. Дело в том, что PKI не видит границ доменов и эти сертификаты распространяются по всему лесу вместе с репликацией. Поэтому для добавления нового доверенного корневого CA вам придётся создавать одинаковую политику в каждом домене леса. И вы некоторые объекты (например CRL) не можете распространять через GPO.

Какие у нас есть инструменты для управления данными контейнерами? Их у нас несколько:

• ADSIEdit.msc — обеспечивает только просмотр содержимого контейнеров в AD (но сами записи там нечитабельны);
• PKIView.msc — позволяет просматривать содержимое каждого контейнера и удалять оттуда сертификаты. C использованием данной консоли мы можем добавлять сертификаты только в NTAuthCertificates. Остальные — только чтение и удаление;
• certutil — интерфейс командной строки, который позволяет добавлять, просматривать контейнеры и удалять сертифакты из них.

Кажется, что certutil'а хватит всем. Но у него есть одна большая проблема — ужасный синтаксис. Напрмер, если вы хотите посмотреть CRL'ы в AD, то придётся делать что типа такого:

certutil –viewstore ldap:///CN=MyCA,CN=CRL,CN=CDP,CN=Public%20Key%
20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

этот синтаксис возможно чем-то универсален, но cовершенно неудобный для использования в командной строке, поэтому я поставил задачу решить этот вопрос с помощью PowerShell. И вот как я его решил:

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

#####################################################################
# dspublish.ps1
# Version 0.7
#
# Adds certificates in Active Directory containers
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################
#requires -Version 2.0

# любая ошибка будет фатальной, поэтому при её возникновении останавливаем работу
# скрипта, чтобы предотвратить фатальные изменения в Active Directory
trap {break}
# объявляем глобальные переменные, которые будут использоваться всеми функциями скрипта
$script:ConfigContext = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().GetDirectoryEntry().distinguishedName
$script:ConfigContext = "CN=Public Key Services,CN=Services,CN=Configuration," + $script:ConfigContext
$script:Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2

function Publish-ADPKIObject {
<#
.Synopsis
    Publishes certificates to Active Directory containers
.Description
    Publishes certificates to Public Key Services containers in Active Directory.
.Parameter File
    Specifies the path to certificate file or X509Certificate2 object.
    Certificates may be passed through pipeline.
.Parameter Container
    Specifies the AD PKI container to publish file. For certificates only
    following containers MUST be used:
    
    RootCA - indicates that certificate will be published to Certification Authorities container
    SubCA - indicates that certificate will be published to AIA container
    NTAuthCA - indicates that certificate will be added to NTAuthCertificate directory
    entry. If not exist, entry will be created.
    
    you MAY specify several containers at once. Certificate will be added to all
    specified containers. Entry names are based on certificate subject.
    
.Parameter Force
    forces object rewrite if object already exist in Active Directory
.EXAMPLE
    dir *.cer | Publish-ADPKIObject RootCA, SubCA
    
    will publish all .CER certificates to Certification Authorities and AIA containers
.EXAMPLE
    Publish-ADPKIObject certificate.cer RootCA -Force
    
    will publish 'Certificte.cer' certificate to Certification Authorities container. If
    object already exist, it will rewrited
.Outputs
    This command provide a resultant of operation.
#>
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        [object[]]$file,
        [Parameter(Mandatory = $true, Position = 1)]
        [string[]]$Container,
        [switch]$Force
    )
    begin {
        # функция, которая будет осуществлять запись сертификатов в AD
        function _ldaproutine_ ($ldap, $CN, $script:Cert, $name, $Force) {
            $path = [ADSI]"LDAP://$ldap"
            # убеждаемся, что такой же объект не существует в AD
            if ($($path.psbase.children | ?{$_.cn -eq $CN})) {
                # если существует, проверяем ключ Force, который позволяет перезаписывать
                # объекты
                if ($force) {
                    $ldap = [ADSI]"LDAP://CN=$CN,$ldap"
                    # если ключ Force указан, то мы просто перезаписываем свойство
                    # cACertificate новым сертификатом
                    $ldap.put("cACertificate", $script:Cert.RawData)
                    # предыдущей строкой мы просто перезаписали объект, который теперь
                    # надо записать в AD методом SetInfo()
                    $retn = $ldap.SetInfo()
                    if ($?) {Write-Host "`'$CN`' certificate is sucessfully rewrited to `'$name`' container" -ForegroundColor Green}
                # если объект уже существует и ключ Force не указан, то просто выводим сообщение, что такой объект уже существует
                } else {Write-Warning "Object already exist in `'$name`' container. Use -Force switch to rewrite"}
            } else {
                # если объект ещё не существует в указанном контейнере, то создаём в нём новый объект
                # с типом certificationAuthority
                $CA = $path.Create("certificationAuthority","CN=$CN")
                # записываем сертификат в свойство cACertificate в бинарном виде из объекта X509Certificate2
                $CA.Put("cACertificate", $script:Cert.RawData)
                # записываем нулями обязательные поля, которые требуются для создания объекта. Использовать как есть.
                $CA.Put("authorityRevocationList", 0)
                $CA.Put("certificateRevocationList",0)
                # когда объект сформирован, записываем его в AD
                $retn = $CA.SetInfo()
                if ($?) {Write-Host "`'$CN`' certificate is sucessfully added to `'$name`' container" -ForegroundColor Green}
            }
        }
    }
    # рабочая секция, которая будет разбирать входные сертификаты и подготавливать необходимые данные
    # которые необходимы для записи 
    process {
        # выбираем текущий объект сертификата
        $script:Certificate = gi $file -ErrorAction Stop
        # проверяем, что объект не является готовым объектом X509Certificate2
        if ($script:Certificate -isnot [System.Security.Cryptography.X509Certificates.X509Certificate2]) {
            # если не является, то это будет файл. Проверяем расширение файла.
            # допускаются только расширения CER и CRT
            if (".cer", ".crt" -contains $script:Certificate.Extension) {
                # если это CER или CRT файл, то конвертируем его в объект X509Certificate2
                $script:Cert.Import($script:Certificate.FullName)
                # в переменную $CN записываем первую часть поля Subject сертификата
                [void]($script:Cert.Subject -match 'CN=([^,]+)')
                $CN = $matches[1]
            }
        # если у нас на конвейер или через аргументы поступил готовый X509Certificate2, то только выбираем
        # поле Subject в отдельную переменную.
        } else {
            $script:Cert = $script:Certificate
            [void]($script:Cert.Subject -match 'CN=([^,]+)')
            $CN = $matches[1]
        }
        # проверяем аргументы, которые указывают на контейнеры, куда надо записывать наши сертификаты.
        # я не делал проверку этих контейнеров в секции param() через использование ValidateSet
        # поскольку данная функция в будущем будет использоваться и для публикации CRL. А для
        # них нужно вручную прописывать имя записи в контейнере CDP и оно может быть произвольным.
        # отфильтровываем все неправильные контейнеры, которые были заданы при вызове функции
        $Container = $Container | ?{"RootCA","SubCA","NTAuthCA" -contains $_}
        # если после фильтрации ни одного валидного контейнера не осталось, то очень сильно ругаемся.
        if (!$Container) {throw "For certificate containers only following values are applicable: RootCA, SubCA, NTAuthCA"}
        # проверяем, что входной сертификат содержит свойство CertificateAuthority равным True.
        # это свойство соответствует расширению Basic Constraints в сертификате, которое может иметь
        # значения: Subject Type=CA - это сертификат CA и Subject Type=End entity, если это конечный
        # сертификат. А в X509Certificate2 конечный сертификат будет иметь значение False в свойстве
        # CertificateAuthority. Но работу скрипта не прерываем, а просто пропускаем текущий сертификат.
        if (!$script:Cert.Extensions | ?{$_.CertificateAuthority -eq $true}) {
            Write-Warning "Input certificate `'$CN`' is not recognized as CA certificate. Skipping"
            return
        }
        # а теперь подготавливаем необходимые данные для записи в зависимости от названия контейнера
        switch ($Container) {
            "RootCA" {
                # указываем название данного контейнера в AD
                $name = "Certification Authorities"
                # получаем LDAP объект этого контейнера
                $ldap = "CN=$name,$script:ConfigContext"
                # и отправляем всё это в функцию записи
                _ldaproutine_ $ldap $CN $script:Cert $name $Force
                $script:Cert.Reset()
            }
            "SubCA" {
                # здесь то же самое, что и для RootCA
                $name = "AIA"
                $ldap = "CN=$name,$script:ConfigContext"
                _ldaproutine_ $ldap $CN $script:Cert $name $Force
                $script:Cert.Reset()
            }
            "NTAuthCA" {
                $name = "NTAuthCertificates"
                $ldap = [ADSI]"LDAP://CN=$name,$script:ConfigContext"
                # поскольку NTAuthCertificates не является контейнером, а отдельной
                # записью, которая содержит массив сертификатов, то правила записи
                # здесь немного иные. Сначала проверяем, что эта запись уже существует в AD.
                if (!$ldap.cn) {
                    # если нет, то создаём её
                    $CA = ([ADSI]"LDAP://$script:ConfigContext").Create("certificationAuthority","CN=$name")
                    # заполняем обязательные свойства объекта и первый сертификат.
                    $CA.Put("authorityRevocationList", 0)
                    $CA.Put("certificateRevocationList",0)
                    $CA.put("cACertificate", $script:Cert.RawData)
                    # когда объект уже готов, то просто записываем его в AD
                    $retn = $CA.SetInfo()
                    if ($?) {Write-Host "`'$CN`' certificate is sucessfully added to `'$name`' container" -ForegroundColor Green}
                    return
                }
                # а вот если эта запись уже есть, то ничего создавать не надо, а просто добавляем
                # новый сертификат вдобавок к существующим. При этом обратите внимание, что объект добавляется
                # как массив (используется запятуя сразу за оператором). Это связано с особенностью работы PowerShell с
                # массивами. Поскольку бинарный сертификат сам по себе является массивом, то при простом добавлении
                # к существующему бинарному массиву, просто сделает ресайз текущего массива. Чтобы новый массив
                # записать как отдельный элемент нового массива - надо при помощи запятой явно это указать
                $ldap.cACertificate += ,$cert.RawData
                # и записываем объект обратно в AD.
                $retn = $ldap.SetInfo()
                if ($?) {Write-Host "`'$CN`' certificate is sucessfully added to `'$name`' container" -ForegroundColor Green}
                $script:Cert.Reset()
            }
        }
    }
}

А примеры использования этого скрипта приведены во встроенном хелпе и сводятся к одной из схем:

Publish-ADPKIObject <certificate> <container> –Force
<certificate> | Publish-ADPKIObject –Force

Причём вы можете указывать несколько контейнеров сразу, например: Publish-ADPKIObject file.cer NTAuthCA, RootCA, SubCA. Я думаю, что этот скрипт получился не такой уж и сложный и его разобрать с помощью моих комментариев не так и сложно. Его можно спокойно расширить под другие контейнеры, например, CDP или KRA. Единственное, что здесь пока не реализовано — санитизация имён объектов. На сколько я знаю, certutil этого тоже не поддерживает. Но сделать её надо. Правда, я пока не нашёл ни одного стандартного механизма, который бы санитизировал имена

Update 04.01.2010: исправлена неточность в тексте. CRL'ы из CDP контейнера AD не копируются на клиентские компьютеры.

В предыдущей статье: Обсуждение схем иерархии Certification Authority мы обсудили наиболее часто встречающиеся ошибки при дизайне иерархии CA. Если кто-то захочет перевести как минимум корневые Enterprise CA на Standalone CA и сделать их Offline, то в этом посте вы узнаете как это делается пошагово.

Изначальные условия:

• onlineca.adatum.com — DNS имя компьютера в домене/лесу adatum.com с установленной ролью Enterprise CA, которую планируется перенести на Standalone CA. Имя CA — Adatum Root CA;
• OfflineRCA — NetBIOS имя компьютера в рабочей группе. Этот компьютер будет держать роль Standalone Root CA для домена/леса adatum.com.

Предварительная переконфигурация

Перед переносом текущего корневого и/или Policy CA следует заранее спланировать периодичность публикации CRL. Если Enterprise CA, как правило, публикует Base CRL каждые 7 дней и Delta CRL — каждые 24 часа. Для Offline CA такая конфигурация будет неработоспособна. Поэтому мы должны переконфигурировать следующие параметры:

• Отключение публикации Delta CRL;
• Увеличение срока действия Base CRL;
• Настройка Overlap Settings.

Для этого мы можем применить вот такой Reg файл:

Примечание: Статья содержит сведения о внесении изменений в системный реестр. Перед внесением изменений в системный реестр рекомендуется создать резервную копию системного реестра и изучить процедуру его восстановления. Дополнительные сведения о создании резервной копии, восстановлении и изменении реестра см. в статье базы знаний Microsoft: http://support.microsoft.com/kb/256986/.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Adatum Root CA]
"CRLPeriod"="months"
"CRLPeriodUnits"=dword:00000003
"CRLOverlapPeriod"="weeks"
"CRLOverlapUnits"=dword:00000001
"CRLDeltaPeriod"="Days"
"CRLDeltaPeriodUnits"=dword:00000000
"CRLDeltaOverlapPeriod"="hours"
"CRLDeltaOverlapUnits"=dword:00000000
"CAXchgValidityPeriod"="Weeks"
"CAXchgValidityPeriodUnits"=dword:00000000
"CAXchgOverlapPeriod"="Days"
"CAXchgOverlapPeriodUnits"=dword:00000000
"ValidityPeriod"="Years"
"ValidityPeriodUnits"=dword:00000005

Этим файлом мы задаём срок действия Base CRL в 3 месяца (но этот период может быть и другой, в зависимости от местных условий) с overlap равным 1 неделя. Так же отключили использование Delta CRL и CA Exchange, который используется для архивирования ключей в базе CA. А так же установили срок действия конечных сертификатов в 5 лет. Если под этим CA будет выделенный Offline Policy CA, то это значение может быть изменено на 10 лет. После импорта этого файла, вы должны перезапустить службу Certificates Services:

net stop certsvc && net start certsvc

Теперь нужно опубликовать новый CRL с новыми настройками:

certutil –CRL

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

Бэкап Certification Authority

Бэкапу будут подлежать следующие вещи:

• База CA;
• Ключевая пара CA;
• Конфигурация CA.

Примечание: на данном этапе пользователи и компьютеры уже не смогут отправлять запросы на этот CA. Но могут продолжать использовать CRL'ы для валидации сертификатов.

Первым делом нужно сделать бэкап самой базы CA. Для этого в командной строке выполните:

certutil –backup c:\RootCA_%date%

Для удаления ключевой пары запустите консоль MMC и добавьте в ней оснастку Certificates с указанным контекстом Computer Account. В оснастке раскройте секцию: Personal –> Certificates и найдите текущий сертификат CA. Далее, Action –> All Tasks –> Export. На странице Export Private Key мастера экспорта сертификатов переставьте переключатель в Yes, export private key. На странице Export file format поставьте галочки напротив Delete the private key if the export is successful и Export extended properties. Этим самым мы удаляем закрытый ключ CA с данного сервера, поскольку он больше не нужен и для предотвращения несанкционированного доступа к ключу. Установите пароль на PFX файл и сохраните в него экспортируемый сертификат. После экспорта удалите этот PFX файл.

Примечание: экспорт сертификата в PFX нужен только для удаления с сервера закрытого ключа CA. Сам ключ был сохранён во время бэкапа базы CA.

Теперь у нас в корне диска C: будет храниться полный бэкап базы CA и его ключевая пара. Нам осталось выполнить бэкап конфигурации CA. Для этого откройте редактор реестра и установите курсор на ключе:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Adatum Root CA

Экспортируйте этот ключ в Reg файл и сохраните в папке, где расположен бэкап базы CA. После этого перенесите всю папку бэкапа на съёмный носитель и скопируйте в корень диска C: компьютера OfflineRCA.

Демонтаж Enterprise CA

Теперь мы готовы демонтировать наш Online Enterprise Root CA. Для этого запустите Server Manager (для 2008 и выше) или Add or Remove Programs –> Windows Components (для 2003) и удалите с сервера роль CA.

После демонтажа роли убедитесь, что данный CA больше не отображается в AD как Issuing CA. Для этого можете запустить оснастку ADSIEdit.msc в контексте Configuration. И пройдите по пути: Configuration –> Services –> Public Key Services –> Enrollment Services. Если демонтируемый CA отсутствует внутри этой папки, то можете закрыть консоль. Если всё ещё отображается, то удалите запись данного CA и закройте ADSI Editor.

Примечание: для удаления объектов PKI из AD вам потребуются права Enterprise Admins.

Установка Offline Standalone CA

На данном этапе все манипуляции будут производиться на сервере OfflineRCA, который состоит в рабочей группе. Запустите Server Manager (или Add or Remove Programs –> Windows Components для 2003) и поставьте галочку на Active Directory Certificate Services (или Certification Authority для 2003). Я думаю, что мастер вам уже знаком, поэтому я только расскажу на каких страницах мастера нам потребуется сделать изменения. В принципе, можете двигаться Next->Next до страницы Private Key. На этой странице выберите Use existing private key и Select a certificate and use its associated private key. Нажмите Next и нажмите кнопку Import. Импортируйте закрытый ключ вместе с сертификатом из PFX файла, который находится в папке с бэкапом CA. На следующей странице можете задать папки хранения базы CA.

Примечание: вам не обязательно устанавливать Standalone CA на полный сервер, а лучше будет устанавливать в Server Core.

Когда роль CA установлена, мы должны восстановить базу CA и конфигурацию. В командной строке выполните:

certutil –restore c:\RootCA_%date% –f –config "OfflineRCA\Adatum Root CA"

и конфигурацию восстановить простым запуском Reg файла. Если ваш бывший корень публиковал сертификаты и CRL в LDAP, то теперь мы не сможем это делать напрямую. Чтобы исправить это, откройте оснастку CertSrv.msc, выберите свойства CA и перейдите на вкладку Extensions. В ней найдите и удалите все LDAP ссылки в CDP и AIA, которые связаны с вашим доменом.

Всё, теперь мы полностью перенесли Online Enterprise Root CA на Offline Standalone CA, который теперь может выключаться на очень большие промежутки времени. По сути это потребуется только для того, чтобы опубликовать новый CRL, издать новый сертификат подчинённому CA или обновить свой собственный сертификат. Ну и обновления на сервер ставить тоже надо невзирая на то, что сервер будет большую часть времени выключен.

Включение распознавания Offline CA в лесу

Чтобы наш мигрированный CA распознавался в исходном домене/лесу adatum.com, нам нужно опубликовать его сертификаты в следующих контейнерах Active Directory:

• Certification Authorities — данный контейнер используется для организации доверия корневым CA в текущем лесу. Данные сертификаты автоматически копируются в контейнер Trusted Root CAs всех компьютеров в лесу;
• AIA — данный контейнер используется для публикации Subordinate (или Intermediate) CA. Это позволяет сократить время на построение цепочек сертификатов. Сертификаты из данного контейнера автоматически копируются в Intermediate CAs на каждый компьютер в текущем лесу;
• CDP — данный контейнер используется для публикации любых CRL. Чуть ниже я расскажу, как вы будете его использовать. Содержимое данного контейнера не копируется клиентам и будет использоваться только в случае, если какой-то сертификат явно ссылается на CRL в этом контейнере.
• CN = NTAuthCertificates — это запись внутри контейнера Public Key Services. Данная запись содержит сертификаты тех CA, которые выдавали логонные сертификаты. Это относится как к логонным сертификатам для смарт-карт, сертификатам для аутентификации в IIS и VPN.

Для импорта сертификата CA войдите в домен с правами Enterprise Admins, скопируйте открытую часть сертификата в C:\RootCA.cer, запустите командную строку и выполните:

certutil –dspublish –f c:\RootCA.cer RootCA
certutil –dspublish –f c:\RootCA.cer SubCA
certutil –dspublish –f c:\RootCA.cer NTAuthCA

После того, как пройдёт репликация в лесу, наш новый CA будет полностью распознаваться как доверенный в текущем лесу.

Установка Online Enterprise Issuing CA

Теперь можно приступать к процессу установки Enterprise Subordinate CA, который уже будет обслуживать конечных потребителей. Единственная разница в установке будет в том, что в списке ролей CA вы должны выбрать Enterprise Subordinate CA.

Совет: при установке CA старайтесь избегать привязки к домену в distinguished name CA. Используйте только привязку к названию компании, например:

CN = Adatum Class 1 Public Primary Certification Authority
OU = DB management systems
O = Adatum Inc.
C = US

Сохраните запрос в файл и получите сертификат у вышестоящего Offline CA (корневого или policy). Этот вопрос выходит за рамки данного материала, поэтому рассматриваться не будет. Сконфигурируйте CA должным образом (точки распространения сертификатов, CRL, периодичность публикации CRL, шаблоны, etc.) и можете запускать его в работу.

Offline CA CRL lifecycle

В случае, если ваш Enterprise CA до миграции публиковал LDAP ссылки в сертификатах, то для избежания задержек при проверке сертификатов, вы в течении всей жизни текущего сертификата корневого и/или Policy CA должны поддерживать доступность CRL в этих точках. Поскольку наши Root и Policy CA теперь члены рабочей группы и не могут публиковать CRL прямо в AD, вам придётся заниматься этим вручную. Когда Offline CA опубликует новый CRL, вы должны его доставить (по сети, что не очень рекомендуется, или через съёмные носители) в точки, куда он публиковался раньше (чтобы обеспечить работоспособность расширений CDP/AIA сертификатов). Если с HTTP ссылками всё просто (положили файл на веб-сервер и всё), то с LDAP придётся делать чуточку иначе, а именно — публиковать его в AD в контейнер CDP:

certutil –dspublish –f C:\RootCA.crl "Adatum Root CA"

Ещё раз обращаю ваше внимание на то, что эта операция требует права Enterprise Admins.

Кажется ничего не забыл. Но если что-то забыл — напомните.

Update 05.12.2009: выпилена часть про смену пароля как не совсем правильную (см.каменты). Судя по логике смены паролей компьютерами в домене, можно реализовать Offline CA в доменной среде с большим сроком бездействия. Но это всё равно не отменяет того факта, что такое решение будет не совсем правильным.

Сегодня хочу немного обсудить несколько (все не получится :-() вопросов планирования ирерархий Certification Authority (CA), как это делается в реальном мире. Как таковых бест-практисов на эту тему не существует, равно как и бест-практисов по планированию лесов Active Directory. Есть только несколько стандартных классических схем и рекомендаций на основании которых можно выбирать. Этот вопрос очень серьёзный, поскольку иерархии PKI и AD очень редко меняются в силу сложности и дороговизны процесса. И с тем вариантом, который вы выбрали на этапе планирования, скорее всего вы будете жить очень долго.

Лирическое отступление

В реальной жизни домены и PKI в основном развёртываются по одному из трёх сценариев:

• Говноадминами в метро на коленке за 15 минут;
• Системными администраторами после тщательного (по мере сил) анализа существующей инфраструктуры;
• Системными интерграторами или аутсорсерами, грохая огромные деньги на полный и компетентный анализ существующей инфраструктуры, учитывая требования бизнеса с запасом на 5 лет минимум.

Не всем посчастливилось устроиться работать в компанию последней группы и чаще всего приходится работать в первых двух. С первым вариантом даже обсуждать нечего, потому что с такими администраторами говорить вовсе не о чем, разве что смаковать последние новости с ЛОРа, секлаба и двача. Я всё-таки надеюсь, что этот пост будет полезен администраторам второй группы.

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

1. Root CA — корневой CA, который является наиболее критической точкой в инфраструктуре, потому что потеряв/скомпрометировав его, ваша PKI и репутация компании летит к чёрту, поскольку это та точка доверия, которая проверяется весьма условно. Т.е. вы доверяете тому или иному корневому сертификату только на основании каких-то косвеных данных или собственных предпочтениях. Технически проверить «хорошесть» корня не представляется возможным. Как правило выдаёт сертификаты только подчинённым Policy CA.
2. Policy CA — даже не знаю как его перевести, поэтому не буду. Но его суть сводится к тому, что данный тип CA определяет политику сертификации на данном CA и на всех последующих CA в цепочке. Каждый Policy CA характеризуется своим собственным CPS (Certificate Practice Statement). Поэтому если у вас на предприятии используются различные схемы проверки подлинности участников, которые запрашивают сертификаты и требования к ним, а так же мероприятия по организации CA, то каждая такая схема выносится в отдельный CPS и отдельный Policy CA. Так же, как и корень, является критической точкой в иерархии, но чуть меньше, чем корневой CA. Поскольку изъять из эксплуатации (decomission) Policy CA всяко проще, чем корневой. Об этой проблеме я уже говорил в посте Certificate chaining engine (CCE) и отзыв корневых сертификатов. Policy CA может быть выделенный и выдавать сертификаты только подчинённым Policy или Issuing CA. А может быть и одновременно совмещён с ролью Issuing CA.
3. Issuing CA — издающий CA, который уже выдаёт сертификаты конечным потребителям — пользователям, компьютерам, различным сетевым устройствам. Каждый Issuing CA должен подчиняться тем требованиям и указаниям, которые описаны в CPS Policy CA.

Enterprise Root CA — хороший выбор?

В условиях малого и среднего бизнеса не всегда можно набрать компетентный в этих вопросах персонал, поэтому админстраторы обычно делают всё попроще — ставят 1 или 2 Enterprise Issuing CA и радуются жизни. В таких ситуациях один единственный CA выполняет все 3 роли — он и корневой, и Policy и издающий CA. Чем это плохо? Учитывая тот факт, что сервер CA находится постоянно в сети и его настройки безопасности могут содержать брешь, через которую CA можно легко скомпрометировать. Это, например, совмещение роли CA с другими ролями, как контроллер домена, сервер терминалов, файл-сервер и т.д. В данных случаях получить доступ к закрытому ключу CA будет проще, чем в остальных сценариях.

Если выделить отдельный сервер, член домена, под роль CA, то риск снижается, но незачительно, поскольку любой член групп Domain/Enterprise Admins, операторы бэкапа, etc. могут получить доступ к ключу CA. Это весьма неиллюзорная угроза, поскольку обидевшийся админ может поломать вам единственный корневой CA и даже использовать его ключ в корыстных целях — выпускать «липовые» сертификаты. Учитывая, что не существует идеальной ОС и в любой из них обнаруживаются те или иные уязвимости, при помощи которых злоумышленник может положить ваш CA не слезая с подругидивана просто запустив эксплоит (я надеюсь, что случай с конфикером/кидо напоминать не надо?). Другая проблема заключается в том, что ваш корневой CA будет жить ровно столько, сколько живёт сам домен/лес, поскольку мигрировать в другой домен/лес может быть весьма проблематично. И если вы решили переименовать домен или мигрировать в другой лес, то неиллюзорный секс с миграцией PKI вас ожидает, особенно, если всё делалось простым Next-Next. Это означает, что даже в условиях сети на 20 человек, держать корневой CA постоянно в сети — не самая лучшая идея. Хотя, если у вас есть HSM (Hardware Security Module), то опасность компрометации такого CA снижается, но не на столько, чтобы оправдать наличие корневого CA в доменной сети. Да и цена таких девайсов явно не по карману компаниям малого и среднего бизнеса. Лично мне с HSM поработать не довелось.

Следовательно, чтобы избежать всех этих проблем путь есть только один — вынос корневого CA из домена на отдельный сервер рабочей группы. При этом вы можете не покупать Enterprise редакции Windows Server, поскольку в рабочей группе хватает Standard Edition (а с выходом Winows Server 2008 R2, Standard тянет даже на Enterprise CA). Какие преимущества вы получите от такого CA?

• Резко уменьшается количество людей, которые могут получить доступ к серверу (как физический, так и программный);
• В рабочей группе вы никак не привязаны к имени домена/леса. Что позволяет сохранять корень доверия даже при смене лесов;
• В рабочей группе сервер не обязательно должен быть подключён к сети. А лучше вообще не подключать к сети, в результате чего вероятность атаки с использованием уязвимости резко падает до нуля;
• Вы можете сделать Offline CA, который будет включаться только для того, чтобы обновить свои CRL, выдать сертификат новому подчинённому CA или обновить свой собственный сертификат. Учитывая, что корневой CA выдаёт сертификаты только другим CA, поэтому вероятность необходимости отзыва такого сертификата не очень высока. Это позволяет увеличить срок действия CRL до нескольких месяцев. Здесь главное — не переусердствовать и делать срок действия CRL более 3-х месяцев вряд ли будет разумным.

С учётом выской популярности и доступности систем виртуализации, даже если у вас нет лишнего железа для сервера CA (а CA к ресурсам крайне нетребователен и может спокойно работать на железе уровня Pentium III), то вы с лёгкостью можете развернуть корневой CA на виртуальной машине с минимальной затратой средств. При этом виртуальную машину лучше хранить на съёмном жёстком диске, который можно прятать в сейф.

Policy CA — что это и зачем оно нужно?

Это достаточно большой и очень теоретический вопрос. В действительности Policy CA от остальных отличает только активная кнопка Issuer Statement:

К сожалению очень многие компании забивают на такую мелочь. Подумаешь, есть кнопка или нет её. Но в действительности Policy CA очень нужен, поскольку кнопка Issuer Statement ведёт на CPS данной ветки иерарахии CA. Как я уже говорил, CPS документально описывает порядок работы служб сертификации и сопутствующих механизмов. В RFC 3647 вы можете более подробно ознакомиться с содержимым CPS или просто почитать CPS коммерческих CA, например, VeriSign — http://www.verisign.com/repository/cps. И это не просто бумажка какая-то, а уже юридический документ, за нарушение условий которого можно получить конфет пизденцовнанести сильный ущерб доверию компании со стороны самих сотрудников и внешних партнёров. Поскольку компания может вырасти или могут поменяться условия работы, не рекомендуется совмещать роль Policy CA с ролью корневого CA, потому что корень у вас только один, а политик сертификации может быть несколько. Все последующие CA (если есть) будут подчиняться политике самого первого Policy CA в цепочке. Поэтому каждый CA второго уровня (следом за корнем) будет представлять своё дерево политик сертификации со своим CPS.

Если Policy CA не рекомендуется совмещать с корнем, то совмещать его с Issuing CA вполне можно, если у вас планируется только один Issuing CA. Если же их будет больше одного, то Policy CA следует выносить отдельно и предусмотреть для него такие же правила размещения, как и для Offline Root CA (об этом я рассказывал чуть выше). Почему не рекомендуется совмещать Policy CA и Issuing CA, если издающих будет больше одного? Дело в том, что у вас не должно быть больше одного уровня издающих CA. Т.е. вот такой схемы:

Поскольку в этом во-первых нет необходимости и вы почём зря удлиняете цепочку сертификации. В принципе, иерархии состоящие из более, чем 4-х уровней нежизнеспособны, поскольку CCE (Certificate Chaining Engine) каждый раз будет тратить очень много времени на построение и проверки цепочек сертификатов и из-за таймаутов может давать битые цепочки. Конечно же, за такое вас никто бить по лицу ногами не будет, но таких схем лучше избегать за исключением очень сложных схем, когда используется 2 уровня Policy CA (что подразумевает несколько различных политик сертификаций) и 2 уровня издающих CA. Такое возможно только в больших компаниях и их я не затрагиваю в данном материале. В случае если вам необходимо иметь несколько издающих CA под одним Policy CA, то схему лучше строить вот так, в зависимости от количеста издающих CA:

В первом случае у нас будет простая иерархия с единственным издающим CA, который так же выполняет роль Policy CA и ниже по иерархии ничего нет. Если ВНЕЗАПНО появятся потребности в ещё одном издающем CA, то это решается достаточно путём миграции ко второй схеме. Я не уверен, что Microsoft поддерживает миграцию с Online Enterprise CA на Offline Standalone CA, но я сам такие миграции делал и особых проблем это не вызывало. Просто при миграции нужно учитывать несколько нюансов и всё. Поэтому с учётом перспективы целесообразно делать такую схему изначально. По большому счёту это наиболее распространённые схемы иерархий PKI.

Время жизни сертификата CA

И ещё один момент, который хочу посмотреть — какой срок действия должен быть у сертификата CA? Вопрос достаточно риторический и зачастую зависит от требования к сроку действия конечных сертификатов. Но обычно используется простая схема:

• конечный сертификат — 3 года;
• Issuing CA — 5 лет;
• 2 Level Policy CA — 10 лет;
• 1 Level Policy CA — 15 лет;
• Root CA — 20 лет.

Т.е. если у вас 2-х уровневая иерархия PKI, то Issuing CA будет на 5 лет, а Root CA на 10 лет. Для 3-х уровневой иерархии Issuing CA на 5 лет, Policy CA на 10 лет и Root CA на 15 лет. Но основной отправной точкой будет требования к сроку действия конечных сертификатов.

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

В последнее время мне всё чаще стали задавать вопрос, что выбрать, AppLocker или старый добрый SRP?

Казалось бы, что тут думать — AppLocker и точка. Многие, наверное, помнят пиар-акцию под названием «Windows 7 + 1», которую проводили многие MVP для рекламы новых технологий Windows 7. И весьма досадно то, что некоторые MVP вместо раскрытия реальной объективности новых технологий распространяли просто маркетинговый булшит и даже подтасовывали факты. Например статья Владимира Безмалого про AppLocker:

• AppLocker как средство обеспечения информационной безопасности
• AppLocker Часть 2

Этот вариант статьи можно ещё прочитать и здесь: http://www.osp.ru/win2000/2009/09/10721226/. Моё внимание обратила на себя табличка сравнения SRP и AppLocker. Вот она с моими комментариями:

Я думаю, что ни для кого не секрет, что аудит в SRP был и не сильно хуже, чем в AppLocker. Разница лишь в том, что AppLocker пишет в свой собственный EventLog, а SRP писал аудит в текстовый файл.

На счёт мастера создания правил я немного не понял. В принципе, окно создания правила в SRP тоже своего рода мастер. Только одношаговый, в отличии от AppLocker.

А сообщения об ошибках в SRP были тоже. Как в виде диалогоых окон, так и в журнале Application в эвентлоге. Т.е. тут у меня 2 мнения — либо человек не работал с SRP, либо намеренно исказил факты, чтобы подкрутить популярность AppLocker'а, поскольку революции AppLocker не совершил. Ведь с появлением AppLocker мы приобрели не только удобный интерфейс, но и потеряли несколько полезных вещей, которые есть в SRP. Как я уже отмечал ранее, мы потеряли возможность самостоятельно регулировать список контролируемых расширений файлов и потеряли возможность фильтрования файлов по конкретным сертификатам. Новое правило издателя позволяет контролировать версию разрешённого приложения, но не отличает каким сертификатом подписано приложение. Да и применимость издателей такая же как и у классических правил сертификатов — т.е. низкая. К сожалению я не могу вспомнить ни одно бизнес-приложение (не стандартные приложения типа Microsoft Office), которое бы было подписано. Плюс невозможность использования системных переменных окружения так же усложняет создание правил в доменной среде. Эту табличку можно переделать в такой вид:

	SRP	AppLocker
Применение правил	Все пользователи	Определённые группы и пользователи
Уровень по умолчанию	Unrestricted	Deny
Разрешающее действие
Запрещающее действие
Особое действие
Правила сертификатов
Правила издателей
Правила хешей
Правила сетевой зоны
Правила пути
Системные переменные окружения
Собственные переменные окружения
Пути из реестра
Режим аудита
Группировка правил
Мастер создания правил
Импорт/экспорт политик
Поддержка PowerShell
Сообщения об ошибках
Настраиваемый список расширений

Мы видим, что преимущество AppLocker перед SRP резко переходит на нет. Я не хочу сказать, что AppLocker — отстой, а лишь хочу показать, что реализация этой технологии не на столько крутая, что её стоит пиарить как революцию.

Из блога Владимира Безмалого:

В Windows 7 SRP также могут применяться, однако все чаще будет использоваться AppLocker. Почему?

К сожалению этого не случится, во всяком случае в цикле Windows 7. Как уже отмечалось, наиболее значительное изменение в AppLocker — это новый простой, удобный и понятный интерфейс, чего в SRP не было. В значительной степени из-за этого SRP на домашних компьютерах применялся лишь в единичных случаях. Сейчас же применить AppLocker гораздо проще на домашних системах при получении одинаково эффективного результата. Но Microsoft слишком жадный и включил эту технологию только в Windows 7 Ultimate и Enterprise. Я верю, что от появления SRP в домашних редакциях Windows 7 количество применений SRP на них не увеличится совсем. Учитывая, что с ноутбуками будет чаще всего проинсталлирована какая-то домашняя редакция Windows 7, то профита от AppLocker они не получат тоже. Но если дома есть возможность использовать AppLocker и вы хотите получить адекватный уровень защиты от запуска случайных файлов — используйте AppLocker. Хотя, скажите, кто из вас, кроме меня, использует Windows 7 Ultimate/Enterprise дома и использует AppLocker?

Если вы будете иметь возможность перевести часть парка машин предприятия на Windows 7 Enterprise, то вопрос использования AppLocker может сложиться не в его пользу. Это обусловлено тем, что если у вас уже используется SRP, то вам AppLocker не будет нужен до тех пор, пока весь парк не будет переведён на Windows 7 Enterprise. Ведь с AppLocker вы ощутимых бенефитов не получите в плане безопасности, но сразу усложните себе жизнь тем, что вам придётся поддерживать гораздо больше политик — SRP и AppLocker. При необходимости поддерживать клиентов отличных от Windows 7 Enterprise лучше использовать то, что может охватить наиболее число машин — SRP.

Внимать моим рекомендациям — личное дело каждого, просто я отразил своё видение проблематики. Вобщем, я не верю в массовое светлое будущее AppLocker по крайней мере до выхода следующей версии Windows, даже не смотря на активный и нечестный пиар технологии со стороны Microsoft (что вполне нормально для самого создателя) и прочих пиарщиков. Но начинать его использование по мере возможности — очень даже можно и нужно, т.к. однажды SRP просто не окажется в релизе ОС.