Пересылка Kerberos с хостами, не входящими в KDC

В моей организации используется Active Directory, который использует Kerberos для аутентификации. У меня есть группа компьютеров на Linux, которые не могут быть присоединены к AD. Для аутентификации пользователей я настроил kerberos и pam на использование AD сервера. После добавления пользователя в систему я могу войти, используя свое имя пользователя и пароль AD. После входа у меня есть билет. Это очень удобно, так как мне не нужно поддерживать отдельный набор учетных данных для пользователей.

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

Пример сценария: клиент AD по SSH подключается к server1 в моей группе компьютеров, не входящих в AD. Я могу войти, используя свое имя пользователя и пароль. После входа у меня есть билет. Теперь я хочу войти на server1 в моей группе компьютеров, не входящих в AD. Это снова запрашивает у меня пароль. Идеально было бы, если бы, поскольку у меня уже есть билет на клиенте AD, мне не нужно было бы вводить пароль для входа.

Согласно моему базовому пониманию kerberos, я думаю, что это не срабатывает на этапе “TGS-REQ”, когда клиент пытается получить билет сервиса (хоста) от KDC. Поскольку мой хост не зарегистрирован/не добавлен/не присоединен, я предполагаю, что KDC/AD не может его предоставить, и этот шаг терпит неудачу.

Мои вопросы?

1. Я прав, это причина моих проблем?
2. Есть ли способ обойти это, чтобы достичь своей цели единой аутентификации с помощью учетных данных AD?
3. Что, если я настрою свой собственный локальный KDC/AD/IDM. Есть ли способ связать это с основным AD?

Я прав, это причина моих проблем?

Да, в частности, в том, что сервер (целевая система SSH) не имеет Kerberos принципала.

Дело не только в записи базы данных; важный момент заключается в том, что ‘присоединение к домену’ устанавливает общий ключ между сервером и KDC (файл /etc/krb5.keytab), который связан с принципалом хоста сервера. Kerberos не может функционировать без этого.

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

Это не “один или оба”; есть три отдельных процедуры, которые создают TGS-REQ, и каждая из них ожидает только одного конкретного принципала:

• Во время вашего первоначального локального входа в систему (т.е. входа с использованием пароля через PAM), Windows или pam_krb5 создает TGS-REQ для своего локального системного хоста как часть предотвращения “подделки KDC”, т.е. убеждаясь, что PAM не может быть обманут, чтобы принять фальшивый пароль. (Если вы настроили pam_krb5 на необъединенной системе, она уязвима для подделки KDC.)

  Обратите внимание, что это на самом деле не является частью получения TGT, как такового – вы вполне можете получать билеты и использовать Kerberos без наличия у локального хоста своего принципала (хотя предпочтительно использовать kinit, а не интеграцию с PAM).

• Во время аутентификации к удаленным сервисам (например, SSH) клиент создает TGS-REQ для хоста сервера (или другого сервисного принципала). Например, если вы запускаете ssh mailsrv, он создаст TGS-REQ для сервиса host/mailsrv.

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

• После аутентификации, если как клиент, так и сервер имеют включенную опцию, Kerberos может скопировать ваш весь TGT на сервер для “второй аутентификации”. Это то, что Unix Kerberos называет “пересылкой билетов” (сравните с пересылкой ключа SSH-агента), также известной как “неконтролируемая делегация” в Active Directory. По историческим причинам пересылка не просто копирует ваш TGT как есть, а вместо этого делает TGS-REQ для krbtgt для получения дублирующегося TGT.

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

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

(Сервер не обязательно должен иметь “полную” конфигурацию присоединения к AD, с PAM и Samba и Winbindd и всем прочим; однако ему необходимо иметь учетную запись компьютера в AD.)

Если вам не разрешают создавать учетные записи компьютеров для систем Linux, тогда вы не можете настроить Kerberos SSO для SSH на них.

Что, если я настрою свой собственный локальный KDC/AD/IDM. Есть ли способ связать это с основным AD?

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

Хотя технически возможно, чтобы два Kerberos области доверяли друг другу (например, чтобы пользователь в области A мог получать билеты для сервисов как в области A, так и в области B, не требуя отдельных учетных данных из области B), это потребовало бы больше полномочий, чем присоединение отдельных машин – это потребовало бы “доверия областей” на уровне AD.

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

Таким образом, без полномочий вы можете только настроить систему ручной синхронизации паролей, где кто-то может войти с использованием своих учетных данных AD, и система автоматически выдает им учетную запись Kerberos Linux. (Я на самом деле видел, как несколько университетов документировали подобные настройки, например, когда у них есть историческая область MIT Kerberos для факультета компьютерных наук и совершенно новая область Windows AD для остальных.)

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

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

Для аутентификации пользователей я настроил kerberos и pam на использование AD сервера. После добавления пользователя в систему я могу войти, используя свое имя пользователя и пароль AD. После входа у меня есть билет.

Помните, что если в системе нет keytab хоста и выполняется только AS-REQ, то это уязвимо к подделке KDC – если злоумышленник получает контроль над сетью в первую очередь, то он мог бы перенаправить весь Kerberos трафик к своему собственному KDC и заставить его ответить “успешными” AS-REP и ‘krbtgt’ для любого имени пользователя и пароля, которые захочет злоумышленник.

Стандартное средство противодействия заключается в том, чтобы клиентская система немедленно использовала полученный TGT для запроса сервисного билета для себя, чтобы она могла проверить этот билет по своему собственному ключу, который был установлен ранее (т.е. во время присоединения к домену – пароль учетной записи машины в Windows или keytab в Linux) и который знал бы только легитимный KDC.

(Пост, который вы упомянули, говорит: “S1 пытается расшифровать TGT, используя ключ, сгенерированный из вашего пароля. Если расшифровка успешна, пароль принимается как правильный.” Это уязвимая часть, и именно здесь S1 дополнительно выполнит TGS-REQ для своего собственного принципала “host/S1”.)