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

[Fabiano Tarlao]

improvement/Errata:

Has this to be filed as a ksu bug? (Y/N) -> Should this to be filed as a
ksu bug? (Y/N)


On 9 November 2017 at 15:34, Fabiano Tarlao <ftarlao at gmail.com> wrote:

> 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_comman
>> ds/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
>>
>
>