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