windows认证机制教程

windows认证机制

一、NTLM认证
- 1.1 NTLM本地认证
- 1.2 NTLM网络认证
二、kerberos认证

当前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认证机制教程