Disclaimer: Эта статья содержит сведения о правке реестра. Перед внесением изменений в системный реестр рекомендуется изучить процедуру его восстановления. Для получения дополнительных сведений о восстановлении реестра см. разделы «Восстановление реестра» или «Восстановление раздела реестра» справочной системы редактора реестра.

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

• Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов — подведение итогов (ссылку будет по окончании написания этого цикла).

В предыдущей части мы поговорили о процессе аутентификации по сертификату (или смарт-картой), но не поговорили о том, как сертификат связывается (ассоциируется) с учётной записью пользователя в Active Directory. Процесс ассоциации сертификата с учётной записью называется certificate mapping. В мире Active Directory существует 2 вида маппинга:

• Implicit certificate mapping;
• Explicit certificate mapping.

Implicit certificate mapping

Implicit certificate mapping (в переводе звучит как «неявный» маппинг. В точности перевода могу ошибаться) является самым простым, шустрым и очевидным методом ассоциации сертификата с учётной записью пользователя. Для этого клиентский сертификат должен содержать расширение Subject Alternative Name и в нём должен быть прописан UPN (User Principal Name) пользователя:

Other Name:
     Principal Name=Administrator@contoso.com

Контроллер домена извлекает UPN пользователя из сертификата и пытается найти такой же UPN в глобальном каталоге. UPN хранится в атрибуте sAMAccountName. Если такой UPN найден, сертификат привязывается к учётной записи пользователя с указанным UPN. В противном случае считается, что учётная запись не найдена и аутентификация проваливается.

На заметку: некоторые пользователи (особенно, которым нужен доступ в 2 и более леса, которые не связаны доверительными отношениями) думают, что можно накидать несколько UPN'ов в расширение и получать профит — один универсальный сертификат для логона в 2 и более леса. Если в расширении SAN указано несколько различных UPN'ов, контроллер домена будет читать только первый из списка.

В 99% случаев вы будете использовать только implicit certificate mapping, который используется по умолчанию.

Explicit certificate mapping

В отдельных случаях у вас может и не быть возможности использовать implicit certificate mapping. Например, это сторонний (или коммерческий) CA, который по каким-то причинам не может или не хочет включать UPN пользователя в расширение SAN. Или у вас просто есть сертификат от чужого леса и вы его хотите использовать для двух лесов, которые друг о друге ничего не знают. И знать не хотят, видимо. С implicit certificate mapping вы можете использовать сертификат только в одном лесу или в нескольких лесах — но при условии, что UPN'ы в лесах совпадают.

Так же, существует ненулевая вероятность, что у вас будет сертификат с прописанным UPN в расширении SAN, но вы захотите использовать этот сертификат для другого UPN. Что делать? По умолчанию, контроллер домена при наличии UPN в SAN применяет *implicit mapping*, т.е. привязка по UPN и он даже не попытается попробовать explicit mapping. Хоть, такие случаи достаточно редки, но бывают нужны, вы можете отключить implicit mapping на уровне домена создав следующее значение в реестре (на контроллерах домена):

KEY =  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Type = DWORD
Value Name = UseSubjectAltName
Value Data = 0

Примечание: это возможно только для Windows Server 2008 и выше. Детали описаны в статье How to disable the Subject Alternative Name for UPN mapping. Но я ещё раз предупреждаю, что делать это следует только когда вы чётко понимаете, что вы делаете и какие последствия вас могут ожидать.

One-to-one mapping

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

Суть этого метода заключается в том, что определённые свойства сертификата должны быть описаны в атрибуте altSecurityIdentities (доступно через Attribute Editor) свойств учётной записи пользователя. Вот как можно создать маппинг one-to-one в консоли Active Directory Users and Computers:

1. Откройте оснастку Active Directory Users and Computers (dsa.msc);
2. В меню View установите флажок на Advanced Features;
3. Выберите учётную запись пользователя, с которой будут связываться сертификаты группы работников;
4. В контекстном меню выберите Name Mappings;
5. В открывшемся окне, кнопкой Add добавляете необходимые сертификаты.

Смотрите, здесь уже используется (и не отключается) маппинг по Issuer DN Name и Subject DN Name. Т.е. если контроллеру предъявляют сертификат с такими же значениями полей Subject и Issuer, он привяжет этот сертификат к этой учётной записи, где настроен маппинг. Если снять чек-бокс «Use Subject for alternate security identity», любые сертификаты, выданные конкретным сервером CA будут мапиться к этой учётной записи и это будет many-to-one certificate mapping. Но не следует использовать маппинг только по издателю. О более гибких примерах маппинга мы поговорим ниже. Вот пример:

В данном случае любой сертификат с конкретным Subject DN, который выдан конкретным CA будет мапиться к рассматриваемой учётной записи.

Many-to-one mapping

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

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

1. Точное совпадение полей Subject и Issuer — X509:<I><S>
2. Только по полю Subject — X509:<S>
3. По полям Issuer и Serial Number — X509:<I><SR>
4. По расширению Subject Key Identifier — X509:<SKI>
5. По Thumbprint (хешу всего сертификата) — X509:<SHA1-PUKEY>
6. И, наконец, по полю RFC822 Name (он же адрес электронной почты) — X509:<RFC822>

Вот примерная таблица (зелёным отмечены правильные условия проверки, красным — неправильные):

Например, у пользователя есть сертификат на CN=Oleg Krylov, OU=Users, DC=contoso, DC=com и который выдан CN=Contoso Corporate CA, DC=contoso, DC=com. Из картинки видно, что мы можем применить следующий биндинг: X509:<I><S>. И вот как его следует использовать в altSecurityIdentities:

• X509:<I>DC=com,DC=contoso,CN=Contoso Corporate CA

Во-первых, элементы DN размещаются в обратном порядке от представления в сертификате. Т.е. сначала RDN, а потом уже CN, потому что они так кодируются в сертификате. Вот, пример ASN1 структуры сертификата VeriSign:

И посмотрите на Subject этого сертификата в UI: http://EVSecure-aia.verisign.com/EVSecure2006.cer. Т.е. вам необходимо взять сертификат и переписывать поле Subject/Issuer снизу вверх. Во-вторых, каждый элемент DN разделяется запятой и вокруг запятых пробелов быть не должно.

У сертификата есть расширение Subject Key Identifier = c1 2f a9 f1 c0 22 d4 37 a2 20 07 1d b9 ab 4a 12 ef f2 f9 fa и вы хотите сделать маппинг по этому расширению. Для этого в свойство altSecurityIdentities необходимо прописать строку следующего содержания:

• X509:<SKI>c12fa9f1c022d437a220071db9ab4a12eff2f9fa

Если делаете маппиг по схеме X509:<I><SR> (по издателю и серийному номеру), следует учитывать, что байты серийного номера должны идти в обратном порядке. Т.е. если в сертификате мы видим вот такой серийный номер: 2e 33 87 4f 6f e2 d4 1e d3 ff ff 35 f6 a4 c9 18, в условии маппинга следует переписывать байты справа налево: 18 c9 a4 f6 35 ff ff d3 1e d4 e2 6f 4f 87 33 2e или вот так:

• X509:<I>DC=com,DC=contoso,CN=Contoso Corporate CA<SR>18c9a4f635ffffd31ed4e26f4f87332e

Это связано с тем, что в структурах C серийный номер (CRYPT_INTEGER_BLOB) записывается в обратном порядке и KDC будет использовать серийный номер так, как он хранится в структуре.

Если на каком-то этапе удалось обнаружить однозначное сходство — дальнейшие попытки биндинга сертификата не производится, а сертификат привязывается к учётной записи и пользователь продолжает процесс аутентификации. Кстати, почему так сложно? Почему бы не взять и не просто сверить 1:1 предъявленный сертификат, с опубликованным в свойствах учётной записи? Ответ тут достаточно очевидный — вы можете использовать many-to-one (когда сравниваются только определённые атрибуты сертификатов). И если вам надо связать множество сертификатов с одной учётной записью, их всех придётся публиковать, а это может неприятно отразиться на репликации. И короткие строки сравнивать быстрее, чем бинарные массивы.

Примечание: many-to-one certificate mapping можно реализовать как средствами Active Directory (описано в статье), так и средствами IIS. При установки роли веб-сервера, у вас есть 2 похожих пункта:

С виду их не отличишь, но теперь вы знаете, что первый пункт (Client Certificate Mapping Authentication) использует маппинг настроенный в Active Directory, а IIS Client Certificate Mapping использует маппинг настроенный в IIS. Подробнее: Many-To-One Mappings <manyToOneMappings>.

Эпилог

Чувствую, что написал очень много и непонятно. Я не обещал, что будет легко. В принципе, вы можете читать только раздел Implicit certificate mapping, а остальное — только когда потребуется или просто ради лулзов . В следующей части перейдём немного от теории к практике.

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

• Windows Vista Smart Card Infrastructure

Сегодня хочу поговорить и обозначить неочевидные моменты, которые связаны с энроллментом сертификатов от имени другого пользователя. В определённых сценариях администратору (или агенту подачи заявок на сертификаты) требуется запрашивать сертификаты от имени другого пользователя. Как пример такого сценария — распространение смарт-карт на предприятии. В таком случае в организации выделяется специальный человек, который будет этим заниматься. Этот человек будет называться 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'е тебе моём?

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

В предыдущих частях мы разговаривали о применении смарт-карт для хранения и использования ключей шифрования EFS в Windows Server 2008. Мы так же рассмотрели вопросы реализации агентов восстановления и самого процесса восстановления. Предыдущие 3 части:

• EFS и смарт-карты в Windows Server 2008 (часть 1)
• EFS и смарт-карты в Windows Server 2008 (часть 2)
• EFS и смарт-карты в Windows Server 2008 (часть 3)

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

• пользователи не могут шифровать новые файлы отозванными или просроченными сертификатами, но сохраняется возможность расшифровывать ранее зашифрованные файлы;
• агенты восстановления EFS файлов теряют возможность дешифрования файлов, которые были зашифрованы после истечения срока или отзыва сертификата агента восстановления. В этом случае когда пользователи шифруют файлы, то они заполняют только DDF, но не DRF, который остаётся пустым.
• агенты восстановления Key Archival так же утрачивают возможность восстановления закрытых ключей пользователей из базы CA, которые были сгенерированы после истечения срока Key Archival сертификата. В этом случае закрытые ключи пользователей не шифруются просроченными сертификатами агентов Key Archival. В результате извлечение BLOB файла из базы CA будет невозможно. Однако, эти агенты могут дешифровывать ключи пользователей, которые запрашивали сертификаты в период валидности сертификатов агентов Key Archival.

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

Вот теперь, я так полагаю, мы в достаточной мере рассмотрели вопрос использования смарт-карт для EFS. В качестве эпилога скажу, что рекомендуется использовать комбинированные шаблоны для агентов восстановления. Например, если агент восстановления будет хранить свои закрытые ключи от EFS и Key Archival на смарт-карте, то выгодней будет использовать шаблон Smart Card Logon и в его EKU добавить уже необходимые области применения (например, Key Archival), что упрощает процедуру эксплуатации таких сертификатов в будущем. Не нужно будет теперь заботиться, что отдельные сертификаты будут истекать в разное время и при компрометации смарт-карты придётся отзывать несколько сертификатов - достаточно будет отозвать один сертификат. То же самое касается и пользователей, которые используют смарт-карты. Достаточно в Smart Card Logon EKU добавить Basic EFS и всё будет хорошо. Почти хорошо, если у вас есть Enterprise или Datacenter редакция Windows Server :)

Вопросы обновления сертификатов и прочие lifecycle эксплуатации (например, введение Certificate Autoenrollment и прочее) смарт-карт и EFS уже выходят за рамки моей статьи, поэтому вам придётся этот материал изучать самостоятельно. И на последок я подобрал несколько полезных ссылок, которые помогут с освоением данного материала:

• The Encrypting File System
• Protecting Data by Using EFS to Encrypt Hard Drives
• Implementing Key Archival Walkthrough
• Key Archival and Management in Windows Server 2003
• Certificate Revocation and Status Checking
• Certificate Autoenrollment in Windows Server 2003 (.doc)

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

• EFS и смарт-карты в Windows Server 2008 (часть 1)
• EFS и смарт-карты в Windows Server 2008 (часть 2)

Когда у нас все агенты восстановления подготовлены и подготовлены шаблоны EFS + Smart Card Logon, то необходимо заранее подготовить смарт-карты и выпустить для них сертификаты. Для этого можно воспользоваться консолью MMC - certmgr.msc и выполнить запрос сертификата:

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

В Public Key Policies нужно выбрать свойства Encrypting File System и получим такое окно. Здесь у нас появилось много новых настроек, которых раньше не было. Вот скрин этого же окна в Windows Server 2003:

тут мы можем только или разрешить или запретить использование EFS. Пробежимся по настройкам новой консоли:

• Encrypt the contents of the users's Documents folder - при использовании этой опции будет зашифрована вся папка Documents пользователя. Особого смысла в ней не вижу. Но кому-то может пригодиться.
• Require a smart card for EFS - опция, которая позволяет принудительно хранить EFS ключи шифрования на смарт-картах. Если эта опция включена, но смарт-карты не реализованы, то шифрование будет недоступно. Т.к. у нас смарт-карты есть, то выставляем здесь флажок.
• Create caching-capable user key from smart card - данная опция позволяет кэшировать ключи шифрования для обеспечения возможности шифрования при изъятом токене или смарт-карте. Параметры кэширования настраиваются дополнительно на вкладке Cache. Если этот флажок сброшен, то будут действовать настройки кеширования драйвера смарт-карты.
• Enable pagefile encryption - разрешает шифровать файл подкачки. При включении шифрования файла подкачки может замедлиться работа системы и увеличиться нагрузка на систему. Во всяком случае первый раз файл подкачки будет шифроваться достаточно долго.
• Display key backup notifications when user key is created or changed - включает или отключает уведомление пользователя, что его ключ шифрования был создан или изменён.

Чуть ниже мы можем позволить пользователям генерировать самоподписанные сертификаты EFS при недоступности существующего сертификата или недоступности централизованного Enterprise CA. В нашем случае использование самоподписанных сертификатов будет запрещено.

Примечание: часто замечаю, что администраторы сетей сильно пренебрегают вопросами планирования инфтраструктуры PKI и в Enterprise среде не разворачивают Certification Authority (хотя технических препятствий зачастую просто нету), а используют самоподписанные сертификаты. Я постоянно утверждаю, что самоподписанные сертификаты - вселенское зло, поскольку они неуправляемы. Во-первых, им никто (кроме самого издателя) не доверяет, отсутствует механизм управления настройками сертификатов и отсутствуют механизмы отзыва сертификата при компрометации ключа. Особенно часто такие сертификаты используют для веб-серверов или для OWA (Outlook Web Access).

И в самом низу указывается шаблон сертификатов, который будет использоваться для шифрования файлов. В моём случае это SM EFS. Если используются раздельные сертификаты для смарт-карт и EFS (версии 1), то следует оставить значение по умолчанию - Basic EFS.

Когда групповые политики будут настроены, то можно приступать к самому процессу шифрования. Когда пользователь захочет зашифровать файл, то он должен на файле или папке выбрать Properties -> Advanced -> Encrypt contents to secure data. И появится окно с предложением использовать сертификат смарт-каты для шифрования:

После чего потребуется выбрать сертификат из списка доступных сертификатов на смарт-карте и которые пригодны для шифрования:

Выбрав указанный сертификат потребуется ввести PIN от смарт-карты или токена. После этого файл или папка будут зашифрованы. Во время текущего сеанса, когда смарт-карта или токен установлены шифрованные файлы будут открываться без необходимости дополнительного ввода PIN. Но при изъятии смарт-карты и при установке обратно, либо при первой попытке открытия шифрованного файла после перелогона в трее появится значок, говорящий, что требуется авторизоваться на смарт-карте:

и потребует ввода PIN в смарт-карту.

Если ключ пользователя был утерян или временно недоступен, то назначенный групповой политикой агент восстановления EFS (как минимум должен иметь право Change extanded attributes на файл) проделывает точно такую же процедуру с вводом PIN от своего токена, где хранится ключ от EFS Recovery Agent и получает возможность расшифровать файл, как бы это сделал пользователь в штатном режиме. Но если токен был потерян, испорчен (т.е. угрозы похищения ключа нету), то не расшифровывать же все файлы пользователя? Можно расшифровывать, а можно и просто восстановить ключ пользователя из базы CA.

Для восстановления ключа шифрования из базы CA потребуется выполнить следующие шаги:

1. войти в систему под учётной записью, которая имеет право управления Certification Authority (обычно администратор), запустить консоль CMD и в ней выполнить следующую команду:
   certutil -getkey 6148fa9e000000000022 %path%\outblob
   где 6148fa9e000000000022 - серийный номер сертификата. Его можно посмотреть как в самом сертификате, так и в консоли Certifiaction Authority добавив в показ колонки Serial Number
   %path%\outblob - путь к выходному BLOB файлу. Вывод команды должен выглядеть примерно так:
   
   C:\Users\Administrator>certutil -getkey 6148fa9e000000000022 .\desktop\outblob
   Querying dc1.contoso.com\contoso-DC1-CA.....................

   "dc1.contoso.com\contoso-DC1-CA"
     Serial Number: 6148fa9e000000000022
     Subject: CN=Administrator, CN=Users, DC=contoso, DC=com
     UPN:administrator@contoso.com
     NotBefore: 12/18/2008 10:26 AM
     NotAfter: 12/18/2009 10:26 AM
     Template: SMEFS, SM EFS
     Version: 3
     Cert Hash(sha1): 3c 43 ff 2d 0e 99 35 c4 a1 59 43 47 bc b6 50 91 1c b7 f5 8a

   Recipient Info[0]:
   CMSG_KEY_TRANS_RECIPIENT(1)
   CERT_ID_ISSUER_SERIAL_NUMBER(1)
       Serial Number: 61312c8f000000000020
       Issuer: CN=contoso-DC1-CA, DC=contoso, DC=com
       Subject: CN=Recovery Agent, CN=Users, DC=contoso, DC=com
   CertUtil: -GetKey command completed successfully.
   

2. Вот этот BLOB файл нужно передать (например, по электронной почте или через сервис мгновенных сообщений) пользователю, который в CA является агентом восстановления ключей и чей сертификат находится во вкладке Recovery Agents.
3. получив этот файл агент восстановления должен установить смарт-карту или токен в ридер или USB, где находится закрытый ключ от KRA сертификата. Далее ему нужно запустить консоль CMD и в командной строке выполнить:
   certutil -recoverkey %path%\outblob user.pfx
   где %path%\outblob - путь к BLOB файлу, который был получен на шаге 2
   user.pfx - имя PKCS #12 файла, который будет содержать пару из открытого и закрытого ключа пользователя. Вот так примерно выглядит вывод команды:
   
   C:\Users\Recovery Agent>certutil -recoverkey outblob administrator.pfx
   dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
   dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
   ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
   HCCE_LOCAL_MACHINE
   CERT_CHAIN_POLICY_BASE
   -------- CERT_CHAIN_CONTEXT --------
   ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

   SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

   CertContext[0][0]: dwInfoStatus=10c dwErrorStatus=0
     Issuer: CN=contoso-DC1-CA, DC=contoso, DC=com
     NotBefore: 12/15/2008 1:26 AM
     NotAfter: 12/15/2013 1:36 AM
     Subject: CN=contoso-DC1-CA, DC=contoso, DC=com
     Serial: 6fc7646fe91510bc4631b9dcc08805e3
     c3 44 cb 46 1d d8 d8 cf dc 35 fb 7c 27 cb 7d a1 d4 64 47 2c
     Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
     Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
     Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

   Exclude leaf cert:
     da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
   Full chain:
     c3 44 cb 46 1d d8 d8 cf dc 35 fb 7c 27 cb 7d a1 d4 64 47 2c
   ------------------------------------
   Verified Issuance Policies: All
   Verified Application Policies: All

   Computed Hash: b3 57 bf 4b fe 18 16 bf 38 a4 17 00 17 27 4e b9 43 64 d4 14
   Decrypted PKCS7 Message Content

   User Certificate:
       Serial Number: 6148fa9e000000000022
       Issuer: CN=contoso-DC1-CA, DC=contoso, DC=com
       Subject: CN=Administrator, CN=Users, DC=contoso, DC=com
       Cert Hash(sha1): 3c 43 ff 2d 0e 99 35 c4 a1 59 43 47 bc b6 50 91 1c b7 f5 8a

   Enter new password:
   Confirm new password:
   CertUtil: -RecoverKey command completed successfully.
   

4. После успешного расшифрования BLOB файла агенту восстановления будет предложено ввести и подтвердить пароль для .pfx файла, который нужно будет потом ввести при импорте файла в Certificate Store.
5. Передать полученный файл пользователю любым доступным способом и сообщить пароль к нему. Не следует и файл и пароль передавать одним путём (например, через почту или Messenger).

Если же ключ был скомпрометирован (была утеряна смарт-карта и есть основания, что PIN известен 2-м и более лицам), то сертификат следует отозвать.

Вот мы и рассмотрели полностью (не скажу, что очень детально, но достаточно сносно для первой хау-ту :) ) вопрос имплементации новой возможности Windows Vista/Windows Server 2008 - хранение и использование ключей EFS на смарт-картах. Осталось рассмотреть только один вопрос - что будет, когда различные сертификаты истекут или будут отозваны, который я постараюсь (если всё получится) осветить в заключительной 4-й части.

В предыдущей части мы поговорили об основах работы шифрующей файловой системы EFS и основными трудностями, которые появляются при использовании EFS. И одной из важных задач становится защита ключей шифрования надёжным способом от взлома, но и обеспечить возможность восстановления данных при потере ключей шифрования и их доступность. Я уже отметил, что варианта у нас всего 2 - архивирование ключей на внешний контейнер (например, смарт-карта или USB диск) либо Key Archival, когда закрытые ключи дополнительно хранятся в базе Certification Authority. Причём, оба этих метода можно спокойно совместить. Но здесь Microsoft нас снова "радует" (что вполне ожидаемо) - Key Archival работает только при условии, что:

• Certification Authority (CA) работает под управлением Windows Server 2003/2008 Enterprise/Datecenter Edition.
• CA является Enterprise CA, а не StandAlone CA.
• криптопровайдер (CSP) поддерживает хранение закрытых ключей.

Механизм Key Archival работает следующим образом:

1. Клиент ищет доступный CA в базе AD и устанавливает с ним соединение. При соединении у CA запрашивается сертификат основанный на шаблоне CA Exchange (который используется только для этих целей).
2. Клиент удостоверяется, что сертификат валидный (имя в сертификате соответствует имени CA, срок годности сертификата ещё не истёк и т.д.) и проверяет списки CRL на предмет отзыва этого сертификата. А так же клиент проверяет, что сертификат подписан именно тем CA, с которым он сейчас работает и на имя этого CA. Это гарантирует, что CA сможет расшифровать полученный на последующих этапах шифрованный закрытый ключ.
3. Если с сертификатом всё в порядке, то клиент шифрует сгенерированный закрытый ключ открытым ключом сертификата CA Exchange. Если это клиент Windows Vista/Windows Server 2008, то клиент может шифровать свой ключ новыми алгоритмами CNG (Cryptography Next Generation) и использовать алгоритм AES для шифрования. По сути, Windows XP тоже поддерживает AES, но эта поддержка была внедрена только начиная с SP1 и здесь для Windows XP нету возможности использовать AES.
4. Далее клиент подготавливает полный запрос PKI для CA и этот запрос направляет в CA.
5. CA в свою очередь дешифрует полученный запрос и сверяет соответствие закрытого и открытого ключа в запросе.
6. Если соответствие подтверждено, то CA шифрует полученный закрытый ключ рандомным симметричным ключом с использованием 3DES или AES )(только для ОС Windows Vista и выше).
7. Затем этот симметричный ключ шифруется одним или несколькими открытыми ключами агентов восстановления, которые определены в свойствах CA и которые допущены к архивированию ключей и сохраняет всё это в специальном BLOB (Binary Large Object) формате в своей базе.

Исходя из этой процедуры нетрудно представить процесс восстановления:

1. администратор CA извлекает необходимый BLOB файл из базы CA.
2. Т.к. этот файл зашифрован открытым ключом агента (или агентов) восстановления, то файл передаётся любому допустимому агенту восстановления для дешифрации.
3. агент восстановления использует свой закрытый ключ для дешифрации файла и создаёт .pfx файл, попутно защищая его паролем.
4. .pfx файл затем передаётся конечному пользователю, который у себя на машине импортирует пару из открытого и закрытого ключа в контейнер Certificate Store.

Для начала нам потребуются агенты восстановления, которые будут уполномочены восстанавливать ключи из базы CA. Для этого в CA существует шаблон Key Recovery Agent. Из изменений, которые потребуются - на вкладке General поставить галочку для публикации сертификата в AD и в Security добавить нужных пользователей (но лучше будет поместить нужных агентов восстановления в отдельную группу и ей назначить право Read и Enroll). Затем следует в консоли CA добавить этот шаблон в список издаваемых сертификатов. Когда эта процедура будет завершена агенты восстановления должны подать заявку на выдачу сертификатов восстановления.

Примечание: здесь стоит отметить, что автоматическая выдача сертификатов работать не будет. Администратор CA должен вручную одобрить каждый запрос в секции Pending Requests. После того как запрос будет одобрен, изданный сертификат появится в секции Crtificate Enrollment Requests. Если агент восстановления для запроса использует Windows 2000/XP/2003, то запрос необходимо произвести запрос сертификата используя Certificates Web Enrollment pages из интернет-браузера.

Когда сертификат получен, то можно в CA разрешать Key Archival. Но если у вас есть смарт-карты, то лучше экспортировать пару ключей Key Recovery Agent на смарт-карту. В моём случае (используя Aladdin eToken Pro) потребовалось выполнить стандартную процедуру экспорта сертификата в PKCS #12 файл (.pfx) и используя ПО токена импортировать сертификат на токен. При экспорте ключей в файл не забудьте поставить галочку для удаления ключей из Certificate Store в случае успешного экспорта. После этой операции агент восстановления перестаёт быть зависимым к своему профилю и будет неуязвим к атакам на профиль.

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

В этом окне нужно переставить переключатель в Archive the key и кнопкой Add добавить сертификаты тех агентов восстановления, которые будут уполномочены для восстановления ключей. Именно этими сертификатами CA будет шифровать ключи пользователей.

Следующим этапом будет изменение шаблонов для поддержки Key Archival. Шаблоны версии 1 не поддерживают данную функцию, а только V2 и V3, а эти шаблоны поддерживаются только в Windows Server Enterprise и Datacenter редакциях. Конкретно для EFS придётся создать новый шаблон версии 2 или 3:

Я его назвал SM EFS (Smart Card EFS). Изображение может отличаться от вашего случая. Я предполагаю, что у меня все CA будут работать под управлением Windows Server 2008. Для 2003 картинка может отличаться, но суть останется та же. Далее, нас заинтересует вкладка Request Handling:

Здесь нужно поставить галочку напротив Archive subject's encryption private key. Галочка ниже (Use advanced Symmetric algorithm to send key to the CA) используется только для клиентов Windows Vista и выше. Если этим шаблоном будут пользоваться более ранние клиенты, то её выставлить нельзя! И последнее, что явно потребуется:

драйвер токена Alddin eToken Pro для хранения сертификатов EFS на токене требует, чтобы на токене так же был и логонный сертификат, иначе он впадает в дикий ступор :) При использовании Windows Server Standard редакции потребуется 2 сертификата - отдельно на основе шаблона Smart Card Logon и EFS Basic. Т.е. не обязательно, чтобы один сертификат содержал все функции. Т.к. у меня CA работает под управлением Enterprise то я создал один шаблон и в Extensions добавил необходимые политики действия, а именно - добавил Smart Card Logon. Тогда я могу с использованием одного сертификата и аутентифицироваться в домене и шифровать файлы. Официальная документация требует, чтобы в списке CSP провайдеров был указан провайдер смарт-карты (токена), но в моём случае это не обязательно, поскольку при издании сертификата драйвер сам предлагает экспортировать сертификат на токен. Шаблон можно сохранять и назначить его для издания сертификатов:

Certificate Templates -> New -> Certificate Template to issue -> в списке выбрать SM EFS

И последняя часть, которая нам потребуется - указание агента восстановления для EFS.

Примечание: мы выше уже создавали агента восстановления, но у нас будет 2 различных агента восстановления - отдельно для EFS, который будет задан в GPO и агент восстановления ключей из базы CA. Это 2 совершенно разные роли и следует чётко различать назначение каждого агента.

На практике по умолчанию агентом восстановления становится первый администратор первого контроллера домена в лесу Active Directory. В целях безопасности не следует его оставлять как есть. Для этого я создал новую учётную запись с именем Recovery Agent и добавил его в группу EFS Recovery. Более ни в каких группах пользователь не состоит. Чтобы сделать его агентом восстановления нужно сначала разрешить групе EFS Recovery запрашивать сертификат на основе шаблона EFS Recovery Agent:

Я просто добавил право Read и Enroll для группы EFS Recovery. Затем пользователь, член EFS Recovery должен залогониться, запустить оснастку certmgr.msc и выполнить запрос сертификата:

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

и после нажатия на Ok потребуется ввести PIN токена:

Теперь этот сертификат хранится только на токене. В установках по умолчанию для eToken Pro при извлечении токена из USB очищается весь контейнер Personal в Certificate Store. Поэтому когда агент восстановления извлекает токен, то его профиль больше не представляет никакой ценности в плане закрытых ключей, которыми можно восстанавливать EFS файлы. Как известно, при установке смарт-карты или токена в ридер или USB, то происходит копирование ключей с токена в хранилище Certificate Store. Т.к. по умолчанию сертификат шаблона EFS Recovery Agent не публикуется в AD, поэтому агент восстановления должен экспортировать .cer (сертификат с открытым ключом) в папку вручную из программного хранилища. Именно эти сертификаты будут использоваться для шифрования ключей EFS и последующего сохранения в поле DRF.

Далее администратор должен открыть объект групповой политики нужного контейнера и перейти в секцию Encrypting File System, как это показано на рисунке:

Я уже удалил сертификат администратора по умолчанию и добавил сертификат нового агента восстановления EFS, который был сохранён самим агентом в .cer файл.

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

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

• Key Archival - архивирование всех закрытых ключей пользователей в базе CA, что обеспечивает возможность восстановления ключей шифрования с минимальными затратами по восстановлению нормальной работы шифрованных файлов.
• EFS Recovery Agent - в контексте обсуждаемого вопроса применили агента восстановления EFS файлов без необходимости восстановления ключей из базы CA. Тем более Key Archival в ряде случаев будет невозможен для применения.

Так же посмотрели почти пошаговый процесс реализации обоих механизмов и показали как агенты восстановления могут защищать свои ключи восстановления сохранив их на внешние криптоконтейнеры - смарт-карты или токены. Мы подготовили базу для восстановления файлов в случае "а если ...". План мероприятий по восстановлению данных должен быть применён и реализован до эксплуатации EFS и цифровых сертификтов в целом. В следующей части я покажу настройки групповых политик для хранения EFS сертификатов пользователей на смарт-картах на примере использования токена eToken Pro, а так же (если объём следующей части позволит) покажу действие агентов восстановления в случае "а если ...".