PrincipalContext.ValidateCredentials始终返回FALSE

Question

我有一个MVC应用程序，需要登录并根据Active Directory验证用户。我使用的是PrincipalContext.ValidateCredentials方法，但始终得到false的身份验证。

连接到服务器是正常的。问题似乎出现在ValidateCredentials中。

下面是我的代码：

public static bool IsAuthenticated(string domain, string username, string pwd) {
    bool IsAuthenticated = false;

    try {
        PrincipalContext insPrincipalContext = 
            new PrincipalContext(ContextType.Domain, domain, "DC=c1w,DC=com");

        username = "c1w\\" + username;

        IsAuthenticated = insPrincipalContext.ValidateCredentials(username, pwd);
    }
    catch (Exception ex)
    {
        // Rethrow this exception
        ExceptionPolicy.HandleException(ex, "Exception Policy");
    }

    return IsAuthenticated;
}

有人知道为什么会发生这种事吗？

Answer 1

我不明白你在哪里初始化"pwd“变量，也许你应该在这个方法中使用ContextOption来精确地指定所需的行为。很抱歉回答过于宽泛，但您的问题中没有太多细节

Answer 2

ValidateCredentials(string, string)的工作原理如下:首先，它尝试使用Negotiate、Signing和Sealing上下文选项进行身份验证。如果失败，它将使用SimpleBind和SecureSocketLayer重新尝试。

问题是，NT4 (又称“遗留”，又名“下层名称”)格式(DOMAIN\UserName，或者更准确地说，NetBiosName\SamAccountName)不能与Negotiate一起工作。但它确实适用于SimpleBind。

因此，在调用带有两个参数的ValidateCredentials()方法时，可能会发生的情况是，由于不喜欢NT4格式，它先是使用协商失败，然后在使用简单绑定时再次失败。

在我自己的测试中，我发现即使在退回到使用简单绑定之后，它仍然失败的原因是它不仅仅使用SimpleBind。它使用的是SimpleBind加上SecureSocketLayer。这意味着如果Active Directory服务器未正确设置为使用SSL (这是测试环境的常见场景)，它仍然会失败。

正如其中一条评论中提到的，你永远不会，永远不会想要单独使用SimpleBind (没有SecureSocketLayer)，否则你的密码将以纯文本的形式通过网络发送。

在野外，我看到一些Active Directory系统根本不允许使用简单绑定，所以您必须让它与协商一起工作。

我找到了两种方法来解决这个问题：

1)如果所有操作都发生在同一个域上，那么您应该能够仅使用用户名(SAM帐户名)调用ValidateCredentials，省略“域”部分。然后，它将在第一次使用协商时正常工作。

2)如果域部分很重要，因为可能涉及多个域(即Domain1\UserA和Domain2\UserA是不同的人)，那么它就会变得有点复杂。在本例中，我最终所做的是将用户名称(域\ NT4 )转换为“用户主体名称”格式(例如LogonName@domain.com)。有几种不同的方法可以做到这一点。最简单的方法可能是使用UserPrincipal.FindByIdentity()的3参数重载，然后获取结果的UserPrincipalName属性的值。另一种方法是使用DirectorySearcher并查询具有匹配sAMAccountName值的用户的userPrincipalName属性的LDAP://domain。注意:只有当所有涉及的域都在同一林中时，此解决方案才有效。

Answer 3

您似乎正在使用domain\userName格式验证用户。您可能需要从userName解析域名并使用ValidateCredential。