去掉sql server windows登录_看完这个，你的Windows还安全吗？01-认证过程和凭据

看完这个，你的Windows还完全吗？ 日常生活中，我们的机密、隐私、安全问题尤为重要，都懂嚎！但是有很多人认为，电脑设个密码就行了。。。说的是不是你，别摇头。。。

觉得这样就安全就大错特错了，不信是么，一起来看一下Windows认证需要的内容和认证过程。

认证过程和凭据 ：

1.过程：

a、本地用户认证

在进行本地登录认证时操作系统会使用用户输入的密码作为凭证去与系统中的密码进行对比验证。

该系统内部运行流程如下

首先用户注销、重启、锁屏后操作系统会让winlogon显示登录界面也就是输入框接收输入后将密码交给lsass进程这个进程会将明文密码加密成NTLM Hash对SAM数据库比较认证。

Windows Logon Process winlogon.exe是 Windows NT 用户登陆程序用于管理用户登录和退出。

lsass 用于微软Windows系统的安全机制。它用于本地安全和登陆策略该程序运行内存中会记录用户输入的 hash 一定概率几率明文。

b、MSCACHE(域缓存凭据)

MSCACHE，又叫作 domain cached credentials、DCC、域缓存凭据。它作用是是缓存在机器本地注册表中的域凭据+域授权信息。

默认情况下windows 操作系统会自动缓存记录最后 10 个密码哈希值。当域控制器不可访问时系统将检查已缓存的最后一个密码哈希值以便使用系统对用户进行身份验证。

需要注意的是，这里的hash是指 mscache hash，或者叫 dcc hash，根据操作系统的版本不同，又分为 dcc1 hash 与 dcc2 hash。Vista 之前保存的是 dcc1， 之后保存的是 dcc2。 两种 hash 的生成算法不一样。但无论是哪种都不是 NTLM 的 HASH。所以导出的域缓存的 hash 是不能用于 PTH ，只能用来破解。

这些密码哈希值缓存在以下注册表设置中HKEY_LOCAL_MACHINESECURITYCache

本地策略组编辑器 -> 计算机配置 -> Windows 设置 -> 本地策略 -> 安全选项 -> 交互式登录之前登

录到缓存的次数 -> 0

2.然后就是认证凭据：

a、lsass.exe 程序

lsass.exe 是一个系统重要进程用于微软Windows系统的安全机制。它用于本地安全和登陆策略。而SAM的功能就固定于 lsass.exe 中但是 lsass.exe 不仅仅只进行本地身份认证所有正确通过本地、远程身份认证的用户信息都会保存在 lsass.exe 的内存中。

winlogon.exe -> 接收用户输入 -> lsass.exe -> (认证)

本地策略组编辑器 -> 计算机配置 -> Windows 设置 -> 本地策略 -> 安全选项 -> 交互式登录之前登

录到缓存的次数 -> 0

由于 WDigest 协议的存在在一些旧版本的 windows 操作系统中XP – win 8.0 和 server 2003 – server 2012 R1纯文本密码存储在 lsass.exe 进程中。考虑到安全因素在后续的 windows 操作系统版本中默认禁用此协议。对于旧版本操作系统微软官方发布 KB2871997 补丁允许用户自行决定是否禁用该协议。

修改是否禁用需要修改注册表HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigest将Negotiate 和 UseLogonCredential 注册表项值应设置为 0 可以完全禁用此协议。

除此以外，用户保存在该系统内的用户凭证也是由lsass.exe管理，在导出程序内存时，会同时导出，并且密码还是以明文的方式保存。

b、SAM文件

SAM 即"安全帐户管理器(Security Accounts Manager)"是 windows 操作系统管理用户帐户的安全所使用的一种机制。

安全帐户管理器对帐号的管理是通过安全标识进行的安全标识在帐号创建时就同时创建一旦帐号被删除安全标识也同时被删除。安全标识是唯一的即使是相同的用户名在每次创建时获得的安全标识都是完全不同的。因此一旦某个帐号被删除它的安全标识就不再存在了即使用相同的用户名重建帐号也会被赋予不同的安全标识不会保留原来的权限。

SAM 是用来存储 windows 操作系统密码的数据库文件为了避免明文密码泄漏SAM 文件中保存的是明文密码在经过一系列算法处理过的 Hash 值被保存的 Hash 分为 LM Hash 、 NTLM Hash 。当用户进行身份认证时会将输入的 Hash 值与 SAM 文件中保存的 Hash 值进行对比。在域控制器上 SAM 文件相当于活动目录数据库文件 ntds.dit。

值得注意的是 ntds.dit 并不等于 SAM 文件虽然在服务器升级为域控时会默认将 SAM 中的本地用户升级为对应级别的域用户或域管理员。但需要注意的是 SAM 文件依旧存在依旧可以配置本地管理员的设置。

SAM 文件保存于%SystemRoot%system32configsam中

在注册表中SAM 保存于

HKEY_LOCAL_MACHINESAMSAM

HKEY_LOCAL_MACHINESECURITYSAM

在正常情况下 SAM 文件处于锁定状态不可直接访问、复制、移动仅有 system 用户权限才可以读写该文件。

出于安全性的考虑在后期的 windows 系统中 SAM 文件中被 bootkey 加密，而 bootkey 则保存在这个SYSTEM 文件下。因此单独的 SAM 文件是无法正常解读的如果需要解密则还需要加载对应系统的 system 文件。

SAM 文件中内容存储类似于 Unix/Linux 系统中的 passwd 和 shadow 文件的结合，区别在于没有这么直观明。

SAM 中 hash 密码存储格式为用户名称:RID:LM-HASH值:NT-HASH值例如

Administrator:500:aad3b435b51404eeaad3b435b51404ee:732ca7a7e650537443ccacae4d2f7

1f5:::

这一串内容表示

用户名为Administrator

RID为500

LM-HASH值为：aad3b435b51404eeaad3b435b51404ee

NT-HASH值为：732ca7a7e650537443ccacae4d2f71f5

3.本地认证讲完看一下网络认证

NTLM 协议

NTLM 是一种网络认证协议它是基于挑战Chalenge/响应Response认证机制的一种认证模式。这个协议只支持 windows 操作系统。

需要注意的是 NTLM 协议是一个嵌入式的协议很重要消息的传输依赖于使用ntlm的上层协议比如SMBLDAPHTTP等。需要注意的是NTLM 不像 kerbreos既可以镶嵌在上层协议里面也可以作为独立的应用层协议。NTLM 是只能镶嵌在上层协议里面消息的传输依赖于使用 ntlm 的上层协议。

a、认证过程

1.三种重要消息

NTLM 验证主要由三种消息组成

type 1协商

type 2质询

type 3验证

协商主要用于确认双方协议版本。

质询就是挑战Chalenge/响应Response认证机制起作用的范畴本小节主要讨论这个机制的运作流程。

验证验证主要是在质询完成后验证结果是认证的最后一步。

2.完整验证流程

1.首先用户客户端向服务器发送 type 1 消息协商它主要包含客户端支持和服务器请求的功能列表。

2.服务器在接收到用户发来的请求后用 type 2 消息质询消息进行响应这个响应中不仅包含有服务器支持和同意的功能列表最重要的是包含服务器产生的Challenge。

3.用户客户端在收到服务器的响应后用 type 3 消息验证回复质询。用户客户端接收到 challenge 之后使用用户 hash 与 challenge 进行加密运算得到 response然后将 response、username、challeng 发给服务器。消息中的 response 是最关键的部分因为它们向服务器证明客户端用户已经知道帐户密码。

在服务器拿到用户客户端发送的 type 3 消息之后使用 challenge 和用户 hash 进行加密得到 response2 与 type 3 发来的 response 进行比较。

1.如果用户 hash 是存储在域控里面的话那么没有用户 hash也就没办法计算 response2也就无法验证。这个时候服务器就会通过 netlogon 协议联系域控建立一个安全通道,然后将 type 1,type 2type3 全部发给域控(这个过程也叫作Pass Through Authentication认证流程)

2.域控使用 challenge 和用户hash进行加密得到 response2与 type 3 的 response 进行比较并将结果返回给服务器。

域控远程认证

Kerberos 域认证

a、kerberos 协议概述

Kerberos 是一种由 MIT麻省理工大学提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。

该认证过程的实现不依赖于主机操作系统的认证无需基于主机地址的信任不要求网络上所有主机的物理安全并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下 Kerberos 作为一种可信任的第三方认证服务是通过传统的密码技术如:共享 密钥执行认证服务的。

在 Kerberos 协议中主要是有三个角色的存在

1.访问服务的Client(以下表述为Client 或者用户)

2.提供服务的Server(以下表述为服务)

3.KDCKey Distribution Center密钥分发中心 kerberos 测试工具介绍

其中 KDC 服务默认会安装在一个域的域控中而 Client 和 Server 为域内的用户或者是服务如 HTTP 服务SQL 服务。在 Kerberos 中 Client 是否有权限访问 Server端的服务由 KDC 发放的票据来决定。

1.名词概念

票据Ticket是网络对象互相访问的凭证。

TGTTicket Granting Ticket入场券通过入场券能够获得票据是一种临时凭证的存在。

TGSticket granting service票据授予服务。

KDC负责管理票据、认证票据、分**据但是 KDC 不是一个独立的服务它由以下服务组成

Authentication Service: 为client生成TGT的服务

Ticket Granting Service: 为client生成某个服务的ticket

另外还需要介绍一个类似于本机SAM的一个数据库AD全称叫 account database存储所有 client 的白名单只有存在于白名单的 client 才能顺利申请到TGT。

从物理层面看AD 与 KDC 均为域控制器Domain Controller。

b、认证流程

1.AS-REQClient 向 KDC 发起请求明文密码将会被加密为 hash时间戳使用 Client hash 进行加密然后作为认证票据TGT请求AS-REQ中的认证因子发送给KDC。

2.AS-REPKDC 使用 Client hash 进行解密如果结果正确就返回用 krbtgt hash 加密的 TGT 票据。TGT 里面包含 PACPAC 包含 Client 的 sidClient 所在的组。

3.TGS-REQ当 Client 请求票据授予服务TGS票据时用户需要向 KDC 展示TGT数据。KDC 会打开票据进行校验和检查。如果 KDC 能够打开票据并能通过校验和检查那么会认为 TGT 为有效票据。此时 TGT 中的数据会被复制以创建 TGS 票据。

4.TGS-REPKDC 使用目标服务账户的 hash 对 TGS 票据进行加密然后将结果发送给 Client。(这一步不管用户有没有访问服务的权限只要TGT 正确就返回 TGS 票据)

5.AP-REQClient 访问目标服务并发送 TGS 票据去请求服务。

6.AP-REP服务使用自己的 hash 解密 TGS 票据。如果解密正确就拿着 PAC 去 KDC 查询 Client 有没有访问权限KDC 解密 PAC。获取 Client的 sid以及所在的组再根据该服务的 ACL判断 Client 是否有访问服务的权限。

c、PAC

在 Kerberos 最初设计的几个流程里说明了如何证明 Client 是 Client 而不是由其他人来冒充的但并没有声明 Client 有没有访问 Server 服务的权限因为在域中不同权限的用户能够访问的资源是有区别的。

所以 Microsoft 为了解决这个问题在实现 Kerberos 时加入了 PAC 的概念PAC 的全称是 Privilege Attribute Certificate特权属性证书。

PAC 可以理解为一串校验信息为了防止被伪造和串改原则上是存放在 TGT 里并且 TGT 由 KDC hash 加密。同时尾部会有两个数字签名分别由 KDC 密码和 server 密码加密防止数字签名内容被篡改。

同时 PAC 指定了固定的 User SID 和 Groups ID还有其他一些时间等信息Server 的程序收到 ST 之后解密得到 PAC 会将 PAC 的数字签名发送给 KDCKDC 再进行校验然后将结果已 RPC 返回码的形式返回给 Server。

下次介绍获取用户凭证思路

感兴趣的小伙伴可以关注或私信我