Windows认证基础知识

潜行的鱼

已于 2024-02-25 16:31:48 修改

阅读量1k

点赞数 14

分类专栏： ATT&CK视角下的红蓝对抗实战指南文章标签： windows 安全

于 2024-02-21 22:29:17 首次发布

本文链接：https://blog.csdn.net/bbq1234564/article/details/136221084

版权

ATT&CK视角下的红蓝对抗实战指南专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Windows凭据

1.SSPI

SSPI(Security Support Provider Interface,安全支持提供程序接口)是Windows操作系统中用于执行各种安全相关操作的公用API.SSPI的功能比较全面，可以用来获得身份验证、信息完整性校验、信息隐私保护等集成的安全服务。它是众多安全支持提供程序的调用接口。

2.SSP

SSP(Security Support Provider,安全支持提供程序)是一个用于实现身份验证的DDL文件。当操作系统启动时，SSP会被加载到LSA(Local Security Authority,本地安全机构)中。SSP的主要作用是扩展Windows的身份安全验证功能。可以这样简单理解：SSP就是一个DLL文件，用来实现身份认证并维持系统权限。下面介绍一下Windows系统中的常见SSP类型。

3.常见SSP类型

1)NTLM：一种Windows网络认证协议，基于挑战/响应(Challenge/Response)验证
机制，用于对主机进行身份验证。
2)Kerberos：一种网络身份验证协议。作为一种可信任的第三方认证服务，它的主要
优势在于可以提供强大的加密和单点登录(SSO)机制。

3)Negotiate:用于在SSPI和其他SSP之间进行安全支撑的应用程序层。当某个应用程序调入 SSPI 以登录到网络时，该应用程序会指定一个SSP来处理请求。如果指定Kerberos或NTLM SSP,则Negotiate将会分析请求并选取最佳SSP,以便基于客户配置的安全策略处理请求。

4)安全通道：也称SChannel,它使用SSL/TLS记录来加密数据有效载荷，主要用于需要进行安全超文本传输协议(HTTP)通信的Web应用程序。

5)摘要身份验证：基于HTTP和SASL（简单认证与安全层）身份验证的质询/响应协议。

6)Cred SSP:用于传输安全凭据的网络协议，通常在RDP或WinRM远程管理中用于提供单点登录和网络级身份验证。

7)分布式密码验证(DPA):提供使用数字证书完成的互联网身份验证。

8)用户对用户的公开密钥加密技术(Public Key Cryptography User-to-User,PKU2U):在不隶属于域的系统之间提供使用数字证书的对等身份验证。

Windows访问控制模型

1.访问控制模型简介

访问控制模型(Access Control Model)是Windows操作系统中一个关于安全性的概念，由访问令牌和安全描述符两部分构成，其中：访问令牌(Access Token)由当前登录Windows账号的用户持有，它包含该账号的基础信息，如用户账户的标识和权限信息；安全描述符由要访问的对象持有，它包含当前对象的安全信息。

假设当用户登录时，操作系统会对用户的账户名和密码进行身份验证，则当登录成功时，系统会自动分配访问令牌。访问令牌包含安全标识符(SD),SD用于标识用户的账户及其所属的任何组账户。当我们创建一个进程，也就是访问一个资源（进程资源）的时候，访问令牌会被复制一份并交给进
程，进程根据它的创建者为它设置的安全描述符中的访问控制列表(ACL)来判断我们是否可以访问，是否有权限执行某步操作。

2.访问令牌

Windows的访问令牌分为两种类型主令牌(Primary Token)和模拟令牌（Imperson-ation Token),它代表某种请求或登录机制的凭据，使用户可以在短时间内执行某种身份认证或权限操作的验证信。Windows系统中每个用户登录账号都生成一个对应的访问令牌。当用户使用账号登录操作系统时，系统会将所登录的账号与安全数据库(SAM)中存储的数据进行对比验证，验证成功后才会生成访问令牌。如果我们打开的进程或线程正在与具有安全描述符的对象交互，则系统将会携带今牌进行访问，以此来表示用户身份。

创建进程时，Windows操作系统的内核都会为进程创建并分配一个主令牌。每个进程都含有一个主令牌，主令牌描述了进程相关用户账号的安全上下文。

同时，一个线程可以模拟一个客户端账号，允许此线程在与安全对象交互时使用客户端的安全上下文。一个正模拟客户端的线程拥有一个主令牌和一个模拟令牌。（主令牌是与进程相关的，而模拟令牌是与线程相关的。）

(1)主令牌
主令牌也叫授权令牌(Delegation Token),是一种认证机制，用于交互式登录，是为了减少不必要的认证工作而出现的，由Windows操作系统的内核创建并分配给进程的默认访问令牌。主令牌描述了登录进程返回的安全标识SID,与当前进程相关的用户账户的安全组的权限列表，代表系统可以使用令牌控制用户可以访问哪些安全对象、执行哪些相关系统操作。

主令牌通常用于本地登录及通过RDP远程登录的场景。
一个完整的主令牌包含如下内容：

当前账号SID
当前账户所处安全组的SID
该令牌的来源，即它是由哪个进程创建的
所有者的SID
主要组的SID
访问控制列表
用户或组拥有的权限列表
模拟级别
统计信息
限制SID

(2)模拟令牌

在默认情况下，当线程开启的时候，其所在进程的主令牌会自动附加到该线程上作为他的安全上下文。而线程可以在另一个非主令牌的访问令牌下执行，这个令牌被称为模拟令牌，通常会用于客户端/服务器之间的通信。

假设在文件共享的时候，服务器需要访问令牌来验证用户的权限，但它无法直接获取用户的访问令牌（该令牌是锁死在内存中的，无法访问），所以它就需要生成一个模拟令牌。

3.安全标识符

在Windows操作系统中，通常使用安全标识符(Security IDentifier,SID)来标识在系统中执行操作的实体。

SID是一个唯一的字符串，可以代表用户、用户组、域、域组、域成员等角色身份。
SID组成部分

前缀：每个SID以"S-"开头，表示这是一个安全标识符。
版本号：紧随"S-"的是版本号，通常为 "1" 表示当前版本的Windows NT SID格式。
认证机构（Authority）：接下来的一对数字表示颁发此SID的认证机构。对于Windows NT系统，这个通常是固定的"S-1-5"，代表该SID是由Windows NT或其后继者（如Windows 2000, Windows XP, Windows Server 2003及以后版本）颁发的。
子颁发机构（Sub-authority values）：紧跟在认证机构后的是一系列用连字符分隔的数值，这些是子颁发机构标识符，用于进一步区分不同的安全主体类型和实例。例如，在S-1-5之后可能跟着一串序列号，如“21”，然后是更多的子颁发机构编号。
- 对于用户账户、组以及其他内置安全主体，这些子颁发机构值联合起来创建了一个独特的标识符。
- 在特定的SID例子中，如 S-1-5-21-3623811015-3361044348-30300820-1013，"21" 后面的三个长整数就是三个子颁发机构值，最后一个数字往往表示具体的用户或组ID（RID，Relative ID）

通过上述对SID的结构分析，我们知道SID结构是一组标识通用用户或通用组的SID，它们的值在所有操作系统中保持不变。

4.安全描述符

安全描述符（ Securitry Desriptor) 包含DACL（任意访问控制列表）和SACL(系统访问控制列表）。其中SACL用来记载对象访问请求的日志，DACL又包含ACE(访问控制项),该项设置了用户的访问权限。安全描述符绑定在每个被访问对象上，当我们携带访向令牌去访问一个带有安全描述符的对象时，安全描述符会检测我们的访问令牌是否具有访问权限。

安全描述符包含安全描述组织架构及其关联的安全信息。下面来详细介绍安全描述符的组织结构以及它包含的安全信息。

(1)安全描述符的组织结构

安全描述符由SECURITY DESCRIPTOR结构及其关联的安全信息组成，其结构体如下：

typedef struct _SECURITY_DESCRIPTOR {
BYTE                                                         Revision;
BYTE                                                         Sbz1;
SECURITY_DESCRIPTOR_CONTROL                                  Control;
PSID                                                         Owner;
PSID                                                         Group;  
PACL                                                         Sacl;
PACL                                                         Dacl;
} SECURITY_DESCRIPTOR,  *PISECURITY_DESCRIPTOR;

(2)安全描述符包含的安全信息

安全描述符包含如下安全信息。
对象的所有者和所属组的SID
DACL：包含ACE,每个ACE的内容描述了允许或拒绝特定账户对这个对象执行
特定操作。
SACL：主要用于系统审计，它的内容指定了当特定账户对这个对象执行特定操作
时，将其记录到系统日志中。
控制位：一组限制安全描述符或各个成员的含义控制位。
(3)安全描述符查看
当我们需要查看某个对象具有什么安全描述符时，可以右击该对象，选择“属性”选
项，并进一步查看“安全”选项卡，如图所示。

当前对象具有的安全描述符

(4)DACL
DACL包含ACE,决定当前用户以哪种权限访问对象。

系统使用以下方式为新对象构建DACL
        1)对象当前的DACL是对象创建者指定的安全描述符中的DACL。除非在安全描述符的控制位中设置了SE DACL PROTECTED位，否则系统会将所有可继承的ACE合并到指定的DACL中。
        2)如果创建者未指定安全描述符，则系统将从可继承的ACE构建对象的DACL.
        3)如果未指定安全描述符，并且没有可继承的ACE,则对象的DACL是来自创建者的主令牌或模拟令牌的默认DACL.
        4)如果没有指定的、继承的或默认的DACL,则系统将创建不具有DACL的对象，从而允许所有人完全访问该对象。

(5)SACL
SACL主要用于系统审计，同时可以指定哪些用户的行为操作记录会被保存到系统日志中。系统使用以下方式为新对象构建SACL.
1)对象的SACL是对象创建者指定的安全描述符中的SACL。除非在安全描述符的粒制位中设置了SE_SACL_PROTECTED位，否则系统会将所有可继承的ACE合并到指定的SACL中。即使SE_SACL_PROTECTED位置已经设置，来自父对象的SYSTEM_RESOURCE_ATTRIBUTE_ACE和SYSTEM_SCOPED_POLICY_ID_ACE也将合并到新对象.
2)如果创建者未指定安全描述符，则系统将从可继承的ACE构建对象的SACL.
3)如果没有指定的或继承的SACL,则该对象没有SACL.
4)要为新对象指定SACL,对象的创建者必须启用SE_SECURITY_NAME特权。如果为新对象指定的SACL仅包含SYSTEM_RESOURCE_ATTRIBUTE_ACE,则不需要SE_SECURITY_NAME特权。如果对象的SACL是从继承的ACE构建的，则创建者不需要此特权。应用程序不能直接操纵安全描述符的内容。Windows API提供了在对象的安全描述符中设置和检素安全信息的功能。此外，还有用于创建和初始化新对象的安全描述符的函数。

(6)安全描述符字符串
安全描述符字符串是指在安全描述符中存储或传输信息的文本格式。安全描述符包含二进制格式的安全信息，Windows API提供了在二进制安全描述符与文本字符串之间进行相互转换的功能。字符串格式的安全描述符不起作用，但是对于存储或传输安全描述符信息很有用。要将安全描述符转换为字符串格式，需要调用
ConvertSecurityDeseriptorToStringSecurityDescriptor函数；
要将字符串格式的安全描述符转换回有效的功能性安全描述符，需要调用ConvertStringSecurityDescriptorToSecurityDescriptor函数。

令牌安全防御

Windows使用访问令牌来记录用户身份，验证用户权限，每个用户都有一个访问令牌。一般的攻击者都会利用DuplicateTokenEx API来对令牌进行模拟盗窃。他们会使用DuplicateTokenEx函数创建一个新令牌，并对现有的令牌进行复制，将新令牌用于ImpersonateLoggedOnUser函数中，允许调用线程模拟已登录用户的安全上下文，同时也可以通过DuplicateTokenEx复制令牌，并使用CreateProcessWithTokenW把复制的令牌用于创建在模拟用户的安全上下文中运行的新进程。

那么怎样才能对令牌窃取攻击进行有效的安全防御呢？有如下两种方法。

1.禁止域管理员异机登录

域管理员是在整个域控中管理权限最高的，为了防止域管理员的令牌被恶意窃取，必须禁止域管理员异机登录。如果因一些特殊情况域管理员登录了其他机器，应及时将令牌清除，以防止令牌被窃取。

2.开启“审核进程创健”策略。

可以通过开启“审核进程创建”策略来监视令牌操作时所需使用的Windows函数的动作。
1)在CMD窗口输入gpedit.msc命令，进入组策略中，
2)依次选择“计算机配置”→“Windows设置”→“安全设置”→“高级审核策略配置”→“系统审核策略-本地组策略对象”→“详细跟踪”→“审核进程创建”。

3)双击打开“审核进程创建”界面，配置无论成功还是失败都进行审核（在创建进程时会生成审核事件，成功审核记录成功的尝试，而失败审核记录不成功的尝试，如图所示。

4)可以通过事件查看器来查看执行访问令牌尝试操作的记录。

UAC

1.UAC原理概述

用户账户控制(User Account Control,UAC)为Windows Vista推出的一项安全技术，其主要原理在于通过限制应用软件对系统层级的访问，提升Windows操作系统的安全性。虽然此类机能一直遭到部分用户的批评，但后续的Windows操作系统仍保留了此类机能。例如在Windows7中，微软公司保留并改进了此项功能(自定义UAC的安全等级)。

2.UAC级别定义

在Windows Vista中只有开启和关闭UAC的选项，而后续的Windows7对UAC进行了更新，增加了UAC白名单，并且设置了以下4个安全级别，而不再只有开启和关闭。用户可以根据自身应用场景需求动态调整UAC的安全级别。
1)第一级别（最高级别），如图所示，相当于Windows Vista中的UAC,即对所有改变系统设置的行为(如安装程序、更改Windows设置)进行提醒。

2)第二级别(默认级别)，如图所示，仅在程序尝试改变系统设置时才会弹出UAC提示，用户改变系统设置时不会弹出提示。(如果使用常见程序和访问常见网站，推荐使用这一级别。)

3)第三级别，如图所示，仅当程序尝试更改计算机时弹出通知提示，用户自行设置更改计算机时不会弹出通知提示。(与第二级别基本相同，但不使用安全桌面。)

4)第四级别，如图所示，UAC从不提示(相当于关闭 UAC)。

3.UAC触发条件

当用户或者应用在开始在涉及UAC的操作时弹出一个窗口，并且会黑屏询问你是否继续使电
脑处于“安全桌面”状态，如图所示。此时这个桌面具有System的权限，其他程序无任何权限进行操作。

（Windows系统中的安全桌面（Winlogon Desktop）：在Windows操作系统中，安全桌面是一个特殊的桌面环境，它与用户日常使用的应用程序桌面是隔离的。当系统需要进行敏感操作，如用户登录验证、用户账户控制（UAC）提示或某些安全相关的交互时，会切换到这个高度安全的桌面环境中。在这个环境下，只有经过认证的组件和进程能够运行，以防止恶意软件干扰验证过程或窃取敏感信息。例如，在显示UAC对话框时，背景会被淡化成灰色，所有非核心进程都会暂停执行，直到用户响应了安全桌面上的提示。）

以下操作会触发UAC

以管理员身份运行程序
配置 Windows Update
增加或删除用户账户
改变用户的账户类型
配置来宾(Guest)账户(Windows7和8.1)
改变UAC设置
安装ActiveX
安装或移除程序
安装设备驱动程序
设置家长控制
修改系统盘根目录、Program Files(x86和x64)目录或Windows目录
查看其他用户文件夹
配置文件共享或流媒体
配置家长控制面板
运行Microsoft Management Console控制台和以.msc为后缀名的程序（部分.mmc程序除外）
运行系统还原程序。
运行磁盘碎片整理程序。
运行注册表编辑器或修改注册表。
安装或卸载显示语言(Windows7)
运行Windows评估程序
配置Windows电源程序
配置Windows功能
运行日期和时间控制台
配置轻松访问

4.UAC用户登录过程

在整个Windows操作系统资源中会有一个ACL,这个ACL决定了各个不同权限的用户/进程能够访问不同的资源。当一个线程尝试访问某个对象时，当前的系统会先检查该线程所持有的访问令牌以及被访问对象的安全描述符中的DACL规则。如果安全描述符中不存在DACL规则，则当前系统会允许线程直接访问。图示为整个线程访问对象的流程。

正常来说，在我们使用账号登录操作系统之后会产生令牌，令牌会记载我们所拥有的权限。如果我们以管理员角色权限进行登录，会生成两份访问令牌，标准用户访问令牌和完全管理员访问令牌。

当我们登录的是Administrator用户的时候(已开启UAC),想在管理控制台中执行“添加或删除用户”操作，UAC会弹出“安全桌面”。可根据实际情况选择是或否，出现这种情况的原因是在访问之前，系统会先检查进程所持有的访问令牌以及被访问对象的安全描述符中的DACL规则，确保携带的令牌及规则正确无误。因为我们携带的访问令牌是权限最低状态下的受保护的管理员访问令牌，所以当进程请求触发了UAC操作的时候，UAC就会弹出通知，询问我们是否允许。单击“是”按钮，其实就向进程发送了我们的管理员访问令牌，使得管理员的状态由“受保护状态”变更为“提升状态”。通过提升状态下的管理员访问令牌即可对计算机执行更改操作。

假设登录的用户是标准用户，Windows会给用户分配一个标准用户访问令牌，要访问某个携带标准用户访问令牌的进程，在进程触发UAC操作的时候会弹出通知，让我们输入管理员密码，此时我们并不具备管理员访问令牌，通过输入管理员密码可获取管理员的访问令牌操作。输人管理员密码的过程本质上就是通过管理员凭据为标准用户提权。

5.UAC虚拟化

UAC虚拟化也称为重定向操作。当用户权限没有达到程序要求的权限时，就会进行重定向操作。虚拟化由两个部分构成，即文件虚拟化和注册表虚拟化。例如，如果一个程序试图写入
C:\Program Files\Contoso\Settings.ini
但用户没有写入那个目录的权限，这个写操作就会被重定向至
C:\Users\Username\AppData\Local\VirtualStore\Program Files\contoso\settings.ini
对于注册表，如果一个程序试图写入
HKEY_LOCAL_MACHINE\Software\Contoso,
它会被自动重定向至HKEY_CURRENT_USER\Sofware\Classes\VirtualStore\Machine\Software\Contoso
或者HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso

Windows安全认证机制

1.什么是认证

认证就是验证人员和对象身份的过程，其主要目的是验证人员和对象是不是真实用户在实际的网络环境中，通常使用加密操作来进行验证，只有使用用户才知道该加密操作的密钥，身份验证交换的服务器会通过比对签名和已知的加密密钥来进行身份验证尝试。在Windows操作系统中主要有NTLM认证（包括本地认证和网络认证）及Kerberos认证两种认证方式。

2.NTLM本地登录认证

当我们在Windows操作系统中创建用户的时候，该用户的密码会加密存储在一个SAM
(Security Account Manager,安全账号管理器)文件中，这是Windows操作系统用于管理用
户账户安全的一种机制。SAM文件的存储路径如下，
%SystemRoot%\system32\config\sam

我们可以将这个SAM文件理解成一个用于存储本地计算机所有用户登录凭据的数据库，所有用户的登录名及口令等数据信息都会保存在其中。该文件会将密码通过NTLM哈希的方式进行加密，然后存储在SAM文件中。存储在SAM文件中的密码均为加密过的哈希值。
当我们使用创建用户的身份登录系统时，系统会主动读取本地SAM文件所存的密码，并
与我们输人的密码进行校验。如果校验成功，则证明登录成功，反之则登录失败。所谓的本地认证过程其实是对用户输人的密码与SAM数据库里加密的哈希值比对的过程。如图所示

用户登录系统认证过程

4.哈希密码的存储方式

Windows操作系统不会存储用户输入的明文密码，而是将其进行加密并存储在SAM数据库中。当用户使用账号密码凭据登录时，系统会先将用户输人的账号密码凭据转换成NTLM哈希，然后将转换后的哈希与SAM数据库中的NTLM哈希进行校验，校验成功则证明登录成功，反之则登录失败。
在Windows操作系统中加密哈希的算法分为两种，一种是LM哈希加密算法，另一种是NTLM哈希加密算法，后者目前更为流行。

(1)LM哈希
LM哈希是早期Windows系统使用的密码存储方式，非常老旧。LM哈希作为很早之前使用的算法，存在着很多的问题和缺陷。Windows操作系统在不断迭代，从Windows Vista和Windows Server2008开始逐渐将LM哈希加密算法棒换为NTLM哈希加密算法。

(2)NTLM哈希
NTLM(NT LAN Manager)哈希是Windows为了安全性和兼容性而设计的哈希加密算法。微软为了解决LM哈希加密算法存在的诸多安全问题而在Windows NT3.1中引人了NTLM算法。目前Windows Vista和Windows Server2008以后的操作系统版本均默认开启了NTLM哈希算法

3.NTLM哈希算法原理

目前在大部分Windows操作系统中使用的密码哈希为NTLM哈希。NTLM哈希值是经过Hex、Unicode、MD4三层编码加密得到的一个由字母和数字组成的32位的哈希值。以下是NTLM哈希的具体算法。
1)将用户密码进行Hex编码，得到十六进制格式。
2)将得到的十六进制结果转换为Unicode编码。
3)使用MD4加密算法对Unicode转换的结果进行加密。

#coding:utf-8
import hashlib
import binascii
password ="123456"
binhex =binascii.b2a_hex(password)
print  "Hex加密结果："+ binhex
print  "Unincode转换结果"+ binhex.encode('utf-16le')
print  "MD4加密结果"  + binascii.hexlify(hashlib.new('md4',binhex.encode('utf-161e')).digest（）

4.本地登录认证流程

假设当 Windows操作系统进入登录页面时用户按下SAS按键序列(也就是Ctrl+Alt+Del)，这将使系统从默认桌面切换至 Winlogon桌面，并启动LogonUI来提示用户输入账号和密码等信息。在用户输人账号和密码信息以后，Winlogon会通过LsaLogonUser 将登录信息传递给身份验证程序包(MSV10),由MSV10身份验证程序包将登录用户账号和密码的哈希值发送至本地SAM Server数据库中进行匹配。如匹配成功，则向MSV10身份验证程序包返回获取到用户的SID及用户所属组的SID,并发送给LSA Server。LSA Server利用该唯一SD等信息创建安全访问令牌(访问令牌包括用户的SID、组SID及分配的权限)，然后将令牌的句柄和登录信息发送给Winlogon,由Winlogon继续执行该用户的登录过程，如图所示。

本地登录认证流程

5. NTLM 网络认证

1. NTLM 认证协议
NTLM基于挑战/响应验证机制，对域上主机进行身份验证。当用户主机请求访问与域关联的服务时，服务会向用户主机发送质询，要求用户主机使用其身份验证令牌进行验证，然后将此操作的结果返回给服务。该服务可以验证结果或将其发送到域控制器进行验证。如果服务或域控制器确认用户主机的身份令牌正确，则用户主机使用该服务。目前NTLM已经不被微软推荐，因为它不支持很多新型的加密方式，微软已经使用Kerberos认证协议作为首选的身份验证方式。

2.NTLM 认证流程
NTLM 是Windows网络认证协议中的一种，它以NTLM 哈希作为凭据的方式进行认证采用挑战/响应(Chalenge/Response)的消息交换模式。NTLM认证协议分三步走。
1)协商(Negotiate):主要用于确认双方协议版本。
2)质询(Question):就是挑战/响应。
3)验证(Auth):主要是在质询完成后验证结果。

3.NTLM 协议类型
NTLM 协议认证包含 NTLM v1和 NTLM v2 两个版本，其中使用最多的是 NTLM v2。

NTLM v1:NTLM v1协议是 NTLM 第一版协议，它在服务器与客户端之间的挑战/响应中同时使用 NT 哈希和LM 哈希。
NTLM v2:NTLM v2也可称为 NTLM 第二版协议，是 NTLM v1的改进版本，它通过强化认证协议及安全身份认证机制来提升NTLM的安全性。
NTLM v1与 NTLM v2 两者的区别在于 Challenge 和加密算法不同:NTLM v1的 Challenge有8位数值，主要加密算法为DES;NTLMv2的Challenge有16位数值，主要加密算法为HMAC-MD5.

4.NTLM 协议认证方式
NTLM协议的认证方式可以分成交互式NTLM身份验证和非交互式NTLM身份验证两类，具体说明如下。
(1)交互式NTLM 身份验证
交互式NTLM身份验证通常涉及用户请求身份验证的客户端系统、保留与用户密码相关信息的域控制器这两种系统，主要应用于用户登录客户端的场景。
(2)非交互式 NTLM 身份验证
非交互式NTLM身份验证通常涉及用于请求身份验证的客户端系统、保存资源的服务器、代表服务器进行身份验证计算的域控制器这三种系统，这种认证方式无须进行交互式提供凭据，用户只需成功登录一次就可以访问所有相互信任的应用系统及共享资源。

5.工作站环境中的 NTLM 工作机制

如图详细描述了NTLM 在工作站环境中的工作机制，

具体如下
1)用户输入账号和密码并登录客户端时，客户端会将用户的账号和密码转换为NTLM哈希并进行缓存，原始密码将会被丢弃(因Windows安全准则要求，原始密码在任何情况下都不能被缓存)。

2)当成功登录客户端的用户试图访问服务器的某个资源时，客户端就会向服务器发送Type1协商消息进行请求认证，该协商消息包含客户端支持和服务器请求的功能列表。

3)收到客户端发送的Type1协商消息认证请求后，服务器会生成一个16位数值的随机数，简称“质询”(Challenge)或“随机数”(Nonce)，并通过Type2 质询消息对客户端进行响应，该响应消息包含服务器支持同意列表以及由服务器产生的16位数值的Challenge 挑战码。

4)接收到服务器发来的Challenge 挑战码后，客户端使用之前转换缓存的NTLM 哈希对 Challenge进行加密运算，得到Response，并通过Type3身份验证消息回复服务器的质询。该身份验证消息包含 Response、Username 以及加密后的Challenge。

5)接收到由客户端加密的Challenge后，服务器会使用自己密码的NTLM哈希对Challenge 进行加密计算，得到 Net NTLM 哈希值，并与客户端发送的Net NTLM 哈希值进行匹配。如匹配成功，则证明客户端输人的密码正确，认证成功；反之，认证失败。

6.域环境中的NTLM工作机制

如图详细描述了 NTLM 在域环境中的工作机制

具体如下。
1)域用户输入账号和密码登录客户端时，客户端会将用户的账号和密码转换为NTLM哈希并进行缓存，原始密码将会被丢弃。

2)当成功登录客户端的用户试图访问服务器的某个资源时，客户端就会向服务器发送Type1协商消息进行请求认证，该协商消息包含客户端支持和服务器请求的功能列表。

3)收到客户端发送的Type1协商消息认证请求后，服务器会生成一个16位数值的随机数，并通过 Type2质询消息对客户端进行响应。该响应消息包含服务器支持同意列表以及由服务器产生的 16 位数值的 Challenge 挑战码。

4)接收到服务器端发来的Challenge 挑战码后，客户端使用之前转换缓存的NTLM 哈希对Challenge 进行加密运算，得到Response，并通过Type3 身份验证消息回复服务器的质询。该身份验证消息包含 Response、Username 以及加密后的Challenge。

5)接收到由客户端加密的 Challenge后，服务器会通过 Netlogon 协议向 DC(域控制器)发送针对客户端的验证请求，同时将Type1、Type2、Type3 全部发送给 DC。

6)DC根据Username从AD中查询该用户账号和密码的NTLM哈希，并将使用此NTLM 哈希加密 Challenge 得到的 NetNTLM 哈希值与服务器收到的 NetNTLM 哈希值进行比对和验证，最终将比对验证结果发送给服务器。

7)服务器根据DC反馈的结果对客户端进行最后的校验。

6.Kerberos 域认证

1.Kerberos 简介
Kerberos是由麻省理工学院(MIT)开发的网络身份验证协议，它的主要优势是可提供强大的加密和单点登录(SSO)机制。作为一种可信任的第三方认证服务，Kerberos通过传统的密码技术(如共享密钥)实现不依赖于主机操作系统的认证，不需要基于主机地址的信任，不要求网络上所有主机的物理安全。并在假定网络上传送的数据包可以被任意读取修改和插入数据的情况下保证通信安全

2.Kerberos 通信端口
1)TCP/UDP的88(Kerberos)端口:身份验证和票证授予
2)TCP/UDP的464端口:Kerberos Kpaswd(密码重设)协议
3)LDAP:389
4)LDAPS:636

3.Kerberos 专有名词

名词	作用
AS	身份认证服务(验证Client身份)
KDC	密钥分发中心(域内最重要的服务器，域控制器)
TGT	证明用户身份的票据(访问TGS的票据)
TGS	票据授权服务
ST	访问服务的票据
krbtgt	每个域中都有krbtgt账户，此账户是KDC服务账户在创建TGT时用来加密的，其密码是随机生成的
Principal	认证主体 Name[/Instance]@REALM
PAC	特权属性证书(用户的SID、用户所在的组)
SPN	服务主体名称
Session Key	临时会话密钥a，只有客户端和TGS知道，在Kerberos 认证中至关重要
Server Session Key	临时会话密钥b，只有客户端和服务端知道，在Kerberos 认证中至关重要
Authenticator	用SessionKey 加密，包含客户端主体名和时间戳，有效时间2分钟
Replay Cache	Kerberos5加人了Replay Cache，服务会缓存2分钟内收到的Authenticator，如果Authenticator 和缓存中的相同，则拒绝

4.Kerberos 角色组件

Kerberos 角色组件包含如下部分
1)KDC:KDC是ADDS(AD目录服务)的一部分，运行在每个控制器上。它向域内的用户和计算机提供会话票据和临时会话密钥，其服务账户为krbtgt。
2)AS:一个身份认证服务器，它执行初始身份验证并为用户颁发票据授予票据
3)TGS:票据授权服务，它根据用户身份票据权限来颁发服务票据。
4)客户端:需要访问资源(如查看共享文件、查询数据库或进行远程连接)的用户客户端在访问资源之前需要进行身份验证。
5)服务端:对应域内计算机上的特定服务，每个服务都有一个唯一的SPN。

5.Kerberos 认证流程概览

Kerberos是一种基于票据的认证方式。当客户端需要访问服务器的某个服务时，需要获得ST
(Service Ticket，服务票据)。也就是说，客户端在访问服务之前需要准备好ST，等待服务验证ST后才能访问。但是这张票据并不能直接获得，需要一张TGT(TicketGrantingTicket，票据授予票据)证明客户端身份。也就是说，客户端在获得ST之前必须先获得张证明身份的TGT。TGT和服务票据ST均是由KDC发放的。因为KDC运行在域控制器上，所以TGT和ST均是由域控制器颁发的。kerberos认证流程如下。

1)当用户登录时，使用NTLM哈希对时间截进行加密，以向KDC证明他知道密码此步骤被称为“预认证”
2)完成预认证后，认证服务器会向用户提供一张在有限时间内有效的TGT
3)当希望对某个服务进行身份验证时，用户将TGT呈现给KDC的TGS。如果TGT有效且用户具有该服务权限，则用户会从TGS接收ST。
4)用户可以将ST呈现给他们想要访问的服务。该服务可以对用户进行身份验证，并根据TGS中包含的数据做出授权决策。

6.Kerberos 认证流程详解

(1)AS-REQ和AS-REP(客户端与AS的交互)
1)AS-REQ。当域内的某个用户在客户端输入账号和密码、想要访问域中的某个服务时，客户端就会向AS发送一个Authenticator的认证请求，认证请求携带了通过客户端NTLM哈希加密的时间戳、用户名、主机IP，以及一些其他参数信息(如消息类型、版本号、协商选项等)，作为认证请求的凭影。因为需要验证AS是否为真，所以利用客户端的NTLM 哈希进行加密。如果AS为真。则会正常解密AS-REQ。

2)AS-REP。在KDC中的AS收到客户端AS-REQ请求后,KDC就会检查客户端用户是否在AD白名单中、如果在且使用读客户编用户的密钥对Authenticator预认证请求解密成功，AS就生成随机sessionKey(CT_SK)，使用用户密码的NTLM哈希对sessionKey(CT_SK)进行加密、并使用默认账户krbigt的NTLM哈希对sessionKey、客户端信息、客户端时间戳、认证到期时间进行加密，得到TGT，然后发送AS-REP响应包给客户端。

(2)TGS-REQ和TGS-REP(客户端与 TGS 的交互)
1)TGS-REQ。收到AS发来的响应包后，客户端会使用自己的NTLM 哈希对两部分密文内容进行解密，得到用于与TGS 通信的密钥sessionKey(CT-SK)及sessionKey Client缓存 TGT，随即客户端使用sessionKey(CT_SK)加密一个Authenticator 认证请求并发送给KDC中的TGS，以此来获取Server 的访问权限。Authenticator认证包含客户端主体名时间戳、客户端发送 SS 主体名、Lifetime、Authenticator 和 TGT。

2)TGS-REP。TGS在收到TGS-REQ发送的Authenticator认证请求后，会对其SS主体名进行验证。如果验证存在，TGS使用账户krbtgt的NTLM哈希对TGT进行解密并提取出 sessionKey，同时会就 TGT的过期时间、Authenticator 认证中的 Client 主体名和 TGI中是否相同等信息对客户端进行校验。校验通过后，TGS将会随机生成一个新的字符串sessionKey，并向客户端一同返回如下两部分内容。

旧sessionKey加密的SS 主体名、Timestamp(时间戳)、Lifetime(存活时间)、新sessionKey
通过 Server 哈希加密生成的票据，主要包括SS密钥加密的 Client 主体名、SS 主体名、
IP_List、Timestamp、Lifetime、新sessionKey。

(3)AP-REQ和AP-REP(客户端与服务端的交互)
1)AP-REQ。客户端收到TGS 回复以后，通过 sessionKey 解密得到 Server session Key并将其加密成一个Authenticator(包括Client主体名、Timestamp、ClientAuthenti-catorService Ticket)，然后发给SS(server)。

2)AP-REP。服务端收到由客户端发来的AP-REQ请求之后，会通过服务密钥对ST进行解密，并从中提取 Service sessionKey信息，同时就TGT的过期时间、Authenticator 认证中的Client主体名和TGT中是否相同等信息对客户端进行校验。校验成功后，服务端会检查在AP-REQ请求包中的协商选项配置是否要验证服务端的身份。如果配置了要验证服务端的身份，则服务端会对解密后的Authenticator再次使用ServicesessionKey进行加密，通过AP-REP响应包发送给客户端。客户端再用缓存的ServicesessionKey进行解密，如果和之前的内容完全一样，则证明自己正在访问的服务器和自己拥有相同的Service sessionKey。

更多Kerberos相关知识可参考

干货 | 全网最详细的Kerberos协议及其漏洞-腾讯云开发者社区-腾讯云 (tencent.com)