首页 > 解决方案 > 针对 Intranet 应用程序的 Active Directory 安全建议/洞察

问题描述

我的任务是为企业 Intranet Web 应用程序提供身份验证/授权。给我的要求是:

  1. 必须针对 Active Directory 进行身份验证
  2. 所有 Active Directory 密码要求必须与 AD 中的相同
  3. 应用程序内的授权必须在 AD 之外进行。仍应通过支持团队使用 AD 锁定/解锁用户。

最初我所做的是使用用户提供的凭据对 LDAP 进行身份验证,其中用户只有在尝试 x 次(不是 AD)后才会被锁定在应用程序之外。我现在被告知,如果用户在 x 次后无法登录,他们应该被锁定在所有应用程序和所有企业连接之外(基本上是注销/强制退出 Windows)。我的感受如下:

  1. 听起来我们也想吃蛋糕。我们想使用 AD,但同时我们不想在它之外进行实际授权。我不明白这样做的目的是什么。他们似乎在尝试使用 SSO,但同时又没有。
  2. 我不明白为什么这应该将用户锁定在整个网络之外。要访问该站点,用户必须首先通过 VPN 登录(已经在 Windows 上登录并通过具有 2FA 的 VPN 登录)。然后,他们只需使用 Windows 密码再次登录该站点。我不明白这样做的安全性好处。
  3. 任何用户都可以输入他们想要的任何用户,并从该网站的帐户中锁定所有人。所以理论上我可以输入 CEO 的 AD 名称,然后在应用程序中输入密码,将他们锁定在整个公司网络之外。

从安全的角度来看,我给出的要求是否有任何理由?应用程序的无效登录是否应该将某些内容锁定在 Windows 帐户之外,尤其是当网络上的任何用户都可以访问该应用程序时?请帮助我了解这两种方法的优缺点。我知道两者都不是“理想的”,但我认为我被指示做的那个不合适。

标签: c#securityactive-directory

解决方案


这似乎是一个相当典型的场景。我假设您在 IIS 中托管 ASP.NET 应用程序。在这种情况下,只需将您的应用程序配置为进行 Windows 身份验证即可满足所有三个要求,但要求 3 中的授权位除外。为此,您通常会编写自己的授权方案,该方案涉及将特定于您的要求的用户角色存储在您的应用数据库。

您可能会混淆身份验证和授权。前者是验证用户身份的过程,而后者是验证用户特定权限的过程。您的要求是仅使用 AD 进行身份验证,这也是典型的。组织在 AD 中应用锁定策略来锁定在环境中的任何位置经历了多次不成功登录尝试的帐户。这与您的应用程序无关,只是 Windows 也会在那里强制执行该策略——因为为什么您的应用程序的行为应该与系统中的其他应用程序不同?就授权而言,这将完全由您的应用程序处理,并且您可以编写逻辑来决定用户在 AD 允许他们进入后对您的应用程序做什么(如果有的话)。

回应您的具体观点:

  1. 为什么不使用AD进行授权? 您可以通过创建与您的应用程序中的角色相对应的 AD 组并让您的应用程序使用 AD API 从它们中读取来执行此操作。但是一些组织可能不希望将 AD 与临时组混为一谈。将角色与您的应用程序配置的其余部分一起放入您的应用程序数据库也可以为您简化实施。

  2. 为什么应用程序内的错误密码尝试会将用户锁定在网络之外?为什么应用程序甚至会提示输入密码? 即使它是一个 Intranet 应用程序,理论上恶意内部人员也有可能在您登录 Windows 并离开办公桌后访问您的设备。也就是说,如果您的组织允许,您可以为应用程序配置集成 Windows 身份验证 (SSO),以便用户在成功登录网络后自动登录应用程序。

  3. 有什么办法可以阻止不良行为者通过输入错误密码故意锁定帐户? 不多,尽管系统管理员使用各种技巧来帮助检测和防御此类攻击。但这主要被视为 AD 问题,而不是特定于您的应用程序的问题。网络上的任何应用程序都可能用于此目的。

我确实认为每个应用程序都可以在密码尝试错误后强制执行锁定。它有助于防止上述涉及恶意内部人员的案例。在错误或错误配置可能在未来将您的应用程序暴露给互联网的假设情况下,它也是额外的安全层。也许牵强,但可能。在您的场景中强制执行是否有意义归结为数据敏感性和组织中的风险偏好。


推荐阅读