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是如何登陆的：
- 用户把smart card插入读卡器以后, winlogon进程把登录事件委派给GINA进行处理.
- 然后在窗口中输入PIN (不是用户名和密码).
- GINA 把 PIN 发送给 Local Security Authority (LSA).
Note: 不需要输入域信息, 因为通过 User Principal Name (UPN)登录.
- LSA 使用 PIN 来访问 smart card 并提取出用户的证书和公钥.
- Kerberos security service provider 把用户证书以及公钥发送给KDC （在AS Request包中的PA Data Structure里面）
- KDC把证书中的UPN 和AD数据库中用户属性里的UPN进行比较，同时KDC验证该证书的签名是否由授权的root CA签发的。
- KDC 使用用户证书里的公钥加密 logon session key ， ，这样做，可以确保只有该用户可以用自己的私钥解开这两个key，而后，用KDC自己账号（krbtgt）的密码加密TGT，并将此TGT与加密的logon session key通过PA_PK_AS_REP反馈给客户端。
- 客户端获得TGT，并解开Logon session key 后进入kerberos验证的第二阶段，向KDC申请service ticket. 当这一步完成之后，后续的步骤就和标准的kerberos验证一样。
最后让我们看一个netmon的抓包，探究一下神奇的PA Data究竟长什么样：
证书的信息：
再看一下标准的Pa Data（思考下有什么不同）:
参考第二篇博文，我们可以看到标准的Pa Data里有两个structure:
a> 用户密码加密的时间戳
b> “include-PAC" flag
谢谢，
俞汝霖 | 企业平台支持部AD技术工程师 | 微软亚太区全球技术支持中心
本博文仅供参考，微软公司对其内容不作任何责任担保或权利赋予