将用户的 Active Directory 凭据发送到后端系统是否错误

Question

我今天不得不查看一个 Intranet 站点的一些代码，它是一个带有 C# WebAPI 的 javascript 表单，它将 AD 用户名和密码（在登录期间）发送到后端，然后以该用户身份登录到 AD 以检查有效性。 （这都是本地的）。

我的 cmets 认为这相当于制作一个带有 facebook 徽标以及用户名和密码的表单，并要求用户使用它登录您的网站，然后自己登录 facebook 以检查 facebook 凭据是否有效。所以钓鱼和中间人一样，如果我们在我们的 Web 应用程序中拥有所有用户的所有 AD 凭据，那么就可以在任何地方以该用户身份登录并执行所有操作。

但是...讨论从开发团队开始，争论是

1. 它可以工作，为什么不呢（没有什么可以出错的，它是 Intranet）
2. 示例也在 stackexchange 上，例如这里： Validate a username and password against Active Directory?) 。因此，对于这个例子，我假设这仅用于特定情况，但从不在网络案例中使用
3. 当您使用某种语言编写桌面应用程序时，您还需要以某种方式验证自己是否能够抵御 AD。
4. 这是模拟的完美示例：我们模拟每个用户（我会在How to pass Windows Authentication credential from client to Web API service 的行中考虑更多）
5. 如果我们将程序扩展为用户可以更改其广告密码的点，我们将需要新密码（和域管理员凭据），所以这相同（我认为您将始终重置等）

所以这会带来疑问。我的想法是（显然对于 AD 而不是 ADFS）

• Windows 中的用户登录
• 用户打开浏览器访问 URL
• IIS 配置了一个启用了 Windows 身份验证的站点
• 浏览器和 IIS 进行协商（浏览器与 Windows 层通信）
• 用户是否有效>继续

据我所知，这是最佳实践（stackexchange 上的大量链接，例如 proper implementation of "windows" authentication in web api? 和网络，例如 https://support.microsoft.com/en-us/help/323176/how-to-implement-windows-authentication-and-authorization-in-asp-net）

Answer 1

应用程序不应该能够拦截用户密码。

因此，现代 Web 和移动应用程序将身份验证过程与 SAML IdP 或 OAuth2 授权服务器/OpenID 提供程序分开。

如果客户端和应用程序都已加入域，则本机 Windows 应用程序可以使用 Kerberos。

所有上述技术使应用程序能够获得经过验证的用户身份，同时无需将用户名和密码直接传输到应用程序。

Answer 2

这相当于制作一个带有 facebook 徽标以及用户名和密码的表单，并要求用户使用它登录您的网站，然后自己登录 facebook

由于信任问题，这不是一个准确的类比。你的公司不是 Facebook。

您的应用程序要求您公司的员工提供您公司内部 Active Directory 的凭据。那里有信任。这更像是一个由 Facebook 运营的网站，要求您提供 Facebook 凭据。

这并不是说没有安全问题。 Windows 身份验证是最好的方法，不仅因为您不与任何其他应用程序共享密码，而且因为它易于使用。如果设置正确，用户无需输入用户名和密码即可自动登录。这会让用户感到满意。

但是，如果您需要对外部域进行身份验证，这将不起作用。这就是我设置登录表单以收集 AD 用户名和密码的地方。我们的几个网站需要允许来自外部 AD 域的用户登录（没有 AD 信任），所以我通过 HTTPS 获取用户名和密码，并通过 LDAPS 对外部域进行身份验证。但是，我们不存储密码。一旦我们使用外部域验证了凭据，我们就会使用用户名创建表单身份验证令牌，然后忘记密码。

如果您将 AD 密码存储在自己的数据库中，那么我认为这是最大的问题。如果有人拥有该数据库，那么您的所有用户都可以在您组织的其他任何地方被冒充。