kerberos协议通过认证服务器实现了,【域渗透】Kerberos协议认证

参考链接：

详解kerberos认证原理，真的超级无敌详细~~~

kerberos认证的示意图

域控制器(AD)里面有两个重要的服务：Authentication Service(AS)、Ticket Granting Service(TGS)

角色：客户端，AD，服务端

KDC负责管理票据、认证票据、分发票据但是 。KDC 不是一个独立的服务它由以下服务组成：

AS：身份验证服务

TGS：票据分发服务

TGT：票据分发票据

KDC：密钥分发中心(这里理解为AD)

session key：AS随机生成的会话密钥

server session key：TGS随机生成的服务会话密钥

时间相关的信息：时间戳

目的：客户端要访问控制服务端，与服务端建立连接通信。

AS

AS-REQ：客户端发送自己的信息以及要连接的服务端信息给AS，AS去AD查看是否为白名单，验证通过，AS返回session key和TGT1、TGT2

TGT1(session key，TGS服务信息，结束信息)(使用客户端的NTLM hash加密)

TGT2(session key，客户端信息，结束时间) (KDC NTLM hash加密)

AS-REP：客户端接收AS返回的session key及TGT1、TGT2，随后发送 认证因子+TGT2+客户端信息+服务端信息给TGS

使用自己客户端的NTML hash解密TGT1得到里面的session key，TGS服务信息，结束信息(应该会验证一下sessoin key是否一致)

使用解密出来的session key加密生成认证因子(客户端信息，当前时间...等信息)

TGS

TGS-REQ：TGS接收到 认证因子+TGT2+客户端信息+服务端信息，校验后，将生成的TGT3和TGT4发送给客户端

TGS会先用KDC NTLM hash解密TGT2，得到里面的 session key，客户端信息，结束时间

再利用session key解密认证因子，得到里面的 客户端信息，当前时间(时间戳)...等信息

校验：

当前系统时间和时间戳(对比未过期)；

(认证因子)客户端信息和(TGT2)客户端信息；

客户端访问服务端的权限；

......

生成server session key

TGT3(sever session key，服务端信息，票据到期时间)(使用session key加密)

TGT4(server session key，客户端信息，票据到期时间)(使用服务端NTLM hash加密)

TGS-REP：客户端接收到TGT3和TGT4后，将生成的认证因子2+TGT4发送给服务端

使用session key解密TGT3(sever session key，服务端信息，票据到期时间)

使用解密出来的server session key加密生成认证因子2(服务器信息，票据到期时间...等信息)

Server

AP-REQ：服务端接收到认证因子+TGT4，认证成功，服务端返回请求数据

使用自己服务端的NTML hash解密TGT4(server session key，客户端信息，票据到期时间)

使用解密出来的server session key解密认证因子2(服务器信息，票据到期时间...等信息)

AP-REP：客户端接收数据，成功建立通信连接

kerberos认证的时序图

PAC

在 Kerberos 最初设计的几个流程里说明了如何证明 Client 是 Client 而不是由其他人来冒充的但并没有声明 Client 有没有访问 Server 服务的权限因为在域中不同权限的用户能够访问的资源是有区别的。

所以 Microsoft 为了解决这个问题在实现 Kerberos 时加入了 PAC 的概念PAC 的全称是 Privilege Attribute Certificate特权属性证书。

PAC 可以理解为一串校验信息为了防止被伪造和串改原则上是存放在 TGT 里并且 TGT 由 KDC hash 加密。同时尾部会有两个数字签名分别由 KDC 密码和 server 密码加密防止数字签名内容被篡改。

Ticket