Аутентификация по протоколу Kerberos

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

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

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

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

Центр 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 приняты меры и против возможного взлома учетной записи изнутри, то есть, злоумышленником с доступом к резервным копиям доменного контроллера. Чтобы помешать этому, атрибут пароля в объекте учетной записи подвергается второму шифрованию с использованием системного ключа. Этот криптографический ключ может храниться на сменном носителе, для которого нетрудно предусмотреть дополнительные меры защиты, либо на контроллере домена, но под защитой механизма дисперсии. Где хранить системный ключ, – выбирает администратор, одновременно определяя алгоритм шифрования атрибутов пароля.

Политика Kerberos

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

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

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

Как уже отмечалось, политика 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 – интерфейс поставщика поддержки безопасности). Он представляет собой интерфейс Win32®, позволяющий просмотреть список доступных на системе поставщиков, выбрать один из них и использовать его для организации аутентифицированного подключения. Выполнение всех этих функций производится в SSPI стандартизированными методами, своего рода подпрограммами «черного ящика», которыми разработчик может пользоваться, даже не разбираясь в тонкостях самого протокола. К примеру, при аутентификации клиент-серверного подключения пересылка удостоверения клиентского приложения на сервер производится с помощью метода InitializeSecurityContext. Если выбран поставщик Kerberos SSP, этот метод генерирует на клиентском компьютере сообщение KRB_AP_REQ. В ответ серверное приложение, используя метод AcceptSecurityContext, направляет клиенту сообщение KRB_AP_REP. Когда аутентификация подключения завершена, серверная подсистема LSA генерирует маркер доступа, основанный на информации из клиентского билета. После этого сервер обращается к методу SSPI под названием ImpersonateSecurityContext и с его помощью прикрепляет маркер доступа к потоку.

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

На компьютерах под управлением 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. Компьютеры под управлением 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 на порт 88 соответствующего IP-адреса. Служба KDC отвечает дейтаграммой на тот порт IP-адреса отправителя, откуда поступил запрос.

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

Сообщения с билетами для компьютеров Windows 2000 часто превышают предел в 1 500 байт, поэтому для их передачи используется протокол ТСР. Применение транспорта ТСР полностью согласуется с требованиями недавно опубликованного обновления спецификации RFC 1510[4].