Quick Look: Kerberos
You know how after you've signed on to your workstation, you can open up your Outlook or Lync without having to sign into them? Or, you can pull up your company's intranet without having to sign your username and password again? That's something called single-sign-on (SSO) and it's made possible by Kerberos. Kerberos is a security protocol for authentication. According to Greek mythology, Kerberos was the three-headed dog that guarded the gates of Hades.
If everything checks out, the TGS will pass back a Service Session Key to use with the new server, and a Service Ticket containing user information, which is encrypted using a secret key that only app01 and the Kerberos services know. My workstation then sends the Service Session Key along with the Service ticket to app01. My workstation also provides a timestamped authenticator, which is encrypted with the Service Session Key.
Kerberos uses 3 components: a Key Distribution Center (KDC), an Authentication Service and a Ticket Granting Service (TGS). All of these are usually running on an Active Directory Domain Controller (DC). The way this would look is described below.
I want to connect from my workstation to an application server that we'll call app01. To get started, I'll need to login to my workstation. This will send a logon request to the Kerberos Authentication Service which is running on the DC. I'm connected to. My logon request will encrypt the time and date on my local workstation using my password as the hash for the encryption key.
When the DC receives the logon request, the Authentication Service will use what it believes my password is to decrypt the request. If the message decrypts successfully and the date/time in the request is close (within 5 minutes or so) of the DC's time, I've successfully proven that I am who I say I am as far as Kerberos is concerned. Then the Ticket Granting Service will send a Ticket Granting Ticket (TGT) back to my workstation, encrypted using a secret key, that is only known by the KDC. A TGT will contain information such as the client name, IP address, a timestamp, and a validity period (like 8 hours or 10 hours, configurable by IT). The TGS will also send a Ticket Granting Service (TGS) Session Key (which is encrypted with my password as the hash), so that all communication between my workstation and the Kerberos services are encrypted.
Next, my workstation will attach the server or service that I'd like to connect to to the TGT and send it back to the TGS. My workstation will also send along with that a timestamped client ID encrypted using the TGS Session Key. The TGS will then check the TGT and Client ID provided by my workstation. The Kerberos server has the secret key to decrypt the TGT along with knowing my password so it can decrypt the TGS Session info.
If everything checks out, the TGS will pass back a Service Session Key to use with the new server, and a Service Ticket containing user information, which is encrypted using a secret key that only app01 and the Kerberos services know. My workstation then sends the Service Session Key along with the Service ticket to app01. My workstation also provides a timestamped authenticator, which is encrypted with the Service Session Key.
App01 looks at the Service Ticket along with the authenticator, making sure the credentials included match up to the Service Ticket from Kerberos, App01 lets me in since Kerberos was a trusted third-party that verified I was who I said I was.
After that, I'm done. My workstation can now send commands and/or data to app01.
After that, I'm done. My workstation can now send commands and/or data to app01.
Comments
Post a Comment