Question

感谢阅读和思考;这是一个毛茸茸的问题，所以我想我会分享，看看对于经验丰富的开发人员来说，这对我们来说是否真的是一个公平的挑战。

我们正在为企业Microsoft Active Directory环境开发Web应用程序，我们使用IIS提供的Windows身份验证来验证用户的单点登录以及表单身份验证。我知道IIS在启用时都会抱怨，但它运行得很好，我们部署的每个站点都没有奇怪的怪癖可以解决 - 直到现在。

新网站拥有“共享”计算机，使用通用帐户永久登录，该帐户对他们需要使用的应用程序具有只读权限。这意味着我们无法区分应该对应用程序具有不同权限的用户;我们需要某种方式来提示用户提供身份验证详细信息。

首先尝试的是一些严肃的谷歌搜索;世界上没有其他人似乎有我们的问题，除了一些误入歧途的灵魂，他们向以太提问并没有得到回应。

经过一些头脑风暴和坚持IIS身份验证的工作方式后，解决问题的最直接方式似乎是发出401 Unauthorized以响应已知为共享帐户的用户。这里的初步测试似乎很有成效，在浏览器中成功更改了用户名，但是网站上的原型没有提示输入凭据，浏览器保留了相同的帐户详细信息。我们还点击了IE特定的javascript

document.execCommand("ClearAuthenticationCache")

再次在实验室工作但不在现场工作。现场IE安全设置的进一步实验表明，如果webapp站点被排除在Intranet区域之外，浏览器将自动重新进行身份验证，而不管用于欺骗浏览器提示用户提供新帐户详细信息的方法。

现在我们被困住了。我们有解决方案可以让它准时到达，但它们肯定不是“正确”的答案：

要求用户在登录我们的应用程序之前注销共享帐户（... yuck）
在所有计算机上从Intranet区域中排除我们的webapp
为用户提供非SSO登录服务

我确信有一种规范的方法可以做到这一点 - 一个已知的模式，一个已经解决的常见基础问题，类似的东西 - 我很想知道有哪些创新方法可以解决这种问题，如果其他任何人真的经历过类似的远程任何事情。

Answer 1

您是否可以创建拒绝共享帐户访问权限的页面。然后，在您需要用户使用非共享帐户重新进行身份验证的任何位置，重定向到该页面，并在查询字符串中编码返回URL？这应该触发浏览器建立通常的登录对话框。

用户重新验证后，新页面应该只重定向回查询字符串中的返回URL。

Answer 2

我们最终解决了向服务器知道的LDAP目录提交查询的解决方案。这意味着必须接受用户的密码，但没有其他解决方案足以在生产环境中运行。

希望这有助于某人。需要.NET Framework 3.5+。

using System.DirectoryServices.AccountManagement;

private static bool IsLdapAuthenticated(string username, string password)
{
    PrincipalContext context;
    UserPrincipal principal;

    try
    {
        context = new PrincipalContext(ContextType.Domain);
        principal = Principal.FindByIdentity(context, IdentityType.SamAccountName, username) as UserPrincipal;
    }
    catch (Exception ex)
    {
        // handle server failure / user not found / etc
    }

    return context.ValidateCredentials(principal.UserPrincipalName, password);
}

如何说服Internet Explorer允许身份验证为另一个用户？

2 个答案: