В рабочей схеме Kerberos доверенный сервер, во-первых, формирует дополнительный билет для доступа клиента к самому доверенному серверу (с другим сессионным ключом). Теперь клиенту достаточно помнить только этот новый сессионный ключ, а свой основной ключ он может убрать до следующей регистрации на доверенном сервере. Во-вторых, все билеты (как к серверам ресурсов, так и к самому доверенному серверу) отсылаются только клиенту. Теперь уже забота клиента предоставить вместе с запросом на предоставление ресурса и билет для данного сервера. А уж сервер, используя свой постоянный ключ, извлечет из билета сессионный ключ, который будет использовать для работы с клиентом. Если клиент хочет, чтобы сервер также аутентифицировал себя, он требует от сервера, чтобы тот извлек из клиентского запроса (зашифрованного сессионным ключом) определенные данные (временную метку) и вернул ее клиенту. Таким образом, клиент сможет убедиться, что сервер успешно дешифровал свой билет и, значит, является тем, за кого себя выдает (во всяком случае, по мнению доверенного сервера) (рис. 22.19).
Рис. 22.19. Принципиальная схема Kerberos
Теперь и доверенный сервер не должен искать постоянный ключ клиента в базе, клиент сам при новом запросе предоставит ему билет, в котором находится сессионный ключ для доверенного сервера.
В принятой в протоколе Kerberos терминологии билет для работы с доверенным сервером называется билетом на получение билетов (англ. ticket-granting-tickets — ТОТ), а билет для сервера ресурсов — билетом на получение сервиса (англ, ticket-granting-service — TGS). Все указанные билеты и связанные с ними ключи действительны только до срока истечения билета или выхода клиента из сети. Они сохраняются только в оперативной памяти, т. н. кэш-памяти билетов (англ, credentials cache) и удаляются по истечении срока или окончании работы клиента в сети.
Таким образом, работа клиента складывается из следующих шагов, каждый из которых составляет отдельный подпротокол протокола Kerberos.