Kerberos是更现代化的身份验证协议，它比 NTLM 认证更安全，但域内某些服务仍支持 NTLM 认证。Kerberos 和 NTLM 认证一样，都是通过在 SSPI 接口实现的功能，这使得使用第三方协议（如：HTTP、SMB、LDAP）在访问服务之前，Kerberos 和 NTLM 一样，由身份验证阶段转为会话阶段。

我们之前的文章表明，NTLM 身份验证阶段就是客户端和服务端展开的协商、挑战、验证，会话阶段就是使用 HTTP、SMB、LDAP 访问服务，那么这里的会话阶段与 Kerberos 身份验证后的会话阶段没有什么不同，我们把重点放在 Kerberos身份验证阶段。

Kerberos 身份验证阶段分为如下步骤：

• as-req & as-rep

• tgs-req & tgs-rep

• ap-req & ap-rep

经过上述步骤后进入会话阶段。

as-req & as-rep

• 此步骤用于客户端向 kdc 请求 tgt 认购权证

• as-req ：客户端发送请求

• as-rep ：kdc 返回 tgt 认购权证

 

上图是 as-req 请求内容，和 as-rep 响应内容。我来详细解释其中的细节。

tgt 请求流程

1. 客户端使用某个域用户的身份凭据（用户密码）生成用户 hash。

2. 客户端使用用户 hash 加密时间戳，并和一系列其他信息组成 as-req 发送给 kdc 以访问 kdc 的 krbtgt 服务（此服务主要用来颁发 tgt ）。

3. kdc 从活动目录数据库中取出用户凭据并生成用户 hash，并尝试用这个自己运算出来的用户 hash 解密时间戳

   • 解密成功：用户凭据正确

   • 解密失败：用户凭据错误

1. 解密成功后，利用此用户在活动目录数据库中的信息生成针对此用户的 tgt 认购权证。

as-rep 内容详解

1. 生成 tgt 的同时，kdc 也生成了一个随机化的 Logon Session Key，其存储位置有两个：

   • Logon Session Key 经过用户 hash 加密后存放在 tgt 之外。

   • Logon Session Key 经过 krbtgt 服务账户 hash 加密后放在 tgt 内部。

2. 除了 Logon Session Key 之外，tgt 内部最重要的信息就是 PAC。

   • PAC 是 krbtgt 服务在活动目录查询访问用户后，生成的一系列关于此用户的权限信息（例如：所属组等）

   • 通过 PAC，目标服务能获取用户所属组等身份，再根据配置在本地的 ACL ，不需要再次访问 kdc 就能判断用户权限。因此 PAC 不能被用户解密。

3. PAC 受 serverchecksum 和 privsvrchecksum 两个签名的保护：

   • privsvrchecksum ：使用 krbtgt 服务账户 hash 进行签名

   • serverchecksum ：使用即将要访问的目标服务的服务账号 hash 进行签名（因为这里这里请求了 tgt 所以此时的目标服务的服务账号 hash 就是 krbtgt 服务账户 hash ，可以说这里的 privsvrchecksum 和 serverchecksum 是一样的）

4. Logon Session Key 的作用出现在 tgs-req & tgs-rep。

tgs-req & tgs-rep

• 此步骤用于客户端向 kdc 请求 st 服务票据

• tgs-req ：客户端发送请求

• tgs-rep ：kdc 返回 st 服务票据

 

上图是 as-req 请求内容，和 as-rep 响应内容。我来详细解释其中的细节。

st 请求流程

1. 客户端接受到 as-rep 后，使用用户 hash 解密被加密的 Logon Session Key。

2. 客户端使用 Logon Session Key 加密时间戳，并和 tgt 、以及其他一系列其他信息组成 tgs-req 发送给 kdc 以访问 kdc ，此时请求的服务名已不再是 krbtgt 服务账户，而是目标服务的服务账户。

3. kdc 获取客户端发来的 tgt ，并使用 krbtgt 服务账户的 hash 解密其中的 Logon Session Key ，并尝试用 Logon Session Key 来解密 Logon Session Key 解密时间戳。

   • 解密成功：用户凭据正确

   • 解密失败：用户凭据错误

   • as-rep 中 tgt 外部的 Logon Session Key ：供用户使用，作为 tgs-req 中时间戳的密钥来加密的时间戳向 kdc 发起验证。

   • as-rep 中 tgt 内部的 Logon Session Key ：供 kdc 使用，用来验证 tgs-req 加密的时间戳。

1. 解密成功后，通常情况下，kdc 会直接将接受的 tgt 的大部分信息复制到 st中。

2. 修改 serverchecksum ：从 krbtgt 服务账户 hash 进行签名替换为使用目标服务账户 hash 进行签名。

tgs-rep 详细内容

1. 生成 tgt 的同时，kdc 也生成了一个随机化的 Server Session Key，其存储位置有两个：

   • Server Session Key 经过Logon Session Key加密后存放在 tgt 之外。

   • Server Session Key 经过目标服务 hash 加密后放在 tgt 内部。

2. 除了 Server Session Key 之外，tgt 内部最重要的信息就是 PAC，PAC 通常直接从 tgt 中复制。

3. PAC 受 serverchecksum 和 privsvrchecksum 两个签名的保护：

   • privsvrchecksum ：使用 krbtgt 服务账户 hash 进行签名

   • serverchecksum ：从 krbtgt 服务账户 hash 进行签名替换为使用目标服务账户 hash 进行签名。

4. Server Session Key 的作用出现在 tgs-req & tgs-rep。

ap-req & ap-rep

发送服务票据，服务器进行验证流程如下：

1. 客户端接受到 tgs-rep 后，使用用户 Logon Session Key 解密被加密的 Server Session Key。

2. 客户端使用 Server Session Key 加密时间戳，并和 st、以及其他一系列其他信息组成 ap-req 发送给服务器以访问目标服务。

3. 服务器提前会在本地缓存服务账户 hash，使用服务账户 hash 解密 st 中被加密的 Server Session Key，并使用 Server Session Key 来验证客户端的加密时间戳，如果能解密成功，则客户身份验证成功

4. 身份验证成功进入会话阶段。

5. 服务器提取 st 的 pac 信息，并根据自身缓存的 acl 判断用户所具有的权限。