【问题标题】:PrincipalContext.ValidateCredentials stops validating after IIS deployment works fine in cassiniIIS 部署在 cassini 中正常工作后,PrincipalContext.ValidateCredentials 停止验证
【发布时间】:2011-11-15 09:19:34
【问题描述】:

我有以下代码 sn-p 来针对 AD 测试纯文本用户名/密码,如果我在 Visual Studio 中按 F5 并通过 WCFTestClient 尝试它,它工作正常,但是一旦我部署到 IIS 并尝试同样的函数,它永远不会为 ValidCredentials 返回 true;是否需要为运行应用程序池的身份设置一些安全方面的信息?

我尝试将应用程序池身份设置为我自己的帐户(域管理员)只是为了测试这是否是问题所在,但这也没有帮助,所以我对如何解决这个问题有点迷茫。

网站(自定义 API)已设置匿名访问。

try
{
    // create a "principal context" - e.g. your domain (could be machine, too) 
    using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, DomainName))
    {
        // validate the credentials
        if (pc.ValidateCredentials(UserName, Password))
        {
            IsValid = true;
            break;
        }
    }
}
catch (Exception)
{
    LoggingControler.LogWarning(null, "Unreachable Domain: " + Domain);
}

我又重温了一遍,这一切都归功于 Windows 中的权限。网络服务不知何故没有足够的权限来执行PrincipalContext.ValidateCredentials。如果我将应用程序池身份更改为域管理员的身份,代码就可以工作。

如果有人能告诉我如何设置一个具有适当权限的受限用户帐户来执行PrincipalContext.ValidateCredentials,我可以完成这个。

【问题讨论】:

    标签: c# iis active-directory


    【解决方案1】:

    好的,我终于通过https://stackoverflow.com/questions/5140377/query-activedirectory-sometimes-not-working-asp-net-chttps://elgg.leeds.ac.uk/webteam/weblog/15385.html 找到了自己的答案

    正如我所发现的,“网络服务”应用程序池身份是解决这个问题的关键......

    添加读取权限无效;所以还有其他问题。

    【讨论】:

    • 即使您授予“网络服务”权限以读取 C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys,AD 本身也可能只允许通过域帐户进行查询.无法将 App Pool 的身份更改为域帐户的原因是什么?
    【解决方案2】:

    您是否启用了Windows Authentication in IIS

    【讨论】:

    • 不,它需要在没有的情况下工作;我手动验证凭据。我又重温了一遍,这一切都归功于 Windows 中的权限。网络服务不知何故没有足够的权限来执行 PrincipalContext.ValidateCredentials。如果我将应用程序池身份更改为域管理员的身份,代码就可以工作。
    猜你喜欢
    • 1970-01-01
    • 2015-07-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-09-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多