Outlook登录过程

一   测试环境说明

Exchange服务器版本：Exchange 2013 SP1

服务器操作系统版本：Windows Server 2012 R2 DataCenter

Outlook版本：Microsoft Outlook 2013

数据来源：从客户端进行抓取数据流

 

二   数据抓取及分析过程

2.1         TCP三次握手

Outlook打开的第一步就是进行身份认证，为了安全，所以必须要进行加密的TCP连接，所以在进行身份认证之前，Outlook会先与域控制器进行三次握手以进行建立会话。

可以看到的是Client首先通过一个高位的动态TCP端口向域控制制器DC01的389号端口发起一个SYN请求，这个就是TCP三次握手的第一次。这个三次握手的过程目的就是与域控制器的389号端口建立起会话通道，因为389号端口就是LDAP协议的端口，用于身份认证的。

                                               

 

到三次握手完成之后，就能看到Client与域控制器DC01之间有一系列的走LDAP协议的数据流，这个就是身份认证的过程。

 

2.2         协商

 

建立会话之后，Outlook与Exchange服务器就会进行一系列的协商。协商的内容大概是一些接下来会话所用到的信息，如两者兼容的最高的加密算法，版本，以及密钥传递、检验算法等等。并且可以看到走的协议也是TLSv1.2，是经过加密的。

这个过程之后就要重启Outlook，也就是配置文件配置完之后进行重启Outlook的那一步。

 

 

 

2.3         Kerberos身份认证

重启Outlook之后，Outlook会再进行一次身份认证，不过这次所用的方法是Kerberos，因为之前已经用LDAP认证过一次。

当所有的都完事之后，Outlook就可以与Cas服务器进行软件层面的通信。

 

2.4         Http协议

当前面的准备工作都完成之后，可以看到接下来会有一些走HTTP协议的数据流。因为当Outlook使用Exchange模式来与服务器进行通话时，也就是MAPI模式，但是MAPI模式是动态端口，所以它又被封装在Http里面，于是乎才会看到客户端与Cas服务器是通过Http协议来进行会话的

所以，当我把80端口给禁用掉时，就会出现以下的情况

 

而如果是第二次登录的话就会发现Outlook的状态为已断开。

 

对于这种包，用Follow TCP Stream的方式来看有时候更加的直观。

 

 

从这里面可以获取到的信息有：

RPC_IN_DATA

虽然抓到的包所走的协议的HTTP协议，但里面实质是RPC，并且可以知道调用的哪一台服务器，对，就是[e-mail]这台服务器，可以在Outlook的账户信息里看到。并且，这个是RPC_IN_DATA，也就是说会有个RPC_OUT_DATA的阶段

 

 

Conection:Keep-Alive

连接方式是保持在线，也就是说Exchange模式的连接一直都是保持在线的，这与POP3的方式有所不同，所以从这里可以判断出outlook的连接方式是哪一种。

 

Cookie & OS

这里可以看到Outlook的版本信息，Outlook 15.0.* ，这个就是Outlook2013的版本，而OS 6.2.9200，要么就是win8.1，要么就是server2012 r2

 

Host & Authorization

Host 就是CAS客户端访问服务器，而Authorization就是身份验证以为加密的方法。

 

 

就是这样，Outlook与Exchange服务器之间进行不间断的通讯

打开RPCH协议的包，可以明确地看到Outlook与Exchange服务器之间走的是RPC-over HTTP，也就是之前说的把RPC封装在HTTP里面。

三   常见的一些错误

3.1       身份验证过程出错

经过上面的一些抓包分析，我们已经知道Outlook的身份验证是通过LDAP协议走TCP389端口的，如果把这个TCP389号端口禁用掉会发生什么事？

l  禁掉TCP389号端口

把TCP389号端口禁掉之后，可以看到数据流中已经没有走LDAP协议的包了，但结果是Outlook依然可以登录，唯一不同的地方就是不能进行自动发现而已。

 

虽然没有的LDAP协议的包，但数据流中多了一些走CLDAP的包。

 

并且打开其中的一个可以看到，走的是UDP协议，端口是389

 

这个就是Outlook在禁掉TCP389号端口后也能进行登录的原因。

CLDAP，全称为 Connect-less Lightweight Directory Access Protocol，无连接的轻型目录访问协议，相对的，LDAP，Lightweight Directory Access Portocol，就是有连接的轻型目录访问协议。那么这个有无连接在区别是在哪里？就是一开始的TCP的三次握手。

 

当TCP的三次握手失败时，Outlook就会放弃用LDAP来进行身份验证，改为用CLDAP协议进行身份验证。

 

 

l  禁掉UDP389号端口

那么，如果把TCP和UDP的389号端口都禁掉了，outlook还能不能进行登录呢？

 

用 tcp.port == 389 || udp.port == 389 来进行包的过滤，可以看到现在的数据流中已经没有任何LDAP或CLDAP的协议在走了。但结果是Outlook还是可以进行身份验证并进行登录。

 

这时候仔细看一下数据流，可以看到有一些很特殊的DNS数据包在。仔细看一下里面的内容，可以看到有“SRV_ldap._tcp…”的字样，提前SRV就很熟悉，就是资源记录。这样换句话说，就是当LDAP和CLDAP都走不通的时候，Outlook就会通过DNS去查询SRV记录，来获取相关的资源，从而进行身份认证。

 

 

l  禁止TCP&UDP 53号端口

那么，如果连DNS协议也走不通呢？Outlook又会出现怎么样的情况？

当连DNS协议都走不通了，这时候Outlook就真的是连不上服务器了，就会出现以下的错误。当然端口不通是一个原因，如果DNS的SRV记录里没有相关的资源记录，我想也会造成一样的错误。

 

l  总结一下这个过程：

i)             禁掉TCP 389端口，自动发现不工作。

ii)            禁掉UDP389端口，登录过程变得很慢。

iii)           禁掉TCP&UDP53号端口，Outlook完全登录不上。

3.2       连接出错

Outlook的连接方式也就两种，Exchange模式和POP3模式，这里先对Exchange模式进行说明。上面抓包的过程也知道，Outlook是把RCP封装在HTTP里面，也就是把80/443端口给封掉就行了。

在未配置证书的环境下，Outlook是走不加密的连接，那么只要把80端口禁掉就可以，但配置了证书的环境下，要同时禁掉80和443号端口才会出现下面的错误，因为如果443走不通，Outlook会切换到80进行通讯，只有把两个端口都禁止，才能隔断通讯