Lync と Exchange の統合 EWS part3

こんばんは。Lync サポートの久保です。

 

これまで EWS 接続に行うための情報のソースとなる Primary SMTP アドレスを取得し、

名前解決を行い　IP　アドレスを取得するところまでを見てきました。

Lync と Exchange の統合 EWS part1 Lync と Exchange の統合 EWS part2

 

今回は証明書を使用した HTTPS の暗号化通信を確立する様子を確認します。

 A レコードによる名前解決

A レコードによる名前解決を行った場合のネットワーク パケットを見てみたいと思います。

1. autodisocver.contoso.com の名前解決を行います。

2. 3-way handshake の後、Client Hello を送信し、Server Hello と続き暗号化の処理が行われていきます。

ここでポイントとなるのが、Client Hello に含まれる Server Name です。A レコードによる名前解決のシナリオでは、autodiscover.contoso.com が含まれます。

3. 次の Server Hello により、サーバーが保持している証明書とルート証明機関が通知されます。

Client Hello の Server Name が、Exchange サーバーの証明書の SAN に含まれていない場合、なりすましなどの危険があると判断し、接続は成立しません。

Server Hellor に含まれる情報から、サーバーがバインドしている証明書の SAN に含まれる値を確認する事ができます。

次の図が SAN に autodiscover.contoso.com が含まれる様子を確認するために、値を展開した図になります。

また、証明書を正しく運用するためには、CRL を取得する動作が欠かせません。CDP は同様にネットワーク パケットから確認可能です。次の図から、CDP は LDAP のみ展開されている様子が確認可能です。

 

SRV レコードによる名前解決

次に SRV レコードによる名前解決をおこなった場合のネットワーク パケットを見てみましょう。

1. _autodiscover._tcp.contoso.com の SRV レコードからホスト名を取得し、A レコードによる名前解決を行います。

2. 3-way handshake の後、Client Hello を送信し、Server Hello と続き暗号化の処理が行われていきます。

ここでポイントとなるのが、Client Hello に含まれる Server Name です。SRV レコードにより名前解決を行うシナリオでは、SRV レコードから通知されたホスト名が含まれます。

つまり、SRV レコードでの名前解決を行った場合、Exchange サーバーの SAN に autodiscover.contoso.com は不要となります。

 

以上が、A レコードで名前解決を行った場合と、SRV レコードでのネットワーク レイヤーでの動作の違いになります。

なお、上記の接続は、Autodisocver での接続についての解説ですが、Autodisocver へ接続した後、EWS 接続先を取得し Exchange サーバーへの接続を行いますが、

EWS 接続を行う際のネットワーク レイヤーの動作は基本的には同じになります。

 

Part1 から Part3 では、ネットワーク パケットしか取得しておりませんが、ネットワーク パケットを解析するだけ、以下の内容を確認することが可能です。

・どのように名前解決がおこなわれて、接続先 IP はどのように通知されているか。

・Exchange サーバーの証明書に含まれなければならない SN/SAN は何か。

・Exchange サーバーが使用している証明機関は何か。そして、クライアントは [信頼されたルート証明機関] にどのような証明書を保持しなければならないか。

・Exchange サーバーが使用している証明機関の CDP は何か。

 

基本的には上記の内容をすべてクリアすれば、ネットワーク レイヤーとしては、Exchange と Lync クライアントは接続可能になります。

次回 Lync と Exchange の統合 EWS part4 では、上記の内容が設定されている箇所を確認する方法について確認したいと思います。

 

引き続き快適な Lync ライフをお楽しみください。