Сетевой протокол аутентификации Kerberos или зачем нужны KDC с TGS, и как проходит аутентификация

 

Kerberos2-01

Твой черный рыцарь как цербер из Ада,

Вновь натравил своих преданных псов…

Каждый хитер и проворен, вот драма,

Только не страшен уже лязг зубов!

Ермек Исин

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

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

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

Для чего нужен KDC?

Еще в первой статье этого цикла я мельком упомянул, что одним из основных компонентов протокола проверки подлинности Kerberos выступает центр распространения ключей (Key Distribution Center, KDC) – центральное хранилище пользовательских данных для проверки подлинности пользователей. Сейчас же подробней рассмотрим этот основной компонент Kerberos.

По сути, KDC, который тесно интегрирован со службами безопасности, размещается на контроллере домена Active Directory и, как было упомянуто в предыдущей статье данного цикла, для хранения базы данных учетных записей безопасности KDC, используется база данных Active Directory. Причем, каждый контроллер домена, включая контроллеры домена только для чтения (RODC) выступают в качестве KDC. Важно знать, что при установке первого контроллера домена в организации, автоматически создается учетная запись krbtgt в контейнере Users, с которой вы не должны выполнять какие-либо действия. Пароль этой учетной запись используется для создания секретного ключа, благодаря которому выполняется шифрование и расшифровка всех билетов TGT (о них речь пойдет немного позже), которые выдаются всеми центрами распространения ключей в домене.

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

Сам KDC выполняется как отдельный процесс, основанный на следующих двух службах:

  • Службапроверкиподлинности (Authentication Service, AS). Данная служба выдает билет предоставления билета (Ticket-Granting Ticket, TGT) для подключения к службе предоставления билетов в своем или в доверенном домене. Само удостоверение TGT позволяет получать билеты для всех служб, используемых для получения доступа к ресурсам. В свою очередь, перед тем как пользователь запросит билет на другом компьютере, он должен запросить у службы проверки подлинности TGT для учетной записи клиента. Далее служба проверки подлинности возвращает службе предоставления билетов TGT для целевого
    доменного компьютера. Сами билеты TGT могут быть использованы до истечения своего срока действия, однако, при первом подключении к службе TGS, пользователю нужно будет предоставлять свои учетные данные для выполнения проверки подлинности;
  • Служба предоставления билетов (TicketGrantingService, TGS). В отличие от службы проверки подлинности, данная служба выдает билеты для подключения к компьютерам в домене. Когда клиентам требуется подключиться к какому-либо компьютеру, он обращается к службе TGS, предоставляет TGT, а затем запрашивает билет на целевой компьютер. Как и во всех случаях, билеты могут быть использованы до истечения своего срока действия, но, при первом подключении к TGS, придется предоставить свои учетные данные.

Обе службы запускаются внутри процесса локальной системы безопасности (Local Security Authority, LSA). Кстати, как клиентские компьютеры, так и любые приложения никогда не должны иметь возможности получения прямого доступа к самой базе данных учетных записей. Помимо этих двух служб, внутри процесса LSA также запускается системный агент каталога (Directory System Agent – DSA, агент, при помощи которого управляется база банных), через который должны проходить все запросы.

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

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

Несмотря на это, размер билетов, выданных во время проверки подлинности Kerberos, может подойти очень близко к указанному вами пороговому значению или же, что еще хуже, превысить такое значение. В Windows Server 2012 поведение предупреждений о размере билетов в системном журнале событий можно контролировать при помощи функциональных возможностей групповой политики. Для этого в редакторе управления групповыми политиками откройте диалоговое окно свойств параметра политики «Предупреждение о билетах Kerberos большого размера» из узла Конфигурация компьютераПолитикиАдминистративные шаблоныСистемаЦентр распределения ключей и установите пороговое значение для таких предупреждений. Обратите внимание на то, что размер буфера маркера контекста также определяется при помощи возможностей групповой политики, что было рассмотрено в предыдущей статье данного курса. Причем, если установленное вами значение будет слишком велико, предупреждения будут отображаться только после сбоев проверки подлинности. А если наоборот, указанное вами значение будет очень маленьким, в журнале событий вы будете лицезреть огромное количество новых событий. Кстати, это будут в основном события с идентификатором 31 – «Выдан предупреждающий билет службы, размер которого приближается к настроенному пороговому значению для билета». Диалогово

Pin It

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.