Команда Linux ksu (керберизованный суперпользователь) не может использовать кэшированные билеты службы (хост)

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

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

Я пробовал в двух разных средах: (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

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

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

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

В ксу В документации 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 конечного сервера (служебный билет) он терпит неудачу, ксу игнорирует кешированный билет и запрашивает пароль пользователя:

$ 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 ксу Kerberos запрашивает DC, чтобы найти отличия от запрошенного мной билета службы. Название сервиса такое же "хост / authdemo4", ксу добавляет канонизируемый флаг к билету и запрашивает билет в TGS, пока кинит отправляет запрос в AS :-(

Обновление с помощью команды kvno (не удалось)

Я тщательно изучил с Wireshark запрос / ответ TGS, выполняемый ксу и я выяснил, что правильный сервис: 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:

$ 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 для хоста / authdemo4. Я также проверил (с помощью Wireshark) различия между ответами ксу и квно запросы, -> I <- не замечаю никакой разницы (см. прикрепленное изображение): Я также пробовал использовать ксу более одного раза без очистки кеша, и запрос TGS каждый раз выполняется снова.

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

Вопросы

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

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

С уважением