Kerberos в Windows 2000

Станет ли новый основной протокол аутентификации достойным своего статуса?

В древнегреческой мифологии трехглавый пес, охранявший вход в подземное царство, назывался Цербер (Kerberos). В компьютерном мире с этим именем связаны не столь мрачные ассоциации. В IETF RFC 1510 приводится описание базового протокола Kerberos, разработанного в Массачусетском технологическом институте как часть проекта Athena, и рассматриваются аспекты аутентификации пользователя. Microsoft встроила протокола Kerberos в Windows 2000 в качестве протокола аутентификации по умолчанию. В данной статье мы рассмотрим ключевые особенности этой реализации протокола Kerberos.

Основы

Доступ к объектам в протоколе Kerberos

В основе работы протокола Kerberos лежит уникальная технология предоставления доступа к объектам системы, ускоряющая процесс аутентификации, по сравнению с предыдущими версиями NT. В реализации протокола Kerberos предусмотрен безопасный способ передачи по сети сеансового ключа шифрования, в котором содержится основная информация для проведения аутентификации пользователя. В протоколе Kerberos аутентификация основана на шифровании с применением симметричного ключа. Предположим, что Алиса и Боб совместно владеют сеансовым ключом, который они используют в процессе аутентификации. Когда Алиса собирается обратиться к Бобу, она с помощью сеансового ключа шифрует свое имя и текущее время и посылает пакет с закодированной информацией Бобу. (В терминологии Kerberos такой закодированный пакет носит название аутентификатор — authenticator.) Боб использует сеансовый ключ, который известен только ему и Алисе, для расшифровки пакета. Если в результате расшифровки будет восстановлено имя Алисы и соответствующее время, то Боб может быть уверен в том, что только одна Алиса могла отослать ему данный пакет. В протоколе Kerberos для безопасного обмена сеансовым ключом по сети применяются пакеты определенного типа — так называемые «билеты» (ticket).

В реализации протокола Kerberos, выполненной компанией Microsoft, все сеансовые ключи генерируются службой KDC. Эта же служба формирует связанные с ключами билеты и передает их клиенту, а затем и ресурсному серверу через того же клиента. (Ресурсный сервер — это компьютер, к ресурсам которого обращается пользователь.) Билет представляет собой зашифрованную версию сеансового ключа, расшифровать который может только ресурсный сервер и домен-контроллер Windows 2000. KDC рассылает билеты через клиентов, что позволяет произвести запись этой информации в кэш рабочей станции клиента, а в дальнейшем при необходимости многократно использовать. (Клиент хранит билеты в специальной области памяти, содержимое которой никогда не сбрасывается на диск.) Однако билеты имеют ограниченный период восстановления (renewal) и время жизни (lifetime). В течение периода восстановления KDC незаметно для пользователя обновляет билеты. Если же период восстановления истек, пользователю предстоит заново пройти всю последовательность регистрации (logon sequence).

Когда ресурсный сервер получает от клиента билет и аутентификатор, он уже может приступить к процедуре аутентификации. В системе NT 4.0 для того, чтобы подтвердить корректность аутентификации клиента, ресурсному серверу необходимо было связаться с контроллером домена. Благодаря протоколу Kerberos в системе Windows 2000 это уже не требуется. Такой подход ускоряет проведение процесса аутентификации, но при этом приводит к большей загрузке станции клиента.

Доступ к объектам, реализованный в протоколе Kerberos, осуществляется с помощью билетов двух типов: ticket-granting ticket (TGT) и service or resource ticket (SRT). Для выполнения регистрации в домене Windows 2000 пользователь должен задать свой пароль (master key в терминологии Kerberos). Когда регистрация пользователя в домене завершена, служба KDC генерирует TGT и отсылает его данному пользователю. TGT гарантирует безопасность передачи сеансового ключа, который KDC использует для аутентификации. Применение в протоколе Kerberos сеансового ключа и TGT ограничивает возможность успешной аутентификации, если при этом используется только пароль, что снижает вероятность грубого «взлома» пакетов, зашифрованных паролем пользователя. Во время процедуры первой регистрации и каждый раз при обновлении TGT пользователь применяет свой пароль для выполнения аутентификации с KDC. В последующих запросах пользователи уже задействуют сеансовый ключ, содержащийся в TGT, для аутентификации с KDC. Следовательно, если пользователь изменяет свой пароль во время сеанса работы, для получения нового TGT ему придется заново ввести свои атрибуты — идентификатор пользователя и пароль.

Для аутентификации с ресурсным сервером пользователю необходим другой сеансовый ключ. В протоколе Kerberos для безопасной передачи по сети этого сеансового ключа используется тип пакета SRT. Он формируется службой KDC на основе хранящегося в кэше клиента TGT. Когда пользователь «предъявляет» TGT и аутентификатор, служба KDC «знает», что однажды контроллер домена проводил аутентификацию этого пользователя, и она завершилась успешно, поэтому KDC разрешает выдать SRT.

ЭКРАН 1. Использование утилиты Windows 2000 Klist для просмотра билетов Kerberos.

В состав Windows 2000 SDK входит программа Klist, с помощью которой можно просмотреть билеты, размещенные в кэше клиентского компьютера, а также присущие им характеристики (см. Экран 1). Кроме того, можно воспользоваться утилитой Windows 2000 Group Policy Object (GPO) для установки значений время жизни TGT, время жизни SRT и максимальный период обновления, как это изображено на Экране 2. Установки по умолчанию следующие: 30 дней для TGT, 29 дней для SRT и 60 дней для обновления билетов. Значение параметра «время жизни TGT», который пользователь может установить на своем рабочем месте, должно быть больше, чем для параметра «время жизни SRT», а максимальный период обновления должен превышать время жизни как TGT, так и SRT. В том же каталоге, как показано на Экране 2, можно установить максимальный временной интервал, который допускается ресурсным сервером, с момента, когда клиент сформировал билет, до того момента, когда ресурсный сервер его получил. Протокол Kerberos использует временные метки для защиты от многократно повторяющихся попыток вскрытия пакетов, поэтому увеличение значения этого параметра повышает риск подобных атак.

ЭКРАН 2. Установка параметра «время жизни» для билетов Kerberos.

Для систем Windows 2000 корпорация Microsoft включила данные авторизации пользователя в поле данных авторизации, которое присутствует в каждом билете протокола Kerberos. Разработчики Microsoft назвали такое поле Privilege Attribute Certificate (PAC). В Windows 2000 добавлением данных PAC в билеты занимается служба KDC, а формируемые вслед за тем запросы на получение TGT, SRT и запросы на обновление билетов наследуют эту информацию. Вместе с тем KDC сохраняет данные авторизации на время сеанса работы пользователя. Поэтому, например, если принадлежность группам для некоторого пользователя изменилась, ему необходимо выполнить процедуру logoff, а затем logon для того, чтобы KDC сформировала новый билет и передала его пользователю.

Взаимная аутентификация

Для того чтобы установить подлинность клиента, в системах NT 4.0 применяется метод аутентификации по принципу запрос/ответ, в соответствии с которым сервер посылает клиенту запрос, клиент вычисляет ответ, а сервер этот ответ проверяет. Таким образом, в NT 4.0 создаются ситуации, когда пользователь может, не осознавая того, предъявить свои полномочия (учетные сведения безопасности) поддельному серверу. Для того чтобы избежать возникновения подобных ситуаций, в протоколе Kerberos поддерживается взаимная аутентификация: клиент запрашивает подлинность сервера, а сервер должен убедиться в подлинности клиента.

Транзитивные доверительные отношения

Как и в NT 4.0, в доменах Windows 2000 понятие доверительные отношения (trust — ситуация, когда некоторые «секреты» известны контроллерам двух различных доменов), присутствует, что упрощает перекрестный доступ к ресурсам различных доменов. Другое проявление доверительных отношений — возможность совместно использовать базы данных учетных записей пользователей. Разработчики из Microsoft упростили процедуру установления и обслуживания доверительных отношений в доменах Windows 2000. В процессе создания иерархии доменов Windows 2000 все необходимые доверительные отношения и их транзитивность устанавливаются автоматически.

Транзитивность доверительных отношений означает, что если, например, компания europe.company.com и us.company.com доверяют company. com, то и europe.company.com доверяет (неявным образом) компании us.company.com. Транзитивность доверительных отношений сокращает число доверительных связей, необходимых для процедуры аутентификации. Пример того, как транзитивность упрощает процесс аутентификации, приведен во врезке.

Транзитивность доверительных отношений — всего лишь логическая концепция, так как в действительности нет никаких «общих тайн», известных контроллерам доменов, между которыми установлено доверие «по транзитивности». Установление транзитивных доверительных отношений означает, что процесс аутентификации между двумя различными сущностями на противоположных концах транзитивной связи протекает не через всю цепочку выстроенного доверительного маршрута, а через специальный «путь доверия» (trust path) в дереве объектов. Разработчики Microsoft утверждают, что алгоритм аутентификации, реализованный таким образом, не оказывает серьезного влияния на сетевой трафик. Реально формируемый при этом трафик, по данным Microsoft, сопоставим с тем, который генерируется в NT 4.0 во время сквозной (pass-through) аутентификации. Вместе с тем очевидно, что для больших распределенных вычислительных сред, к которым, например, можно отнести Internet, возможностей протокола Kerberos уже недостаточно для аналогичной реализации процесса аутентификации. Kerberos предназначен для аутентификации в сетях intranet.

В Windows 2000 предусмотрено пять базовых типов доверительных отношений, они перечислены в Таблице 1. Можно выяснить характеристики доверительных отношений, обратившись к описанию свойств домена, как это показано на Экране 3, или же посредством утилиты командной строки trustdom.exe. Кроме того, с помощью этой утилиты можно явным образом установить доверительные отношения между доменами. Конечные пользователи, работающие со станций, операционные системы которых поддерживают протокол Kerberos, могут «прочувствовать» наличие транзитивных отношений во время выполнения процесса регистрации. Такие пользователи в качестве регистрирующего домена могут выбрать любой из списка доменов, с которыми их «родной» домен имеет или прямые доверительные отношения, или опосредованные (т. е. транзитивные). Для NT 4.0 конечный пользователь в процессе регистрации «видит» лишь те домены, с которыми были установлены прямые доверительные отношения.

ЭКРАН 3. Просмотр доверительных отношений с помощью свойств объектов домена.

В соответствии с протоколом Windows 2000 Kerberos доверительные отношения, установленные внутри одного и того же леса доменов, явные или неявные — значения не имеет, по умолчанию являются транзитивными. В Windows 2000 beta 2 предусматривалась возможность управления включением/выключением транзитивности в доверительных отношениях. Однако в следующей бета-версии системы, Windows 2000 beta 3, этой возможности уже нет. Явные доверительные отношения, установленные между лесами доменов, или же доверительные отношения в доменах Windows 2000, например в доменах Unix, поддерживающих протокол Kerberos, по умолчанию считаются нетранзитивными. Таким образом, при необходимости провести аутентификацию между двумя доменами, которые принадлежат различным лесам доменов, следует вручную установить между ними доверительные отношения.

Делегирование аутентификации

Используя механизм делегирования аутентификации, пользователь А может предоставить право на проведение аутентификации с сервером приложений С некоторому посреднику — машине В, как если бы за машиной В находился непосредственно сам пользователь А. Установка делегирования означает, что сервер приложений С во время процесса аутентификации будет «принимать решение» о предоставлении или отказ в доступе на основании факта идентичности учетной записи пользователя А, но не на основании учетной записи рабочей станции В. Описанный процесс делегирования аутентификации также известен под названием «продвижение аутентификации» (authentication forwarding). В соответствии с протоколом Kerberos, при выполнении процедуры делегирования пользователь А пересылает билет станции-посреднику В, которая в свою очередь использует билет пользователя А для выполнения процесса аутентификации с сервером приложений С.

Метод делегирования аутентификации можно использовать при обращении к таким многозвенным (multitier) приложениям, как, например, Outlook Web Access (OWA). Для того чтобы воспользоваться услугами OWA, пользователи обращаются к своим почтовым ящикам с помощью браузера. В большинстве случаев сервер Microsoft Exchange Server, который поддерживает работу почтовых ящиков пользователей, не производит обмен информацией с сервером Microsoft Internet Information Server (IIS). Это означает, что IIS должен провести аутентификацию с сервером Exchange, как если бы IIS был обычным пользователем. В сетях NT 4.0 при использовании для аутентификации протокола NT LAN Manager (NTLM) при установлении связи в обе стороны осуществить подобный сценарий без проблем было нелегко. (Напомним, что такой подход соответствует попытке установить связь между браузером и IIS, а также между IIS и сервером Exchange.) Протокол NTLM, как известно, не поддерживает механизм делегирования.

ЭКРАН 4. Установка делегирования для учетной записи пользователя.

Можно установить делегирование как для учетной записи пользователя Windows 2000, так и для учетной записи компьютера с помощью параметра Account is trusted for delegation в диалоговом окне, отображающем свойства учетной записи, как показано на Экране 4. Кроме того можно установить делегирование аутентификации.

Регистрация с помощью кредитной карты

В Windows 2000 реализована поддержка регистрации с помощью кредитных карт (smart card logon), что обеспечивает больший уровень безопасности, нежели аутентификация с помощью пароля. Это происходит из-за того, что регистрация с помощью кредитной карты основывается на двухэтапной аутентификации. Для того чтобы зарегистрироваться в системе, пользователю необходимо иметь саму кредитную карту, а также знать ее персональный идентификационный номер (PIN-код). Кроме того, регистрация с помощью кредитной карты блокирует попытки несанкционированного входа в систему по принципу работы вируса-«троянца», когда программа-взломщик пытается «снять» пароль пользователя непосредственно из памяти системы.

Для того чтобы обеспечить возможность регистрации с помощью кредитной карты, разработчики Windows 2000 реализовали расширение протокола Kerberos, получившее название PKINIT. Во время выполнения последовательности регистрации на базе этого расширения, PKINIT заменяет пароль пользователя содержимым его открытого ключа, которое хранится на кредитной карте.

Для того чтобы воспользоваться возможностью регистрации с помощью кредитной карты, следует установить Windows 2000 Certificate Server, который для своей работы подгружает необходимые сертификационные шаблоны регистрации. Пользователю нужно иметь собственно кредитную карту и устройство считывания. В настоящее время Windows 2000 поддерживает кредитные карты компаний Gemplus и Schlumberger (оба производителя предоставляют свои службы в виде модуля расширения Microsoft CryptoAPI8).

Протокол Kerberos — открытый стандарт

Корпорация Microsoft разработала свою реализацию протокола Kerberos на основе открытого стандарта RFC 1510 (т. е. версии Kerberos V5), а это означает, что протокол Kerberos может обеспечить межсетевую аутентификацию между Windows 2000 и другими операционными системами, которые также отвечают требованиям стандарта RFC 1510.

Межсетевая аутентификация по протоколу Kerberos может проявляться по-разному. Сервер Windows 2000 может выступать в роли хоста Kerberos, KDC, и в этой роли обслуживать клиентов сети, которыми могут быть как клиенты Windows 2000, так и компьютеры на базе других платформ. С другой стороны, в роли хоста KDC могут выступать серверы с операционной системой, отличной от Windows 2000, и обслуживать запросы клиентов, которыми могут быть как клиенты Windows 2000, так и станции других типов. И, наконец, можно создать межплатформенные доверительные отношения между доменом Windows 2000 и доменом на базе другой операционной платформы для осуществления межсетевой аутентификации. В этом случае вы имеете два центра KDC — по одному с каждого конца доверительной связи.

ЭКРАН 5. Установление соответствия доверительных отношений между учетными записями Windows 2000 и Unix.

Реализация межсетевой аутентификации представляет собой достаточно сложный процесс, он требует от администраторов систем дополнительных усилий. Например, для того чтобы организовать межплатформенные доверительные отношения для проведения межсетевой аутентификации между платформами Windows 2000 и Unix, нужно описать точные соответствия между каждой учетной записью Unix, которой необходим доступ к ресурсам домена Windows 2000, и учетной записью Windows 2000, как это показано на Экране 5. Нужно установить соответствие для каждой учетной записи Unix, поскольку названия учетных записей Unix в протоколе Kerberos для домена Windows 2000 ровным счетом ничего не значат. В среде Windows 2000 для отождествления учетных записей используются так называемые идентификаторы безопасности — SID. В диалоговом окне Security Identity Mapping показаны подобные соответствия, которые являются частью дополнительных свойств объекта User.

Остается добавить, что компании, расположенные за пределами США, должны учитывать экспортное законодательство США при планировании межсетевой аутентификации. Эти законы запрещают экспорт программного обеспечения, в котором задействованы ключи шифрования длиною более 56 разрядов. Стандарт MIT Kerberos V5, доступный через Web-узлы в США для Unix-платформ, использует ключ шифрования длиной 128 разрядов и экспорту не подлежит. Протокол Windows 2000 Kerberos может применяться внутри Соединенных Штатов в не экспортируемом варианте с ключом 128 разрядов и для всего остального мира (экспортный вариант) с длиной ключа 56 разрядов. Выяснить, какая именно версия Windows 2000 установлена на конкретной системе можно, обратившись к свойствам следующих системных файлов: schannel.dll, rsabase.dll, или ndiswan.sys.

Кроме того, хотя разработчики Microsoft реализовали протокол Kerberos как модуль расширения Security Support Provider Interface (SSPI), тем не менее протокол Kerberos поддерживает формат GSS_API, описанный в RFC 1964. И как следствие, Unix-приложения, поддерживающие GSS_API, и приложения Windows 2000 могут сообща использовать протокол Kerberos для аутентификации.

Что дальше

Microsoft, реализовав протокол Kerberos, расширила в системе Windows 2000 возможности процесса аутентификации. Протокол Kerberos в своей основе использует симметричное шифрование, что позволяет применять его в локальных сетях и сетях intranet в качестве протокола аутентификации. Вместе с тем добавление компонента PKINIT можно рассматривать как первый шаг на пути расширения функциональности процесса аутентификации, выполняемого на базе протокола Kerberos с использованием открытого ключа, что расширяет сферу применения самого Kerberos.

ОБ АВТОРЕ

Подробнее о транзитивных доверительных отношениях Kerberos

Предположим, Алиса зарегистрировалась в north.eu108.corp108. com со своим бюджетом, но при этом ей нужно получить доступ к ресурсу на сервере east.na108.corp108.com. Далее, шаг за шагом будет показано, как протекает процесс аутентификации по правилам работы протокола Kerberos в дереве, содержащем пять доменов.

1. Алиса использует свой TGT для того, чтобы попытаться получить билет с KDC1 для доступа к ресурсам на сервере в домене east. KDC1 не уполномочен обслуживать домен east, в котором расположен сервер, и поэтому отсылает Алису в домен, наиболее близкий к домену east, и с которым у домена north имеются доверительные отношения по протоколу Kerberos. Предположим, это домен eu108.

2. KDC2 отсылает Алису к KDC3

3. KDC3 отсылает Алису к KDC4

4. KDC4 отсылает Алису к KDC5

5. KDC5 уполномочен обслуживать домен east, поэтому KDC5 генерирует билет для Алисы.

6. Алиса использует полученный билет для доступа к ресурсному серверу.

С помощью утилиты Klist, входящей в состав Windows 2000 Software Development Kit (SDK), можно просмотреть все билеты, находящиеся в кэше станции Алисы. Вы обнаружите один TGT для каждого домена, один билет для учетной записи рабочей станции Алисы (принадлежащей домену north), а также один билет для сервера ресурсов.

Длину описанного маршрута можно сократить с помощью явного задания доверительных отношений (тип отношений shortcut-trust) между доменами north и east. В этом случае последовательность шагов, необходимая для реализации доступа Алисы к ресурсам сервера в домене east, изменится:

1. Алиса использует свой TGT для того, чтобы попытаться получить билет с KDC1 для доступа к ресурсам на сервере в домене east. KDC1 не уполномочен обслуживать этот домен, где расположен сервер ресурсов, и поэтому отсылает Алису в домен, который наиболее близок к домену east, и с которым у домена north имеются доверительные отношения по протоколу Kerberos.

2. KDC5 уполномочен обслуживать домен east, поэтому KDC5 генерирует билет для Алисы.

3. Алиса использует полученный билет для доступа к серверу ресурсов.

Если после этой последовательности шагов заглянуть в кэш рабочей станции Алисы, то удастся обнаружить лишь четыре билета: один TGT для домена north, один TGT для домена east, один билет для учетной записи рабочей станции Алисы и один билет для сервера ресурсов. Установление отношения shortcut-trust привело к снижению междоменного трафика и уменьшило число билетов, которые необходимо передать пользователю.