C#基础系列08 - NTLM 基础学习续集 - NTLM性能问题初探

本文探讨NTLM验证中的性能问题,特别是在域环境中。NTLM通过Netlogon服务与目录服务交互,当存在大量并发请求、复杂域架构、网络问题或服务器性能问题时,可能导致性能瓶颈。常见场景包括Secure Channel损坏、网络端口耗尽等。解决方法包括调整Netlogon的MaxConcurrentApi参数,以及针对特定场景的故障排查和修复。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

接上篇 : NTLM 基础学习

这次探讨一下NTLM验证中较少出现的性能问题.  在国外大型企业以及微软官方可以见到类似的文章和分享, 国内中文内容和分享比较少. 我们做个尝试, 抛砖引玉;

NTLM和Kerberos是当前 Windows 体系主要的两种认证协议.  Linux/Mac 等也很早开始支持这两种协议.  加上当前移动设备迅猛增加, 移动端的应用普遍的采用了兼容性较好的NTLM协议, 比如iPhone/Android基于ActiveSync的邮件应用, 比如系统自带的基于802.1x的有线/无线Radius认证<mschapv2默认使用NTLM>. 以上这些, 造就了NTLM在企业内外大量使用, 带来便利的同时,也带来了大量的安全隐患和稳定性隐患<性能瓶颈>. 

安全性隐患在上篇已经有所涉及, 我们不再展开. 稳定性隐患<性能瓶颈>较少遇到, 那么什么时候会发生NTLM的性能瓶颈? 很多朋友也会问,NTLM不就是个认证, 性能瓶颈从哪里来的? 要回答这两个问题, 我们重新回忆一下NTLM的过程和相关知识点: 

 

1首先是NTLM身份验证基本过程

NTLM验证是一种Challenge/Response 验证机制,由三种消息组成:通常称为type 1(协商),类型type 2(质询)和type 3(身份验证)。

它基本上是这样工作的:

  1. 用户登录客户端电脑
  2. (type
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值