传统上，在我的工作地点，我们有一个内部子网，它在防火墙后面受到完全保护。不允许打开任何端口来直接从公共网络连接。我们还运行 DMZ，我们只允许在需要时打开特定端口。此外，我们不允许从 DMZ 打开到内部网络的连接，但内部网络可以打开到 DMZ 的连接。我敢说这是一个非常传统的 DMZ 风格配置。
我们还在内部网络中托管域控制器。到目前为止，这意味着我们需要单独管理 DMZ 密码，因为没有 AD 身份验证。这没什么大不了的，因为我们只有少数 DMZ 服务器。
现在我们即将推出一款需要更多 DMZ 服务器的产品，在我们测试的最后阶段，我们已经遇到了 DMZ 系统上的密码管理问题。解决方案似乎是从 DMZ 到内部网络打洞，以允许 DMZ 服务器加入域。
对我来说，这提出了两个问题：
我希望有人在那里有一些想法。
1）显然不是一个好主意。这意味着，如果加入域的 DMZ 机器受到威胁，那么您的公司 AD 将处于危险之中，这是不可接受的
唯一的选择是为您的 DMZ 部署单独的 Active Directory 林，可能具有不同的区域；例如，隔离网段中的主要可写域控制器和其他网段中的只读域控制器，但无论如何都没有链接到您的公司 AD。
确实存在管理/行政开销，但在安全方面，您没有很多其他选择。
如果您的内部生产 AD 很关键并且包含敏感系统、DATA 等，如果受到损害会对业务产生很大影响，那么您应该考虑使用单独的林。如果完全隔离的“DMZ”林不实用或管理成本太高（由于帐户重复等导致管理成本高），您可以考虑使用单向信任连接新的“DMZ”林，（DMZ Forest 信任内部“生产”林。DMZ 林应在内部网络上使用 RODC（如果您的版本可用）实施。然后，DMZ 设备可以通过防火墙上配置的端口进行身份验证，以仅访问“DMZ”林 RODC，从而允许集中管理 DMZ设备。生产林管理员可以使用他们的生产帐户来管理整个信任的 DMZ 设备。这是高级别的，可能不适合所有 dmz 要求，并假定集中管理 DMZ 系统的基本要求。
使用 RODC 可能是您的选择。将只读域控制器放在 DMZ 中。强化操作系统以仅允许来自 DMZ 中其他服务器的身份验证流量访问以及来自其专用网络中的 AD 复制伙伴的 AD 复制流量。阻止从 DMZ 到专用网络的入站请求（应该已经完成）。从专用网络中的 DC 配置推送复制，以便从专用网络端发出请求。
AD 联合服务可能是另一种选择。