Re: 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/authde...@addemo.it

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

Insert TGT:
$ kinit kservice -c ./prova.cc
Password for kserv...@addemo.it:

Insert service ticket:
$ kvno host/authde...@addemo.it -c ./prova.cc
host/authde...@addemo.it: kvno = 17

Check cache content:
$ klist -c ./prova.cc
Ticket cache: FILE:./prova.cc
Default principal: kserv...@addemo.it

Valid starting   Expires  Service principal
11/09/2017 15:18:53  11/10/2017 01:18:53  krbtgt/addemo...@addemo.it
renew until 11/10/2017 15:18:48
11/09/2017 15:19:07  11/10/2017 01:18:53  host/authde...@addemo.it
renew until 11/10/2017 15:18:48

Invoke ksu:
$ ksu kservice -n kserv...@addemo.it -c FILE:./prova.cc
Authenticated kserv...@addemo.it
Account kservice: authorization for kserv...@addemo.it successful
Changing uid to kservice (50006)
groups: cannot find name for group ID 50024
kservice@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  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*
> > 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...@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
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: 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  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/
> authde...@addemo.it
>
> I have tried with kvno to insert the service ticket into the cache:
>
> Insert TGT:
> $ kinit kservice -c ./prova.cc
> Password for kserv...@addemo.it:
>
> Insert service ticket:
> $ kvno host/authde...@addemo.it -c ./prova.cc
> host/authde...@addemo.it: kvno = 17
>
> Check cache content:
> $ klist -c ./prova.cc
> Ticket cache: FILE:./prova.cc
> Default principal: kserv...@addemo.it
>
> Valid starting   Expires  Service principal
> 11/09/2017 15:18:53  11/10/2017 01:18:53  krbtgt/addemo...@addemo.it
> renew until 11/10/2017 15:18:48
> 11/09/2017 15:19:07  11/10/2017 01:18:53  host/authde...@addemo.it
> renew until 11/10/2017 15:18:48
>
> Invoke ksu:
> $ ksu kservice -n kserv...@addemo.it -c FILE:./prova.cc
> Authenticated kserv...@addemo.it
> Account kservice: authorization for kserv...@addemo.it successful
> Changing uid to kservice (50006)
> groups: cannot find name for group ID 50024
> kservice@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  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*
>> >> 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...@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
>>
>
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Benjamin Kaduk]

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*
>
>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...@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

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Fabiano Tarlao]

P.s: I posted the same question to serverfault

but I get no response.

Questions at the end

*About my environment*

I have tried in two different environments: (i) Linux Ubuntu 16.04LTS
server enrolled in Active Directory (Microsoft) Domain and (ii) Linux
Ubuntu 16.04LTS server enrolled in a FreeIPA Realm.

*What I like to do*

I'm trying to use *ksu*

command to login on the current host (*authdemo4.addemo.it
*) as another user: *kservice*. In detail I'm
trying (i) to obtain a service ticket for user *kservice* for the host
*authdemo4.addemo.it
*, (ii) to save the ticket in a MIT cache file
*/media/public/krb_kservice* and (iii) to provide this ticket to *ksu*
command in order to login as *kservice*.


*it should be possibile (?)*

The *ksu* MIT documentation states that using a service ticket from cache
file is possible, let's quote:

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.

*My experiments and results*

When using the TGT Kerberos ticket for *kservice*.. it works like a charm:

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

This is the cache content, there is only the TGT:

$ klist -c /media/public/krb_kservice
Ticket cache: FILE:/media/public/krb_kservice
Default principal: kserv...@addemo.it

Valid starting   Expires  Service principal
11/08/2017 11:44:07  11/08/2017 21:44:07  krbtgt/addemo...@addemo.it
renew until 11/09/2017 11:44:03

When trying with the end-server Kerberos ticket (service ticket) it fails,
*ksu* ignores the cached ticket and asks for the user password:

$ kinit   -S HOST/authdemo4.addemo...@addemo.it  -c
/media/public/krb_kservice  kservice
Password for kserv...@addemo.it:
$ ksu kservice -n kserv...@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 kserv...@addemo.it: :

This is the cache content, there is only the service ticket:

$ klist -f -c /media/public/krb_kservice
Ticket cache: FILE:/media/public/krb_kservice
Default principal: kserv...@addemo.it

Valid starting   Expires  Service principal
11/08/2017 13:51:05  11/08/2017 23:51:05  HOST/authdemo4.addemo...@addemo.it
renew until 11/09/2017 13:51:02, Flags: FPRIA

It is proxiable-forwardable-renewable-initial-preauthenticated ticket.

In brief: *my attempt with end-server service ticket doesn't work*.

*I have tried* to change the kinit request, I have changed the service
principal name-parts to uppercase/lowercase, with and without-domain,
HOST->host, and so on but *it keeps failing*.

I checked with Wireshark the *ksu* Kerberos requests to the DC in order to
find differences with my requested service ticket. Service name is the same
"*HOST/authdemo4.addemo.it *", *ksu* adds the
*canonizable* flag to the ticket and it asks the ticket to the TGS while
*kinit* sends the request to the AS :-(

*Questions*

They overlap a bit :-)

   - 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*
   
   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?
   - Are there alternatives to *kvno* command in order to perform service
   ticket requests to TGS (and put it into a cache file)?
   - Am I doing something wrong? Any tip?

Regards

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos