Что такое kerberos аутентификация

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

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

Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.

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

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

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

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

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

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

Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.

Получив эти данные KDC извлекает долговременный ключ данного пользователя и расшифровывает метку времени, которую сравнивает с собственным текущим временем, если оно отличается не более чем на 5 минут (значение по умолчанию), то метка считается действительной. Эта проверка является дополнительной защитой, так как не позволяет использовать для атаки перехваченные и сохраненные данные.

Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.

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

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

Успешно пройдя аутентификацию, клиент будет располагать сеансовым ключом, которым впоследствии он будет шифровать все сообщения для KDC и билетом на получение билета (TGT).

Теперь рассмотрим ситуацию, когда клиент хочет обратиться к серверу.

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

Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.

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

Теперь, имея новый ключ и билет, клиент обращается непосредственно к серверу:

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

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

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

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Руководство по выживанию — Kerberos

Это руководство по выживанию посвящено системе Kerberos, в частности, Kerberos V (или Kerberos 5, кому как нравится), разработанной M.I.T.. Предыдущая версия, — Kerberos IV (Kerberos 4), — имеет значительные отличия и в этом руководстве не рассматривается.

Содержание:

Обзор

Kerberos 5 (в дальнейшем в этом тексте называемый просто Kerberos) — это сетевая система аутентификации, определённая в RFC 4120 (с дополнениями в RFC 4537 и RFC 5021, оба добавляют возможности проведения переговоров, но не меняют основу протокола).

Кроме того, в RFC 4121 определён метод, называемый GSSAPI (General Security System Application Program Interface, общий программный интерфейс систем безопасности), с помощью которого Kerberos-совместимые приложения могут напрямую вызвать службу Kerberos. Позднее GSSAPI был трансформирован для поддержки других (не Kerberos) систем обеспечения безопасности.

Kerberos может также использоваться для транспортировки информации по авторизации, но эта возможность рассматривается как специфичная для приложений и не определяется в RFC. Тем не менее, для транспортировки этой информации выделены общие поля (раздел 5.2.6 RFC 4120).

Kerberos широко используется повсюду в мире локальных и глобальных сетей и, возможно, в первую очередь в Microsoft, начиная с Windows 2000. В Kerberos активно используется симметричное шифрование. Голова уже начинает болеть.

И для особо любопытных: название Kerberos является искажением имени Cerberus (Цербер), которое в Древнегреческой мифологии носил трёхголовый пёс, охранявший врата царства мёртвых, чтобы не дать людям улизнуть оттуда.

Обзор Kerberos

Kerberos предоставляет как сетевую аутентификацию, так и безопасный метод, посредством которого может быть проведена авторизация без необходимости повторного ввода пароля или предоставления других удостоверяющих данных. Поэтому он используется для обеспечения того, что обычно называется Технологией единого входа (Single Sign-on, SSO). Для начала несколько общих определений:

Kerberos не делает никаких предположений о защищённости той сети, поверх которой он работает (по факту, он просто ей не доверяет). Однако, он предполагает, что хосты приложений и особенно хост, на котором работает Центр распределения ключей (Key Distribution Center, KDC) Kerberos, являются защищёнными. Особенности Kerberos:

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

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

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

Все коммуникации между аутентифицированными пользователями (клиентами) и сервисами приложений должны иметь возможность быть зашифрованными. С этой целью поддерживаются и могут применяться различные алгоритмы шифрования (все симметричные).

Терминология Kerberos

Как и у всех серьёзных систем, у Kerberos есть своя уникальная терминология, а кое-какие общие термины в контексте Kerberos обретают новый смысл. Постараемся раскрыть их простыми словами (во возможности):

Realm просто означает совокупность пользователей и серверов приложений, которые охватывает (или имеет о них информацию) Центр распределения ключей (KDC). Так, для того чтобы пользователь подсоединился (или вошёл) в Realm, у Сервера аутентификации (Authentication Server) этой области Realm должны быть сведения об удостоверяющих данных этого пользователя (и другая информация о нём), хранящиеся в защищённой базе данных безопасности того или иного вида (форма хранения не определяется в RFC). В терминологии Microsoft это будет называться Доменом (Domain). Области Realm могут доверять другим Realm, в этом случае доверяющие друг другу области должны быть взаимно аутентифицированными (Cross-Authenticated).

Форма имени Realm — . @REALM (регистр символов имеет значение). Например, если Realm называется JOE, то его Realm-имя будет @JOE (что отличается от Realm-имени @joe), а если Realm называется EXAMPLE.COM, то его Realm-имя будет @EXAMPLE.COM. (Примечание: Согласно текущей рекомендации (раздел 6.1 RFC 4120) в качестве имени REALM следует использовать доменное имя, которое часто преобразуется в верхний регистр.) Несмотря на то, что последняя форма может напоминать адрес электронной почты, никакого отношения к электронной почте она не имеет. Если буквы большие, это наверняка REALM, а не почта.

Принципал — это строка, полностью идентифицирующая пользователя службы Kerberos. Он имеет форму thing@REALM. Принципал может быть именем сервиса, выполняющегося на хосте (мы будем называть его принципалом сервиса (Service-Principal)), или именем пользователя (мы будем называть его принципалом пользователя (User-Principal)). Принципалы формируют индексное поле для информации об объекте, хранящейся в базе данных безопасности Kerberos (в Центре распределения ключей или KDC). Форматы принципалов для пользователей и сервисов различаются.

Имя принципала пользователя — это приблизительный эквивалент имени пользователя или имени учётной записи. Оно имеет форму principal-name[/instance-name]@REALM (где часть /instance-name является опциональной). Например, если имя пользователя в принципале пользователя — alice, а Realm — joe, то полный принципал будет alice@joe. Расширение instance-name позволяет любому пользователю иметь более одного принципала. Так, если alice является администратором области Realm joe, имя её принципала будет alice/admin@joe, и у этого принципала будут другие права (и удостоверяющие данные).

Если речь идёт о принципале сервиса, то форма имени принципала становится service-name/QDN@REALM, где QDN — это доменное имя хоста (без точки в конце, как того требует FQDN), на котором работает сервис, а service-name — это специфичная для приложения строка, идентифицирующая сервис на этом хосте. Некоторые типы сервисов используют ключевое слово host. Так, для сервиса ftp, работающего на хосте с именем fileserver.example.com в области Realm @EXAMPLE.COM, имя принципала сервиса будет ftp/fileserver.example.com@EXAMPLE.COM.

Разрешение — это структура данных, содержимое которой известно только издателю этого разрешения, и какой-либо стороне или сторонам, к которым это разрешение имеет отношение. Промежуточные хосты, такие как клиентский хост, рассматривают эти разрешения как неразбираемый набор бит и просто передают их на конечный пункт назначения. В Kerberos разрешения могут быть либо Разрешениями на получение разрешения (Ticket Granting Tickets, TGT), — по сути представляют собой доказательства успешно пройденной аутентификации, — либо Сервисными разрешениями (Service Tickets, ST), — выдаются Службой выдачи разрешений (Ticket Granting Service, TGS) и позволяют пользователю получить доступ к требуемому Сервису приложений (Application Service).

Рисунок 1: Обзор использования Kerberos

Двухминутный тур «Галопом по Kerberos»:

Пользователь выполняет вход в систему на клиентском хосте (1), предоставляя при этом принципал пользователя и требуемый принципал сервиса, которые посылаются (7) Серверу аутентификации (Authentication Server, AS) (2) Центра распределения ключей (KDC) Kerberos (5).

Предположим, что принципал сервиса есть в базе данных безопасности (6). Сервер аутентификации (2) посылает (8) разрешение на получение разрешения (TGT), которое интерпретируется клиентом как неразбираемый набор бит, а также уникальный ключ сессии, зашифрованный удостоверяющими данными принципала пользователя.

При получении этого сообщения, клиент (1) запрашивает удостоверяющие данные пользователя, и, если он сможет расшифровать сообщение (8) с помощью представленных удостоверяющих данных, то эти удостоверяющие данные считаются корректными и пользователь становится аутентифицированным.

Когда аутентифицированный пользователь захочет получить доступ к сервису, клиент (1) посылает сообщение (9) Службе выдачи разрешений (Ticket Granting Service, TGS) (3) в составе KDC (5). В этом сообщении содержится TGT (полученный в сообщении (8)), а также имя требуемого принципала сервиса.

TGS (3) отправляет ответ (10) с сервисным разрешением (ST), разрешающим использование запрашиваемого сервиса. Это сервисное разрешение интерпретируется клиентом как неразбираемый набор бит.

Клиент (1) посылает (11) сервисное разрешение (ST) соответствующему Серверу приложений (Application Server) (4).

Сервер приложений (4) использует сервисное разрешение (ST) для проверки того, что запрашивающий авторизован на использование этого сервиса. Он отправляет ответ (12), только если клиент (1) запрашивал выполнение взаимной аутентификации, в противном случае с получением сообщения (11) процесс считается завершённым и можно начинать использовать сервис.

Kerberos — этап входа в систему

В этом разделе несколько более подробно (но не исчерпывающе) описываются различные диалоги протокола. В мельчайших подробностях форматы сообщений определяются в RFC 4120, и для каждого типа сообщения мы приведём ссылку на соответствующий раздел этого документа. Цифры в скобках, встречающиеся в тексте, относятся к приведённому ниже рисунку 2:

Клиент (1) посылает сообщение KRB_AS_REQ (7) (оно же «Первоначальный запрос аутентификации» («Initial Authentication Request»)) Серверу аутентификации (AS) (2), который логически является составной частью KDC (5). Это сообщение посылается открытым текстом (без какого-либо шифрования). Оно содержит имя принципала пользователя, имя принципала сервиса, к которому пользователь хочет подключиться (как правило, принципала Службы выдачи разрешений (TGS), имеющего название krbtgt/REALM@REALM), опциональный список IP-адресов, которые пользователь хочет использовать, опциональное время жизни для этого входа в систему, а также метку nonce (случайное число), используемую как для идентификации ответов, так и для снижения риска подвергнуться атакам воспроизведения (replay attacks).

Сообщение KRB_AS_REQ определено в разделах 3.1.2 и 5.4.1 RFC 4120.

При получении этого сообщения AS (2) проверяет наличие принципала пользователя и принципала сервиса в базе данных безопасности (6) и выдаёт сообщение об ошибке, если они не найдены. Примечание: RFC по Kerberos оставляют формат базы данных безопасности на усмотрение разработчиков системы. В мире Windows это Active Directory (структура, основанная на LDAP).

Сервер аутентификации (2) отвечает одним сообщением KRB_AS_REP (8), которое состоит из:

Случайным образом сгенерированного ключа сессии, времени жизни этого ключа, отметки времени timestamp и копии метки nonce, полученной от клиента (1). Эта информация шифруется с использованием удостоверяющих данных принципала пользователя.

Разрешения на получение разрешения (TGT), зашифрованного с использованием ключа сервиса, запрашиваемого клиентом (обычно Службы выдачи разрешений). Это TGT, с точки зрения клиента, является неразбираемым набором бит, который просто передаётся TGS (3) при запросе доступа к конкретному Сервису приложений (4). Клиент не может интерпретировать содержимое TGT, поскольку у него нет (да ему и не надо) ключа, с помощью которого его можно было бы расшифровать.

Сообщение KRB_AS_REP определено в разделах 3.1.3 и 5.4.2 RFC 4120.

При получении этого сообщения (8) клиент (1) может наконец запросить удостоверяющие данные пользователя и использовать их в качестве ключа для выполнения дешифрования полученного сообщения. Если удалось успешно расшифровать сообщение и исходная метка nonce оказалась верной, то удостоверяющие данные пользователя должны быть корректными. После этого сведения об удостоверяющих данных пользователя могут быть сразу же забыты. Хотя системы, проводящие аутентификацию, могут запросить ввести удостоверяющие данные в тоже самое время, когда вводится имя учётной записи пользователя, на самом деле это не требуется, поскольку протокол Kerberos позволяет отложить запрос удостоверяющих данных вплоть до этого шага, чтобы минимизировать возможные негативные последствия при использовании небезопасной хост-системы или ПЭВМ.

Если предположить, что удостоверяющие данные были правильными, то пользователь с настоящего момента считается аутентифицированным KDC. У него также есть TGT (неразбираемый набор бит) и ключ сессии, так что теперь он может перейти к запросу сетевых сервисов с соответствующего Сервера приложений (4). Эти запросы описаны далее.

Рисунок 2: Операции Kerberos

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

Kerberos — запросы сервисов приложений

Цифры в скобках, встречающиеся в тексте, относятся к приведённому выше рисунку 2:

Если пользователь желает использовать сетевой сервис, он должен сначала получить Сервисное разрешение от TGS (3) KDC (5). Клиент (1) создаёт сообщение KRB_TGS_REQ (9) в Службу выдачи разрешений (TGS) (3) на получение Сервисного разрешения (ST) для целевого Сервиса приложений. Содержимое сообщения KRB_TGS_REQ:

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

TGT (неразбираемый набор бит), которое было получено клиентом во время последовательности обмена сообщений этапа входа в систему. Оно уже зашифровано ключом, который неизвестен клиенту, но может быть получен TGS (3) из базы данных безопасности (6) с использованием принципала пользователя.

Структура Authenticator, которая состоит в основном из принципала клиента (Client-Principal), метки nonce (случайное число) и других данных. Authenticator шифруется с помощью ключа сессии, полученного во время последовательности обмена сообщений этапа входа в систему. Опционально, вместе с Authenticator клиент может предложить «подключ» (по существу, замену ключа сессии). При наличии этого подключа, TGS (3) должен использовать его для шифрования ответа.

Сообщение KRB_TGS_REQ определено в разделах 3.2.2 и 5.4.1 RFC 4120. Оно посылается (9) Службе выдачи разрешений (TGS) (3) KDC (5).

TGS (3) отвечает сообщением KRB_TGS_REP (10), которое состоит из:

Случайным образом сгенерированного ключа сессии сервиса приложений (который будет использоваться для шифрования последующих сообщений между клиентом (1) и Сервисом приложений (4)), времени жизни этого ключа, отметки времени timestamp, принципала сервиса, который был запрошен, и копии метки nonce (случайное число), отправленной клиентом (1). Эта информация зашифрована либо с использованием ключа сессии, полученного во время последовательности обмена сообщений этапа аутентификации, либо с использованием подключа (замены ключа сессии), предложенного клиентом в сообщении KRB_TGS_REQ.

Сервисного разрешения (ST), зашифрованного с использованием ключа Сервера приложений, на котором выполняется запрашиваемый клиентом сервис. Это разрешение содержит множество информации, интересной Сервису приложений. С точки зрения клиента, ST представляет собой неразбираемый набор бит, который передаётся Серверу приложений, когда тот требует подтвердить свои права. Клиент не может интерпретировать содержимое ST, поскольку у него нет (да ему и не нужно) каких-либо ключей, которыми он мог бы его расшифровать. Важная часть содержимого ST — копия ключа сессии сервиса приложений, сгенерированного TGS и также отправленного клиенту (смотрите пункт a). Примечание: Серверы приложений также проходят аутентификацию в KDC (5), используя процедуру, практически аналогичную описанной выше для аутентификации пользователя.

Сообщение KRB_TGS_REP определено в разделах 3.2.4 и 5.4.2 RFC 4120.

Клиент (1) расшифровывает свою часть структуры с помощью либо ключа сессии, либо предложенного им подключа, и извлекает и сравнивает метку nonce. Он также извлекает новый ключ сессии сервиса приложений.

Наконец, клиент (1) посылает Серверу приложений (4) сообщение KRB_AP_REQ (11) на запрос доступа. Это сообщение состоит из:

Структуры Authenticator пользователя, как определено выше для сообщения KRB_TGS_REQ. Эта структура Authenticator зашифрована с помощью ключа сессии сервиса приложений, полученного из предыдущего сообщения KRB_TGS_REP (10).

Сервисного разрешения, полученного в предыдущем ответе (10).

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

Сообщение KRB_AP_REQ определено в разделах 3.3.1 и 5.5.1 RFC 4120.

Сервер приложений (4) отвечает (12) сообщением KRB_AP_REP только в случае, если была запрошена взаимная аутентификация. В противном случае считается, что целевой сервис доступен и ожидает поступления клиентских данных.

Сообщение KRB_AP_REP определено в разделах 3.3.3 и 5.5.2 RFC 4120.

В разрешениях (как TGT, так и ST) могут опционально содержаться данные авторизации (раздел 5.2.6 RFC 4520). Конкретное содержимое этих полей специфично для разных типов приложений. Microsoft использует эти поля с данными авторизации для передачи Атрибутных сертификатов привилегий (Privilege Attribute Certificates, PAC).

RFC по теме

Неполный список связанных с Kerberos RFC.

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Источник