Остальные материалы цикла:
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:
- Откройте оснастку Active Directory Users and Computers (dsa.msc);
- В меню View установите флажок на Advanced Features;
- Выберите учётную запись пользователя, с которой будут связываться сертификаты группы работников;
- В контекстном меню выберите Name Mappings;
- В открывшемся окне, кнопкой 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, алгоритм поиска учётной записи с которой можно связать предъявленный сертификат усложняется. Контроллер домена будет искать в своей базе сертификаты и пытаться их забиндить по следующим признакам (именно в такой последовательности, как они здесь указаны):
- Точное совпадение полей Subject и Issuer — X509:<I><S>
- Только по полю Subject — X509:<S>
- По полям Issuer и Serial Number — X509:<I><SR>
- По расширению Subject Key Identifier — X509:<SKI>
- По Thumbprint (хешу всего сертификата) — X509:<SHA1-PUKEY>
- И, наконец, по полю 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, а остальное — только когда потребуется или просто ради лулзов 
. В следующей части перейдём немного от теории к практике.
Что бы почитать?