Ntlm&Kerberos认证方式

NTLM

NTLM介绍

NTLM 是 telnet 的一种验证身份方式，它是基于挑战（Chalenge）/响应（Response）认证机制的一种认证模式，是一种即时应答的协议，NT又是指windows NT 早期的标准安全协议。

NTLM认证流程

第一步:客户端接收用户输入的用户名,密码,域,然后客户端会将密码hash过后存于本地

第二步:客户端将用户名明文发送给DC

第三步:DC会生成一个16字节的随机数，名为Challenge，之后传回给客户端

第四步:当客户端收到Challenge之后，会复制一份，与之前转换成Hash的密码一同，在混合转换成Hash，混合后值为:response，之后客户端再将Challenge,Response及用户名一并都传给服务端

第五步:服务端在收到客户端传过来的这三个值以后会把它们都转发给DC

第六步:当DC接到过来的这三个值的以后,会根据用户名到域控的账号数据库(ntds.dit)里面找到该用户名对应的hash,然后把这个hash拿出来和传过来的challenge值再混合hash

第七步:将(6)中混合后的hash值跟传来的response进行比较,相同则认证成功,反之,则失败

NTLM Hash的生成

假设我的密码是admin，那么操作系统会将admin转换为十六进制，经过Unicode转换后，再调用MD4加密算法加密，这个加密结果的十六进制就是NTLM Hash

admin -> hex(16进制编码) = 61646d696e
61646d696e -> Unicode = 610064006d0069006e00
610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634

Kerberos

Kerberos介绍

Kerberos是一个Authentication协议，目的即为判断用户的身份是否为用户所声明的身份，也就是判断在域内声明的客户端或服务端是否就为客户端或服务端。

Kerberos特点

Kerberos协议避免了用户的密码以明文的形式被传输，避免了密码被截获的危险。而且使用的是一种短期的Key，由于这种Key只在一段时间内有效，即使加密的数据包被恶意的网络监听者截获，等他把Key计算出来的时候，这个Key早就已经过期了。相较于NTLM，NTLM还需要将用户名进行明文传输，导致可能中途被截断导致安全问题。同时引入的短期动态口令的原理，防止截断加密包进行破解。

Kerberos角色

KDC（确切地说是KDC中的Authentication Service）实现对Client身份的确认，并颁发给该Client一个TGT。

AD（Account Database） 用户数据库

用户一般为客户端/Client

服务端/Service

AS（Authentication Service）接收KRB_AS_REQ验证发送方是否为声称的角色，同时验证该角色是否在AD里

TGS（Ticket Granting Service）票据分发服务

Kerberos认证流程

第一步:Client向KDC的Authentication Service发送Authentication Service Request（KRB_AS_REQ）发送内容:

​ 包含用户身份信息即为用户名密码和KDC的Ticket Granting Service的Server Name

第二步:AS通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密，如果是一个合法的Timestamp，则可以证明发送方提供的是正确无误的密码。验证通过之后，AS将一份Authentication Service Response(KRB_AS_REP)发送给Client。发送内容:

​ 这一步包含被客户端的Master Key加密过的Logon Session Key(验证身份的登录信息)

​ TGT(加密后)包含:Logon Session Key(登录信息) Client name & realm(用户信息) End Time：(TGT的到期时间)

第三步:客户端向KDC中的TGS（Ticket Granting Service）发送Ticket Granting Service Request(KRB_AS_REP) 发送内容:

​ TGT

​ Authenticator(包含了证明TGT拥有者为自身的信息)

​ Client name & realm Server name & realm (均为加密后)

第四步:TGS先使用自己的Master Key对客户端提供的TGT进行解密，获得Logon Session Key。再通过Logon Session Key解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response(KRB_AS_REP) 发送内容:

​ 使用Logon Session Key加密过的Session Key。该Session Key 将被用于Client和Server的认证

​ Ticket(内容与TGT加密信息一致)

第五步:Client收到KRB_TGS_REP，使用Logon Session Key解密第一部分后获得Session Key。有了Session Key和Ticket，Client就可以直接和Server进行交互.利用可以直接交互，客户端向Server发送KRB_AP_REQ 发送内容:

​ Ticket(与第四步不同，这次需要的是客户端获得的被Server Key加密的Ticket)

​ Authenticator(与第三步内容相同)

​ Flag(是否需要双向验证的标志)

第六步:Server接收到KRB_AP_REQ之后，使用自己的Master Key解密Ticket，从而获得Session key。通过Session key解密Authenticator，验证对方身份，如果验证通过允许对方访问资源，反之拒绝。

对于需要进行双向验证，Server从Authenticator提取Timestamp，使用Session Key进行加密，并将其发送给Client用于Client验证Server的身份。