[TOC] ## Kerberos协议原理 Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。 该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的。 ## 认证步骤 (1)、客户端client将登录客户端的用户名、地址、时间戳信息发送给AS认证服务器，用来生成票据许可票据（TGT）+会话密钥（sessionKEY）； (2)、AS服务器收到客户端client的请求后，KDC服务器生成随机会话密钥（session key）得到密钥K，使用客户端登录用户的NTLM hash对会话密钥（session key ）进行加密得到密钥A，KDC服务器用户的NTLM hash对会话密钥（session key ）客户端相关信息（client info）、时间戳（timestamp）等信息加密得到TGT，最后将会话密钥（key1）A和TGT一起发送给客户端； (3)、客户端对收到的请求密钥A，使用客户端账户的NTML hash对A进行解密得到（session key）密钥K，解密后的密钥K对客户端相关信息（client info）、时间戳（timestamp）进行加密得到B，最后将密钥（key2）B与TGT发送给TGS； (4)、TGS 收到客户端的请求后，使用 KDC 的 NTLM Hash 解密 TGT，得到 Session Key和时间戳 (timestamp) 、客户端相关信息（Client Info），使用 TGT 解密出的 Session Key 解密密文B，得到时间戳 (timestamp) 和客户端相关信息（Client Info）。之后对比这俩解密通过后会随机生成一个新的会话密钥（session key），并用生成的新会话密钥对时间戳 (timestamp) 和客户端相关信息（Client Info）进行加密得到密文C，使用TGS服务器的NTML hash对新的会话密钥（session key）和(timestamp) 和客户端相关信息（Client Info）密文C进行加密得到最终票据（Ticket）即ST（Service Ticket），最后一起发送给client； (5)、客户端client最后将服务票据ST（Service Ticket）和密文C直接请求服务; (6)、服务票据ST（Service Ticket）和密文C解密后进行鉴别授权。 ## 详细过程 **1. Client—>KDC-AS** KRB_AS_REQ (Kerberos Authentication Service Request) - 客户端执行散列运算加密一个时间戳,然后发送给身份验证服务(KDC-AS) client先向KDC的AS发送Authenticator1，内容为通过Client密码Hash加密的时间戳、Client ID、网络地址、加密类型等内容。 a. 客户端Client对用户口令执行散列运算转换为NTLM散列。此散列值(即用户密钥)成为客户端和KDC共享的长期密钥(long term key)。 b. KRB_AS_REQ (Kerberos Authentication Service Request) - 客户端执行散列运算加密一个时间戳,然后发送给身份验证服务(KDC-AS)。 **2. KDC-AS—>Client** KRB_AS_REP (Kerberos Authentication Service Response) - 身份验证服务(KDC-AS)会解密时间戳,若解密成功(KDC-AS检查用户的信息(登录限制.组成员身份等)并创建票据授予票据(Ticket-Granting Ticket,TGT), 并向本地LSA (Local Security Authority)请求生成一个特殊的数据PAC,表明了客户端获得某个特定用户的口令(即验证了用户的身份)。 身份验证服务(KDC-AS)向客户端回复两条信息: a. 短期会话密钥SessionKeya-kdc,用于客户端向KDC发起后续的请求 ,该消息经客户端的长期密钥(long term key)加密。(此短期会话密钥仅适用于该客户端和KDC之间) b. 票据授予票据(Ticket Granting Ticket,简称TGT),包含有关用户名.域名.时间和组成员资格等信息。 TGT票据使用KDC的krbtgt密钥进行加密,PAC使用krbtgt密钥进行进行签名,并且系统很少会验证PAC数据(在Windows环境中为krbtgt账户的NT-Hash)。 **3.Client->KDC-TGS** KRB_TGS_REQ (Kerberos Ticket Granting Service Request) - Client使用AS返回的”短期会话密钥”构建访问特定服务的请求,再把AS返回的”票据授予票据(TGT)”连同请求一起发送到票据授予服务TGS) 此过程叫KRB_TGS_REQ Client-A使用AS返回的会话密钥SessionKeya-kdc构建访问特定服务的请求。客户端Client再把请求连同TGT一起发送到票据授予服务TGS。 (TGT是被KDC的krbtgt密钥加密的，所以Client无法解密) 黄金票据 - 此过程3可以伪造TGT(前提是获取krbtgt账号的口令散列值)，宣称自己是域内任何账号，包括域管或者不存在的用户，这是黄金票据的原理。 **4.KDC-TGS—>Client** KRB_TGS_REP (Kerberos Ticket Granting Service Response) - 票据授予服务TGS解密TGT和服务请求,然后如果请求被允许(KDC会打开票据,进行校验和检查。如果DC能够打开票据,并能通过校验和检查,那么会认为TGT为有效票据。此时TGT中的数据会被复制,以创建TGS票据ST),Server密码HASH加密sessionkey-tgs 票据授予服务TGS向客户端Client发送一个服务票据(Service Ticket,简称ST),包括两个部分: a. 远程服务器的部分 - 包含请求用户的组成员资格、时间戳、用于客户端和远程服务器之间通信的会话密钥。使用远程服务器Server-B和KDC共享的长期密钥(long term key)加密这部分消息。 b. 客户端的部分 - 包含用于客户端和远程服务器之间通信的会话密钥SessionKeya-b。(使用步骤2中AS回复的短期会话密钥(SessionKeya-kdc)加密这部分消息生成的会话密钥SessionKeya-b。) **5.Client—>Server** RB_AP_REQ (Kerberos Application Request) - Client把服务票据(Service Ticket)中的服务器部分和请求一起发送到Server-B(用户要访问活动目录中的主机)。 远程服务器将直接接受该服务器票据,并不需要和KDC直接通信,因为该票据是用远程服务器和KDC共享的长期密钥加密过的。 解密成功(目标服务会使用自己的NTLM密码散列打开TGS票据,并提取用户的授权数据和会话密钥SessionKeya-b。)即表明KDC已经允许了此次通信。 白银票据 - 此过程5可以伪造TGS(前提是获取服务账号的口令散列值)，宣称自己是域内任何账号，例如域管，这是白银票据的原理。