如果公司经常要求在合作伙伴的活动目录中创建用户,反之亦然,那么在 AD 实例之间建立联合/信任关系是否有意义?如果是这样,应该考虑什么?合作伙伴 AD 中用户的 ACL 是否仍以相同方式工作?这会暴露哪些安全风险?
谢谢!
K A
更新:
我了解到,通过让应用程序本身检查用户存储,有一种更好的方法可以做到这一点。最好的方法是将应用程序移动到两个用户存储都信任的域中。我在下面的答案中提供了更多详细信息。
如果公司经常要求在合作伙伴的活动目录中创建用户,反之亦然,那么在 AD 实例之间建立联合/信任关系是否有意义?如果是这样,应该考虑什么?合作伙伴 AD 中用户的 ACL 是否仍以相同方式工作?这会暴露哪些安全风险?
谢谢!
K A
更新:
我了解到,通过让应用程序本身检查用户存储,有一种更好的方法可以做到这一点。最好的方法是将应用程序移动到两个用户存储都信任的域中。我在下面的答案中提供了更多详细信息。
我一直在研究这个,我找到了一个很好的解决方案。由于两家公司都需要使用同一个系统,因此系统本身只需要验证用户是否存在于任一用户存储中(身份验证),然后在系统级别进行授权。
为两家公司提供访问权限背后的想法是可靠的 - 如果我们一起工作并且没有办法做到这一点,我们需要重新创建公司的所有用户,而无需在连接的用户存储中访问。显然,这将是一团糟和维护的噩梦。
我发现在我的情况下,即使两个 AD 在同一个 WAN 上,也有必要建立一个正式的联盟或信任。值得庆幸的是,我们已经有了一个在两家公司之间都可以信任的域,所以我只需要将合作伙伴使用的应用程序移到这个域中。之后,只需完全限定 DNS 后缀以指示正在使用的 AD。然后,特定于应用程序的 ACL 引用所需的用户存储。
是的,如果您希望两者都能够跨多个域对人员进行身份验证,这是有道理的。您必须将具有您所针对的应用程序的服务器放在您要用于身份验证的每个 AD 实例信任的域中。