Exchange服務(wù)器版本：Exchange 2013 SP1
服務(wù)器操作系統版本：Windows Server 2012 R2 DataCenter
Outlook版本：Microsoft Outlook 2013
數據來(lái)源：從客戶(hù)端進(jìn)行抓取數據流
Outlook打開(kāi)的第一步就是進(jìn)行身份認證，為了安全，所以必須要進(jìn)行加密的TCP連接，所以在進(jìn)行身份認證之前，Outlook會(huì )先與域控制器進(jìn)行三次握手以進(jìn)行建立會(huì )話(huà)。
可以看到的是Client首先通過(guò)一個(gè)高位的動(dòng)態(tài)TCP端口向域控制制器DC01的389號端口發(fā)起一個(gè)SYN請求，這個(gè)就是TCP三次握手的第一次。這個(gè)三次握手的過(guò)程目的就是與域控制器的389號端口建立起會(huì )話(huà)通道，因為389號端口就是LDAP協(xié)議的端口，用于身份認證的。
到三次握手完成之后，就能看到Client與域控制器DC01之間有一系列的走LDAP協(xié)議的數據流，這個(gè)就是身份認證的過(guò)程。
建立會(huì )話(huà)之后，Outlook與Exchange服務(wù)器就會(huì )進(jìn)行一系列的協(xié)商。協(xié)商的內容大概是一些接下來(lái)會(huì )話(huà)所用到的信息，如兩者兼容的最高的加密算法，版本，以及密鑰傳遞、檢驗算法等等。并且可以看到走的協(xié)議也是TLSv1.2，是經(jīng)過(guò)加密的。
這個(gè)過(guò)程之后就要重啟Outlook，也就是配置文件配置完之后進(jìn)行重啟Outlook的那一步。
重啟Outlook之后，Outlook會(huì )再進(jìn)行一次身份認證，不過(guò)這次所用的方法是Kerberos，因為之前已經(jīng)用LDAP認證過(guò)一次。
當所有的都完事之后，Outlook就可以與Cas服務(wù)器進(jìn)行軟件層面的通信。
當前面的準備工作都完成之后，可以看到接下來(lái)會(huì )有一些走HTTP協(xié)議的數據流。因為當Outlook使用Exchange模式來(lái)與服務(wù)器進(jìn)行通話(huà)時(shí)，也就是MAPI模式，但是MAPI模式是動(dòng)態(tài)端口，所以它又被封裝在Http里面，于是乎才會(huì )看到客戶(hù)端與Cas服務(wù)器是通過(guò)Http協(xié)議來(lái)進(jìn)行會(huì )話(huà)的
所以，當我把80端口給禁用掉時(shí)，就會(huì )出現以下的情況
而如果是第二次登錄的話(huà)就會(huì )發(fā)現Outlook的狀態(tài)為已斷開(kāi)。
對于這種包，用Follow TCP Stream的方式來(lái)看有時(shí)候更加的直觀(guān)。
從這里面可以獲取到的信息有：
RPC_IN_DATA
雖然抓到的包所走的協(xié)議的HTTP協(xié)議，但里面實(shí)質(zhì)是RPC，并且可以知道調用的哪一臺服務(wù)器，對，就是226838cd-9d60-4f51-9e33-70506d2add34@contoso.com這臺服務(wù)器，可以在Outlook的賬戶(hù)信息里看到。并且，這個(gè)是RPC_IN_DATA，也就是說(shuō)會(huì )有個(gè)RPC_OUT_DATA的階段
Conection:Keep-Alive
連接方式是保持在線(xiàn)，也就是說(shuō)Exchange模式的連接一直都是保持在線(xiàn)的，這與POP3的方式有所不同，所以從這里可以判斷出outlook的連接方式是哪一種。
Cookie & OS
這里可以看到Outlook的版本信息，Outlook 15.0.* ，這個(gè)就是Outlook2013的版本，而OS 6.2.9200，要么就是win8.1，要么就是server2012 r2
Host & Authorization
Host 就是CAS客戶(hù)端訪(fǎng)問(wèn)服務(wù)器，而Authorization就是身份驗證以為加密的方法。
就是這樣，Outlook與Exchange服務(wù)器之間進(jìn)行不間斷的通訊
打開(kāi)RPCH協(xié)議的包，可以明確地看到Outlook與Exchange服務(wù)器之間走的是RPC-over HTTP，也就是之前說(shuō)的把RPC封裝在HTTP里面。
經(jīng)過(guò)上面的一些抓包分析，我們已經(jīng)知道Outlook的身份驗證是通過(guò)LDAP協(xié)議走TCP389端口的，如果把這個(gè)TCP389號端口禁用掉會(huì )發(fā)生什么事？
l 禁掉TCP389號端口
把TCP389號端口禁掉之后，可以看到數據流中已經(jīng)沒(méi)有走LDAP協(xié)議的包了，但結果是Outlook依然可以登錄，唯一不同的地方就是不能進(jìn)行自動(dòng)發(fā)現而已。
雖然沒(méi)有的LDAP協(xié)議的包，但數據流中多了一些走CLDAP的包。
并且打開(kāi)其中的一個(gè)可以看到，走的是UDP協(xié)議，端口是389
這個(gè)就是Outlook在禁掉TCP389號端口后也能進(jìn)行登錄的原因。
CLDAP，全稱(chēng)為 Connect-less Lightweight Directory Access Protocol，無(wú)連接的輕型目錄訪(fǎng)問(wèn)協(xié)議，相對的，LDAP，Lightweight Directory Access Portocol，就是有連接的輕型目錄訪(fǎng)問(wèn)協(xié)議。那么這個(gè)有無(wú)連接在區別是在哪里？就是一開(kāi)始的TCP的三次握手。
當TCP的三次握手失敗時(shí)，Outlook就會(huì )放棄用LDAP來(lái)進(jìn)行身份驗證，改為用CLDAP協(xié)議進(jìn)行身份驗證。
l 禁掉UDP389號端口
那么，如果把TCP和UDP的389號端口都禁掉了，outlook還能不能進(jìn)行登錄呢？
用 tcp.port == 389 || udp.port == 389 來(lái)進(jìn)行包的過(guò)濾，可以看到現在的數據流中已經(jīng)沒(méi)有任何LDAP或CLDAP的協(xié)議在走了。但結果是Outlook還是可以進(jìn)行身份驗證并進(jìn)行登錄。
這時(shí)候仔細看一下數據流，可以看到有一些很特殊的DNS數據包在。仔細看一下里面的內容，可以看到有“SRV_ldap._tcp…”的字樣，提前SRV就很熟悉，就是資源記錄。這樣換句話(huà)說(shuō)，就是當LDAP和CLDAP都走不通的時(shí)候，Outlook就會(huì )通過(guò)DNS去查詢(xún)SRV記錄，來(lái)獲取相關(guān)的資源，從而進(jìn)行身份認證。
l 禁止TCP&UDP 53號端口
那么，如果連DNS協(xié)議也走不通呢？Outlook又會(huì )出現怎么樣的情況？
當連DNS協(xié)議都走不通了，這時(shí)候Outlook就真的是連不上服務(wù)器了，就會(huì )出現以下的錯誤。當然端口不通是一個(gè)原因，如果DNS的SRV記錄里沒(méi)有相關(guān)的資源記錄，我想也會(huì )造成一樣的錯誤。
l 總結一下這個(gè)過(guò)程：
i) 禁掉TCP 389端口，自動(dòng)發(fā)現不工作。
ii) 禁掉UDP389端口，登錄過(guò)程變得很慢。
iii) 禁掉TCP&UDP53號端口，Outlook完全登錄不上。
Outlook的連接方式也就兩種，Exchange模式和POP3模式，這里先對Exchange模式進(jìn)行說(shuō)明。上面抓包的過(guò)程也知道，Outlook是把RCP封裝在HTTP里面，也就是把80/443端口給封掉就行了。
在未配置證書(shū)的環(huán)境下，Outlook是走不加密的連接，那么只要把80端口禁掉就可以，但配置了證書(shū)的環(huán)境下，要同時(shí)禁掉80和443號端口才會(huì )出現下面的錯誤，因為如果443走不通，Outlook會(huì )切換到80進(jìn)行通訊，只有把兩個(gè)端口都禁止，才能隔斷通訊
聯(lián)系客服
