📒博客主页：开心星人的博客主页
🔥系列专栏：Try to Hack
🎉欢迎关注🔎点赞👍收藏⭐️留言📝
📆首发时间：🌴2022年10月7日🌴
🍭作者水平很有限，如果发现错误，还望告知，感谢！

@toc

Kerberos概述

Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。

==Kerberos是一个假设网络环境不安全的情况下能够正常进行认证工作的协议。== 该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。
在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术(如:共享密钥)执行认证服务的。

• Domain Controller (域控制器)，简称DC，一台计算机，实现用户、计算机的统一管理。
• Key Distribution Center(秘钥分发中心)，简称KDC，默认安装在域控里，包括AS和TGS。
• Authentication Service(身份验证服务)，简称AS，用于KDC对Client认证,为Client生成TGT的服务。
• Ticket Grantng Service (票据授予服务)，简称TGS，用于KDC向Client和Server分发Session Key（临时key）。
• Active Directory(活动目录)，简称AD，用于存储用户、用户组、域相关的信息。
• Client 客户端，指用户。
• Server 服务端，可能是某台计算机，也可能是某个服务（如HTTP服务，SQL服务）。

票据（Ticket）：是网络对象互相访问的凭证。

TGT（Ticket Granting Ticket）：入场券，通过入场券能够获得票据，是一种临时凭证的存在。

KDC负责管理票据、认证票据、分发票据，但是KDC不是一个独立的服务，它由以下服务组成：
Authentication Service: 为client生成TGT的服务
Ticket Granting Service: 为client生成某个服务的ticket

域认证粗略流程

1、client向kerberos服务请求，希望获取访问server的权限。 kerberos得到了这个消息，首先得判断client是否是可信赖的， 也就是白名单黑名单的说法。这就是AS服务完成的工作，通过在AD中存储黑名单和白名单来区分client。成功后，返回AS返回TGT给client。
2、client得到了TGT后，继续向kerberos请求，希望获取访问 server的权限。kerberos又得到了这个消息，这时候通过client 消息中的TGT，判断出了client拥有了这个权限，给了client访问server的权限ticket。
3、client得到ticket后，终于可以成功访问server。这个ticket只是针对这个server，其他server需要向TGS申请。

域认证详细流程

1、AS-REQ—AS-REP阶段：
首先Client用自己的哈希值NTLM-hash对timestamp、client-info、server-info等数据进行加密，发送给AS，向AS请求TGT票据。（AS-REQ）

当AS收到Client发来的信息后，AS会先向活动目录AD请求，询问是否有此Client用户，如果有的话，就会取出该Client的NTLM hash，然后生成一个随机秘钥称为Session-Key as（临时秘钥Session-Key）。并使用Client NTLM-hash 加密 Session-key as 作为一部分内容。

还有一部分内容就是TGT：使用KDC一个特定账户krbtgt的NTLM-hash对Session-key as、timestamp、Client-info进行的加密。然后将这两部分回复给Client。（AS-REP）

该阶段是Client和AS的认证。

2、TGS-REQ—TGS-REP阶段：
Client 收到AS发来的AS-REP后，先使用自身的 NTLM Hash 解密得到 Session-key as，然后使用 Session-key as 对 Client-Info、timestamp、Server-Info 加密作为一部分，加上TGT ，一并发送给 KDC中的 TGS。（TGS-REQ）

TGS 收到请求后，使用 krbtgt 的 NTLM Hash 解密 TGT，得到 Session-key as、timestamp、Client-info，同时，使用 TGT 解密出的 Session-key as 解密第一部分内容，得到Client-info、timestamp。 比对这两部分解密得到的内容以验证是否通过。通过后，生成一个新的随机秘钥(Session-Key tgs)，并向Client回复TGS-REP的两部分内容：

一部分是Session-key as 加密的 Session-key tgs
另一部分是ST(ticket)，即Server NTLM-hash加密的数据(Session-key tgs、timestamp、Client-info)
该阶段是Client和KDC的通信。

3、AP-REQ—AP-REP阶段：
Client收到TGS-REP后，先用自己保存的Session-key as解密出了Session-key tgs。再使用Session-key tgs加密Client-info、timestamp作为一部分内容，另一部分是ST，一并发送给Server。（AP-REQ）

Server 收到Client发来的AP-REQ后，用自身的NTLM Hash解密了ST，得到Session-key tgs，再用Session-key tgs解密第一部分得到Client-info、timestamp。然后与ST的Client-info、timestamp进行对比。timestamp 一般时间为8小时。验证通过后，回复AP-REP，最终建立通信。

https://www.freebuf.com/articles/network/245872.html
https://zhuanlan.zhihu.com/p/77873456
https://payloads.online/archivers/2018-11-30/1/
https://daiker.gitbook.io/windows-protocol/kerberos/1