「深入 Exchange 2013」03 内部vs外部

这一章我们来讲内部访问与外部访问。

CAS是干嘛的,还不就是为了给企业网络里的内部用户,或者是给穿过防火墙连接进来的外部用户提供服务的。一些组织可能对内部和外部用户的访问都不设限制,也有一部分组织限制了外部用户的连接。也就是说,这些部署了Exchange的组织,都有这样一个可以灵活控制内/外访问的需求。

内部vs外部最主要的不同点就是客户端以哪种URL连接,并且用哪种验证方法进行身份验证。在CAS上这些设置是独立于每一种协议的,比方说当前我要查看某前端上OutlookAnyWhere的内部与外部设置,那么我输入以下命令即可查看:

如图中返回的信息,是安装完成之后的默认设置。从中我们可以看到,内部和外部客户端使用了不同的验证方法,并且默认的是没有配置外部主机名。对比一下Get-WebServicesVirtualDirectory命令。

注意这里,内部与外部URL就拥有不同的值,虚拟目录的验证方法也变成了一组验证方法,而并非上面的一种。为什么会有这些不一样呢?

外部与内部URL

Autodiscover会在Outlook Anywhere设置、OutlookWebApp、EWS、EAS以及其他的虚拟目录里向客户端发布外部与内部的URL。然后由客户端决定用哪些URL来进行连接,客户端必须通过它对自身网络位置的了解,或者干脆就按顺序尝试这两个URL,这了两种办法来进行判断。

Exchange 2013默认将这些服务的内部URL设置成服务器名加上这些虚拟目录的路径,比如说EWS的就是https://CAS01.contoso.com/EWS/Exchange.asmx。默认情况下外部URL是空白的,如果你需要允许外部用户访问,则需要手动配置该URL。

外部与内部验证方法

随着你设置好了外部与内部的URL,Exchange会自动的生成一些受客户端终结点支持的身份验证方法设置。这些设置得仔细考虑清楚再下手修改,不然会出现一些比较蛋疼而且影响范围广的问题,比如Outlook或者OWA一直要求重复验证。

注意:在Exchange 2013 RTM和Exchange 2013 CU1版本中,如果用户的连接从一个面向外部的CAS被重定向到另一个CAS上的时候,有可能会出现再次验证的提示框。但是在Exchange 2013 CU2中,用户针对OWA的验证身份信息已经可以被重复发送了,所以在上面的场景里,用户只用登陆一次即可。

当然,也有一些场景下你必须更改这些验证方法,那就是在多版本混合部署环境中。比方说,在一个已有的Exchange 2007或是2010场景里,加进来一台Exchange 2013的CAS,你首先得做设置,把所有的CAS流量全部丢到Exchange 2013的CAS上,因为它能够进行重定向和代理这些流量到旧版本的服务器上;要达到这个目的,你就得在环境里所有的(任何版本)CAS服务器上,为所有的客户端使用Basic验证,为所有的虚拟目录加上NTML验证。Basic验证是所有基于HTTP协议的通用方法,所以得在EWS、EAS和Autodiscover上加上这个。

注意:如果你对Exchange 2013 CAS上的虚拟目录进行了一些改动,或是误操作了一些东西,微软专门准备了一篇大师级的文档,包括了这些虚拟目录的默认权限设置与默认的Url设置:http://technet.microsoft.com/en-us/library/gg247612(v=exchg.150).aspx .

管理虚拟目录设置

在一台刚刚装好的全角色Exchange 2013服务器上,默认存在7个虚拟目录:

Autodiscover,ECP,EWS,EAS,OAB,Outlook Web App,以及Windows PowerShell。有两种方法可以对这些虚拟目录的身份验证方法与Url设置进行修改。

第一:使用Cmdlet,例如Set-EcpVirtualDirectory,Set-OabVirtualDirectory等等。

第二:使用EAC,如下图,在服务器 - 虚拟目录的设置里。双击你要修改的虚拟目录名称即可打开属性窗口进行修改。

需要注意的是,每一个虚拟目录都有一些自己特定的设置,比如OWA和ECP的身份验证里头都有FBA验证方法,而其他的没有。

下图所示的设置,即通过输入一个统一的外部访问域名,一次性配置好所有的虚拟目录的外部URL。

OK,内部和外部访问就讲到这里,还有一些东西我们会放到讲Autodiscover的时候再说。下一章我们聊聊CAS的负载均衡,与客户端关联性。

最后照例打一下广告:

http://www.itcharger.com/

你身边的 IT 加油站!

也欢迎关注 ITCharger 的微信公众号,每周更新的文章也会在这上面发布; 同时也有其他关于微软私有云技术的文章的分享。

时间: 2024-10-18 14:30:46

「深入 Exchange 2013」03 内部vs外部的相关文章

「深入 Exchange 2013」MAPI over HTTP实战配置

在前面我们聊Outlook Anywhere的文章里头,我提到了MAPI over HTTP这个Exchange Server 2013 SP1中新增加的功能,这次这篇文章咱们就详细说说这个新的传输协议是什么,以及实战如何去配置它. 什么是MAPI/HTTP,有什么好处? 以前版本中(Exchange 2010),用的是RPC over HTTP(外部网络outlook anywhere)以及RPC Direct(内部网络)连接,Exchange 2013里,所有的连接都通过Outlook An

「深入 Exchange 2013」07 Autodisocver

微软在Exchange 2007里引入Autodiscover自动发现服务,意图去简化用户配置Outlook与Exchange ActiveSync的过程.Outlook的配置文件虽然可以手动配置,但是从Autodiscover会覆盖手动配置的选项,在你做出一些更改的时候,明显批量的自动下发配置更方便. Autodiscover还负责告诉Outlook当前的邮箱位置信息,Outlook会在与邮箱断开连接之后重新尝试Autodiscover.总而言之,这玩意儿跟Outlook Anywhere一样

「深入 Exchange 2013」05 Outlook Anywhere

这一章来给大家讲Outlook Anywhere,概念比较重要,但是容易混淆,大家得仔细阅读,仔细区分. RPC over HTTP/HTTPS 首先得理解,为何在Exchange 2013当中,仅支持Outlook Anywhere的Outlook MAPI客户端连接方式.早期版本的MAPI访问依赖的是TCP的RPC协议直接连接到MBX服务器,而Exchange2013则使用HTTPS封装的RPC协议.这就意味着,如果你在当前是Ex2007或者Ex2010的环境当中,再增加一台Ex2013的服

「深入 Exchange 2013」14 接收连接器

接收连接器在概念上要比发送连接器简单一点,每个接收连接器只用侦听来自你分配给它的ip地址和端口的请求,然后将SMTP会话传送出去即可.接收连接器使用权限组来决定哪些发送者被允许使用该连接器,权限组则是预先定义好的一系列安全主体对某个对象(当前场景下则是接收连接器)所拥有的权限,比如说是"任何有邮箱账户的用户"即Exchange Users,或者是"组织里的任何Exchange Server"即Exchange Servers.这种模型类似于NTFS权限模型,先把用户

「深入 Exchange 2013」09 证书

今儿咱们来聊Exchange里的证书,CAS与MBX角色都有用到证书的地方,只是CAS角色更依赖证书一些,在一台Exchange服务器刚刚安装完成的时候,安装程序会自动生成一张自签名证书,这张自签名证书往往并不满足咱们的需求,所以咱们一般会向企业CA再去针对Exchange所涉及到的多个IIS服务的DNS备用名称申请合适的额证书. Exchange在哪些地方用到证书 1. 让客户端验证服务器的身份.这是最常规的用法,大多数管理员可能都碰到过证书名称不匹配引起的客户端报错. 2. 服务器去验证客户

「深入 Exchange 2013」15 TLS传输层安全

默认情况下,SMTP流量是不被加密的,这就导致在公网上进行邮件沟通就像是在广播一样,任何人拦截到该邮件都可以轻而易举的读取其内容.但是现实场景中有许多敏感信息是通过邮件来进行发送的,所以其中一种保护邮件安全的方法就是使用传输层安全协议(Transport Layer Security)来提供SMTP流量在传输中的加密,受TLS保护的SMTP流量可以让拦截/窃听者无法读取到SMTP流量的内容,但是它只提供传输过程中的保护,对于已经到达目标服务器,或者是在发件方本地服务器的邮件则没法提供保护. 有两

「深入 Exchange 2013」10 传输服务简述

前面的内容里面,已经为大家比较深入的介绍了Exchange2013的客户端访问角色涉及到的诸多细节.在接下来的章节里就跟大家聊一聊Exchange 2013里的传输服务,这一节总共的内容都比较多,而且更偏向理论,所以咱先来一篇简述,然后再分拆开一个一个讲. 在之前的版本中,由Exchange2007引入了Hub Transport(集线器传输)角色作为所有邮件信息的传递中枢,任何发送或者接收到的邮件都必然会经过至少一个Ex2010与Ex2007的集线器传输角色:那么在Exchange2013当中

「深入 Exchange 2013」08 代理、重定向、共存

回顾一下以前讲过的东西,CAS并不直接为客户端提供邮箱连接,而是以两种方式来保证客户端连接到正确的MBX:代理或和重定向.在代理连接当中,CAS接收客户端连接并且转发给恰当的服务器:在重定向连接当中,CAS仅仅是回应客户端一个恰当的服务器的FQDN以让客户端再次发起连接. 在Exchange2013的环境中,CAS只在少数几种情况下才会进行重定向动作.这是由于重定向迫使客户端进行再次连接,这种情况不是所有的客户端种类都可以接受的. 代理 CAS代理动作在Ex2010与Ex2007被设计的略微复杂

「深入 Exchange 2013」12 传输架构Part2

本章接着上一章,简单说一下四个组件在Exchange Server 2013整个传输架构当中各自负责什么. 前端传输服务(The Front End Transport Service) FET服务在整个传输里边似乎工作量是最小的:它负责所有客户端的入站与出站SMTP流量,FET是SMTP流量通过防火墙之后所接触到的第一个组件,和其他在CAS上运行的服务组件一样,FET服务不存储任何邮件数据,也不维护任何的队列,以及提供基本上是无状态的客户端连接(对客户端连接不维护任何的状态信息).但是,FET