kerberos的认证过程

为什么需要kerberos：

kerberos目的是认证，既然认证就是辨别身份，那我输入用户名密码不就好了，为何要有Kerberos这样一个复杂的东西；举例来说，有A，B，C三个服务器，分别提供不同的服务，user要访问ABC都需要输入用户名密码，但是ABC没必要都存一份user的密码，所以就衍生出一个中央服务器D来专门存储用户名密码；如果user通过了D的认证，那就是合法的身份，就可以使用ABC任何一个服务，所以user需要告诉ABC它通过了D的认证。如何证明这个事情，以及信息在网络传输过程如何防止被截获篡改而假冒等等，解决这些问题就靠Kerberos。

kerberos的三个角色：

• AS（Authentication Server）：认证服务器
• KDC（ker DIstribution center）：密钥分发中心
• TGT（Ticket Granting Ticket）：票据授权票据
• SGT：服务许可票据
• TGS（Ticket Granting Server）：票据授权服务器
• SS（service server）：特定服务提供端

1.访问服务的用户

2.提供服务的server

3.KDC 密钥分发中心

• 其中 KDC 服务默认会安装在一个域的域控中，而 Client 和 Server 为域内的用户或者是服务，如 HTTP 服务，SQL 服务。在 Kerberos 中 Client 是否有权限访问 Server 端的服务由 KDC 发放的票据来决定。

KDC 又分为两个部分：

• AS 的作用就是验证 Client 端的身份，验证通过就会给一张 TGT票给 Client。
• TGS 的作用是通过 AS 发送给 Client 的票（TGT）换取访问 Server 端的票。

kerberos认证流程：

1和 2步骤 client和KDC相互认证
1>>> AS_REQ:用户向KDA发起AS_REQ，请求的凭据是用户hash加密的时间戳，内容为通过 Client 密码 Hash 加密的时间戳、ClientID、网络地址、加密类型等。

2>>> AS_KDA:KDA对用户hash进行解密，验证成功后返回给用户由用户密码 HASH 加密的 sessionkey-as 和 TGT（由 KRBTGT HASH 加密的 sessionkey-as 和 TimeStamp 以及PAC，PAC里包含用户的sid，用户所在的组。）

3>>> TGS_REQ:用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求。

Client 接收到了加密后的 Sessionkey-as 和 TGT 之后，用自身密码解密得到 Sessionkey-as，TGT 是由 KDC 密码加密，Client 无法解密。这时 Client 再用 Sessionkey-as 加密 TimeStamp 和 TGT 一起发送给 KDC 中的 TGS（TicketGranting Server）票据授权服务器换取能够访问 Server 的票据。

4>>> TGS_REP:KDC使用krbtgt hash进行解密，如果正确，就返回用服务hash加密的TGS票据（这一步不管用户有没有对服务的访问权限，只要TGT是正确的，就会返回TGS票据）

TGS 收到用户发送过来的 TGT 和 Sessionkey-as 加密的 TimeStamp 之后，首先会检查自身是否存在 Client 所请求的服务。如果服务存在，则用 KRBTGT 密码解密 TGT。一般情况下 TGS 会检查 TGT 中的时间戳查看 TGT 是否过期，且原始地址是否和 TGT 中保存的地址相同。验证成功之后将用 sessionkey-as 加密的 sessionkey-tgs 和 Server 密码 HASH 加密的 Sessionkey-tgs 发送给 Client。

5>>> AP_REQ:用户用获取的TGS票据去请求服务

6>>> AP_REP:服务器使用自己的hash去解密TGS票据，如果解密正确，就拿解密得到的PAC去KDA询问用户有没有访问权限，KDC解密获取用户的sid以及用户所在的组，在根据服务的ACL，判断用户是否可以访问该服务。