NTLM认证与kerberos认证与PAC相关知识

ntml认证

过去一般用于工作组环境中,也就是个人PC机,不过域内也会使用,而且与kerberos认证共存。
域内的流程:

  1. 客户端向要访问的机器发送用户名,这个被访问的机器称为服务端。

  2. 服务端向客户端发送一个challenge。

  3. 客户收到challenge后用自己的 NTML hash对其进行加密生成response , 并将response发送给服务端

  4. 服务端将response、challenge、客户端的用户名一起发送给域控。

  5. 域控将用户名对应的hash用challenge进行加密后与response进行对比,如果一样那么认真成功。


工作组环境下登陆时候的ntlm认证:
操作系统会将用户输入的密码转换成hash然后与sam文件对应用户的hash做比较,如果一致则认证成功。

kerberos认证

如果cat 要访问tom这个server,就会经历以下的认证步骤。

1.客户端向kdc的as发送authenticator说自己是cat,authenticator它的内容是一个被Client的Master key加密过的Timestamp,还会明文发送Client name & realm: 简单地说就是Domain name\Client例如test\zhangsan。还会发送server name这个参数,此时的server name 是tgs的名字,还有其他的例如ip与加密方式等。因为客户端下一步要访问tgs来得到ticket。
发送内容:

1.authenticator(master key加密的时间戳)
2.client info(id与ip)
3.serverName 这里是tgs的名字
4.tgt的寿命

2.as 收到 数据后用cat的master 解密authenticator,并对结果进行分析,若验证成功,则as用cat的master加密一段随机生成的challenge来生成第一个值,这个challenge就是session key(C - KDC)。再生成一个用krbtgt的hash加密的tgt,这个tgt里面有cat的用户信息,时间戳,还有用与客户端与kdc交流的session key也就是之前生成的那个challenge。
发送内容:

1.tgt:client的名字,client的ip,tgs的名字,时间戳,tgt的到期时间, session key(kdc-client)
2.被client的master key加密的session key(kdc-client)tgs的名字,时间戳,到期时间

3.客户端收到这两段信息,用自己的master key解密得到session key。再用session key加密自己的信息与时间戳得到authenticator。将authenticator与想要访问的服务器名与TGT这三个数据发送给TGS。
发送内容:

1.authenticator。被session key(kdc-client)加密的时间戳还有client的名字
2.tgt。同上
3.serverName 这里是真正要访问的服务的名字
4.ticket的寿命

4.TGS得到这三个值。先用自己的master key解密TGT得到client info与时间戳 与 session key(C-KDC)。在用这个session key解密authenticator得到client info与时间戳等。对比两个用户信息。若相同则认证成功,证明客户端就是它所声称的那个人。认证成功后,用客户端说申请访问的服务端的master key加密client info 与一个专用于客户端与指定要访问的服务端之间交流的session key 这些东西组合起来就是ticket的内容。再用KDC与客户端之间交流用的sessionkey加密那个客户端与服务端之间交流的session key。将这两组数据发送给客户端。
发送内容:

1.ticket:client的名字,client的ip,到期时间,session key(client-server),server的名字也就是tom,时间戳。前面这些是被server的master key 加密的。
2.被session key(kdc-client)加密的session key(client-server),时间戳,到期时间,server的名字

黄金票据的原理就是,用krbtgt的hash来伪造TGT的内容。更改里面的client参数与session key等。让TGS以为我就是那个我所声称的人,当然我一般会声称自己是administrator。第四步主要是来验证客户端的身份。

5.客户端得到一个ticket与一个被(客户端-KDC)session key加密的数据。先用session key(C-KDC)解密数据得到session key(S-C)。用这个session key(S-C)加密自己的client info 与时间戳生成authenticator。将authenticator与ticket 发给要访问的服务器。
发送内容:

1.authenticator。被session key(c-s)加密的时间戳与client info
2.ticket

###白银票据就是伪造ticket。伪造TGS ticket的核心点是能够得到目标服务器的ntlm hash。
###spn攻击就是找到那个“主人”是krbtgt的服务器。这样子就可以请求到用krbtgt的hash加密的ticket了。这个ticket加密的内容是 client info 跟一个session key还有timestamp。这时候可以用暴力破解技术来破解这个ticket。知道破解结果中有client info的相关信息,即可算作破解成功。进而得到krbtgt的密码,可以做黄金票据拿下整个域环境。

6.服务器用自己的master key 解密ticket 得到session key与client info 等。再用session key 解密authenticator。对比信息,决定验证是否成功。成功后则会返回一条用session key(s-c)加密的包含client info与时间戳到信息。

TGT跟ticket的内容基本是一样的。只是加密途径不一样。一个是用krbtgt的hash加密,一个是用sever的hash加密。
里面内容都是client 的info 跟时间戳还是session key,只不过一个session key是客户端与kdc之间的,一个是客户端与服务端之间的。

PAC认证

pac认证是在kerberos认证的第二步认证成功的时候就会将pac夹在返回的TGT中给客户端。之后会存在tgs返回给client 的ticket中最终传送给server。

PAC的实现

当用户与KDC之间完成了认证过程之后, Client需要访问Server所提供的某项服务时, Server为了判断用户是否具有合法的权限需要将Client的User SID等信息传递给KDC, KDC通过SID判断用户的用户组信息, 用户权限等, 进而将结果返回给Server, Server再将此信息与用户所索取的资源的ACL进行比较, 最后决定是否给用户提供相应的服务。
PAC会在KRB_AS_REP阶段中被AS放在TGT里加密发送给Client,然后由Client转发给TGS,让其验证自己的PAC是否被更改。
在PAC中包含有两个数字签名PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM,这两个数字签名分别由Server端密码HASH和KDC的密码HASH加密。
同时TGS解密之后验证签名是否正确,然后再重新构造新的PAC放在Ticket里返回给客户端,客户端将Ticket发送给服务端进行验证。

附录:
第一组信息ticket的详细内容:(被server的master key 加密)
你的姓名/ID
HTTP 服务名/ID
你的网络地址(如果是多个主机,则是一个IP列表.如果是任意一台机器,那么就是null)
时间戳
ticket的寿命
HTTP Service Session Key

第二组信息:被 session key(kdc-C)加密
HTTP服务名/ID
时间戳
ticket的寿命
HTTP Service Session Key

第一组信息tgt的内容:被krbtgt的master key 加密
你的名字/ID 也就是client的名字
TGS的名字/ID
时间戳
你的网络地址 (如果是多个主机,则是一个IP列表.如果是任意一台机器,那么就是null)
TGT的寿命
TGS Session Key 用与C与KDC的通信

第二组信息:被client的master key 加密
TGS的名字/ID
时间戳
寿命
TGS Session Key

  • 2
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Shanfenglan7

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值