Posts on this page:
Остальные материалы цикла:
В предыдущей части мы поговорили о процессе и методах ассоциации сертификата с учётной записью пользователя в Active Directory. Сегодня мы поговорим уже про сами сертификаты, каким требованиям они должны удовлетворять и всё такое. Я пообещал, что в этой части мы приобщимся к практике. Но я передумал и мы снова займёмся теорией :-)
Поскольку у нас разговор идёт об аутентификации при помощи цифровых сертификатов, они нам обязательно потребуются. Для различных сетевых протоколов и методов аутентификации нам потребуется различный набор сертификатов. Итак:
Остальные материалы цикла:
Disclaimer: Эта статья содержит сведения о правке реестра. Перед внесением изменений в системный реестр рекомендуется изучить процедуру его восстановления. Для получения дополнительных сведений о восстановлении реестра см. разделы «Восстановление реестра» или «Восстановление раздела реестра» справочной системы редактора реестра.
В предыдущей части мы поговорили о процессе аутентификации по сертификату (или смарт-картой), но не поговорили о том, как сертификат связывается (ассоциируется) с учётной записью пользователя в Active Directory. Процесс ассоциации сертификата с учётной записью называется certificate mapping. В мире Active Directory существует 2 вида маппинга:
Сегодня хочу поговорить и обозначить неочевидные моменты, которые связаны с энроллментом сертификатов от имени другого пользователя. В определённых сценариях администратору (или агенту подачи заявок на сертификаты) требуется запрашивать сертификаты от имени другого пользователя. Как пример такого сценария — распространение смарт-карт на предприятии. В таком случае в организации выделяется специальный человек, который будет этим заниматься. Этот человек будет называться Enrollment Agent и в его задачи будет входить:
Для решения этой задачи Windows CA (будь то Standalone или Enterprise CA и CA может работать под управлением любой версии Windows Server) предлагает возможность реализации данной задачи через использование Enroll On Behalf Of (EOBO). Суть метода заключается в том, что такой агент получает для себя специальный сертификат на основе шаблона Enrollment 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. В качестве эпилога скажу, что рекомендуется использовать комбинированные шаблоны для агентов восстановления. Например, если агент восстановления будет хранить свои закрытые ключи от EFS и Key Archival на смарт-карте, то выгодней будет использовать шаблон Smart Card Logon и в его EKU добавить уже необходимые области применения (например, Key Archival), что упрощает процедуру эксплуатации таких сертификатов в будущем. Не нужно будет теперь заботиться, что отдельные сертификаты будут истекать в разное время и при компрометации смарт-карты придётся отзывать несколько сертификатов - достаточно будет отозвать один сертификат. То же самое касается и пользователей, которые используют смарт-карты. Достаточно в Smart Card Logon EKU добавить Basic EFS и всё будет хорошо. Почти хорошо, если у вас есть Enterprise или Datacenter редакция Windows Server :)
Вопросы обновления сертификатов и прочие lifecycle эксплуатации (например, введение Certificate Autoenrollment и прочее) смарт-карт и EFS уже выходят за рамки моей статьи, поэтому вам придётся этот материал изучать самостоятельно. И на последок я подобрал несколько полезных ссылок, которые помогут с освоением данного материала:
В предыдущих частях мы рассмотрели принципы работы EFS, изучили основные вопросы безопасности и доступности ключей, а так же показали как создавать агентов восстановления файлов EFS и агентов восстановления ключей:
Когда у нас все агенты восстановления подготовлены и подготовлены шаблоны EFS + Smart Card Logon, то необходимо заранее подготовить смарт-карты и выпустить для них сертификаты. Для этого можно воспользоваться консолью MMC - certmgr.msc и выполнить запрос сертификата:
пользователь выполнил запрос сертификата и драйвер предложил сразу положить сертификат на токен. Данную процедуру необходимо проделать для всех пользователей, которые будут шифровать файлы сертификатами и хранить их на смарт-картах. После этого можно приступать к настройке групповой политики:
В Public Key Policies нужно выбрать свойства Encrypting File System и получим такое окно. Здесь у нас появилось много новых настроек, которых раньше не было. Вот скрин этого же окна в Windows Server 2003:
тут мы можем только или разрешить или запретить использование EFS. Пробежимся по настройкам новой консоли:
Чуть ниже мы можем позволить пользователям генерировать самоподписанные сертификаты 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 потребуется выполнить следующие шаги:
certutil -getkey 6148fa9e000000000022 %path%\outblob
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.
certutil -recoverkey %path%\outblob user.pfx
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.
Если же ключ был скомпрометирован (была утеряна смарт-карта и есть основания, что PIN известен 2-м и более лицам), то сертификат следует отозвать.
Вот мы и рассмотрели полностью (не скажу, что очень детально, но достаточно сносно для первой хау-ту :) ) вопрос имплементации новой возможности Windows Vista/Windows Server 2008 - хранение и использование ключей EFS на смарт-картах. Осталось рассмотреть только один вопрос - что будет, когда различные сертификаты истекут или будут отозваны, который я постараюсь (если всё получится) осветить в заключительной 4-й части.