Kerberos

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

KDC -Key Distribution Center который находится на контроллере домена DC.

Процесс получения доступа к сервису происходит в 3 этапа:

Authentication Service (AS): Клиент должен аутентифицироваться на KDC.
Ticket-Granting Service (TGS): Затем он должен запросить билет для доступа к выбранному сервису (например, CIFS, HTTP, SQL, ...).
Application Request (AP): В итоге он пользуется услугой, предоставляя билет.

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

Authentication Service (AS)

KRB_AS_REQ (Kerberos Authentication Service Request)

Сначала клиент(pixis) посылает запрос на получение Ticket Granting Ticket (TGT) контроллеру домена (DC). Этот запрос называется KRB_AS_REQ . TGT, запрашиваемый клиентом, представляет собой фрагмент зашифрованной информации, содержащий, помимо прочего, сеансовый ключ и информацию о пользователе (ID, имя, группы, ...).

Для выполнения этого TGT-запроса клиент(pixis) посылает в KDC свое имя, а также точное время запроса, зашифрованное хэшированной версией своего пароля.

KDC получит это имя пользователя и проверит, существует ли оно в его базе данных.

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

KRB_AS_REP(Kerberos Authentication Service Response)

Ответ от KDC содержит:

Сеансовый ключ, зашифрованный хешированным паролем pixis;
TGT, содержащий различную информацию, например:

Имя пользователя (pixis)
Срок действия
Сгенерированный сеансовый ключ
Сертификат атрибутов привилегий (PAC), содержащий много специфической информации о пользователе, включая его идентификатор (SID) и все группы, в которые он входит.

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

Ticket-Granting Service (TGS)

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

KRB_TGS_REQ(Kerberos Ticket-Granting Service Request)

Если pixis хочет использовать какой-либо сервис, например CIFS на SERVER01, он посылает KDC несколько фрагментов информации, чтобы KDC мог отправить в ответ Service Ticket:

Аутентификатор, который содержит его имя пользователя и текущую временную метку, зашифрованные сеансовым ключом.
TGT;
Сервис, который он хочет использовать, и связанный с ним хост, в данном примере CIFS/SERV01;

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

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

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

KRB_TGS_REP(Kerberos Ticket-Granting Service Response)

Теперь, когда KDC смог убедиться, что пользователь является pixis, он отправляет обратно информацию, которая позволит пользователю сделать запрос к сервису. Этим сообщением является KRB_TGS_REP. Оно включает в себя следующие элементы:

Билет, содержит имя и хост запрашиваемого сервиса (CIFS/SERV01), имя пользователя (pixis), PAC, а также новый сеансовый ключ, который действителен только для связи между pixis и SERVER01 в течение определенного времени. Этот ключ шифруется ключом службы (т.е. ключом хоста, поскольку служба CIFS работает под учетной записью хоста);
Новый ключ сессии

Эти две части информации (билет и ключ сеанса) шифруются первым ключом сеанса - тем, которым изначально обменялись KDC и клиент.

Получив это сообщение, клиент сможет расшифровать первый уровень и получить сеансовый ключ, созданный для связи с сервисом, а также билет, сгенерированный для использования этого сервиса. Такой билет принято называть Ticket-Granting-Service (TGS).

Application Request (AP)

KRB_AP_REQ(Kerberos Application request Request)

pixis генерирует новый аутентификатор, который шифрует новым сеансовым ключом вместе с TGS.

Служба CIFS получает TGS и может расшифровать его с помощью своего собственного ключа. Поскольку только служба CIFS знает свой ключ, он может быть уверен в подлинности данного TGS.

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