9

通过搜索 Windows 身份验证方法和协议，我决定了解在一个简单的可执行文件中使用的 Negotiate、Kerberos 和 NTLM 之间的确切区别，然后再将其与 IIS 和 Web 身份验证一起使用。

我取得了很好的结果，但我仍然需要有关 Negotiate 和 Kerberos 的更多详细信息。

我有以下情况：

我创建了一个非常简单的 C# windows 窗体应用程序，它显示一个消息框，显示以下值：

System.Security.Principal.WindowsIdentity.GetCurrent().AuthenticationType

请注意，我是本地计算机上具有管理员权限的域用户，我有以下结果：

  1. 当我在主动连接到 DC 时运行 exe 文件（双击）时，我得到了“协商”。

  2. 当我在主动连接到 DC 时运行 exe 文件（以不同用户身份运行/使用本地用户）时，我得到了“NTLM”。

  3. 当我使用“以管理员身份运行”或“以不同用户身份运行”运行 exe 文件时，我得到了“Kerberos”。

  4. 当我使用本地帐户在本地登录时运行 exe 文件时，我得到了“NTLM”。

我了解 LSA 将对本地帐户使用NTLM。此外，我了解 Active Directory 使用Kerberos对域用户和计算机进行身份验证。

我的问题是，为什么当我通过（双击）使用我的帐户运行 exe 或使用我的相同帐户“以不同用户身份运行”时，我得到协商身份验证类型？

更新：我注意到以下内容：

- 如果本地用户正在运行 exe，那么它是NTLM
- 如果域用户运行 exe，那么它是Negotiate（如果该用户是本地管理员）但是是Kerberos（如果该用户不是本地管理员)
- 如果域管理员运行 exe，那么它是Kerberos

我只是澄清一下这种行为。

4

1 回答 1

7

首先，（您似乎在问题中理解，但只是为了清楚）EXE 没有任何身份验证 - 它只是一个可执行文件。操作系统创建一个进程对象，该对象在主体标识的登录会话中执行它。正是这个主体已经通过 NTLM 或 Kerberos（或其他协议）进行了身份验证。

接下来，协商意味着在创建登录会话时协商身份验证包用于决定将使用哪个身份验证包（Kerberos 或 NTLM）。

当您查询该WindowsIdentity.AuthenticationType值时，您最终会调用本地安全机构 (LSA) 中名为LsaGetLogonSessionData. 这将报告用于运行您正在执行的进程的登录会话的详细信息。创建此登录会话的方式可能对用于验证凭据的身份验证包影响最大。

首次登录 Windows 时，Winlogon.exe通过调用LsaLogonUser建立交互式登录。它按顺序查询身份验证包，HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages直到找到可以对给定凭据进行身份验证的包。建立交互式登录后，您可以使用不同凭据下的非交互式登录创建新进程，在这种情况下，LogonUser可能会调用该函数。此函数的参数之一是dwLogonProvider具有以下默认值（可能是使用的参数）：

LOGON32_PROVIDER_DEFAULT 

Use the standard logon provider for the system. 
The default security provider is negotiate, unless you pass NULL 
for the domain name and the user name is not in UPN format. 
In this case, the default provider is NTLM.

因此，为进程运行的登录会话报告的包取决于登录会话的创建方式。（从您的问题中不清楚您究竟是如何创建您正在测试的登录会话......在所有情况下都执行“运行方式”？在某些情况下注销/登录 Windows？）它还取决于 Winlogon 能够使用哪个包交互式登录会话的第一个成功验证。最后，请注意，身份验证机制都调用了一些身份验证包，如果使用协商，则首选 Kerberos，尽管报告的是协商。

这是一个旧但仍然相关的图表，它显示了所有身份验证如何在 Windows 中组合在一起：

Windows 身份验证体系结构

来源

于 2016-03-27T08:44:29.840 回答