【每日一记4】+第10天+存储基础知识(9)Kerberos
  

蓝海 829

{{ttag.title}}
     Kerberos 是一种依赖于验证技术共享密钥的协议,其基本概念很简单,如果一个秘密只有两个人知道,任何一个人都可以通过他们之间共享的秘密来确定对方的身份。用技术的语言来讲,就是对称加密,互相确认。

     说到这里,可能有人会问,NTLM也是CIFS的安全认证啊,为什么Kerberos会用的更广泛呢?他的优点又在哪呢?相信大家了解了Kerberos的工作原理之后就会清楚了。

Kerberos认证和我们看电影的过程差不多,主要分三个步骤:
第一步咨询:用户登陆domain
第二步买票:用户获得service票据
第三步来访:使用服务票据访问某服务

用户登陆domain (Logging into the Domain)

1. Authentication Server request

    AS_REQ,即上图步骤(1)

    一个用户在一台Client机上第一次登陆时,会有弾框提示输入用户名和密码。这时用户密码信息会通过Hash算法产生一个用户的Long Term Key(LTK),再和用户登陆Client端时的时间戳一起进行加密,然后这个用户验证请求被发送给Kerberos Data Center(KDC),并要求KDC返回一个相应的Ticket Granting
Ticket(TGT)。


2. Authentication Server response

     AS_REP,即上图步骤(2)

    KDC在数据库中先找到该用户的密码,并用同样的Hash算法生成一个LTK。 然后KDC通过LTK从预认证信息Preauth包KRB_AR_REQ中解密出用户信息和时间戳, 如果用户信息无误,并且时间戳和目前信息相差在5分钟之内,KDC会认为该用户验证通过。KDC将生成一个TGT,并准备把TGT返回给Client。

     在生成TGT的同时,KDC生成一组随机数作为Logon Session Key,并让他和客户端传来的LTK再次进行加密,产生一个名叫enc-part的信息放在该KRB_AS_REP包中,KDC还会用生成的TGT与能被所有KDC识别的LTK进行加密,再次产生一个enc-part放在TGT的头中,这样就得到了一个只有KDC能解开的TGT,最后把这个TGT加入KRB_AS_REP包中并发送至Client端。

3. Ticket cache

    Client端收到KRB_AS_REP后会用自己的LTK来解密KRB_AS_REP中的enc-part,这里我们默认会得到KDC选用的随机数Logon Session Key。这时候Client端将会把得到的Logon Session Key和KRB_AS_REP中带有原始时间戳的TGT一起存入票据内存中准备给下面过程使用。

PS:这时候KDC为了减少自身负担,并没有吧Logon Session Key保存在自己这边,所有只有这个用户在Client端的票据内存里面才有该记录了。


用户获得service票据(Getting a Service Ticket)

1. Ticket Granting Server request

     TGS_REQ,即上图步骤(3)

Client端接下来会拿着TGT去告诉KDC我要访问某服务,并让KDC给他访问该服务的票据(service ticket),以后他就可以拿着这张票据直接访问该服务了. Client端用现在的时间戳和之前存在票据内存中的Logon Session Key进行加密生成Authenticator,然后再把带有原始时间戳的TGT一起打包发送给KDC等待验证。

2.  Ticket Granting Server response

     TGS_REP,即上图步骤(4)

KDC收到KRB_TGS_REQ后会用自己的LTK解密出TGT,然后看看TGT中的原始时间戳,如果来确定TGT现在还是处于有效的状态,KDC就会从TGT中读取Logon Session Key,并用这个Logon Session Key解密Authenticator来获得第二次记录的时间戳,如果该时间差在5分钟之内,KDC认为验证成功,并将生成一个service ticket。

PS:Kerberos为了防止重演攻击,特别加入了对时间戳的验证。

接下来KDC又会生成一组叫做Service Session Key的随机数,并把这组随机数和service ticket中记录的Logon Session Key进行加密,产生一个名叫enc-part的信息放在该KRB_TGS_REP包中,KDC还会用生成的service ticket与能被所有KDC识别的LTK进行加密,再次产生一个enc-part放在TGS的头中,这样就得到了一个只有KDC能解开的service ticket,最后把这个service ticket加入KRB_AS_REP包中并发送至Client端。

3. Ticket Cache

     Client收到KRB_TGS_REP后,通过票据内存中的Logon Session Key解密enc-part,然后得到KDC生成的Service Session Key。最后把Service Session Key和service ticket一起作为访问目标服务器的Credential存入票据内存中。

使用服务票据访问某服务(Using the Service Ticket)

1. Application Server request

    AP_REQ,即上图步骤(5)

     经过上面的两次验证,Client现在就能拿着服务票据去访问该服务了。Client记录下时间戳,并读取内存中的Service Session Key与他进行加密生成新的Authenticator,同时用户还要标记好自己是否需要双向认证 (Mutual
Authentication),最后再加上之前的服务票据一起发送给该服务的server(在NAS系统中相对应的服务就是CIFS,server就是我们加入domain的CIFS server)。

2. Application Server response

     AP_REP,即上图步骤(6)

NAS收到这个加密的KBR_AP_REQ之后,用自己的LTK进行解密。接着server从service ticket里面读出service session Key来解密Authenticator中的时间戳。如果时间差小于5分钟,NAS就允许该用户对他进行访问了,并且为这个Client上的这个用户创建一个security token。

Kerberos优点:

虽然上面Kerberos的工作原理稍微有点复杂,不过我们还是能从中看出Kerberos的高效性,相互身份验证以及互操作性的优点。

高效性:客户端不用每次访问NAS时都去DC验证,而通过查询client credentials就可以验证了。

相互身份验证:client和server可以互相验证。

互操作性:微软的Kerberos V5实现是基于IETF的推荐标准规范。这样,Windows Server 2003的Kerberos V5实现就为其他使用Kerberos V5协议的网络的互操作打下了基。

打赏鼓励作者,期待更多好文!

打赏
2人已打赏

zjwshenxian 发表于 2020-3-2 07:52
  
感谢分享
发表新帖
热门标签
全部标签>
每日一问
技术盲盒
技术笔记
干货满满
技术咨询
功能体验
产品连连看
新版本体验
GIF动图学习
自助服务平台操作指引
标准化排查
运维工具
2023技术争霸赛专题
通用技术
秒懂零信任
技术晨报
信服课堂视频
用户认证
安装部署配置
安全攻防
SDP百科
设备维护
深信服技术支持平台
社区帮助指南
答题自测
每日一记
玩转零信任
畅聊IT
专家问答
技术圆桌
在线直播
MVP
网络基础知识
升级
上网策略
测试报告
日志审计
问题分析处理
流量管理
云计算知识
原创分享
解决方案
sangfor周刊
VPN 对接
项目案例
SANGFOR资讯
专家分享
技术顾问
信服故事
功能咨询
终端接入
授权
资源访问
地址转换
虚拟机
存储
迁移
加速技术
排障笔记本
产品预警公告
信服圈儿
S豆商城资讯
技术争霸赛
「智能机器人」
追光者计划
答题榜单公布
纪元平台
卧龙计划
华北区拉练
天逸直播
以战代练
山东区技术晨报
文档捉虫活动
齐鲁TV
华北区交付直播
每周精选

本版版主

461
244
13

发帖

粉丝

关注

本版达人

feeling

本周分享达人

新手29676...

本周提问达人