我想要具体的条款。 当我说DMZ的时候，我正在谈论一个地方，你会把服务器暴露给像互联网这样的不可信任的networking，或者在某些情况下只是那些不太可信的networking。
我试图通过审计我们通过防火墙公开的东西来支撑我们的networking边界。 我说的防火墙不是微软的ISA服务器，永远不会。 如果你们中的任何一个处于这种情况，你就知道允许成员服务器连接到域控制器所需的端口非常广泛。 微软试图解决这个问题提供了一些使用RODC来减less开放端口数量的devise，但是即使它只是一个端口，Active Directory本身也是一个未经授权的人攻击了DMZ成员服务器的情况。
DMZ中AD成员服务器的共识是什么？ 太不安全，还是可以接受的风险？ 假设前者（我倾向于），除了本地帐户身份validation之外，是否还有比AD更安全的选项来validationloginDMZ Windows服务器的用户？ 如果没有，那么是否有一种机制可以在login时将本地帐户与真实用户相关联以进行审计？ 似乎跟踪用户在独立服务器DMZ中的行为的唯一select是为login到服务器的每个用户创build本地计算机帐户。
当然，理想情况下，您没有人login到服务器进行正常操作; 整个事情应该由代理使用服务帐户进行pipe理（这是一个整体“另外的讨论）。 但是现在我们的行动还不是“那里”。 我们希望DSC能够做到这一点。
微软的build议的重点是对我来说不切实际或错过了这一点。 一个仅用于DMZ的Active Directory降低了入侵者收集英特尔的能力，但仍然使得该向量几乎就地存在。 他们的解决scheme可以做的最好的办法是把这个英特尔限制在DMZ上（除了你的DMZ AD可能提供的服务外），将风险宝贝分开。 权衡是每个DMZ的一个AD。 所以现在你的pipe理员正在pipe理一个帐户+ N DMZ's。
并不是说微软正在倾听，但是需要有一个中间的方式来授权Windows用户，但是不需要使用像enum LDAP用户那样的凭据。
我不知道别人怎么想，但我的观点是这样的：
如果AD服务器用于企业/内部authentication/授权，那么它不应该在DMZ上。 如果它用于外部可用应用程序的身份validation，那么是的 – 它属于那里，假设它根本没有任何钩子进入DRN。
如您所述，DMZ允许不受信任的networking访问提供的服务。 这些服务可能会受到影响，如果您的内部目录在那里 – 这也将是。