kerberos 协议概述

Posted 2020-11-23 zlg666

前言

域环境：

kerberos主要是在域环境做身份认证。什么是域环境呢？

域英文叫DOMAIN——域(Domain)是Windows网络中独立运行的单位，将网络中多台计算机逻辑上组织到一起，进行集中管理， 这种区别于工作组的逻辑环境叫做域。

域环境的作用：

MS以后不要将名称搞的这么专业,还是要考虑到中国的国情,早知道将"域"改成"中央"将"工作组"改成"自由市场",这样方便易懂,就不会有这么多的问题了。

在下图中 YUNYING.LAB 为其他两个域的根域，NEWS.YUNYING.LAB 和 DEV.YUNYING.LAB 均为 YUNYING.LAB 的子域，这三个域组成了一个域树。子域的概念可以理解为一个集团在不同业务上分公司，他们有业务重合的点并且都属于 YUNYING.LAB 这个根域，但又独立运作。同样 TEST.COM 也是一个单独的域树，两个域树 YUNYING.LAB 和 TEST.COM 组合起来被称为一个域林。

 

 

 

kerberos的认证过程

为什么需要kerberos：

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

kerberos的三个角色：

1.访问服务的用户

2.提供服务的server

3.KDC（ker DIstribution center）密钥分发中心

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

KDC 又分为两个部分：

Authentication Server（AS）：AS 的作用就是验证 Client 端的身份，验证通过就会给一张 TGT（Ticket Granting Ticket）票给 Client。

Ticket Granting Server（TGS）：TGS 的作用是通过 AS 发送给 Client 的票（TGT）换取访问 Server 端的票。

kerberos认证流程：

 

 

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，判断用户是否可以访问该服务。

 

https://tools.ietf.org/html/rfc4120.html           详细解读