Остальные материалы цикла:

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

---

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

---