在生产环境旁边有多个testing环境，最好的方法是什么？
我们有多个编程团队来构build使用Active Directory的解决scheme。 我们尝试了不同的方法，从他们自己的域控制器（在同一个子网）开始，或者在我们的产品AD中的其他OU，这个团队可以控制并且可以在这个OU中创build/删除账户。
我们想到了可能的解决scheme：
- 在ou production env中设置单独的OU。
- 为我们的
contoso.com域创build子域，比如test.contoso.com ， something.contoso.com并将控制委托给团队（我们需要额外的DC还是我们已经足够拥有的两个DC？
- build立对我们的主域有信任的额外的testing域控制器，并且所有的团队可以随意使用testing域控制器。
- 为每个团队/项目设置单个域控制器。
我们正在考虑所需资源的数量，安全性（例如多个密码的多个域控制器可能会导致用户使用更简单的密码）以及此场景的整体最佳实践。
更新：在90％的情况下，它将是SharePoint，BizTalk，客户关系pipe理等authentication。在其他情况下，它可以是SPN，Kerberosauthentication和testing与证书颁发机构。
这取决于你正在testing什么，以及AD需要做什么。 我对你的解决scheme的看法：
- 如果您只是testing账户创build/删除，那就好了，就像您在问题中所说的那样。 只要这是你的产品所做的全部或大部分 。
- 是的 – 每个域至less需要一个DC – 两个在一个失败的情况下更好。 即使是testing环境。 这让他们染上了他们想要的一切。
- 这太可怕了。 它们连接的域中有哪些DC并不重要 – AD是一个多主数据库，因此在一个地方进行的更改将被复制到任何地方。 你还没有任何担保 – 如果你让他们在任何地方添加/删除帐户，他们可能会意外删除所有帐户或在您的生产networking上执行其他操作。 恢复networking后的第一项任务将是一个粉红色的滑雪，可能是你的系统pipe理员，而不是开发团队。
- 在当今时代易于虚拟化的时代，您可能最好至less为每个人创build一个testing域（对于prod域没有信任），并根据您的公司和networking布局，为每个人创build额外的testing域根据需要，或者让每个开发人员在他们自己的机器上的虚拟机上运行DC（或更多），或者在他们的多维数据集中的第二个桌面上运行DC。 还有很多其他的架构选项。 取决于你的预算和需求。