Команде Linux ksu (kerberized super user) не удается использовать билеты кэшированного сервиса (хоста)

Вопросы в конце

О моем окружении

Я пробовал в двух разных средах: (i) сервер Linux Ubuntu 16.04LTS, зарегистрированный в домене Active Directory (Microsoft), и (ii) сервер Linux Ubuntu 16.04LTS, зарегистрированный в области FreeIPA.

Бинарная версия Krb5:

$ strings libkrb5.so | grep BRAND
KRB5_BRAND: krb5-1.13.2-final 1.13.2 2015050

Что я люблю делать

Я пытаюсь использовать команду ksu для входа на текущий хост (authdemo4.addemo.it) от имени другого пользователя: kservice. Подробно я пытаюсь (i) получить билет службы для пользователя kservice для хоста authdemo4.addemo.it, (ii) сохранить билет в файле кэша MIT /media/public/krb_kservice и (iii) предоставить этот билет к команде ksu для входа в систему как kservice.

это должно быть возможно

В документации ksu MIT говорится, что использование билета службы из файла кэша возможно, давайте процитируем:

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

Мои эксперименты и результаты

При использовании билета TGT Kerberos.. он работает как шарм:

$ kinit -c /media/public/krb_kservice  kservice
Password for kservice@ADDEMO.IT:
$ ksu kservice -n kservice@ADDEMO.IT -c FILE:/media/public/krb_kservice
Authenticated kservice@ADDEMO.IT
Account kservice: authorization for kservice@ADDEMO.IT successful
Changing uid to kservice (50006)
groups: cannot find name for group ID 50024
kservice@authdemo4:/home/userlab$ 

Это содержимое кеша, есть только TGT:

$ klist -c /media/public/krb_kservice
Ticket cache: FILE:/media/public/krb_kservice
Default principal: kservice@ADDEMO.IT

Valid starting       Expires              Service principal
11/08/2017 11:44:07  11/08/2017 21:44:07  krbtgt/ADDEMO.IT@ADDEMO.IT
        renew until 11/09/2017 11:44:03

При попытке с билетом Kerberos конечного сервера (билет службы) происходит сбой, ksu игнорирует кэшированный билет и запрашивает пароль пользователя:

$ kinit   -S HOST/authdemo4@ADDEMO.IT  -c /media/public/krb_kservice  kservice
Password for kservice@ADDEMO.IT:
$ ksu kservice -n kservice@ADDEMO.IT -c FILE:/media/public/krb_kservice
WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel.
Kerberos password for kservice@ADDEMO.IT: :

Обратите внимание, что я испробовал все эти принципы обслуживания: host/authdemo4.addemo.it@ADDEMO.IT, HOST/authdemo4.addemo.it@ADDEMO.IT, host/authdemo4@ADDEMO.IT, HOST/authdemo4@ADDEMO.IT

Это содержимое кеша, есть только тикет сервиса:

$ klist -f -c /media/public/krb_kservice
Ticket cache: FILE:/media/public/krb_kservice
Default principal: kservice@ADDEMO.IT

Valid starting       Expires              Service principal
11/08/2017 13:51:05  11/08/2017 23:51:05  HOST/authdemo4@ADDEMO.IT
        renew until 11/09/2017 13:51:02, Flags: FPRIA

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

Вкратце: моя попытка с билетом обслуживания конечного сервера не работает.

Я проверил с Wireshark запросы ksu Kerberos к DC, чтобы найти различия с моим запрошенным сервисным билетом. Имя службы - это то же самое " host / authdemo4 ", ksu добавляет к заявке канонизируемый флаг и запрашивает билет в TGS, а kinit отправляет запрос в AS:-(

Обновление с использованием команды kvno (ошибка)

Я проверил с Wireshark запрос / ответ TGS, выполненный ksu, и обнаружил, что правильный сервис: host/authdemo4@ADDEMO.IT

Я попытался с квно вставить сервисный билет в кеш:

Вставьте TGT:

$ kinit kservice -c ./prova.cc
Password for kservice@ADDEMO.IT:

Вставьте сервисный билет:

$ kvno host/authdemo4@ADDEMO.IT -c ./prova.cc
host/authdemo4@ADDEMO.IT: kvno = 17

Проверьте содержимое кэша:

$ klist -c ./prova.cc
Ticket cache: FILE:./prova.cc
Default principal: kservice@ADDEMO.IT

Valid starting       Expires              Service principal
11/09/2017 15:18:53  11/10/2017 01:18:53  krbtgt/ADDEMO.IT@ADDEMO.IT
        renew until 11/10/2017 15:18:48
11/09/2017 15:19:07  11/10/2017 01:18:53  host/authdemo4@ADDEMO.IT
        renew until 11/10/2017 15:18:48

Вызвать ксю:

$ ksu kservice -n kservice@ADDEMO.IT -c FILE:./prova.cc
Authenticated kservice@ADDEMO.IT
Account kservice: authorization for kservice@ADDEMO.IT successful
Changing uid to kservice (50006)
groups: cannot find name for group ID 50024

Кажется, он работает, НО он всегда игнорирует билет службы и снова с нуля выполняет запрос TGS для host / authdemo4. Я также проверил (с помощью Wireshark) различия между ответами на запросы ksu и kvno, ->I <- не замечаю никакой разницы (см. Прикрепленное изображение): Я также пытался использовать ksu более одного раза без очистки кэша, и запрос TGS выполняется снова, каждый раз.

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

Вопросы

Они немного пересекаются:-)

  • Есть ли способ заполнить файл кэша Kerberos билетом службы, который совместим с ksu?
  • Существуют ли альтернативы команде kvno для выполнения запросов билетов службы в TGS?
  • Я делаю что-то неправильно? Любой совет?
  • Как вы думаете, это ошибка КСУ?:-)

С уважением

1 ответ

Решение

ответы

Есть ли способ заполнить файл кэша Kerberos билетом службы, совместимым с ksu?

НЕТ, так как версия 1.13 ksu не использует кэшированные сервисные билеты

Существуют ли альтернативы команде kvno для выполнения запросов билетов службы в TGS?

Мои поиски не привели к альтернативам, но предыдущий ответ делает это гораздо менее важным для меня

Я делаю что-то неправильно? Любой совет?

НЕТ, кажется, я работал правильно, проблема в измененном (не задокументированном) поведении ksu

Как вы думаете, это ошибка КСУ?:-)

О ДА, это ошибка ksu или ошибка документации, разработчики изменили поведение, но забыли синхронизировать с документацией

Я отправил отчет об ошибке и получил отзыв (спасибо сопровождающему ksu Грегу Хадсону за оперативную поддержку). Они утверждают, что предыдущее исправление изменило поведение ksu с версии 1.13, и они не заметили / не обновили документацию.

Отправленный отчет об ошибке: http://krbdev.mit.edu/rt/Ticket/Display.html?id=8619

Текущее поведение ksu не соответствует документации (о тикете сервиса в кеше).

При версии ksu>= 1.13 билет службы конечного сервера не читается / не проверяется из файла кэша, НО проверяется только кэшированный TGT. Когда ksu вызывается, запрос билета службы к TGS выполняется для проверки кэшированного TGT.

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

ОБНОВЛЕНИЕ: Они ответили на запрос об ошибке и решили восстановить задокументированное поведение, но ksu не является высоким приоритетом в проекте Krb5, и они не могут гарантировать график работы.

Другие вопросы по тегам