Kerberos(1)-Kerberos工作原理
Kerberos认证
kerberos简介
在古希腊神话中Kerberos指的是：有着一只三头犬守护在地狱之门外,禁止任何人类闯入地狱之中。
而现实中的Kerberos是一种**网络身份验证协议,旨在通过密钥加密技术为客户端/服务器应用程序提供身份验证,**主要用在域环境下的身份验证。Kerberos只提供每个用户的权限信息，需要每个服务来确认用户是否可以访问其资源。
kerberos具体内容
传输层
Kerberos使用UDP/TCP作为传输协议，UDP/TCP是以明文方式发送数据。因此Kerberos需要提供加密。
主要对象
这几个对象在Kerberos中共同工作来提供认证。
- Client-想要访问服务的用户或客户端
- AP-应用服务器，提供用户所需的服务
- KDC-密钥分发中心，kerberos的主要服务，负责颁发票据，安装在DC域控制器上。由颁发TGT的AS（身份验证服务）支持。
加密密钥
Kerberos处理结构有几种，如票据。这些结构中有很多是加密或者签名了的，来防止被第三方篡改。这些密钥密钥如下。
- KDC或krbtgt密钥-由krbtgt账户的NTLM hash衍生
- 用户密钥-用户NTLM hash派生
- 服务密钥-来自服务所有者的NTLM hash，可以是一个用户或者计算机账户
- 会话密钥-由用户和KDC协商确定
- 服务会话密钥-在用户和服务之间使用
票据
Kerberos 处理的主要结构是 ticket。票据传递给用户，方便用户在Kerberos认证流程中使用。票据分为两种.
- TGS (Ticket Granting Service) 是用户用来对服务进行认证的票据。它是用服务密钥加密的。
- TGT (Ticket Granting Ticket) 是提交给 KDC 以请求 TGS 的票据。它是用 KDC 的密钥加密的。
PAC
PAC (Privilege Attribute Certificate) 是一个几乎包含在每个票据中的结构。这个结构包含了用户的权限，并且是用 KDC 的密钥签名的。
有可能通过与KDC通信来验证PAC，但是并不常见。然而验证PAC也只检查其签名，不检查PAC中的权限是否正确。
此外，Client可以通过在票据请求的KERB_PAC_REQUEST字段中指定PAC来避免将其放入票据中。（先简单介绍，后续详细探究PAC）
消息
Kerberos 使用不同种类的消息。其中最主要是以下几种。
- KRB_AS_REQ: 用来向 KDC 请求 TGT。
- KRB_AS_REP: 用来由 KDC 交付 TGT。
- KRB_TGS_REQ：用于使用 TGT向 KDC 请求 TGS。
- KRB_TGS_REP：用于由KDC交付TGS。
- KRB_AP_REQ：用于使用 TGS 对用户进行服务认证。
- KRB_AP_REP：（可选）由服务用来对用户进行身份验证。
- KRB_ERROR。传达错误情况的信息。
它不是 Kerberos 的一部分，而是 NRPC 的一部分，AP 也可以选择使用 KERB_VERIFY_PAC_REQUEST 消息来向 KDC 发送 PAC 的签名，并验证它是否正确。
kerberos认证流程
-Kerberos%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/image-20220225020242688-16457257643591.png)
KRB_AS_REQ
首先，用户必须从KDC获取到一个TGT。所以必须发送一个KRB_AS_REQ。
-Kerberos%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/KRB_AS_REQ-16456427564093.png)
KRB_AS_REQ主要是以下字段：
- 带有客户端密钥的加密时间戳，以验证用户并防止重放攻击
- 已认证用户的用户名
- 与krbtgt相关服务的主体名称（SPN）
- 用户生成的临时信息
注意：
通常情况下加密的时间戳只有在用户需要预认证的情况下才需要，除非在用户账户中设置了DONT_REQ_PREAUTH标志。
KRB_AS_REP
收到请求后，KDC通过解密时间戳来验证用户身份。如果信息是正确的，那么它必须以KRB_AS_REP来回应。
-Kerberos%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/KRB_AS_REP-16456427870795.png)
KRB_AS_REP主要是以下字段：
- 用户名
- TGT
- 用户名
- 会话密钥
- TGT过期时间
- 具有用户权限的PAC，由KDC签名
- 一些带有用户密钥的加密数据
- 会话密钥
- TGT过期时间
- 用户的临时信息，防止重放
一旦完成，用户就已经拥有了TGT，可以用来申请TGS，并在之后获得服务。
KRB_TGS_REQ
为了请求TGS，必须向KDC发送KRB_TGS_REQ消息。
-Kerberos%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/KRB_TGS_REQ-1-16456432552937.png)
KRB_TGS_REQ主要是以下字段：
- 用会话密钥加密的数据
- 用户名
- 时间戳
- TGT
- 请求服务的主体
- 用户生成的临时信息
KRB_TGS_REP
在收到 KRB_TGS_REQ 消息后，KDC 返回 KRB_TGS_REP 中的 TGS。
-Kerberos%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/KRB_TGS_REP-16456435608059.png)
KRB_TGS_REP 主要是以下字段：
- 用户名
- TGS
- 服务会话密钥
- 用户名
- TGS过期时间
- 具有用户权限的PAC，由KDC签名
- 带有会话密钥的加密数据
- 服务会话密钥
- TGS过期时间
- 用户临时信息
KRB_AP_REQ
最后，如果一切顺利，用户已经有了一个有效的TGS来与服务进行交互。为了使用它，用户必须向AP发送一个KRB_AP_REQ消息。
-Kerberos%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/KRB_AP_REQ-164564361736012.png)
KRB_AP_REQ主要是以下字段：
- TGS
- 服务会话加密数据
- 用户名
- 时间戳，避免重放
之后，如果用户的权限是正确的，他就可以访问服务。如果是服务将根据KDC验证PAC（通常不会发生）。而且，如果需要相互认证，它将用KRB_AP_REP消息来回应用户。
参考连接：