Contents of this directory is archived and no longer updated.

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


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

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

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

Basic certificate-based authentication

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

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

TLS negotiation abstract

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

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

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

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

Smart card authentication abstract

Примечание: если у пользователя уже есть соответствующий сервисный тикет (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).

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


Share this article:

Comments:

Дмитрий Пономарев
Дмитрий Пономарев 27.01.2012 14:18 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

Вадимс, Годные статьи! Я сичтаю, что если уж объяснять "в деталях", то нужно объяснять, почему происходит именно так. Ну, например, вот ты говоришь, что "<...> именно поэтому, при использовании смарт-карты для логона, сервер KDC должен иметь свой собственный сертификат", но не объясняешь, почему. Я бы объяснил, что при использовании хеша парольного аутентификатора, клиент доверяет KDC на основании того, что KDC обладает хешем пароля пользователя, а при аутентификации по СОК клиент основывает доверие на доверии к сертификату, представленному KDC. И еще. Вот ты пишешь "учётные данные для аутентификации при помощи NTLM". Мало кто поймет суть этого трюка. Расскажи подробне людям о "поддержке" NTLM при PKCA, про "трюк", когда KDC перенаправляет в PACе пользователю "по требованию" хеши паролей, ассоциированные с его учетной записью. А то существует заблуждение, что если пароль не участвует, то и хешам пароля для поддержки NTLM неоткуда взяться, а меж тем, все на ресурсы "по IP адресу" доступаются после PKCA. :))

Vadims Podāns
Vadims Podāns 27.01.2012 15:27 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

я же описал основные факторы, которые увеличивают время логона смарт-картой. На счёт сертификата KDC, там во-первых, происходит обоюдная аутентификация и во-вторых, KDC свой ответ тоже подписывает сертификатом. Я не посчитал нужным рассказывать про учётные данные NTLM, потому что он никак не будет влиять на рассматриваемую тему. Достаточно знать, что у пользователя будет пакет учётных данных NTLM, которые он сможет использовать для ресурсов, не поддерживающих керберос (или где не используется NTLM). В таком случае пришлось бы рассказывать, почему при обращении к ресурсу по IP, а не по имени используется не керберос, а NTLM. Мне кажется, что знание этого факта уже само по себе достаточно. Опять же, я не ставил целью рассказать работу PKCA (равно, как и кербероса) в деталях, а лишь осветить наиболее важные моменты. Хотя, согласен, такое заблуждение существует (что при логоне смарт-картой никаких NTLM не бывает).

Дмитрий Пономарев
Дмитрий Пономарев 27.01.2012 16:37 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

Согласен с тобой, что смежные темы раскрывать не нужно. Почитал первую часть. Ты не все указал, что может в сертификате указываться в качестве "указателя" на объект пользователя. Распознается кроме UPN и DN еще RFC-emailaddress и серийный номер сертификата. Этот процесс обзывается, Account Binding, кажется... Дополни, если это так.

Oleg Krylov
Oleg Krylov 29.01.2012 13:59 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

Встряну в разговор гур, т.к. хоть и не являюсь специалистом по PKI, тема имеет ко мне непосредственное отношение. Вопросов два: 1. Вадимс, ты пишешь: "5.Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных...". Внимание вопрос: что именно имеется ввиду под "некоторым объемом данных"? Это какая-то служебная информация (тип клиента, таймстамп и прочая, прочая, прочая) или рандомный набор символов? А может это отрывок из любимого произведения данного конкретного пользователя? 2. У меня карие глаза, если что, и вообще за использование Registred Trademark "Oleg Krylov" неплохо было бы отчислений каких-то :)

Dmitry Zobnin
Dmitry Zobnin 30.01.2012 08:33 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

Набрался смелости и решил задать вопрос :). Как именно сервер (на данной схеме обозначен как Web Server in the Cloud) определяет членство пользователя в группах безопасности AD? Я так понял, что список SID'ов групп, членами которых данный юзер является, находится в каком-то из токенов (TGT и/или TGS). Не могли бы вы пояснить этот момент?

Vadims Podāns
Vadims Podāns 30.01.2012 08:55 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

> Это какая-то служебная информация (тип клиента, таймстамп и прочая, прочая, прочая) она самая. Как в обычном керберосе. > и вообще за использование Registred Trademark "Oleg Krylov" неплохо было бы отчислений каких-то :) все персонажи в статье вымышлены и любое совпадение с реальными лицами — чисто случайность. > определяет членство пользователя в группах безопасности AD? при помощи TGS, который вкладывается в AP-REQ.

Stanky
Stanky 05.02.2012 11:16 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

"происходит уже обоюдная аутентификация сервера и клиента" - далеко не факт. Обоюдная аутентификация происходит всегда только между клиентом и контроллером домена, а между сервисом и клиентом - это уже опционально, ибо сертификат при получении TGS уже не используется.

Aleksey
Aleksey 17.09.2013 18:29 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

Вадимс, а какое ограничение по количеству входов по сертификату на компьютер пользователя при отсутствии соединения с контроллером домена? Если есть, то где и как это можно настроить?

Aleksey
Aleksey 18.09.2013 09:49 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

Вадимс, а вообще ограничение есть и какое оно (если есть)?

Vadims Podāns
Vadims Podāns 19.09.2013 12:47 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт второй, а Ричард Третий)

Не в курсе даже. Знаю, что есть ограничение, что кэшируется только последняя смарт-карта, которая использовалась при последнем онлайн логоне.

Comments are closed.