1. Kerberos 认证原理

1.1 kerberos 协议

Kerberos 是一种由 MIT（麻省理工大学）提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。

1.2 Kerberos协议框架

在 Kerberos 协议中主要是有三个角色的存在：

1. 访问服务的 Client；

2. 提供服务的 Server；

3.KDC（Key Distribution Center）密钥分发中心

1.3 Kerberos相关名词解释

1. KDC（Key Distribution Center）密钥分发中心
2. Authentication Service：AS 的作用就是验证 Client 端的身份（确定你是身份证上的本人），验证通过就会给一张 TGT（Ticket Granting Ticket）票给 Client
3. Ticket Granting Service：TGS 的作用是通过 AS 发送给 Client 的票（TGT）换取访问 Server 端的票（上车的票 ST）。ST（ServiceTicket）也被称之为 TGS Ticket，为了和 TGS 区分

1.4 Kerberos 详解认证流程

当 Client 想要访问 Server 上的某个服务时，需要先向 AS 证明自己的身份，然后通过 AS 发放的 TGT 向 Server 发起认证请求，这个过程分为三块：

The Authentication Service Exchange：Client 与 AS 的交互，

The Ticket-Granting Service (TGS) Exchange：Client 与 TGS 的交互，

The Client/Server Authentication Exchange：Client 与 Server 的交互。

重要提醒：Kerberos有所有注册服务的密码，就是用这些密码来进行HASH加解密的

(1)The Authentication Service Exchange

KRB_AS_REQ(请求)：

Client->AS：Client 先向 KDC 的 AS 发送 Authenticator1(内容为Client hash加密的时间戳）

KRB_AS_REP(应答)：

AS-> Client：AS根据用户名在AD中寻找是否在白名单中，然后根据用户名提取到对应的NTLM Hash，然后会生成一个随机数session key，然后返回给Client由Client的ntlm hash加密的session key-as作为AS数据，再返回TGT（使用KDC中krbtgt的NTLM Hash加密session key和客户端的信息，客户端的信息里面包含了时间戳等信息）

AS验证的简述：在 KDC(AD) 中存储了域中所有用户的密码 HASH，当 AS 接收到 Client 的请求之后会根据 KDC 中存储的密码来解密，解密成功并且验证信息。
验证成功后返回给 Client两个东西，一个是由 Client 密码 HASH 加密的 session key-as 和 TGT（由 KRBTGT HASH 加密的 session key 和 TimeStamp 等信息）。

(2)TheTicket-Granting Service (TGS) Exchange

KRB_TGS_REQ(请求)：

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

KRB_TGS_REP(应答)：

TGS 收到 Client 发送过来的 TGT 和 Session key 加密的 TimeStamp 之后，首先会检查自身是否存在 Client 所请求的服务。如果服务存在，则用 KRBTGT的HASH解密 TGT。

一般情况下 TGS 会检查 TGT 中的时间戳查看 TGT 是否过期，且原始地址是否和 TGT 中保存的地址相同。

验证成功之后将返回Client两个东西，一个是用 session key 加密的 session key-tgs，然后另一个是 Client要访问的Server的密码 HASH 加密的 session key-tgs（前面和session key加密生成的）生成就是ST（TGS）

(3)TheClient/Server Authentication Exchange

KRB_AP_REQ(请求)：

Client -> Server 发送 Authenticator3(session key-tgs 加密 TimeStamp) 和票据 ST(Server 密码 HASH 加密 session key-tgs)

Client 收到 session key 加密生成的 session key-tgs 和 Server 密码 HASH 加密 session key-tgs生成的TGS 之后，用 session key 解密得到 session key-tgs，然后把 sessionkey-tgs 加密的 TimeStamp 和 ST（也就是TGS）一起发送给 Server。

KRB_AP_REP(应答)：

Server-> Client

server 通过自己的密码解密 ST，得到 sessionkey-tgs, 再用 sessionkey-tgs 解密 Authenticator3 得到 TimeStamp，验证正确返回验证成功。

参考：
https://www.cnblogs.com/zpchcbd/p/11707302.html
https://www.cnblogs.com/tyb1222/archive/2012/07/13/2590747.html
https://blog.csdn.net/duguxingfeng/article/details/101756321

2. Clickhouse 中Kerberos认证实践

Clickhouse新增加的Kerberos认证方式兼容ck自带的用户/密码认证方式，丰富了ck用户登陆认证方式。

2.1 Clickhouse Kerberos认证流程

客户端和服务端在启动时候，都会进行Kerberos认证的初始化，关键的两个函数sasl_server_init()和sasl_client_init().

1. 客户端通过sasl_client_new() 来创建 SASL 连接上下文；
2. 客户端启动 sasl_client_start()和要使用的安全机制列表，clickhouse选择了GSSAPI安全机制；如果 sasl_client_start() 返回 SASL_CONTINUE 或 SASL_OK，则客户端应向服务器发送包含生成的所有验证数据的选定机制，即server ticket。
3. 客户端通过sendHello，发送server ticket；
4. 服务端将接收客户机选定的机制，以及所有的验证数据。随后，服务器将调用 sasl_server_start() 来初始化此会话的机制数据；
5. 服务端sasl_server_start() 还将处理所有的验证数据。如果 sasl_server_start() 返回 SASL_CONTINUE 或 SASL_OK，则服务器将发送验证数据；
6. 服务端sasl_server_step()来处理来自客户机的验证并相应地生成回复。 此交换将持续进行下去，直到验证完成或出现错误为止。

2.2 客户端Kerberos认证代码流程

2.3 服务端Kerberos认证代码流程