在上一篇咱们聊了一下CAS的架构，这一章就来聊聊CAS的验证方法
很多管理员从未纠结过客户端的验证问题，因为Exchange的默认设置在单一环境中完全够用了。当拓扑变得更复杂，环境中开始出现一些其他版本的Exchange时候，就得重视起这个玩意。
选择验证方法的重要性在于，其他的服务器都指望着着CAS角色发送过来的请求符合特定的验证方法。如果用户的邮箱处于Exchange2013的MBX上，那么CAS可以直接将请求代理给HTTP代理终结点，如果处于Exchange2007的或者是Exchange2010的MBX上，CAS会代理该请求至Outlook Anywhere终结点，或者更具体的说，2013的CAS会代理Outlook Anywhere 请求到旧版本的/rpc/虚拟目录。所以在虚拟目录上的设置就代表了下一层的服务器将接受怎样的身份验证方法。这也就是为啥你得在旧版本的CAS上面全部打开Outlook Anywhere，哪怕是内部站点。
一共有3个地方你可以指定CAS的验证方法，并且它们是相互独立的。分别是内部客户端、外部客户端、或者是虚拟目录本身。（关于内部与外部客户端，我们下一篇会具体聊）
Exchange 2013支持的验证方法并不都是为On-premises客户准备的，比方说Office 365允许Microsoft Account验证（就是Live IDs登陆，或者更官方一点叫Microsoft Online Services IDs），但是在on-premises的环境就没办法用了，验证方法类型有如下几个：
Basic 基本验证：使用明文传递用户认证信息，要使用它请配合SSL或者TLS（Secure Sockets Layer/Transport Layer Security）
Kerberos验证：是Windows原生的 客户端-服务器 验证交互模型。当用户登录到一个域控的时候，他会收到一个Kerberos令牌，然后传递给需要认证该用户的服务器或者应用，以使这些应用和服务器不用再要求用户重新输入认证信息。Kerberos由MIT设计，用来在非信任的网络上传递安全网络认证信息，它并不会将用户名和密码以明文形式暴露出来。但是，Kerberos验证要求用户连接到一个叫Kerberos Key distribution Center令牌分发中心也就是KDC服务器，在windows层面上，这意味着要求客户端能够连接到域控。这在某些场景下就是一个限制：比方Exchange 客户端处于防火墙后面，或者是没有加入域，亦或者没有运行windows操作系统。
NTLM验证：NTML验证是Windows在没有Kerberos验证之前所使用的验证方法，比起中央管理化的KDC，NTLM依赖于加密的“挑战”(challenge)与响应序列。不同于Kerberos认证信息的是，NTLM认证令牌只对最初发出请求的服务器有效。（关于NTML验证与kerberos验证的对比，相信已经有很多高手写出了详细的过程。后续如果有必要我也会聊聊）
集成的windows身份验证（IWA）：是微软在IIS中对开启Kerberos和NTML验证方法的设置的统称。IIS默认支持IIS用户使用该方法来进行 客户端到服务器的验证，使用该方法，服务器请求和接受Kerberos验证，同时也接受那些无法使用Kerberos验证的客户端使用NTML验证。
基于表单的验证（FBA）：最常见使用该验证方法的就是Outlook Web App，用户在打开OWA的时候会看到一个登陆表单，然后用户输入认证信息，浏览器发起一个HTTP POST请求到Exchange服务器的HTTPS Url上，所以该认证信息在传输过程中是加密的。然后该服务器找到域控，对该认真信息尽心验证，如果验证通过，服务器就为用户生成一个加密的cookie，接下来用户接受该cookie，并在随后的请求里都带着cookie，以表明这是一个已经被验证过的用户请求。有些反向代理解决方案（比方TMG）可以构架它们自己的FBA验证页，用来在允许用户连接到Exchange之前进行预验证。
上述的这些验证类型，在不同的应用场景中很容易被弄混淆，或者说是弄乱了。举个例子，在Exchange2013当中要使用Set-OutlookAnyWhere命令来设置Outlook Anywhere虚拟目录的验证方式，会看到以下几种选项：
-ExternamClientAuthenticationMethod: 该参数用来设置接收来自External URL即外部URL连接的用户请求时使用的验证方法。
-InternalClientAuthenticationMethod: 该参数用来设置接收来自Internal URL即内部URL连接的用户请求时使用的验证方法。
注意：以上这些选项的参数，你只能为每一种用户类型设置一种验证方法
-IISAuthenticationMethods: 该参数规定了IIS可以接受的多种验证方法。看起来不太必要，毕竟在前面的两个参数里，已经可以单独设置内部用户与外部用户的验证方式，为何还要为IIS单独做一个设置呢？考虑这样一个场景，如果你的外部用户和CAS之间存在一个防火墙，而这个防火墙是可以转换验证类型的，比如TMG可以从客户端接受基本类型的验证，然后用IWA重新验证并提交给CAS，这个时候，IIS就得设置为接受IWA验证了。
-DefaultAuthenticationMethod: 这个参数作用是一键统一设置以上三个参数，设置成一样的验证方法。
如果你为一台服务器的OutlookAnywhere配置了基本验证方法，那么IIS只会在/rpc/虚拟目录里接受基本验证方法。为了接受Exchange2013的代理请求，/rpc/虚拟目录也需要接受IWA验证方法；否则验证会不通过。然而，直接针对IIS进行设置，Exchange会覆写该设置。所以如果我们要修改所有旧版本的CAS服务器使CAS之间的内部连接都使用Kerberos，外部客户端连接继续使用basic，我们要敲的命令如下(注意：这里的场景是需要在老版本的CAS服务器上进行设置，所以这条命令是EX2010版本的，关于该命令更多参数：http://powershell.ws/command/Set-OutlookAnywhere/)：
Set-OutlookAnywhere -Server CASservername -ClientAuthenticationMethod Basic -IISAuthenticatioinMethods Basic, NTLM
验证类型方法我们就聊到这里，作为一个管理员，不光要挑选正确的验证方法，还要注意这些验证类型应用的地方，下一篇我们就讲一讲Exchange2013的CAS角色如何对内部和外部进行相应设置。
最后照例打一下广告：
你身边的 IT 加油站！
也欢迎关注 ITCharger 的微信公众号，每周更新的文章也会在这上面发布; 同时也有其他关于微软私有云技术的文章的分享。
