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

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

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

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

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

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

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

Управление безопасностью ресурсов в среде Windows 2000 еще больше облегчается за счет применения вложенных групп. Группу, созданную в одном домене, можно включить в группу другого домена или в универсальную группу, которая действует по всему дереву доменов. В результате этого у администратора появляется отличная возможность: когда сотрудник организации переводится на другое место, уровень его доступа к ресурсам можно изменить сразу по всему предприятию, не затронув при этом ни единого списка 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[5].

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

В среде 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 с учетной записью в домене вводит с клавиатуры свои регистрационные данные, его запрос на вход в систему проходит трехэтапную обработку.

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 на проверку. На экране появляется стандартное диалоговое окно входа в систему. Алиса вводит имя пользователя и пароль, а в ниспадающем списке доменов выбирает «Запад». После щелчка на кнопке ОК библиотека 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) и несколько объектов настольной системы, прикрепляет ее маркер доступа и запускает процесс, который позволит Алисе взаимодействовать с компьютером Боб. Маркер доступа Алисы впоследствии будет включаться во все прикладные процессы, запускаемые в ходе текущего сеанса.

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

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

При регистрации с помощью смарт-карт используется пара, состоящая из личного и открытого ключей, которая хранится в памяти смарт-карты. Расширение протокола 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 – первоначальный запрос на аутентификацию. В поле данных предварительной аутентификации этого запроса включается сертификат открытого ключа пользователя. KDC проверяет подлинность сертификата и извлекает из него открытый ключ, которым шифрует ключ сеанса регистрации. После этого он включает этот ключ вместе с билетом TGT в сообщение KRB_AS_REP и направляет его клиенту. Расшифровать сеансовый ключ сможет только тот клиент, у которого есть секретная половина криптографической пары, функции которой на этом заканчиваются. Вся дальнейшая связь между клиентом и службой KDC поддерживается на основе сеансового ключа. Никаких других отклонений от стандартного процесса регистрации и вхождения в сеть не требуется.

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы открыть этот документ, Microsoft Word передает в операционную систему Windows 2000, установленную на рабочей станции, запрос ввода-вывода, для чего использует вызов интерфейса прикладного программирования (API). Операционная система определяет, что документ относится к числу удаленных ресурсов, и передает запрос редиректору файловой системы. Тот, в свою очередь, посредством протокола 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, содержащее билет, зашифрованный с секретным ключом запрашиваемого сервера. Сюда же включается аутентификатор, зашифрованный с помощью сеансового ключа, который получили Алиса и этот сервер. Затем 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 выдает сигнал ошибки, и редиректор разрывает соединение с сервером файлов. При положительном же результате проверки сеанс продолжается. Так проходит взаимная аутентификация.

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

Главная цель реализации протокола аутентификации 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.

 

---

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

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

[6] В Windows 2000 реализован текущий проект спецификации IETF CAT для PKINIT.

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