集成 Windows 身份验证和SSL协议

发布于 2024-08-07 21:33:40 字数 313 浏览 8 评论 0原文

我的 Intranet 上有一个管理网站,当前通过 IIS 使用集成 Windows 身份验证。我们希望将此应用程序移至公共网站并使用 SSL 对其进行保护,以便我们的用户可以从任何地方访问它。

我一直计划使用 HttpModule 从 http 重定向到 https,但看起来这不适用于集成身份验证(登录弹出窗口出现在重定向之前)。

我是否被困在 IIS 中使用“需要 SSL”复选框?这似乎对用户不太友好,因为如果用户忘记使用 https URL,他们会得到一个漂亮的胖错误页面,而不是温和的重定向。

在这种情况下你会怎么做?

I have an administrative website on our intranet that currently uses Integrated Windows Authentication through IIS. We would like to move this application to a public website and secure it with SSL so our users can access it from anywhere.

I had been planning on using an HttpModule to redirect from http to https, but it doesn't look like this works with integrated authentication (the login popup appears before the redirect).

Am I stuck using the "require SSL" checkbox in IIS? This doesn't seem all that user friendly since the user gets a nice fat error page instead of a gentle redirect if they forget to use the https URL.

What would you do in this situation?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

姐不稀罕 2024-08-14 21:33:40

我每次都将其作为 IIS 问题解决,而不是代码问题:

  • 在 IIS 中创建一个新网站
  • ,将其绑定到相同的 IP 地址(和/或主机标头)、SSL 证书和端口 443,将
  • 其配置为指向与当前端口 80 站点
  • 测试相同的应用程序根目录,以确保直接连接到 https://site 给出预期响应
  • 重新配置原始站点(仍绑定到端口 80)以使用 HTTP 重定向功能
  • 将端口 80 站点配置为重定向到端口 443 站点; (可选)删除应用程序和虚拟目录映射(以防有人意外禁用重定向)

从那时起,任何只需在浏览器中键入网站地址的用户都将收到来自 IIS 的快速重定向消息,该消息会将其发送到 SSL - 网站的受保护版本。

I've solved this as an IIS problem every time, not a code problem:

  • create a new web site in IIS
  • bind it to the same IP address (and/or host header), to your SSL cert and to port 443
  • configure this to point to the same application root as the current port 80 site
  • test to make sure that directly connecting to https://site gives the expected responses
  • reconfigure the original site (still bound to port 80) to use the HTTP Redirect feature
  • configure the port 80 site to redirect to the port 443 site; optionally, remove the application and virtual directory mappings (in case someone accidentally disables the redirect)

From then on, any user that just types the web site address into their browser will get a lightning-fast redirect message from IIS that sends them to the SSL-protected version of the site.

十年不长 2024-08-14 21:33:40

我们的 Intranet 站点上也遇到了类似的问题,最终从集成 Windows 身份验证切换到直接在站点上请求其网络用户名/密码。这样我们就可以将它们重定向到 HTTPS 或其他类似的东西,而不必担心身份验证弹出窗口何时出现。

我们有一些与此类似的代码(假设您使用的是 ASP.NET)来对用户进行身份验证,然后我们将身份验证状态存储在 cookie 中。

public static bool AuthenticateUser(string username, string password)
{
    System.DirectoryServices.DirectoryEntry _entry = new System.DirectoryServices.DirectoryEntry(ldap_path, username, password, System.DirectoryServices.AuthenticationTypes.Delegation);

    bool _authenticated = false;
    try
    {
        Object _o = _entry.NativeObject;
        _authenticated = true;
    }
    catch
    {
        _authenticated = false;
    }
    finally
    {
        // Avoids the "multiple connections to server not allowed" error.
        _entry.Close();
        _entry.Dispose();
    }

    return _authenticated;
}

通过在应用程序中处理所有身份验证而不是依赖 IIS,它最终为我们节省了大量的麻烦和挫败感。

We had similar issues on our intranet site and ended up switching from Integrated Windows Authentication to requesting their network username/password directly on the site. That way we can redirect them to HTTPS or other such things without worrying about when the authentication popup shows up.

We have some code similar to this (assuming you're using ASP.NET) that authenticates the user, and then we store the authentication state in a cookie.

public static bool AuthenticateUser(string username, string password)
{
    System.DirectoryServices.DirectoryEntry _entry = new System.DirectoryServices.DirectoryEntry(ldap_path, username, password, System.DirectoryServices.AuthenticationTypes.Delegation);

    bool _authenticated = false;
    try
    {
        Object _o = _entry.NativeObject;
        _authenticated = true;
    }
    catch
    {
        _authenticated = false;
    }
    finally
    {
        // Avoids the "multiple connections to server not allowed" error.
        _entry.Close();
        _entry.Dispose();
    }

    return _authenticated;
}

It ended up saving us tons of headache and frustration by handling all authentication in the application rather than depending on IIS.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文