手机版 欢迎访问it开发者社区(www.mfbz.cn)网站

当前位置: > 开发

盘点认证协议 : 普及篇之Kerberos

时间:2021/8/3 0:27:21|来源:|点击: 次

首先分享之前的所有文章 , 欢迎点赞收藏转发三连下次一定 >>>> 😜😜😜

文章合集 : 🎁 https://juejin.cn/post/6941642435189538824
Github : 👉 https://github.com/black-ant
CASE 备份 : 👉 https://gitee.com/antblack/case

  • 纯约束型协议 : 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
    • 发票的可信第三方。在活动目录中,每个网域控制器都充当一个 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 访问详情 :

kdc001.jpg

  1. KRB_AS_REQ: 从身份验证服务(AS)请求TGT
    • 客户机的请求包括用户的用户主体名(UPN)和时间戳。它使用用户的密码散列进行加密
  2. KRB_AS_REP : 从身份验证服务接收TGT
    • KDC 使用 UPN 在其数据库中查找客户机,并使用用户的密码 hashto 尝试解密消息
    • 如果 KDC 成功地解密 TGT 请求,并且时间戳位于 KDC 配置的时间偏差内,则身份验证成功
    • 身份认证成功后 , KDC将TGT 和 TGS会话密钥被发送回客户端。TGS 会话密钥用于加密后续请求
  3. KRB_TGS_REQ : 发送当前的 TGT 并请求TGS
    • 客户机显示它的 TGT 以及一个请求,包括它想要访问的服务的服务主体名称(Service Principal Name,SPN)
    • TGS 请求使用TGS会话密钥进行加密
  4. KRB_TGS_REP : 从 KDC 接收 TGS
    • KDC 验证 TGT,如果成功,则生成 TGS。TGS 包含有关请求者的信息(如请求者的 SID 和组成员身份) ,并使用服务的密码散列进行加密
    • TGS 和服务会话密钥使用 TGS 会话密钥加密,然后发送回客户机
  5. KRB_TGS_REP : 将 TGS 提交给应用服务器进行授权
    • 客户机将从 KDC 接收的 TGS 连同验证者消息一起发送到应用服务器,验证者消息使用服务会话密钥进行加密 (App 此时会拿着 TGS 去 KDC 认证)
  6. 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 个人部分)

image.png

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

image.png

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 用户
kdc002.jpg

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

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
    // -加密方式

kdc004.jpg

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

kdc005.jpg

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

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 域单点部分厂家还是有涉及.

Copyright © 2002-2019 某某自媒体运营 版权所有