从Internet连接到自动发现服务的支持场景

    如果您通过Outlook Anywhere（以前称为RPC over HTTP）来为Microsoft Exchange提供从外部访问，您必须在客户端访问服务器上安装一张有效的安全套接字层证书，通过下面四种情景中的任何一种。此外，在自动发现服务能够提供正确的外部URL给客户端之前，您必须正确配置您的Exchange服务，例如可用服务。当客户端尝试连接的您的Microsoft Exchange邮件环境的时候，客户端使用用户的电子邮件中的SMTP域地址来找到Internet上的自动发现服务，根据您是否将自动发现服务配置和您组织的外部DNS主机名称不一样的名称，自动发现服务的URL如下：

    · https://<smtp-address-domain>/autodiscover/autodiscover.xml

    · https://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml.

    例如，如果用户的电子邮件地址为kwekua@contoso.com，自动发现服务应该在https://contoso.com/autodiscover.xml或者https://autodiscover.contoso.com/autodiscover/autodiscover.xml处查找。这意味着，在您的外部DNS区域中，您必须为自动发现服务添加一个主机记录。

    有几种方法可以配置您的客户端访问服务器，用来支持来自Internet到自动发现服务的连接。在比较这些方法的好处和坏处之后，您可以决定选择哪种方法。

    场景1 使用一张支持多个DNS名称的证书

    我们建议您使用支持主题备用名称字段的统一通讯证书，在同一张证书中提供所有必须的DNS名称。使用统一通讯证书，可以减少配置和管理自动发现服务和Exchange服务URL的复杂性。然而，使用统一通讯证书可能要增加成本，因为这种证书要比您已经拥有的单名称证书要贵许多。

    获取统一通讯证书

    目前有许多第三方的证书授权机构支持主题备用名称，具体的名单您可以参考下面的链接：

    http://support.microsoft.com/kb/929395/en-us

    或者，您也可以安装Windows证书服务，创建并安装您自己的安全套接字层证书，用来包含多个DNS名称。尽管在开始这是最小代价的方法，您将承受额外的管理工作，分发和维护用户的根证书，以便那些没有加入域的客户端，能够将证书链添加到信任的根证书存储中，此外，您的Outlook Anywhere用户必须手动在他们的远程工作站上安装根证书，Exchange ActiveSync用户必须手动在他们的移动设备上安装根证书。

    场景2使用一个单一名称的证书

    如果您不计划支持通过Outlook Anywhere从Internet上连接到您的Exchange邮件环境，对于加入域的Outlook 2007客户端，最简单的方法是在缺省的Web站点上使用一张单一名称证书。我们建议您立即使用一张标准的证书来替换自签名的证书。该标准证书颁发给公用名称或者FQDN，即您的远程用户通过Outlook Web Access或者Exchange ActiveSync连接到Exchange，例如：mail.contoso.com。

    注意：

    在这种场景中，您必须在活动目录中的SCP对象中更新自动发现URL和Exchange服务的内部URL，以便Outlook客户端不会收到下面的错误：

    安全证书名称无效或者不能与站点的名称匹配

    场景3使用两张单一名称证书

    有时候您不能使用一张证书支持多个DNS名称，例如，您想从以前版本的Exchange导出一张已经存在的证书来替换自签名的证书，或者在没有完全理解Exchange 2007自动发现服务的证书要求之前，您已经购买了一张新的单一名称证书。如果是这种情况的话，通过部署备用方法能够让您纠正这样的情景，最终让您实现相同的功能。一个选择是获取第二张证书，并安装在第二个Web站点上，该站点专门供自动发现使用。

    在这种情况下，一张颁发给公用名称的证书被用作来自Internet连接的客户端的接入点，例如，mail.contoso.com。第二张证书拥有参考自动发现服务的FQDN的公用名称，例如，autodiscover.contoso.com。该选项要求两个单独的Web站点和公共IP地址。缺省的Web站点将托管您主要的Exchange功能和服务，比如Outlook Web Access和Exchange ActiveSync，而第二个Web站点将被用来托管自动发现服务。

    场景4重定向自动发现服务

    直到Microsoft知识库文章939184描述的Outlook 2007累积更新的发布，以及前面提到的场景2使用单一名称证书，这种部署场景是，也许仍然是理想的解决方法，对于象托管Exchange 2007的环境。通过重定向使用自动发现服务也许是理想的解决方法，因为有一些DNS提供商不支持SRV记录。然而，那些没有托管多个域的组织可以使用这种部署。通过该选项，您在缺省的Web站点上安装一张单一名称的证书，并创建另外一个不包含证书的Web站点，加入域的客户端通过使用SCP对象继续找到自动发现，并且不会收到任何安全告警，只要保存在SCP对象中的用来连接到自动发现服务的URL，已经被更改指向缺省Web站点上的证书的FQDN。对那些来自Internet连接的客户端，使用DNS最初查找自动发现的时候会失败，就象前面描述过的自动发现服务如何工作的一样。然而，在连接到自动发现服务失败之前，Outlook将使用HTTP（不是HTTPS）尝试通过另外一种方法来连接到自动发现URL，并连接到自动发现Web站点，接着被重定向到缺省Web站点下的托管的自动发现服务。当这些基于Internet的Outlook客户端连接到该重定向站点的时候，它们将看到一个可以忽略的告警消息让他们去验证他们被重定向到一个信任的URL。在这种情况下，您必须建议您的用户接受该警告消息，并允许Outlook连接到该信任的URL。

    注意：和使用两个单一名称证书类似，该解决方法也要求为第二个Web站点指定一个公共的IP地址。

总结：

    前面的所有场景都被Microsoft支持，但是复杂程度不一样。部署所需要花费的努力和长期管理每个方案将导致总体的拥有成本的增加取决与您的环境。下面的表1描述了每个方案的过程和条件：

    注意：

    不管您使用哪种部署，在替换缺省的自签名证书的时候，您的内部Outlook 2007用户也许会报告他们收到下面的安全警告，在启动Outlook的时候：

    安全证书的名称无效或者不能与站点的名称匹配

 

原文地址：http://blog.ixpub.net/13762133/viewspace-239444