If a company often requires users to be created in a partner's active directory, and vice versa, does it make sense to set up a federated / trusted relationship between the AD instances? If so, what should be considered? Does the ACL for users in the partner AD still work the same way? What security risks does this expose?
如果公司通常要求在合作伙伴的活动目录中创建用户，反之亦然，那么在AD实例之间建立联合/信任关系是否有意义？如果是这样，应该考虑什么？合作伙伴AD中的用户ACL是否仍然以相同的方式工作？这暴露了哪些安全风险？
Thanks!
谢谢！
KA
K A
Update:
更新：
I've learned that there's a better way to do this by having the application itself check user stores. The best way to do this is by moving the application into a domain trusted by both user stores. I've provided more detail in my answer below.
我已经了解到，通过让应用程序自己检查用户存储，可以有更好的方法。执行此操作的最佳方法是将应用程序移动到两个用户存储所信任的域中。我在下面的答案中提供了更多细节。
2 个解决方案
#1
1
Yeah, it makes sense if you want both to be able to authenticate people across mulitple domains. You have to put the server that has the application you're targeting in a domain trusted by every AD instance you want to use for authentication.
是的，如果您希望两者都能够跨越多个域进行身份验证，那么这是有道理的。您必须将具有您要定位的应用程序的服务器放在您要用于身份验证的每个AD实例所信任的域中。
#2
2
I've been researching this a bit more, and I've found a good solution. Since both companies both need to use the same system, the system itself just needs to verify if a user exists in either of the user stores(authentication), and then to the authorization at the system level.
我一直在研究这个问题，我找到了一个很好的解决方案。由于两家公司都需要使用相同的系统，因此系统本身只需要验证用户是否存在于任一用户存储（验证）中，然后验证系统级别的授权。
The idea behind giving both companies access is solid - If we are working together and didn't have a way to do this, we'd need to re-create all the users from the company without access in the connected user store. Obviously, this would be a total mess and a maintenance nightmare.
给予两家公司访问的理念是可靠的 - 如果我们一起工作但没有办法做到这一点，我们需要重新创建公司的所有用户，而无需在连接的用户存储中访问。显然，这将是一场混乱和维护的噩梦。
I found out that in my case, even though both ADs are on the same WAN, it's necessary to have a formal federation or trust. Thankfully, we already have a domain that's trusted between both companies, so I just have to move the applications used by the partners into this domain. After that, it's simply a matter of fully-qualifying the DNS suffix to indicate the AD being used. Application-specific ACLs then reference the desired user store.
我发现在我的情况下，即使两个AD都在同一个WAN上，也需要有正式的联合或信任。值得庆幸的是，我们已经有一个两家公司都信任的域名，所以我只需要将合作伙伴使用的应用程序移动到这个域中。之后，只需要完全限定DNS后缀以指示正在使用AD。然后，特定于应用程序的ACL引用所需的用户存储。
#1
1
Yeah, it makes sense if you want both to be able to authenticate people across mulitple domains. You have to put the server that has the application you're targeting in a domain trusted by every AD instance you want to use for authentication.
是的，如果您希望两者都能够跨越多个域进行身份验证，那么这是有道理的。您必须将具有您要定位的应用程序的服务器放在您要用于身份验证的每个AD实例所信任的域中。
#2
2
I've been researching this a bit more, and I've found a good solution. Since both companies both need to use the same system, the system itself just needs to verify if a user exists in either of the user stores(authentication), and then to the authorization at the system level.
我一直在研究这个问题，我找到了一个很好的解决方案。由于两家公司都需要使用相同的系统，因此系统本身只需要验证用户是否存在于任一用户存储（验证）中，然后验证系统级别的授权。
The idea behind giving both companies access is solid - If we are working together and didn't have a way to do this, we'd need to re-create all the users from the company without access in the connected user store. Obviously, this would be a total mess and a maintenance nightmare.
给予两家公司访问的理念是可靠的 - 如果我们一起工作但没有办法做到这一点，我们需要重新创建公司的所有用户，而无需在连接的用户存储中访问。显然，这将是一场混乱和维护的噩梦。
I found out that in my case, even though both ADs are on the same WAN, it's necessary to have a formal federation or trust. Thankfully, we already have a domain that's trusted between both companies, so I just have to move the applications used by the partners into this domain. After that, it's simply a matter of fully-qualifying the DNS suffix to indicate the AD being used. Application-specific ACLs then reference the desired user store.
我发现在我的情况下，即使两个AD都在同一个WAN上，也需要有正式的联合或信任。值得庆幸的是，我们已经有一个两家公司都信任的域名，所以我只需要将合作伙伴使用的应用程序移动到这个域中。之后，只需要完全限定DNS后缀以指示正在使用AD。然后，特定于应用程序的ACL引用所需的用户存储。