具有集成 Windows 身份验证的 Extranet
在 Extranet 上使用 Windows Integrated Security 是否可能、安全且实用？
例如，Intranet 上有一个 IIS 网站，可以通过 LAN 使用集成身份验证。当用户与 LAN 断开连接时，他希望能够使用已加入域的笔记本电脑上的浏览器通过互联网（无 VPN）连接到同一网站，而无需单独登录。
Is it possible, safe and practical to use Windows Integrated Security on an Extranet?
E.g. there is an IIS website on the intranet that can be used over the LAN with integrated authentication. When the user disconnects from the LAN he wants to be able to use the browser on his domain-joined-notebook to connect to the same website over the internet (no VPN) without having to logon separately.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是否“安全”的问题是您在 Internet 场景中使用户面临哪些额外的安全威胁，而他们在 Intranet 场景中没有遇到这些威胁。此外，您是否使服务器面临额外的安全威胁 - 并假设问题不是“是否允许从 Internet 访问服务器”，而是“我们应该允许该服务器现在暴露于哪些身份验证方法” -the-Internet”，这个次要问题归结为“使用 Windows 集成身份验证协议更好还是要求使用基本证书、摘要证书或数字证书更好”？
对用户/客户端的安全威胁：用户的凭据是否受到合理保护，免受“从线路中嗅探”的攻击者的侵害？ Windows 集成身份验证使用 NTLM 或 Kerberos；在外联网场景中，用户/客户端通常不能依赖 Kerberos，因为这也需要从 Internet 透明访问 KDC（即 Active Directory 域控制器）。虽然这是可以做到的，但具有安全意识的组织允许这样做的情况并不常见。因此，我们讨论的是 NTLM - 它使用从服务器发送的“随机数”（随机字符集）对用户密码进行哈希处理，以便用户的密码不会以明文形式通过网络出现。将 NTLM 与 Basic 进行比较，这是明显的胜利；将 NTLM 与摘要式身份验证进行比较，它在某种程度上是等效的；将 NTLM 与客户端证书身份验证进行比较，证书总是在安全性方面获胜（但在部署/引导挑战方面失败）。通常，您会发现您的安全或服务器管理员希望对暴露于 Internet 的 IIS 侦听器使用 SSL 证书，以便更好地保护用户的凭据免受“嗅探器”的攻击。 SSL 并不完美，并且不能防止中间更复杂的攻击者（或客户端设备上有特洛伊木马/僵尸程序的人），但它的成本非常低，可以让您多一层安心。 SSL + NTLM 是许多人做出的合理选择。
服务器面临的安全威胁：服务器暴露给试图访问经过身份验证的资源的未经授权的攻击者。如果服务器允许任何 AD 验证的身份验证协议，那么它同样容易（或不会）受到试图暴力破解用户密码的攻击，以及某种针对重复错误密码发出警报的 IDS 解决方案建议进行尝试（但要将信噪比降低到可管理的水平是一个相当大的挑战）。服务器还存在这样的可能性：任何可利用的漏洞（主要是 IIS 中的漏洞，或通过防火墙暴露的任何其他漏洞）都可能被外部攻击者用来获得对服务器的特权访问。最好做好频繁打补丁的准备。其他不太可能但听起来很可怕的安全威胁也是可能的，但这是首先要解决的大问题。
The question of whether it's "safe" is a question of what additional security threats you're exposing the user to in the Internet scenario, that they weren't exposed to in the Intranet scenario. Additionally, are you exposing the server to additional security threats - and assuming that the question isn't "whether to allow access to the server from the Internet" but rather "which authentication methods should we allow for this server-now-exposed-to-the-Internet", this secondary question boils down to "is it better to use Windows integrated authentication protocols or require the use of Basic, Digest or digital certificates"?
Security threats to user/client: are the user's credentials reasonably protected from attackers who "sniff them from the wire"? Windows-integrated authentication uses either NTLM or Kerberos; in extranet scenarios, the user/client can't generally rely on Kerberos, since that would require transparent access to a KDC (i.e. an Active Directory domain controller) from the Internet as well. While this can be done, it's unusual to see a security-conscious organization allow that. So we're talking about NTLM - which hashes the user's password with a "nonce" (random set of characters) that are sent from the server, so that the user's password doesn't appear in plaintext over the wire. Compare NTLM to Basic and it's a clear win; compare NTLM to Digest authentication, and it's somewhat equivalent; compare NTLM to client certificate authentication, and certs always win for security (but lose on the deployment/bootstrapping challenges). Generally you'll find your security or server admins will want to use an SSL certificate for the IIS listener that's exposed to the Internet, so that user's credentials are even more protected against "sniffers". SSL is hardly perfect and doesn't protect against more sophisticated attackers in the middle (or someone who has a trojan/bot on the client device), but it costs very little for an extra layer of peace of mind. SSL + NTLM is a reasonable choice made by many.
Security threats to server: server is exposed to unauthorized attackers trying to gain access to authenticated resources. If the server allows any AD-authenticated authentication protocols then it's equally susceptible (or not) to attacks that try to brute force a user's password, and some sort of IDS solution that raises alarm bells for repeated bad password attempts is advisable (but quite a challenge to get the signal/noise ratio down to manageable levels). The server is also exposed to the possibility that any exploitable holes (primarily in IIS, or anything else exposed through the firewall) can be used to gain privileged access to the server by an outside attacker. Better be prepared for frequent patching. Other less likely but scary-sounding security threats are possible, but that's the big ones to tackle first.
是的，绝对可以使用集成安全性。但是，它还取决于您用于身份验证的框架。在 ASP.NET 中，您可以使用内置的身份验证模块。您将身份验证模式设置为“Windows”，.Net 将为您管理。您还可以拥有不同的角色来管理 Web 应用程序中不同类型的用户。您的网络应用程序必须在 LAN 外部可用（即您的防火墙不应阻止传入的 HTTP 请求）
Vamyip
Yes, it is definitely possible to use integrated security. But, it also depends on the framework you are using for authentication. In ASP.NET you can use built in authentication module. You to set the authentication mode to "Windows" and .Net will manage it for you. You can also have different roles for managing different types of users in your web app. You web app must be available outside your LAN(i.e. your firewall should not block incoming HTTP requests)
Vamyip
正如 ParanoidMike 指出的那样，通过将使用 Windows 身份验证的 Web 应用程序暴露到互联网，您正在为黑客创建一个暴力攻击向量。要尝试减轻此威胁，您应考虑采取以下操作：
我目前正在调查是否可以一起排除管理员帐户
As ParanoidMike points out by exposing a webapplication to the internet that uses windows authentication you are creating a brute force attack vector to hackers. To try and mitigate this threat you should consider taking the following actions:
I'm currently investigating if it is possible to exclude admin accounts all together