🛡️
WindowsDomainAbout
  • README
  • Kerberos
    • Kerberos认证流程
    • Kerberos扩展及应用
    • Kerberos安全
  • NTLM
    • NTLM认证流程
  • Windows访问控制
    • Windows访问控制
Powered by GitBook
On this page
  • 一、Kerberos简介
  • 二、标准认证流程
  • 1. KRB_AS_REQ
  • 2. KRB_AS_REP
  • 3. KRB_TGS_REQ
  • 4. KRB_TGS_REP
  • 5. KRB_AP_REQ
  • 6. KRB_AP_REP
  • 三、扩展后的认证流程
  • 1. Request
  • 2. S4U2self
  • 3. Service ticket, as if from user
  • 4. Response
  • 5. Request
  • 6. S4U2proxy for Service 2
  • 7. Ticket for Service 2
  • 8. Request As User
  • 9. Response
  • 10.Response
  1. Kerberos

Kerberos认证流程

PreviousKerberosNextKerberos扩展及应用

Last updated 3 years ago

一、Kerberos简介

Kerberos协议由麻省理工学院开发,如今主要被用于Windows网络认证,Windows 2000和之后的操作系统使用Kerberos协议为其默认认证方法。加入Windows域则代表启动Kerberos作为客户端到服务端认证的默认协议,如果双方其一或全都未加入Windows域,则使用NTLM进行身份验证。

二、标准认证流程

Kerberos协议认证过程中主要存在三种角色:

  • Client,客户端,访问服务

  • Server,服务端,提供服务

  • KDC(Key Distribution Center),密钥分发中心

Kerberos协议的认证流程如下图所示:

1. KRB_AS_REQ

Client向KDC的AS(Authentication Service)服务发送KRB_AS_REQ请求,目的是获得TGT(Ticket Granting Ticket),发送的内容包括使用Client用户哈希加密的时间戳,这也就是用户凭证。

这一步也叫做预认证,证明Client有域内的用户和对应的哈希,可以进行下一阶段的请求。

抓包来看,KRB_AS_REQ包含的字段如下:

  • pvno,Kerberos协议版本号,现在常用的是Kerberos 5

  • msg-type,消息类型,10即0x0a,代表krb-as-req

  • padata,认证相关信息

  • req-body,里面包含kdc-options、cname、sname、till、nonce、etype等

padata即PA_DATA,其中在KRB_AS_REQ阶段时用到的主要是:

  1. ENC_TIMESTAMP,用户哈希加密的时间戳

  2. PA_PAC_REQUEST,启动PAC支持的扩展

在req-body里,主要有:

  1. kdc-options,一些flag字段

  2. cname,发起请求的用户名

  3. sname,请求的服务名,在KRB_AS_REQ中为krbtgt

  4. realm,域名

  5. till,到期时间

  6. nonce,随机生成的一个数

  7. etype,加密类型

2. KRB_AS_REP

KDC在收到KRB_AS_REQ之后,使用发起请求的用户的哈希解密凭证得到时间戳,如果解密成功并且时间在一定范围内,则通过预认证。

预认证通过后,KDC会返回TGT票据,此票据是使用KDC的krbtgt用户的hash加密的,理论上无法被伪造和解密。

KRB_AS_REP的主要字段有:

  • pvno, 版本

  • msg-type,消息类型

  • crealm,域名

  • cname,请求的用户名

  • ticket,加密的票据

  • enc-part,里面有下阶段的认证密钥

可以看到,在ticket字段里,主要包含了域名、服务名、使用krbtgt用户哈希加密的密文等。

而enc-part里也是密文,但这里的密文是使用请求用户的哈希加密的,所以是可以解密的,里面是下一阶段的认证密钥。

3. KRB_TGS_REQ

通过预认证之后,Client向KDC的TGS(Ticket Granting Service)服务发起请求,请求中包含了之前申请的TGT。

主要的字段和KRB_AS_REQ相同,但内容有区别。

padata字段里的ap-req字段里的ticket就是上面申请的TGT,而authenticator是在KRB_AS_REP中得到的下一阶段认证密钥。

req-body里主要有这些字段:

  • kdc-options,一些特殊选项,比如是否可转发等

  • cname,请求的用户名

  • realm,域名

  • sname,需要申请访问的服务名,如cifs等,如果服务是krbtgt,那得到的ST(服务票据)是可以当做TGT来使用的

  • till,到期时间

  • nonce,随机数

4. KRB_TGS_REP

KDC验证TGT票据和对应服务后,会返回ST票据给Client,这张票据对应着相关服务的访问权限,也就是俗称的白银票据。此票据是使用所请求的服务账户hash加密的,理论上也不可伪造和解密。

这些字段就不再解释,和之前步骤的大致相同,这里同样有enc-part,它是使用前面KRB_AS_REP阶段得到的key字段加密的,解密后同样得到一个key,作为下一阶段的认证密钥。

5. KRB_AP_REQ

Client请求访问对应的服务,提供ST和KRB_TGS_REP阶段得到的认证密钥加密的字段,以获取访问权限。通过设置ap-options的MUTUAL-REQUIRED可以进行双向认证。

6. KRB_AP_REP

除非Client要求进行双向认证,否则服务端一般不回复KRB_AP_REP.

三、扩展后的认证流程

Kerberos协议支持S4U扩展,通过此扩展可以实现委派的功能。

这时流程中存在四个角色:

  • Client,客户端

  • KDC

  • Service1,代理用户请求的服务

  • Service2,要被访问的服务

S4U扩展有两个子协议:S4U2self和S4U2proxy,前者让Service1代表用户获得对Service1自身的票据,也就是获得了Client对Service1的票据;后者则允许Service1代表用户去请求Service2的服务权限。

这里要说明的是,委派功能并不完全等同于S4U扩展,还能使用forwarded TGT的方法实现,流程如下图:

从上面可以看出,这种方式要求Client要先通过Kerberos的方式进行认证,而S4U2self可以让用户使用其他的验证方式来获得对Service1的访问权限,这样就简化了整体流程,也扩展了适用场景。

使用S4U扩展后,委派的流程如下:

1. Request

Client可以使用Kerberos以外的验证方式,来获得对Service1的访问权限,这里Service1并不需要得到Client的相关凭据。

2. S4U2self

Service1已经从KDC处得到了TGT,那么它会代表Client去请求KDC,以获得自身可转发的ST.

可以看到padata里多了pA-FOR-USER,里面的KerberosString字段表明Service1是代表哪个用户进行请求的。

req-body里能看到cname和sname都是Service1,因为Service1代替了Client向KDC发起请求,请求的目标服务也是Service1.

要想获得可转发的ST,需要满足:

  • 使用的TGT是可转发的

  • Service1配置了约束委派

  • 请求时设置了可转发标志

  • Client不是敏感账户

3. Service ticket, as if from user

KDC返回对Service1的可转发ST给Service1

4. Response

这一步实际上没什么作用,因为单靠S4U2self协议并不能请求到其他服务,这需要靠S4U2proxy完成。

5. Request

Client向Service1发起请求,需要Service1以Client的身份去访问Service2,这里就要求Service1通过前几个步骤来获得对自身的可转发ST.

6. S4U2proxy for Service 2

Service1代表Client向KDC请求获得Service2的ST,这个ST也应是可转发的,所以kdc-options应设置forwardable和cname-in-addl-tkt,后者是为了标志S4U2proxy功能。

与普通的KRB_TGS_REQ一样,使用的TGT放在padata中。这里的cname是Client,sname为Service2.

这次还多了一个Service1的ST,放在了req-body的additional-tickets中。

7. Ticket for Service 2

如果上一步的请求中存在特权属性证书(PAC),那么KDC会验证PAC,在PAC有效或不存在PAC的情况下,返回Service2的ST给Service1。此ST中cname和crealm字段存储的是Client的信息,不是Service1的信息。

8. Request As User

Service1向Service2发起请求,后者会将其看作是Client,并且认为Client已经通过了KDC验证。

9. Response

Service2响应Service1

10.Response

Service1响应用户