Интернет-журнал "Домашняя лаборатория", 2007 №6
Шрифт:
Возможность взаимной аутентификации появилась именно в Kerberos (в NT LAN Manager она отсутствовала). Механизм очень прост — сервер S после аутентификации клиента С высылает последнему временную метку из аутентификатора этого самого клиента, зашифрованную ключом сессии. Это доказывает клиенту, что данный сервер действительно является сервером S, т. к. для расшифровки аутентификатора ему был необходим ключ, который он мог извлечь только из билета Т, зашифрованного секретным ключом сервера S.
Реализация
Смысл и алгоритм реализации данных сервисов уже описан выше. Осталось заметить, что в качестве секретного ключа, известного только передающей и принимающей сторонам, можно использовать соответствующий ключ сессии.
Делегирование
Подробно понятие делегирования (как и понятие имперсонализация) будут рассматриваться далее. Здесь будет объяснена только его суть и описан механизм реализации делегирования в Windows 2000 Kerberos.
При имперсонализации клиента (с его согласия) сервер получает доступ к локальным ресурсам от имени данного клиента (уровень передаваемых прав доступа определяется клиентом). Однако имперсонализация не позволяет серверу делать удаленные вызовы других серверов от имени клиента. Конечно, выполняя некоторый вызов клиента С сервер S может послать удаленный вызов на другой сервер Q, но с точки зрения сервера Q вызов получен именно от сервера S, а не клиента С. Следовательно, даже если клиент С имеет особые права доступа к серверу Q, сервер S не сможет ими воспользоваться, выполнив простую имперсонализацию клиента С.
В чем причина ограниченности возможностей имперсонализации? Имперсонализация реализуется средствами конкретной операционной системы. При имперсонализации в Windows потоку в серверном процессе, выполняющему вызов пользователя, приписывается маркер доступа (access token), в котором записаны права данного пользователя, а не серверного процесса (как обычно бывает по умолчанию). Это позволяет получить от имени пользователя доступ к локальным ресурсам, т. к. при этом просто сопоставляются права доступа из маркера доступа со списком принципалов, которым разрешен или запрещен доступ к конкретному локальному ресурсу.
При удаленном доступе необходимо обеспечить такие сервисы как аутентификация, контроль целостности данных, шифрование трафика. Очевидно, что маркер доступа не содержит необходимых для этого данных. Фактически, говоря в терминах протокола Kerberos, Сервер S должен обратиться к KDS с запросом на получение билета для сервера Q, причем сервер Q при получении этого билета должен быть уверен, что получил он его от клиента С, а не от сервера S.
Данная возможность реализована в Kerberos и называется делегированием. Отметим, что делегирование отсутствует в NT LAN Manager.
Делегирование прав от клиента С серверу S осуществляется следующим образом:
• Клиент С посылает серверу S (которым он уже аутентифицирован) свой билет для KDS — и ключ сессии с KDS —
Сервер S должен иметь эти данные для того, чтобы получить от KDC билет для какого-либо другого сервера (например, Q), выданный как бы клиенту С. В отличие от сервера Q, KDS обмануть очень сложно (да и сервер Q можно обмануть только с помощью самого KDS). Поэтому от KDS и не скрывается то, что запрашивает билет сервер S, но выписать его необходимо на имя клиента С. Среди флагов билета TGT должен быть флаг forwardable, указывающий на то, что клиент С еще при первом обращении к KDS уведомил его о том, что в будущем он будет делегировать свои полномочия другим серверам (кстати, не любому серверу, а только тому, который зарегистрирован в домене как заслуживающий доверия (trusted) сервер).
• Сервер S посылает (от лица клиента С) запрос KDS на получение билета для сервера Q, в который включается, как обычно, имя сервера Q, билет и аутентификатор
Зметим, что в аунтетификатор включается имя клиента и он кодируется ключом сессии клиента С и KDS.
• KDS аутентифицирует клиента
Конечно, KDS замечает, что билет запрашивает не клиент С (вызов пришел не с того IP адреса, который указан в TGT). Однако он закрывает на это глаза в связи с тем, что в
TGT имеется флаг forwardable, и отправитель запроса знает ключ, который он мог получить только от клиента
• KDS посылает серверу S запрошенный билет, зашифрованный ключом сервера Q, и ключ сессии сервера S и сервера Q -
• Далее общение сервера S и сервера Q проходит как обычное общение клиента и сервера. Заметим, что с точки зрения сервера Q он работает с клиентом С. Это позволяет серверу S делегировать полученные от клиента полномочия серверу Q и т. д. Для этого у него есть все необходимое: TGT, закодированный ключом KDS, и ключ сессии
Удаленный вызов за пределы домена
Проблема удаленного вызова за пределы домена состоит в том, что клиент должен получить билет для сервера из другого домена у KDS этого другого домена. Но наш клиент не зарегистрирован в этом новом домене и, следовательно, не может получить там TGT.
Решение проблемы — доверие двух KDS из разных доменов друг другу. Выражается это доверие в том, что эти KDS из первого и второго доменов генерируют общий только им известный секретный ключ. Краткое описание механизма аутентификации при вызове за пределы домена:
• Клиент С из первого домена, желающий получить доступ к серверу R из второго домена обращается прежде всего к KDS своего домена. Первый KDS возвращает клиенту новую версию его TGT, зашифрованную паролем и ключ сессии для общения с KDS второго домена (это ключ хранится и в новой версии TGT).
• Клиент отправляет KDS второго домена новый TGT, зашифрованный ключом и аутентификатор, зашифрованный ключом сессии клиента и второго KDS.
• Второй KDS расшифровывает TGT и, доверяя первому KDS, возвращает клиенту билет для запрашиваемого сервера из своего домена.