Kerberos

最新推荐文章于 2023-10-31 23:44:33 发布

原创最新推荐文章于 2023-10-31 23:44:33 发布 · 1.1k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#service #解密 #加密 #session #应用服务器 #sql server

SQL Server 同时被 2 个专栏收录

7 篇文章

订阅专栏

Windows

2 篇文章

订阅专栏

简介

Kerberos是一种验证机制，最先由MIT提出和实现，之后被运用到windows的认证机制中。

Windows是从windows 2000时才开始将Kerberos作为默认首选验证方式，先前使用的是一种叫做NTLM(challenge-response)的验证机制。

Kerberos采用对称密钥体制对信息进行加密。其基本思想是：能正确对信息进行解密的用户就是合法用户。用户在对应用服务器进行访问之前，必须先从第三方（Kerberos服务器）获取该应用服务器的访问许可证（ticket）。

Kerberos这个词本身源自希腊神话，意指地狱看门犬，守卫在冥界的入口处。它有三个头，在很多游戏中都有出现。这个形象本身也与这种验证机制有些相像，在客户端访问服务端的服务之前做认证，并且这个机制一般至少涉及到三个节点之间的信息传输。

节点功能

Kerberos验证机制是使用在域环境中的。简单来说，它的功能就是要让正确的域用户访问到正确的域内服务。因此，首先需要域账户和域内服务均在域的管理员机器DC(DomainController，可以将其视为验证过程中的一个中枢)中进行过登记和注册，这样，DC便持有域账户和域内服务的一些关键信息，用于之后用户和service的身份认证。

1. 客户端C(Client)

a) 服务的请求者，提供用户账号和所请求的服务信息，唯一持有过用户密码的明文；

b) 使用正确的key对session消息进行加解密；

c) 完成Ticket的传递；

d) 协助DC完成认证并最终与Service建立起session；

2. 域管理员DC(DomainController)

a) AS(AuthenticationServer)

i. DC中的一个服务角色，存放有Kerberos数据库的一个只读副本，其中包括账号对应的密码hash值(K_C)，TGS的密钥(K_tgs)，主要负责对域账号的认证；

ii. 对Client进行域账号认证，如果正确，则为Client提供继续访问的TGT(Ticket-GrantingTicket)

b) TGS(Ticket-GrantingService)

i. DC中的另一个服务角色，存放有Kerberos数据库的一个只读副本，包含ServicePrincipal Name(SPN)和Service密钥(K_S)，主要负责对Service的验证，确保Client能访问到正确的Service；

ii. 根据Client发送来的SPN(ServicePrincipal Name)，验证其有效性，如果正确，

则为Client生成一个支持它继续访问Service的请求票据(Service-GrantingTicket?)。

3. 服务端S(Service)

a) 响应客户端服务请求的最终站，提供某种服务如SQL Server,Exchange等。

b) 必须在DC上注册过SPN才能委托DC的Kerberos认证机制为其进行账号认证。

认证过程

1. C==>AS

a) 客户端向DC的AS发起请求KER_AS_REQ

KER_AS_REQ主要包括 {ID_c, TS₁, ID_tgs }

IC_C客户端标识

TS 时间戳，用来控制会话时间，请求和响应间隔超过一定时间则会作废。

2. AS==>C

a) 对Client进行域账号认证：
如果该账号存在，则得到该账号对应的密码hash值(K_C)，并对之后回传给Client的 KRB_AS_RES进行加密，客户端能正确解密则说明用户正确并通过认证。

b) 为之后Client和TGS的会话创建一个随机的session_key(K_c/tgs)：
这个K_c/tgs会通过一个双重加密的机制先后让正确的Client和TGS获得。

c) 为Client提供TGT(Ticket-GrantingTicket)：
TGT主要包括 K_tgs{ K_c/tgs , ID_c , ID_tgs , TS_{2 ,}Lifetime}
它是一个用于Client之后去访问TGS(Ticket-GrantingService)的加密票据，只有对应的TGS可以解密（通过TGS自己的密钥K_tgs）。因此Client不能解密，只能转发。

d) 用第一步中得到的密码hash值(K_C)加密KRB_AS_RES，传回给Client
KRB_AS_RES主要包括：K_C{K_c/tgs , TS₂ ,Lifetime₂ , TGT}

3. C==>TGS

a) 客户端将TGT和请求服务的ID_V(SPN)以及一些用于完成认证的信息发给TGS

b) KRB_TGS_REQ主要包括 {ID_V, TGT , Authenticator_C}
Authenticator_C主要包括 K_C/TGS{ID_C, AD_C , TS₃}

4. TGS==>C

a) 接收和解密TGT（用自己的K_tgs），由此完成之前AS对TGS的认证

b) 获得K_C/TGS，并用它解密Authenticator_C

c) 比较TGT和Authenticator_C中的ID_C和AD_C确认Client已被AS认证；

d) 通过ID_V验证其有效性，若有，得到它的密钥K_S；

e) 为Client提供SGT(Service-GrantingTicket)?：
SGT主要包括K_s{ K_c/s , ID_c, ID_s , TS_{4 ,}Lifetime}
它是一个用于Client之后去访问Service的加密票据，只有对应的Service可以解密（通过TGS自己的密钥K_s）。因此Client不能解密，只能转发。

f) 为之后Client和Service的会话创建一个随机的session_key(K_c/s)：
这个K_c/s会通过一个双重加密的机制先后让正确的Client和Service获得。

g) 用之前得到的Service密钥(K_S)加密KRB_AP_RES，传回给Client
KRB_TGS_RES主要包括：K_c/tgs{ K_c/s , ID_V ,TS₄ , Lifetime₄ , SGT}