Linux ksu (kerberized super user) command fails to use cached service (host) tickets... how can I do this?

[Fabiano Tarlao]

Thanks Ben for your tips.
I have tried again, I examined deeply the TGS request/response performed by
*ksu* and I found out that the correct service is: host/authdemo4 at ADDEMO.IT

I have tried with kvno to insert the service ticket into the cache:

Insert TGT:
$ kinit kservice -c ./prova.cc
Password for kservice at ADDEMO.IT:

Insert service ticket:
$ kvno host/authdemo4 at ADDEMO.IT -c ./prova.cc
host/authdemo4 at ADDEMO.IT: kvno = 17

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

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

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

It works BUT it always ignores the service ticket and performs again from
scratch a TGS request for host/authdemo4.
I have also checked (with Wireshark) differences between the responses of
the ksu and kno requests, ->I<- don't notice any difference (see attached
image):
[image: Inline images 1]:


I have also tried using *ksu* more than once without purging the cache and
the TGS request is performed again, each time.

*Has this to be filed as a ksu bug? (Y/N)*
It looks ksu behaviour doesn't adhere to the behaviour described in the
documentation. I quote again:

Otherwise, ksu looks for an appropriate Kerberos ticket in the source
cache. The ticket can either be for the end-server or a ticket granting
ticket (TGT) for the target principal’s realm. If the ticket for the
end-server is already in the cache, it’s decrypted and verified. If it’s
not in the cache but the TGT is, the TGT is used to obtain the ticket for
the end-server. The end-server ticket is then verified.

*Any other tip?*


On 9 November 2017 at 14:21, Benjamin Kaduk <kaduk at mit.edu> wrote:

> On Thu, Nov 09, 2017 at 11:10:12AM +0100, Fabiano Tarlao wrote:
> >
> >    - is there a way to populate a Kerberos cache file with a service
> ticket
> >    (for the host) that is compatible with *ksu*?
> >    - I have read about *kvno*
> >    <http://web.mit.edu/tsitkova/www/build/krb_users/user_
> commands/kvno.html>
> >    command but I have failed to use it, the documentation does not
> suffice
> >    (for me) and there are no usage examples around, can you explain me
> how to
> >    use it?
>
> kvno is a simple tool that attempts to perform a TGS request for a ticket
> for the indicated service principal, and reports the key version number
> of that service principal used by the KDC to encrypt the ticket.
> It requires a TGT to be present in the cache already, so you would do
> your normal kinit, and then `kvno HOST/authdemo4.addemo.it at ADDEMO.IT`.
>
> >    - Are there alternatives to *kvno* command in order to perform service
> >    ticket requests to TGS (and put it into a cache file)?
>
> Not really.  That is, there are lots of things that will request a
> service ticket and put it in the cache as part of their normal operation
> (ssh, ldapsearch, etc.), but kvno is the closest to a dedicated tool
> for this operation.
>
> >    - Am I doing something wrong? Any tip?
>
> My only guess is that ksu is being confused the the 'initial' service
> ticket (i.e., obtained directly from the AS and not the TGS), so that
> kinit+kvno would help.  But the ksu codebase is not much fun to go
> looking in, so I did not try to check.
>
> -Ben
>