Linux ksu(kerberized超级用户)命令无法使用caching的服务(主机)票据

问题在最后

关于我的环境

我已经尝试了两种不同的环境:(i)在Active Directory(微软)域中注册的Linux Ubuntu 16.04LTS服务器和(ii)在Ubuntu FreeBSD Realm注册的Linux Ubuntu 16.04LTS服务器。

Krb5二进制版本:

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

我喜欢做什么

我试图使用ksu命令作为另一个用户login当前主机( authdemo4.addemo.it ): kservice 。 详细地说,我试图(i)为主机authdemo4.addemo.it获取用户kservice的服务票证,(ii)将票证保存在MITcaching文件/ media / public / krb_kservice中 ,(iii)提供这张票以ksu命令为了login为kservice

它应该是可能的

ksu麻省理工学院的文件指出,从caching文件使用服务票据是可能的,让我们引用:

否则,ksu将在源caching中查找适当的Kerberos票证。 该票可以是最终服务器,也可以是目标主体领域的票证授予票(TGT)。 如果terminal服务器的票证已经在caching中,则解密并validation。 如果它不在caching中,但是TGT是,则TGT用于获取terminal服务器的票证。 terminal服务器票证然后被validation。

我的实验和结果

当使用TGT Kerberos票证时,它就像一个魅力:

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

这是caching内容,只有TGT:

 $ klist -c /media/public/krb_kservice Ticket cache: FILE:/media/public/krb_kservice Default principal: [email protected] Valid starting Expires Service principal 11/08/2017 11:44:07 11/08/2017 21:44:07 krbtgt/[email protected] renew until 11/09/2017 11:44:03 

尝试使用terminal服务器Kerberos票证(服务票证)失败时, ksu将忽略高速caching票证并要求input用户密码:

 $ kinit -S HOST/[email protected] -c /media/public/krb_kservice kservice Password for [email protected]: $ ksu kservice -n [email protected] -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 [email protected]: : 

请注意,我已经尝试了所有这些服务主体: host / [email protected]HOST / authdemo4.addemo.it@ ADDEMO.IThost / authdemo4@ ADDEMO.ITHOST / [email protected]

这是caching内容,只有服务票据:

 $ klist -f -c /media/public/krb_kservice Ticket cache: FILE:/media/public/krb_kservice Default principal: [email protected] Valid starting Expires Service principal 11/08/2017 13:51:05 11/08/2017 23:51:05 HOST/[email protected] renew until 11/09/2017 13:51:02, Flags: FPRIA 

它是可接近 – 可转发 – 可更新 – 初始 – 预authentication票证。

简而言之: 我尝试使用terminal服务器服务票证不起作用

我使用Wireshark检查了ksu Kerberos向DC 发出的请求,以便查找与我请求的服务票据的区别。 服务名称是相同的“ 主机/ authdemo4 ”, ksu增加canonizable标志的票证,并要求票据TGS而kinit发送请求到AS 🙁

更新,使用kvno命令(失败)

我用Wireshark深入考察了由ksu执行的TGS请求/响应,我发现正确的服务是: host/[email protected]

我已经尝试用kvno将服务票据插入caching中:

插入TGT:

 $ kinit kservice -c ./prova.cc Password for [email protected]: 

插入服务票证:

 $ kvno host/[email protected] -c ./prova.cc host/[email protected]: kvno = 17 

检查caching内容:

 $ klist -c ./prova.cc Ticket cache: FILE:./prova.cc Default principal: [email protected] Valid starting Expires Service principal 11/09/2017 15:18:53 11/10/2017 01:18:53 krbtgt/[email protected] renew until 11/10/2017 15:18:48 11/09/2017 15:19:07 11/10/2017 01:18:53 host/[email protected] renew until 11/10/2017 15:18:48 

调用ksu:

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

它似乎工作,但它总是忽略服务票证, 并再次从头执行主机/ authdemo4 的TGS请求 。 我也检查了(与Wireshark) ksukvno请求的响应之间的差异, – >我< – 没有注意到任何区别(见附图): kvno和ksu的Kerberos响应看起来完全相同 我也尝试了不止一次使用ksu而不清除caching,并且每次都要重新执行TGS请求。

简而言之:这种尝试使用terminal服务器服务票证不起作用(服务票证总是被重新请求)。

问题

他们重叠了一下:-)

  • 有没有一种方法来填充与ksu兼容的服务票据的Kerberoscaching文件?
  • 为了向TGS执行服务票据请求,是否有替代kvno命令?
  • 难道我做错了什么? 任何小费?
  • 你认为这是一个ksu错误吗? 🙂

问候

答案

有一种方法来填充与ksu兼容的服务票证的Kerberoscaching文件吗?

,从版本1.13开始,ksu没有利用caching的服务票据

为了向TGS执行服务票据请求,是否有替代kvno命令?

我的search没有导致其他select,但以前的答案使这对我来说不那么重要

难道我做错了什么? 任何小费?

,看来我的工作是正确的,问题是改变(没有logging)ksu的行为

你认为这是一个ksu错误吗? 🙂

关于是的 ,这是一个ksu错误或文档错误,开发人员改变了行为,但忘记与文档同步

我提交了一个bug报告并得到了反馈(感谢ksu维护者Greg Hudson提供的支持)。 他们声明,以前的bug修改了ksu行为从版本1.13,他们没有注意到/没有更新文档。

提交的错误报告: http : //krbdev.mit.edu/rt/Ticket/Display.html?id = 8619

当前的ksu行为不符合文档(关于caching中的服务票证)。

在ksu版本> = 1.13的情况下, terminal服务器服务票据不会从caching文件读取/validation,但是只有caching的TGT被validation 。 当ksu被调用时,执行TGS的服务票据请求以validation被高速caching的TGT。

目前,他们还在考虑如何去做。 我build议恢复logging的行为,我将在未来更新这个问题与他们的最终决定。