简写 | 含义 |
---|---|
DC | Domain Controller 域控 |
KDC | Key Distribution Center 密钥分发中心 |
AD | Account Database 账户数据库 |
AS | Authentication Service 身份验证服务 |
TGS | Ticket Granting Service 票据授与服务 |
TGT | Ticket Granting Ticket 票据中心授予的票据 |
1、client向kerberos服务请求,希望获取访问server的权限。kerberos得到了这个消息,首先得判断client是否是可信赖的,可以理解为黑白名单。这就是AS服务完成的工作,通过在AD中存储黑名单和白名单来区分client。成功后,AS返回TGT给client。
2、client得到了TGT后,继续向kerberos请求,希望获取访问、server的权限。kerberos又得到了这个消息、消急中的TGT,判断出了client拥有了这个权限,给了client访问server的权限ticket。
3、client得到ticket后,可以成功访问servcer。这个ticket只是针对这个server,其他server需要向TGS申请
(1)首先客户端(client)向服务端,即KDC发送用户信息,包括计算机名、地址、TGS等域控信息。发送过,去之后,KDC验证收到的计算机名,地址,用户名在不在AD里面,如果都在,会向客户端发发送2和3(如上图)。
(2)身份验证服务(AS):KDC根据客户端发来的username去AD里面找到对应的hash来加密SeesionKey,这个SeesionKey是随机生成的。
(3)TGT(Ticket Granting Ticket 票据中心授予的票据):KDC通过KDC里面某个特定的用户对应的NTMLhash加密SeesionKey和客户端信息,这里的SeesionKey和上一步是一样的,加密完成之后一起发送给客户端。
服务端发送给KDC的具体信息:
KDC返回给客户端的具体信息:
(1)客户端继续向服务端发送信息,TGT(这个是第一步中服务端返回给客户端的TGT)、用客户端Hash解密出SeesionKey,然后用SeesionKey加密信息:(client信息、时间戳客户端信息)、服务端信息、client info,把这些信息发送给服务端。
(2)服务端收到信息后,TGS没有SeesionKey,但收到的TGT有SeesionKey,TGS可以用KDC的Hash解密TGT,然后利用得到的TGT中的SeesionKey去解密客户端发来的SessionKey包装的信息,解密之后校验时间戳,如果与当前时间相差太久,认证失败,可能是攻击者伪造的,成功之后,比较这个SessionKey中的客户端信息和第一步中返回给客户端TGT中的客户端信息是否相同,认证通过后将返回一个数据包给客户端。包的内容为:用刚刚的SessionKey加密server SessionKey(KDC又随机生成的一个随机字符,用于客户端和服务端通信的SessionKey,没有则无法认证),票据的内容是上一步中的服务器信息,KDC通过服务器信息中的计算机名去AD提取对应的Hash(Server SesionKey)值,来加密票据。
(1)客户端无法解密Ticket,但是客户端有Server SessionKey,用它加密客户端信息和时间戳发送给服务端。
(2)服务端首先用自己的Hash解密Ticket,Ticket中包含Server SessionKey,服务端利用Server SessionKey去解密收到的客户端信息和时间戳,拿去和票据中的信息比较,判断票据中的到期时间。
认证的本质就是交换秘钥,采用的对称加密算法,验证时间戳和身份。