次の方法で共有


Exchange の自動検出

Exchange 自動検出サービスについて説明します。

Exchange 自動検出サービスは、クライアント アプリケーションが最小限のユーザー入力で自身を構成するための簡単な方法を提供します。 ほとんどのユーザーは自分のメール アドレスとパスワードを知っており、これら 2 つの情報を使用して、起動して実行するために必要なその他のすべての詳細を取得できます。 Exchange Web Services (EWS) クライアントの場合、自動検出は通常、EWS エンドポイント URL を検索するために使用されますが、自動検出は、他のプロトコルを使用するクライアントを構成するための情報を提供することもできます。 自動検出は、ファイアウォールの内部または外部にあるクライアント アプリケーションに対して機能し、リソース フォレストと複数のフォレストシナリオで動作します。

自動検出プロセスの概要

自動検出プロセスには、基本的に 3 つのフェーズがあります。 フェーズ 1 では、潜在的な自動検出サーバーの一覧を生成し、フェーズ 2 では、(うまくいけば) 応答が成功するまで、リスト内の各サーバーを試します。 どの候補も解決しなかった場合は、フェーズ 3 に進みます。これは、自動検出エンドポイントを見つけるための "最後の溝" の試行を表します。

EWS マネージ API の ExchangeService.AutodiscoverUrl メソッドにより、このプロセスの 3 つのフェーズはすべて実装されます。そのため、EWS マネージ API を使用する場合は、独自に自動検出を実装することについて心配する必要はありません。 次の図は、自動検出プロセスの 3 つのフェーズを示しています。

図 1. 自動検出プロセスの 3 つのフェーズ

候補プールの定義、エンドポイントの試行、他の選択肢の試行の 3 つのフェーズを示す自動検出プロセスの図。

フェーズ 1: 候補プールを定義する

自動検出を使用するには、まず、ユーザーに正しい自動検出サーバーの場所を示す必要があります。 好都合なことに、自動検出の定義により、探す場所の数は限られています。 複数の候補が見つかった場合、自動検出では一覧を生成して優先度を設定する方法も定義します。

表 1. 自動検出エンドポイント候補のソース

探す場所 見つかるもの
Active Directory Domain Services (AD DS)
ドメインに参加しているクライアントの場合は、最初に探す場所になります。 Exchange は AD DS にサービス接続ポイント (SCP) オブジェクトを公開します。これにより、自動検出の要求は Active Directory サイトに基づいてサーバーにルーティングできるようになります。 SCP 検索の結果は、候補一覧の最上位にする必要があります。

: SCP 検索は、ドメインに参加していないクライアントや Active Directory サーバーにアクセスできないクライアントには使用できません。 この場合は、SCP 検索を省略する必要があります。
ユーザーの電子メール アドレス ドメイン
自動検出では、標準エンドポイント URL の形式が 2 つ定義されています。これは、ユーザーの電子メール アドレスのドメイン部分から派生します。
"https://" + domain + "/autodiscover/autodiscover" + *fileExtension*
"https://autodiscover." + domain + "/autodiscover/autodiscover" + *fileExtension*

fileExtension の値は、使用している自動検出アクセス方法 (SOAP または POX) によって異なります。 SOAP サービスではファイル拡張子 ".svc" が使用され、POX では ".xml" が使用されます。

次の図は、自動検出エンドポイント一覧の生成方法を示しています。

図 2. 自動検出エンドポイント一覧の生成プロセス

図は自動検出エンドポイントのリストを生成するためのプロセスを示しています。矢印は、エンドポイントのリストが SCP 参照や、ユーザーの電子メールアドレスから生じることを示しています。

フェーズ 2: 各候補を試してみる

潜在的な候補の順序付き一覧を生成したら、URL に要求を送信して結果を検証することで、一覧の各候補を試してみます。図 3 を参照してください。 成功の応答が得られた時点で完了です。

図 3. 各エンドポイント候補を順に試す

サーバーが正常な応答を受信するまで優先順位順に各エンドポイントを試行することを示す図。

候補者に要求を送信する前に、信頼できることを確認します。 ユーザーの資格情報を送信していることを忘れないでください。そのため、信頼できるサーバーとだけ共有することが重要です。 少なくとも、次のことを確認する必要があります。

  • エンドポイントが HTTPS エンドポイントであること。 クライアント アプリケーションは、非 SSL エンドポイントに対して認証やデータの送信を行ってはいけません。

  • サーバーが提示した SSL 証明書が信頼された機関からのものであり有効であること。

注:

これらは、基本的なセキュリティの推奨事項にすぎません。 認証を扱うときには、コードが組織のセキュリティ要件を満たしていることを常に確認します。

送信する要求の種類は、自動検出サービスにアクセスする方法によって決まります。

表 2. 自動検出の要求の種類

使用するもの 要求を送信する手段
EWS マネージ API
GetUserSettings メソッド。
SOAP 自動検出サービス
GetUserSettings 操作。
POX 自動検出サービス
自動検出要求本文が含まれる HTTP POST。

フェーズ 3: その他の方法を試す

場合によっては、リスト内のすべてのエンドポイントを試してみるだけで、すべてのエンドポイントからエラーが返される場合があります。 タオルをスローする前に、認証されていない GET 要求を送信したり、SRV レコードの DNS に対してクエリを実行したり、いくつかのことを試すことができます。 これらの試行でも結果が得られない場合は、自動検出サービスに問い合わせることはできません。

図 4. その他の方法を試す

認証されていない GET 要求および DNS クエリを介して生成された新しいエンドポイントを示す図。

認証されていない GET 要求の送信

最初に試してみることは、ユーザーの電子メール アドレスから派生したエンドポイントに向けて、認証されていない GET 要求を送信することです。 そのエンドポイントの形式は "http://autodiscover." です。+ domain + "/autodiscover/autodiscover.xml" これは SSL エンドポイントでない点に注意してください。 サーバーが 302 リダイレクト応答を返す場合は、その応答の Location ヘッダーに含まれるエンドポイント URL に向けて自動検出要求の再送信を試してみます。

SRV レコードについての DNS の照会

認証されていない GET 要求が失敗した場合に、最後に試してみることは、自動検出サービスに関する SRV レコードに対する DNS クエリです。 このレコードは、"_autodiscover._tcp." + ドメインの形式になります。 このクエリは複数のレコードを返すことがありますが、最高の優先度と重みが付けられた SSL エンドポイントをポイントするレコードのみを使用します。

自動検出を使用する場合のオプション

自動検出には、SOAP または POX Web サービスを使用してアクセスできます。 使用する方法は、要件と環境によって異なります。ただし、可能であれば、SOAP Web サービスを使用することをお勧めします。 EWS マネージ API もオプションです。 SOAP と POX 自動検出サービスの両方のクライアント部分を実装します。

表 3: 自動検出にアクセスする場合のオプション

オプション 利点 欠点
EWS マネージ API
自動検出プロセスが実装される。

SOAP と POX の両方の自動検出サービスを使用する。

Exchange Online、Office 365 の一部としての Exchange Online、または Exchange 2007 SP1 以降の Exchange の各バージョンで動作する。

使いやすい。
Microsoft.Exchange.WebServices.Autodiscover.UserSettingName 列挙体で使用できるユーザー設定に制限される。

.NET Framework アプリケーションにのみ使用できる。
SOAP 自動検出
プラットフォームに依存しない。

監視のある設定のみを要求できる。
Exchange 2007 では使用できない。
POX 自動検出
プラットフォームに依存しない。

Exchange Online および Exchange 2007 SP1 以降のすべてのバージョンでサポートされる。
特定の設定を要求できない。

このセクションの内容

関連項目