译者注:在翻译这篇文章时，我力求完美，能够完整且正确的反映原文的意思．但是，由于译者水平有限，可能有一些地方理解的有偏差，所以还是请读者读原文进行更加深一步的理解．另外，在本文中，我还添加了一些自己的心得，如果其中有差错，请各位大牛更正．
概括
一般情况下，Kerberos有以下几点:
- 用于验证的协议
- 使用tickets来进行验证
- 不需要在本地存储密码，也不需要通过网络传输密码
- 包括了一个受信任的第三方
- 基于对称密钥加密
你有一个保存在本地的ticket,它证明你有权访问某个服务，它被密钥给加密了．只要这个ticket还有效，你就能够访问那个服务．
一般来说，Kerberos用于内部环境中．比如说，你想要访问一个网站，但是不想要重新输入密码，这时候，存放在你本机上的ticket就起作用啦．它会起到让你只需要登录一次，以后便不用重新输入密码的作用．
当你登录到你的电脑时，或者通过在命令行中执行kinit USER命令，ticket便会被刷新．
Kerberos这个名字起源于格林童话中，Hade的三头犬的名字．这个名字特别适合，因为它引入了一个第三方的验证机构．
Kerberos Realm
管理员会创建Realm,它代表了一个域，限定了你能够访问的服务或者主机．这是很有必要的．
你的机器，就位于Realm中．Realm还包含了你请求的服务以及你要访问的主机，以及KDC(Key Distribution Center).如下图所示:
需要牢记的一些内容
当你请求访问一个服务或者一个主机的时候，你会和三个组件进行交互:
- 用于验证的服务器(The Authentication Server)
- 用于产生Ticket的服务器(The Ticket Granting Server)
- 你要访问的服务或者主机
还有其他的我们需要牢记的内容:
- 每次进行交互时，你都会收到两个消息，其中一个是你能够解密的，而另一个则不是你能够解密的．
- 你要访问的服务或者主机从来都不会直接和KDC进行交互
- KDC在它的数据库中，存储了用户机器以及服务的全部密钥
- 密钥是密码加上一个salt经过哈希运算之后得到的值.采用的哈希算法会在Kerberos启动时选择．对于服务以及主机来说，是没有密码的．所以，密钥实际上是由管理员在设置Kerberos时设置的，并且存放在服务以及主机的内存中．
- Kerberos采用对称加密技术
- KDC本身又是经过加密的，防止有不法人士从KDC中的数据库中窃取密钥．
- Kerberos可以配置为使用非对称加密技术，而非对称加密技术．
下面我们将会用实例来讲解到底在你和服务进行交互时，都发生了什么．
你和The Authentication Server
当你想要访问一个HTTP服务时，你需要做的第一件事，就是告诉The Authentication Server你是谁．当你登录到你的机器，或者执行kinit USERNAME时，便会发送给The Authentication Server一条消息，这条消息包含的内容，将会被用于生成Ticket Granting Ticket．那么这条消息到底包含什么内容呢?
- 你的名字/ID
- 你要访问的服务的名字/ID(在第一步中，是Ticket Granting Server)
- 你的网络地址(如果是多个主机，则是一个IP列表．如果是任意一台机器，那么就是null)
- TGT的寿命
The Authentication Server会检查你是否存在于它的数据库．它也只会检查你是否存在．
如果没有任何错误(比如，用户没有发现)，那么，它会随机生成用于你和The Ticket Granting Server进行交互的session key.
The Authentication Server会给你发送回来两个消息．其中一个消息是TGT,它包含了:
- 你的名字/ID
- TGS的名字/ID
- 时间戳
- 你的网络地址(如果是多个主机，则是一个IP列表．如果是任意一台机器，那么就是null)
- TGT的寿命(可能是你发送给The Authentication Server的消息中请求的那一个．如果你或者TGS的密钥快要过期了，那么它的值就小一些．如果你在设置Kerberos时设置了，那么就有其他的约束)
- TGS Session Key
这条消息，会被TGS Secret Key加密．
还有一条其他的消息，它包含了:
- TGS的名字/ID
- 时间戳
- 寿命
- TGS Session Key
这条消息被你的密钥加密．
TGS Session Key是你和TGS进行交互的密钥．
前面也介绍过了，你的密钥由你的密码，加上一个salt(形式为:user@REALMNAME.COM)，经过哈希运算之后得到的值．你可以使用你的密钥来解密得到的第二个消息，从中你可以得到TGS Session Key.如果你的密码不对，你就不能获取到．
然而，你不能解密TGT,因为你不知道TGS Secret Key.所以，这个经过TGS Secret Key加密后的TGT,会被存放在你的机器上的Credential Cache中．
你和The Ticket Granting Server
在上一步中，你已经获得了一个无法解密的TGT，以及一个TGS Session Key.
现在，我们需要跟The Ticket Granting Server进行交互了．
你需要向The Ticket Granting Server发送三个消息．其中第一个叫做Authenticator，被TGS Session Key加密，它包含了:
- 你的名字／ID
- 时间戳
同时，你还需要发送一个普通的没有经过加密的消息，其中包含了:
- 你想要访问的HTTP Service的名字/ID
- Ticket的寿命
第三个消息，就是位于你的Credential Cache中的你无法解密的TGT.
The Ticket Granting Server首先会检查你要访问的Service是否在KDC的数据库中存在．
如果确实存在，那么，TGS就会用它的密钥来解密TGT.由于TGT中包含了TGS Session Key,所以TGS就能解密你发送的用TGS Session Key加密的第一个消息．
然后，TGS会做以下几件事:
- 比较你在Authenticator中传递的Client ID是否和TGT中的相同．
- 比较你在Authenticator中传递的时间戳以及TGT中的时间戳(一般情况下，Kerberos允许有两分钟的误差，但是你可以自己配置这个误差)
- 检查TGT是否已经过期了
- 检查Authenticator是否早就接受过了(防止重放攻击)
- 如果在原始请求中的网络地址非空，则检查你的IP地址是否和原始请求中的网络地址相同，或者是否在原始请求的网络地址中
当上面的事情做完后，The Ticket Granting Server会随机生成一个HTTP Service Session Key,并且为你准备一个包含下面内容的HTTP Service ticket:
- 你的姓名/ID
- HTTP 服务名/ID
- 你的网络地址(如果是多个主机，则是一个IP列表．如果是任意一台机器，那么就是null)
- 时间戳
- ticket的寿命
- HTTP Service Session Key
这个HTTP Service ticket被HTTP Service Secret Key加密．其中HTTP Service Secret Key是服务的密钥．
然后TGS会给你发送回来两个消息．一个是经过加密后的HTTP Service Ticket,另一个包括:
- HTTP服务名/ID
- 时间戳
- ticket的寿命
- HTTP Service Session Key
这条消息被TGS Session Key加密．
然后，你的机器通过解密那条被TGS Session Key的消息，来获得HTTP Service Session Key.
然而，你的机器不能解密HTTP Service ticket，因为它没有HTTP Service Secret Key.
你和The HTTP Service
为了访问HTTP服务，你的机器需要发送另外一条Authenticator,它包含了:
- 你的名字/ID
- 时间戳
这个Authenticator被HTTP Service Session Key加密．
除此之外，你的机器还需要发送从TGS收到的你无法解密的HTTP Service Ticket．
HTTP服务通过它的密钥解密HTTP Service Ticket，来获得HTTP Service Session Key.然后使用HTTP Service Session Key来解密你发送的Authenticator.
和TGS类似，HTTP服务器然后会做下面的事情:
- 比较你在Authenticator中传递的Client ID是否和Ticket中的相同．
- 比较你在Authenticator中传递的时间戳以及Ticket中的时间戳(一般情况下，Kerberos允许有两分钟的误差，但是你可以自己配置这个误差)
- 检查Ticket是否已经过期了
- 检查Authenticator是否早就接受过了(防止重放攻击)
- 如果在原始请求中的网络地址非空，则检查你的IP地址是否和原始请求中的网络地址相同，或者是否在原始请求的网络地址中
然后，HTTP 服务器会给你发送一条Authenticator消息，它包含了你的ID，以及时间戳，用HTTP Service Session Key加密．
你的机器，通过解密Authenticator来得知它已经通过了验证，以及HTTP服务的ID和时间戳．
在以后你想要访问那些已经通过验证的服务的时候，只要HTTP Service Ticket没有过期，那么就能够访问．
