Support Questions
Find answers, ask questions, and share your expertise

when use kerberos, where is the service ticket

New Contributor

hi all:

 

in Kerberos: The Definitive Guide

this book classify the principal into two type,  user principal  and service principal.

then in the 2.4.4.1 exmple,  when user login as  user principal jgarman@WEDGIE.ORG,  and telnet to

host/cfs.wedgie.org(use service)  will get the service ticket  host/cfs.wedgie.org@WEDGIE.ORG.

2.4.4.1 The ticket (or credential) cache
$ klist
Ticket cache: FILE:/tmp/krb5cc_502_auJKaJ
Default principal: jgarman@WEDGIE.ORG

Valid starting     Expires            Service principal
09/10/02 01:48:12  09/10/02 11:48:12  krbtgt/WEDGIE.ORG@WEDGIE.ORG
09/10/02 01:48:14  09/10/02 11:48:12  host/cfs.wedgie.org@WEDGIE.ORG
09/10/02 04:20:42  09/10/02 11:48:12  host/web.wedgie.org@WEDGIE.ORG

 

2.5 Putting the Pieces Together

...

Inside the credential cache, I have obtained an initial Ticket Granting Ticket through the Authentication Server (this is the first ticket out of three). By logging into this system, the system created this credential cache and obtained a TGT for me. During my log in session, I also logged into a host called cfs.wedgie.org, which has a Kerberized telnet daemon running on it. Because I was using Kerberos authentication, I was able to log into cfs without typing a password; instead, my telnet client obtained a service principal from the Ticket Granting Server, and used that ticket to contact the Kerberized telnet on cfs. Later, I did the same, except this time I logged into web.wedgie.org.

During this time, after logging in to three machines (including my initial authentication to Kerberos), I have only typed in my password once. The Kerberos software requested, generated, and sent tickets on my behalf as necessary to transparently authenticate me to the other machines as I accessed them. As a user, all of this happens behind the scenes. Now we'll peel back the curtain, and uncover the magic that occurs behind the scenes.

 

 

 

 

So what i understand is that the end user only use user principal,   the service principal is used for encryp service ticket.

But when i use in cdh, i login as a user,  and then accese hdfs or beeline service.

Then use klist, find only the krbtgt's ticket,  can't find any service's(hdfs, hive) ticket.

 

 

 

[cqpsrvas@w2110313 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_7542
Default principal: bdhupbas@UPBG.COM

Valid starting       Expires              Service principal
10/13/2020 10:24:20  10/14/2020 10:24:20  krbtgt/UPBG.COM@UPBG.COM
        renew until 10/20/2020 10:24:20

 

 

 

 

 

so where is the service's ticket

what's the real procedure or steps of the back.

what's the function of the service principal like hdfs/xxxx@xxxx,  hive/xxx@xxx, if they are not used to encrypt service ticket.

1 REPLY 1

Cloudera Employee

The service principal keys definitely are used to encrypt the service ticket that the client sends to the server to authenticate itself.

 

I'm not 100% sure why it's not showing up in the klist. The short technical answer is that the hadoop CLIs are not using the user key cache to cache the service tickets. If there is a reason why they don't, it's a reason I have forgotten or never knew.

; ;