盘点认证协议 : 普及篇之Kerberos-灵析社区

带鱼

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

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

一 . 前言

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

Kerberos 优点
  1. 密码从不通过网络发送，因为只有密钥以加密形式发送;
  2. 身份验证是相互的，因此客户端和服务器在相同的步骤进行身份验证，并且它们都确信自己正在与正确的对应方进行通信;
  3. 身份验证可重用且不会过期;
  4. Kerberos 完全基于开放的互联网标准
  5. Kerberos 被许多行业采用，因此其安全协议或底层模块中的任何新缺陷都会很快得到纠正
Kerberos 缺点
  1. 如果未经授权的用户可以访问密钥分发中心，则整个身份验证系统将受到威胁
  2. Kerberos 只能被支持 Kerberos 的应用程序采用。为了让某些应用程序能够识别 Kerberos，重写这些应用程序的代码可能是个问题
Kerberos 关键词
  • 安全认证协议
  • tickets 验证
  • 密码保护（本地 不保存，链路不传输 ）
  • 对称加密
  • Server - client 可以相互验证
  • 有可信第三方

二 . Kerberos 基础要点

2.1 Kerberos 成员

认证体系成员
  • Client 成员
  • 应用程序服务器 (AP , ApplicationServer , Resource)
  • 密钥分配中心 (KDC) : AS + TGS + 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 访问详情 :

  1. KRB_AS_REQ: 从身份验证服务(AS)请求TGT
  2. KRB_AS_REP : 从身份验证服务接收TGT
  3. KRB_TGS_REQ : 发送当前的 TGT 并请求TGS
  4. KRB_TGS_REP : 从 KDC 接收 TGS
  5. KRB_TGS_REP : 将 TGS 提交给应用服务器进行授权
  6. KRB_AP_REP : 授予客户端访问服务的权限

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 的使用前提

  1. 域控制器之间的复制 : 如果部署了多个域控制器(即多个 KDC) ，则必须启用复制并及时回收。 如果复制失败或回收被延迟，当用户更改密码时，身份验证可能
  2. 客户端和 kdc 必须将他们的时钟同步 在 Kerberos 中，时间的准确度量对于防止重放攻击非常重要。 Kerberos 支持可配置的时间偏移(默认5分钟) ，超过这个时间，身份验证将失败
  3. 客户端和 kdc 必须能够在网络上进行通信 Kerberos 流量发生在 TCP 和 UDP 端口88上，所有客户端都必须能够访问至少一个 KDC (网域控制器)
  4. 客户端、用户和服务必须具有唯一的名称 计算机、用户或服务主体名称的重复名称可能导致身份验证失败
  5. 客户端和 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 域单点部分厂家还是有涉及.


阅读量：2013

点赞量：0

收藏量:0