Программирование серверных приложений

InitializeSecurityContext и буферы

admin — Mon, 01 Mar 2010 14:52:26 +0000

У вас будет довольно смутное представление о том, как SSPI работает с буферами, пока вы не начнете вникать в подробности. После этого многое прояснится. Как я уже говорил, буферы используются в InitializeSecurityContext для входных и выходных блобов, предназначенных для взаимодействия с сервером. При первом вызове InitializeSecurityContext вы передаете NULL параметром plnput. Но, получив данные от сервера, вы должны построить буферы и передавать их этой функции.
Как при вводе, так и при выводе InitializeSecurityContext получает массив SecBuffer типа SECBUFFER_TOKEN. Этот тип указывает системе, что данный буфер является или входным, или выходным блобом для построения контекста.
Прежде чем обратиться к InitializeSecurity'Context, надо выделить память для буферов pbBlockReceived и pbBlockToSend. В качестве альтернативы можно иметь функцию, выделяющую блок для вашего выходного буфера.
После обращения к InitializeSecurityContext элемент cbBuffer выходного буфера содержит размер блоба, который будет послан серверу. Если этот размер ненулевой, вам следует послать серверу столько байт, сколько указано этим значением из буфера, на который указывает элементpvBuffer. Это «рукопожатие» в процессе аутентификации.
SSPI определяет несколько различных типов буферов. Я буду рассказывать о них в соответствующем контексте. Список типов буферов, определенных на данный момент, см. в документации Platform SDK.

Подпись и шифрование сообщений

admin — Wed, 17 Feb 2010 14:53:54 +0000

Пройдя аутентификацию, клиент и сервер могут систематизированно обмениваться сообщениями. Полная эффективность такого взаимодействия будет достигнута, если сообщения, которыми они обмениваются, подписаны и зашифрованы. При этом следует придерживаться таких правил:
1. подписывайте сообщения, когда конфиденциальность не требуется, но нужна уверенность в целостности сообщений (т. е. практически всегда);
2. шифруйте сообщения, когда нужно обеспечить конфиденциальность (подписывать сообщения при шифровании не обязательно).
Для подписи и шифрования применяются «параллельные» функции так же, как и при аутентификации, но механизм идентичен и на клиенте, и на сервере.
Вы передаете MakeStgnature буфер данных и полный контекст, а она возвращает вам подпись, которую вы вместе с буфером данных передаете по сети. Принимающая сторона берет эту информацию и проверяет буфер данных, используя подпись. Подчеркиваю: вы должны рассматривать данные, полученные от MakeSignature, как «черный ящик», нужный только при обмене информацией.
Параметр IQOP связан с протоколом безопасности и позволяет вам указать подробности используемого для подписи алгоритма. Обычно этот параметр устанавливается в 0. Если вам нужно отслеживать последовательность номеров сообщений, вы должны указывать номер сообщения в параметре Message-SeqNo. Если последовательность вас не интересует, укажите 0.
Как и в других функциях SSPI, с которыми мы имели дело, данные из функции MakeSignature передаются через буферы. В случае MakeSignature передаются два буфера с одним дескриптором, так что вам нужно создать массив из двух переменных SecBuffer. Тип буфера, в который вы будете получать подпись сообщения, должен быть SECBUFFERTOKEN. Второй буфер должен иметь тип SECBUFFER_DATA — это указывает на то, что он содержит собственно данные. Ниже приведена функция, которая подписывает буфер данных и посылает его с помощью псевдокоммуникационной функции SendData.

Демонстрационное приложение SSPIChat

admin — Thu, 04 Feb 2010 14:54:23 +0000

Пример SSPIChat («12 SSPIChat.exe») демонстрирует применение всех рассмотренных нами технологий, связанных с SSPI, включая согласование аутентификации, перевоплощение, подпись и шифрование сообщений. Исходный код и файлы ресурсов SSPIChat находятся в каталоге 12-SSPIChat на прилагаемом компакт-диске. Пользовательский интерфейс SSPIChat таков :
Чтобы разобраться с этим примером, запустите его несколько раз с одной или разных машин в сети. Связь осуществляется по TCP/IP. Прежде чем инициировать взаимодействие, вы можете выбрать желаемый компонент защиты и указать, нужна ли вам взаимная аутентификация, шифрование и делегирование.
При использовании делегирования сервер создаст второе диалоговое окно, относящееся к клиентским реквизитам. Это окно можно задействовать для связи с третьим сервером, который будет рассматривать противоположную сторону в качестве изначального клиента. (Эта функция не работает, если делегирование на серверной машине запрещено.)
Независимость от транспортного уровня подчеркнута наличием класса CTransport, скрывающего всю функциональность, связанную с коммуникациями и содержит функции SendData и ReceiveData. Последние — примерно то, что применялось во фрагментах кода в этой главе.
Я настоятельно рекомендую хорошо разобраться с этим примером, прежде чем приступать к написанию SSPI-программ с применением протокола SSL (он описан далее). Программная модель SSPI сложна и изобилует «подводными камнями». Осмыслив общие подходы, вам будет проще разобраться с SSL.

Хранилища сертификатов

admin — Sat, 30 Jan 2010 15:53:25 +0000

Основой для управления сертификатами являются хранилища. CryptoAPI позволяет управлять разными типами хранилищ — от персональных однопользовательских до машинных и временных хранилищ, существующих только в памяти. При создании хранилища вы указываете носитель, на котором оно будет содержаться, иначе оно не будет сохранено.
Хранилища содержат сертификаты, которые, как вы знаете, применяются для аутентификации, подписи и шифрования. Однако, работая с SSL, вам вряд ли придется иметь дело с хранилищами, кроме машинных (в которых вы будете хранить сертификаты сервера) и, возможно, персональных (для хранения сертификатов клиентов). Опишу несколько сценариев.
Сценарий 1 Вы разрабатываете службу, использующую для связи SSL, которая будет работать с учетной записью LocalSystem. Пусть клиент будет аутентифицировать службу, но не наоборот. Скорей всего вы создадите для этой службы сертификат (и соответствующий ему закрытый ключ) и будете хранить его в машинном хранилище своей хост-системы. Служба распознает сертификат по его общему имени. Когда клиент подключается к службе, она с помощью CryptoAPI отыскивает свой сертификат и, используя его, инициирует сеанс связи с применением SSPI и SSL В этом случае серверу известно, что сертификат надо искать в машинном хранилище.
После аутентификации у клиента есть копия сертификата, которую он получил по сети. Хотя сам клиент не посылает сертификат, ему все же нужно расшифровать информацию из сертификата, чтобы убедиться, что он подсоединился к нужному серверу. В Windows 2000 SSL автоматически проверяет цепочку сертификатов, чтобы убедиться, что она соответствует данным, полученным от центра сертификации, которому доверяет клиент. Кроме того, имя сервера (в том виде, как его указал клиент) сравнивается с общим именем в сертификате сервера.
Однако вашему клиенту ничто не мешает с помощью функций CryptoAPI открыть сертификат, получить из него общее имя и сравнить его с известным общим именем сертификата, который он ожидал получить. Если эти имена не совпадают, клиент может предпочесть отсоединиться от сервера, так как сервер не тот, за кого себя выдает. Полезно уметь делать такую проверку, так как ранние версии Windows в отличие от Windows 2000 сами этого не делают.
В этой ситуации подразумевается наличие доверительных отношений, так как вы должны быть уверены, что центр сертификации не выдал несколько сертификатов с одним общим именем. Ваша политика в отношении разных центров сертификации может быть разной.
Общее имя представляет собой простую текстовую строку. Однако помните, что сертификаты подписаны закрытым ключом центра сертификации. Следовательно, если вы открыли сертификат открытым ключом центра, это значит, что информация в нем не менялась.
Браузеры посимвольно сравнивают общее имя из сертификата с URL, к которому подключен браузер. Если имена не совпадают, браузер считает, что защита нарушена.
Сценарий 2 Все, как в первом сценарии, но служба работает не с учетной записью LocalSystem, а со специальной доменной учетной записью, созданной для этой службы. Что касается сертификатов, то единственное существенное отличие в том, что вы (администратор сервера) будете хранить сертификат в персональном хранилище для учетной записи сервера. Дело в том, что учетная запись сервера может не быть администратором на хост-машине и, таким образом, не иметь доступа к машинному хранилищу сертификатов. Так что вам следует знать, как получать доступ к персональным учетным записям.
Сценарий 3 Этот сценарий надо рассмотреть независимо от того, с какой учетной записью будет работать ваш сервер: машинной или собственной. Если серверу нужен сертификат клиента, последний при поиске сертификата должен действовать примерно так же, как сервер.
Когда установлено соединение, клиент ищет сертификат на своей машине и использует его, чтобы установить SSL-соединение. Поскольку клиентские программы работают в основном с учетной записью интерактивного пользователя, им скорее всего не составит труда найти сертификат в персональном хранилище по его общему имени и послать его по сети. Если вы будете писать программы, реализующие один из этих сценариев,
вам нужно уметь с помощью CryptoAPI решать следующие задачи:
1. открывать хранилище сертификатов;
2. отыскивать сертификат по его общему имени;
3. расшифровывать полученный сертификат;
4. просматривать общее имя в расшифрованном сертификате и сравнивать его с известным именем.
Все эти задачи позволяет решить CryptoAPI. Хотя есть еще одна связанная с этим задача, о которой я не говорил, но выполнять которую придется — получение сертификата.

Получение сертификата

admin — Mon, 18 Jan 2010 15:53:39 +0000

Получение сертификата — непростая тема хотя бы потому, что способов ее решения несколько. Я дам лишь начальные сведения, а дальше вы сами проанализируете свои требования и решите, что выбрать. Основных подходов два:
1. купить сертификат в общедоступном центре сертификации;
2. работать с собственным центром сертификации на базе Microsoft Certificate Services.
Первый подход предполагает взаимодействие со сторонними организациями, такими как VeriSign или Thawte (это лишь одни из многих), для получения сертификата для вашего серверного ПО. Эти организации будут хранить информацию о вашей компании, а также о том, как используется ваш сертификат, и выдадут вам этот сертификат, заверенный своей подписью, за некоторую плату.
Преимущество такого подхода в том, что известным центрам сертификации по умолчанию доверяют большинство ОС. Так что клиентские программы (или конкретные пользователи) без лишних хлопот и затрат распознают сертификат вашего сервера.
Второй подход предполагает наличие работающей службы Microsoft Certificate Services. Отлично, но вам нужно быть уверенными, что ваше клиентское ПО доверяет установленному вами центру сертификации. Если ваш клиент и сервер исполняются в одной организации, вам скорее всего нужно придерживаться этого подхода. Вы можете его придерживаться, даже если ваш сервер и клиент работают через Интернет, но при этом клиентское ПО должно обеспечивать установление доверительных отношений пользователя с вашим центром сертификации.
Сертификатом можно управлять и перемещать его из одного системного хранилища в другое через модульный компонент Certificates консоли Microsoft Management Console (MMC). Это позволит вам проверить разные сценарии с одним и тем же сертификатом. Например, вы можете создать сертификат сервера, перетащить его в папку персональных сертификатов (Personal) машины и затем проверить работу сервера с учетной записью машины. Позднее вы можете попробовать запустить сервер с учетной записью пользователя, перетащив через ММС сертификат в папку Personal учетной записи пользователя.

Поиск сертификата

admin — Thu, 07 Jan 2010 15:54:53 +0000

В сертификатах содержится порядочный объем информации, и CryptoAPI позволяет искать сертификаты на основе любой содержащейся в них информации. Однако большая часть информации в сертификатах не уникальна, что делает критерии поиска неоднозначными. Обычно на сертификаты ссылаются по их общим именам, так что при поиске следует использовать именно их.
Общее имя сертификата является его атрибутом. При поиске сертификата в хранилище вы можете в качестве критерия использовать один или несколько атрибутов. Для этого создается массив структур, по одной для каждого атрибута, и этот массив передается функции CertFindCertificatelnStore.
Собственно критерий поиска задается параметром pvF.indPara. Если вы ищете сертификат по его атрибутам, указав флаг CERT_FIND_SUBJECT_ATTR, этот параметр должен содержать указатель на структуру CERT_RDN.
CertFindCertificatelnStore позволяет перебрать сертификаты в хранилище. Параметр pPrevCertContext указывает последний найденный контекст. Его нужно установить в NULL для контекста первого сертификата, а также когда вы ищете только один сертификат.
Если поиск завершен успешно, CertFindCertificatelnStore возвращает указатель на структуру контекста сертификата. Закончив работу с этой структурой, вы должны освободить ее с помощью CertFreeCertificateContext.
Конструкция этой структуры обладает большой гибкостью, необходимой для хранения различных типов данных, которыми могут быть представлены атрибуты сертификата. Элем сит pszObjIci является идентификатором рассматриваемого атрибута. Для общего имени сертификата установите его значение в szOID_COMMON_NAME. Элемент dwValueType указывает тип данных этого значения. Для общего имени устанавливайте его в CERT_RDN_PRINTABLE_ STRING. (Для общих имен сертификатов всегда используйте ANSI-строки.)
Элемент Value — это блоб-структура с двумя элементами: cbData npbData. Они являются размером данных и указателем на данные соответственно.
Некоторые типы атрибутов и их типы данных описаны в документации Platform SDK. Если структуры, которые вы хотите заполнить, не описаны в документации, можете использовать другой подход для поиска сертификата. Например, откройте сертификат и просмотрите его значения RDN, чтобы в дальнейшем для поиска сертификатов использовать сходные данные.
Приведенный далее пример кода показывает, как применяются рассмотренные функции работы с сертификатами. В нем открывается персональное хранилище локальной машины и ищется сертификат с общим именем «Jason's Test Certificate».
Хотя «Jason's Test Certificate» — допустимое общее имя сертификата, оно не демонстрирует наиболее распространенный подход использования общих имен. Обычно сертификат называется в соответствии с расположением сервера в сети. Таким образом, клиентское ПО может сравнить общее имя сертификата с именем сервера, с которым оно пытается установить защищенный сеанс взаимодействия.

Программирование для SSL

admin — Wed, 30 Dec 2009 15:56:12 +0000

Большая часть того, что вы знаете об SSPI, применима к взаимодействию по протоколу SSL. Предполагается, что, читая этот раздел, вы знаете о применении SSPI для Kerberos и NTLM, здесь будем основываться на той информации, которую вы уже получили в этой главе.
Как и в случае с протоколами NTLM и Kerberos, вы обращаетесь к Acquire-CredentialsHandle как на клиентской, так и на серверной стороне. Однако при работе с SSL вам хотя бы на одной стороне нужно получить сертификат, передав специфичную для SSP структуру SCHANNEL_CRED. Эта структура похожа на структуру SEC_WINNT_AUTH_IDENTITY (мы ее уже рассмотрели), содержащую имя пользователя, пароль и имя домена, но SCHANNEL_CRED хранит еще и информацию сертификата.

Работа с протоколом SSL через SSPI

admin — Fri, 11 Dec 2009 15:55:43 +0000

Мы обсудили SSPI и аутентификацию с учетными записями доверенных объектов Windows с применением протоколов NTLM и Kerberos. Аутентификацию можно также проводить с использованием SSPI посредством цифровых сертификатов. Это делается через SSPI и компонент защиты SChannel, реализующий SSL. Если вы планируете работать с SSL, не забудьте включить в исходные тексты заголовочные файлы Security.h и SChannel.h, а также скомпоновать свой проект с библиотечным файлом Secur32.1ib.
В отличие от рассмотренных нами протоколов SSL ориентируется не столько на аутентификацию клиента сервером, сколько на аутентификацию сервера клиентом. При этом сервер также может аутентифицировать клиента, что позволяет ему заимствовать права. Для начала рассмотрим наиболее распространенный сценарий.
Клиент хочет подключиться к некоторому сайту, вероятней всего в Интернете. Прежде чем передать на сайт важную информацию, он хочет убедиться, что взаимодействует с нужным субъектом. Сервер посылает клиенту свой сертификат, который подписан и содержит открытый ключ из пары открытого/ закрытого ключа.
Клиент может узнать из сертификата, кто его издал, и решить, доверять ли ему. Если он доверяет соответствующему центру сертификации, он считает, что информация в сертификате имеет силу. После проверки сертификата клиент может прочитать содержащуюся в нем информацию, такую как URL сервера, и сравнить с той, что предоставил взаимодействующий с ним сервер. При успешном сравнении клиент может быть спокоен: он связался с нужным ему сервером.
В модели сертификатов остается много не проработанных вопросов. Как на самом деле клиентское ПО доверяет информации в сертификате? Правильно ли переносить принятие решения о доверии с клиентского ПО на пользователя (человека)? Как передается информация? Какие корневые центры являются доверенными? Может ли пользователь выбирать эти центры сертификации? Можно ли доверять всем центрам в отношении всех типов сертификатов? Нужно ли, чтобы центры сертификации были привязаны к конкретным областям деятельности, например, медицине или розничной торговле? Ответы на эти вопросы будут проясняться по мере роста технологии. Сейчас же я сосредоточусь на технике применения сертификатов.
В зависимости от среды, спроектированной вами для защищенного обмена данными, вы можете решить стать собственным центром сертификации. Microsoft Certificate Services позволит вам выпускать собственные сертификаты, и, поскольку ваши клиенты доверяют вашему центру, вы сможете создавать сертификаты, соответствующие вашим конкретным стандартам.
С собственным центром сертификации вы даже сможете пойти на то, чтобы «прошивать» сертификаты вашего центра в коде клиентских программ. Когда клиент соединится с сервером, вы сможете использовать эти явные доверительные отношения для инициации сеанса, а затем для генерации клиентского сертификата (клиент сгенерирует закрытый ключ и передаст открытый ключ серверу). Сервер с помощью этого открытого ключа сгенерирует сертификат в собственном центре и сохранит нужную информацию. После этого при каждом соединении клиента с сервером они могут использовать открытые ключи друг друга (в виде сертификатов) для быстрой взаимной аутентификации и согласования сеансового ключа, что позволит им сразу перейти к обмену данными.
Признав сертификат сервера, клиент может извлечь из сертификата открытый ключ, зашифровать им симметричный сеансовый ключ и послать его серверу. Сервер — единственная сущность, у которой есть соответствующий закрытый ключ, так что он сможет расшифровать сеансовый ключ. Теперь клиент и сервер могут обмениваться данными, будучи уверенными, что они взаимодействуют с кем нужно.
В стандартных сценариях, требующих защищенного обмена данными, браузер или другой клиент посылает через сеть клиенту информацию о кредитной карте или другие конфиденциальные данные. Для подобного рода транзакций можете использовать SSPI, чтобы работать по протоколу SSL.

SSL — это поток

admin — Sat, 28 Nov 2009 15:56:46 +0000

В отличие от других рассмотренных протоколов, в которых предполагается, что данные, которыми обменивается стороны, сформированы в виде блобов (с помощью функций InitializeSecurityContext и AcceptSecurityContext), в SSL вообще не передаются блобы! Получая блоб от InitializeSecurityContext, вы передаете данные в «чистом виде», не посылая предварительно размер этих данных.
Хотя SSL предполагает передачу и получение данных «в чистом виде», ничто не мешает вам реализовать некий «мета-протокол» с указанием размера передаваемых блобов. Это может радикально упростить ваш SSL-код, но формально вы отойдете от спецификации HTTPS. Если вы будете передавать по сети, кроме данных, их размер, ваш клиент или сервер скорей всего не смогут взаимодействовать с клиентами и серверами, реализующими протокол HTTPS, очень распространенный в Web-браузерах и Web-серверах.
Вы можете удивиться: откуда принимающая сторона знает, сколько данных нужно прочитать? А она и не знает. Дело в том, что в SSL обмен данными производится в виде потоков. Приведенный сценарий показывает, как SSL реагирует на поток информации. Здесь говорится о том, как считывается информация, пока не закончится сообщение.
1. Одна сторона (например, клиент) посылает неизмененный блоб по сети.
2. Принимающая сторона читает столько информации, сколько может и передает ее функции «обработки блоба». (В нашем случае сервер передает данные функции AcceptSecurityContext.)
3. Если принимающая сторона не прочитала из сети достаточно информации, чтобы закончить этот проход транзакции, функция обработки блоба выдает код завершения SEC_E_INCOMPLETE_MESSAGE.
4. Если возвращается такой код, указывающий, что сообщение не получено полностью, вам нужно сохранить уже полученные данные и продолжать получать дополнительные данные, пока функция не вернет значение, отличное от SEC_E_INCOMPLETE_MESSAGE.
Нужно понимать, что потоковая природа SSL порождает еще одну проблему, кроме получения не всех данных. Ваша программа может получать слишком много данных из сети. При этом AcceptSecurityContext или InitializeSecurity-Context укажет на наличие излишних данных, которые нужно сохранить для дальнейшего использования (видимо, после чтения дополнительных данных.)
Так что, как видите, в SSL больше сценариев. Две следующие ситуации вы всегда должны четко представлять.
1. Вам может не хватать полученных данных, чтобы выполнилась функция SSPI, и потребуется получать дополнительные данные.
2. У вас может быть избыток информации для SSPI-функции, и вам придется сохранить ее для следующих обращений к функциям SSPI.
А. Вам требуется получить дополнительную информацию из сети. Б. Вам не требуется получать дополнительную информацию из сети.
Во втором сценарии два «подсценария». Сценарий 2А достаточно очевиден, а вот 2Б — неожиданность. Случается, что AcceptSecurityContext или Initialize-SecurityContext указывают, что вы передали им лишние данные, и требуется «продолжение». Более того, в этих случаях функции обработки блобов могут не предоставить данных для возврата по сети. Так что вам придется изменить буфер и снова передать его этим функциям.
По-моему, сценарий с избыточными данными никогда не обнаружит себя в приложениях с SSPI, потому что AcceptSecurityContext и InitializeSecurityContext обладают всей нужной информацией для обработки данных. Эти функции прервут свое выполнение, только если им не хватит данных, чтобы обработать законченное сообщение.
Проблему с лишними данными не так просто решить, как может показаться. Представьте, что вы получаете из сети блоб, разбитый на три «раздела», последний из которых не завершен, и вам требуются дополнительные данные из сети. Вы передаете этот блоб, например в AcceptSecurityContext, и она обрабатывает первые два внутренних раздела. Закончив, она обнаруживает, что последний раздел неполный и ей нужны дополнительные данные. Однако нежелательно передавать весь блоб этой функции, получив дополнительные данные, так как она уже обработала первые два внутренних раздела.
Чтобы избежать такой ситуации, разработчики системы решили, что, если любой внутренний раздел или подраздел блоба обработан, функции AcceptSecurityContext и InitializeSecurityContext должны вернуть управление независимо от того, достаточно ли у них данных для дальнейшей обработки. Таким образом, вы поймете, что нужны дополнительные данные, скорректируете буфер и снова вызовите нужную функцию.

SSL и перевоплощение

admin — Thu, 12 Nov 2009 15:58:26 +0000

Если сервер аутентифицировал клиента, получив его сертификат (т. е. имела место не анонимная аутентификация), сервер может позаимствовать права этого клиента. Заимствование прав при этом фактически не отличается от аналогичной процедуры с применением других протоколов с SSPI. Вы просто передаете описатель контекста функции ImpersonateSecurityContext или получаете маркер непосредственно, обращаясь к QuetySecurityContextToken. (Обе эти методики рассмотрены ранее в этой главе.)
Однако остается один актуальный вопрос: как Windows 2000 создает маркер для пользователя, не имея ничего, кроме его сертификата? Ответ: установив соответствие сертификата в Active Directory или с помощью специфической информации, которую Microsoft встраивает в сам сертификат. Всего есть три способа установить соответствие между сертификатом и маркером для учетной записи доверенного объекта в домене Windows 2000.
Прежде чем рассказывать, как устанавливается соответствие между сертификатом и пользователем в домене, я хотел бы подчеркнуть важность самой этой возможности. Если к серверу под управлением Windows 2000 подключается клиент с известным сертификатом, сервер может построить для этого клиента маркер и зарегистрировать его на сервере независимо от того, под управлением какой ОС работает клиент. Это значит, что вы можете заимствовать права клиента, ПО которого работает на машине под управлением UNIX, Windows или другой системы, поддерживающей SSL
Чтобы установить соответствие между сертификатом и учетной записью пользователя в Windows 2000, можно применить три подхода.
Соответствие «один к одному* Любой сертификат, подписанный издателем, которому доверяет сервер, может быть связан с учетной записью пользователя. Когда такой сертификат используется в SSL-соединении с заимствованием прав, система ищет общее имя и имя издателя сертификата в Active Directory, чтобы определить учетную запись пользователя, для которой нужно создать маркер.
Соответствие «многие к одному* Любой центр сертификации, которому доверяет сервер, может быть связан с учетной записью пользователя. Когда любой сертификат, подписанный этим центром, используется в SSL-соединении с заимствованием прав, система ищет в Active Directory имя издателя, чтобы определить учетную запись пользователя, для которой нужно создать маркер.
UPN-соответствие Чтобы установить соответствие с помощью UPN (user principal name) — имени пользователя, имеющего учетную запись в данной среде, — в отличие от двух других подходов информация из сертификата используется для поиска учетной записи пользователя, для которой нужно создать маркер. UPN является именем учетной записи, права которой нужно заимствовать, и в сертификате это имя должно существовать как специальное поле. Выглядеть оно может примерно так: «jclark@subdo-main.microsoft.com».
Хотя перевоплощение для SSL-соединений не представляет проблем, за администрирование соответствий сертификатов вы отвечаете сами. Простейший подход, требующий минимум администрирования, — UPN-соответствие. Все, что вам нужно в этом случае, — центр сертификации на базе Microsoft Certificate Services в качестве центра сертификации предприятия. Затем вы запрашиваете у центра сертификат «пользователя». Этот сертификат будет включать атрибут UPN, содержащий имя пользовательской учетной записи, запросившей сертификат. Если этот сертификат применяется при подключении клиента к серверу по протоколу SSL, права его владельца могут быть заимствованы сервером.
Вы, конечно, можете захотеть заимствовать права сертификатов, не содержащих специфической информации, которую добавляет Microsoft. Для этого вам потребуется явно установить соответствия в Active Directory. Чтобы установить соответствие между сертификатом и пользователем в Active Directory типа «один к одному» и «многие к одному», используются похожие методики.
Сначала вам следует экспортировать сертификат в .CER-файл. Этот тип файла имеет стандартный формат для экспорта сертификатов и включает подписанную копию сертификата и открытый ключ, но не включает соответствующий закрытый ключ для сертификата. Модульный компонент Certificates в ММС позволяет экспортировать сертификат, просто щелкнув его правой кнопкой мыши и выбрав All Tasks, а затем Export. Таким образом вы запустите мастер Certificate Export Wizard.
Получив .CER-файл, нужно создать соответствие для учетной записи пользователя в Active Directory в следующей последовательности:
1. в ММС открыть модульный компонент Active Directory Users and Computers;
2. в меню View выбрать Advanced Features;
3. в левой панели выбрать папку Users;
4. в правой панели щелкнуть правой кнопкой пользователя, к которому вы хотите привязать сертификат, и выбрать Name Mappings в контекстном меню;
5. на вкладке Х509 Certificates окна Security Identity Mapping нажать кнопку Add;
6. выбрать .CER-файл с нужным вам сертификатом и нажать Open — появится диалоговое окно Add Certificate:
7. если вы установите флажок Use Subject For Alternate Security Identity у вас будет соответствие «один к одному»;
8. если сбросить флажок Use Subject For Alternate Security Identity и оставить установленным только флажок Use Issuer For Alternate Security Identity, получится соответствие «многие к одному».
После этого серверное ПО сможет заимствовать права клиента.
При установлении соответствий сертификатов есть две распространенные проблемы, на которых нужно остановиться. Во-первых, если сервер не доверяет издателю сертификата, у клиента, подключающегося с таким сертификатом, не могут быть позаимствованы права. Во-вторых, если сертификат является пользовательским, созданным центром сертификации на базе Microsoft Certificate Services, прежде чем в Active Director)' будет установлено явное соответствие, будет задействован UPN. Так что при попытке установить соответствие такого сертификата пользователю в Active Directory результаты могут быть непредсказуемыми.