Kerberos协议

前言

此文章只是自己对该知识点对网上资源的总结。

Kerberos 协议

介绍

kerberos 是一种由MIT(麻省理工大学)提出的一种网络身份验证协议，它旨在通过使用加密技术为客户端/服务端应用程序提供强大的认证服务。
Kerberos是西方神话中守卫地狱之门的三头犬的名字。只所以使用这个名字是因为Kerberos需要三方的共同参与，才能完成一次事务处理。

主要的三个角色 (三只狗)

1. Client
2. Server
3. KDC(Key Distribution Center) == DC

KDC 密钥分发中心

Authentication Server. ==AS. 身份验证服务

Ticket Granting Server . ==TGS 票据授予服务

该认证过程的实现不依赖于主机操作系统的认证,无需基于主机地址的信任,不要求网络上所有主机的物理安全,并假定网络上传送的数据包可以被任意地读取.修改和插入数据。
在以上情况下, Kerberos 作为一种可信任的第三方认证服务,是通过传统的密码技术(如:共享密钥)执行认证服务的。

Kerberos会使用的端口

​ TCP和UDP的88端口：身份验证和票证授予

​ TCP和UDP的464端口：经典Kerberos Kpaswd（密码重设）协议

krbtgt账户

每个域控制器DC都有一个kebtgt的用户账户，此账户是KDC的服务账户用来创建票据授予服务(TGS)加密的密钥

粗略认证

1. client向kerberos服务请求,希望获取访问server的权限。kerberos得到消息后，首先会判断client是否为可信赖的。(黑白名单)成功后，AS返回TGT给client 。
2. Client 得到TGT后，继续向kerberos 请求，希望获取访问server的权限。kerberos又得到了这个消息，这时候通过client消息中TGT，判断出client拥有了这个权限，返回给client 访问server的权限 ticket
3. client得到最后的ticket后，就可以访问server了，不过这个ticket只针对这一个server。
   

详细过程

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(前提是获取服务账号的口令散列值)，宣称自己是域内任何账号，例如域管，这是白银票据的原理。

LSA(Local Security Authority) 本地安全机构

LSA 管理本地的安全策略、管理审计策略和设置、为用户生成包含SID和组权限关系的令牌。LSA的验证过程:LSA通过访问本地SAM(Security Accounts Manager)数据库，可以完成本地用户的验证。

情景

1. 当用户按下“Ctrl + Alt + Del”之后，Winlogon被唤醒，同时跳出需要输入用户名和密码的登入身份凭据窗口（由Gina.ll来定义）

2. 用户使用domain\user或UPN名之后，由Winlogon读取用户的身份凭据，并把它交给LSA（本地安全机构)

LSA在收到Winlogon的交给他的身份凭证后，并不是马上就交给Kerberos协议，还有可能是NTLM协议，因为我们知道用户登入有两种，一种是本地登入，一种是域登入。如果是本地登入的话，会使用本地数据库进行验证，如果是域登入的话，就会使用域控制器来进行身份验证。那LSA如何判断是本地登入还是域登入？

LSA的处理流程
1.LSA首先会把身份凭据交给SSPI,由该接口负责与Kerberos和NTLM服务沟通。
2. SSPI不能确定用户是本地登录还是域账户进行域登录。所以他会先把身份认证请求传递到Kerberos SSP。
3. Kerberos SSP会验证用户的登入目标是本地计算机还是域。如果是登录域,Kerberos SSP将继续处理。如果是本地计算机,即用户不是登录域,Kerberos SSP返回一个错误消息到SSPI,交回给GINA处理,使服务器登录不可用。
4. SSPI现在发送请求到下一个安全提供程序——NTLM。NTLM SSP会将请求交给Netlogon服务针对LSAM (Local Security Account Manager,本地安全账户管理器)数据库进行身份认证。使用NTLM SSP的身份认证过程与Windows NT系统的身份认证方法是相同的。

PAC(Privilege Access Certificate) 特权访问证书

KDC在向Kerberos客户端颁发TGT时,会向本地LSA请求生成一个特殊的数据结构，名为特权访问证书。这个PAC包含为kerberos客户端构建一个本地访问令牌所需要的用户信息，它同时使用域控制器服务器的私钥和KDC服务器的私钥来进行数字签署，以防假的KDC伪造PAC

PAC数据结构
1. 用户的登入时间以及用户会话额到期时间
2. 用户上一次设置密码的时间,以及允许他再次更改密码的时间
3. 用户的经典登入名,domain\user
4. 用户的显示名称
5. 指派给用户账户的经典NT登入脚本的名称(如果有的话)
6. 用户漫游配置文件的UNC路径
7. 客户端主目录的UNC路径
8. 用户的并发登入数
9. 在颁发PAC的KDC处,自从上一次成功登入以来,所允许的不成功登入尝试次
10. 用户的RID
11. 用户的"主要组"的RID,只限在POSIX使用
12. 在域中,将用户作为一个成员的组的数量,以及每个组的RID
13. 适用于用户的已知SID
14. 域的SID
15. 资源域的SID
除此之外,PAC中还嵌入了另一个名为用户账户控制的数据结构