盘点认证协议 : 普及篇之Kerberos 一 . 前言 Kerberos 最初是由麻省理工学院(MIT)开发的，是雅

总文档 :文章目录
Github : github.com/black-ant

纯约束型协议 : OAuth , SAML , OIDC , CAS ,LTPA
服务器类协议 : RADIUS , Kerberos , ADFS
认证方式类 : OTP , 生物认证 (人脸 , 声纹 , 指纹)
认证服务器(附带) : AD , LDAP , ADFS

这一篇来聊一下 Kerberos 协议 , 已经基于Kerberos的 AD 域单点

一 . 前言

Kerberos 最初是由麻省理工学院(MIT)开发的，是雅典娜计划(projectathena)的一部分 , Kerberos 提供了一个集中的身份验证服务器，其功能是对用户到服务器的身份验证，以及对用户到服务器的身份验证。在 Kerberos 身份验证中，服务器和数据库用于客户端身份验证。Kerberos 作为第三方受信任服务器(称为密钥分发中心(KDC))运行。网络上的每个用户和服务都是一个主体。

Kerberos 优点

密码从不通过网络发送，因为只有密钥以加密形式发送;
身份验证是相互的，因此客户端和服务器在相同的步骤进行身份验证，并且它们都确信自己正在与正确的对应方进行通信;
身份验证可重用且不会过期;
Kerberos 完全基于开放的互联网标准
Kerberos 被许多行业采用，因此其安全协议或底层模块中的任何新缺陷都会很快得到纠正

Kerberos 缺点

如果未经授权的用户可以访问密钥分发中心，则整个身份验证系统将受到威胁
Kerberos 只能被支持 Kerberos 的应用程序采用。为了让某些应用程序能够识别 Kerberos，重写这些应用程序的代码可能是个问题

Kerberos 关键词

安全认证协议
tickets 验证
密码保护（本地不保存，链路不传输）
对称加密
Server - client 可以相互验证
有可信第三方

二 . Kerberos 基础要点

2.1 Kerberos 成员

认证体系成员

Client 成员
应用程序服务器 (AP , ApplicationServer , Resource)
密钥分配中心 (KDC) : AS + TGS + DB
- 发票的可信第三方。在活动目录中，每个网域控制器都充当一个 KDC。
- KDC 提供两个核心服务:
  - 身份验证服务(AS)对客户机进行身份验证并向其发出票证;
  - 票证授予服务(TGS)接受经过身份验证的客户机并向其发出票证以访问其他资源
- KDC 存在一个数据中心 (Database , db)

2.2 Kerberos 架构

架构特点 :

消息 = 可解码部分 + 不可解码部分
服务端不与 KDC 直接交流
KDC 中拥有所有用户及密码

涉及概念 :

principal : 认证主体，类似于用户名
realm : 作用域，一个 principal 只在指定的 realm 中起作用
password : 用户密码，对应于 kerberos 中的 master_key ，可存在于 keytab文件中
credential ：凭证，用于证明用户 / 行为的有效性（password / ticket）
Long-term Key/Master Key ：长期不变的 key , 他的原则是不能在网络上传输
Short-term Key/Session Key ：可在网络上进行传输的key , 这种 key 有时效性

TGT 和 TGS 的区别

TGT KDC 加密部分（不可解读） ： name/ID + TGS的 name /ID + 时间戳 + IP 地址 + TGT 生命周期 + TGS session key
TGT 个人加密部分（可解读） ：TGS 的 name / ID + 时间错 + 生命周期 + TGS session key

2.3 Kerberos 请求流程

Kerberos 协议过程主要有两个阶段，第一个阶段是 KDC 对 Client 身份认证，第二个阶段是Service对Client身份认证。

第一次：客户端输入登录信息 , Kerberos 客户机创建一个加密密钥并向身份验证服务器(AS)发送一条消息
第二次： AS 使用这个密钥创建临时会话密钥，并向票据授予服务(TGS)发送消息
第三次： TGS 向客户机授予票据和服务器会话密钥 , 客户端使用这些来与服务器进行身份验证并获得访问权

以下是 Kerberos 访问详情 :

KRB_AS_REQ: 从身份验证服务(AS)请求TGT
- 客户机的请求包括用户的用户主体名(UPN)和时间戳。它使用用户的密码散列进行加密
KRB_AS_REP : 从身份验证服务接收TGT
- KDC 使用 UPN 在其数据库中查找客户机，并使用用户的密码 hashto 尝试解密消息
- 如果 KDC 成功地解密 TGT 请求，并且时间戳位于 KDC 配置的时间偏差内，则身份验证成功
- 身份认证成功后 , KDC将TGT 和 TGS会话密钥被发送回客户端。TGS 会话密钥用于加密后续请求
KRB_TGS_REQ : 发送当前的 TGT 并请求TGS
- 客户机显示它的 TGT 以及一个请求，包括它想要访问的服务的服务主体名称(Service Principal Name，SPN)
- TGS 请求使用TGS会话密钥进行加密
KRB_TGS_REP : 从 KDC 接收 TGS
- KDC 验证 TGT，如果成功，则生成 TGS。TGS 包含有关请求者的信息(如请求者的 SID 和组成员身份) ，并使用服务的密码散列进行加密
- TGS 和服务会话密钥使用 TGS 会话密钥加密，然后发送回客户机
KRB_TGS_REP : 将 TGS 提交给应用服务器进行授权
- 客户机将从 KDC 接收的 TGS 连同验证者消息一起发送到应用服务器，验证者消息使用服务会话密钥进行加密 (App 此时会拿着 TGS 去 KDC 认证)
KRB_AP_REP : 授予客户端访问服务的权限
- 客户端接收消息并用服务会话密钥对其进行解密
- 应用服务器从服务票据中提取特权属性证书(PAC) ，用网域控制器验证其内容
- 仅当票据授予票据(TGT)超过20分钟时，才会验证票据/PAC

2.5 KDC 流程详情

基础成员　：

-》 组成角色
  > KDC : key distributed center 密钥配置中心 , 整个安全认证过程的票据生成管理服务 , 包含 AS 和 TGS
  > AD ：account database ，存储所有client的白名单

-》 主要角色
  > C : Client 
  > AS :  Authentication Server 认证服务器 ，完成用户认证
  > TGS : Ticket Granting Server 凭证服务器 
  > ST : Http Service Ticket
  > SS : Service Server
  > RS : Resource server

Step 1 : KRB_AS_REQ 第一次申请 TGT

请求 C->SS : 通过明文（Name/身份信息 , IP/client 消息 , TGT 有效时间）访问（亦可使用 Master key 进行加密，AD 中保存有 Master key）
处理 IN SS : SS 判断该对象是否在 AD 中存在 , 并且产生 Session Key 用于 TGS 之间通信
返回 SS->C:返还TGT (TGT 服务端部分 + TGT 个人部分)

Step 2 : KRB_TGS_REQ 第二次生成 TGS

> 请求 C -> TGS :  
  -> TGS Session key 加密部分（Name/ID + 时间戳 + client Info），明文 （服务Name/ID+生命周期），TGT 
  
> 处理 IN TGS  （对TGT 第一部分解密 ）:  
  -> 1. 用户名对比 （TGT <-> 认证器）
  -> 2. 时间戳对比
  -> 3. 是否过期
  -> 4. IP是否一致
  -> 5. 认证器是否已存在于缓存 
  -> 6. 添加权限和认证服务  
  -> 7. 产生 Http Service Session Key
  -> 8. 准备 ST
  
> 返回  TGS -> C: 
  -> ST  ( Http 服务密码 进行加密 ) = 个人name/id + Http 服务name /id + IP + 时间戳 + ST 生命周期 + Http Service Session Key
  -> TGS Session Key 加密部分 = Http 服务name /id + 时间戳 + ST 生命周期 + Http Service Session Key

Step 3 : 资源服务器处理

> 请求 C -> RS : 
   -> Http Service Session Key加密部分 : 个人 name / ID + 时间戳
   
> Resource 服务器 中 ：
   -> 1. 对比用户名
   -> 2. 比较时间戳
   -> 3. 检查是否过期
   -> 4. 检查IP地址
   -> 5. 是否已经存在于缓存

2.5 KDC 的使用前提

域控制器之间的复制 :
- 如果部署了多个域控制器(即多个 KDC) ，则必须启用复制并及时回收。
- 如果复制失败或回收被延迟，当用户更改密码时，身份验证可能
客户端和 kdc 必须将他们的时钟同步
- 在 Kerberos 中，时间的准确度量对于防止重放攻击非常重要。
- Kerberos 支持可配置的时间偏移(默认5分钟) ，超过这个时间，身份验证将失败
客户端和 kdc 必须能够在网络上进行通信
- Kerberos 流量发生在 TCP 和 UDP 端口88上，所有客户端都必须能够访问至少一个 KDC (网域控制器)
客户端、用户和服务必须具有唯一的名称
- 计算机、用户或服务主体名称的重复名称可能导致身份验证失败
客户端和 kdc 必须使用 NETBIOS 和 DNS 名称解析
- 客户端和 kdc 必须使用 NETBIOS 和 DNS 名称解析
- Kerberos 服务主体名称通常包括 NETBIOS 和 DNS 地址，这意味着 KDC 和 Client 必须能够以相同的方式解析这些名称
- 某些情况下 , IP 地址也可用于服务主体名称

三 . Kerberos AD域配置

3.1 配置 KDC DB 部分

Step 1 : 创建Kerberos SPN 用户

Step 2 : 配置用户属性 , 设置不要求验证 , 密码不过期

Step 3 :生成 kerberos.keytab

ktpass.exe /out c:\kerberos.keytab /princ HTTP/antblack.com@ADSERVER.COM.CN /pass zzy19950810 /mapuser kerberos@ADSERVER.COM.CN /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT

ADSERVER.COM.CN 
    //- 当前域名
antblack.com 
    //- KDC Client 端域名 (即应用服务器域名)
kerberos@ADSERVER.COM.CN 
    //- 绑定的用户
zzy19950810
    //- 绑定的密码
RC4-HMAC-NT
    // -加密方式

Step 4 :生成后用户会多委派属性 ,选择信任

同时可以看到用户已经绑定了多个(PS : 这里实际上应该是ADSERVER.COM.CN , 截图问题)

3.2 配置 KDC

CentOS 7 可以不用安装 ,如果 klist 不存在 , 执行以下命令
yum install krb5-server krb5-libs krb5-auth-dialog

修改 /etc/krb5.conf

# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 default_realm = ADSERVER.COM.CN
 default_keytab_name = /opt/kerberos.keytab
 default_tkt_enctypes = rc4-hmac
 default_tgs_enctypes = rc4-hmac

[realms]
ADSERVER.COM.CN= {
  kdc = 192.168.158.9
}

[domain_realm]
.adserver.com.cn = ADSERVER.COM.CN
adserver.com.cn = ADSERVER.COM.CN

/opt/kerberos.keytab : windows AD 之前生成的 , 拖入应用服务器
192.168.158.9 : KDC DB 地址
ADSERVER.COM.CN : KDC AD 域信息
rc4-hmac : 加密方式

Step 3 : 测试 KDC

klist -k    
[root@localhost ~]# klist -k
Keytab name: FILE:/opt/kerberos.keytab
KVNO Principal
---- --------------------------------------------------------------------------
	3 HTTP/antblack.com@ADSERVER.COM.CN

// 测试 KeyTab 是否连接
// 这个 ANTBLACK.CN 会去查询 kerb5.conf 中的 realm , 并且去其配置的 kdc 进行认证
kinit -k HTTP/antblack.cn@ANTBLACK.CN
klist -k
// 执行后会出现票据


// PS : 此时 AD 中运行 : klist tickets
>>>>>>>>>>>>>>>>
当前登录 ID 是 0:0x12de650
缓存的票证: (2)
#0>     客户端: administrator @ WDHACPOC.COM.CN
        服务器: krbtgt/WDHACPOC.COM.CN @ WDHACPOC.COM.CN
        Kerberos 票证加密类型: AES-256-CTS-HMAC-SHA1-96
        票证标志 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        开始时间: 3/30/2021 16:35:39 (本地)
        结束时间:   3/31/2021 2:35:39 (本地)
        续订时间: 4/6/2021 16:35:39 (本地)
        会话密钥类型: AES-256-CTS-HMAC-SHA1-96
        缓存标志: 0x1 -> PRIMARY
        调用的 KDC: WIN-U76BKIQFGGJ

#1>     客户端: administrator @ WDHACPOC.COM.CN
        服务器: host/win-u76bkiqfggj.wdhacpoc.com.cn @ WDHACPOC.COM.CN
        Kerberos 票证加密类型: AES-256-CTS-HMAC-SHA1-96
        票证标志 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
        开始时间: 3/30/2021 16:35:39 (本地)
        结束时间:   3/31/2021 2:35:39 (本地)
        续订时间: 4/6/2021 16:35:39 (本地)
        会话密钥类型: AES-256-CTS-HMAC-SHA1-96
        缓存标志: 0
        调用的 KDC: WIN-U76BKIQFGGJ

四 . Java 实现方式

// TODO : 行业代码不便于整理 , 后续会做一个简化的 demo 填坑

总结

Kerberos 对外主推的是安全性 , 这个也属于常见但是用的不多的协议 , 结合 AD 域单点部分厂家还是有涉及.