附录 C应用程序与 RODC 的兼容性.docx

附录 C应用程序与 RODC 的兼容性.docx

《附录 C应用程序与 RODC 的兼容性.docx》由会员分享，可在线阅读，更多相关《附录 C应用程序与 RODC 的兼容性.docx（12页珍藏版）》请在冰豆网上搜索。

附录C应用程序与RODC的兼容性

引用：

附录C：

应用程序与RODC的兼容性

更新时间:

2009年5月

应用到:

WindowsServer2008

只读域控制器（RODC）是WindowsServer 2008操作系统中的一种新类型的域控制器。

RODC包含只读ActiveDirectory域服务（AD DS）数据库。

借助RODC，组织可以在无法保证物理安全性的位置中轻松部署域控制器。

在本指南中

已知可用于RODC的应用程序

应用程序与RODC的兼容性

测试应用程序与RODC的兼容性

用于解决应用程序与RODC之间的兼容性问题的开发人员指南

已知可用于RODC的应用程序

更新时间:

2009年5月

应用到:

WindowsServer2008

已知以下应用程序与RODC兼容，但如果将这些应用程序直接安装在RODC上，其中一些应用程序可能无法正常运行。

随后部分将介绍使用与RODC交互的自定义应用程序可能会遇到的常见问题以及建议用于解决这些问题的步骤。

∙MicrosoftInternetSecurityandAcceleration（ISA）Server

∙MicrosoftOfficeLiveCommunicationsServer

∙MicrosoftSystemsManagementServer（SMS）

∙MicrosoftOfficeOutlook

∙MicrosoftOperationsManager（MOM）

∙WindowsSharePointServices

备注

WindowsSharePointServices可以从Microsoft网站下载；该应用程序未包含在WindowsServer 2008中。

∙MicrosoftSQLServer

∙WindowsServer服务，包括：

∙ActiveDirectory证书服务（AD CS）

∙ActiveDirectoryRightsManagementServices（AD RMS）

∙凭据漫游

∙分布式文件系统（DFS）

∙分布式文件系统复制（DFSR）和文件复制服务（FRS）

∙域名系统（DNS）

∙动态主机配置协议（DHCP）

∙组策略

∙Internet身份验证服务

∙Internet信息服务（IIS）

∙网络访问保护（NAP）

∙终端服务（用户和计算机管理单元）

∙终端服务授权服务器

应用程序与RODC的兼容性

更新时间:

2009年5月

应用到:

WindowsServer2008

由于大多数启用ActiveDirectory的应用程序都是读取密集型的应用程序，因此不管目录是否可写，它们都继续工作。

因此，将RODC引入到环境中不会影响它们。

通常，基础结构应用程序和服务（如DNS和DHCP）还能很好地使用只读目录数据。

但是，将RODC引入到企业环境中可能会影响与AD DS交互的某些应用程序。

部署RODC的组织可以测试在应用程序可能与站点中的RODC（而不是传统可写的域控制器）交互的方案中是否会影响其应用程序。

他们还可以在RODC和可写域控制器之间的连接可用或不可用的方案中测试他们的应用程序。

下图描述了这些方案。

第一种方案是典型的分支机构部署，其中分支站点具有与中心站点的日常通信。

第二种方案是与可写域控制器的连接受限制的外围网络（也称为隔离区和屏蔽子网）或Extranet方案。

您可以在以后查看本文档中的指南以便测试应用程序以及解决与RODC交互时应用程序遇到的问题时参考下图。

图 1   在分支机构方案中，应用程序可以通过广域网（WAN）链接访问可写域控制器

图 2   在Extranet或外围网络方案或WAN脱机并且应用程序不能访问可写域控制器的方案中

已启用目录的应用程序

使用Microsoft技术构建的已启用目录的应用程序主要使用以下类型的技术：

∙ActiveDirectory服务界面（ADSI）

这些应用程序使用非托管ADSI提供程序和一个托管System.DirectoryServices命名空间。

有关非托管ADSI提供程序的详细信息，请参阅ADSI服务提供程序（

有关System.DirectoryServices命名空间的详细信息，请参阅System.DirectoryServices命名空间（

∙轻型目录访问协议（LDAP）应用程序编程接口（API）

这些应用程序使用非托管WLDAP32和一个托管System.DirectoryServices.Protocols命名空间。

有关非托管WLDAP32的详细信息，请参阅轻型目录访问协议（

有关托管System.DirectoryServices.Protocols命名空间的详细信息，请参阅System.DirectoryServices.Protocols命名空间（

已启用目录的应用程序使用DC定位器的DsGetDcName函数，以搜索并连接到域控制器以便读取或写入数据。

备注

例如，某些应用程序还可以通过其名称或IP地址以特定域控制器为目标。

如果这些应用程序继续以可写域控制器为目标，则它们不会受到RODC的影响。

但是，作为最佳操作，确保您的应用程序使用DC定位器。

在ADSI中，隐式调用DC定位器的DsGetDcName函数，这个过程称为无服务器绑定。

对于LDAP应用程序，该应用程序开发人员显式调用DsGetDcName。

根据您所设置的参数，DsGetDcName在网络上搜索与条件匹配的域控制器，如全局编录服务器或主域控制器（PDC）仿真器。

然后该应用程序连接到该域控制器以执行所需的操作。

有关DC定位器的详细信息，请参阅目录服务函数（

有关DsGetDcName的详细信息，请参阅DsGetDcName函数（

有关无服务器绑定的详细信息，请参阅无服务器绑定和RootDSE（

RODC对已启用目录的应用程序的影响

尽管ADSI和LDAP应用程序都使用同一个DsGetDcName函数，但是默认情况下每种类型的应用程序可以连接到不同类型的域控制器。

换言之，默认情况下ADSI应用程序搜索并连接可写域控制器。

相比之下，默认情况下LDAP应用程序搜索并连接可写域控制器或只读域控制器。

此默认行为可能会导致与RODC交互时已启用目录的应用程序出现以下问题：

∙问题1：

读取操作无效或失败

∙问题2：

写入操作失败

∙问题3：

写入/读回操作失败

备注

如果应用程序在域控制器的LocalSystem安全上下文下运行，则该应用程序在RODC上运行时其权限将会降低。

这是因为在计算机上LocalSystem安全上下文下运行的应用程序将使用该计算机的域帐户凭据。

RODC的域帐户拥有的权限较低。

问题1：

读取操作无效或失败

当应用程序不以RODC为目标时会发生读取操作无效或失败，因为不管它是否是最靠近的域控制器，它都是只读域控制器。

例如，假定如图1中所示的应用程序只能从AD DS读取数据，并且将读取的该数据位于站点中的RODC上。

如果应用程序配置为始终为目录操作查找可写域控制器（默认情况下ADSI应用程序就是这样），然后该应用程序通过WAN链接从中心站点中的可写域控制器中读取数据。

在本例中，应用程序忽略RODC并且不将其用于读取操作。

这会导致在WAN联机时出现读取操作无效以及在WAN脱机时读取操作失败。

重要事项

不管该域控制器是可写还是只读，都要确保将只从AD DS读取数据的应用程序配置为使用最近的域控制器。

尽管默认情况下LDAP应用程序使用最近的域控制器，但是默认情况下ADSI应用程序只以可写域控制器为目标。

因此，您可能必须解决可以与部署的RODC交互的ADSI应用程序的读取操作无效的问题。

有关详细信息，请参阅本文档后面的用于解决应用程序与RODC之间的兼容性问题的开发人员指南。

问题2：

写入操作失败

在Extranet或外围网络方案中，写入操作失败。

但是，在分支机构方案中，当应用程序与RODC交互以尝试写入操作时，默认情况下RODC返回对可写域控制器的引用。

应用程序必须响应该引用，然后才能使用它接收的信息来查找可写域控制器。

尽管ADSI应用程序自动跟踪引用，但是开发人员必须将LDAP应用程序配置为跟踪写入引用。

该配置称为LDAP_Write_Referral。

在分支机构方案中，如果与可写域控制器的连接不可用，则无论应用程序使用LDAP还是ADSI，写入操作都会失败，并且没有其他配置可帮助解决这个问题。

问题3：

写入/读回操作失败

当应用程序将数据写入一个域控制器，然后尝试在另一个域控制器上读取同一数据时会发生写入/读回操作失败。

这种情况下，该应用程序不读取更新的数据，因为该数据尚未复制到该应用程序进行读取操作的目标域控制器。

引入RODC会使这个问题更突出，因为您可能无法确定引用中返回了哪个可写域控制器。

例如，假定如图1中所示的应用程序向AD DS中写入数据，然后读回相同的数据。

如果该应用程序希望更新的数据可用于写入/读回操作，则应该以此可写域控制器为目标进行写入和读取操作。

如果应用程序没有明确连接此可写域控制器进行写入和读取操作，则它可能会从RODC中读取尚未更新的数据，因为中心域控制器和RODC之间存在复制延迟。

如果您的应用程序向AD DS中写入数据，然后希望读回更新的数据，则确保明确查找可写域控制器以写入数据，然后连接同一域控制器以读回该数据。

测试应用程序与RODC的兼容性

更新时间:

2009年5月

应用到:

WindowsServer2008

在分支机构、外围网络或Extranet中部署RODC之前，执行以下步骤测试站点中所有已启用目录的应用程序与RODC的兼容性。

第1步：

设置测试环境

根据下图中的拓扑设置测试环境。

图 3   用于测试应用程序是否与RODC兼容的设置

执行以下步骤设置测试环境：

1.安装运行WindowsServer 2008的可写域控制器。

2.在域控制器上安装DNS服务器服务。

有关详细信息，请参阅“使用Windows界面安装新的WindowsServer2008林”（Default-First-Site-Name站点中。

3.使用ActiveDirectory站点和服务新建站点。

例如，新建一个名为Branch的站点。

4.将Branch站点添加到DEFAULTIPSITELINK站点链接对象中。

DEFAULTIPSITELINK是默认情况下在AD DS中创建的第一个站点链接的名称。

您必须将此分支站点添加到该站点链接中，才能启用RODC和可写域控制器（在此过程的第1步中安装）之间的复制。

5.在Branch站点中安装RODC。

有关详细信息，请参阅“安装其他WindowsServer2008域控制器”（

6.如有必要，为站点之间存在的防火墙配置规则。

7.如有必要，将客户端计算机加入域，然后将客户端计算机对象移动到Branch站点。

8.将应用程序安装到Branch站点中。

第2步：

对应用程序进行分类

确定应用程序与AD DS交互的方式，然后根据组织使用它们的方式以及应用程序执行的操作类型对应用程序进行分类。

可以使用下表中的类别作为参考。

应用程序类型

描述

读取应用程序

仅从AD DS中读取数据的应用程序。

在此类别中，还可能包含一个向AD DS中写入数据的应用程序（如果不关心写入操作是否失败）。

例如，假定您拥有一个其操作中有99.9%都执行读取操作，而只有0.1%执行写入操作的应用程序。

如果您不关心当可写域控制器不可用时有一些写入操作将失败，则可以考虑使该应用程序成为读取应用程序。

读写应用程序

写入AD DS及从中读取数据的应用程序，其中读取操作独立于写入操作。

对于此应用程序类型，请确保您的应用程序执行独立的读取和写入操作。

如果读取操作依赖于在写入操作期间写入的数据，则将该应用程序分类为写入/读回应用程序。

写入/读回应用程序

向AD DS写入数据并希望读回更新数据的应用程序。

第3步：

测试应用程序

根据需要执行以下步骤，以帮助您确定分类以及测试应用程序的方式：

1.在应用程序服务器上部署应用程序。

2.使用为其创建的测试计划来测试应用程序。

（为每个应用程序创建测试计划不在本指南的范围之内。

）

下表显示了可以运行的测试的结果，以帮助您按类型对应用程序进行分类。

应用程序类型

测试

期望的结果

读取应用程序

断开与可写域控制器的连接。

所有目录操作都应该通过。

读写应用程序

断开与可写域控制器的连接，然后重新连接。

当断开可写域控制器时，读取操作应该通过，但写入操作应该失败。

当重新连接此控制器时，所有目录操作都应该通过并且所有读取操作都应该被优化。

换言之，应将读取操作定位到最近的域控制器，而不考虑它是可写还是只读域控制器。

写入/读回应用程序

断开与可写域控制器的连接。

所有目录操作都应该失败。

第4步：

解决损坏或无效的应用程序问题

标识不提供期望结果的应用程序，因为这些应用程序在RODC环境中被损坏或无效。

有关解决自定义应用程序问题的详细信息，请参阅用于解决应用程序与RODC之间的兼容性问题的开发人员指南。

有关解决其他应用程序问题的详细信息，请与这些应用程序的独立软件供应商（ISV）或开发人员联系，并向他们提供基于测试的问题的详细信息。

他们可以使用在本指南中描述的相同解决方案步骤。

用于解决应用程序与RODC之间的兼容性问题的开发人员指南

更新时间:

2009年5月

应用到:

WindowsServer2008

在继续这些解决方案步骤之前，请确保对您的应用程序进行相应的分类。

解决ADSI应用程序问题

默认情况下，ADSI应用程序通过隐式调用设置有DS_WRITABLE_REQUIRED标记的DsGetDcName函数来查找可写域控制器。

此行为导致ADSI仅查找可写域控制器。

如果ADSI没有找到可用的可写域控制器，则默认的ADSI调用失败，即使它们仅尝试读取ActiveDirectory数据也是如此。

此行为可能导致读取操作无效，如问题1中所述。

在分支机构方案中，使用默认ADSI行为的读取应用程序从中心站点域控制器中读取所有数据，而不使用RODC。

如图1中所示。

如图2中所示的外围网络或Extranet方案中，使用默认ADSI行为的读取应用程序会由于没有与可写域控制器的可用连接而失败。

若要解决此问题，您可以通过在调用ADSIADsOpenObject函数时设置ADS_READONLY_SERVER标记来覆盖ADSI的默认行为。

这样做会导致ADSI查找可写域控制器和只读域控制器。

下表概述了ADSI应用程序的解决方案。

备注

覆盖仅用于读取应用程序和读写应用程序的ADSI默认行为。

应用程序类型

ADSI应用程序的解决方案

读取应用程序

这些应用程序仅从AD DS读取数据。

当调用ADSIADsOpenObject函数时，设置ADS_READONLY_SERVER标记。

这会导致ADSI查找可写域控制器和只读域控制器。

读写应用程序

这些应用程序从AD DS读取和写入数据。

读取操作独立于写入操作。

确保您的应用程序执行独立的读取和写入操作。

如果读取操作依赖于应用程序在写入操作期间写入的数据，则将该应用程序分类为写入/读回应用程序。

当调用ADSIADsOpenObject函数时，设置ADS_READONLY_SERVER标记。

这会导致ADSI查找可写域控制器和只读域控制器。

写入/读回应用程序

这些应用程序向AD DS写入数据并希望读回更新的数据。

无任何条件地调用ADSIADsOpenObject函数。

这会导致ADSI仅查找可写域控制器。

然后，ADSI使用同一域控制器进行读取操作。

不要设置ADS_READONLY_SERVER标记，因为这会导致应用程序从RODC中读取尚未更新的数据，而不是更新的数据。

例如，假定应用程序向DC1写入数据，并且该写入操作成功。

然后应用程序尝试使用RODC2读回该数据。

这种情况下，读取操作可以返回尚未更新的数据。

解决LDAP应用程序问题

LDAP应用程序不会自动查找域控制器。

相反，它们显式调用DC定位器来查找域控制器。

LDAP应用程序使用DsGetDcName函数来查找与您的条件匹配的域控制器。

可以使用下表中的信息来帮助您解决LDAP应用程序的问题。

应用程序类型

LDAP应用程序的解决方案

读取应用程序

这些应用程序仅从AD DS读取数据。

不要在调用DsGetDcName函数时设置DS_WRITABLE_REQUIRED标记。

读写应用程序

这些应用程序从AD DS读取和写入数据。

读取操作独立于写入操作。

确保您的应用程序执行独立的读取和写入操作。

如果读取操作依赖于AD DS在写入操作期间写入的数据，则将该应用程序分类为写入/读回应用程序。

您可能决定查找可写域控制器用来写入数据，查找RODC用来读取数据。

当您在分支机构站点中使用读写应用程序时，如果在查找域控制器来写入数据时未设置DS_WRITABLE_REQUIRED标记，则您首先应该联系站点中的RODC。

因此，在RODC上的写入尝试会生成一个写入引用，然后您必须跟踪对可写域控制器的引用以写入数据。

只要您必须写入AD DS，就明确搜索可写域控制器；不要依赖LDAP引用。

写入/读回：

向AD DS写入数据并希望读回更新数据的应用程序

当查找域控制器来写入数据时设置DS_WRITABLE_REQUIRED标记。

然后，确保您连接同一域控制器以读取数据。

这样做可确保您的所有写入操作以及从属的读取操作都联系可写域控制器。

下图显示了每种类型的已启用目录的应用程序的解决方案过程。

图 4   每种类型的已启用目录的应用程序的解决方案过程

其他资源

MSDN库中的以下主题具有可以帮助您准备应用程序以使用RODC的详细信息：

∙绑定到ActiveDirectory域服务（

∙DsRoleGetPrimaryDomainInformation函数（

可以使用DsRoleGetPrimaryDomainInformation函数确定域控制器是否是RODC。

∙DsGetDcName函数（

∙DOMAIN_CONTROLLER_INFO结构（

DC定位器返回一个具有两个新标记的DOMAIN_CONTROLLER_INFO结构。

您可以检查这些标记以查看您的应用程序是绑定到可写域控制器，还是绑定到运行WindowsServer 2008的RODC。