Share via


PaData在Kerberos认证协议中的作用

         看了小屈同学的前两篇博文,受益颇丰,很有启发。在上一节中,我们提到了“PA Data”这个数据结构,它到底是用来干什么的呢?带着这个疑问,在这一节里,我们了解一下在kerberos验证的扩展应用中PA Data是如何起作用的,从而完善我们对于kerberos验证的知识体系的理解。

         我们知道除了输入用户名密码这种常规方式登录系统以外,还有另外一个方式,那就是smart card logon。当我们使用smart card登录系统的时候,只需将卡插入读卡器,输入PIN码(不是域内用户的密码)就能完成登录了。在这个过程中用户的AS_request中Pre-authentication Data所存放的并不是通过用户密码加密的时间戳(标准的kerberos验证中的PA Data),而是smart card中提取出来的用户的证书。

          在第一篇博文中我们知道要完成kerberos验证,需要完成“三部曲”:AS 验证(获得TGT);TGT验证(获得service ticket);AP验证(完成应用服务service ticket的验证)。PA DATA的使用就发生第一步即AS验证部分。要使用证书进行AS验证,我们应用的是扩展的kerberos验证方式:PKINIT(Public Key Cryptography for Initial Authentication in Kerberos)。从本质上说,在PKINIT kerberos验证中,DC通过匹配用户证书中的UPN和AD数据库中的用户UPN来实现身份的识别和验证。(思考一下,在第一节中,DC是如何验证用户身份的呢?)由于smart card证书只会发布给“授权”的“正确”的用户(因为我们信赖Root CA,并且smart card证书的申请流程是安全的),并且证书受到PIN码保护(即使证书落入了非授信人员手中也无法获取到里面的内容)。所以,我们认为用户在Pre-authentication Data中提交的证书是可信赖的,DC只要从证书中提取用户名并且和AD中的用户属性进行匹配就能完成验证了(不需要验证用户的密码了)。

         下面我们来具体看下smart card是如何登陆的:

  1. 用户把smart card插入读卡器以后, winlogon进程把登录事件委派给GINA进行处理.
  2. 然后在窗口中输入PIN (不是用户名和密码).
  3. GINA 把 PIN 发送给 Local Security Authority (LSA).

Note: 不需要输入域信息, 因为通过 User Principal Name (UPN)登录.

  1. LSA 使用 PIN 来访问 smart card 并提取出用户的证书和公钥.
  2. Kerberos security service provider 把用户证书以及公钥发送给KDC (在AS Request包中的PA Data Structure里面
  3. KDC把证书中的UPN 和AD数据库中用户属性里的UPN进行比较,同时KDC验证该证书的签名是否由授权的root CA签发的。
  4. KDC 使用用户证书里的公钥加密 logon session key , ,这样做,可以确保只有该用户可以用自己的私钥解开这两个key,而后,用KDC自己账号(krbtgt)的密码加密TGT,并将此TGT与加密的logon session key通过PA_PK_AS_REP反馈给客户端。
  5. 客户端获得TGT,并解开Logon session key 后进入kerberos验证的第二阶段,向KDC申请service ticket. 当这一步完成之后,后续的步骤就和标准的kerberos验证一样。

最后让我们看一个netmon的抓包,探究一下神奇的PA Data究竟长什么样:

       

       

证书的信息:

      

      再看一下标准的Pa Data(思考下有什么不同):

      

       参考第二篇博文,我们可以看到标准的Pa Data里有两个structure:

a>     用户密码加密的时间戳

b>    “include-PAC" flag

谢谢,

俞汝霖 | 企业平台支持部AD技术工程师 | 微软亚太区全球技术支持中心

 

本博文仅供参考,微软公司对其内容不作任何责任担保或权利赋予