введение

Настоящий документ представляет технические аспекты реализации протокола аутентификации Kerberos 5 в операционной системе Microsoft® Windows® 2000. Здесь приводится подробное описание некоторых наиболее важных концепций, архитектурных элементов, а также функций аутентификации по протоколу Kerberos. Первый раздел «Обзор протокола Kerberos» рассчитан на тех, кто не знаком с аутентификацией по этому протоколу. Несколько последующих разделов посвящено более подробному описанию того, как Microsoft реализовала Kerberos в своей операционной системе Windows 2000. Завершается информационный документ кратким обсуждением вопросов взаимодействия описываемого протокола с другими его реализациями.

Аутентификация в Windows 2000

Windows 2000 поддерживает несколько протоколов, которые помогают убедиться, что входящий в систему пользователь в самом деле имеет здесь свою учетную запись. Среди них – протоколы аутентификации удаленных подключений и протоколы аутентификации пользователей, входящих в сеть через Интернет. Однако внутри доменов Windows 2000 для проверки пользовательских данных предусмотрено всего два метода:

· Kerberos версия 5. Протокол Kerberos 5 является стандартным средством аутентификации сетевых пользователей на всех компьютерах с операционной системой Windows 2000.

· Windows NT LAN Manager (NTLM). Протокол NTLM применялся в качестве стандартного средства сетевой аутентификации в операционной системе Windows NT® 4.0. В среде Windows 2000 он используется для аутентификации серверов и доменов Windows NT 4.0. Кроме того, NTLM применяется для аутентификации на автономных компьютерах, работающих под управлением Windows 2000.

Компьютеры под управлением Windows 3.11, Windows 95, Windows 98 и Windows NT 4.0 смогут использовать протокол NTLM для сетевой аутентификации в доменах Windows 2000. Компьютерам же, работающим под управлением Windows 2000, этот протокол обеспечит аутентификацию на серверах Windows NT 4.0 и откроет доступ к ресурсам доменов Windows NT 4.0. Однако в тех случаях, когда есть выбор, в среде Windows 2000 по умолчанию будет использоваться протокол Kerberos 5.

Преимущества аутентификации по протоколу Kerberos

Протокол Kerberos выгодно отличается от NTLM большей гибкостью и эффективностью использования. Обеспечивает он и повышенный уровень безопасности. Ряд преимуществ, которые дает переход на Kerberos, приводится ниже.

· Более эффективная аутентификация на серверах. При аутентификации по протоколу NTLM серверу приложений приходится подключаться к контроллеру домена при проверке каждого клиента. С Kerberos такая необходимость отпадает – здесь аутентификация производится за счет проверки удостоверения, представленного клиентом. Индивидуальное удостоверение клиент получает от конкретного сервера единожды, после чего может неоднократно использовать его на протяжении всего сеанса работы в сети.

· Взаимная аутентификация. Протокол NTLM позволяет серверу идентифицировать своих клиентов, однако не предусматривает верификации сервера ни клиентами, ни другими серверами. Этот протокол разрабатывался для сетей, в которых все серверы считаются легитимными. В отличие от него Kerberos такого допущения не делает, поэтому проверяет обоих участников сетевого подключения, каждый из которых в результате может точно узнать, с кем поддерживает связь.

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

· Упрощенное управление доверительными отношениями. Одно из важных достоинств взаимной аутентификации по протоколу Kerberos состоит в том, что доверительные отношения между абонентами безопасности (security authority) доменов Windows 2000 по умолчанию являются двусторонними и переходными. Благодаря этому в сетях со множеством доменов больше не придется плести сложную паутину явно выраженных доверительных отношений между каждой парой доменов. Вместо этого все домены большой сети можно свести в дерево переходных отношений взаимного доверия. Удостоверение, выданное системой безопасности для любого домена, может приниматься во всех ветвях дерева. Если же сеть содержит несколько деревьев, то удостоверение любого из них будет приниматься по всему «лесу».

· Совместимость. В основу своей реализации протокола Kerberos корпорация Microsoft положила стандартные спецификации, рекомендованные группой IETF. Благодаря такому подходу удалось обеспечить аутентификацию клиентов Windows 2000 во всех сетях, которые поддерживают Kerberos 5.

Стандарты аутентификации по протоколу Kerberos

Протокол Kerberos впервые увидел свет десять с лишним лет назад, создан он был в Массачусетском технологическом институте в рамках проекта Athena[1]. Однако общедоступным этот протокол стал лишь после появления версии 4. После того, как специалисты отрасли изучили новый протокол, его авторы разработали и предложили пользователям очередную версию – Kerberos 5, которая и была принята в качестве стандарта IETF. Реализация протокола в Windows 2000 выполнена в строгом соответствии с требованиями, изложенными в документе RFC 1510[2]. Кроме того, при ее разработке были использованы механизм и формат передачи жетонов безопасности в сообщениях Kerberos, описанные в спецификациях Интернета из документа RFC 1964[3].

Расширения протокола Kerberos

В Windows 2000 нашли применение расширения протокола Kerberos, упрощающие начальную аутентификацию клиентов. Обычно для этой цели используются секретные ключи, которыми должны заранее обменяться между собой участники сеанса, но теперь такую процедуру можно провести с помощью открытых ключей. Благодаря этому появилась возможность интерактивной регистрации пользователя с помощью микропроцессорных карточек. В основу расширений, обеспечивающих аутентификацию с открытым ключом, положен проект спецификации, который сейчас рассматривается в рабочей группе IETF. Он внесен рядом независимых разработчиков, заинтересованных в развитии технологий шифрования с открытым ключом[4]. Корпорация Microsoft также принимает участие в рассмотрении этого стандарта и впредь намерена поддерживать работы в данном направлении.

обзор протокола Kerberos

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

Основные концепции

Протокол Kerberos активно использует технологии аутентификации, опирающиеся на «секреты для двоих». Основная концепция довольно проста: если есть секрет, известный только двоим, любой из его хранителей может легко удостовериться, что имеет дело именно со своим напарником. Для этого ему достаточно каким-либо способом проверить, знает ли собеседник их общий секрет.

Рассмотрим это на простом примере. Допустим, Алиса часто посылает сообщения Бобу, который использует содержащуюся в них информацию только тогда, когда полностью уверен, что она поступила именно от Алисы. Чтобы никто другой не смог подделать письма, они договорились о пароле, который пообещали никому больше не говорить. Если из сообщения можно будет заключить, что отправитель знает этот пароль, Боб может точно сказать: оно пришло от Алисы.

Теперь Бобу и Алисе остается только решить, каким образом показать свое знание пароля. Можно, скажем, просто включить его в текст сообщения, например, после подписи: «Alice, Our$ecret». Это было бы очень просто, удобно и надежно, если бы Алиса и Боб были уверены, что никто другой не читает их сообщений. К сожалению, об этом можно только мечтать. Почта передается по сети, где работают и другие пользователи. А среди них есть Кэрол, которая очень любит подключать к сети свой анализатор пакетов в надежде выведать чьи-нибудь секреты. И становится совершенно ясно, что Алиса не может просто назвать пароль в тексте письма. Чтобы секрет оставался секретом, о нем нельзя говорить открыто, нужно найти способ только дать знать собеседнику, что он тебе известен.

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

Аутентификаторы

Простой протокол аутентификации с секретным ключом вступает в действие, когда кто-либо стучится в сетевую дверь и просит впустить его. Чтобы доказать свое право на вход, пользователь предъявляет аутентификатор (authenticator) в виде блока информации, зашифрованного с помощью секретного ключа. Содержание этого блока должно меняться при каждом последующем сеансе, в противном случае злоумышленник вполне может проникнуть в систему, воспользовавшись перехваченным сообщением. Получив аутентификатор, привратник расшифровывает его и проверяет полученную информацию, чтобы убедиться в успешности дешифрования. Если все прошло нормально, страж может быть уверен, что человеку, предъявившему аутентификатор, известен секретный ключ. А ведь этот ключ знают всего двое, причем один из них – сам привратник. Таким образом, можно он делает вывод, что пришелец в самом деле тот человек, за которого себя выдает.

Но может случиться и так, что постучавшийся в дверь захочет провести взаимную аутентификацию. В этом случае используется тот же самый протокол, но в обратном порядке и с некоторыми изменениями. Теперь привратник извлекает из исходного аутентификатора часть информации, а затем шифрует ее, превращая в новый аутентификатор, и в таком виде возвращает пришельцу. Тот, в свою очередь, расшифровывает полученную информацию и сравнивает ее с исходной. Если все совпадает, пришелец может быть уверен: если привратник дешифровал оригинал, значит, он знает секретный ключ.

А теперь вернемся к нашему примеру. Предположим, Алиса и Боб договорились: перед тем, как пересылать информацию между своими компьютерами, они с помощью известного только им двоим секретного ключа будут проверять, кто находится на другом конце линии. В ситуации, когда Алиса играет роль осторожного гостя, а Боб – бдительного привратника, это будет выглядеть так.

1. Алиса посылает Бобу сообщение, содержащее ее имя в открытом виде и аутентификатор, зашифрованный с помощью секретного ключа, известного только им двоим. В протоколе аутентификации такое сообщение представляет собой структуру данных с двумя полями. Первое поле содержит информацию об Алисе, так сказать, ее имя. Во втором поле указывается текущее время на рабочей станции Алисы.

2. Боб получает сообщение и видит, что оно пришло от кого-то, кто называет себя Алисой. Он сразу же достает ключ, которым они с Алисой договорились шифровать аутентификатор, и, дешифровав второе поле, узнает время отправки сообщения.

Задача Боба намного упрощается, если его компьютер работает синхронно с компьютером Алисы, поэтому давайте предположим, что оба они сверяют свои часы с сетевым временем, благодаря чему те идут практически одинаково. Допустим, часы на компьютерах Алисы и Боба никогда не расходятся больше, чем на пять минут. В этом случае Боб может сравнить извлеченное из второго поля аутентификатора значение с текущим временем на своих часах. Если различие составит более пяти минут, компьютер автоматически откажется признавать подлинность аутентификатора.

Если же время оказывается в пределах допустимого отклонения, можно с большой долей уверенности предположить, что аутентификатор поступил именно от Алисы. Но Бобу этого мало, ему нужна полная уверенность. Ведь, рассуждает он, может быть и так: кто-то перехватил предыдущую попытку Алисы связаться со мной и теперь пытается воспользоваться ее аутентификатором. Впрочем, если на компьютере сохранились записи о времени аутентификаторов, поступивших от Алисы за последние пять минут, Боб может найти последний и отказаться от всех других сообщений, отправленных одновременно с ним или ранее. Но если второе поле свидетельствует, что сообщение ушло в сеть уже после отправки последнего аутентификатора Алисы, то и его автором вполне могла быть Алиса.

3. Боб шифрует время из сообщения Алисы с помощью их общего ключа и включает его в собственное сообщение, которое направляет Алисе.

Обратите внимание, что Боб возвращает Алисе не всю информацию из ее аутентификатора, а только время. Если бы он отправил все сразу, у Алисы закралось бы подозрение, что кто-то, решив притвориться Бобом, просто скопировал аутентификатор из ее исходного сообщения и без каких-либо изменений отправил его назад. Но в полученном письме содержится только часть информации, а это значит, что получатель исходного аутентификатора смог дешифровать его и обработать содержащуюся там информацию. А время он выбрал потому, что это поле является уникальным идентификатором сообщения Алисы.

Алиса получает ответ Боба, дешифрует его, а затем сравнивает полученный результат со временем, которое было указано в исходном аутентификаторе. Если эти данные совпадают, она может быть уверена, что ее аутентификатор дошел до того, кто знает их с Бобом секретный ключ. Этот человек смог расшифровать сообщение и извлечь из него информацию о времени. Поскольку ни она, ни Боб никому свой ключ не передавали, Алиса делает вывод, что именно Боб получил ее аутентификатор и ответил на него.

Рис. 1. Взаимная аутентификация (Алиса-Боб)

Управление ключами

При использовании простых протоколов наподобие описанного выше возникает одна очень важная проблема. В случае с Алисой и Бобом мы ни слова не сказали о том, как и где они договаривались о секретном ключе для своей переписки. Конечно, люди могут просто встретиться в парке и обсудить все детали, но ведь в сетевых переговорах участвуют машины. Если под Алисой понимать клиентскую программу, установленную на рабочей станции, а под Бобом – службу на сетевом сервере, то встретиться они никак не могут. Проблема еще более осложняется в тех случаях, когда Алисе – клиенту – нужно посылать сообщения на несколько серверов, ведь для каждого из них придется обзавестись отдельным ключом. Да и службе по имени Боб потребуется столько секретных ключей, сколько у нее клиентов. Но если каждому клиенту для поддержания связи с каждой службой требуется индивидуальный ключ, и такой же ключ нужен каждой службе для каждого клиента, то проблема обмена ключами очень быстро приобретает предельную остроту. Необходимость хранения и защиты такого множества ключей на огромном количестве компьютеров создает невероятный риск для всей системы безопасности.

Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Кербер (или Цербер) – персонаж классической греческой мифологии. Этот свирепый пес о трех головах, по поверьям греков, охраняет врата подземного царства мертвых. Трем головам Кербера в протоколе Kerberos соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет так называемый центр распределения ключей Key Distribution Center или, сокращенно, KDC.

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

Когда клиенту нужно обратиться к серверу, он прежде всего направляет запрос в центр KDC, который в ответ направляет каждому участнику предстоящего сеанса копии уникального сеансового ключа (session key), действующие в течение короткого времени. Назначение этих ключей – проведение аутентификации клиента и сервера. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера, а направляемая клиенту – долговременного ключа данного клиента.

Рис. 2. Управление ключами (в теории)

Теоретически, для выполнения функций доверенного посредника центру KDC достаточно направить сеансовые ключи непосредственно абонентам безопасности, как показано выше. Однако на практике реализовать такую схему чрезвычайно сложно. Прежде всего, серверу пришлось бы сохранять свою копию сеансового ключа в памяти до тех пор, пока клиент не свяжется с ним. А ведь сервер обслуживает не одного клиента, поэтому ему нужно хранить пароли всех клиентов, которые могут потребовать его внимания. В таких условиях управление ключами требует значительной затраты серверных ресурсов, что ограничивает масштабируемость системы. Нельзя забывать и о превратностях сетевого трафика. Они могут привести к тому, что запрос от клиента, уже получившего сеансовый пароль, поступит на сервер раньше, чем сообщение KDC с этим паролем. В результате серверу придется повременить с ответом до тех пор, пока он не получит свою копию сеансового пароля. То есть, нужно будет сохранить состояния сервера, а это накладывает на его ресурсы еще одно тяжкое бремя. Поэтому на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным. Ее описание приводится ниже.

Сеансовые мандаты

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

Рис. 3. Управление ключами (на практике)

Обратите внимание, что в данном случае функции службы KDC ограничиваются генерацией мандата. Ей больше не нужно следить за тем, все ли отправленные сообщения доставлены соответствующим адресатам. Даже если какое-нибудь из них попадет не туда, – ничего страшного не случится. Расшифровать клиентскую копию сеансового ключа может только тот, кто знает секретный долговременный ключ данного клиента, а чтобы прочесть содержимое сеансового мандата, нужен секретный код сервера.

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

Рис. 4. Взаимная аутентификация (клиент-сервер)

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

Одно из достоинств применения сеансовых мандатов состоит в том, что серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений (credentials cache) клиента, который направляет мандат на сервер каждый раз, когда хочет связаться с ним. Сервер, со своей стороны, получив от клиента мандат, дешифрует его и извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может просто стереть его из своей памяти.

Такой метод дает и еще одно преимущество: у клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые мандаты можно использовать многократно. На случай же их хищения устанавливается срок годности мандата, который KDC указывает в самой структуре данных. Это время определяется политикой Kerberos для конкретного домена. Обычно срок годности мандатов не превышает восьми часов, то есть, стандартной продолжительности одного сеанса работы в сети. Когда пользователь отключается от нее, кэш-память удостоверений обнуляется и все сеансовые мандаты вместе с сеансовыми ключами уничтожаются.

Мандаты на выдачу мандатов

Как уже отмечалось, долговременный ключ пользователя генерируется на основе его пароля. Чтобы лучше понять это, вернемся к нашему примеру. Когда Алиса проходит регистрацию, клиент Kerberos, установленный на ее рабочей станции, пропускает указанный пользователем пароль через функцию одностороннего хеширования (все реализации протокола Kerberos 5 должны обязательно поддерживать алгоритм DES-CBC-MD5, хотя могут применяться и другие алгоритмы). В результате генерируется криптографический ключ.

В центре KDC долговременные ключи Алисы хранятся в базе данных с учетными записями пользователей. Получив запрос от клиента Kerberos, установленного на рабочей станции Алисы, KDC обращается в свою базу данных, находит в ней учетную запись нужного пользователя и извлекает из соответствующего ее поля долговременный ключ Алисы.

Такой процесс – вычисление одной копии ключа по паролю и извлечение другой его копии из базы данных – выполняется всего лишь один раз за сеанс, когда пользователь входит в сеть впервые. Сразу же после получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos рабочей станции запрашивает сеансовый мандат и сеансовый ключ, которые используются во всех последующих транзакциях с KDC на протяжении текущего сеанса работы в сети.

На запрос пользователя KDC отвечает специальным сеансовым мандатом для самого себя, так называемый мандат на выдачу мандатов (ticket-granting ticket), или мандат TGT. Как и обычный сеансовый мандат, мандат TGT содержит копию сеансового ключа для связи службы (в данном случае – центра KDC) с клиентом. В сообщение с мандатом TGT также включается копия сеансового ключа, с помощью которой клиент может связаться с KDC. Мандат TGT шифруется посредством долговременного ключа службы KDC, а клиентская копия сеансового ключа – с помощью долговременного ключа пользователя.

Получив ответ службы KDC на свой первоначальный запрос, клиент дешифрует свою копию сеансового ключа, используя для этого копию долговременного ключа пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится: вся последующая связь с KDC будет шифроваться с помощью полученного сеансового ключа. Как и все другие сеансовые ключи, он имеет временный характер и действителен до истечения срока действия мандата TGT, либо до выхода пользователя из системы. По этой причине такой ключ называют сеансовым ключом регистрации (logon session key).

С точки зрения клиента мандат TGT почти ничем не отличается от обычного. Перед подключением к любой службе, клиент прежде всего обращается в кэш-память удостоверений и достает оттуда сеансовый мандат нужной службы. Если его нет, он начинает искать в этой же кэш-памяти мандат TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор, который вместе с мандатом TGT высылает в центр KDC. Одновременно туда направляется запрос на сеансовый мандат для требуемой службы. Другими словами, организация безопасного доступа к KDC ничем не отличается от организации такого доступа к любой другой службе домена – она требует сеансового ключа, аутентификатора и мандата (в данном случае мандата TGT).

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

Аутентификация за пределами домена

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

Чтобы лучше понять принцип междоменной аутентификации, рассмотрим для начала простейшую сеть, содержащую всего два домена – «Восток» и «Запад». Предположим, что администраторы этих доменов являются сотрудниками одной организации или у них есть какие-либо другие веские причины уравнять пользователей второго домена со своими собственными. В любом из этих случаев наладить аутентификацию между доменами нетрудно, для этого достаточно договориться о едином междоменном ключе (в Windows 2000 такой ключ генерируется автоматически, когда между доменами устанавливаются доверительные отношения). Как только ключ создан, служба выдачи мандатов каждого домена регистрируется в центре KDC другого домена в качестве главного абонента безопасности. В результате служба выдачи мандатов каждого из доменов начинает рассматривать службу выдачи мандатов второго домена, как еще одну службу, мало чем отличающуюся от других. Благодаря этому клиент, прошедший аутентификацию и зарегистрировавшийся в системе, может запрашивать и получать сеансовые мандаты для нее.

А теперь рассмотрим, что происходит, когда пользователь с учетной записью в домене «Восток» запрашивает доступ к серверу из домена «Запад». Прежде всего клиент Kerberos, установленный на рабочей станции этого пользователя, посылает запрос в службу выдачи мандатов своего домена, в котором просит выдать сеансовый мандат для доступа на нужный сервер. Служба выдачи мандатов домена «Восток» проверяет список своих абонентов безопасности и убеждается, что такого сервера среди них нет. Поэтому она направляет клиенту так называемый мандат переадресации (referral ticket), который представляет собой простой мандат TGT, зашифрованный с помощью междоменного ключа, общего для служб KDC доменов «Восток» и «Запад». Получив мандат переадресации, клиент использует его для подготовки другого запроса на сеансовый ключ. Однако на этот раз запрос пересылается в службу выдачи мандатов того домена, где находится учетная запись нужного сервера, то есть, домена «Запад». Его служба выдачи мандатов пытается расшифровать мандат переадресации с помощью собственной копии междоменного ключа. Если попытка удается, центр KDC направляет клиенту сеансовый мандат на доступ к соответствующему серверу своего домена.

Процесс переадресации запроса значительно усложняется в сетях, где развернуто более двух доменов. Теоретически служба KDC каждого домена может установить непосредственную связь с аналогичными службами всех доменов сети, договорившись с каждой из них об индивидуальном междоменном ключе. Однако на практике количество и сложность подобных взаимосвязей очень быстро возрастают до такой степени, что становятся просто неуправляемыми, особенно в сложных сетях. Протокол Kerberos решает эту проблему, делая ненужными прямые связи между доменами. Клиент одного домена может получить мандат на доступ к серверу другого домена через один или несколько промежуточных серверов, каждый из которых выдаст ему мандат переадресации.

В качестве примера рассмотрим сеть, состоящую из трех доменов: «Восток», «Запад» и «ШтабКвартира». В службе KDC домена «Восток» нет междоменного ключа для аналогичной службы домена «Запад», но центры распределения ключей обоих доменов наладили обмен мандатами с доменом «ШтабКвартира». Когда пользователь с учетной записью в домене «Восток» хочет подключиться к серверу домена «Запад», его запрос будет передресован дважды. Сначала он пройдет через службу KDC «родного» домена, затем – через промежуточный домен «ШтабКвартира» и, наконец, достигнет центра распределения ключей домена «Запад», которому известен ключ нужного сервера. Таким образом, клиент здесь посылает сеансовые мандаты трижды в три различные службы KDC.

1. Клиент запрашивает у службы KDC домена «Восток» мандат на доступ к серверу домена «Запад».

Служба KDC домена «Восток» направляет клиенту мандат переадресации в службу KDC домена «ШтабКвартира», зашифрованный междоменным ключом, общим для доменов «Восток» и «ШтабКвартира».

2. Клиент обращается в службу KDC домена «ШтабКвартира» с просьбой о мандате на доступ к серверу домена «Запад».

Служба KDC домена «ШтабКвартира» направляет клиенту мандат переадресации в службу KDC домена «Запад», зашифрованный междоменным ключом, общим для доменов «ШтабКвартира» и «Запад».

3. Клиент обращается в службу KDC домена «Запад» с просьбой о мандате на доступ к серверу домена «Запад».

Служба KDC домена «Запад» направляет клиенту мандат на доступ к нужному серверу.

Подпротоколы

Протокол Kerberos содержит в себе три подпротокола. Первый из них используется службой KDC для передачи клиенту сеансового ключа регистрации и мандата TGT. Он называется Authentication Service Exchange (обмен между службами аутентификации) или, сокращенно AS Exchange. Второй подпротокол под названием Ticket-Granting Service Exchange (обмен между службами выдачи мандатов) или TGS Exchange служит для рассылки служебных сеансовых ключей и сеансовых ключей самой службы KDC. Третий подпротокол, Client/Server Exchange (клиент-серверный обмен) или CS Exchange, используется клиентом для пересылки сеансового мандата доступа к службам.

Чтобы лучше разобраться в том, как эти подпротоколы взаимодействуют между собой, давайте посмотрим, что происходит, когда Алиса, пользователь рабочей станции, обращается к Бобу, сетевой службе.

Подпротокол AS Exchange

Прежде всего Алиса входит в сеть, для чего вводит свое пользовательское имя и пароль. Клиент Kerberos, установленный на ее рабочей станции, преобразует пароль в криптографический ключ и сохраняет полученный результат в кэш-памяти удостоверений.

После этого клиент посылает в службу аутентификации центра KDC запрос KRB_AS_REQ (Kerberos Authentication Service Request – запрос к службе аутентификации Kerberos). Первая часть его сообщения содержит идентификатор пользователя, то есть Алисы, а также имя службы, для которой ей нужно удостоверение, то есть службы выдачи мандатов. Во второй же части указываются данные предварительной аутентификации (pre-authentication data), которые подтверждают, что Алиса знает пароль. Обычно в качестве таких данных используется метка времени, зашифрованная долговременным ключом Алисы, хотя Kerberos допускает и другие виды предаутентификационных данных.

Рис. 5. Подпротокол AS Exchange

Получив запрос KRB_AS_REQ, служба KDC обращается в свою базу данных и находит в ней долговременный ключ Алисы, после чего расшифровывает данные предварительной аутентификации и оценивает метку времени, содержащуюся в них. Если проверка прошла успешно, служба KDC делает вывод, что данные предварительной аутентификации были зашифрованы долговременным ключом Алисы и, следовательно, поступили от клиента, имя которого содержится в первой части сообщения.

После того, как проверка личности Алисы завершена, служба KDC генерирует удостоверение, подтверждающее, что клиент Kerberos на ее рабочей станции имеет право обратиться к службе выдачи мандатов. Этот процесс выполняется в два этапа. Во-первых, KDC создает сеансовый ключ регистрации и шифрует его копию с помощью долговременного ключа Алисы. Во-вторых, служба включает еще одну копию сеансового ключа регистрации в мандат TGT. Туда же заносятся и другая информация об Алисе, например, ее данные авторизации. Затем KDC шифрует мандат TGT собственным долговременным ключом и, наконец, включает шифрованный сеансовый ключ регистрации вместе с мандатом TGT в пакет KRB_AS_REP (Kerberos Authentication Service Reply – ответ службы аутентификации Kerberos), который направляет клиенту.

Получив такое сообщение, клиент вновь генерирует ключ на основе пароля Алисы, расшифровывает с его помощью сеансовый ключ регистрации и сохраняет его в кэш-памяти удостоверений. После этого из сообщения извлекается мандат TGT, который также помещается в эту кэш-память.

Подпротокол TGS Exchange

Клиент Kerberos, установленный на рабочей станции Алисы, запрашивает удостоверение на доступ к службе Боб, для чего посылает в службу KDC сообщение KRB_TGS_REQ (Kerberos Ticket-Granting Service Request – запрос к службе выдачи мандатов Kerberos). В него включается имя пользователя, аутентификатор, зашифрованный с помощью сеансового ключа регистрации Алисы, мандат TGT, который был получен с помощью подпротокола AS Exchange, а также имя службы, на доступ к которой нужен мандат.

Рис. 6. Подпротокол TGS Exchange

Получив запрос KRB_TGS_REQ, служба KDC с помощью собственного секретного ключа дешифрует мандат TGT и извлекает из него сеансовый ключ регистрации Алисы, который тут же использует для расшифровки аутентификатора. Если содержимое аутентификатора выдерживает проверку, служба KDC извлекает из мандата TGT регистрационные данные Алисы и на их основе генерирует сеансовый ключ, общий для клиента Алисы и службы Боб. Одну копию этого ключа KDC шифрует с помощью сеансового ключа регистрации Алисы, а другую вместе с данными авторизации Алисы помещает в мандат, который шифрует с помощью долговременного ключа Боба. После этого удостоверение Алисы включается в пакет KRB_TGS_REP (Kerberos Ticket-Granting Service Reply – ответ службы выдачи мандатов Kerberos) и направляется на ее рабочую станцию.

Получив такое сообщение, клиент с помощью сеансового ключа регистрации Алисы расшифровывает сеансовый ключ доступа к службе и помещает его в кэш-память удостоверений. После этого клиент извлекает мандат на доступ к службе и сохраняет его в той же кэш-памяти.

Подпротокол CS Exchange

Клиент Kerberos, установленный на рабочей станции Алисы, обращается к службе Боб, для чего посылает на нее запрос KRB_AP_REQ (Kerberos Application Request – запрос приложения Kerberos). Это сообщение содержит аутентификатор Алисы, зашифрованный посредством сеансового ключа для службы Боб, мандат, полученный с помощью протокола TGS Exchange, а также флаг, указывающий о желании клиента провести взаимную аутентификацию (наличие или отсутствие этого флага определяется конфигурацией Kerberos; он устанавливается автоматически без запроса пользователя).

Рис. 7. Подпротокол CS Exchange

Получив сообщение KRB_AP_REQ, служба Боб дешифрует мандат, извлекает из него данные авторизации Алисы и сеансовый ключ, с помощью которого сразу же расшифровывает аутентификатор Алисы. Если метка времени, заложенная в него, выдерживает проверку, Боб ищет в запросе флаг взаимной аутентификации. Найдя его, Боб шифрует метку времени из аутентификатора Алисы сеансовым ключом, включает полученный результат в пакет KRB_AP_REP (Kerberos Application Reply – ответ приложения Kerberos) и возвращает его на рабочую станцию Алисы.

После получения пакета клиент рабочей станции Алисы дешифрует аутентификатор Боба, используя для этого сеансовый ключ, и сравнивает полученную метку времени с исходной. Если они совпадают, делается вывод, что связь установлена с нужной службой и можно приступать к обмену информацией. В ходе сеанса прикладные данные шифруются, как правило, с помощью сеансового ключа, но не обязательно – клиент и сервер могут воспользоваться в этих целях и другими ключами.

Мандаты

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

Что такое мандат

Для целей настоящего информационного документа достаточно перечислить поля мандата и описать содержащуюся в них информацию. Более подробно структура мандата и различных сообщений Kerberos описана в документе RFC 1510.

Таблица 1. Поля мандата

Название поля		Описание
Первые три поля мандата не шифруются. Содержащаяся здесь информация пересылается открытым текстом, что позволяет клиенту использовать ее для управления мандатами, хранящимися в кэш-памяти.
tkt-vno		Номер версии формата мандата. Для Kerberos 5 здесь указывается цифра 5.
Realm		Имя области (домена), где генерирован мандат. Служба KDC может создавать мандаты только для серверов собственной области, поэтому здесь, по существу, указывается имя области, где расположен сервер.
Sname		Имя сервера.
Остальные поля шифруются с помощью секретного ключа сервера.
Flags	Флаги мандата.
Key	Сеансовый ключ.
Crealm	Имя области (домена) клиента.
Cname	Имя клиента.
Transited	Список областей Kerberos, принимавших участие в аутентификации клиента, которому выдан данный мандат.
Authtime	Время первоначальной аутентификации клиента. Служба KDC заполняет это поле в момент генерации мандата TGT. При генерации мандатов на основе мандата TGT временная метка из поля authtime мандата TGT копируется в поле authtime генерируемого мандата.
Starttime	Время вступления мандата в силу.
Endtime	Время истечения срока действия мандата.
renew-till	Наибольшее значение поля endtime, которое может быть задано с помощью флага RENEWABLE (поле необязательное).
Caddr	Один или несколько адресов, из которых может использоваться данный мандат. Поле необязательное. Если оно не заполнено, мандатом можно воспользоваться из любого адреса.
Authorization-data	Атрибуты привилегий клиента. Поле необязательное. Его содержимое Kerberos не обрабатывает – оно интерпретируется службой.

Содержимое поля flags адресуется побитно. Включение и выключение флагов здесь производится изменением значения (0 или 1) соответствующего бита. Длина поля – 32 разряда, однако для администратора Kerberos интерес представляют только 9 флагов мандата.

Таблица 2. Флаги мандата

Флаг	Описание
FORWARDABLE	Указывает, что на основании данного мандата TGT служба выдачи мандатов может генерировать новый мандат TGT с другим сетевым адресом (поле имеется только в мандатах TGT).
FORWARDED	Указывает на то, что данный мандат TGT был переадресован или генерирован на основе другого мандата TGT, прошедшего переадресацию.
PROXIABLE	Указывает, что служба выдачи мандатов может генерировать мандаты, сетевой адрес которых будет отличаться от приведенного в данном мандате TGT (поле имеется только в мандатахTGT).
PROXY	Указывает на то, что сетевой адрес в данном мандате отличается от адреса, приведенного в мандате TGT, на основании которого он выдан.
RENEWABLE	Используется в сочетании с полями endtime и renew-till, разрешая периодическое обновление службой KDC мандатов с повышенным сроком действия.
INITIAL	Указывает, что данный мандат является мандатом выдачи мандатов (поле имеется только в мандатах TGT).

Какие данные из мандата известны клиенту

Клиенту необходимо знать часть информации, содержащейся как в обычных мандатах, так и в мандатах TGT, чтобы управлять своей кэш-памятью удостоверений. Возвращая мандат и сеансовый ключ с помощью подпротоколов AS Exchange или TGS Exchange, служба KDC упаковывает клиентскую копию сеансового ключа в структуру данных, где уже могут быть заполнены поля flags, authtime, starttime, endtime и renew-till. Вся эта структура шифруется с помощью ключа клиента, включается в пакет KRB_AS_REP или KRB_TGS_REP и возвращается на рабочую станцию клиента.

Как служба KDC ограничивает срок действия мандата

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

Запрашивая в центре KDC мандат для доступа к службе, клиент может указать конкретное время начала его действия. Если этого не сделано или заданное время уже минуло, центр KDC указывает в поле starttime текущее время.

Но независимо от того, указал клиент время начала действия мандата или нет, запрос обязательно должен содержать время прекращения срока его действия. Получив такой запрос, служба KDC рассчитывает значение поля endtime. Для этого она суммирует наибольший срок действия мандата, предусмотренный политикой Kerberos, со значением поля starttime, а затем сравнивает полученный результат со временем прекращения действия мандата, указанным в запросе клиента. Если они не совпадают, в поле endtime заносится то время, которое наступит раньше.

Что происходит после истечения срока действия мандата

О скором истечении срока действия сеансового мандата или мандата TGT служба KDC не уведомляет клиента. Не следит она и за транзакциями с клиентом, если не считать краткосрочных записей, главная цель которых – предотвратить повторное использование перехваченных пакетов.

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

Может случиться и так, что клиент включит просроченный мандат TGT в свой запрос на сеансовый мандат, который направит в службу KDC. В этом случае центр выдачи мандатов перешлет клиенту сообщение об ошибке, после чего клиенту придется запросить новый мандат TGT, а для этого ему понадобится долговременный ключ пользователя. Если в процессе начальной регистрации такой ключ не был занесен в кэш-память, система может попросить пользователя еще раз ввести свой пароль, на основании которого будет вновь рассчитан долговременный ключ.

Обновляемые мандаты TGT

Один из методов защиты сеансовых ключей состоит в частой их смене. С этой целью в политике Kerberos можно предусмотреть относительно небольшой максимальный срок действия мандатов. Но есть и другой способ – использовать обновляемые мандаты. При этом обеспечивается периодическое обновление сеансовых ключей без необходимости запрашивать совершенно новый мандат. Если политика Kerberos разрешает применение обновляемых мандатов, служба KDC включает в каждый генерируемый мандат флаг RENEWABLE и указывает два срока истечения его действия. Первый из них ограничивает жизнь текущего экземпляра мандата, а второй определяет общее время, в течение которого может использоваться мандат с учетом его обновлений.

Время истечения срока действия текущего экземпляра мандата указывается в поле endtime. Как и в случае с необновляемыми мандатами, значение этого поля равно сумме значения из поля starttime и наибольшего срока действия мандатов, определенного политикой Kerberos. Клиент, использующий обновляемый мандат, должен представить его в службу KDC для обновления до времени, указанного в поле endtime. Одновременно с мандатом в центр распределения ключей направляется и новый аутентификатор. Получив мандат, который нужно обновить, служба KDC прежде всего проверяет общий срок его действия, указанный в поле renew-till. Это время задается при первичной генерации мандата. Оно определяется путем суммирования значения из поля starttime с максимально допустимым политикой Kerberos сроком действия мандата с учетом всех обновлений. Если указанное в поле renew-till время еще не наступило, служба KDC генерирует новый экземпляр мандата, где указывает более позднее время endtime и заменяет сеансовый ключ.

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

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

Особую сложность для протокола Kerberos создают многоуровневые клиент-серверные приложения. Здесь клиент может подключаться к серверу, который, в свою очередь, должен будет подключиться к другому серверу более высокого уровня. Для этого первому серверу понадобится мандат на подключение ко второму. В идеале такой мандат должен ограничивать доступ первого сервера ко второму лишь теми функциями, на которые клиент имеет права.

Для решения этой проблемы в протоколе Kerberos имеется специальный механизм – так называемое делегирование аутентификации. По существу, в такой ситуации клиент поручает свою аутентификацию серверу. С этой целью он уведомляет службу KDC о том, что данный сервер имеет право представлять клиента. Такой подход напоминает концепцию персонификации (concept of impersonation) Windows 2000.

Делегирование аутентификации возможно двумя способами. Во-первых, клиент может получить мандат на подключение к серверу высшего уровня, а затем передать его ближайшему серверу. Мандаты, полученные таким способом – клиентом для ближайшего сервера – называются представительскими (proxy tickets). Однако на этом пути имеется одна серьезная трудность: чтобы получить представительский мандат, клиенту нужно знать имя сервера высшего уровня. Решить проблему помогает второй способ делегирования аутентификации. Здесь клиент передает на ближайший к нему сервер свой мандат TGT, который тот по мере необходимости использует для запроса собственных мандатов. Мандаты TGT, полученные таким образом, то есть, по удостоверению клиента, называются передаваемыми (forwarded tickets). Какой из описанных способов применяется службой KDC, зависит от политики Kerberos.

Представительские мандаты

Когда служба KDC приступает к генерации мандата TGT, она прежде всего обращается к политике Kerberos и проверяет, допускается ли применение представительских мандатов. Если да, центр управления мандатами выставляет в мандате TGT, который он готовит клиенту, флаг PROXIABLE.

Чтобы получить представительский мандат, клиент пересылает свой мандат TGT в службу выдачи мандатов и запрашивает в ней мандат на подключение к серверу высшего уровня. В запросе выставляется специальный флаг, свидетельствующий о том, что нужен представительский мандат, а также указывается имя сервера, который будет являться представителем клиента. Получив такой запрос, служба KDC создает мандат на доступ к серверу высшего уровня, выставляет в нем флаг PROXY и отсылает в таком виде клиенту. Клиент затем направляет полученный мандат на сервер, который будет его представлять, а тот, в свою очередь, использует этот мандат для доступа к серверу высшего уровня.

Передаваемые мандаты

Клиент, который намерен делегировать свои права на получение мандата для доступа к серверу высшего уровня, должен запросить в службе KDC передаваемый мандат TGT. Это делается с помощью подпротокола AS Exchange. В запрос обязательно включается имя сервера, который будет представлять клиента. Если политика Kerberos допускает использование передаваемых мандатов, служба KDC генерирует мандат TGT на доступ данного клиента к серверу высшего уровня, выставляет в нем флаг FORWARDABLE и в таком виде направляет клиенту. Клиент, в свою очередь, пересылает полученный мандат TGT тому серверу, с которым работает непосредственно.

Этот сервер, направляя мандат на сервер высшего уровня, представляет в службу KDC мандат TGT, полученный от клиента. Обнаружив в нем флаг FORWARDABLE, центр управления мандатами выставляет в новом мандате флаг FORWARDED и возвращает его первому серверу.

компоненты Kerberos в Windows 2000

Центр распределения ключей KDC

В операционной системе Windows 2000 Центр распределения ключей (Key Distribution Center, KDC) реализован как служба домена. В качестве базы данных учетных записей он использует службу каталога Active Directory домена. Кроме того, некоторые данные о пользователях поступают в него из глобального каталога (Global Catalog).

Как и в других реализациях протокола Kerberos, центр KDC Windows 2000 представляет собой единый процесс, объединяющий две службы:

· Служба аутентификации Authentication Service (AS). Эта служба выдает мандаты на выдачу мандатов (мандаты TGT), открывающие доступ к службе выдачи мандатов своего домена. Прежде, чем получить мандат на обслуживание, сетевой клиент должен запросить первоначальный мандат TGT, обратившись для этого к службе аутентификации того домена, где находится учетная запись пользователя.

· Служба выдачи мандатов Ticket-Granting Service (TGS). Эта служба выдает мандаты на доступ к другим службам своего домена или к службе выдачи мандатов доверяемого домена. Чтобы обратиться в службу TGS, клиенту нужно сначала войти в контакт со службой выдачи мандатов того домена, где находится учетная запись службы, представить свой мандат TGT и запросить нужный мандат. Если у клиента нет мандата TGT, который открывает доступ к данной службе выдачи мандатов, он может воспользоваться процессом переадресации (referral process). Начальной точкой этого процесса является служба того домена, где находится учетная запись пользователя, а конечной –служба выдачи мандатов домена, где находится учетная запись требуемой службы.

Центр KDC, как и служба каталога Active Directory, имеется в каждом домене. Обе службы автоматически запускаются подсистемой LSA (Local Security Authority – распорядитель локальной безопасности), которая установлена на контроллере домена. Они работают в пространстве процессов этого распорядителя. Ни одну из этих служб остановить невозможно. Чтобы гарантировать постоянный доступ к KDC и Active Directory, в Windows 2000 предусмотрена возможность развертывания в каждом домене нескольких равноправных контроллеров домена. При этом запросы на аутентификацию и на выдачу мандата, адресованные службе KDC данного домена, может принимать любой контроллер домена.

В доменах Windows 2000 служба KDC является абонентом безопасности. Как и предусмотрено документом RFC 1510, в этом качестве она выступает под именем krbtgt. Учетная запись абонента безопасности для нее создается автоматически при организации нового домена; эту запись нельзя ни изменить, ни переименовать. Пароль учетной записи KDC также присваивается автоматически, а затем регулярно меняется на плановой основе вместе с паролями доверенных учетных записей домена (domain trust account). Пароль учетной записи KDC используется при вычислении секретного ключа, необходимого для шифрования и дешифрования генерируемых этой службой мандатов TGT. Пароль же доверенной учетной записи домена необходим для расчета междоменных (межобластных) ключей, которые используются для шифрования мандатов переадресации.

Все экземпляры службы KDC одного домена используют единую учетную запись абонента безопасности с именем krbtgt. При обращении к центру распределения ключей домена клиент должен указать как имя абонента безопасности krbtgt, так и имя домена. Эти сведения приводятся и в мандатах, где идентифицируют службу, выдавшую данный мандат. Подробная информация о формах имен и адресных конвенциях приведена в документе RFC 1510.

База данных учетных записей

База данных, которая необходима службе KDC для получения информации относительно абонентов безопасности, хранится в каталоге Active Directory домена. Каждый абонент здесь представлен в виде объекта учетной записи. Криптографические ключи, применяемые для связи с пользователем, компьютером или службой, хранятся в виде атрибутов объекта учетной записи конкретного абонента безопасности.

Серверами службы каталога Active Directory являются только контроллеры доменов. На каждом из них хранится копия каталога, в которую можно вносить изменения. Это позволяет создавать новые учетные записи, изменять пароли и корректировать состав групп, обратившись на любой контроллер домена. Изменения, внесенные в одну реплику каталога, автоматически переносятся на все другие его реплики. Правда, Windows 2000 не использует для этой цели протокол репликации Kerberos. Копирование и распространение информации, хранящейся в Active Directory, производится посредством протокола децентрализованной репликации (multi-master replication protocol), разработанного корпорацией Microsoft , причем пересылка ее осуществляется по безопасным каналам между контроллерами доменов.

Физическим хранением информации об учетных записях управляет агент DSA (Directory System Agent – агент каталожной системы). Этот защищенный процесс интегрирован с подсистемой LSA, также работающей на контроллере домена. Клиенты службы каталога никогда не получают прямого доступа к хранилищу с данными об учетных записях. Любой клиент, которому нужна каталожная информация, должен воспользоваться для подключения к DSA одним из поддерживаемых интерфейсов ADSI (Active Directory Service Interface – интерфейс служб Active Directory). Лишь после этого он может искать, читать и записывать каталожные объекты и их атрибуты.

Запросы на доступ к объектам или атрибутам этого каталога подлежат проверке в механизмах управления доступом Windows 2000. Подобно объектам файлов и папок в файловой системе NTFS, объекты Active Directory защищаются посредством ACL (Access Control List – список управления доступом), где содержится информация о том, кто и каким способом имеет право обращаться к объектам. Правда, в объектах Active Directory, в отличие от файлов и папок, список управления доступом имеется для каждого атрибута. Благодаря этому появилась возможность вводить дополнительные ограничения на доступ к отдельным атрибутам, содержащим наиболее конфиденциальную информацию.

Самым секретным элементом любой учетной записи, конечно же, является пароль. В объекте учетной записи атрибут пароля хранит не сам пароль, а криптографический ключ, полученный на его основе, однако этот ключ представляет для взломщика не меньшую ценность. По этой причине доступ к атрибуту пароля предоставляется исключительно владельцу учетной записи. Такого права не имеет никто другой, даже администратор. Прочесть информацию о пароле или изменить ее могут только процессы с привилегией Trusted Computer Base, которые работают в контексте безопасности LSA.

В Windows 2000 приняты меры и против возможного взлома учетной записи изнутри, то есть, злоумышленником с доступом к резервным копиям доменного контроллера. Чтобы помешать этому, атрибут пароля в объекте учетной записи подвергается второму шифрованию с использованием системного ключа. Этот криптографический ключ может храниться на сменном носителе, для которого нетрудно предусмотреть дополнительные меры защиты, либо даже на контроллере домена, но под защитой механизма дисперсии (dispersal mechanism). Где хранить системный ключ, – выбирает администратор, одновременно определяя алгоритм шифрования атрибутов пароля.

Политика Kerberos

В среде Windows 2000 политика Kerberos определяется на уровне домена и реализуется службой KDC домена. Она сохраняется в каталоге Active Directory как подмножество атрибутов политики безопасности домена. По умолчанию вносить изменения в политику Kerberos имеют право только члены группы администраторов домена.

В политике Kerberos предусматриваются:

Примечание: Приведенные ниже значения по умолчанию не являлись стандартными в третьей бета-версии.

· Максимальный срок действия пользовательского мандата (Maximum user ticket lifetime). Под «пользовательским мандатом» здесь имеется в виду мандат на выдачу мандатов (мандат TGT). Значение задается в часах и по умолчанию равно 10 час.

· Максимальное время, в течение которого допускается обновление пользовательского мандата (Maximum lifetime that a user ticket can be renewed). Задается в сутках; по умолчанию составляет 7 суток.

· Максимальный срок действия служебного мандата (Maximum service ticket lifetime). Под «служебным мандатом» здесь имеется в виду сеансовый мандат. Значение этого параметра должно быть более 10 минут, но менее значения Maximum user ticket lifetime. По умолчанию оно равно 10 час.

· Максимально допустимое отклонение в синхронизации компьютерных часов (Maximum tolerance for synchronization of computer clocks). Указывается в минутах; по умолчанию равно 5 мин.

· Проверка ограничений при входе пользователя в систему (Enforce user logon restrictions). Если этот пункт помечен флажком, служба KDC анализирует каждый запрос на сеансовый мандат и проверяет, имеет ли данный пользователь право на локальный вход в систему (привилегия Log on Locally) или на доступ к запрашиваемому компьютеру через сеть (привилегия Access this computer from network). Такая проверка занимает дополнительное время и может замедлить предоставление сетевых услуг, поэтому администратору предоставляется право ее отключения. По умолчанию она включена.

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

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

Предварительная аутентификация

По умолчанию служба KDC требует проведения предварительной аутентификации всех учетных записей, что предельно затрудняет атаки с подбором паролей. Однако такая функция может вызвать проблемы совместимости с другими реализациями протокола Kerberos, поэтому предусмотрена возможность ее отключения в отдельных учетных записях.

Поставщик поддержки безопасности Kerberos

Протокол аутентификации Kerberos реализован в форме поставщика поддержки безопасности (security support provider, сокращенно SSP) – динамически подключаемой библиотеки, входящей в состав операционной системы. В Windows 2000 предусмотрен также поставщик SSP для протокола NTLM. По умолчанию оба эти компонента загружаются подсистемой LSA на компьютер Windows 2000 одновременно с загрузкой операционной системы. Каждый из этих поставщиков позволяет производить аутентификацию как входа в сеть, так и клиент-серверных подключений. Какой поставщик будет использован в том или ином конкретном случае, зависит от возможностей компьютера, с которым устанавливается связь, однако в первую очередь система всегда пытается воспользоваться поставщиком Kerberos SSP.

После того, как подсистема LSA создаст контекст безопасности для интерактивного пользователя, может потребоваться еще один экземпляр Kerberos SSP. Его загрузку производит процесс, запущенный в пользовательском контексте безопасности, чтобы обеспечить поддержку подписи и заверение сообщений.

Системные службы и приложения транспортного уровня обращаются к SSP через интерфейс SSPI (Security Support Provider Interface – интерфейс поставщика поддержки безопасности) корпорации Microsoft. Он представляет собой интерфейс Win32®, позволяющий просмотреть список доступных на системе поставщиков, выбрать один из них и использовать его для организации аутентифицированного подключения. Выполнение всех этих функций производится в SSPI стандартизированными методами (method), своего рода подпрограммами «черного ящика», которыми разработчик может пользоваться, даже не разбираясь в тонкостях самого протокола. К примеру, при аутентификации клиент-серверного подключения пересылка удостоверения клиентского приложения на сервер производится с помощью метода InitializeSecurityContext. Если выбран поставщик Kerberos SSP, этот метод генерирует на клиентском компьютере сообщение KRB_AP_REQ. В ответ серверное приложение, используя метод AcceptSecurityContext, направляет на клиент сообщение KRB_AP_REP. Когда аутентификация подключения завершена, серверная подсистема LSA генерирует жетон доступа, основанный на информации из клиентского мандата. После этого сервер обращается к методу SSPI под названием ImpersonateSecurityContext и с его помощью прикрепляет жетон доступа к нити персонификации службы (impersonation thread for service).

Для доступа к посреднику Kerberos SSP все распределенные службы Windows 2000 используют интерфейс SSPI. С помощью протокола Kerberos можно производить аутентификацию:

· служб спулера печати;

· доступа к удаленным файлам в файловой системе CIFS по протоколу SMB;

· запросов к Active Directory по протоколу LDAP;

· управления распределенной файловой системой и переадресации запросов в ней;

· распорядителя безопасности при организации подключения между хост-компьютерами по протоколу IPSec;

· резервирования ресурсов для обеспечения качества обслуживания в сети;

· элементов интрасетей на сервере Internet Information Server;

· управления удаленным сервером или рабочей станцией с использованием удаленного вызова процедур с их аутентификацией;

· получения на сервере Microsoft Certificate Server сертификатов, необходимых для доступа к пользователям и компьютерам домена.

Кэш-память удостоверений

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

Управление кэш-памятью удостоверений возложено на поставщика Kerberos SSP, который работает в контексте безопасности подсистемы LSA. Каждый раз, когда возникает необходимость в получении мандата или ключа, либо в их обновлении, распорядитель LSA обращается к Kerberos SSP, который и выполняет эту задачу.

В подсистеме LSA сохраняются также копии хешированных паролей интерактивных пользователей. Если в ходе сеанса работы истекает срок действия пользовательского мандата TGT, поставщик Kerberos SSP использует такую копию для получения нового мандата. Это делается в фоновом режиме, без прекращения сеанса. Пароль здесь находится во временном хранении, его локальная копия уничтожается после прекращения сеанса работы пользователя.

По иному обстоит дело с хешированными паролями для служб и компьютеров. Как и в прежних версиях Windows NT, они сохраняются в безопасной области системного реестра компьютера. Реестр используется также для хранения хешированных паролей для учетных записей пользователей на локальных системах, однако локальные учетные записи пригодны исключительно для доступа к компьютерам, работающим в автономном режиме, но не через сеть.

Разрешение имен DNS

Согласно документу RFC 1510, для пересылки сообщений между клиентами и службой KDC должен использоваться протокол IP. Чтобы послать первоначальный запрос аутентификации, поставщику Kerberos SSP, установленному на клиентском компьютере, нужно найти адрес центра распределения ключей того домена, где находится учетная запись пользователя. Другими словами, необходимо знать имя сервера со службой KDC в доменной системе имен DNS. Если это имя может быть преобразовано в IP-адрес, Kerberos SSP направляет на него свое сообщение, если же нет, – выдается сигнал ошибки, указывающий на то, что домен не найден.

Служба KDC устанавливается на всех контроллерах домена Windows 2000. Кроме функций серверов KDC эти контроллеры выполняют еще и функции серверов LDAP (Lightweight Directory Access Protocol – облегченный протокол доступа к каталогам). Обе эти службы регистрируются в записях указателя служб системы DNS (записях ресурсов SRV). Чтобы найти контроллер домена, клиенту достаточно запросить на сервере DNS запись ресурса SRV с именем _ldap._tcp.dc._msdcs.ИмяДоменаDNS. А запросив запись ресурса SRV с именем _kerberos._udp.ИмяДоменаDNS, клиент получит в ответ адрес службы KDC. Но есть и такие клиенты, преобразователи IP-адресов которых не поддерживают тип записей SRV. Им, чтобы найти нужный адрес, приходится запрашивать запись хост-компьютера (запись ресурса А) с именем требуемого домена.

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

В Windows 2000 имеется специальная инструментальная программа, помогающая настраивать клиенты для работы с областями Kerberos, которые не входят в домены Windows 2000. Она запускается файлом ksetup.exe из каталога Support на установочном компакт-диске Windows 2000.

Транспорт IP

В соответствии с документом RFC 1510, для подключения к службе KDC клиент должен послать дейтаграмму UDP (User Datagram Protocol – протокол дейтаграмм пользователя) на порт 88 соответствующего IP-адреса. Служба KDC отвечает дейтаграммой на тот порт IP-адреса отправителя, откуда поступил запрос.

UDP относится к транспортным протоколам, не устанавливающим логического соединения, поэтому его применение вполне оправданно в тех случаях, когда организация подключения предусматривает предварительный обмен служебными сообщениями. Этот протокол хорошо подходит и там, где обмен ограничивается единственным запросом и единственным ответом на него, как это имеет место в сеансах связи между клиентом и службой KDC. Важно только, чтобы каждое такое сообщение полностью умещалось в одну дейтаграмму. Но наилучшие результаты применение протокола UDP дает в тех случаях, когда дейтаграммы передаются как единое целое, то есть, каждая из них полностью вписывается в один кадр. Емкость же кадра зависит от передающей среды. В кадре Ethernet, например, максимальный размер передаваемого блока данных (MTU) равен 1 500 октетов. Следовательно, в физических сетях Ethernet сообщения Kerberos, отправляемые в виде дейтаграмм, могут содержать до 1 500 октетов данных.

В среде Windows 2000 объем данных, передаваемых при входе пользователя в сеть, может легко превысить это значение. В то же время такие данные используются только компьютерами под управлением Windows 2000, поэтому их можно смело исключить из мандатов, которые направляются на компьютеры с другими операционными системами. В результате размер таких сообщений значительно сокращается, и они вполне вписываются в рамки транспорта UDP. Именно этот протокол и используется для передачи мандатов. Сообщения же с мандатами для компьютеров Windows 2000 часто превышают предел в 1 500 байт, поэтому для их передачи используется протокол ТСР (Transport Control Protocol – протокол управления транспортом), отличающийся гораздо большей емкостью. Применение транспорта ТСР полностью согласуется с требованиями недавно опубликованного обновления спецификации RFC 1510[5].

данные авторизации

Протокол Kerberos служит для аутентификации, но не для проверки полномочий (авторизации) пользователей. Его задача – только удостовериться, что абонент безопасности в самом деле является тем, за кого себя выдает. Kerberos не проверяет ни того, доступ к каким файлам и другим объектам разрешен этому абоненту, ни того, как тот может воспользоваться предоставленным доступом. Эти аспекты работы находятся в ведении механизмов контроля за доступом, имеющимися в системе. Но протокол Kerberos помогает им в этом, отводя одно из полей своего мандата под данные, которые необходимы для проверки полномочий пользователя. Правда, он не описывает формат этих данных и ничего не говорит о том, как эти данные будут использованы сервером.

Контроль доступа в Windows 2000

Некоторые операционные системы возлагают проверку полномочий пользователей на собственные механизмы конкретных приложений. Зачастую этой цели служат списки с именами пользователей, которым разрешен доступ к той или иной информации. Такой тип контроля за доступом легко можно интегрировать в процесс аутентификации Kerberos. Для этого достаточно указать в поле данных авторизации мандата имя абонента безопасности в той или иной форме. Такой метод можно назвать поименной проверкой полномочий (name-based authorization).

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

В среде Windows 2000 предусмотрены специальные меры защиты общих файлов и других ресурсов от несанкционированного доступа. Если такой файл используется двумя процессами, операционная система обеспечивает его безопасность собственными механизмами контроля за доступом. Заголовок каждого объекта содержит дескриптор безопасности со списком контроля доступа ACL. Последний находится в полном ведении владельца объекта, который имеет право разрешать и запрещать доступ к нему любого абонента безопасности, а также определять пределы полномочий абонентов, которым разрешен доступ к этому объекту. Чтобы обеспечить выполнение заданных условий, операционная система производит проверку полномочий каждый раз, когда от приложения поступает запрос на идентификатор защищенного объекта. Перед тем, как выдать ответ, она обращается к списку ACL объекта и убеждается, что абонент безопасности, использующий данное приложение, может обращаться к этому объекту. Если такое право пользователю не предоставлено, доступ запрещается.

Еще одно важное отличие механизма Windows 2000 от других механизмов контроля за доступом состоит в том, что в этой среде абоненты безопасности не идентифицируются по имени ни в самой операционной системе, ни в записях ACL. Вместо этого каждому абоненту присваивается уникальный идентификатор безопасности SID (Security Identifier) – алфавитно-цифровая последовательность, по структуре напоминающая телефонный номер. Первую ее часть можно сравнить с кодом города, так как она указывает на домен, выдавший SID. Вторая часть идентификатора определяет учетную запись внутри этого домена, подобно тому, как последняя группа телефонного номера – номер конкретного телефона в городе. Код домена уникален для предприятия, а код учетной записи не повторяется внутри домена. В отличие от телефонных номеров идентификатор безопасности никогда не используется повторно. Возможность получить SID, уже принадлежавший ранее другому пользователю, полностью исключена, тогда как в механизмах контроля за доступом, основанных на именах пользователей, избежать такой проблемы бывает непросто.

У описываемого способа есть и еще одно важное преимущество над контролем доступа по именам. Полномочия здесь определяются не только по идентификатору пользователя, но и по его принадлежности к одной или нескольким группам безопасности. И действительно, сегодня в большинстве случаев права на доступ к ресурсам определяются не для отдельного пользователя, а для группы, и уровень привилегий зависит от потребностей ее членов. Такой подход значительно упрощает обновление списков ACL в сетях с тысячами пользователей и миллионами объектов. Членством в группах администратор может управлять централизованно: чтобы изменить уровень доступа конкретного пользователя ко многим ресурсам, его достаточно включить в определенную группу или исключить из нее.

Управление безопасностью ресурсов в среде Windows 2000 еще больше облегчается за счет применения вложенных групп (nested group). Группу, созданную в одном домене, можно включить в члены группы другого домена или даже сделать ее членом универсальной группы, которая действует по всему дереву доверяемых доменов. В результате этого у администратора появляется отличная возможность: когда сотрудник организации переводится на другое место, уровень его доступа к ресурсам можно изменить сразу по всему предприятию, не затронув при этом ни единого списка ACL.

Как и индивидуальные абоненты безопасности, каждая группа безопасности Windows 2000 получает собственный идентификатор SID. Таким образом, в этой среде права пользователя на доступ к объектам определяются несколькими идентификаторами – одного его личного плюс по одному на каждую группу, членом которой состоит данный пользователь.

Как KDC готовит данные авторизации

Аутентификация по протоколу Kerberos предусматривает пересылку на локальный компьютер идентификаторов SID самого абонента безопасности и всех групп, членом которых он является. С этой целью в сеансовом мандате предусмотрено специальное поле данных авторизации. Сбор информации, необходимой для проверки полномочий, осуществляется в два не связанных между собой этапа. Первый из них проводится, когда служба KDC домена Windows 2000 создает мандат TGT, а второй – когда она готовится генерировать сеансовый мандат для сервера своего домена.

Получив от пользователя запрос на мандат TGT, служба KDC того домена, где находится учетная запись пользователя, обращается в каталог Active Directory этого же домена. Один из атрибутов учетной записи пользователя содержит его собственный идентификатор SID, а другой – идентификаторы всех групп безопасности домена, в которые этот пользователь входит. Все обнаруженные идентификаторы передаются в KDC, где включаются в поле мандата TGT, отведенное под данные авторизации. В сети с несколькими доменами служба KDC, кроме того, обращается в глобальный каталог Global Catalog за информацией об универсальных группах, в которые входит сам пользователь либо группы безопасности домена, членом которых он состоит. Если такие универсальные группы найдены, их идентификаторы SID включаются в то же поле мандата TGT.

Когда пользователь запрашивает сеансовый мандат на доступ к серверу, служба KDC домена, где находится этот сервер, копирует содержимое поля мандата TGT, отведенное под данные авторизации, в такое же поле сеансового мандата. Если сервер и учетная запись пользователя находятся в разных доменах, служба KDC обращается в каталог Active Directory и ищет группы безопасности локального домена, куда входит сам пользователь или одна из его групп безопасности. Идентификаторы SID найденных групп включаются в поле сеансового мандата, отведенное под данные авторизации.

Такое применение поля с данными авторизации полностью отвечает требованиям обновлений документа RFC 1510, представленных на рассмотрение Целевой группы инженерной поддержки Интернета IETF[6]. Точный формат таких данных в Windows 2000 может изменяться вплоть до выхода этой операционной системы в свет. На момент публикации настоящего документа они представлялись в формате NDR (Network Data Representation – представление сетевых данных) и подписывались службой KDC.

Как данные авторизации используются службами

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

Выполняя внутренние задачи на компьютере под управлением Windows 2000, служба вызывает метод AcquireCredentialsHandle интерфейса SSPI, получая тем самым доступ к собственному удостоверению – секретному ключу для учетной записи, которая используется для работы этой службы. После этого она подключается к коммуникационному порту, где начинает ожидать сообщения клиентов.

Когда клиент высылает запрос на подключение и представляет свой сеансовый мандат, служба вызывает метод AcceptSecurityContext интерфейса SSPI, посредством которого просит поставщика Kerberos SSP проверить удостоверение клиента, и пересылает ему сеансовый ключ клиента вместе с описателем для секретного ключа службы. В ответ Kerberos SSP проводит аутентификацию полученного мандата, открывает его и извлекает содержимое поля с данными авторизации, которое пересылает в родительский процесс, то есть, в подсистему LSA. Если в этих данных имеется список идентификаторов SID, подсистема LSA создает на их основе жетон доступа, представляющий пользователя на локальной системе. Кроме того, подсистема LSA обращается в собственную базу данных, чтобы определить, не является ли сам пользователь или одна из групп безопасности, в которую он входит, членом группы безопасности на локальной системе. Если это так, LSA добавляет в жетон доступа соответствующие идентификаторы SID. После этого подсистема уведомляет службу, из которой поступил запрос, о том, что проверка клиента успешно завершена, и вкладывает в свой ответ жетон доступа для данного клиента.

Получив такое подтверждение, служба завершает связь с клиентом и обращается к методу ImpersonateSecurityContext, посредством которого прикрепляет жетон доступа клиента к персонифицированной нити. Этот жетон вступает в действие, когда требуется доступ персонифицированной нити к какому-либо объекту. Операционная система контролирует доступ, сверяя идентификаторы SID из жетона с этими же идентификаторами в списке ACL объекта. Если они совпадают, проверяется соответствие уровня доступа, отмеченного в ACL, с тем, который затребован нитью. При выполнении этого условия доступ разрешается, в противном случае – запрещается.

Зачем подписывать данные авторизации

Сеансовый мандат шифруется секретным ключом той учетной записи, в интересах которой была запущена служба. Доступ к этому ключу может получить любая служба, имеющая описатель своего собственного удостоверения. Это открывает возможность для мошенничества. Пользователь со вполне законной учетной записью в сети может попытаться повысить уровень своих прав, воспользовавшись для этого фиктивной службой. Установив ее, злоумышленник запрашивает сеансовый мандат для новой службы, а затем дешифрует его, изменяет данные авторизации (например, добавляет в них идентификатор SID привилегированной группы), вновь шифрует скорректированный мандат и представляет его в подсистему LSA для вызова метода AcceptSecurityContext. Таким способом ему удается расширить свои права на том компьютере, где запущена его служба.

Чтобы предотвратить подделку данных авторизации, они перед внесением в сеансовый мандат подписываются службой KDC. После этого любая попытка скорректировать такие данные неизбежно приведет к искажению подписи. Подсистема LSA на компьютере Windows 2000 обязательно проверяет достоверность такой подписи во всех сеансовых мандатах, кроме тех, что поступили от доверяемых служб.

При получении запроса на метод AcceptSecurityContext подсистема LSA доверяет только тем службам, которые работают под эгидой учетной записи Local Systems. Дело в том, что эта учетная запись по умолчанию доступна лишь службам, которые были установлены вместе с самой операционной системой, например внутренней службе «Сервер» (Server). Конечно, использование этой учетной записи нетрудно предусмотреть в конфигурации и других служб, однако сделать это может лишь член группы Администраторов. Предполагается, что администратор, установивший такую службу, полностью отвечает за ее безопасность.

Службам, работающим в интересах других учетных записей, подсистема LSA не доверяет. Получив сеансовый мандат от любого приложения, которое не входит в число локальных систем (группа Local System), она просит центр KDC своего домена проверить подпись в поле с данными авторизации. Запрос и ответ на него производятся с помощью вызова удаленной процедуры по безопасному каналу Netlogon контроллера домена. Такие запросы на проверку никогда не покидают пределов локального домена, что объясняется просто: сеансовые мандаты всегда выдаются, – а значит, и подписываются, – службой KDC того домена, где находится запрашиваемый компьютер.

интерактивная регистрация

Пользователи зачастую считают, будто регистрация в домене Windows сразу же открывает им выход в сеть. Конечно же, это не так. Если для сетевой аутентификации используется протокол Kerberos, то пользователь после входа в систему получает доступ лишь к службе аутентификации домена. Точнее говоря, он получает мандат TGT, которые должен предъявить при запросе сеансовых мандатов для обращения к другим службам домена.

Когда пользователь входит в домен с компьютера под управлением Windows 2000, ему обязательно нужен хотя бы один сеансовый мандат –для той машины, на которой он регистрируется. В отличие от других компьютеров, каждая машина Windows 2000 имеет в домене собственную учетную запись, которую для простоты можно представить как служебную. Таким образом, чтобы получить доступ к ресурсам на компьютере Windows 2000, удаленному пользователю нужно представить запрос в службу «Сервер» (Server) этого компьютера. Интерактивные же пользователи для этого направляют свои запросы в службу «Рабочая станция» (Workstation). Однако получить доступ к любой из этих служб, как и к любой другой службе группы «Локальная система» (Local System), можно лишь после того, как будет представлен сеансовый мандат для данного компьютера.

Процесс регистрации

Когда пользователь компьютера Windows 2000 с учетной записью в домене Windows 2000 вводит с клавиатуры свои регистрационные данные, его запрос на вход в систему проходит трехэтапную обработку.

1. Пользователь посылает заявку на подключение к службе выдачи мандатов домена.

Это делается с помощью протокола AS Exchange, обеспечивающего связь между поставщиком Kerberos SSP пользовательского компьютера и службой KDC домена, где находится учетная запись пользователя. Результатом успешного обмена данными является мандат TGT, который пользователь должен будет представлять в ходе всех последующих транзакций с KDC.

2. Пользователь запрашивает мандат на компьютер.

Эта операция выполняется с помощью протокола TGS Exchange, который обеспечивает связь между поставщиком Kerberos SSP компьютера и службой KDC домена, где находится учетная запись этого компьютера. После завершения операции генерируется сеансовый мандат, который пользователь должен будет представлять для получения доступа к системным службам компьютера.

3. Пользователь посылает запрос на доступ к службам «Локальной системы» компьютера.

При выполнении этой операции поставщик Kerberos SSP на компьютере пользователя представляет сеансовый мандат в подсистему LSA этого же компьютера.

Если учетные записи пользователя и компьютера, на котором он работает, находятся в разных доменах, выполняется еще одна дополнительная процедура. Перед тем, как запросить сеансовый мандат для компьютера, поставщик Kerberos SSP запрашивает в службе KDC домена пользователя мандат TGT, пригодный для обращения к службе KDC домена, где находится учетная запись компьютера. Затем он представляет полученный мандат TGT в эту службу и получает от нее сеансовый мандат для компьютера.

Особенности процесса регистрации во многом зависят от конфигурации компьютера. В Windows 2000 для этой цели обычно используется пароль, хотя в операционной системе предусмотрена возможность входа в систему по предъявлении микропроцессорной карточки. В обоих случаях выполняется примерно одинаковая последовательность операций, однако есть между ними и различия, которые будут рассмотрены ниже. Сначала остановимся на регистрации с применением пароля.

Вход в систему по паролю

Предположим, что Алиса имеет учетную запись в домене «Запад». Там же находится и учетная запись сервера Боб, с которым она обычно работает. Вход в сеть Алиса начинает с нажатия клавиш CTRL+ALT+DEL, комбинация которых в стандартной конфигурации Windows 2000 генерирует сигнал SAS (Secure Attention Sequence – последовательность обращения к системе безопасности).

В ответ служба Winlogon компьютера переключается на настольную систему, с которой поступил сигнал SAS, и направляет на нее динамически подключаемую библиотеку GINA (Graphical Identification and Authentication – графическая идентификация и аутентификация) – компонент, загружаемый службой Winlogon. GINA служит для получения от пользователя данных регистрации, их упаковки в структуру данных и отправки в подсистему LSA на проверку. Независимые производители, возможно, предложат замену этой библиотеке, однако здесь мы рассмотрим случай, когда Winlogon загружает стандартный файл MSGINA.DLL из состава операционной системы.

На экране появляется стандартное диалоговое окно входа в систему. Алиса вводит имя пользователя и пароль, а в ниспадающем списке доменов выбирает «Запад». После щелчка на кнопке ОК библиотека MSGINA пересылает введенные данные в службу Winlogon. Та, в свою очередь, вызывает метод LsaLogonUser и с его помощью направляет регистрационную информацию в подсистему LSA для проверки.

Получив пакет с данными регистрации Алисы, подсистема LSA первым делом преобразует текстовый пароль в секретный ключ, для чего производит его одностороннее хеширование. Полученный результат сохраняется в кэш-памяти удостоверений, откуда он может быть извлечен при необходимости обновления мандата TGT или аутентификации по протоколу NTLM, если потребуется подключиться к серверу, не поддерживающему протокол Kerberos.

Чтобы проверить регистрационные данные Алисы и начать сеанс ее работы на компьютере, подсистеме LSA необходимо получить:

· мандат TGT, который нужно представить в службу выдачи мандатов;

· сеансовый мандат, открывающий доступ к серверу Боб.

Подсистема LSA получает эти мандаты при посредничестве поставщика поддержки безопасности Kerberos SSP, который обменивается сообщениями непосредственно со службой KDC домена «Запад».

Рис. 8. Интерактивная регистрация в домене

Обмен сообщениями осуществляется в следующем порядке:

1. Подсистема LSA направляет в службу KDC домена «Запад» сообщение KRB_AS_REQ.

В сообщении указываются:

· пользовательское имя Алисы – Alice;

· имя домена с учетной записью Алисы – West.

· данные предварительной аутентификации, зашифрованные посредством секретного ключа, который был рассчитан на основе пароля Алисы.

2. Если данные предварительной аутентификации клиента верны, служба KDC отвечает сообщением KRB_AS_REP.

В сообщение включаются:

· сеансовый ключ для связи Алисы со службой KDC, зашифрованный с помощью секретного ключа, который был рассчитан на основе пароля Алисы.

· мандат TGT для службы KDC домена «Запад», зашифрованный с помощью секретного ключа службы KDC.

В мандате TGT указываются:

· сеансовый ключ для связи Алисы со службой KDC;

· данные авторизации Алисы.

Данные авторизации включают в себя:

· идентификатор SID учетной записи Алисы;

· идентификаторы SID групп безопасности домена «Запад», членом которых состоит Алиса;

· идентификаторы SID универсальных групп предприятия, в которые входит либо сама Алиса, либо одна из ее групп домена.

3. Подсистема LSA направляет в службу KDC домена «Запад» сообщение KRB_TGS_REQ.

В сообщение включаются:

· имя компьютера, к которому нужно подключиться, – Bob;

· имя домена этого компьютера – West;

· мандат TGT Алисы;

· аутентификатор, зашифрованный сеансовым ключом, который используется для связи Алисы с данной службой KDC.

4. Служба KDC отвечает сообщением KRB_TGS_REP.

В сообщении указываются:

· сеансовый ключ Алисы и Боба, зашифрованный посредством сеансового ключа, который Алиса использует для связи со службой KDC;

· сеансовый мандат Алисы для компьютера Боб, зашифрованный сеансовым ключом, который используется для связи Боба со службой KDC.

Сеансовый мандат содержит:

· сеансовый ключ, общий для Боба и Алисы;

· данные авторизации, скопированные из мандата TGT Алисы.

Получив сеансовый мандат Алисы, подсистема LSA расшифровывает его с помощью секретного ключа этого компьютера и извлекает данные авторизации Алисы. Затем она обращается в локальную базу данных диспетчера учетных записей безопасности SAM (Security Account Manager). Здесь она проверяет, не является ли Алиса членом какой-либо группы безопасности, локальной для данного компьютера, и не имеет ли она специальных привилегий на этой локальной машине. Если проверка дает положительный результат, подсистема LSA добавляет обнаруженные идентификаторы SID в список данных авторизации, извлеченный из мандата. Пополненный таким образом список используется для генерации жетона доступа, описатель которого возвращается в Winlogon вместе с идентификатором сеанса регистрации Алисы и подтверждением подлинности введенных ею данных.

В ответ Winlogon создает для Алисы оконную станцию (windows station) и несколько объектов настольной системы, прикрепляет ее жетон доступа и запускает оболочечный процесс, который позволит Алисе взаимодействовать с компьютером Боб. Жетон доступа Алисы впоследствии будет включаться во все прикладные процессы, запускаемые в ходе текущего сеанса.

Вход в систему с помощью смарт-карты

При стандартной регистрации с помощью Kerberos пользователь прежде всего должен доказать службе KDC, что он является именно тем, за кого себя выдает. Для этого ему необходимо продемонстрировать знание секрета, который известен только ему и службе KDC. Роль такого секрета играет криптографический ключ, рассчитанный на основе пароля пользователя. Он используется только при обмене сообщениями по подпротоколу AS Exchange в тех случаях, когда:

· клиент шифрует данные предварительной аутентификации;

· служба KDC расшифровывает данные предварительной аутентификации;

· служба KDC шифрует ключ сеанса регистрации;

· клиент расшифровывает ключ сеанса регистрации.

Для шифрования и дешифрования данных используется один и тот же общий секретный ключ, который по этой причине называют симметричным.

Для регистрации с помощью смарт-карт в Windows 2000 реализовано специальное расширение исходного подпротокола AS Exchange из набора Kerberos, позволяющее использовать открытые ключи[7]. В отличие от общих секретных ключей криптография открытых ключей асимметрична. Здесь требуется применение двух ключей, один из которых служит для шифрования сообщения, а другой – для его дешифрования. Вместе они образуют пару, состоящую из секретного и открытого ключа. Секретный ключ известен только владельцу этой пары и никогда не передается второму абоненту. Открытый ключ владелец пары сообщает всем, с кем намерен обмениваться конфиденциальной информацией.

При регистрации с помощью смарт-карт вместо общего секретного ключа, рассчитываемого на основе пароля пользователя, применяется пара, состоящая из секретного и открытого ключей, которая хранится в памяти смарт-карты. Расширение протокола Kerberos, определяющее порядок применения открытых ключей при обмене по подпротоколу AS Exchange, предусматривает следующий порядок использования такой пары. Открытая ее часть служит для шифрования сеансового ключа пользователя службой KDC, а секретная – для дешифрования этого ключа клиентом.

Регистрация начинается с того, что пользователь вставляет свою смарт-карту в специальное считывающее устройство, подключенное к компьютеру. При соответствующей конфигурации Windows 2000 это равносильно сигналу SAS, то есть, одновременному нажатию клавиш CTRL+ALT+DEL. В ответ Winlogon направляет на настольную систему динамически подключаемую библиотеку MSGINA, которая выводит на экран стандартное диалоговое окно регистрации. Правда, теперь пользователю достаточно ввести только один параметр – персональный идентификационный номер PIN (Personal Identification Number).

MSGINA вызывает метод LsaLogonUser и с его помощью пересылает регистрационные данные пользователя в подсистему LSA точно так же, как и при парольной регистрации. Эта подсистема использует PIN пользователя для доступа к смарт-карте, где хранятся секретный ключ пользователя и сертификат Х.509 v3, содержащий открытый ключ пары. В дальнейшем все криптографические операции с использованием данной пары будут производится через смарт-карту.

Поставщик Kerberos SSP клиентского компьютера направляет в службу KDC сообщение KRB_AS_REQ – первоначальный запрос на аутентификацию. В поле данных предварительной аутентификации этого запроса включается сертификат открытого ключа пользователя. Центр распределения ключей проверяет подлинность сертификата и извлекает из него открытый ключ, которым шифрует ключ сеанса регистрации. После этого он включает этот ключ вместе с мандатом TGT в сообщение KRB_AS_REP и направляет его клиенту. Расшифровать сеансовый ключ сможет только тот клиент, у которого есть секретная половина криптографической пары, функции которой на этом заканчиваются. Вся дальнейшая связь между клиентом и службой KDC поддерживается на основе сеансового ключа. Никаких других отклонений от стандартного процесса регистрации и вхождения в сеть не требуется.

О том, какие типы смарт-карт и устройств их чтения поддерживаются в среде Windows 2000, можно узнать из списка устройств, совместимых с этой операционной системой, «Windows 2000 Hardware Compatibility List».

Данные предварительной аутентификации

По умолчанию поставщик Kerberos SSP, работающий на клиентском компьютере, в качестве данных предварительной аутентификации направляет в службу KDC шифрованную метку времени. На системах же, конфигурация которых предусматривает регистрацию с применением микропроцессорной карточки, роль данных предварительной аутентификации отводится сертификату открытого ключа.

Удаленная регистрация

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

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

Интерфейс поставщика поддержки безопасности

Как правило, аутентификация проводится на основе механизма клиент-серверного приложения, который обеспечивает связь между процессами. Клиент-серверным приложениям, разработанным для Windows 2000, нет никакой необходимости знать детали протокола аутентификации, более того, им не нужен даже список поддерживаемых протоколов. Обоим компонентам такого приложения вполне достаточно вызовов в интерфейс поставщика поддержки безопасности SSPI (Security Support Provider Interface). Клиентское приложение направляет туда запрос на контекст безопасности для пользователя, а серверное обращается к этому интерфейсу, чтобы создать такой контекст. Все остальное берет на себя интерфейс SSPI.

С некоторой натяжкой можно сказать, что интерфейс SSPI превращает протокол аутентификации Kerberos в подтекст прикладного протокола, организуя своего рода переговоры внутри переговоров. На обоих концах канала связи клиента с сервером интерфейс SSPI действует через поставщика поддержки безопасности SSP, который владеет всеми кодами, необходимыми для работы конкретного протокола аутентификации. SSP просто передает сообщения аутентификации транспортному приложению. Для этого приложения, если не оговорено иного, передаваемые данные остаются невидимыми. Оно не знает ни того, что содержится в сообщении аутентификации, ни того, что отвечать при получении такого сообщения. Функции обработки и реагирования на сообщения аутентификации полностью возложены на поставщика SSP.

Рис. 9. Протокол аутентификации как подтекст прикладного протокола

Выбор поставщика поддержки безопасности

В состав Windows 2000 входит несколько поставщиков поддержки безопасности, разработанных для проведения аутентификации по протоколам Kerberos, NTLM и SChannel. При обращении к интерфейсу SSPI приложение может указать, какой из поставщиков ему нужен, но предусмотрена и другая возможность: функция согласования, заложенная в SSPI, позволяет приложению выбрать из числа доступных тот протокол, который обеспечит наивысшую безопасность сеанса[8]. Когда предложение запрашивает вход в систему с согласованием, клиент предлагает ему весь список имеющихся протоколов безопасности, начиная с самых безопасных. Сервер определяет, какие из этих протоколов доступны ему, и выбирает из их числа самый безопасный. На системах Windows 2000 первым в списке всегда идет Kerberos, за ним следует NTLM, а потом – SChannel. Если и клиент, и сервер работают под управлением Windows 2000, механизм согласования всегда будет выбирать для аутентификации протокол Kerberos.

Пример: открытие файла на уделенном сервере

Предположим, что Алиса вошла в сеть со своей рабочей станции, воспользовавшись для этого принадлежащей ей учетной записью в домене. Затем она запустила Microsoft Word и решила открыть документ, хранящийся на сервере файлов.

Чтобы открыть этот документ, Microsoft Word передает в операционную систему Windows 2000, установленную на рабочей станции, запрос ввода-вывода, для чего использует вызов интерфейса прикладного программирования (API). Операционная система определяет, что документ относится к числу удаленных ресурсов, и пересылает запрос на редиректрор (redirector) своей файловой системы. Тот, в свою очередь, посредством протокола совместного использования файлов Server Message Block (SMB) связывается со службой «Сервер» (Server) удаленного сервера файлов, открывает файл и считывает данные из него. Все эти действия выполняются поэтапно, с помощью последовательности сообщений SMB. Первый – и единственный, который нас интересует, – этап состоит в организации аутентифицированного подключения между перенаправителем и удаленной службой.

Процесс согласования с поставщиком поддержки безопасности

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

С чего клиент начинает процесс аутентификации

Протокол аутентификации вступает в действие, когда перенаправитель рабочей станции Алисы обращается к SSPI и вызывает метод AcquireCredentialsHandle, указав в качестве абонента безопасности Алису. В ответ он получает описатель удостоверения, выданного Алисе при ее интерактивной регистрации на своей рабочей станции. Затем перенаправитель вновь обращается к SSPI, но на этот раз вызывает метод InitializeSecurityContext, с помощью которого передает описатель к мандату TGT Алисы и указывает сервер, к которому нужно подключиться, – в нашем случае сервер файлов. В результате такого вызова генерируется сообщение Kerberos KRB_TGS_REQ, содержащее мандат TGT Алисы. Поставщик Kerberos SSP направляет это сообщение непосредственно в службу KDC того домена, где хранится учетная запись Алисы, и получает от нее мандат на доступ к соответствующему серверу файлов. Затем Kerberos SSP кэширует полученный мандат и вновь обращается к процессу, от которого был получен вызов, то есть, к редиректору. Тем самым он указывает, что процесс аутентификации еще не завершен.

В продолжение предыдущего вызова редиректор вновь посылает запрос на метод InitializeSecurityContext. На этот раз поставщик Kerberos SSP генерирует сообщение Kerberos KRB_AP_REQ, содержащее мандат, зашифрованный посредством секретного ключа, общего для запрашиваемого сервера и службы KDC. Сюда же включается аутентификатор, зашифрованный с помощью сеансового ключа, который получили Алиса и этот сервер. Затем Kerberos SSP возвращает созданное сообщение на редиректор. Тот, в свою очередь, преобразует полученное сообщение в жетон аутентификации и в таком качестве включает его в сообщение SMB, которое посылает службе «Сервер».

Что отвечает служба «Сервер»

Получив от редиректора сообщение SMB, служба «Сервер» создает локальный контекст безопасности для нового клиента. С этой целью она обращается в SSPI, вызывает метод AcceptSecurityContext и выставляет указатель на жетон аутентификации. Поставщик Kerberos SSP, запущенный на сервере файлов, открывает сообщение KRB_AP_REQ, достает мандат и извлекает из него сеансовый ключ, с помощью которого оценивает достоверность аутентификатора Алисы. Если проверка прошла успешно, Kerberos SSP удаляет из сеансового мандата данные авторизации Алисы и передает его в подсистему LSA сервера. Та, в свою очередь, генерирует жетон доступа Алисы и создает контекст безопасности для ее работы на данной системе. Сделав все это, поставщик Kerberos SSP готовит сообщение KRB_AP_REP и возвращает его вместе с описателем контекста безопасности Алисы тому процессу, от которого поступил первоначальный запрос.

Когда вызов метода AcceptSecurityContext возвращается в службу «Сервер», та включает KRB_AP_REP в поле данных сообщения SMB и отправляет последнее на редиректор рабочей станции Алисы. Описатель контекста безопасности Алисы используется для персонификации пользователя. С этой целью редиректор обращается к интерфейсу SSPI и вызывает метод ImpersonateSecurityContext. В результате такого вызова жетон доступа Алисы прикрепляется к персонифицированной нити сервисного процесса, после чего та от имени Алисы открывает файл. Если Алиса имеет право на чтение этого файла, служба отвечает на запрос ввода-вывода, поступивший от перенаправителя.

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

Когда редиректор получает сообщение SMB, содержащее KRB_AP_REP, он передает эти данные поставщику Kerberos SSP на рабочей станции Алисы для идентификации сервера. С помощью своей копии сеансового ключа Kerberos SSP расшифровывает аутентификатор сервера, а затем сравнивает метку времени из него с той, которая была отправлена в сообщении KRB_AP_REQ. Если эти метки не совпадают, Kerberos SSP выдает сигнал ошибки, и редиректор разрывает подключение с сервером файлов. При положительном же результате проверки сеанс продолжается. Так проходит взаимная аутентификация.

Пример: междоменная аутентификация

Сеть, где работает Алиса, содержит три домена, в том числе один родительский и два дочерних – «Восток» и «Запад». Учетная запись Алисы хранится в домене «Запад». Она уже зарегистрировалась в своем домене и получила мандат TGT для службы KDC домена «Запад». Но вот, работая на своем компьютере, она решила взглянуть на документ в каталоге общего пользования на сервере Боб из домена «Восток».

Рис. 10. Сеть Алисы

Порядок организации безопасного клиент-серверного подключения очень похож на тот, что был описан в предыдущем примере. Однако на этот раз Алиса и сервер файлов находятся в разных доменах, поэтому поставщику Kerberos SSP, установленному на рабочей станции Алисы, нужно сначала получить мандат TGT для домена сервера. Только после этого он может обращаться за мандатом на доступ к самому серверу. Таким образом, появляется еще одно звено – процесс переадресации, который выполняется в следующей последовательности.

1. Рабочая станция Алисы направляет в центр распределения ключей (служба KDC) домена west.company.com сообщение KRB_TGS_REQ.

В сообщение включаются:

· имя компьютера, к которому нужно подключиться – Bob,

· имя домена, в котором находится этот компьютер, –east.company.com,

· мандат TGT для доступа к службе KDC домена west.company.com,

· аутентификатор, зашифрованный посредством сеансового ключа, общего для Алисы и службы KDC этого домена.

2. Служба KDC домена west.company.com отвечает сообщением KRB_TGS_REP.

В сообщении содержатся:

· сеансовый ключ для связи Алисы со службой KDC домена company.com, зашифрованный посредством сеансового ключа Алисы, который она получила при регистрации в системе;

· мандат TGT для доступа к службе KDC домена company.com, зашифрованный посредством секретного ключа, о котором эти домены договорились при установлении доверительных отношений.

3. Рабочая станция Алисы направляет службе KDC домена company.com сообщение KRB_TGS_REQ.

В сообщение включаются:

· имя компьютера, к которому нужно подключиться, – Bob;

· имя домена, в котором находится этот компьютер, –east.company.com;

· мандат TGT для доступа к службе KDC домена company.com;

· аутентификатор, зашифрованный сеансовым ключом, который используется для связи Алисы с этой службой KDC.

4. Служба KDC домена company.com отвечает сообщением KRB_TGS_REP.

Это сообщение содержит:

· мандат TGT на доступ к службе KDC домена east.company.com, зашифрованный с помощью секретного ключа, о котором эти домены договорились при установлении доверительных отношений;

· сеансовый ключ, который используется для связи Алисы с данной службой KDC, зашифрованный посредством сеансового ключа, общего для Алисы и службы KDC домена company.com.

5. Рабочая станция Алисы посылает службе KDC домена east.company.com сообщение KRB_TGS_REQ.

Сообщение содержит:

· имя компьютера, к которому нужно подключиться, – Bob;

· имя домена, в котором находится этот компьютер, –east.company.com;

· мандат TGT для доступа к службе KDC домена east.company.com;

· аутентификатор, зашифрованный сеансовым ключом, который используется для связи Алисы с этой службой KDC.

6. Служба KDC домена east.company.com направляет в ответ сообщение KRB_TGS_REP.

В сообщение включаются:

· сеансовый ключ для связи Алисы с компьютером Боб, зашифрованный с помощью сеансового ключа, общего для Алисы и службы KDC домена east.company.com;

· сеансовый мандат для доступа к компьютеру Боб, зашифрованный посредством секретного ключа, который используется компьютером Боб и этой службой KDC.

Сеансовый мандат содержит:

· сеансовый ключ для связи компьютера Боб с Алисой;

· данные авторизации, скопированные из мандата TGT Алисы, а также данные для локального домена east.company.com.

В состав данных авторизации входят:

1. идентификатор SID учетной записи Алисы;

· идентификаторы SID групп домена west.company.com, членом которых является Алиса;

· идентификаторы SID универсальных групп, в состав которых входит либо сама Алиса, либо одна из групп домена west.company.com, где Алиса состоит членом;

· идентификаторы SID групп домена east.company.com, в состав которых входит либо сама Алиса, либо одна из ее групп домена west.company.com, либо одна из ее универсальных групп.

7. Рабочая станция Алисы посылает компьютеру Боб сообщение KRB_AP_REQ.

Сообщение содержит:

1. имя пользователя – Alice.

· мандат для компьютера Боб;

· аутентификатор, зашифрованный посредством сеансового ключа, общего для Алисы и компьютера Боб.

8. Компьютер Боб отвечает сообщением KRB_AP_REP.

Это сообщение содержит аутентификатор, зашифрованный с помощью сеансового ключа, общего для компьютера Боб и Алисы.

Вопросы совместимости

Главная цель реализации протокола аутентификации Kerberos 5 в операционной системе Windows 2000 – обеспечить полную совместимость с эталонным протоколом Kerberos, опубликованным Массачусетским технологическим институтом.

Сценарии

Корпорация Microsoft проверила совместимость своей реализации Kerberos с эталонным протоколом Массачусетского технологического института при взаимодействии со следующими системами.

Служба KDC операционных систем Windows. Реализации протокола Kerberos для других сред обеспечивают аутентификацию в центрах распределения ключей доменов Windows 2000. Аутентификация пользователей таких реализаций, а также хост-компьютеров, на которых они развернуты, требует применения утилиты kinit и шифрования по стандартам DES-CBC-MD5 или DES-CBC-CRC.

Центры распределения ключей Kerberos для других операционных систем. Системы под управлением Windows 2000 могут проходить аутентификацию на хост-компьютерах, выполняющих функции центров распределения ключей областей Kerberos. Кроме того, возможна такая конфигурация автономных систем Windows 2000, при которой учетные записи локального компьютера будут отображаться на абоненты безопасности Kerberos. При такой конфигурации пользователь может одновременно регистрироваться на компьютере и в области Kerberos.

Клиент Windows и служба Kerberos для другой операционной системы. Клиентское приложение, запущенное в среде Windows 2000, может пройти аутентификацию в службе Kerberos для другой операционной системы, если эта служба поддерживает интерфейс прикладного программирования GSS-API (Generic Security Service Application Program Interface – интерфейс прикладного программирования для службы общей безопасности), описанный в документе RFC 1964.

В состав Windows 2000 интерфейс GSS-API не входит. Чтобы обеспечить аутентификацию по протоколу Kerberos 5, создаваемые для этой операционной системы приложения должны опираться на интерфейс SSPI. Оба эти интерфейса совместимы и имеют между собой много общего.

Клиент Kerberos для другой операционной системы и служба Windows. Клиентские приложения, использующие протокол Kerberos для других операционных систем, могут пройти аутентификацию в службах, которые работают в среде Windows 2000. Для этого они должны поддерживать интерфейс прикладного программирования GSS-API, описанный в документе RFC 1964.

Доверительные отношения. Домены Windows 2000 могут доверять областям Kerberos в сетях, которые работают под управлением других операционных систем. Такие области при соответствующей конфигурации также могут доверять доменам Windows. Однако подобные доверительные отношения не столь всеобъемлющи, как доверие между доменами Windows. В частности, пользователь области Kerberos не может представить данных авторизации, необходимых для управления доступом к службам на Windows 2000. Чтобы включить такие данные в мандат пользователя, необходим механизм отображения учетных записей. Для идентификации пользователей Kerberos из доверенной области производится отображение нескольких избранных учетных записей этого домена, результаты которого сохраняются в свойстве altSecurityID объекта учетной записи пользователя. Управление отображенными учетными записями может производиться с помощью ветви Active Directory Users and Computers.

Конфигурирование системы

В папке Support установочного компакт-диска Windows 2000 имеется несколько вспомогательных программ, которые помогают настроить эту операционную систему для работы с системами UNIX. Описание работы с ними приведено в разделе «MIT Kerberos 5 (krb5 1.0) Interoperability» краткого технического руководства «Beta 3 Technical Walkthrough».

Дополнительная информация

Самую свежую информацию по операционной системе Windows 2000 всегда можно найти на узле http://www.microsoft.com/windows.

[1] Miller, S., Neuman, C., Schiller, J., J. Saltzer, “Section E.2.1: Kerberos Authentication and Authorization System,” MIT Project Athena, Cambridge, MA, декабрь 1987.

[2] Kohl, J., C. Neuman, “The Kerberos Network Authentication Service (V5),” RFC 1510, сентябрь 1993.

[3] Linn, J., “The Kerberos Version 5 GSS-API Mechanism,” RFC 1964, июнь 1996.

[4] Tung, B., Neuman, C., Wray, J., Medvinsky, A., Hur, M., J. Trostle, “Public Key Cryptography for Initial Authentication in Kerberos,” draft-ietf-cat-kerberos-pk-init.

[5] Neuman, C., Kohl, J. и T. Ts’o, “The Kerberos Network Authentication Service (V5),” draft-ieft-cat-kerberos-revisions-03, ноябрь 1998.

[6] Neuman, C., Kohl, J, и T. Ts’o, “The Kerberos Network Authentication Service (V5),” draft-ietf-cat-kerberos-revisions, ноябрь 1997.

[7] В Windows 2000 реализован текущий проект спецификации IETF CAT для PKINIT за одним исключением. Поскольку американское законодательство запрещает включать алгоритм шифрования RSA с 512-битным ключом в экспортируемые системы, к которым относится и Windows NT, вместо него по договоренности с авторами проекта используется стандарт шифрования данных PKCS #7.

[8] При этом поставщик поддержки безопасности использует метод согласования, в основу которого положен протокол SPNEGO, описанный в документе RFC 2478, “Simple and Protected GSS-API Negotiation Mechanism,” декабрь 1998.