这一章我们来讲内部访问与外部访问。
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的负载均衡,与客户端关联性。
最后照例打一下广告:
你身边的 IT 加油站!
也欢迎关注 ITCharger 的微信公众号,每周更新的文章也会在这上面发布; 同时也有其他关于微软私有云技术的文章的分享。