Active Directory

Catch 全部子网使用 Active Directory 中

John Policelli

 

概览:

  • 域控制器定位程序
  • 集中和分散拓扑
  • 实现捕获所有子网

内容

客户端如何定位域控制器
此问题
Catch 全部子网
向上覆盖

一个理想的领域中将用户定向到 Active Directory 身份验证的适当的域控制器 (DC)。 但是,这不一定是由于对不在正确 Active Directory 中定义的 IP 子网信息的大多数组织。 因此,许多用户身份验证不是最佳 Active Directory 身份验证的任意的域控制器。

此文章中, 我将提供以确保用户在 IP 子网信息不完全定义 Active Directory 中查找相应 DC 进行身份验证可能解决方案。

客户端如何定位域控制器

当计算机尝试定位域控制器时,调用域控制器定位程序 (Locator) 进程已启动因此相应的 Active Directory 域控制器可以找到。 定位程序使用存储在 Active Directory 和 DNS 来尝试查找与所需的角色的域控制器中,并且,位于客户端最近的站点的信息。

定位程序使用复制到目录林中每个域控制器在目录林根域中配置容器中定义的信息。 站点对象、 子网的对象和域控制器服务器对象是为客户端计算机中查找最近的域控制器定位程序的所有强制。 站点对象用于表示 Active Directory 站点。 子网对象用来表示 IP 地址段,并且与相应的站点对象的关联。 域控制器服务器对象用来表示域控制器,并且与站点对象关联。

Active Directory 域控制器注册指定 DC 所在的站点的 DNS 记录。 每个域控制器注册的 DNS 记录的数量取决于 DC 所具有的角色。 是例如是全局编录服务器的 DC 将注册为公布自己的其他 DNS 记录。 同样,拥有操作主机角色的域控制器将注册为此公布自己的 DNS 记录。

客户端计算机来定位域控制器的过程所示:

  1. 定位程序在客户端计算机上启动作为本地的 Net Logon 服务的远程过程调用 (RPC)。
  2. 客户端收集信息时需要选择一个域控制器,并将信息传递到 Net Logon 服务。
  3. 在客户端计算机上的 Net Logon 服务使用收集的信息构建一个查询以确定适当的域控制器发送到 DNS。
  4. 在客户端计算机上的 Net Logon 服务向发现的域控制器发送数据报。
  5. 目录服务会截获该查询,并在域控制器上下将它传递给 Net Logon 服务。
  6. 在域控制器上的 Net Logon 服务客户端 IP 地址通过查找与客户端 IP 地址,然后返回最接近的子网对象的子网站点映射表中查找以下信息以客户端: 所在的网站的客户端,客户端 IP 地址最匹配的站点的名称 ; 所在网站中当前的域控制器和一个位,指示是否找到的 DC 所在客户端最近站点的名称。
  7. 客户端检查信息以确定是否它应尝试查找更好的域控制器。 决定由如下所示: 如果返回的域控制器运行在最近的站点中,客户端使用此域控制器,; 如果客户端已发现的 DC 声明客户端站点中的 DC 位于,客户端使用此域控制器 ; 如果 DC 是不在最近的站点,客户端更新的站点信息,并发送新的 DNS 查询来查找站点中的新 DC。 如果第二个查询成功,使用新的 DC。 如果第二个查询失败,则使用原始的 DC。
  8. 如果客户端查询的域是与计算机已加入的域相同,计算机所在的网站就会存储在客户端计算机上注册表中。
  9. 在客户端定位 DC 之后,将缓存域控制器条目。 如果域控制器不在最佳站点中,客户端将在 15 分钟后刷新缓存,并丢弃缓存条目。 它然后尝试与客户端的在同一站点中查找一个最佳域控制器。

在情况下,客户端计算机使用 IP 地址子网站点映射表中未表示是 DC 返回 NULL 站点名称,并在客户端使用可能驻留在任何 Active Directory 站点中,返回的域控制器。

此问题

如果域控制器无法确定最近站点,由于不在 Active Directory 中, 定义的 IP 子网信息然后身份验证使用不是最佳的 DC。

图 1 显示了使用集中和分散的拓扑的示例 Active Directory 站点设计。 从 Active Directory 中定义的子网之一上的计算机登录用户定向到在进行身份验证其最近 Active Directory 站点的域控制器。 但是,登录从位于子任何其他网,例如 10.1.4.0/24 的计算机上的用户被定向到任意的 DC。

fig01.gif

图 1 示例集中和分散拓扑站点设计

此适当修复程序解决这一问题当然,是在 Active Directory 中定义其他子网,并将它们与相应的站点相关联。 但是,获取该信息通常图标问题需要将这些其他子网添加到 Active Directory 的组织 (尤其是大中型组织)。 更是具体地说 Active Directory 管理员通常会知道其他子网通过错误和日志文件存在,但不知道这些子网属于阻止他们标识要关联的子网的站点的物理 Office。

Catch 全部子网

此问题更实用的方法解决方案是使用 Active Directory 中的一个或多个 catch 所有子网。 捕获所有子网是一个 Active Directory 子网,用于捕获来自未在 Active Directory 中定义的子网上的客户端身份验证。 捕获所有子网是实质上是一个 Super-subnet。

图 1 所示,10.1.1.0/24 子网是在 Active Directory 中定义,并与在多伦多 Active Directory 站点相关联。 假设您注意到许多 10.1.4.0/24 和 10.1.5.0/24 子网上的客户端将验证对 Active Directory。 您认为,这些子网是基于前缀 (10.1.x.x) 多伦多办公室中。 要确保这些的子网,以及使用该 10.1.x.x 前缀的任何其他子网上的计算机验证多伦多站点中的 DC。 因此创建使用该 10.1.0.0/16 前缀直接从您认为到位于在多伦多办公室的所有子网身份验证在捕获所有子网,然后您确保身份验证使用多伦多站点中的 DC。 本示例将捕获所有子网映射 图 2 中的红色文本显示。

fig02.gif

图 2 使用捕获所有子网的中心站点

在大多数组织,远程分支机构的 IP 子网信息被传递到 Active Directory 管理员。 该间隔通常存在为中心的办公室,中心的位置和数据中心 IP 子网。 在捕获所有子网可用于提高这些情况下中的身份验证。 远程分支机构的 IP 子网是相当静态,并通常需要很好的理解这些子网上,您可以创建捕获所有子网的所有其他子网。

在此示例,您可以创建使用 10.0.0.0/8 前缀一个捕获所有子网,以捕获来自您认为不属于将远程办公室并确保身份验证的所有子网身份验证使用 DC 中心多伦多站点。 本示例将捕获所有子网映射 图 3 中的红色文本显示。 并可以甚至使用多个 catch 所有子网如 图 4 ,所示 (如果您希望。

fig03.gif

图 3 捕获所有子网所有位置

fig04.gif

图 4 使用多个 catch 所有子网

注意,在 图 3 和 4 捕获所有子网使用重叠在远程站点 (10.0.0.0/8 涵盖 10.1.1.0/24 例如) 中使用的前缀的前缀。 您可能想知道是否从远程分支机构中的计算机身份验证将仍然会转向相应的远程办公室中的一个域控制器结果。 答案是肯定的。 当重叠的 IP 子网存在于 Active Directory 中时,使用 IP 子网,最小匹配的子网掩码。 是例如 10.1.1.0/24 将使用而不是 10.0.0.0/8 如果计算机有 10.1.1.5/24 子网的 IP 地址。 但是,10.1.1.1./32 将用于而不是 10.1.1.0/24 10.1.1.5 的 IP 地址的计算机。

向上覆盖

在继续操作并实现捕获所有的子网之前,必须注意捕获所有子网的概念是不适合所有环境。 这样的解决方案的可行性大大取决于您的 IP 地址配置。

在我提供了下面的示例中,IP 寻址方案,请是相当简单。 但是,随着 IP 寻址方案变得更复杂,使用捕获所有的子网的可行性变可能性。 是例如如果您的环境包含多个网络段,并且您的 IP 地址配置每个位置上不连续,它将几乎不可能创建捕获所有子网,将提供任何值。 与所有的解决方案必须考虑技术、 业务,和环境因素确定实现捕获所有的子网的生命力时特定于您的环境。

并注意将捕获所有的子网不能解决完全缺少子网的问题。 实际上,如果在您的环境中引入了捕获所有的子网,它是甚至更为重要您显式定义所有已知的子网在 Active Directory 中。

捕获所有的子网的使用将增加查找最近的域控制器的用户的数。 但是,您的目标应仍然是解决此问题的来源,并确保将会收到为所有添加、 修改和删除网络子网的相应信息,以便可以维护提供有效的身份验证的所有用户的最新 Active Directory 站点设计。

John Policelli (Microsoft MVP 目录服务、 MCTS、 MCSA、 ITSM、 iNet +、 网络 + 和 A +) 通过在体系结构、 安全、 战略规划和灾难恢复计划的组合成功的十年是一个解决方案中心 IT 顾问。 John 已花费过去九年专注于身份和访问管理并提供某些在加拿大的 Active Directory 的最大安装认为领导能力。 John 保持在博客 http://policelli.com/blog.