深入剖析 SharePointSharePoint 目录集成
Pav Cherny
代码下载位置：SharePoint2008_09.exe(2,775 KB)
目录
SharePoint 目录管理服务
自定义目录管理服务
SharePoint 和 ILM
结束语
Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 包括“目录管理服务”形式的目录同步功能，可为 Active Directory 中的 SharePoint 资源来置备启用邮件功能的联系人和组对象。通过
为 SharePoint® 资源置备这些类型的收件人对象，用户可在发送文档和其他信息时，直接从 Microsoft® Outlook® 通讯簿中选择 SharePoint 库、列表和组。
SharePoint 收件人对象还提供一种方法来控制 Exchange Server 组织中的邮件传输和格式转换。此外，通过在 Active Directory® 中设置邮件发送限制，还可以防止未通过身份验证的发件人（如垃圾邮件发送者）将邮件提交到 SharePoint 库。
但是，SharePoint 的目录管理能力是有限的，并且在撰写本文时，我们假设的是使用 Exchange Server 2003 作为底层邮件传送系统。如果您目前使用的是 Exchange Server 2007 或第三方邮件传送系统，则需要通过自定义的解决方案来扩展或替换内置的目录管理功能，以获得所需级别的互操作性。
在本专栏中，我将简要介绍 SharePoint 的目录管理功能，然后讨论一种克服现有限制的方法。我的前提是内置的“目录管理服务”仅满足最基本的用户需求。包含各种邮件传送系统和目录平台的环境需要更出色的灵活性和功能。通过使用自定义的解决方案来替换内置组件，可将 SharePoint 收件人信息与提供 API 或导入功能的任意目录解决方案进行同步。
为证实这一点，我将向您展示如何通过与 Exchange Server 2007 兼容的方式来同步 SharePoint 的收件人信息。同样，您可以使用自定义的解决方案将收件人信息与 IBM Lotus Notes 或其他系统进行同步。
您还可以获得通过元目录服务（如 Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1) 中包括的 Identity Information Server）来集中化目录置备过程的能力。具体地来，我将向您展示如何将 SharePoint 与 ILM 2007 相集成，以协调 SharePoint 文档库的目录对象的置备。您可在本专栏的随附材料中找到用于构建此解决方案的工具、源代码和分步说明，该材料可从 technetmagazine.com 网站的“代码下载”部分获取。
SharePoint 目录管理服务
与 Exchange Server 不同（Exchange Server 针对几乎所有配置和收件人信息使用的都是 Active Directory），SharePoint 依赖于配置和内容数据库。因此，SharePoint 必须将启用邮件功能的库、列表和组的收件人信息从它的数据库传播到目录中。毕竟，邮件传送客户端更希望在通讯簿中查找收件人信息，而通讯簿通常是通过目录对象生成的。
SharePoint 预设包括一个用于此目的的“目录管理服务”，它是电子邮件集成 Web 服务 (SharepointEmailWS.asmx) 的一部分，在 SharePoint 3.0 管理中心中，可在“操作”页面的“传入电子邮件设置”下进行配置。图 1 展示了内置“目录管理服务”的工作原理。
图 1 SharePoint 目录管理服务体系结构（单击图像可查看大图）
当您启用一个 Web 场用于目录管理然后向库、列表或组分配一个电子邮件地址来接收邮件时（例如，通过使用 EmailSettings.aspx），会隐式调用电子邮件集成 Web 服务以在 Active Directory 中置备相应的收件人对象。首先，SharePoint 将电子邮件地址信息存储在内容数据库中。接下来，SharePoint 代表您以 Web 应用程序池帐户的身份将置备请求发送到电子邮件集成 Web 服务。如果置备请求失败，则最终在内容数据库中会出现电子邮件地址信息，但在 Active Directory 中却没有对应的收件人对象。
其他资源
- SharePoint 产品和技术网站
- Windows SharePoint Services 技术中心
- Windows SharePoint Services 开发人员中心
- Microsoft SharePoint 产品和技术团队博客
导致置备请求失败的原因有多种。最常见的原因是缺少 IIS 元数据库访问权限。由于 SharepointEmailWS.asmx 的设计目的是作为应用程序池帐户的 Web 服务，因此这一 Web 服务会检查 IIS 元数据库以查看调用者是否是应用程序池帐户，如果不是则拒绝其访问，而无论您的 SharePoint 站点和 Active Directory 权限级别如何。
然而，SharepointEmailWS.asmx 将以调用者的身份来执行此访问权限检查，因此调用应用程序池帐户需要访问元数据库以验证其自身的访问权限。这将强制您授予应用程序池帐户提升的权限以使操作能够成功。
当然，在 Web 服务器上提升的权限将成为导致安全问题的一个根源。要控制对 ASP.NET Web 服务的访问还有更好的方法。并且，SharePoint 期望在管理中心站点查找“目录管理服务”，但在被锁定以减少攻击面的 Web 场中，此站点并非永久可用。因此，如果希望在 SharePoint 生产环境中使用内置的“目录管理服务”，必须接受弱化的安全性配置。
内置“目录管理服务”基于紧密耦合的客户端/服务器体系结构这一事实带来了更大的限制。Microsoft.SharePoint.dll 直接使用 System.DirectoryServices.dll，因此无法通过实现您自己的逻辑来自定义置备过程。例如，内置的“目录管理服务”实现不会写入所有收件人属性以支持 Exchange Server 2007，并且没有选项可供自定义属性生成规则。
无法实现您自己的逻辑这一事实也意味着无法自定义置备过程以实现一些功能，例如实现自定义批准。SharePoint 支持组的批准过程，但此功能是以管理中心站点为基础的。只有 SharePoint 场管理员可以批准未决请求，但 SharePoint 管理员不必负责批准 Active Directory 置备过程。
也许更为重要的是，没有用于启用邮件功能的文档库和列表的批准过程。如果启用目录管理，则必须为 Web 场中的所有站点管理员授予权限，使其可在 Active Directory 中创建启用邮件功能的联系人和组。另外，它也无法基于组织单元 (OU) 来构建收件人管理，因为每个 Web 场的所有收件人对象都放在相同的 OU 中。
您无法将收件人对象移到另一个 OU 中，因为“目录管理服务”期望在 SharePoint OU 中查找收件人对象，因此必须在 Active Directory 中为 SharePoint 管理中心应用程序池帐户授予管理权限。此外，还无法在 SharePoint 和 Active Directory 之间实现双向同步。在 Active Directory 中更改对象属性不会将更改传播回 SharePoint 环境。
自定义目录管理服务
至此我们已经了解到内置“目录管理服务”还留有一些空间来构建额外的灵活性，接下来我们就讨论一些替代项。我要告诉大家的好消息是 SharePoint 允许您实现自己的目录管理服务。在 SharePoint 3.0 管理中心，您只需在“操作”页面的“传入电子邮件设置”下将 Web 服务注册为远程“目录管理服务”即可。
如需有关部署和注册自定义 Web 服务的详细分步说明，请参阅随附材料中的工作表 "Directory Integration Based on a Custom Directory Management Service.xps"。此外，我的自定义 Web 服务还展示了如何在不使用 cmdlet 或 Exchange 管理工具的情况下，在 Active Directory 中置备与 Exchange Server 2007 兼容的收件人对象。对应的源代码位于 EmailIntegrationService 文件夹中。图 2 显示了该解决方案的体系结构。
图 2 自定义目录管理服务体系结构（单击图像可查看大图）
自定义 Web 服务的界面必须遵从“目录管理服务”界面的要求，如 SharePoint SDK 中所述。只要在 MSDN® 网站 (msdn.microsoft.com) 中搜索 "SharepointEmailWS"，即可找到所需的全部详细信息。也可查阅随附材料内 EmailIntegrationService\App_Code 文件夹中的 Service.cs 文件。此文件可实现所需的 Web 服务界面，而置备 Active Directory 对象的实际代码位于 SPRecipient.cs 中。例如，SPRecipient.cs 中的 UpdateRecipientAttributes 函数可生成所需的 Exchange Server 2007 属性。如果希望开发自己的自定义目录管理服务，则必须替换代码文件 SPRecipient.cs。
自定义目录管理服务是一个不错的工具，可用来克服提升的权限需求，并可将 SharePoint 与第三方目录或邮件传送系统相集成。您不必通过检查 IIS 元数据库来限制 Web 服务对应用程序池帐户的访问。相反，您可以向 Web 服务的 web.config 文件添加一个 <authorization> 小节（请参阅随附材料示例）。
但是，即使这样也仍然存在许多问题，因为您无法控制 SharePoint 是否以及何时调用目录管理服务。此外，在删除启用邮件功能的文档库或列表时，SharePoint 不会调用“目录管理服务”，因此会在 Active Directory 中留下一个无效的收件人对象。无论使用的是内置“目录管理服务”还是自定义解决方案，均无法保证 Active Directory 中的收件人信息与 SharePoint 资源的一致。
SharePoint 和 ILM
要实现可靠的目录集成，应考虑部署专业的目录管理包（如 ILM）。此系统依赖于基于拉动的目录同步模型。管理代理从其连接的资源中拉出信息、将信息导入共用的元目录，然后再从元目录导出到其连接的系统。源系统通常不会将其信息推入元目录中。通过拉动信息，可确保与每个同步周期保持一致。
另一个好处是 ILM 包括许多现成的管理代理，可支持 Active Directory、Lotus Notes 和各种其他系统。您只需针对 SharePoint 实现一个自定义的管理代理，即可将 SharePoint 信息与环境中受到支持的其他目录平台进行同步。
您必须实现逻辑才能从 SharePoint 检索所需信息、保存导入文件中的信息，并将导入信息传输到元目录。但是，您无需实现该逻辑即可将该信息从元目录导出到 Active Directory 或其他目录平台。图 3 展示了如何使用 ILM 实现从 SharePoint 到 Active Directory 的同步。此外，也可以在其他方向实现同步来为目录对象置备 SharePoint 资源，但这种方法可能被认为是不必要的或可选的。
图 3 基于 Identity Lifecycle Manager 的目录集成（单击图像可查看大图）
开发 SharePoint 管理代理的一个不错起点是 Alex Tcherniakhovski 的文章 "Connecting ILM 2007 with SharePoint Services Lists"，其网址为 blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx。Alex 介绍了如何构建基于 ILM 的目录管理解决方案（依靠提交到文档库的基于 InfoPath® 的置备请求）。Alex 的管理代理从文档库中检索所有经过批准的请求并创建对应的元目录对象，然后可将这些对象导出到连接的目录中。
但在默认情况下，当您针对某个列表或组启用邮件功能时，SharePoint 不会生成基于 InfoPath 的置备请求。可通过一个自定义的目录管理服务来实现此目的，但稍后您会遇到我们之前提到过的一致性问题，因为在任何情况下 SharePoint 都不会调用目录管理服务。因此，建议您的管理代理直接从站点集合的列表和组中检索所需的 SharePoint 收件人信息。如果需要批准过程，您可在随后针对管理代理中的新资源生成基于 InfoPath 的置备请求，然后再处理所有经过批准的请求。
检索 SharePoint 信息的方法有多种。可直接从内容数据库中读取信息、使用 SharePoint 对象模型或利用 SharePoint Web 服务。
建议不要直接访问内容数据库，因为在未来的版本中，数据库的结构可能会发生改变，致使您的目录管理解决方案无法正常运行。
直接在管理代理中使用 SharePoint 对象模型同样也比较麻烦，因为对象模型要求在本地运行代码，但在您的环境中，在各个 SharePoint 场的 Web 服务器上安装 ILM 可能会使目录管理基础结构变得更加复杂。
您可能会考虑使用 SharePoint Web 服务，但这会引发另一个难题，因为通过 SharePoint Web 服务无法轻松访问所需的信息（如 SharePoint 组的电子邮件地址信息或“传入电子邮件服务器显示地址”）。
最终看来，似乎最好的办法是实现一个自定义 SharePoint Web 服务，然后使用 SharePoint 对象模型来检索所需的信息，从而以 XML 文档的格式将其返回给调用者。现在，可通过自定义 SharePoint Web 服务的单个实例来集中化 ILM 的部署并集成任意数量的场和站点集合，如图 3 所示。
还有一个值得一提的方面，即基于 ILM 的目录集成并不会免去对自定义目录管理服务的需要。此自定义服务不需要执行任何操作，因为 ILM 会置备目录对象，但您必须提供一个自定义服务，以便能够在 SharePoint 3.0 管理中心启用目录管理。否则将无法实现一些功能，例如，您将无法首先向组分配电子邮件地址。图 4 显示了最终解决方案的体系结构。
图 4 基于 Web 服务的 SharePoint 目录集成（单击图像可查看大图）
通过在 web.config 文件中设置 OpMode 参数 (<add key="OpMode" value="dummy"/>)，可将随附材料中包括的自定义目录管理服务变成虚拟服务。在此配置中，对于没有执行任何操作的置备调用，自定义服务会始终返回 SUCCESS 作为响应。
此外，自定义服务会公开一个 ResolveUsers 方法，SharePoint 管理代理可调用此方法将基于 NetBIOS 的用户帐户名称解析为可分辨名称（在置备组时必须执行此步骤）。（SharePoint 以基于 NetBIOS 的用户帐户名称列表的形式返回组成员身份信息，但 Active Directory 需要的是可分辨名称。）就是这些！有关如何部署最终解决方案的详细信息，请参阅随附材料中的 "Configuring Directory Integration based on ILM 2007.xps"。
WSS 3.0 和 MOSS 2007 包括一个“目录管理服务”，可将 SharePoint 与 Exchange Server 2003 相集成，以实现基于邮件传送的跨平台协作。
但是这存在着诸多限制。用户必须将内置的“目录管理服务”更换为自定义解决方案。您也可以使用专业的目录管理解决方案（如 ILM）将 SharePoint 集成到目录管理基础结构中。这将提供最高级别的灵活性，并有助于确保在基于拉动的同步模型中信息的一致性。
Pav Cherny 是一位 IT 专家兼撰稿人，专门研究 Microsoft 协作与统一通信技术。他的出版物包括白皮书、产品手册和书籍，其内容主要介绍 IT 运营和系统管理。Pav 是 Biblioso Corporation 的总裁，该公司主要经营托管文档和本地化服务。