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 <[email protected]> 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/ > [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 > 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 <[email protected]> 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/[email protected]`. >> >> > - 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 [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
