Andrew's Magnum Opus

<ahamilto> anyways
<ahamilto> -----BEGIN KERBEROS EXPLANATION-----
<zan> (i hope that drink is diet coke, would hate to make you turn to alcohol because of my lack of reading comprehension)
<ahamilto> so Kerberos servers are called KDCs or Key Distribution Centers
<ahamilto> KDCs can either be dedicated servers (like in the syslab) or built into a package (like with Microsoft Active Directory)
<ahamilto> KDCs store principals
<ahamilto> principals can be issued  to users, computers, or servers
<ahamilto> *services
<ahamilto> user principals are generally of the form username@REALM or username/role@REALM
<zan> so is 2016zan@tjhsst.edu my principal?
<ahamilto> no
<zan> or 2016zan/student@tjhsst.edu or similar?
<ahamilto> no
<ahamilto> I'll get to that
<zan> okay
<ahamilto> host principals are generally of the form host/Fully Qualified Domain Name@REALM; eg host/iodine.tjhsst.edu@CSL.TJHSST.EDU
* `bjones grabs ahamilto's and srepetsk's drink to throw in his own eyes
<`bjones> er, *drinks
<ahamilto> service principals are issued to services running on a host and are generally of the form service/FQDN of server; eg ldap/openldap1.tjhsst.edu@CSL.TJHSST.EDU
<ahamilto> now realms
<ahamilto> a realm can be roughly generalized to an organization or network
<ahamilto> at TJ we have two realms
<zan> windows and linux?
<ahamilto> CSL.TJHSST.EDU is the realm that covers the CSL network; all of the CSL servers have host principals issued from this realm and admins generally have various principals here as well
<ahamilto> LOCAL.TJHSST.EDU is the windows realm where all of the windows computers and all students/staff have principals
<ahamilto> zan: to answer your earlier question, your principal is 2016zan@LOCAL.TJHSST.EDU
<ahamilto> "But then how do I log into CSL services you might ask"; well Kerberos realms have this neat thing called trust
<zan> even if I log in to serenity? Wouldn't I be 2016zan@CSL.TJHSST.EDU then?
<ahamilto> no
<zan> Oh, I get one principal, period
<ahamilto> CSL.TJHSST.EDU and LOCAL.TJHSST.EDU trust eachother and (simplified for now) CSL.TJHSST.EDU machines will accept a LOCAL.TJHSST.EDU principal
<ahamilto> zan: in your case yes
<ahamilto> zan: it is possible to have both (I have both as does affiliated and sdamashek)
<ahamilto> and a bunch of people for that matter but unimportant
<ahamilto> so, we have a realm, we have our principals
<ahamilto> let's say you decide to log into serenity
<ahamilto> you enter a username and password
<ahamilto> serenity is configured to validate these via Kerberos
<ahamilto> so serenity is going to go find a KDC to talk to
<`bjones> serenity is a transport ship
<ahamilto> `bjones: yes, Firefly class
<`bjones> exactly
<ahamilto> so serenity goes and asks the KDC (hey, can you validate these credentials for me)
<ahamilto> KDC hopefully does so (assuming you entered your password right) and returns to serenity a TGT or ticket-granting-ticket
<ahamilto> a TGT is a temporary proof of your identity; it functions like an ID badge but with an expiration time (typically 8 hours after it was issued)
<ahamilto> the purpose of issuing a TGT is to allow you to subsequently authenticate yourself to other systems without needing to re-enter your password every time
<ahamilto> in the syslab this is used for accessing your homedir
<ahamilto> right after you validate your kerberos credentials and get your TGT
<zan> So that's what I was thinking of when I wrote #3, then
<ahamilto> serenity goes and talks to the AFS servers and says "hey, 2016zan wants access to his homedir, here is his TGT"
<ahamilto> the AFS server then goes to the KDC and says "hey, can you verify for me that this ticket is valid"
<ahamilto> KDC says "who the hell are you"
<ahamilto> AFS server replies "I'm host/afsserver.csl.tjhsst.edu, here's my host principal"
<ahamilto> KDC says "Ok, you're good and the ticket is good"
<`bjones> !praise headaches
<tjhsstBot> headaches: Your skin emanates such a porcelain sheen that I am  tempted to stamp WC under your bosom and across your armpits.
<ahamilto> important note about time, all of the messages above are timestamped
<ahamilto> the KDC will not accept messages that are too old or too far into the future
<ahamilto> default window is usually +-5 minutes
<ahamilto> this is a security measure
<ahamilto> you can't record me requesting an admin ticket and replay it later
<zan> How would it be negative?
<ahamilto> the KDC looks at the time and goes hell no
<ahamilto> zan: if the KDC clock is slower than the client then from the perspective of the KDC, the client is in the future
<jwoglom> zan: time differences between server and client
<`bjones> it actually literally says that
<`bjones> !slogan the future
<tjhsstBot> There's lots of fun in the future.
<ahamilto> therefore, pretty much every kerberos deployment uses NTP to keep the clocks synched otherwise kerberos dies
<`bjones> !slogan dead puppy
<tjhsstBot> Nothing to worry about with dead puppy.
<ahamilto> questions, comments, concerns?