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

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

В предыдущей части мы поговорили о процессе и методах ассоциации сертификата с учётной записью пользователя в Active Directory. Сегодня мы поговорим уже про сами сертификаты, каким требованиям они должны удовлетворять и всё такое. Я пообещал, что в этой части мы приобщимся к практике. Но я передумал и мы снова займёмся теорией

Необходимый набор сертификатов

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

Интерактивный логон при помощи смарт-карты

Для поддержки интерактивного логона при помощи смарт-карты, нам потребуется как минимум 2 вида сертификатов: клиентский сертификат, который записан на смарт-карте и сертификат контроллера домена. Каким условиям должен удовлетворять клиентский сертификат?

• Должен быть выдан доверенным (как клиентом, так и контроллером домена) центром сертификации;
• Должен быть действителен по времени;
• Поле Subject — не имеет значения. Может быть пустым;
• Расширение Enhanced Key Usage (EKU) должно содержать Smart Card Logon (1.3.6.1.4.1.311.20.2.2) и/или Client Authentication (1.3.6.1.5.5.7.3.2). Smart Card Logon обязателен для Windows XP и Windows Server 2003. В Windows Vista для логона смарт-картой можно использовать только Client Authentication. Но я буду советовать использовать оба;
• Расширение Key Usage должно содержать Digital Signature (0x80);
• Расширение Subject Alternative Name (SAN) должно содержать User Principal Name (UPN) пользователя. Если для каких-то целей этих UPN'ов прописано несколько, UPN для логона должен быть первым в списке.

Примечание: хоть мы и говорили, что расширение SAN в клиентском сертификате вовсе не обязательно и можно использовать различные формы explicit mapping, вы должны при любой возможности использовать implicit certifiate mapping по UPN и использовать explicit только когда другого выхода нет.

Windows CA предлагает нам 2 шаблона по умолчанию, которые годятся для этих целей: Smart Card Logon и Smart Card User. Единственное отличие этих шаблонов — Smart Card User содержит ещё EKU Secure Email (1.3.6.1.5.5.7.3.4). Вам следует использовать только шаблон Smart Card Logon или производный из него. Дело в том, что не рекомендуется объединять сертификаты, которые используются для логона (или цифровой подписи) с сертификатами, которые используются для шифровния.

Сертификат контроллера домена (KDC) должен удовлетворять следующим требованиям:

• Должен быть выдан доверенным (как клиентом, так и контроллером домена) центром сертификации;
• Должен быть действителен по времени;
• Поле Subject — не имеет значения;
• Расширение Enhanced Key Usage (EKU) должно содержать как минимум Server Authentication (1.3.6.1.5.5.7.3.1) и Client Authentication (1.3.6.1.5.5.7.3.2). Желательно в EKU включить Smart Card Logon (1.3.6.1.4.1.311.20.2.2), чтобы обозначить, что данный сертификат будет использоваться для аутентификации клиента по смарт-карте. Для того, чтобы обеспечить поддержку строгой проверки сертификата для KDC, в EKU необходимо включить KDC Authentication (1.3.6.1.5.2.3.5);
• Расширение Key Usage должно содержать Digital Signature и Key Encipherment (0xa0);
• Расширение Subject Alternative Name (SAN) должно содержать как минимум FQDN контроллера домена. А в идеале, ещё и FQDN и NetBIOS имена рассматриваемого домена.

Windows CA предлагает нам 3 шаблона по умолчанию, которые годятся для этих целей: Domain Controller, Domain Controller Authentication и Kerberos Authentication. Если у вас в домене есть контроллеры под управлением Windows Server 2003, следует использовать Domain Controller Authentication. Если у вас в домене все контроллеры под управлением Windows Server 2008 и выше, следует использовать шаблон Kerberos Authentication.

Примечание: для доменов с контроллерами на основе Windows Server 2003 можно использовать и шаблон Kerberos Authentication. Но контроллеры не извлекут таких профитов, как strong KDC validation. Так же, возможно появление следующей ошибки: Automatic certificate enrollment for local system detected the DNS name in the Kerberos Authentication certificate does not match the DNS name of the local computer. A new enrollment for one Kerberos Authentication certificate will be performed in 24 hours. Это известная проблема, поэтому для таких доменов лучше использовать шаблон Domain Controller Authentication.

В чём заключается суть аутентификации KDC? Если доменная машина выполняет аутентификацию с использованием PKINIT, клиентский компьютер убеждается, что удалённый хост не только имеет серверный сертификат и его имя соответствует имени в сертификате, но и является именно контроллером домена или сервером KDC, который является авторитарным для рассматриваемого домена. В процессе аутентификации, клиентский компьютер не имеет нотариально заверенногодостоверного списка контроллеров в домене. И наличие EKU = KDC Authentication и FQDN + NetBIOS имён домена в расширении SAN гарантированно идентифицирует хост как контроллер для домена, указанного в расширении SAN.

Логон на веб-странице

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

• Должен быть выдан доверенным (клиентом и сервером) центром сертификации;
• Должен быть действителен по времени;
• Поле Subject — имя сервера, которое клиент вводит в адресной строке веб-браузера;
• Расширение Enhanced Key Usage (EKU) должно содержать Server Authentication (1.3.6.1.5.5.7.3.1);
• Расширение Key Usage должно содержать Digital Signature и Key Encipherment (0xa0);
• Опционально, расширение Subject Alternative Name (SAN) может содержать дополнительные имена, которые могут использоваться для доступа к серверу. Если расширение SAN представлено в сертификате и поле Subject не пустое, SAN должен включать себя и имя из поля Subject. Подробнее здесь: Как правильно задавать имя сертификата при использовании расширения Subject Alternative Name (SAN).

Windows CA предлагает по умолчанию один шаблон, который годится для этой цели: Web Server.

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

• Должен быть выдан доверенным (клиентом и сервером) центром сертификации;
• Должен быть действителен по времени;
• Поле Subject — не имеет значения. Может быть пустым;
• Расширение Enhanced Key Usage (EKU) должно содержать Client Authentication (1.3.6.1.5.5.7.3.2);
• Расширение Key Usage должно содержать Digital Signature (0x80);
• Расширение Subject Alternative Name (SAN) должно содержать User Principal Name (UPN) пользователя. Если для каких-то целей этих UPN'ов прописано несколько, UPN для логона должен быть первым в списке.

Windows CA предлагает нам по умолчанию 2 шаблона, которые отвечают предъявленным требованиям: Authenticated Session и User. Вам следует использовать шаблон Authenticated Session или производный от него для создания клиентских сертификатов. Шаблон User дополнительно содержит EKU для Secure Email и EFS. Как я уже говорил, не следует комбинировать в одном сертификате EKU для цифровых подписей или логона с EKU для шифрования.

Логон на сервере VPN

В зависимости от типа VPN (L2TP, SSTP) вам потребуется различный набор сертификатов (для PPTP отдельный серверный сертификат не требуется). Клиентский сертификат для любых видов VPN должен отвечать требованиям, описанным в параграфе «Интерактивный логон при помощи смарт-карты» (если используется смарт-карта) или «Логон на веб-странице» (если не используется смарт-карта). Далее, вам потребуется сертификат для RADIUS сервера. Этот сертификат должен быть установлен на RADIUS сервере или на самом сервере VPN, если используется Integrated Authentication и который отвечает следующим требованиям:

• Должен быть выдан доверенным (клиентом и VPN сервером) центром сертификации;
• Должен быть действителен по времени;
• Поле Subject — FQDN сервера;
• Расширение Enhanced Key Usage (EKU) должно содержать Server Authentication (1.3.6.1.5.5.7.3.1) и Client Authentication (1.3.6.1.5.5.7.3.2);
• Расширение Key Usage должно содержать Digital Signature и Key Encipherment (0xa0);
• Расширение Subject Alternative Name (SAN) должно содержать FQDN сервера.

Windows CA предлагает по умолчанию шаблон RAS and IAS Servers, который удовлетворяет всем требованиям для RADIUS сервера.

Для L2TP вам ещё потребуются компьютерные сертификаты для обоюдной аутентификации узлов и которые отвечают следующим требованиям:

• Должен быть выдан доверенным (клиентом и сервером) центром сертификации. Причём, цепочки сертификатов обоих узлов должны заканчиваться одним и тем же сертификатом корневого CA;
• Должен быть действителен по времени;
• Поле Subject — имя сервера, которое клиент вводит при подключении к VPN серверу;
• Расширение Enhanced Key Usage (EKU) должно содержать IP security IKE intermediate (1.3.6.1.5.5.8.2.2);
• Расширение Key Usage должно содержать Digital Signature и Key Encipherment (0xa0);
• Опционально, расширение Subject Alternative Name (SAN) может содержать дополнительные имена, которые могут использоваться для доступа к серверу. Если расширение SAN представлено в сертификате и поле Subject не пустое, SAN должен включать себя и имя из поля Subject. Подробнее здесь: Как правильно задавать имя сертификата при использовании расширения Subject Alternative Name (SAN).

Windows CA по умолчанию предлагает два шаблона, которые годятся для аутентификации узлов в L2TP: IPsec и IPsec (Offline). Если один из узлов не является членом одного и того же леса Active Diretory, следует использовать IPsec (Offline), потому что этот шаблон позволяет указывать поле Subject и расширение Subject Alternative Names в запросе. Шаблон IPsec автоматически строит эту информацию из Active Directory.

Для SSTP VPN вам потребуется сертификат SSL, который отвечает тем же самым требованиям, что и сертификат SSL для веб-сервера (см. параграф «Логон на сервере VPN»).

Логон в 802.11x сетях (Wireless)

Для получения доступа в беспроводную 802.11x сеть, точка доступа (WAP) должна быть настроена на использование RADIUS сервера для аутентификации и авторизации клиента. RADIUS сервер должен иметь сертификат, как описано в параграфе «Логон на сервере VPN». Требования к пользовательскому сертификату описаны в параграфе «Интерактивный логон при помощи смарт-карты» (если используется смарт-карта) или в параграфе «Логон на веб-странице» (если используется сертификат, установленный в пользовательское хранилище сертификатов).

Сертификаты центров сертификаций

При использовании сертификатов для аутентификации пользователей вам необходимо, что сертификат центра сертификации, который выпускает логонные сертификаты для пользователей и контролллеров домена, опубликованы в хранилище NTAuthCertificates в Active Directory. Если вы используете свой собственный Windows Enterprise CA, никаких дополнительных действий не требуется. Если вы используете сторонний CA (внешний, или CA на базе линупса), сертификат CA необходимо вручную опубликовать в указанное храналище. Например, можно использовать certutil.exe:

certutil –dspublish –f CAcertfile.crt NTAuthCA

Альтернативно вы можете это сделать через оснастку PKI Health Tool:

1. Войдите в систему с правами Enterprise Admins;
2. Запустите оснастку PKI Helath Tool (Start –> Run... –> pkiview.msc);
3. Выделите корневой узел (Enterprise PKI) и в контекстном меню выберите Manage AD Containers. Перейдите во вкладку NTAuthCertificates. Используйте кнопку Add для того, чтобы добавить туда сертификат издающего CA.

Эпилог

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

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

• Что-нибудь почитайте, не сидите без дела

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 хранится в атрибуте userPrincipalName. Если такой 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

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

Общая схема аутентификации по сертификатам

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

1. Пользователь запрашивает доступ к некоторой сетевой службе;
2. По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
3. Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
4. Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
5. Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
6. Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).

Я посчитал нужным немного развернуть последний пункт, чтобы вы понимали общее устройство этого канала (поскольку, у людей есть некоторые заблуждения на этот счёт):

1. Клиент запрашивает установку безопасного канала;
2. Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
3. Клиент посылает на сервер свой список протоколов симметричного шифрования;
4. Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
5. Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
6. После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).

Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.

Логон смарт-картой или PKINIT

Интерактивная аутентификация в Active Directory по сертификату не является самостоятельным механизмом. Как и всегда, основной протокол аутентификации в домене — Kerberos. Чтобы обеспечить взаимодействие между аутентификацией по смарт-карте и Керберосом, применяется нехитрый протокол PKINIT. PKINIT, в свою очередь, является лишь надстройкой над керберосом (или расширением протокола). Вот как он примерно работает:

Примечание: если у пользователя уже есть соответствующий сервисный тикет (TGS), выполняются только шаги 5 и 6.

1. Пользователь вводит PIN от смарт-карты и посылает запрос AS-REQ на контроллер домена (он же Key Distribution Center — KDC). Этот запрос содержит преаутентификационные данные PA_PK_AS_REQ, которые, в свою очередь, содержат логонный сертификат и подписанная временная метка и опциональные атрибуты. В качестве опциональных атрибутов, клиент посылает список поддерживаемых алгоритмов, корневых CA, параметры Diffie-Hellman и т.д. Более детально структуру запроса (а там есть достаточно занятных вещей) можно найти в RFC 4556  §3.2.1 (пункт 5 на странице 12). В связи с этим (например, передача списка доверенных корневых CA от клиента на сервер) время логона смарт-картой будет значительно медленней, чем при связке логин/пароль. Плюс расходы на криптографические операции.
2. Сервер KDC проверяет запрос и пробует ассоциировать полученный сертификат с учётной записью пользователя. Если сопоставление сертификата с учётной записью произошло успешно, KDC формирует ответ AS-REP, включая в него Ticket-Granting Ticket (TGT) и прочую необходимую информацию. Ответ подписывается сертификатом самого KDC (именно поэтому, при использовании смарт-карты для логона, сервер KDC должен иметь свой собственный сертификат (о нём мы поговорим в следующих статьях).
3. Клиент проверяет этот ответ и проверяет подпись (вместе с сертификатом KDC). Если с ответом и сертификатом всё хорошо, клиент, на основе имеющегося TGT, генерирует Ticket Granting Service запрос — TGS-REQ для доступа к конкретной службе и отправляет его на KDC.
4. KDC проверяет запрос TGS-REQ и в случае положительного вердикта формирует ответ Ticket-Granting Service (TGS-REP), включая в него всю необходимую информацию для интерактивного логона, включая все необходимые SID'ы и учётные данные для аутентификации при помощи NTLM.
5. Клиент генерирует специальный токен GSS-API (RFC 1964) и в него заворачивает полученный TGS-REP. На выходе получается запрос AP-REQ, который направляется уже к конкретной службе, куда нужен доступ.
6. Здесь, собственно, происходит уже авторизация клиента и между ними (клиентом и серверной службой) начинается свой собственный диалог. Возможно, о бабах

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

На последок, особо пытливым умам — увлекательное чтиво:

• MS-PKCA
• MS-PAC
• MS-KILE
• RFC 4556
• RFC 1964

Данная серия постов заказана и оплачена благотворительным фондом винниклОлега Крылова и всех-всех-всех.

Исходя из названия серии, мы, очевидно, будем говорить про цифровые сертификаты и аутентификацию. Для начала предлагаю классический бэкграунд аутентификации другими средствами (паролями же!).

Password-based authentication background

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

• Пароли очень короткие (5-8 символов);

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

• Пароли забываются;

Действительно пароль вида $gf)a90sfLq*wrF4 запомнить нелегко. С очень высокой долей вероятности, что пользователь после удачных выходных вряд ли в понедельник утром вспомнит его — звонок в тех.поддержку. Пока решается его вопрос с паролем, пользователь простаивает и ничего не делает, просто любуется экраном логона. Но можно выйти из ситуации и обойтись без звонка в тех.поддержку:

• Пароли записываются на бумажки и приклеиваются на монитор;

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

• Один и тот же пароль используется для множества сетевых ресурсов одновременно;

Нередко, когда пользователь зарегистрирован в десятке (а то и в десятках) мест, где используется один и тот же пароль. Потерял 1 пароль — потерял доступ всюду. Лично я не в состоянии удержать в голове все пароли от всех (да хотя бы топ-10) сайтов, где я бываю. Признаюсь, что у меня есть секретный текстовый файл, где я записываю все свои пароли и на сегодняшний день он имеет размер в 5кб. Я знаю, что это несекурно, но пока ничего лучше не придумал (если есть идеи, можете их озвучить в комментариях).

Об этом можно говорить долго и упорно, но смысла это не добавит, поэтому переходим дальше.

Introduction to certificate-based authentication

Цифровые сертификаты — это альтернативная форма идентификации пользователя. Здесь и далее я буду говорить про цифровые сертификаты в контексте Active Directory.

Цифровой сертификат — это документ, защищённый цифровой подписью (т.е. защищён от подделки), который содержит необходимую информацию о его владельце, которая позволяет уникально идентифицировать пользователя. Эта информация включает как минимум логонную информацию (адрес учётной записи в каталоге Active Directory или его User Principal Name — UPN). Поскольку цифровые сертификаты это часть инфраструктуры открытого ключа, они обязательно содержат открытый ключ.

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

• Зная открытый ключ, невозможно вычислить закрытый ключ и наоборот.
• Данные зашифрованные одним ключом (например, открытым) могут быть расшифрованны только вторым ассоциированным (например. закрытым) ключом.
• Если мы шифруем данные открытым ключом — это шифрование и данные прочитать может только владелец закрытого ключа.
• Если мы шифруем данные закрытым ключом — это цифровая подпись и данные прочитать может любой пользователь, но создать конкретную цифровую подпись может только владелец закрытого ключа.

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

Смарт-карта это устройство со встроенным микрочипом, который хранит цифровой сертификат и закрытый ключ от него. Микрочип устроен так, что извлечь закрытый ключ из него не представляется возможным, а получить доступ можно только путём ввода отдельного пароля, называемым PIN (Personal Identification Number). Ряд смарт-карт оборудуются дополнительным элементом физической защиты, при разрушении которой уничтожаются и хранимые на них ключи и сертификаты. Это защитная мера, которая предотвращает доступ к ключам и защищённой этими ключами информации при попытке физического доступа к микрочипу, что и есть главное условие безопасности.

Где можно применять аутентификацию пользователей по сертификатам?

В Microsoft Windows мы можем применять пользовательские сертификаты для:

• Интерактивного логона в домен (требуется смарт-карта);
• Логона на сервер терминалов при помощи Remote Desktop (требуется смарт-карта);
• Аутентификации на веб-странице;
• Аутентификации в VPN;
• Аутентификации в 802.11х сетях (они же wireless).
• Аутентификации в ActiveSync;
• и ещё по мелочам.

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

Сегодня хочу поговорить про использование алиасов в скриптах и дать несколько практических советов при сборке текстов из фрагментов.

Алиасы

Семантика языка PowerShell подразумевает использование унифицированного синтаксиса, где название каждой команды явно говорит о том, что она делает. Например, Get-Process. Совершенно очевидно, что эта команда должна делать. Но, порой, эти команды бывают очень длинными и набирать их постоянно в консоли бывает не очень удобно. Например, самый топовый — Get-ChildItem. Это даже не самая длинная команда, просто наиболее часто используемая. Или Foreach-Object. Даже автозавершение команд не всегда спасает ситуацию. Для этого были придуманы алиасы (короткие ссылки на команды), которые очень выгодно использовать в консоли. Так же у команд есть и очень длинные параметры. Например, всякие –InputObject, –Include, –ErrorAction и т.д. PowerShell позволяет сокращать параметры первыми буквами до тех пор, пока эти буквы не будут явно указывать на конкретное название. Например, у команды Get-ChildItem параметр –Include может быть сокращён до –I, а –Exclude до –Ex. Но многие скриптописатели пишут скрипты (и выкладывают их даже где-то) с использованием этих самых алиасов и коротких обозначений параметров.

Хорошо это или плохо? Ответ очевидный — за такое надо бить больно сапогами и по лицу. Использование алиасов приводит нас обратно к одной из проблем оболочки cmd — сразу не скажешь, что делает та или иная команда. Пользователь без соответствующей подготовки вряд ли сходу скажет, что делает команда regsvr32 или что делает ключ /i этой команды. Или вот 2 примера:

gps iex* | spps -f
ls .\ -r -fo | %{cp $_.fullname -des e:\ -ea 0}

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

Get-Process iex* | Stop-Process -Force
Get-ChildItem .\ -Recurse -Force | ForEach-Object {Copy-Item $_.fullname -Destination e:\ -ErrorAction SilentlyContinue}

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

Пользователи PowerGUI Script Editor могут воспользовться адд-оном, написанным одним пошикмвп Шейем Леви (Shay Levy) — Expand Alias, который автоматически разворачивает алиасы в их полное значение.

Кавычки и here strings

PowerShell очень часто используют не только для созидательных целей, но и для аналитических тоже — сбор каких-то данных. Или какой-то скрипт выполняющий сложные операции и попутно пишущий что-то в лог-файл.

На этой неделе мне прислали скрипт, который на выходе делает красивую HTML'ку с красивыми стилями и всё такое. И вот какое чудо (не единственное) я увидел:

$a = "<title>Телефонный справочник ООО `"Имя компании`"</title>"

# стили и заголовок окна
$a = $a + "<style>"
$a = $a + "BODY{background-color:#FFF;color:#000;font-family: tahoma; font-size: 8pt; }"
$a = $a + "TABLE{border-width: 1px;border-style: solid;border-color: #BFBFBF;border-collapse: collapse; width: 100%}"
$a = $a + "TH{border-width: 1px;padding: 0px;border-style: solid;border-color: #BFBFBF;background-color:#4E7DD1; color: #FFF}"
$a = $a + "TD{border-width: 1px;padding: 0px;border-style: solid;border-color: #BFBFBF;background-color:#FFF}"
$a = $a + "col#c1 { width: 10%;} col#c2{ width: 10%; }col#c3 {width: 10%;}col#c4 { width: 3%;}"
$a = $a + "col#c5 { width: 10%;} col#c6{ width: 11%; }col#c7 {width: 10%;}col#c8 { width: 25%;}"
$a = $a + "</style>"

Ах, какая красота. Уже в первой строке человек использует бэктик (`) для эскейпа двойных кавычек внутри текстовой строки. Зачем? Я не знаю. Ведь достаточно было заменить наружные кавычки на одинарные и всё стало бы прекрасно:

$a = '<title>Телефонный справочник ООО "Имя компании"</title>'

А какую функцию несёт переменная $a? Мы уже говорили, что название переменной должно отражать её сущность. Это сейчас понятно, что там, а чуть ниже в коде, где она будет использоваться — мы уже забудем, что там было.

Ок, идём дальше. А дальше он добавляет к этой строке другой код HTML (естественно, в виде текста). Я давно замечал, что люди или не знают или не хотят использовать here strings. Ведь можно сделать вот так:

$html = @'
<title>Телефонный справочник ООО "Имя компании"</title>
<style>
BODY{background-color:#FFF;color:#000;font-family: tahoma; font-size: 8pt; }
TABLE{border-width: 1px;border-style: solid;border-color: #BFBFBF;border-collapse: collapse; width: 100%}
TH{border-width: 1px;padding: 0px;border-style: solid;border-color: #BFBFBF;background-color:#4E7DD1; color: #FFF}
TD{border-width: 1px;padding: 0px;border-style: solid;border-color: #BFBFBF;background-color:#FFF}
col#c1 { width: 10%;} col#c2{ width: 10%; }col#c3 {width: 10%;}col#c4 { width: 3%;}
col#c5 { width: 10%;} col#c6{ width: 11%; }col#c7 {width: 10%;}col#c8 { width: 25%;}
</style>
'@

Если вам надо в коде разместить набор строк, заключайте их в here strings (с двойными кавычками, если внутри надо экспандить переменные или с одинарными, если это не надо).

Так же, в этом скрипте увидел ещё вот такую прелесть:

$menu = $menu + "<a href=`"#"+$head+"`">"+$head+"</a><br>"

А если мы снова упакуем это в here strings?

$menu += @"
<a href="#$head">$head</a><br>
"@

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

Вот ещё прелесть:

$PatternTo = "<col id=""c1""/><col id=""c2""/><col id=""c3""/><col id=""c4""/><col id=""c5""/><col id=""c6""/><col id=""c7""/><col id=""c8""/>"

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

$PatternTo = '<col id="c1"/><col id="c2"/><col id="c3"/><col id="c4"/><col id="c5"/><col id="c6"/><col id="c7"/><col id="c8"/>'

эффект тот же самый и минус 16 кавычек.

Отсюда следует вот такое правило: учитесь правильно использовать кавычки. Избегайте эскейпинг кавычек — в 99% случаев это не нужно совсем. Вместо этого надо предусмотреть использование одинарных кавычек или применять here strings, если выхода нет.

$menu= "</style>" + "<TABLE Style=`"border-color:#FFF; border-collapse: separate`"><tr><td Style=`"border-color:#FFF`">" +$menu + "</td></tr></TABLE>"

Например, здесь мы не можем обойтись просто одинарными кавычками, потому что внутри строки надо вставить значение переменной. Значит, нам поможет here strings:

$menu= @"
</style><TABLE Style="border-color:#FFF; border-collapse: separate"><tr><td Style="border-color:#FFF">$menu</td></tr></TABLE>
"@

Работа с большим объёмом текста

В PowerShell при работе с большим объёмом текста (уже начиная от мегабайта) наблюдается ощутимая деградация производительности. Например, ваш код на выходе генерирует большой XML или HTML код, следует избегать операторы конкатенации ($a = $a + "some text" или $a += "some text"). Вместо этого следует использовать StringBuilder:

# создаём объект StringBuilder
$SB = New-Object Text.StringBuilder
# добавляем фрагменты текста в коде
<...>
[void]$SB.Append("some string")
<...>
# выгружаем итоговый текст в файл:
Set-Content -Path $path -Value $SB.ToString()

В качестве примера можете посмотреть мой код в PSFCIV, который заворачивает объекты с конвейера в XML:

function _toxml_ {
# в Begin создаём заголовок XML и открывающийся тег <FCIV>
    Begin {
        $xmlstring = New-Object System.Text.StringBuilder
        [void]$xmlstring.Append('<?xml version="1.0" ?><FCIV>')
    }
# в Process будут по одному поступать объекты, которые описывают файл.
    Process {
# для каждого файла у нас будет один тег <FILE_ENTRY>
        [void]$xmlstring.Append(" <FILE_ENTRY>`n")
# чтобы вручную не создавать и не заполнять вложенные теги мы простым foreach
# перечисляем теги, какие у нас будут в XML и за счёт переменных автоматом
# создаём их в XML и заполняем их данными. Для этого свойства объектов должны
# называться так же, как и теги.
        foreach ($child in ("name", "Size", "TimeStamp", "SHA1", "MD5")) {
            [void]$xmlstring.Append(" <$child>$($_.$child)</$child>`n")
        }
# когда текущий объект обработан, закрываем тег и ждём следующий объект файла
        [void]$xmlstring.Append(" </FILE_ENTRY>`n")
    }
# когда объекты закончились, закрываем первый тег <FCIV> и подаём полученный XML дальше
    End {
        [void]$xmlstring.Append("</FCIV>`n")
        [string]$xmlstring.ToString()
    }
}

В этом случае деградация производительности будет минимальной.