Kerberos认证基础是怎样的呢
这期内容当中小编将会给大家带来有关Kerberos认证基础是怎样的呢，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
在古希腊神话中Kerberos指的是：一只三头犬守护在地狱之门外,禁止任何人类闯入地狱之中。而现实中的Kerberos是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务,域环境中默认优先使用Kerberos进行认证。
下面请看Kerberos 协议框架：
通过上图可以看到整个认证流程有三个重要的角色,分别为Client、Server和KDC。下面介绍下几个相关的名词：
1、访问服务的 Client。
2、提供服务的 Server。
3、KDC（Key Distribution Center）：密钥分发中心。
在KDC中又分为两个部分：Authentication Service(AS,身份验证服务)和Ticket Granting Service(TGS,票据授权服务)。
4、DC（Domain Controller）：即域控制器；AD（Active Directory）：即活动目录。
DC中有一个特殊用户叫做:krbtgt，它是一个无法登录的账户，是在创建域时系统自动创建的，在整个kerberos认证中会多次用到它的Hash值去做验证。
AD会维护一个Account Database(账户数据库). 它存储了域中所有用户的密码Hash和白名单。只有账户密码都在白名单中的Client才能申请到TGT。
举个简单的栗子：如果把Kerberos中的票据一类比作一张门禁卡，那么Client端就是住客，Server端就是房间，而KDC就是小区的门禁。住客想要进入小区，就需要手里的门禁卡与门禁相对应，只有通过门禁的验证，才能打开门禁进入小区，整个过程就相当于一个缩减版的Kerberos认证。
Kerberos 详细认证流程：
当 Client 想要访问 Server 上的某个服务时，需要先向 AS 证明自己的身份,验证通过后AS会发放的一个TGT,随后Client再次向TGS证明自己的身份,验证通过后TGS会发放一个ST,最后Client向 Server 发起认证请求，这个过程分为三块：
※ Client 与 AS 的交互
※ Client 与 TGS 的交互
※ Client 与 Server 的交互
壹 Client 与 AS 的交互
一、准备：
用户在Client中输入账号密码后,Client会对密码进行哈希加密,我们叫做Master key。
1、请求：Client 先向 KDC 的 AS 发送 Authenticator(认证者),我们叫它Authenticator1,为了确保Authenticator1仅限于自己和KDC知道,Client使用自己的Master Key对其的主体部分进行加密。
其内容为：
1)、经过 ClientMaster Key(用户的NTLM Hash)加密的TimeStamp(一个当前时间的时间戳)。
2)、Client的一些信息(info),比如用户名。
二、响应：
1、AS接收到Authenticator1后,会根据Client提交的用户名在AD中寻找是否在白名单中,然后查询到该用户名的密码,并提取到Client对应的Master key,对TimeStamp进行解密,如果是一个合法的Timestamp,就证明了Client提供的用户名和密码是存在AD中的,并且AS提取到的Timestamp不能超过5分钟,否则AS就会直接拒绝Client的请求。
2、TimeStamp验证通过后,AS会给Client发送一个由Client的Master key加密过的Logon Session Key和一个TGT(client-server-ticket)。TGT的内容：经过KDC中的Master Key(krbtgt NTLM Hash)加密的 Logon Session Key(临时会话密钥) 和 TimeStamp、TGS会话密钥、用户信息、TGT到期时间。
当Client通过AS的验证,并顺利拿到TGT就完成了Kerberos的第一步认证。
这里需要理解Logon Session Key：
1、Logon Session Key是什么：
即临时会话秘钥a,Client向KDC发起对TGT的申请说自己要去访问Server上的摸个服务,KDC在收到该请求后,会生成一个用于该Client和KDC进行安全通信的Session Key（SKDC-Client,也被称为Logon Session Key)。这里KDC不会保存SKDC-Client。
需要注意的是SKDC-Client是一个临时会话秘钥,所以它具有自己的生命周期,同时TGT和Session相互关联,当Logon Session Key过期,TGT也就失效了。
2、到了第二步还有一个Session Key(临时会话秘钥b),是用于Client和Server之间通信的Session Key（SServer-Client）,这里Server也不会保存SServer-Client。
贰 Client 与 TGS 的交互
Client使用TGT从KDC获得基于某个Server的Ticket：
一、请求：
Client通过自己的Master key对第一部分解密获得Logon Session Key之后,携带着TGT对TGT发送请求。Client是解不开TGT的,它作为一个Client通过身份验证的票提交给TGS。
请求的内容：
1、TGT：Client通过与AS交互获得的TGT,TGT 被 KDC 的 Master Key 进行加密。
2、Authenticator2：Client端使用 Logon Session Key对其进行加密,Authenticator2实际上就是关于Client的一些信息和当前时间的一个Timestamp,用以证明当初 TGT 的拥有者是否就是自己。
二、响应--TGS验证通过后发放ST(Service Ticket)票：
TGS收到Client请求,验证其真身份：
TGS 在发给Client真正的Ticket之前,会检查自身是否存在 Client 所请求的服务,如果服务存在,还得确定Client提供的那个TGT是否是AS颁发给它的,于是它得通过 Client 提供的 Authenticator2 来证明。但是 Authentication2 是通过 Client的 Logon Session Key 进行加密的,而TGS并没有保存这个 Logon Session Key 。所以 TGS 先得通过自己的 Master Key(krbtgt的密码hash处理) 对 Client 提供的 TGT 进行解密,从而获得Client Info和 Logon Session Key（SKDC-Client）,再通过这个Logon Session Key解密 Authenticator2，获得Client Info,对两个Client Info进行比较进而验证对方的真身份
响应内容：
认证通过后TGS会生成一个经过Logon Session Key（SKDC-Client）加密的用于Client和Server之间通信的Session Key（SServer-Client）,和经过KDC的Master Key加密的ST(Service Ticket)
1、经过 Logon session key加密的Client和Server之间的Session Key
2、经过Server的Master Key进行加密的ST(Service Ticket)。Ticket大体包含以下一些内容：Session Key（SServer-Client）Domain name\Client。Ticket的到期时间。
Client 收到TGS的响应,使用 Logon session key,解密第一部分后获得 Session Key （注意区分 Logon Session Key 与 Session Key 分别是什么步骤获得的,及其的区别）。有了 Session Key 和 ST(Service Ticket), Client 就可以直接和 Server 进行交互,而无须在通过 KDC 作中间人了。
叁 Client 与 Server 的交互与双向验证：
Server验证Client：Client通过与TGS交互获得访问Server的Session Key,然后为了证明自己就是ST(Service Ticket)的真正所有者,会将Authenticator和时间戳提取出来,并使用Session Key进行加密。最后将这个被加密过的Authenticator3 和ST作为请求数据包发送给Server。此外还包含一个Flag用于表示Client是否需要进行双向验证。
Server接收到Request之后,首先通过自己的Master Key(krbtgt的NTLM Hash处理)解密ST,从而获得Session Key。然后通过解密出来的Session Key再去解密Authenticator3 ,进而验证对方的身份。如果验证成功,就让 Client 访问对应的资源,否则就会直接拒绝对方的请求。
到目前为止，服务端已经完成了对客户端的验证，但是，整个认证过程还没有结束。接下来就是Client对Server进行验证以确保Client所访问的不是一个钓鱼服务。
Server需要将Authenticator3中解密出来的Timestamp再次用Session Key进行加密,并发送给Client。Client再用缓存Session Key进行解密,如果Timestamp和之前的内容完全一样,则可以证明此时的Server是它想访问的Server。
到这里就完成了整个Kerberos认证
上述就是小编为大家分享的Kerberos认证基础是怎样的呢了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。
