2026-10-13·5 分钟阅读
小橘第一天到猫咪公司上班。登录电脑后，它打开内部应用，又访问共享文件夹，很多时候都不用再次输入密码。“奇怪，大家怎么都认识我？”
这是 Kerberos 身份认证常见的使用场景，也是 Windows 域环境中实现单点登录的重要基础。[1] 今天，我们把电脑后台的认证过程，画成小橘亲自领票的故事。
01 登录一次 背后是谁在帮忙
猫咪公司有一个大家共同信任的“办事大厅”——KDC（Key Distribution Center，密钥分发中心）。大厅里有两个窗口：
AS（Authentication Service，认证服务）：负责初始认证，签发 TGT。
TGS（Ticket-Granting Service，票据授予服务）：根据有效凭证签发服务票据。
AS 和 TGS 是 KDC 的两项服务，不必理解成两台独立服务器。在 Windows 域环境中，KDC 运行在域控制器上，并使用 Active Directory 中的账号信息。[2]
小橘走到 AS 窗口：“你好，我来证明一下，我是我。”
02 AS 交换 领取 TGT
“光报名字不够，还需要相应的证明。”客户端向 AS 发起请求。这一阶段的主要消息是 AS-REQ → AS-REP。
以常见的密码预认证方式为例，客户端使用由用户密码派生的密钥，加密时间戳等预认证信息，供 KDC 验证。这个过程并不是把明文密码直接发送给 KDC。
验证通过后，客户端获得两项关键内容：TGT（Ticket-Granting Ticket，票据授予票据），以及客户端与 TGS 后续交互使用的会话密钥。
它们受到相应的加密保护，并非以明文随意传输。[3]
小橘举起 TGT：“现在能去拿入职资料了？”
“先去换票。”窗口小猫指向旁边，“TGT 的用途，是申请后续的服务票据。”
TGT 可以理解成“换票凭证”，不是访问所有资源的通行证。
03 TGS 交换 申请文件服务的 ST
小橘来到 TGS 窗口：“我想访问文件服务，这是我的 TGT。”这一阶段的主要消息是 TGS-REQ → TGS-REP。
实际请求不只有 TGT，还包含目标服务的信息，以及用相应会话密钥加密的认证器（Authenticator）。
认证器中包含客户端身份、时间戳等信息，用于证明请求方掌握配套的会话密钥。
验证通过后，TGS 返回目标服务的服务票据（Service Ticket，本文简称 ST），以及客户端与目标服务使用的会话密钥。
这是面向目标服务的一组凭证，与前一阶段客户端和 TGS 使用的会话密钥用途不同。[4]
小橘记住了：TGT 用于申请服务票据；ST 用于向对应服务证明身份。
04 AP 交换 服务认出了小橘
来到文件服务面前，客户端提交 ST 和认证器，发起 AP-REQ。服务端验证票据和认证器，确认客户端身份。如果要求双向认证，服务端还会返回 AP-REP，让客户端也能验证服务端。[5]
“身份验证通过，你好，小橘。”眼前有两扇门：“入职资料”开着，“猫粮预算”锁着。小橘顺利领取了自己有权限访问的入职资料。
图示说明｜票代表服务票据 ST，小钥匙代表配套的会话密钥。实际认证时，客户端提交的是 ST 和用会话密钥加密的认证器，并不会直接把会话密钥作为凭证发送给服务端。
服务端通常使用自身的长期密钥解开服务票据中的加密部分，取得相应会话密钥，再验证认证器。图中的小钥匙不是打开所有资源的“万能钥匙”。[6]
三段交互：AS 获得 TGT → TGS 获得 ST → AP 向服务认证。
这些交互通常由客户端在后台完成，有效票据可以在适用范围内缓存、复用，所以用户不必反复输入密码。[7]
05 连试三次 有 ST 为什么还是被拒绝
小橘准备离开时，看到了旁边的“猫粮预算”。“里面会不会写着今年能买多少小鱼干？”
它碰了碰门把手。访问被拒绝。
“是不是刚才没操作好？”第二次，拒绝。第三次，还是拒绝。小橘看着手里的 ST，陷入了困惑。
这里有一个关键区别：身份认证成功，并不意味着对所有资源都有访问权限。
漫画中的两扇门，代表同一文件服务中的不同资源。服务已经认出了小橘，但还需要根据资源的访问控制规则，决定是否允许读取预算文件。[8]
所以，这里的“拒绝访问”表示预算资源的权限检查未通过，不能简单等同于 Kerberos 认证失败。
06 多次 DENY 小飞发现需要核查的线索
另一边，飞络安全顾问小飞，正在 SOC 安全运营中心查看告警。
屏幕上出现了一组记录：10:01、10:02、10:03，小橘连续访问猫粮预算，结果都是 DENY。
“短时间内连续访问被拒绝，需要核实一下。”
在这个故事中，文件资源的访问审计日志已经接入监测，并配置了相应的检测规则。
三次是漫画中的示例，不是 Kerberos 的固定告警阈值。实际规则需要结合时间窗口、资源敏感程度、访问频率和业务习惯设置。
多次 DENY 只是值得关注的信号。它可能来自误操作、权限配置问题，也可能涉及异常访问，需要进一步核查。
07 联系本人 确认操作也确认原因
小飞联系上小橘：“刚才这几次访问猫粮预算的操作，是你本人发起的吗？”
“是我。”小橘有点不好意思，“我想看看预算，打不开，就多试了几次。”
小飞把回答与访问时间、账号、来源设备和目标资源等信息核对，了解了这次尝试的背景。
本人确认是核查环节的一部分，仍然需要结合日志和其他线索判断。
如果小橘否认操作，或者回答与记录不一致，就需要进一步调查账号或设备是否存在异常；这次，核查结果与小橘的解释相符。
这也是我们希望通过 SOC 安全运营服务提供的价值：从日志中发现异常，结合上下文核查，并推动后续处理，让告警有人跟进。
08 认证不等于授权
小飞对小橘说道：认证（Authentication）回答“你是谁”；授权（Authorization）回答“你能做什么”。
“Kerberos 帮助文件服务确认了你是小橘。但猫粮预算能不能看，还要看你的权限。”
小橘恍然大悟：“所以，有工牌，也不代表可以随便进入财务室！”
“没错。如果工作确实需要，就按流程申请相应权限。”小飞递给它一张权限申请单。
预算门上的锁负责执行访问控制；小飞负责核查异常、确认情况并提供指导。两者各有职责。
小橘的安全笔记
TGT 用来申请服务票据，ST 用来向目标服务认证。
认证还需要配套的会话密钥和认证器，票据本身不是全部。
认证通过不等于获得所有权限，资源仍然要检查授权。
访问异常需要结合上下文核查，告警不等于已经发生攻击。
最后，小橘又补了一句：“密码要保护，票据和相关密钥也要保护。”
至于猫粮预算——小橘决定先把入职资料读完，再考虑自己有没有合理的工作需求。
参考资料
[1] Microsoft Learn · Kerberos authentication overview阅读原文
[2] Microsoft Learn · Key Distribution Center阅读原文
[3] RFC 4120 · AS Exchange阅读原文
[4] RFC 4120 · TGS Exchange阅读原文
[5] Microsoft Learn · Kerberos Subprotocols阅读原文
[6] RFC 4120 · Client/Server Authentication Exchange阅读原文
[7] Microsoft Learn · Kerberos V5 Protocol阅读原文
[8] RFC 4120 · Authorization阅读原文