Команде 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, и они не могут гарантировать график работы.