服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 活动目录configuration：有人可以解释冲突的信息？
Intereting Posts
KVM在线磁盘大小调整？ 在Fedora 17上将PHP降级到5.3 暂时限制访问IIS网站 不同VLAN上的iSCSI LUN 通过SSH进行系统日志的其他安全措施 如何编辑Powershell脚本以继续出现错误？ Apache CentOS 7上的故障无法启动 Ubuntu ufw：在每个接口的基础上设置一个规则 如何杀死一个无用的while循环？ 为什么我的软件包不包含在我自定义的yum版本库中？ 不能WMI查询根\ MSCluster命名空间作为本地pipe理员 阻止访问某些网站 对于从工作EC2映像创build的EC2实例，SSHlogin失败 无法在Hyper-Vpipe理器上创build外部虚拟交换机 如何在Apache Coyote 1.1 tomcat服务器中设置“Accept Ranges：byte”？

活动目录configuration：有人可以解释冲突的信息？

如果你看看微软最佳实践 ，build立一个新的森林/域名，他们提出了一些build议，在网上与其他build议相冲突，并没有跟我曾经工作过的任何公司一样。

例如，最佳做法指定使用在Active Directory命名空间中的Internet权限注册的DNS名称，因为它们是全局唯一的。 然后他们build议为注册的DNS名称添加一个前缀以创build一个新的从属名称。 例如，如果DNS根名称是contoso.com，那么您应该创build一个Active Directory林根域名称，例如concorp.contoso.com …

在很多地方，我看到了使用互联网注册名称的build议，因为内部networkingstream量路由到外部IP和DFS共享问题。 我也很less看到公司使用域名的“corp.company.com”命名scheme。 他们通常使用诸如“company.com”或“company.local”之类的东西。

最后，最佳做法build议将根域留空以pipe理域并创build单个全局子域。 遵循这种做法将导致域名，如“domain.corp.company.com”，这是我从来没有见过的。

是否有理由不遵循最佳实践或是否被遵循，我只是不看正确的结构？

太糟糕了，我不是为了聚会而醒来的，呃？ 无论如何，我还是会打个招呼。

我教过MCSE课了好几年，微软的各种培训材料之间的build议总是相当一致的。

  • 不要使用您不属于您的Active Directory域名（即microsoft.com）的域名。

  • 不要将FQDN用于其他DNS服务器已经授权的域（即company.com）

  • 对全球唯一的域使用FQDN（即ad.company.com，corp.company.com）。

我相信“.local”TLD“build议”是在Windows Small Business Server 2003的时候开始的。“.local”TLD并不是由ICANN保留的，尽pipe在这一点上值得怀疑的是它将被用于“真实“在互联网上（我相信Zeroconf协议也依赖于”.local“TLD）。

我曾经在“company.com”用于AD域名的环境太多，需要愚蠢的丑陋的黑客手段，涉及手动将DNSlogging从DNS DNS服务器复制到支持AD的DNS服务器。 我已经回答了这个网站上的一堆问题，这些问题归结为这个可怜的域名select，导致黑客必须被实施（必须运行networking服务器来redirect到每个“真实的”“company.com”网站AD域控制器等）。

我不知道为什么公司坚持为AD域做“company.com”命名scheme。 这只会造成问题。 没有什么好的理由说明为什么你应该这样做，而且它违背了DNS的基本原则，那就是世界上只有一套DNS服务器应该对给定的DNS域名具有权威性。 （我经常听到“UPN后缀”的说法，如果你想让用户有一个UPN后缀“@ company.com”，例如，你可以做到这一点，实际上命名的域名“company.com”。用户可以有“@whitehouse.gov”UPN后缀，如果你想，域名的尊重…）

我一直偏袒“ad.company.com”，我自己。

“空根”的思想纯粹是一种政治build构。 最初（W2K时间框架）微软公司吹捧“空白根”作为一种方式来隔离组织各部分之间的安全问题，同时还有一个单一的AD基础设施。 幸运的是，他们已经放弃了这种态度（尽pipe他们不一定会退回去纠正所有错误的文件），因为已经certificate，任何AD森林领域的“域pipe理员”轻松地将自己变成“企业pipe理员”组的成员。

所以今天“空洞的根”才真正用于政治目的。 我认为没有地方可以解决，因为它增加了不必要的复杂性（从来没有一个单一的域环境可以实现的多域环境）并且没有任何真正的优势。

如果您希望在组织中关注安全性之间进行安全隔离，则必须使用多森林部署（这绝对是最不好玩的一种环境，不惜一切代价避免）。

你所描述的是直接出MCSE类。

关于他们的最佳实践需要记住的一件事是他们正在讨论从Active Directory的大量实现中获得的经验。

我不想假设太多，但基于你的问题，我猜你在SMB部分？ 由于规模问题，并非所有这些最佳做法都必然适用于这一领域。

对于DNS域名，select“真实”域名的build议可能基于还托pipeExchange的AD林。 这样的configuration使得两者更容易pipe理。 一个更好的方法是注册真实的域名，然后将AD转换为.local。 您的AD DNS域名将是contoso.local和“真正的”名称contoso.com。 然后，为Exchange的真实名称configuration备用SPN后缀。 听起来很麻烦，但不值得处理裂脑DNS等问题。

就如何处理森林根域而言，他们的build议是基于更严格地划定森林内对象pipe理的安全性。 您可能有组织边界，要求某些部门/业务单位等有一个域pipe理员为他们的域名。 还有其他的好处，但这可能是最常见的。

我会给你我遵循的原则

  1. 对于域环境，请始终使用非互联网域名后缀 （即.lan或.local） – 由于DNS，这可能会非常快速地成为一个非常大的交易。 假设您的网站托pipe在其他几个子域的其他位置，您的网站是company.com，而您的AD域也是company.com。 你的工作站寻找www.company.com去你的网站，但你的AD DNS响应一个“未find”，因为它认为它是company.com的权限，而你没有名为“www”的networking上的机器。 当你有VPN用户时，相反的情况是正确的。 您的VPN'd用户可以尝试访问myserver.company.com，但DNS查find您的网站的DNS服务器，而不是AD服务器….你得到的漂移。 .lan后缀减轻了这一点。
  2. 如果你知道你最终有分支机构的支持，那么根域是空白的是有道理的。 否则，没有理由增加额外的复杂性和额外的域控制器。

所谓的“根占位符域”（空的根目录）在大型组织中可能实际上是有用的，在大型组织中合并/分裂场景更有可能; 如果您发现自己需要在森林中创build其他领域并转向更分散的pipe理模式，那么拥有自己的地方可以拥有森林范围的行政账户和FSMOangular色是一件好事。 您不能移动或重命名林根域，所以如果您觉得您可能需要一个独特的目的，您必须从一开始就创build它。

对于小型组织来说，这当然是完全没有用的，而且还需要至less另外两台服务器充当第二个域的DC。