Exchange ネットワーク ポートのリファレンス

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2016-11-28

ここでは、MicrosoftExchange Server 2010 で使用されるすべてのデータ パスのポート、認証、および暗号化について説明します。各表に続く「注」には、標準以外の認証または暗号化方式が明記されています。

トランスポート サーバー

Exchange 2010 には、メッセージ トランスポート機能を実行する 2 つのサーバーの役割が含まれています。ハブ トランスポート サーバーおよびエッジ トランスポート サーバー。

次の表では、これらのトランスポート サーバーと他の Exchange 2010 サーバーおよびサービスとの間のデータ パスのポート、認証、および暗号化について説明します。

トランスポート サーバーのデータ パス

トランスポート サーバーに関する注

• ハブ トランスポート サーバー間のすべてのトラフィックは、TLS と、Exchange 2010 セットアップによってインストールされる自己署名入り証明書を使用して暗号化されます。

  注意

  Exchange 2010 では、同じ Exchange 組織内の他のハブ トランスポート サーバーとの内部 SMTP 通信用のハブ トランスポート サーバーで、TLS を無効にすることができます。絶対に必要でない限り、この操作はお勧めしません。詳細については、「WAN 組織の最適化のサポートのために、Active Directory サイト間の TLS を無効にする」を参照してください。

• エッジ トランスポート サーバーとハブ トランスポート サーバーの間のすべてのトラフィックは、認証および暗号化されます。相互 TLS は、認証および暗号化の基になるメカニズムです。Exchange 2010 は、X.509 検証を使用する代わりに、直接信頼を使用して証明書を認証します。直接信頼とは、Active Directory または Active Directory Lightweight Directory Services (AD LDS) の存在が、その証明書の検証になっていることを意味します。Active Directory は、信頼されたストレージ メカニズムと見なされます。直接信頼を使用する場合は、証明書が自己署名されているか、または証明機関 (CA) によって署名されているかはどちらでもかまいません。Exchange 組織でエッジ トランスポート サーバーを購読すると、検証するハブ トランスポート サーバーの Active Directory にエッジ トランスポート サーバー証明書が発行されます。Microsoft Exchange EdgeSync サービスが、検証するエッジ トランスポート サーバー用のハブ トランスポート サーバー証明書のセットを一緒に使用して AD LDS を更新します。

• EdgeSync は、ハブ トランスポート サーバーから TCP 50636 を経由した、購読済みエッジ トランスポート サーバーへのセキュリティで保護された LDAP 接続を使用します。AD LDS は、TCP 50389 で接続要求待ちも行います。このポートへの接続では、SSL は使用されません。LDAP ユーティリティを使用してポートに接続したり、AD LDS データをチェックすることができます。

• 既定では、2 つの異なる組織にあるエッジ トランスポート サーバー間のトラフィックは暗号化されます。Exchange 2010 セットアップによって自己署名入り証明書が作成され、既定で TLS が有効になります。これによって、送信側システムは、Exchange への受信 SMTP セッションを暗号化できます。また、既定では、Exchange 2010 はすべてのリモート接続について TLS の使用を試行します。

• 同一のコンピューターにハブ トランスポート サーバーの役割とメールボックス サーバーの役割がインストールされている場合は、ハブ トランスポート サーバーとメールボックス サーバーの間のトラフィックの認証方法は異なります。メール送信がローカルである場合は、Kerberos 認証が使用されます。メール送信がリモートである場合は、NTLM 認証が使用されます。

• Exchange 2010 はドメイン セキュリティもサポートしています。ドメイン セキュリティは、S/MIME などのメッセージ レベルのインターネット上のセキュリティ ソリューションの代わりとして Exchange 2010 および Microsoft Outlook 2010 が提供する低コストの機能です。ドメイン セキュリティは、セキュリティで保護されたインターネット経由のドメイン間のメッセージ パスを管理する手段を提供します。これらのセキュリティで保護されたメッセージ パスを構成した後では、認証された送信者からセキュリティで保護されたパスを使用して正常に届いたメッセージは、Outlook および Outlook Web Access ユーザーに対して "ドメイン保護" と表示されます。詳細については、「ドメイン セキュリティについて」を参照してください。

• ハブ トランスポート サーバーおよびエッジ トランスポート サーバーでは、複数のエージェントを実行できます。一般に、スパム対策エージェントは、そのエージェントが実行されているコンピューターにローカルな情報を利用します。したがって、リモート コンピューターとの通信は最低限必要なものだけに限られます。受信者フィルターは例外です。受信者フィルターには、AD LDS または Active Directory のいずれかへの呼び出しが必要です。受信者フィルターは、エッジ トランスポート サーバーで実行することをお勧めします。この場合、AD LDS ディレクトリはエッジ トランスポート サーバーと同じコンピューター上にあります。したがって、リモート通信は必要ありません。ハブ トランスポート サーバーに受信者フィルターをインストールして構成している場合、受信者フィルターは Active Directory にアクセスします。

• Exchange 2010 の送信者評価機能では、プロトコル分析エージェントを使用します。このエージェントも、疑わしい接続について受信メッセージ パスを特定するために、外部のプロキシ サーバーへのさまざまな接続を行います。

• その他すべてのスパム対策機能では、セーフリスト集約および受信者データなどのデータを受信者フィルターに使用します。このデータはローカル コンピューター上でのみ収集、格納、アクセスが行われます。データは MicrosoftExchange EdgeSync サービスを使用して、ローカルの AD LDS ディレクトリに頻繁にプッシュされます。

• ハブ トランスポート サーバー上の Information Rights Management (IRM) エージェントは、組織内の Active Directory Rights Management Services (AD RMS) サーバーに接続します。AD RMS は、ベスト プラクティスとして SSL を使用してセキュリティ保護されている Web サービスです。AD RMS サーバーとの通信は HTTPS を使用して行われ、認証用には、AD RMS サーバーの構成に応じて、Kerberos または NTLM が使用されます。

• ジャーナル ルール、トランスポート ルール、メッセージ分類は Active Directory に保存され、ハブ トランスポート サーバー上のジャーナル エージェントとトランスポート ルール エージェントによってアクセスされます。

メールボックス サーバー

メールボックス サーバー用に NTLM または Kerberos 認証のどちらが使用されるかは、Exchange ビジネス ロジック層のコンシューマーが実行されているユーザーまたはプロセスのコンテキストによって決まります。この場合のコンシューマーとは、Exchange ビジネス ロジック層を使用する任意のアプリケーションまたはプロセスです。そのため、メールボックス サーバーのデータ パス 表の 既定の認証 列内の多くのエントリは NTLM/Kerberos として扱われます。

Exchange ビジネス ロジック層は、Exchange ストアにアクセスし、通信するために使用されます。Exchange ビジネス ロジック層は、外部アプリケーションおよびプロセスと通信するために、Exchange ストアからも呼び出されます。

Exchange ビジネス ロジック層のコンシューマーがローカル システムとして実行されている場合、そのコンシューマーから Exchange ストアに対する認証方法は常に Kerberos です。Kerberos が使用されるのは、コンシューマーがコンピューター アカウント Local System を使用して認証される必要があり、双方向に認証された信頼が存在している必要があるからです。

Exchange ビジネス ロジック層のコンシューマーがローカル システムとして実行されていない場合、認証方法は NTLM です。たとえば、Exchange ビジネス ロジック層を使用する Exchange 管理シェル コマンドレットを実行する場合は、NTLM が使用されます。

RPC トラフィックは常に暗号化されます。

次の表では、メールボックス サーバーとのデータ パスのポート、認証、および暗号化について説明します。

メールボックス サーバーのデータ パス

メールボックス サーバーに関する注

• 前述の表に一覧にされている [クラスタリング] データ パスでは動的 RPC over TCP を使用して、異なるクラスター ノード間でクラスターの状態および処理を通信します。また、クラスター サービス (ClusSvc.exe) は UDP/3343 を使用し、ランダムに割り当てられた値の大きい TCP ポートを使用してクラスター ノード間の通信を行います。

• ノード内の通信では、クラスター ノードはユーザー データグラム プロトコル (UDP) ポート 3343 上で通信します。クラスター内の各ノードは、シーケンス化されたユニキャスト UDP データグラムを、定期的にクラスター内の他の各ノードと交換します。この交換の目的は、すべてのノードが正しく実行されているかどうかを確認し、またネットワーク リンクの正常性を監視することです。

• ポート 64327/TCP はログ配信で使用される既定のポートです。管理者は、ログ配布用に別のポートを指定できます。

• [ネゴシエート] と記載されている HTTP 認証では、最初に Kerberos が試行され、次に NTLM が試行されます。

クライアント アクセス サーバー

特に断りのない限り、Outlook Web App、POP3、IMAP4 などのクライアント アクセス テクノロジは、クライアント アプリケーションからクライアント アクセス サーバーへの認証および暗号化ごとに説明されています。

次の表では、クライアント アクセス サーバーと他のサーバーやクライアントとの間のデータ パスのポート、認証、および暗号化について説明します。

クライアント アクセス サーバーのデータ パス

クライアント アクセス サーバーに関する注

• Exchange 2010 では、Microsoft Outlook などの MAPI はクライアント アクセス サーバーに接続します。

• クライアント アクセス サーバーは複数のポートを使用して、メールボックス サーバーと通信します。一部の例外を除き、これらのポートは RPC サービスによって決定され、固定されていません。

• [ネゴシエート] と記載されている HTTP 認証では、最初に Kerberos が試行され、次に NTLM が試行されます。

• Exchange 2010 クライアント アクセス サーバーが、MicrosoftExchange Server 2003 を実行するメールボックス サーバーと通信する場合は、ベスト プラクティスとして、Kerberos を使用し、NTLM 認証と基本認証を無効にすることをお勧めします。また、信頼された証明書と共にフォーム ベース認証を使用するように Outlook Web App を構成することもお勧めします。Exchange ActiveSync クライアントが Exchange 2010 クライアント アクセス サーバー経由で Exchange 2003 バックエンド サーバーと通信する場合、Windows 統合認証を Exchange 2003 バックエンド サーバーの Microsoft-Server-ActiveSync 仮想ディレクトリに対して有効にする必要があります。Exchange システム マネージャーを Exchange 2003 サーバー上で使用して Exchange 2003 仮想ディレクトリに対する認証を管理するには、Microsoft サポート技術情報の記事 937031「イベント ID 1036 がモバイル デバイスを接続するには、Exchange 2007 サーバーに Exchange 2003 バックエンド サーバー上のメールボックスにアクセスする際に、CAS の役割が実行されている Exchange 2007 サーバーに記録されます。」で参照される修正プログラムをダウンロードしてインストールしてください。

  注意

  このサポート技術情報は MicrosoftExchange Server 2007 特有のものですが、Exchange 2010 にも適用されます。

• クライアント アクセス サーバーが別のクライアント アクセス サーバーに POP3 要求をプロキシすると、ポート 995/TCP 経由の通信が発生します。これは、接続しているクライアントが POP3 を使用して TLS (ポート 110/TCP) を要求するかまたは SSL を使用してポート 995/TCP に接続するかに関係なく起こります。同様に、IMAP4 接続の場合は、要求しているサーバーはポート 993/TCP を使用して要求をプロキシします。これは、接続しているクライアントが IMAP4 を使用して TLS (ポート 443/TCP 上) を要求するか、または SSL 暗号化された IMAP4 を使用してポート 995 に接続するかどうかには関係ありません。

クライアント アクセス サーバーの接続

メールボックス サーバーを含む各 Active Directory サイトには、クライアント アクセス サーバーが必要であることに加えて、Exchange サーバー間でトラフィックの制限を避けることが重要です。Exchange が使用する定義済みのすべてのポートが、送信元と送信先のサーバー間で双方向に開いていることを確認します。Exchange サーバー間、または Exchange 2010 メールボックス サーバーあるいはクライアント アクセス サーバーと Active Directory との間へのファイアウォールのインストールはサポートされていません。ただし、トラフィックに制限がなく、各種の Exchange サーバーと Active Directory との間で利用可能なポートがすべて開いている場合は、ネットワーク デバイスをインストールできます。

ユニファイド メッセージング サーバー

IP ゲートウェイおよび IP PBX は、SIP トラフィックの暗号化用に相互 TLS を使用し、セッション開始プロトコル (SIP)/TCP 接続用に IP ベース認証を使用する、証明書ベースの認証のみをサポートしています。IP ゲートウェイでは、NTLM または Kerberos 認証はサポートされません。したがって、IP ベースの認証を使用する場合は、接続 IP アドレスを使用して、暗号化されていない (TCP) 接続用の認証メカニズムを提供します。ユニファイド メッセージング (UM) で IP ベースの認証を使用する場合、UM サーバーは IP アドレスに接続が許可されているかどうかを確認します。IP アドレスは IP ゲートウェイまたは IP PBX で構成されます。

IP ゲートウェイと IP PBX では、SIP トラフィックの暗号化用に相互 TLS をサポートしています。必要な信頼された証明書が正しくインポートおよびエクスポートされると、IP ゲートウェイまたは IP PBX は UM サーバーに証明書を要求し、さらに UM サーバーが IP ゲートウェイまたは IP PBX に証明書を要求します。IP ゲートウェイまたは IP PBX と UM サーバーの間で信頼された証明書を交換することにより、IP ゲートウェイまたは IP PBX と UM サーバーは、相互 TLS を使用して、暗号化された接続を介して通信できるようになります。

次の表では、UM サーバーと他のサーバーとの間のデータ パスのポート、認証、および暗号化について説明します。

ユニファイド メッセージング サーバーのデータ パス

ユニファイド メッセージング サーバーに関する注

• Active Directory で UM IP ゲートウェイ オブジェクトを作成する場合、物理 IP ゲートウェイまたは IP PBX (構内交換機) の IP アドレスを定義する必要があります。UM IP ゲートウェイ オブジェクトで IP アドレスを定義すると、UM サーバーが通信できる有効な IP ゲートウェイまたは IP PBX (SIP ピアとも呼ばれます) の一覧に IP アドレスが追加されます。UM IP ゲートウェイを作成したときに、UM ダイヤル プランに関連付けることができます。UM IP ゲートウェイをダイヤル プランに関連付けると、ダイヤル プランに関連付けられたユニファイド メッセージング サーバーは、IP ベースの認証を使用して IP ゲートウェイと通信できるようになります。UM IP ゲートウェイが作成されていない場合や、適切な IP アドレスを使用するように構成されていない場合、認証は失敗し、UM サーバーは IP ゲートウェイの IP アドレスからの接続を受け付けません。また、相互 TLS と IP ゲートウェイまたは IP PBX と UM サーバーを実装する場合は、UM IP ゲートウェイは FQDN を使用するように構成する必要があります。UM IP ゲートウェイを FQDN で構成したら、UM IP ゲートウェイの DNS 前方参照ゾーンにホスト レコードを追加する必要もあります。

• Exchange 2010 では、UM サーバーはポート 5060/TCP (セキュリティ保護されていない) またはポート 5061/TCP (セキュリティ保護されている) で通信することができ、両方を使用するように構成できます。

詳細については、「ユニファイド メッセージング VoIP セキュリティについて」および「ユニファイド メッセージングのプロトコル、ポート、およびサービスについて」を参照してください。

Exchange 2010 セットアップで作成される Windows ファイアウォール ルール

セキュリティが強化された Windows ファイアウォールはステートフルなホストベースのファイアウォールで、ファイアウォール ルールに基づいて受信トラフィックと送信トラフィックをフィルター処理します。Exchange 2010 セットアップは、サーバーとクライアントの通信に必要なポートを各サーバーの役割で開くための Windows ファイアウォール ルールを作成します。したがって、これらの設定を構成するときにセキュリティ構成ウィザード (SCW) を使用する必要はなくなりました。セキュリティが強化された Windows ファイアウォールの詳細については、「セキュリティが強化された Windows ファイアウォールと IPsec」を参照してください。

この表では、各サーバーの役割で開かれるポートを含めた、Exchange セットアップによって作成される Windows ファイアウォール ルールを示しています。これらのルールは、セキュリティが強化された Windows ファイアウォール MMC スナップインを使用して表示できます。

Exchange 2010 セットアップで作成される Windows ファイアウォール ルールに関する注意

• インターネット インフォメーション サービス (IIS) がインストールされているサーバーでは、Windows は HTTP ポート (ポート 80、TCP) および HTTPS ポート (ポート 443、TCP) ポートを開きます。Exchange 2010 セットアップはこれらのポートを開きません。したがって、これらのポートは上述の表には記載されていません。

• Windows Server 2008 および Windows Server 2008 R2 では、セキュリティが強化された Windows ファイアウォールにより、ポートを開くプロセスまたはサービスを指定することができます。ルールで指定されたプロセスまたはサービスにポートの使用が制限されるので、セキュリティ保護がより強化されます。Exchange セットアップは、指定されたプロセス名でファイアウォール ルールを作成します。場合によっては、プロセスに制限されない追加ルールも、互換性のために作成されます。展開でサポートされている場合は、プロセスに制限されないルールを無効化または削除して、プロセスに制限された対応するルールを維持することができます。プロセスに制限されないルールは、ルール名の中にある (GFW) という語で区別されます。

• 多くの Exchange サービスでは、リモート プロシージャ コール (RPC) を通信に使用します。RPC を使用するサーバー プロセスは RPC エンドポイント マッパーに接続して、動的なエンドポイントを受信し、これらのエンドポイントをエンドポイント マッパー データベースに登録します。RPC クライアントは RPC エンドポイント マッパーに接続して、サーバー プロセスによって使用されるエンドポイントを決定します。既定では、RPC エンドポイント マッパーは、ポート 135 (TCP) で接続要求待ちを行います。Windows ファイアウォールで、RPC を使用するプロセスの構成を行うと、Exchange 2010 セットアップにより、このプロセスに対して 2 つのファイアウォール ルールが作成されます。1 つは RPC エンドポイント マッパーとの通信を許可し、もう 1 つのルールは動的に割り当てられたエンドポイントとの通信を許可します。RPC の詳細については、「RPC の動作方法」を参照してください。動的 RPC の Windows ファイアウォール ルール作成の詳細については、「動的 RPC を使用した受信ネットワーク トラフィックの許可」を参照してください。

詳細については、Microsoft Microsoft サポート技術情報の記事 179442「ドメインの信頼関係を使用するためのファイアウォールの構成方法」を参照してください。

 © 2010 Microsoft Corporation.All rights reserved.