データ パス セキュリティ リファレンス

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2009-06-05

ここでは、Microsoft Exchange Server 2007 で使用されるすべてのデータ パスのポート、認証、および暗号化について説明します。各表の後の注では、標準以外の認証または暗号化の方法を説明および定義しています。

トランスポート サーバー

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

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

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

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

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

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

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

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

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

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

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

その他のすべてのスパム対策機能は、ローカル コンピュータでのみ収集、格納、およびアクセスされるデータを使用します。通常、セーフ リスト集約データや受信者フィルタ用の受信者データなどのデータは、Microsoft Exchange EdgeSync サービスを使用してローカル ADAM ディレクトリにプッシュされます。

ジャーナリングおよびメッセージ分類は、ハブ トランスポート サーバーで実行され、Active Directory のデータを利用して機能します。

メールボックス サーバー

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

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

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

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

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

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

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

データ パス	必要なポート	既定の認証	サポートされる認証	暗号化のサポート	既定での暗号化
クラスタ連続レプリケーション (CCR) とスタンバイ連続レプリケーション (SCR) のログ配布	445/TCP	NTLM/Kerberos	NTLM/Kerberos	可 (IPSec)	不可
CCR と SCR のシード	ランダム ポート	NTLM/Kerberos	NTLM/Kerberos	可 (IPSec)	不可
ボリューム シャドウ コピー サービス (VSS) によるバックアップ	ローカル メッセージ ブロック (SMB)	NTLM/Kerberos	NTLM/Kerberos	不可	不可
従来のバックアップ	ランダム ポート	NTLM/Kerberos	NTLM/Kerberos	可 (IPSec)	不可
クラスタ化	135/TCP (RPC)。この表の後の「メールボックス サーバーに関する注」を参照	NTLM/Kerberos	NTLM/Kerberos	可 (IPSec)	不可
MAPI アクセス	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	可 (RPC 暗号化)	可
メールボックス アシスタント	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	不可	不可
可用性 Web サービス (メールボックスへのクライアント アクセス)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	可 (RPC 暗号化)	可
Active Directory アクセス	389/TCP/UDP (LDAP)、3268/TCP (LDAP GC)、88/TCP/UDP (Kerberos)、53/TCP/UDP (DNS)、135/TCP (RPC netlogon)	Kerberos	Kerberos	可 (Kerberos 暗号化)	可
コンテンツ インデックス処理	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	可 (RPC 暗号化)	可
Admin のリモート アクセス (リモート レジストリ)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	可 (IPSec)	不可
Admin のリモート アクセス (SMB/ファイル)	445/TCP (SMB)	NTLM/Kerberos	NTLM/Kerberos	可 (IPSec)	不可
受信者更新サービスの RPC アクセス	135/TCP (RPC)	Kerberos	Kerberos	可 (RPC 暗号化)	可
Microsoft Exchange Active Directory トポロジ サービスのアクセス	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	可 (RPC 暗号化)	可
Microsoft Exchange System Attendant サービスの従来のアクセス (要求の待機)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	不可	不可
Microsoft Exchange System Attendant サービスの Active Directory への従来のアクセス	389/TCP/UDP (LDAP)、3268/TCP (LDAP GC)、88/TCP/UDP (Kerberos)、53/TCP/UDP (DNS)、135/TCP (RPC netlogon)	Kerberos	Kerberos	可 (Kerberos 暗号化)	可
Microsoft Exchange System Attendant サービスの従来のアクセス (MAPI クライアントの場合)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	可 (RPC 暗号化)	可
オフライン アドレス帳 (OAB) の Active Directory へのアクセス	135/TCP (RPC)	Kerberos	Kerberos	可 (RPC 暗号化)	可
Active Directory に対する受信者の更新	389/TCP/UDP (LDAP)、3268/TCP (LDAP GC)、88/TCP/UDP (Kerberos)、53/TCP/UDP (DNS)、135/TCP (RPC netlogon)	Kerberos	Kerberos	可 (Kerberos 暗号化)	可
Active Directory への DSAccess	389/TCP/UDP (LDAP)、3268/TCP (LDAP GC)、88/TCP/UDP (Kerberos)、53/TCP/UDP (DNS)、135/TCP (RPC netlogon)	Kerberos	Kerberos	可 (Kerberos 暗号化)	可
Outlook のオフライン アドレス帳 (OAB) へのアクセス 注 : Outlook 2003 以前のバージョンに適用されます。オフライン アドレス帳の Web 配布の機能が有効ではない場合、この設定は Office Outlook 2007 クライアントにも適用されます。	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	可 (RPC 暗号化)	可
WebDAV	80/TCP、443/TCP (SSL)	基本、NTLM、ネゴシエート	基本、NTLM、ネゴシエート	可 (HTTPS)	可

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

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

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

WebDAV アプリケーションまたはクライアントは、80/TCP または 443/TCP を使用してメールボックス サーバーに接続できますが、通常、これらのアプリケーションまたはクライアントはクライアント アクセス サーバーに接続します。次に、クライアント アクセス サーバーが 80/TCP または 443/TCP を使用してメールボックス サーバーに接続します。

"メールボックス サーバーのデータ パス" の表に示されているクラスタ化のデータ パスでは、動的 RPC (TCP) を使用して、クラスタ ノード間でクラスタの状態および処理を通信します。また、クラスタ サービス (ClusSvc.exe) は UDP/3343 を使用し、ランダムに割り当てられた値の大きい TCP ポートを使用してクラスタ ノード間の通信を行います。

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

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

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

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

データ パス	必要なポート	既定の認証	サポートされる認証	暗号化のサポート	既定での暗号化
自動検出サービス	80/TCP、443/TCP (SSL)	基本/統合 Windows 認証 (ネゴシエート)	基本、ダイジェスト、NTLM、ネゴシエート (Kerberos)	可 (HTTPS)	可
可用性サービス	80/TCP、443/TCP (SSL)	NTLM/Kerberos	NTLM、Kerberos	可 (HTTPS)	可
Outlook Web Access	80/TCP、443/TCP (SSL)	フォーム ベース認証	基本、ダイジェスト、フォーム ベース認証、NTLM (v2 のみ)、Kerberos、証明書	可 (HTTPS)	自己署名入り証明書を使用して可
POP3	110/TCP (TLS)、995/TCP (SSL)	基本、NTLM、Kerberos	基本、NTLM、Kerberos	可 (SSL、TLS)	可
IMAP4	143/TCP (TLS)、993/TCP (SSL)	基本、NTLM、Kerberos	基本、NTLM、Kerberos	可 (SSL、TLS)	可
Outlook Anywhere (以前の RPC over HTTP)	80/TCP、443/TCP (SSL)	基本	基本または NTLM	可 (HTTPS)	可
Exchange ActiveSync アプリケーション	80/TCP、443/TCP (SSL)	基本	基本、証明書	可 (HTTPS)	可
クライアント アクセス サーバーからユニファイド メッセージング サーバー	5060/TCP、5061/TCP、5062/TCP、動的なポート	IP アドレスごと	IP アドレスごと	可 (SIP [セッション開始プロトコル] over TLS)	可
クライアント アクセス サーバーから以前のバージョンの Exchange Server を実行するメールボックス サーバー	80/TCP、443/TCP (SSL)	NTLM/Kerberos	ネゴシエート (Kerberos から NTLM またはオプションで基本へのフォールバック)、POP/IMAP テキスト	可 (IPSec)	不可
クライアント アクセス サーバーから Exchange 2007 メールボックス サーバー	RPC。この表の後の「クライアント アクセス サーバーに関する注」を参照	Kerberos	NTLM/Kerberos	可 (RPC 暗号化)	可
クライアント アクセス サーバーからクライアント アクセス サーバー (Exchange ActiveSync)	80/TCP、443/TCP (SSL)	Kerberos	Kerberos、証明書	可 (HTTPS)	自己署名入り証明書を使用して可
クライアント アクセス サーバーからクライアント アクセス サーバー (Outlook Web Access)	80/TCP、443/TCP (SSL)	Kerberos	Kerberos	可 (HTTPS)	可
WebDAV	80/TCP、443/TCP (SSL)	HTTP 基本または Outlook Web Access フォーム ベース認証	基本、Outlook Web Access フォーム ベース認証	可 (HTTPS)	可
Outlook のオフライン アドレス帳 (OAB) へのアクセス 注 : オフライン アドレス帳の Web 配布の機能が有効な場合に、Office Outlook 2007 に適用されます。	80/TCP、443/TCP (SSL)	NTLM/Kerberos	NTLM/Kerberos	可 (HTTPS)	不可

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

クライアント アクセス サーバーは、多くのポートを使用してメールボックス サーバーと通信します。一部の例外を除き、これらのポートはリモート プロシージャ コール (RPC) サービスによって決定され、固定されていません。RPC サービスによって使用される動的ポートの範囲を指定することが可能です。RPC サービスによって使用される動的ポートの範囲を制限する方法の詳細については、マイクロソフト サポート技術情報の記事番号 154596「ファイアウォールで動作するように RPC の動的ポート割り当てを構成する方法」を参照してください。

重要 :
同じ Active Directory サイト内のクライアント アクセス サーバーとメールボックス サーバーの間にファイアウォールが追加された構成はサポートされません。

重要 :
クライアント アクセス サーバーが境界ネットワークにインストールされた構成はサポートされません。クライアント アクセス サーバーは Active Directory ドメインのメンバである必要があり、クライアント アクセス サーバーのコンピュータ アカウントは Exchange サーバーの Active Directory セキュリティ グループのメンバである必要があります。Exchange サーバーの Active Directory セキュリティ グループは、組織内のすべての Exchange サーバーに対する読み取りおよび書き込みアクセスが可能です。組織内のクライアント アクセス サーバーとメールボックス サーバーの間の通信は、RPC サービスを使用して行われます。境界ネットワークへのクライアント アクセス サーバーのインストールがサポートされないのは、これらの要件があるためです。

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

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

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

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

次の表では、ユニファイド メッセージング サーバーと他のサーバーとの間のデータ パスのポート、認証、および暗号化について説明します。

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

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

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

元の RTM (Release To Manufacturing) 版の Exchange 2007 では、ユニファイド メッセージング サーバーは 5060/TCP (セキュリティで保護されない) と 5061/TCP (セキュリティで保護される) のいずれかのポートで通信できますが、両方のポートで通信することはできません。

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

詳細情報

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

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。