NTLM 和 Kerberos 安全认证过程简述

本文详细解析了NTLM与Kerberos两种网络认证协议的工作原理。NTLM采用质询/应答模式,涉及用户名验证、密码摘要信息认证及随机数加密对比等步骤。Kerberos则基于对称密钥密码学,通过KDC可信第三方验证用户名并颁发TGT,后续利用TGT请求服务票证ST,实现端到端安全性。

参考文件:http://www.cnblogs.com/artech/archive/2011/01/25/NTLM.html

NTLM采用一种质询/应答消息交换模式

1、身份认证用户名验证:客户端向服务器端发送用户名若用户名验证通过,服务器端生成随机数,然后向客户端发送该随机数字。

2、身份认证密码认证:(1)密码摘要信息认证:客户端软件利用MD5或者SHA哈希生成密码的摘要信息,并利用摘要对随机数字进行加密。(2)客户端发送利用摘要加密的随机数字给服务器端。

3、服务端向DC服务器请求相关信息进行验证:服务器向DC请求用户名相关信息包括用户名、密码摘要、存储的随机数字

4,安全验证通过与否测试:服务器端利用存储的用户密码的摘要信息,对随机数进行加密。然后将两个加密后的随机数字进行比较。如果两者相同,则通过用户身份认证。

参考文件:http://www.cnblogs.com/artech/archive/2011/01/24/kerberos.html

Kerberos 使用对称密钥密码学,并提供端到端的安全性。

KDC是kerberos认证的可信第三方;KDC维护所有网络成员的密钥;票证授予票证TGT理解为一张名片;

1、服务器端KDC.AS验证用户名,验证通过后,利用用户的密码作为密钥,加密TGT返回客户端。

2、客户端利用密码作为密钥解密TGT,然后发送TGT+某服务请求给KDC.TGS

3、KDC.TGS验证TGT信息后,然后向客户端返回ST,其中ST包含两个相同的SessionID+客户端用户的身份标识,第一个用KDC保存的用户共享密钥加密,第二个用KDC保存的某请求服务共享密钥加密。

4、客户端利用自己与KDC共享密钥解密,获取自己与某服务请求的服务器进行通信的会话密钥;接着添加自己的认证信息,然后将含两个认证信息的ST发送于某服务请求服务器。

5、某请求服务器利用自己与KDC共享密钥解密,获取自己与某服务请求的服务器进行通信的会话密钥;某请求服务器解密认证信息后与KDC存储认证信息进行比对 ,然后开始处理服务,并利用会话密钥加密返回给客户端。

<think>嗯,用户想要总结NTLMKerberos的认证流程,并绘制思维导图。首先,我需要先回忆这两种认证协议的基本流程区别。NTLM是微软早期的认证协议,基于挑战-响应机制,而Kerberos则更现代,基于票据机制,安全性更高。用户可能需要对比它们的步骤、优缺点以及适用场景。 首先,我应该先分别梳理两者的认证流程。NTLM的流程相对简单,分为协商、挑战验证三个阶段。客户端发送请求,服务器生成挑战值,客户端用密码哈希加密后返回,服务器验证。但NTLM可能存在中间人攻击的风险,而且效率较低,尤其是在跨域环境下。 Kerberos的流程更复杂,涉及KDC(密钥分发中心),包括AS_REQ、AS_REP、TGS_REQ、TGS_REP、AP_REQ、AP_REP等步骤。客户端先获取TGT,然后用TGT获取服务票据,最后用服务票据访问应用服务器。Kerberos支持双向认证票据的时效性,安全性更高,但需要时间同步KDC的高可用性。 接下来,用户可能需要对比两者的不同点,比如认证方式、安全性、效率、依赖条件等。例如,Kerberos使用对称加密票据,而NTLM使用挑战响应;Kerberos支持双向认证,NTLM不支持;Kerberos需要KDC,而NTLM依赖域控制器。 用户还提到要绘制思维导图,可能需要结构化的对比分步骤的流程说明。因此,回答中需要将流程分点列出,并明确各步骤的关键点。同时,引用部分提到了NTLMKerberos属于Windows集成验证机制,需要确保信息准确,可能参考已有的资料,比如引用[1]中的内容。 此外,用户可能希望了解在什么情况下选择哪种协议,比如内网环境可能更适合Kerberos,而旧系统可能仍使用NTLM。需要指出Kerberos在效率扩展性上的优势,以及NTLM的兼容性。 最后,生成相关问题时要围绕认证流程、对比、优化、应用场景等,帮助用户进一步深入理解。例如,如何优化Kerberos的部署,或者NTLM的安全风险如何缓解。</think># NTLM vs Kerberos 认证流程对比 ## 一、NTLM认证流程(三步握手) $$流程图: 客户端 \xrightarrow{协商请求} 服务端 \xleftarrow{挑战值} 客户端 \xrightarrow{加密响应} 服务端$$ 1. **协商**:客户端发送$NTLM_NEGOTIATE$消息 2. **挑战**:服务端生成$16字节随机数(Nonce)$[^1] 3. **响应**:客户端用$NT哈希值加密Nonce$返回 4. **验证**:域控制器通过$SAM数据库比对哈希$ ## 二、Kerberos认证流程(六步交互) $$流程图: 客户端 \leftrightarrow KDC \leftrightarrow TGS \leftrightarrow 应用服务器$$ 1. **AS_REQ**:请求$TGT(Ticket Granting Ticket)$ 2. **AS_REP**:获取$TGT+会话密钥(AES加密)$ 3. **TGS_REQ**:用$TGT申请服务票据$ 4. **TGS_REP**:获得$服务票据+服务会话密钥$ 5. **AP_REQ**:向应用服务器提交$服务票据$ 6. **AP_REP**:可选$双向验证$ ## 三、核心差异对比 | 维度 | NTLM | Kerberos | |--------------|-------------------------------|------------------------------| | 协议基础 | 挑战-响应机制 | 票据授权机制 | | 加密方式 | 仅客户端加密 | 全程对称加密(AES/DES) | | 认证方向 | 单向认证 | 支持双向认证 | | 时间敏感 | 不依赖时间同步 | 要求5分钟内时间同步 | | 跨域能力 | 需建立域信任 | 通过跨域TGT实现 | | 效率 | 每次访问都认证 | 票据8小时有效 | ## 四、思维导图设计建议 ``` 认证协议 ├─ NTLM │ ├─ 三阶段流程 │ ├─ 哈希传递风险 │ └─ 适用场景:旧系统/SMB协议 └─ Kerberos ├─ 六阶段流程 ├─ 黄金票据/白银票据攻防 └─ 适用场景:AD域/云环境 ``` ## 五、安全建议 1. Kerberos需部署$KDC冗余集群$保障可用性 2. NTLM应启用$NTLMv2并禁用LM响应$[^1] 3. 定期轮换$KRBTGT账户密码$(影响Kerberos票据有效性)
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值