ActiveDirectory/Kerberos/Tickets

Что это такое

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

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

Термины

Realm

область/домен организации или подразделения, определяет логические границы

Principal name

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

UPN (User Principal Name)

основное имя/принципал пользователя

SPN (Service Principal Name)

основное имя/принципал службы

Authenicator

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

Ticket

билет; является записью с личностью пользователя, которая используется для аутентификации с сервером совместно с аутентификатором

KDC (key distribution server)

сервер, предоставляющий билеты и временные сессионные ключи; состоит из сервера аутентификации (AS) и сервера выдачи билетов (TGS)

AS (authentication server)

сервер аутентификации, предоставляющий первичный билет (TGT) для доступа к TGS

TGS (ticket-granting server)

сервер выдачи билетов для доступа к другим серверам/службам

TGT (ticket-granting ticket)

билет на выдачу билетов; позволяет получить билет для сервера/службы в указанном realm

Service ticket

билет для доступа к конечному серверу/службе

PAC (privilege attribute certificate)

сертификат атрибутов привелегий; дополнительная информация о пользователе, включающая в себя список групп, дополнительные учетные данные для аутентификации не через Kerberos и инормацию управления политикой для поддержки интерактивного входа (специфична для серверов в доменах Microsoft Active Directory)

Session key

временный ключ шифрования, используемый клиентом и сервером для аутентификации

Secret key

долговременный ключ шифрования пользователя/сервера/службы; для пользователя обычно являющийся производным от пароля (хэшем), может хранится на смарт-карте/токене

Sub-session key

дополнительный временный ключ шифрования, используемый клиентом и сервером для увеличения защищенности передаваемых данных аутентификации

Keytab

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

Credential cache

кэш учетных данных; определенное место (файл, область оперативной памяти), в котором хранятся полученные билеты и сессионные ключи

Principal

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

component1/component2/.../componentN@REALM

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

Name[/Instance]@REALM

Instance является необязательной частью имени и используется для уточнения типа пользователя. В Active Directory это поле не используется .

Если запись связана со службой, то имя имеет следующий формат:

Service/Hostname@REALM

Первый компонент имени является именем службы, например, imap, ldap, ftp, http. Часто компонент является просто словом "host", использующееся для обозначения удаленного доступа к компьютеру (telnet, ssh). Второй компонент является полным именем компьютера (FQDN) предоставляющей указанную службу. Важно, чтобы этот компонент (имя компьютера) точно совпадало с обратной записью DNS по IP-адресу компьютера. Например, данные имена являются службами:

imap/mbox.example.com@EXAMPLE.ALT
host/server.example.com@EXAMPLE.ALT

Также, есть имена, которые являются исключениями и не связаны с пользователем, компьютером или службой. Например, имя krbtgt/REALM@REALM используется для службы TGS, которая выдает билет на выдачу билетов (TGT).

Что содержит билет

При успешной аутентификации пользователь получает:

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

Информация о билете для пользователя:

Незашифрованная часть:

• realm пользователя
• UPN

Зашифрованная часть:

• сессионный ключ шифрования
• флаги
• список последних запросов пользователя (время последнего запроса)
• случайное число сгенерированное клиентом (используется для определения атак с повторной отправкой пакетов)
• срок действия пароля/долговременного ключа шифрования
• время выдачи предыдущего/первчиного билета
• время начала действия билета (необязательно, может использоваться время выдачи предыдущего билета вместо)
• время окончания действия билета
• время, до которого возможно обновление билета (если есть флаг разрешающий обновление)
• realm службы
• SPN
• адреса клиентов, на которых может использоваться билет (если отсутствует, то везде)

Билет содержит в себе:

Незашифрованная часть:

• realm который выдал билет (также является realm службы)
• SPN

Зашифрованная часть:

• сессионный ключ шифрования
• флаги
• realm клиента, откуда был запрошен билет
• UPN
• список realm через которые прошла аутентификация (раздел 3.3.3.2 RFC 4120)
• время выдачи предыдущего/первичного билета
• время начала действия билета (необязательно)
• время окончания действия билета
• время, до которого возможно обновление билета (если есть флаг разрешающий обновление)
• адреса клиентов, на которых может использоваться билет (если отсутствует, то везде)
• данные авторизации (необязательно, набор ограничений/запретов по дальнейшему взаимодействию с билетом, раздел 5.2.6 RFC 4120; содержит PAC)

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

Каждый билет имеет срок действия (по умолчанию, 10 часов). Так как сервер аутентификации не имеет возможности взаимодействовать с уже выданными билетами, то для ограничения времени в течение которого можно злоупотреблять им, билет имеет ограничение по сроку действия. Администратор realm может лишь прекратить выдачу новых билетов для конкретного пользователя в любой момент времени, но не может запретить использовать уже выданные билеты.

Флаги, которые может иметь билет:

• Перенаправляемый (Forwardable, F)
  Если билет перенаправляемый, то KDC может выдать новый билет с другим сетевым адресом на основе этого билета. Это позволяет перенаправить данные об аутентификации без повторного ввода пароля. Например, если пользователь имеет перенаправляемый TGT и использует удаленный доступ для входа на другой компьютер, то KDC может выдать новый TGT для этого пользователя с сетевым адресом удаленного компьютера, позволяя аутентификации на этом компьютере работать так, будто пользователь вошел в систему локально.

• Перенаправленный (Forwarded, f)
  Когда KDC создает новый билет на базе перенаправляемого, он устанавливает данный флаг на новом билете. Билеты, которые созданы на базе билета с данным флагом, тоже будут иметь данный флаг.

• Разрешен для уполномочивания (Proxiable, P)
  Билет, разрешенный для уполномочивания, схож с перенаправляемым билетом, т.к. он разрешает службе использовать личность пользователя. В отличие от перенаправляемого билета, билет с данным флагом выдается только для определенных служб. Также, билет с данным флагом нельзя использовать для получения TGT, в отличие от перенаправляемого.

• Уполномоченный (Proxy, p)
  Данный флаг устанавливается на билете который был выдан на основе билета, разрешенного для уполномочивания.

• Отсроченный (Postdated, d)
  Отсроченный билет выдается с флагом "недействительный". После того, как наступит время с которого он действителен, он может использоваться для получения действительных билетов.

• Разрешен для отсрочки (Postdateable, D)
  TGT с данным флагом могут использоваться для получения отсроченных билетов .

• Возобновляемый (Renewable, R)
  Возобновляемые билеты могут быть использованы для получения нового билета (новых сессионных ключей) без повтороного ввода пароля. Возобновляемый билет имеет два срока истечения действия: время истечения самого билета и последнее возможное время истечения для последующих билетов, которые выданы на основе этого возобновляемого билета.

• Первичный (Initial, I)
  Билет с данным флагом может выдать только сервер аутентификации (AS). Таким билетом является TGT, а также билет службы, полученный напрямую без использования TGT.
  Сервера служб, которые хотят удостовериться, что билет был получен недавно, могут потребовать билет с таким флагом (см. #Процесс получения билета службы без TGT)

• Недействительный (Invalid, i)
  Билет с данным флагом должен отвергаться серверами служб. Отсроченные билеты выдаются с данным флагом и должны быть проверены KDC перед тем как могут быть использованы.

• Предварительно аутентифицирован (Preauthenticated, A)
  Данный флаг показывает, что пользователь прошел предварительную аутентификацию (ввел пароль) для получения билета.

• Аутентифицирован аппаратно (Harware authenticated, H)
  Данный флаг показывает, что использовалось внешнее устройство для аутентификации. Предполагается, что устройством владеет только сам пользователь, запросивший билет.

• Политика транзита проверена (Transit policy checked, T)
  Билет с данным флагом показывает, что KDC, который выдал данный билет, имеет политику проверки транзитных realm (через которые прошла аутентификация) при перекрестной аутентификации. Билет содержит список всех realm которые использовалисб для прохождения аутентификации (см. #Список realm через которые прошла аутентификация). Если флаг не установлен, то сервер службы должен самостоятельно проверить транзитные realm, иначе требуется отклонить аутентификацию с таким билетом.

• Разрешен для делегирования (Okay as delegate, O)
  Данный флаг показывает, что сервер, указанный в билете, разрешен как делегат (посредник) с учетом политик установленных в данном realm. Некоторые приложения могут использовать данный флаг для разрешения перенаправления билетов на другой удаленный сервер, но не все приложения это соблюдают.

• Анонимный (Anonymous, a)
  Анонимный билет не указывает пользователя (UPN), который на самом деле будет использовать данный билет. Вместо него используется принципал "по умолчанию" данного realm. Такой билет используется только для безопасной передачи сессионного ключа.

Более подробно о формате билета и его полей можно посмотреть в RFC 4120.

Список realm через которые прошла аутентификация

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

Если указанный сервер в TGT, который передан KDC, является службой TGS, но TGT выдан другим realm, KDC попробует найти общий ключ шифрования для связи (inter-realm) и использует его для расшифровки билета. Если билет действителен, то KDC выполнит запрос на выдачу билета для службы, следуя тому же алгоритму, как и при одинаковых realm.

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

Аутентификатор

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

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

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

Кэш повторов

Существует вероятность того, что злоумышленик сможет перехватить как билет, так и аутентификатор и использовать их в течение двух минут, пока аутентификатор не истек. Это очень сложно, но не невозможно. Чтобы решить эту проблему, был добавлен механизм кэша повторов.

В серверах приложений/служб, а также в TGS, есть возможность запоминать аутентификаторы которые были приняты за последние две минуты и отклонять их, если они были повторами/копиями.

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

PAC

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

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

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

Если валидация PAC включена на клиенте, необходимо удостовериться в том, что необходимые ключи доступны для использования службам, которые отвечают за процесс аутентификации (sssd или winbind).

Более подробно о формате PAC и его содержимом можно посмотреть в MS-PAC.

Получение билета

Примечание: AS и TGS являются одним и тем же логическим сервером (сервером Kerberos), несмотря на то, что описываются как отдельные (раздел 1.1 RFC 4120).

Примечание: предварительная аутентификация используется по умолчанию в доменах Active Directory

Есть несколько способов получения билета:

• получить билет определенной службы напрямую
• получить TGT, затем, при помощи него получать все последующие билеты для служб
• получить TGT, затем, получить TGT для другого realm, затем, получать все последующие билеты для служб в другом realm

Предварительная аутентификация

Перед тем как выдать билет, KDC проверяет наличие запрашиваемых UPN и SPN в базе данных. Если требуется выдать TGT, тогда достаточно знать, что UPN существует, потому что krbtgt/EXAMPLE.ALT@EXAMPLE.ALT точно существует. Очевидно, что выданный TGT, если запрос получен от злоумышленника, не может быть использован, т.к. он не знает пароля и не сможет получить сессионный ключ для создания достоверного аутентификатора.

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

Если политики KDC требуют предварительную аутентификацию для первичного запроса клиента, то AS ответит на запрос с ошибкой, которая сообщит о том, что необходимо ее осуществить.

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

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

Предварительная аутентификация является необязательной и может быть отключена. Kerberos из состава Active Directory по умолчанию запрашивает ее, в отличие от MIT или Heimdal Kerberos.

Процесс получения TGT

1. Клиент вводит пароль или указывает ключ шифрования из keytab (для шифрования данных предварительной аутентификации)

2. Клиент отправляет запрос AS_REQ к AS (со своим UPN user/EXAMPLE.ALT, и SPN krbtgt@EXAMPLE.ALT/EXAMPLE.ALT), а также данные предварительной аутентификации

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

4. Клиент использует пароль (его хэш) или использует ключ шифрования из keytab для расшифровки сессионного ключа для TGS (билет TGT остается зашифрованным)

После этого, пользователь может предоставлять билет TGT для доступа к другим службам в этом realm.

Процесс получения билета службы

1. Клиент отправляет запрос TGS_REQ к TGS, содержащий имя службы, аутентификатор (зашифрованный сессионым ключом для связи с TGS) и билет TGT

2. Клиент получает ответ TGS_REP, расшифровывает данные при помощи сессионного ключа, получает расшифрованные данные в виде сессионного ключа для сервиса и информацию о нем (SPN, время жизни и т.д.) и сам билет для службы

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

Процесс получения билета службы без TGT

Первичным билетом называют то, что получено напрямую от AS, т.е. когда пользователю необходимо предоставить пароль или долговременный ключ. Исходя из этого, можно сделать вывод, что TGT всегда является первичным билетом. При этом, билеты для служб выдаются TGS при предоставлении TGT и, соответственно, не являются первичными билетами. Но, есть исключение: чтобы гарантировать что пользователь ввел пароль недавно (за пару секунд до), некоторые приложения могут потребовать чтобы билет для службы был первичным. В этом случае, билет, хоть и не являющийся TGT, запрашивается напрямую от AS и, соответственно, является первичным.

1. Клиент вводит пароль или указывает ключ шифрования из keytab (для шифрования данных предварительной аутентификации)

2. Клиент отправляет запрос AS_REQ к AS (со своим UPN user/EXAMPLE.ALT, и SPN imap/mbox.example.com@EXAMPLE.ALT), а также данные предварительной аутентификации

3. Клиент получает ответ AS_REP, содержащий сессионный ключ (для связи со службой), информацию о билете и сам билет для службы

4. Клиент использует пароль (его хэш) или использует ключ шифрования из keytab для расшифровки сессионного ключа для службы (сам билет остается зашифрованным)

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

Получение билета в доверенных доменах

Ранее была упомянута возможность пользователя принадлежащего к одному realm аутентифицироваться и получать доступ к службам другого realm.

Эта возможность, известная как перекрестная аутентификация, основана на предположении что существуют доверительные отношения между realm участвующими в процессе.

Это доверие может быть односторонним, т.е. пользователи realm A могут получить доступ к службам realm B, но не наоборот, или двухсторонним, где, как можно догадаться, возможно обратное.

Доверительные отношения разделяют на прямые, транзитивные и иерархические.

Подробнее о доверительных отношениях в доменах AD: ActiveDirectory/Trusts.

Прямые доверительные отношения

Этот тип доверительных отношений самый простой, является основой перекрестной аутентификации и используется для реализации двух других типов довертительных отношений.

Данное отношение используется, когда KDC realm B имеет непосредственное доверие к KDC realm A, позволяя пользователям из realm A получать доступ к его ресурсам. С технической точки зрения, прямое доверие достигается наличием у участвующих в доверительных отношениях KDC долговременного ключа шифрования. Если требуется обеспечить двухстороннее доверие, то ключей будет два (от A к B, от B к A).

Для осуществления этого механизма, используется так называемый удаленный TGT и, на примере realm A и B, имеет имя krbtgt/B@A и добавляется на оба KDC с одним и тем же долговременным ключом шифрования.

Этот ключ шифрования гаранитриует доверие между двумя realm. Чтобы реализовать двухстороннее доверие, необходимо создать второй удаленный TGT вида krbtgt/A@B с одинаковым новым ключом шифрования на каждом KDC.

Введение удаленных TGT делает перекрестную аутентификацию подвидом (обобщением) обычной аутентификации внутри одного realm: это подчеркивает, что предыдущее описание работы Kerberos остается действительным, если принять как исключение, что TGS одного realm может проверять удаленные TGT другого realm выданные TGS того realm.

Обратите внимание на небольшое расхождение: удаленные TGT выдаются не AS, как обычные TGT внутри одного realm, а TGS локального realm (клиента) при выдаче TGT этого realm.

Рассмотрим пример. Предположим, что пользователь tux из realm EXAMPLE.ALT, чье имя tux@EXAMPLE.ALT, хочет получить доступ к серверу dc.test.alt принадлежащему realm TEST.ALT по протоколу SSH:

• если tux еще не получил TGT в realm EXAMPLE.ALT, он делает первчиный запрос аутентификации (выполнив команду kinit). Ответ приходит от AS его realm
• далее, он выполняет команду ssh tux@dc.test.alt которая должна подключиться к dc.test.alt без запроса пароля;
• клиент SSH делает два DNS запроса: определяет IP-адрес сервера dc.test.alt и запрашивает обратную DNS запись для получения полного имени сервера (FQDN) в канонической форме (в данном случае, совпадает с dc.test.alt);
• клиент SSH понимает, с использованим полученных данных от DNS, что удаленный сервер не принадлежит realm пользователя и запрашивает у TGS realm EXAMPLE.ALT (обратите внимание, что он запрашивает данные у TGS именно своего(локального) realm) удаленный TGT krbtgt/TEST.ALT@EXAMPLE.ALT;
• далее, он запрашивает у TGS realm TEST.ALT билет службы host/dc.test.alt@TEST.ALT, используя полученный удаленный TGT;
• когда TGS realm TEST.ALT получает запрос, он проверяет наличие принципала krbtgt/TEST.ALT@EXAMPLE.ALT в своей базе данных, при помощи которого он может проверить доверительные отношения. Если проверка прошла успешно, билет для службы (зашифрованный ключом принципала host/dc.test.alt@TEST.ALT) выдается пользователю, который посылает его на сервер dc.test.alt для получения доступа к серверу по SSH.

Транзитивные доверительные отношения

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

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

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

Иерархические доверительные отношения

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

Keytab

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

По умолчанию, на компьютере присоединенному к домену, существует файл /etc/krb5.keytab, содержащий ключ службы host компьютера и ключ учетной записи компьютера.

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

Кэш учетных данных (билетов)

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

Существует несколько типов кэша:

• FILE:<путь>
  Хранит кэш в указанном файле на диске.
• DIR:<путь>
  Хранит несколько файлов кэша, которые могут быть организованы по отдельным realm или разным KDC.
• MEMORY
  Хранит кэш в оперативной памяти, закреплен за текущим процессом. При закрытии процесса автоматически удаляется.
• KEYRING:<имя>
  KEYRING:process:<имя>
  KEYRING:thread:<имя>
  KEYRING:session:<имя>
  KEYRING:user:<имя>
  Хранит кэш в области оперативной памяти, которая доступна только ядру ОС и не попадает в файл/раздел подкачки на диск. Может быть системным, закрепленным за отдельным процессом или потоком, за отдельной сессией, за отдельным пользователем.
• KEYRING:PERSISTENT:<uid>
  Закреплен за пользователем, но не удаляется при выходе пользователя из системы.
• KCM
  Использует отдельную службу (сервер KCM) для хранения кэша, которая имеет контроль над билетами, отслеживает их срок действия и управляет ими. Может сохранять данные на диск, чтобы не терять их при перезапуске службы или перезагрузке компьютера.

Получение билета для пользователя

Данный процесс на рабочей станции осуществляет пользователь вручную при помощи kinit или GSSAPI (из интерфейса приложения), или автоматически при входе в пользователя (при помощи winbind или sssd).

Чтобы аутентифицироваться при помощи пароля:

$ kinit
$ kinit <UPN пользователя>

Команда для получения билета службы с использованием TGT:

$ kvno <SPN службы>

Команда для получения билета службы напрямую:

$ kinit -S <SPN службы>
$ kinit -S <SPN службы> <UPN пользователя>

Получение билета для компьютера (из keytab)

Со стороны Kerberos, учетная запись компьютера является таким же Principal, как и обычный пользователь. Отличие - долговременный ключ шифрования хранится в keytab и доступен только пользователю root (по умолчанию).

Чтобы воспользоваться keytab для аутентификации, необходимо выполнить следующую команду:

$ kinit -k -t /etc/krb5.keytab COMPUTER\$@EXAMPLE.ALT

Команда для получения билета службы с использованием TGT:

$ kvno <SPN службы>

Команда для получения билета службы напрямую:

$ kinit -k -t /etc/krb5.keytab -S <SPN службы>
$ kinit -k -t /etc/krb5.keytab -S <SPN службы> <UPN пользователя>

Подробнее об учетной записи компьютера: ActiveDirectory/MachinePassword.

Создание ключей для службы

Подробнее о настройке: Создание_SPN_и_Keytab_файла.

Конфигурация krb5.conf

Файл конфигурации Kerberos (его библиотек и вспомогательных программ) находится в /etc/krb5.conf.

Конфигурация может быть дополнена файлом по указанному пути или директории с файлами (например, /etc/krb5.conf.d/):

include <путь_к_файлу>
includedir <путь_к_директории>

• [libdefaults]
  Общие настройки для Kerberos
  • canonicalize
    Нормализация имени принципала, приведение его к форме, записанной в базе данных
  • clockskew
    Максимально возможное отклонение времени между клиентом и сервером
  • default_ccache_name
    Название (путь) к кэшу учетных данных, который используется по умолчанию
  • default_realm
    Название realm, которое используется по умолчанию (например, при вводе имени пользователя без указания realm)
  • renew_lifetime
    Время, в течение которого можно обновить билет
  • ticket_lifetime
    Время действия билета

• [realms]
  Настройки realm: адреса KDC и т.д.

• [domain_realm]
  Правила сопоставления имен компьютеров (DNS имен) именам realm.

• [capaths]
  Правила (пути) для определения серверов, необходимых для осуществления прямой перекрестной аутентификации.

• [appdefaults]
  Настройки для определенных приложений, которые можно сгруппировать по имени приложения или имени realm.

• [plugins]
  Список подключаемых модулей, которые требуют регистрации для их включения.

Настройки pkinit для предварительной аутентификации с использованием смарт-карт или токенов (вместо пароля) указываются в [libdefaults] для общих настроек для всех realm, или в [realms] для опредленного realm.

Более подробное описание всех настроек можно найти в man krb5.conf.

Отладка

Для нахождения проблем в процесс аутентификации, необходимо установить переменную окружения KRB5_TRACE=<путь к файлу> перед запуском приложения, которое требует проверки:

$ KRB5_TRACE=/dev/stdout kinit

/dev/stdout будет выводить сообщения в терминал для просмотра в реальном времени.

При использований приложений/служб на Java можно использовать флаги:

• -Dsun.security.krb5.debug=true для отладки обмена с KDC и клиентом
• -Dsun.security.spnego.debug=true для отладки при использовании SPNEGO (например, веб-сервер)

Для отладки проблем при входе в систему (проблемам с PAM), можно включить вывод сообщений pam_winbind, добавив или раскоментировав строки в файле /etc/security/pam_winbind.conf:

debug = yes
debug_state = yes
silent = no

После этого, в журнале системы можно посмотреть сообщения от pam_winbind (параметр -b 0 показывает сообщения с момента включения компьютера):

# journalctl -b 0 -g pam_winbind

Для сервера Samba можно включить вывод сообщений изменив параметр "log level" файла /etc/samba/smb.conf:

log level = kerberos:10

Журнал сообщений, которые записывает Kerberos, будет находится в файле /var/log/log.wb-<имя домена>.

Для сервера MIT Kerberos можно включить журналы ошибок в разделе [logging] файла конфигурации kdc.conf (см. man kdc.conf или описание файла на сайте MIT).

На клиентах под управлением Windows можно включить вывод сообщений Kerberos в Журнал событий: How to enable Kerberos event logging.

Некоторые ошибки могут быть связаны не с KDC или клиентом напрямую, а с другими службами домена. О различных способах отладки проблем домена написано в Домен/Решение проблем и Диагностические_инструменты.

Обновление билетов

У билета есть три времени — начало действия билета, конец действия билета и разрешенный период обновления билета. Начало и конец составляют период жизни билета.

Билет действителен в рамках периода жизни, а также может быть обновлен в любой (почти) момент времени в этих рамках. Обновление требуется для продления срока действия билета. Если период жизни вышел за разрешенный период обновления, то обновить билет больше нельзя, требуется получить новый.

Обновить билет вручную можно выполнив команду:

$ kinit -R

Интервалы жизни/обновления, как задать?

Интервал обновления билетов

Примечание: данная проблема больше актуальна для sssd и sssd-kcm, т.к. winbind имеет фиксированный интервал, равный половине жизни билета.

Обозначим, что:

• S — начало действия билета
• E — конец действия билета
• R — период, на котором возможно обновление билета
• T — период обновления билета

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

На промежутке от S до E можно обновлять билет, пока E меньше R. Иначе, потребуется получить новый билет, что потребует ввода пароля.

Помимо конца действия билета, существует «мертвая зона», в которой нельзя обновить билет. Она равняется двум минутам до конца действия билета . Это накладывает ограничение на интервал обновления билетов.

Например, интервал обновления равен половине срока жизни билета. Тогда, если таймер обновления сработает в ((E1 — S1)/2 — 2) или ровно в (E1 — S1)/2, то второе его срабатывание выпадет на последние две минуты жизни билета и обновление не произойдет.

Q: Почему время между S1 и Т1 меньше, чем между T1 и T2 (иначе говоря, разный интервал)?
A: Таймер для интервала обновления не перезапускается, если, например, пользователь получил билет вручную или вышел и зашел в систему заново, не перезагружая компьютер. Поэтому, начало интервала T1 находится до получения билета.

Q: Почему не будет первого срабатывания, если таймер достиг половины жизни билета?
A: Проверка осуществляется со знаком «больше», а не «больше или равно». С учетом погрешностей, таймер может сработать как за 1 секунду до, так и после. Также, если интервал будет почти равен половине жизни билета, то даже если таймер начнет отсчет ровно от начала действия билета, то он все равно попадет в мертвую зону.

Чтобы этого избежать, интервал обновления билета должен быть минимум на две минуты меньше половины его срока жизни. Если учесть, что может существовать разница во времени между клиентом и сервером, то необходимо заложить как минимум одну минуту на это. Тогда, даже если таймер сработает в ((E — S)/2 — 2), то следующее срабатывание произойдет вне «мертвой зоны».

Исходя из этого, можно получить два варианта для значения интервала обновления:

• T = (любое время), где T <= (E — S)/2 — 3 мин.
• T = (E — S)/4, где (E — S) >= 12 минут

Второй вариант проще и более реалистичный. Он проверяет достаточно часто, но и не редко. При стандартном значении в 24 часа (или 10 часов в Active Directory), получим интервал обновления равным 6 часам (2.5 часа).

Q: Почему не рекомендуется установить время обновления в несколько минут? Тогда и «мертвая зона» никогда не наступит.
A: Это может вызвать большую нагрузку на сервер(а) Kerberos, особенно при большом количестве рабочих станций.

Настройка времени жизни билетов на сервере

Active Directory, как и Samba, имеет следующие параметры для срока действия билетов:

• Максимальный срок действия билета пользователя
• Максимальный срок действия билета службы
• Максимальный срок жизни для возобновления билета пользователя

"Максимальный срок действия билета службы" присутствует только на серверах MS AD и Samba, на сервере MIT Kerberos нельзя задать отдельно срок жизни билета для службы.

Значения 10 часов и 7 дней являются стандартными для MS AD, соответственно и для Samba.

Задание параметров Samba KDC возможно как в файле конфигурации /etc/samba/smb.conf, так и через политики безопасности. Последние требуют выполнения samba-gpupdate на контроллере домена/KDC для их применения.

https://wiki.samba.org/index.php/Samba_KDC_Settings

This option sets the command that is called to apply GPO policies. The samba-gpupdate script applies System Access and Kerberos Policies to the KDC. System Access policies set minPwdAge, maxPwdAge, minPwdLength, and pwdProperties in the samdb. Kerberos Policies set kdc:service ticket lifetime, kdc:user ticket lifetime, and kdc:renewal lifetime in smb.conf.

Примечание: установка некоторых значений параметров(а) через политики ломает Samba и невозможно войти в пользователя или получить билет службы.

Время в /etc/samba/smb.conf задается только в часах, целым числом. /etc/krb5.conf на клиенте умеет указывать время в секундах, минутах, часах, днях. Сервер MIT Kerberos тоже умеет задавать время в данном формате .

https://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/kdc_conf.html

Значние для "ticket_lifetime" и "renew_lifetime" выбирается наименьшее из двух (клиента и сервера). Если клиент запросил меньше, чем указано на сервере, то это будет разрешено.

Настройка времени жизни билетов и интервала обновления на клиенте

В файле /etc/krb5.conf в разделе [libdefaults]

[libdefaults]
ticket_lifetime = 8h
renew_lifetime = 1d

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

sssd

В файле /etc/sssd/sssd.conf в разделе [domain/<имя_домена>]. Значение указывается целым числом в секундах, либо с одной единицей измерения (s для секунд, m для минут, h для часов, d для дней). Указывать две и более единиц времени нельзя.

[domain/<имя_домена>]
krb5_lifetime = 8h
krb5_renewable_lifetime = 1d

При использовании KCM, эти параметры необходимо указать в разделе [kcm]

[kcm]
krb5_lifetime = 8h
krb5_renewable_lifetime = 1d

Взаимодействие пользователя и программ

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

• Повторное получение билета
  Если пользователь решит получить билет по новой, то все три доступных способа обновят этот билет.
  Исключения:
  • Был запрошен/получен билет с меньшим временем жизни
    Последствия — может не произойти обновления, т. к. таймер рассчитывает на старое время жизни билета.
• Удаление билета
  Если пользователь решит удалить билет, то только winbind сможет получить новый билет автоматически, т. к. он имеет доступ к паролю от учетной записи пользователя.
• Удаление и повторное получение билета
  Если пользователь решит удалить билет и тут же получить билет по новой, то все три доступных способа обновят этот билет.
  Исключения:
  • Был запрошен/получен билет с меньшим временем жизни
    Последствия — может не произойти обновления, т. к. таймер рассчитывает на старое время жизни билета.
  • Пользователь получил билет после срабатывания таймера
    Последствия — sssd удалит хранилище билетов пользователя из списка наблюдения и не обновит билет.
• Потеря соединения с сервером Kerberos
  Если пропадет соединение из-за проблем с каналом связи или из-за неполадок на самом сервере Kerberos, то, при наличии действующего билета, он будет обновлен. Иначе, потребуется получение нового билета.
  Только winbind сможет получить новый билет автоматически, т. к. он имеет доступ к паролю от учетной записи пользователя.
• Спящий режим
  При использовании спящего режима нужно убедиться, что включена блокировка экрана при переходе в него. Так как период сна достаточно большой, то есть шанс, что билет истечет и при пробуждении его будет нельзя продлить.
  Если включить блокировку экрана, то при каждом пробуждении будет запрашиваться пароль пользователя, что принудительно получит новый билет.

sssd

sssd имеет два варианта. Первый вариант совместим с любым типом хранилища билетов, который поддерживает библиотека Kebreos. Второй вариант работает только с типом хранилища KCM. Его преимущество — интеграция с sssd, которая позволяет отслеживать все действия с билетами в хранилище.

Вариант 1 — krb5

В файле /etc/sssd/sssd.conf необходимо добавить параметр "krb5_renew_interval", задающий интервал обновления билетов, в раздел с настройками домена. Значение указывается целым числом в секундах, либо с единицей измерения (s для секунд, m для минут, h для часов, d для дней).

[domain/<имя_домена>]
krb5_renew_interval = 60m

Вариант 2 — kcm

Необходимо установить пакет sssd-kcm, и включить сокет:

# apt-get install sssd-kcm
# systemctl enable sssd-kcm.socket
# systemctl start sssd-kcm.socket

После этого, необходимо указать тип хранилища билетов по умолчанию в файле /etc/krb5.conf:

[libdefaults]
    default_ccache_name = KCM:

В файле /etc/sssd/sssd.conf в разделе [kcm] необходимо включить обновление билетов и указать интервал обновления билетов (аналогично первому варианту):

[kcm]
tgt_renewal = true
krb5_renew_interval = 60m

sssd-kcm может наследовать имеющиеся настройки интервала обновления из существующих настроек домена.

[domain/<имя_домена>]
krb5_renew_interval = 60m

[kcm]
tgt_renewal = true
tgt_renewal_inherit = <имя_домена>

winbind

Необходимо изменить конфигурационный файл /etc/samba/smb.conf и установить в разделе [global] значение параметра "kerberos method" как "secrets and keytab".

[global]
        security = ads
        realm = DOMAIN.ALT
        workgroup = SMB
        netbios name = CLIENT1
        template shell = /bin/bash
        kerberos method = secrets and keytab

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

GNOME Online Accounts

GNOME Online Accounts является SSO фреймворком для приложений GNOME. Позволяет добавить учетные записи для использования системой и приложениями (почта, календарь, облачные хранилища). Также поддерживает учетные записи для организаций через Kerberos.

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

Является частью окружений MATE и GNOME.

Отключение (для версий ниже 3.52.0-alt1)

Чтобы отключить службу для всех пользователей, необходимо создать файл /usr/share/glib-2.0/schemas/kerberos-disable.gschema.override со следующим содержимым:

[org.gnome.online-accounts]
whitelisted-providers = ['exchange','flickr','foursquare','google','imap_smtp','owncloud','facebook','lastfm']

Затем, необходимо выполнить команду для обновления умолчаний:

# glib-compile-schemas /usr/share/glib-2.0/schemas/

Если требуется отключить службу только для одного пользователя, то необходимо выполнить следующую команду от его имени:

$ dconf write /org/gnome/online-accounts/whitelisted-providers "['exchange','flickr','foursquare','google','imap_smtp','owncloud','facebook','lastfm']"

Отключение (для версий выше 3.52.0-alt1)

В новых версиях служба отключается только для всех пользователей. Для этого, необходимо создать файл /etc/goa.conf со следующим содержимым:

[kerberos]
ticketing=false

Учетная запись Kerberos будет отображаться, но обновление билетов работать не будет. Если требуется полное отключение, чтобы не было видно учетной записи, то необходимо изменить содержимое файла /etc/goa.conf на следующее:

[providers]
enable=exchange;google;imap_smtp;owncloud;webdav;ms_graph

krb5-ticket-watcher

krb5-ticket-watcher является графической программой, которая запускается при входе в систему, позволяет получать новые билеты, просматривать текущие и автоматически их обновлять. Она может использоваться, когда компьютер и пользователь не состоят в домене Active Directory, используется получение билетов в других (не доверенных) доменах/realm или остальные способы автоматического обновления не работают.

При наличии обновления билетов через winbind или sssd, если не планируется использовать, требуется удалить программу из системы:

# apt-get remove krb5-ticket-watcher

SSO

SSO (Single Sign On, технология единого входа) является одним из ключевых преимуществ Kerberos, т.к. позволяет пользователю, получившему TGT, осуществлять вход без дополнительной аутентификации или ввода пароля на различные службы организации.

Для работы билетов Kerberos требуется дополнительная настройка как серверов, так и клиентов (для некоторых случаев).

Браузеры

Групповые политики/Firefox

Настройка браузеров для SSO

Файловые менеджеры

Dolphin, используя ссылки формата smb:// может подключаться к общим папкам используя SSO.

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

Альтернативным решением может стать только монтирование общих папок (например, через autofs), где есть возможность использовать кэш учетных данных текущего пользователя.

ADMC/GPUI

Групповые политики/ADMC#Установка

Групповые политики/GPUI#Запуск_программы

CUPS

CUPS/Kerberos

NFS

NFS сервер с Kerberos авторизацией

Squid

Squid/AD-auth

Samba share

Samba/Fileserver/AD-auth

ActiveDirectory/FileShare

Dovecot

Dovecot/AD-auth

Apache

Apache2/AD-auth

nginx

Nginx/AD-auth

1С

1C/#Настройка аутентификации в домене Active Directory на базе Samba 4

SSH

Домен/Использование Kerberos#sshd

Источники

• RFC 4120
• Kerberos protocol tutorial
• MIT Kerberos Documentation: Ticket management
• [MS-KILE]: Kerberos Protocol Extensions
• [MS-PAC]: Privilege Attribute Certificate Data Structure
• Kerberos Policy