如何验证WindowsIdentity实例？

Question

我正在尝试在我的WPF客户端/服务器（WCF）应用程序中使用Windows Identity Foundation进行授权，该应用程序可能在与提供身份验证的活动目录相同的信任环境中运行也可能不运行。例如，可以由活动目录提供身份验证，但应用程序可以在云中运行，应用程序的用户配置文件角色/权限将由应用程序数据库提供。

我觉得我错过了WIF过程的一个基本部分，以便完全理解我应该做的事情：

1. 用户使用Active Directory用户名/密码登录Windows域
2. 用户打开我的应用程序。
3. 我引用登录用户的WindowsIdentity，现在可以查看他们的登录令牌及其所有配置的角色/声明 - 但就像他们可以登录到域一样，他们可以登录到他们自己的计算机，并且仍然可以WindowsIdentity令牌。
4. 我可以将用户的Windows标识绑定到我的数据库中的用户配置文件，并授予他们访问我的应用程序中他们的配置文件允许的特定功能的权限。

我缺少的是我有来自WindowsIdentity.GetCurrent（）的WindowsIdentity实例...如何验证生成此内容的内容？即，它是本地计算机用户还是活动目录用户，如果它是活动目录用户，我怎么知道它是我的真正的活动目录服务器？

例如 - 几个场景：

情景1

1. 用户将其本地计算机命名为与我的活动目录域相同的名称
2. 用户在该计算机上创建一个本地用户，其用户名与我们在我的活动目录中存在的用户具有相同的用户名，该用户对我的应用程序具有完全管理访问权限。
3. 他们登录我的应用程序，出于所有密集目的，他们似乎具有相同的用户名，就像管理用户登录到我的活动目录一样。

在这种情况下，用户具有本地用户帐户而不是活动目录帐户，并且它具有为有目的地环绕应用程序安全性而创建的欺骗标识。

我认为有一些方法可以确定这是Windows本地用户帐户而不是Active Directory用户？我可以使用WindowsIdentity中找到的用户名调用我的活动目录，并比较SID以确定这实际上是一个欺骗性用户帐户，并且应该拒绝用户访问。

这是正确的方法吗？我可以通过某种方式告诉WindowsIdentity它是由我的活动目录发出的，而且这个身份还没有被篡改过吗？

场景2

1. 用户创建一个与我的活动目录同名的欺骗性Active Directory服务器，并创建一个帐户，模仿与方案1中描述的本地用户相同的过程。

现在我有一个具有相同域名和用户名的活动目录用户，我为场景1建议的相同解决方案也可以解决此场景的问题，但确定此令牌未创建将再次很好通过检查令牌，通过我的活动目录。

有人可以清理我所缺少的东西 - 或者我是否遗漏了任何东西？我应该只是打电话给Active Directory来验证提供的WindowsIdentity是否允许访问我的应用程序？

Answer 1

简单回答： 您的活动目录不仅仅是名称。当您的计算机加入域时，它会交换一组凭据。欺骗活动目录或任何其他计算机要比仅创建具有相同名称的计算机困难得多。 Windows负责机器之间的所有幕后身份验证。除了错误和漏洞之外，你可以非常肯定，当你调用WindowsIdentity.GetCurrent（）时，有一个不间断的推力链，由不同的凭据支持，以验证用户。

更完整的答案： 有两种类型的Windows身份验证：

1. 第一种类型是网络中的对等体（即域外）。在这种情况下，当计算机A中的用户连接到计算机B时，它实际上使用B的本地用户。如果B中的用户恰好具有与A中的用户相同的名称和密码，则认证在没有用户干预的情况下发生。如果不是，则出现登录屏幕并且用户需要为B中的某个用户提供凭证。在任何情况下，用户实际登录到计算机B，并且B不需要信任或知道计算机A中的本地使用。
2. 第二种类型在域中。我相信，如果计算机本身属于域的一部分，或者与域具有信任关系的域，则只能添加域中的用户。在任何情况下，计算机B将具有允许其验证域控制器的不同凭证集。现在，当来自计算机A的用户想要登录计算机B时，要求域控制器（它知道并信任）对用户进行认证。一旦从域控制器获得OK，就会接受用户。

Windows支持各种身份验证协议，比其他协议更新，更强大。网络管理员配置接受哪些协议。大多数（全部？）协议不涉及通过网络发送实际密码（查看digest authentication以获取此类协议的示例或阅读the old NTLM protocols）