Как работает вход в доменный компьютер#
При входе пользователя в доменный компьютер аутентификация осуществляется по протоколу Kerberos.
Протокол назван так по имени трехголовой собаки Цербера, охраняющей выход из царства мёртвых по древнегреческой мифологии. Каждая голова этой собаки соответствует одному из трех участников процедуры аутентификации:
Клиент (Client) — субъект, желающий получить доступ к ресурсу;
Сервер приложения (Application Server, AP) — служба, к ресурсу которой клиент хочет получить доступ;
Центр распределения ключей (Key Distribution Center, KDC) — доверенная третья сторона, отвечающая за аутентификацию (Authentication Servicec, AS) пользователей и выпуск билетов для доступа к сетевым службам в домене (Ticket Granting Server, TGS).
Рассмотрим процесс аутентификации пользователя.
Пользователь Алиса через приложение графического входа (Fly Display Manager Greet) передает логин и пароль в открытом виде клиенту Kerberos, в роли которого выступает System Security Services Daemon (SSSD). Учетные данные пользователя обрабатываются стеком модулей аутентификации (Pluggable Authentication Modules, PAM).
Клиент Kerberos рассчитывает долгосрочный мастер ключ Алисы (UPN long-term key или Master key), как хэш от введенного пароля, и может удалить из памяти компьютера пароль в открытом виде для повышения устойчивости системы к взлому.
Клиент отправляет запрос службе аутентификации Центра распределения ключей (Key Distribution Center, KDC).
KDC расшифровывает аутентификатор, используя хэш пароля Алисы из LDAP-каталога. Ключи для аутентификации по протоколу Kerberos хранятся в атрибуте krbPrincipalKey, который представляет из себя бинарный объект, зашифрованный мастер-ключом KDC.
Если процедура расшифровки завершилась успешно и полученная временная метка расходится с временем сервера не более, чем на 5 минут, то считается, что предварительная аутентификация пройдена успешно. По этой причине для корректной работы kerberos-протокола так важна синхронизация времени между всеми участниками.
Для повышения безопасности системы KDC генерирует временный сессионный ключ (S1) и передает его клиенту, чтобы использовать в дальнейшем для шифрования сообщений между клиентом и KDC вместо хэша пароля пользователя.
Не смотря на то, что сессионный ключ был сгенерирован сервером, в домене может быть несколько контроллеров, и Клиент вправе обратиться с последующим запросом к любому из них. Клиенту выдается билет на выдачу билетов (Ticket-granting ticket, TGT), который он должен предъявлять в KDC при последующих обращениях.
Сессионный ключ и билет шифруются симметричным алгоритмом с помощью долгосрочного ключа клиента, поэтому только клиент сможет расшифровать сообщение, подтверждая этим фактом, что является тем, за кого себя выдает. Данная проверка аутентичности считается основной.
Клиент расшифровывает сессионный ключ и TGT билет своим долгосрочным ключом. Возможность использования этих данных в последующих запросах означает, что Клиент является тем, за кого себя выдает.
9. Клиент отправляет контроллеру запрос на доступ к серверу приложению, в котором содержится имя пользователя, имя сервера приложения, билет на выдачу билетов (TGT) и аутентификатор. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью сессионного ключа S1.
KDC расшифровывает информацию из TGT билета, используя долгосрочный ключ KDC из LDAP-каталога, после чего ему становится доступна следующая информация: имя пользователя, сессионный ключ и срок действия билета. Сервер расшифровывает аутентификатор, используя сессионный ключ из TGT билета, и, если полученное значение расходится с временем сервера не более, чем на 5 минут, то считается, что аутентификация пройдена успешно.
Для повышения безопасности протокола KDC генерирует новый сессионный ключ (S2) и передает его клиенту, чтобы использовать в дальнейшем для шифрования сообщений между клиентом и сервером приложения вместо сессионного ключа S1.
Ключ S2 был сгенерирован сервером KDC и его следует передать Серверу приложения. Клиенту выдается зашифрованный сервисный билет (Service ticket, ST), который он должен предъявлять серверу приложения.
После передачи сервисного билета Клиенту информация о ключах больше не требуется и может быть удалена для повышения безопасности системы.
Клиент расшифровывает сессионный ключ S2 и сервисный билет ST известным ему сессионным ключом S1. Возможность использования этих данных в последующих запросах означает, что Клиент является тем, за кого себя выдает.
Клиент отправляет серверу приложения запрос на аутентификацию, в котором содержится имя пользователя, сервисный билет (ST) и аутентификатор. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью сессионного ключа S2.
Сервер приложения, в роли которого выступает служба SSSD на пользовательском компьютере расшифровывает ответ. Используя этот долгосрочный ключ, служба SSSD может расшифровать информацию из сервисного билета (ST), после чего ей становится доступна следующая информация: имя пользователя, сессионный ключ S2 и срок действия билета. SSSD расшифровывает аутентификатор, используя сессионный ключ S2 из сервисного билета, и, если полученное значение расходится с временем компьютера не более, чем на 5 минут, то считается, что аутентификация пройдена успешно.
Для подтверждения сервером приложения своей аутентичности он увеличивает полученную метку времени на 1, шифрует симметричным алгоритмом, используя сессионный ключ S2, и возвращает клиенту. Данное подтверждение актуально при аутентификации в сетевых приложения, когда клиент и сервер приложения являются разными субъектами.
Клиент расшифровывает аутентификатор, используя сессионный ключ S2. Если полученное значение можно получить, прибавляя 1 к ранее отправленному значению, то взаимная аутентификация считается пройденной успешно. Получив подтверждение, что вход в компьютер действительно хочет выполнить Алиса, приложение DM запускает приложение рабочий стол (Fly Windows Manager, fly-wm) от ее имени.
