0

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.

Krb5 binary version:

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

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.. it works like a charm:

$ 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$ 

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: [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

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/[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]: :

Please note that I have tried all these service principals: host/[email protected], HOST/[email protected], host/[email protected], HOST/[email protected]

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: [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

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

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

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", ksu adds the canonizable flag to the ticket and it asks the ticket to the TGS while kinit sends the request to the AS :-(

Update, using kvno command (fails)

I examined deeply with Wireshark the TGS request/response performed by ksu and I found out that the correct service is: host/[email protected]

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

Insert TGT:

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

Insert service ticket:

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

Check cache content:

$ 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

Invoke 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

It seems to work 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 kvno requests, ->I<- don't notice any difference (see attached image): Kerberos response for kvno and ksu, looks identical I have also tried using ksu more than once without purging the cache and the TGS request is performed again, each time.

In brief: this attempt with end-server service ticket doesn't work (service ticket is always re-requested).

Questions

They overlap a bit :-)

  • is there a way to populate a Kerberos cache file with a service ticket that is compatible with ksu?
  • Are there alternatives to kvno command in order to perform service ticket requests to TGS?
  • Am I doing something wrong? Any tip?
  • Do you think this is a ksu bug? :-)

Regards

1 Answer 1

0

Answers

Is there a way to populate a Kerberos cache file with a service ticket that is compatible with ksu?

NO, since version 1.13 ksu doesn't take advantage of cached service tickets

Are there alternatives to kvno command in order to perform service ticket requests to TGS?

My searches has not lead to alternatives but the previous answer make this far less important to me

Am I doing something wrong? Any tip?

NO, it seems I have worked right, the problem is the changed (not documented) ksu behaviour

Do you think this is a ksu bug? :-)

ABOUT YES, it is a ksu bug or a documentation bug, developers changed the behaviour but forgot to sync with documentation

I filed a bug report and got feedback (Thanks to ksu maintainer Greg Hudson for the prompt support). They state that a previous bugfix changed the ksu behaviour from version 1.13 and they have not noticed/not updated the documentation.

The submitted bug report: http://krbdev.mit.edu/rt/Ticket/Display.html?id=8619

The current ksu behaviour does not adhere to the documentation (about service ticket in cache).

With ksu version >= 1.13 the end-server service ticket is not read/validated from cache file BUT only the cached TGT is validated. When the ksu is invoked a service ticket request to TGS is performed in order to validate the cached TGT.

At the moment, they are still thinking about what to do. I reccomended to restore the documented behaviour, I'll update this question in the future with their final decision.

UPDATE: They replied at the bug-request and decided to restore the documented behaviour, but ksu is not high priority in the Krb5 Project and they cannot guarantee a timetable for the work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .