Сетевой протокол аутентификации 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 – «Выдан предупреждающий билет службы, размер которого приближается к настроенному пороговому значению для билета». Диалоговое окно данного параметра политики изображено ниже:

Kerberos2-02

Рис. 1. Определение порогового размера билета

Хоть и такой компонент как DirectAccess возник впервые лишь в операционной системе Windows Server 2008 R2, он постепенно начинает набирать популярность. А для того, чтобы клиенты, расположенные за пределами интрасети могли использовать возможности DirectAccess, в Windows Server 2012 появилась прокси-служба KDC. Как это все работает?

По сути, компьютеры, использующие DirectAccess, создают безопасный канал TLS или SSL к прокси-службе KDC, работающей на сервере DirectAccess. А чтобы получить билет службы для этого сервера, сообщения Kerberos должны отправляться прокси-службе KDC. Подробнее о прокси-службе KDC вы можете почитать в документе «Kerberos Key Distribution Center (KDC) Proxy Protocol Specification».

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

Процесс проверки подлинности Kerberos

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

Более чем очевидно, что на этом ничего не заканчивается. Итак, какие же действия выполняются во время проверки подлинности Kerberos:

  1. Прежде всего, поставщик SSP пересылает центру распространения ключей сообщение проверки подлинности, включающее в себя имя и домен пользователя, а также запрос TGT с секретным ключом, который, как вы уже знаете, извлекается из пароля пользователя. Между прочим, секретный ключ может использоваться как для проверки подлинности клиента, так и для проверки подлинности сервера. Ввиду того, что билет будет отправлен в чистом виде, что чревато воздействию злоумышленников, часть запроса обязательно шифруется;
  2. Сразу после этого, контроллер домена сверяет имя пользователя в своей базе данных, а затем проверяет копию секретного ключа, которая соответствует этой учетной записи. Выполняется расшифровка зашифрованных в сообщении данных и вместе с предыдущей проверкой выполняется проверка временной метки. Если контроллеру домена удалось расшифровать сообщение, причем временная метка была создана не раньше, чем за 5 минут до текущего времени на контроллере домена, выполняется последующая подготовка к проверке подлинности пользователя. Естественно, эту разницу вы можете настроить при помощи функциональных возможностей групповой политики. Для этого в редакторе управления групповой политики следует открыть диалоговое окно свойств параметра политики «Максимальная погрешность синхронизации часов компьютеров» из узла Конфигурация компьютераПолитикиКонфигурация WindowsПараметры безопасностиПолитики учетных записейПолитика Kerberos и установить требуемое пороговое значение. Диалоговое окно данного параметра политики изображено на следующей иллюстрации:
    Kerberos2-03
    Рис. 2. Настройка максимальной погрешности синхронизации часов компьютера
  3. После того как проверка подлинности удачно будет завершена, контроллер домена пересылает на клиентский компьютер сообщение с сеансовым ключом TGS и билетом TGT, который и будет предоставлять пользователю доступ к TGS. Сеансовый ключ представляет собой ключ шифрования, который используется для аутентификации клиента и может дополнительно использоваться для аутентификации сервера, вместо секретного ключа клиента для взаимодействия с KDC. Теперь, если пользователю на протяжении жизненного цикла TGT, понадобится предоставить свои учетные данные какому-либо ресурсу или приложению, клиент все время будет предоставлять службе TGS этот билет TGT. В билете, помимо всей необходимой информации еще передаются идентификаторы безопасности пользователя и групп безопасности, в которые входит пользователь, что называется сертификатом атрибутов привилегий (Privilege Attribute Certificate, PAC). Билет TGT, который пересылается пользователю в теле KRB_AS_REP, зашифрован ключом KDC, который пользователю не известен и не должен быть известен. То есть пользователь получает TGT в зашифрованном виде и расшифровать его не может.
    Время жизни билета пользователя можно предопределить, опять же, при помощи групповой политики. Для этого следует воспользоваться возможностями параметра политики «Максимальный срок жизни билета пользователя» из узла Конфигурация компьютераПолитикиПараметры WindowsПараметры безопасностиПолитики учетных записейKerberos. Здесь вы можете указать максимальный интервал времени, в течение которого может быть использован билет представления билета. По истечении срока действия билета TGT необходимо возобновить существующий билет или запросить новый. Диалоговое окно свойств текущего параметра политики можно увидеть ниже:
    Kerberos2-04
    Рис. 3. Максимальный срок жизни билета пользователя
  4. На этом этапе пакет возвращается на пользовательский компьютер и его снова следует расшифровать. За процесс расшифровки сеансового ключа TGS на клиентском компьютере отвечает секретный ключ пользователя. Как и на втором шаге данного процесса, если клиенту удалось расшифровать сеансовый ключ, и временная метка оказалась действительной, клиент считает, что центр KDC является валидным и ему можно доверять. Сеансовый ключ кэшируется на компьютер пользователя до истечения своего срока действия, причем, для подключений к центру распространения ключей теперь будет использоваться именно этот ключ. А так как клиенту более не нужен секретный ключ – он просто удаляется из кэша;
  5. Пользователь уже прошел проверку подлинности, то есть, можно сказать, один из важнейших этапов уже пройден. Однако, осталось получить доступ к ресурсам сети, что являлось ключевой задачей всей рассматриваемой процедуры. Если для предоставления доступа к службе TGS используется билет TGT полученный пользователем, то для доступа к остальным ресурсам сети пользователю еще предстоит от службы TGS получить билет доступа к службе. Соответственно, на этом шаге клиент отправляет запрос билета доступа к службе на TGS, куда входит такая информация, как имя и домен пользователя, его SPN, билет TGT, о котором речь шла выше, UPN, а также временная метка, зашифрованная сеансовым ключом;
  6. KDC опять расшифровывает билет TGT при помощи долговременного ключа, извлекает сеансовый ключ TGS и по временной метке проверяет, корректный ли используется сеансовый ключ. Если все извлеченные данные валидны, центр распространения ключей выполняет LDAP-запрос для поиска учетной записи пользователя и подготавливает билет доступа к службе. Как и в случае со временем жизни билета пользователя, при помощи параметра политики «Максимальный срок жизни билета службы», вы можете определить максимальное количество минут, в течение которого полученный билет сеанса разрешается использовать для доступа к конкретной службе. Билеты сеансов применяются только для проверки подлинности на новых подключениях к серверам. После того как подключение пройдет проверку подлинности, срок действия билета теряет смысл. Если вы укажите значение, равное 0 минут, срок жизни билета никогда не истечет. Диалоговое окно свойств данного параметра политики изображено на следующей иллюстрации:
    Kerberos2-05
    Рис. 4. Максимальный срок жизни билета службы
  7. Так как сеансовый билет уже готов, его необходимо доставить до правильного адресата. Раз у контроллера домена, по сути, есть два адресата, в ответе присутствуют два сеансовых ключа службы, однако оба ключа отправляются непосредственно клиенту. Первый ключ предназначен для клиента, подключаемого к ресурсу сети, причем, этот ключ зашифрован при помощи сеансового ключа TGS. Второй же ключ, в свою очередь, необходим участнику службы, к которому будет подключен пользователь и в этом ключе хранится сам билет доступа к службе. Этот билет также шифруется, однако, ключ известен только центру распространения ключей и самому участнику службы, соответственно;
  8. Теперь клиентский компьютер кэширует у себя в памяти обе части сеансового билета. Для предоставления доступа клиентский компьютер предоставляет сетевой службе билет сеанса;
  9. В последнюю очередь, сетевая служба, к которой подключается пользователь, расшифровывает билет доступа к службе, используя свой секретный ключ, а после чего выполняется расшифровка временной метки, где можно найти и сам запрос. Если все получилось, сетевая служба начинает доверять центру KDC и определяет, требуется ли взаимная проверка подлинности для клиента. Если такова необходима, временная метка из запроса шифруется и отправляется ответ на клиентский компьютер. После этого снова клиенту требуется выполнять расшифровку временной метки, используя свой сеансовый ключ. Если все временные метки сошлись – происходит общее доверие;
  10. И, наконец-то, сервер, к которому подключается пользователь, передает билет доступа к службе подсистемы LSA. Выполняется расшифровка билета доступа к службе, и извлекаются данные авторизации, которые представляют собой только идентификаторы безопасности пользователя и групп, членами которых является сам пользователь. И вот, когда процессы аутентификации и авторизации были успешно завершены, клиенту предоставляется доступ к запрашиваемым ресурсам.

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

И, напоследок

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

Из следующей статьи настоящего цикла вы узнаете о том, что же такое утверждения и какую роль они играют в работе Kerberos и в Windows Server 2012 в целом.

VN:F [1.9.22_1171]
Rating: 8.0/10 (1 vote cast)
Сетевой протокол аутентификации Kerberos или зачем нужны KDC с TGS, и как проходит аутентификация, 8.0 out of 10 based on 1 rating

Leave a Reply

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