AD认证:Kerberos 和 NTLM

AD认证主要用到两种协议:Kerberos 和 NTLM

NTLM

认证过程如下:

  1. client本地生成NTLM hash,值为用户密码的hash值。

  2. client发送用户名给应用服务器。

  3. 应用服务器随机生成一个值给client,这个值通常叫nonce或challenge。

  4. client用NTLM hash对nonce进行加密,并发送给应用服务器。

  5. 应用服务器收到后,连同用户名和nonce一并发送给AD服务器。

  6. AD根据该用户的密码生成NTLM hash,并对nonce进行加密,然后对client发送的进行比对。

  7. 若值相同,则通过认证,若不同,则认证失败。

Kerberos

关键名词:

  1. KDC:Key Distribution Center,密钥发行中心,提供两个服务:身份验证服务(Authentication Service 简称AS)和Ticket-Granting Service(TGS)。域会为KDC生成名为krbtgt的域账户,TGT的加密解密均使用该账户的密码。域用户首次访问时,会想AS进行身份验证,通过后,AS请求TGS向域用户提供票证(TGT)。

  2. SPN:Service Principal Name。AD账户除了用

<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票据有效性)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值