下载掌阅APP，畅读海量书库
立即打开
认证就是验证人员和对象身份的过程，其主要目的是验证人员和对象是不是真实用户。在实际的网络环境中，通常使用加密操作来进行验证，只有使用用户才知道该加密操作的密钥，身份验证交换的服务器会通过比对签名和已知的加密密钥来进行身份验证尝试。在Windows操作系统中主要有NTLM认证（包括本地认证和网络认证）及Kerberos认证两种认证方式，接下来详细介绍。
1.NTLM本地登录认证
当我们在Windows操作系统中创建用户的时候，该用户的密码会加密存储在一个SAM（Security Account Manager，安全账号管理器）文件中，这是Windows操作系统用于管理用户账户安全的一种机制。SAM文件的存储路径如下，另见图1-19。
图1-19 SAM文件的存储路径
我们可以将这个SAM文件理解成一个用于存储本地计算机所有用户登录凭据的数据库，所有用户的登录名及口令等数据信息都会保存在其中。该文件会将密码通过NTLM哈希的方式进行加密，然后存储在SAM文件中。存储在SAM文件中的密码均为加密过的哈希值，如图1-20所示。
当我们使用创建用户的身份登录系统时，系统会主动读取本地SAM文件所存的密码，并与我们输入的密码进行校验。如果校验成功，则证明登录成功，反之则登录失败。所谓的本地认证过程其实是对用户输入的密码与SAM数据库里加密的哈希值比对的过程，如图1-21所示。
图1-20 NTLM哈希值
图1-21 用户登录系统认证过程
2.哈希密码的存储方式
Windows操作系统不会存储用户输入的明文密码，而是将其进行加密并存储在SAM数据库中。当用户使用账号密码凭据登录时，系统会先将用户输入的账号密码凭据转换成NTLM哈希，然后将转换后的哈希与SAM数据库中的NTLM哈希进行校验，校验成功则证明登录成功，反之则登录失败。
在Windows操作系统中加密哈希的算法分为两种，一种是LM哈希加密算法，另一种是NTLM哈希加密算法，后者目前更为流行。
（1）LM哈希
LM哈希是早期Windows系统使用的密码存储方式，非常老旧。LM哈希作为很早之前使用的算法，存在着很多的问题和缺陷。Windows操作系统在不断迭代，从Windows Vista和Windows Server 2008开始逐渐将LM哈希加密算法替换为NTLM哈希加密算法。
（2）NTLM哈希
NTLM（NT LAN Manager）哈希是Windows为了安全性和兼容性而设计的哈希加密算法。微软为了解决LM哈希加密算法存在的诸多安全问题而在Windows NT 3.1中引入了NTLM算法。目前Windows Vista和Windows Server 2008以后的操作系统版本均默认开启了NTLM哈希算法。
3.NTLM哈希算法原理
目前在大部分Windows操作系统中使用的密码哈希为NTLM哈希。NTLM哈希值是经过Hex、Unicode、MD4三层编码加密得到的一个由字母和数字组成的32位的哈希值。以下是NTLM哈希的具体算法。
1）将用户密码进行Hex编码，得到十六进制格式。
2）将得到的十六进制结果转换为Unicode编码。
3）使用MD4加密算法对Unicode转换的结果进行加密。
4.本地登录认证流程
假设当Windows操作系统进入登录页面时用户按下SAS按键序列（也就是Ctrl+Alt+Del），这将使系统从默认桌面切换至Winlogon桌面，并启动LogonUI来提示用户输入账号和密码等信息。在用户输入账号和密码信息以后，Winlogon会通过LsaLogonUser将登录信息传递给身份验证程序包（MSV1_0），由MSV1_0身份验证程序包将登录用户账号和密码的哈希值发送至本地SAM Server数据库中进行匹配。如匹配成功，则向MSV1_0身份验证程序包返回获取到用户的SID及用户所属组的SID，并发送给LSA Server。LSA Server利用该唯一SID等信息创建安全访问令牌（访问令牌包括用户的SID、组SID及分配的权限），然后将令牌的句柄和登录信息发送给Winlogon，由Winlogon继续执行该用户的登录过程，如图1-22所示。
图1-22 本地登录认证流程
1.NTLM认证协议
NTLM基于挑战/响应验证机制，对域上主机进行身份验证。当用户主机请求访问与域关联的服务时，服务会向用户主机发送质询，要求用户主机使用其身份验证令牌进行验证，然后将此操作的结果返回给服务。该服务可以验证结果或将其发送到域控制器进行验证。如果服务或域控制器确认用户主机的身份令牌正确，则用户主机使用该服务。目前NTLM已经不被微软推荐，因为它不支持很多新型的加密方式，微软已经使用Kerberos认证协议作为首选的身份验证方式。
2.NTLM认证流程
NTLM是Windows网络认证协议中的一种，它以NTLM哈希作为凭据的方式进行认证，采用挑战/响应（Challenge/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；NTLM v2的Challenge有16位数值，主要加密算法为HMAC-MD5。
4.NTLM协议认证方式
NTLM协议的认证方式可以分成交互式NTLM身份验证和非交互式NTLM身份验证两类，具体说明如下。
（1）交互式NTLM身份验证
交互式NTLM身份验证通常涉及用户请求身份验证的客户端系统、保留与用户密码相关信息的域控制器这两种系统，主要应用于用户登录客户端的场景。
（2）非交互式NTLM身份验证
非交互式NTLM身份验证通常涉及用于请求身份验证的客户端系统、保存资源的服务器、代表服务器进行身份验证计算的域控制器这三种系统，这种认证方式无须进行交互式提供凭据，用户只需成功登录一次就可以访问所有相互信任的应用系统及共享资源。
5.工作站环境中的NTLM工作机制
图1-23详细描述了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哈希值进行匹配。如匹配成功，则证明客户端输入的密码正确，认证成功；反之，认证失败。
图1-23 工作站环境中的NTLM工作机制
6.域环境中的NTLM工作机制
图1-24详细描述了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反馈的结果对客户端进行最后的校验。
图1-24 域环境中的NTLM工作机制
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专有名词
Kerberos的专有名词见表1-6。
表1-6 Kerberos专有名词
4.Kerberos角色组件
如图1-25所示，Kerberos角色组件包含如下部分。
1）KDC：KDC是ADDS（AD目录服务）的一部分，运行在每个域控制器上。它向域内的用户和计算机提供会话票据和临时会话密钥，其服务账户为krbtgt。
2）AS：一个身份认证服务器，它执行初始身份验证并为用户颁发票据授予票据。
3）TGS：票据授权服务，它根据用户身份票据权限来颁发服务票据。
4）客户端：需要访问资源（如查看共享文件、查询数据库或进行远程连接）的用户。客户端在访问资源之前需要进行身份验证。
5）服务端：对应域内计算机上的特定服务，每个服务都有一个唯一的SPN。
图1-25 Kerberos角色组件
5.Kerberos认证流程概览
Kerberos是一种基于票据的认证方式。当客户端需要访问服务器的某个服务时，需要获得ST（Service Ticket，服务票据）。也就是说，客户端在访问服务之前需要准备好ST，等待服务验证ST后才能访问。但是这张票据并不能直接获得，需要一张TGT（Ticket Granting Ticket，票据授予票据）证明客户端身份。也就是说，客户端在获得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）进行加密，并使用默认账户krbtgt的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主体名和TGT中是否相同等信息对客户端进行校验。校验通过后，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-cator、Service Ticket），然后发给SS（server）。
2）AP-REP。服务端收到由客户端发来的AP-REQ请求之后，会通过服务密钥对ST进行解密，并从中提取Service sessionKey信息，同时就TGT的过期时间、Authenticator认证中的Client主体名和TGT中是否相同等信息对客户端进行校验。校验成功后，服务端会检查在AP-REQ请求包中的协商选项配置是否要验证服务端的身份。如果配置了要验证服务端的身份，则服务端会对解密后的Authenticator再次使用Service sessionKey进行加密，通过AP-REP响应包发送给客户端。客户端再用缓存的Service sessionKey进行解密，如果和之前的内容完全一样，则证明自己正在访问的服务器和自己拥有相同的Service sessionKey。