NTLM验证过程

简介:

参考文献:

Microsoft NTLM

Kerberos连接过程

正文

NTLM有Interactive和Noninteractive两种,Interactive就是用户登录类型的,只有client和DC两个参与者,而Noninteractive则是Client要去连接一个Server。Microsoft NTLM给出了NTLM的Noninteractive验证过程,有如下7步过程:

  1. (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.
  2. The client sends the user name to the server (in plaintext).
  3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
  4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.
  5. The server sends the following three items to the domain controller:

    • User name
    • Challenge sent to the client
    • Response received from the client
  6. The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
  7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

但是其中有些地方不够详细,我在本文中加以补充。NTLM是windows验证的一种,其过程如下图所示:

下面来详细解析NTLM验证过程,仍然是七步过程:

  1. 用户登录时输入的user name、password和domain name,然后Client端计算password的hash值并保存在本地
  2. 客户端将user name的明文发送给DC
  3. DC生成一个16-byte的随机数,叫做challenge,传输给client
  4. client收到challenge以后,在复制一份拷贝,然后将其中一个challenge用password hash加密,这个叫做response,然后将challenge,response以及user name传送给server
  5. server端在收到client传送过来的三份内容以后将它们转发给DC
  6. DC在收到user name,response,challenge以后,根据user name在account database中找到其对应的password hash,然后用这个password hash加密challenge
  7. 最后一步是客户端将response跟加密后的challenge进行比较,如果相同则NTLM验证成功。

Microsoft NTLM的最后还提到了另外一点,就是让我们不要直接使用NTLM,而是使用negotiate。如果使用negotiate的话,那么windows会判断kerberos是否可用,如果可用就优先使用kerberos,否则使用NTLM。kerberos的安全性要比NTLM要高。

在sharepoint的中就有NTLM和negotiate的选择,默认选择的是NTLM,如果知道如何配置kerberos的话,建议使用negotiate模式



本文转自xwdreamer博客园博客,原文链接:http://www.cnblogs.com/xwdreamer/archive/2012/08/23/2652541.html,如需转载请自行联系原作者


目录
相关文章
|
1月前
|
算法 数据安全/隐私保护 Python
数字签名是一种用于验证数据完整性和来源身份的技术。它基于公钥密码学,允许数据的发送方使用其私钥对数据进行签名,而接收方则可以使用发送方的公钥来验证签名的有效性。
数字签名是一种用于验证数据完整性和来源身份的技术。它基于公钥密码学,允许数据的发送方使用其私钥对数据进行签名,而接收方则可以使用发送方的公钥来验证签名的有效性。
|
3月前
|
安全 算法 数据安全/隐私保护
CSRF 实验:Token 不与 Session 绑定绕过验证
CSRF 实验:Token 不与 Session 绑定绕过验证
|
3月前
|
算法 数据安全/隐私保护
客户端验证 证书解析
客户端验证 证书解析
50 7
|
3月前
|
前端开发 安全 Go
CSRF 实验:更改请求方式绕过验证
CSRF 实验:更改请求方式绕过验证
|
3月前
|
存储 安全 Go
CSRF 实验:Token 不存在绕过验证
CSRF 实验:Token 不存在绕过验证
|
3月前
|
存储 SQL 安全
使用 BurpSuite 基于 Token 机制实施
使用 BurpSuite 基于 Token 机制实施
使用 BurpSuite 基于 Token 机制实施
|
10月前
|
分布式计算 安全 Java
有哪些方法可以验证kerberos keytab文件的有效性?
有哪些方法可以验证kerberos keytab文件的有效性?
|
数据安全/隐私保护
JMX安全漏洞修复 服务端增加用户名和密码验证机制
JMX安全漏洞修复 服务端增加用户名和密码验证机制
122 0
|
JSON 安全 关系型数据库
php传递url参数加密验证的解决方案(加密解密、安全验证过滤)
php传递url参数加密验证的解决方案(加密解密、安全验证过滤)
328 0
083.验证歌德巴赫猜想
083.验证歌德巴赫猜想
72 0