windows认证机制

2021/6/22 7:26:53

本文主要是介绍windows认证机制,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

windows认证机制

  • 一、NTLM认证
    • 1.1 NTLM本地认证
    • 1.2 NTLM网络认证
  • 二、kerberos认证
    • 2.1 kerberos解决了什么问题
    • 2.2 kerberos中涉及的角色
    • 2.3 kerberos完整认证过程

本文参考Windows认证及抓密码总结

当前windows的认证机制主要有两种,一种是ntlm认证,另一种是kerberos。还有一种成为ACCESS TOKEN也起到权限认证的作用,这个token主要是用来标识用户与程序之间的所属关系的。当用户登录后会生成一个access token,当前用户打开的每一个进程都拥有一份这个access token的拷贝,这也是为什么用户b不能处理用户a打开的进程的原因

一、NTLM认证

1.1 NTLM本地认证

当用户注销登录后,操作系统会盗用winlogon.exe程序,也就是我们看到的登录界面,当我们输入用户名密码之后,该进程会将我们的用户名密码交给lsass.exe进程,该进程会将我们的用户名密码进行hash变换得到ntlm hash,并存储一份明文密码,然后同windows的sam数据库进行对比,如果对比成功,则登录成功,否则登录失败。因为存在明文密码,所以我们可以在lsass进程中将该密文提取出来,常用的提取工具是mimikatz与msf。
ntml是怎么得到的呢,首先将我们的用户名密码进行16进制变化,然后进行unicode变换,通过md4摘要得到ntlm hash

123456 -> hex(16进制编码) = 313233343536
313233343536 -> Unicode = 610064006d0069006e00
610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634

1.2 NTLM网络认证

NTLM的网络认证,设计到challenge/response机制,即协商、挑战、认证
协商: 主要确认双方的协议版本、加密等级
挑战: 服务器在收到客户端发送的协商请求后,得到里面的内容,然后确认使用的协议版本、加密等级,安全服务,并生成一个随机数返回给客户端,该随机数根据协议版本的不同,长度不同。
认证: 挑战完成后,进行认证

具体的实现过程如下:

  • 首先,客户端在接受到用户输入的用户名密码之后,将其交给lsass.exe进程进行ntlm变换的到一个ntlm hash
  • 然后,客户端将用户名明文发送给服务端,服务端使用该用户名生成一个16位的随机数,即challenge发还给客户端。
  • 客户端收到该challege后,使用ntlm hash对该challege进行加密,然后发还给服务端,及response
  • 服务端收到该response之后,会向DC发送认证请求,该请求包括用户名、原始challenge、经过ntlm has变换之后的challenge即响应。
  • DC在收到该认证请求之后,会通过传过来的用户名从自己的数据库,及AD中获取该用户的ntlm hash值,然后对发送过来的原始challenge进行加密之后对比传过来的response,如果对比成功则人称通过,否则不通过。这一步的具体认证过程是我脑补的,不知道对不对,原文并没有说清楚

二、kerberos认证

这个东西有点复杂,不过找到了一篇很好的文章,终于理解了!!!Kerberos认证流程简述

2.1 kerberos解决了什么问题

简单地说,Kerberos提供了一种单点登录(SSO)的方法。考虑这样一个场景,在一个网络中有不同的服务器,比如,打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求。很自然的,不可能让每个服务器自己实现一套认证系统,而是提供一个中心认证服务器(AS-Authentication Server)供这些服务器使用。这样任何客户端就只需维护一个密码就能登录所有服务器。kerberos不仅验证客户端,也验证服务端!!

2.2 kerberos中涉及的角色

  • KDC 密钥分发中心 包括as与tgs两部分 一般在域控中由DC担任
  • AS 认证服务器,用于提供想tgs服务器获取ticket的入场券TGT
  • TGS 票据授予服务器, 用于授予客户端ticket
  • AD 账户数据库 存放在AS中,只有该数据库白名单中的用户才能申请TGT
  • session key 用户与域控生成的加密密钥
  • client 请求的发起方
  • server 提供服务的一方

2.3 kerberos完整认证过程

先放图
在这里插入图片描述
这里面涉及到一个krbtgt账户,该账户时kdc的一个自建用户,不能用于登录,在域控中使用net user命令可以查看。

  • 首先,客户端在接受到用户输入的用户名密码之后,将其交给lsass.exe进程进行ntlm变换的到一个ntlm hash
  • 然后,客户端将用户名明文、时间戳发送给KDC,向KDC申请TGT
  • KDC下给你AS服务器验证该用户,判断其是否在AD的白名单里面,如果在,AS服务器则会生成一个session key ,再从AD中查询到该用户的ntlm hash 使用该hash对该session key进行加密得到密文A;再用krbtgt的ntlm hash对session key、客户端用户信息、客户端时间戳、过期时间进行加密得到TGT;将该TGT与密文A一并发回给客户端
  • 客户端收到信息后,使用自己的ntlm hash 对密文A进行解密得到session key。再用这个session key 将client info 与客户端时间戳进行加密得到密文B,再将密文B与TGT一起发送给TGS服务器
  • TGS服务器收到消息后,使用krbtgt的ntlm hash对TGT进行解密得到session key、client info、时间戳,再用该session key 解密密文B 得到client info、时间戳,在对比两次解密的值,是否一致,时间戳需要在一定的误差范围内,windows是五分钟,如果一致,TGS服务器生成一个新的session key2,用它加密client info 时间戳得到密文ENC,再由server的ntlm hash 加密session key2、client info 、时间戳得到ticket,再将ticket与enc发还给客户端
  • 客户端发送ticket与enc到服务端请求服务
  • 服务端server 通过自己的ntlm hash 解密ticket 得到session key2、client info 、时间戳,然后通过session key2解密enc得到client info、时间戳,对比两次解密的结果,对比成功则授权访问

由于krbtgt只存在于域控中KDC中,TGT要用krbtgt的NTLM HASH解密,即TGT只能由KDC解密
所以如果krbtgt的NTLM HASH泄露出去了,那谁拿到krbtgt的NTLM HASH,谁就充当KDC,就可以伪造TGT,也就是权限维持里常说的黄金票据。。。。。。的原理,生成伪造黄金票据把票据一导入,体验一把生杀大权尽在手中的感觉。黄金票据就是域控的krbtgt用户的ntlm hash

另一方面ticket是服务账号用NTLM HASH加密得到的,如果这个服务账号的NTLM HASH泄露了,谁拿到域控中计算机服务账号的NTLM HASH,谁就充当TGS,这就是权限维持中白银票据的原理。白白银票据就是被请求服务的账户的ntlm hash。



这篇关于windows认证机制的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程