Exchange 2007 のトランスポート アクセス許可モデル

 

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

トピックの最終更新日: 2007-08-27

ここでは、Microsoft Exchange Server 2007 のトランスポート アクセス許可モデルについて詳しく説明します。Microsoft Exchange Server 2007 では、トランスポートとは、メッセージをあるサーバーから別のサーバーに転送するプロセスを指します。メッセージがメールボックス サーバーとハブ トランスポート サーバーの間で転送される場合は、MAPI プロトコルが使用されます。メッセージがハブ トランスポート サーバー間で送受信される場合は、SMTP (簡易メール転送プロトコル) が使用されます。サーバー間の各通信セッションに、オプションの認証段階を割り当てることができます。接続要求に認証チェックが必要になる可能性があります。

認証は、メッセージの送信者を識別しようとするプロセスです。認証が行われない場合、または認証の試みに失敗した場合、その送信者の識別情報は匿名になります。承認は、接続しているユーザー、プログラム、またはデバイスに、何らかのデータ、機能、またはサービスへのアクセスを許可するかどうかを決定するプロセスです。このアクセスは、要求された操作によって異なります。認証プロセスでは、識別情報を検証します。承認プロセスでは、許可するアクセスのレベルが決定されます。

Exchange 2007 では、SMTP および MAPI プロトコルが Microsoft Exchange Transport サービスによって提供されます。SMTP または MAPI プロトコルのどちらかを使用するセッションでは、Microsoft Exchange Transport サービスが Microsoft Windows 承認モデルを使用して、セッションのアクセス許可を管理します。Exchange 2007 のトランスポートのコンテキストでは、承認は、さまざまなプロトコル コマンドやイベントを受け付けるかどうかに関連しています。たとえば、承認では、送信者に特定の電子メール アドレスからのメッセージの送信を許可するためのアクセス許可や、特定のサイズのメッセージを許可するためのアクセス許可をチェックします。Exchange 2007 は、MAPI と SMTP のどちらのプロトコル通信中にもセッションの認証を実行できます。セッションが認証された後、そのセッションで使用できる許可グループが認証の結果によって変更されることがあります。認証に応じて異なる許可グループが許可されるため、インターネットからの匿名メッセージと、Exchange 組織内の認証されたユーザーによって送信されたメッセージを異なる方法で処理することが可能になります。

エッジ トランスポート サーバーの役割でのトランスポートの既定の動作は、ハブ トランスポート サーバーの役割での既定の動作とは異なります。この違いは、コードの相違によるものではありません。この違いは、各役割での既定のアクセス許可のセットが異なることからきています。同じ Active Directory フォレストに含まれている各 Exchange サーバーは信頼関係を持っています。この信頼関係は、インストール時に構成される既定のアクセス許可によってフォレスト内のメール フローをセキュリティで保護できることを示しています。

認証された各セッションは、認証しているセキュリティ プリンシパルがメンバとして含まれている各グループのセキュリティ識別子の一覧を示すアクセス トークンを提供します。図 1 は、アクセス トークンに示されているグループ メンバシップ間の関係と、アクセスされるオブジェクトのグループに割り当てられるアクセス許可を示しています。

認証済みセッションと認証済みメッセージの違い

Exchange 2007 のトランスポート モデルの中心的な概念は、認証済みトランスポート セッションと認証済みメッセージの違いです。メッセージには、そのメッセージが認証されているのか、または匿名かを示すメタデータをスタンプできます。あるサーバーが別のサーバーを認証すると、そのサーバーはメッセージを送信して、そのメッセージに認証済みか匿名かを示すメタデータをスタンプすることができます。受信側のサーバーは、認証済みのスタンプが信頼できるかどうかを判断します。受信側のサーバーが送信者を信頼する場合は、認証済みのスタンプを変更せずにおきます。受信側のサーバーが送信者を信頼しない場合は、送信側サーバーの認証済みのスタンプを無効にして、メッセージが匿名であることを示すメタデータをそのメッセージにスタンプします。Exchange 組織では、認証済みのメッセージ スタンプを信頼するサーバー間で、エンド ツー エンドの内部のメール フローが発生します。インターネットからのメッセージを受信するエッジ トランスポート サーバーは、インターネット上の匿名サーバーの認証済みスタンプを信頼しません。このため、エッジ トランスポート サーバーは、認証された接続を経由してメッセージをハブ トランスポート サーバーに送信する前に、各メッセージにそのメッセージが匿名であることを示すメタデータをスタンプします。

メッセージ トランスポートの認証および承認プロセスの動作

Exchange 2007 では、SMTP セッションを認証するために、次の基本的な機構を使用できます。

• MAPI セッションでは、Windows のアカウントとパスワードを使用します。あるいは、SMTP の AUTH 拡張機能を使用することもできます。これには、クリア テキスト パスワード認証、NTLM 認証、および Kerberos 認証が含まれています。
• SMTP の STARTTLS 拡張機能を使用することによって、X.509 証明書を使用することができます。このシナリオの場合、サーバーは、トランスポート層セキュリティ (TLS) ネゴシエーションの一部として証明書を提供します。オプションとして、クライアントも証明書を提供します。
• 外部の認証機構を使用することができます。外部の認証では、物理的にセキュリティが保護されたネットワークや IPsec などの、Exchange には含まれていない機構を使用します。この方法は、専用の送信コネクタおよび受信コネクタ上の識別された IP ルート経由で通信が発生する場合に使用します。

送信側のトランスポート サーバーは、メッセージを送信する前に、受信側のトランスポート サーバーを認証することができます。送信者によって認証された後、受信側のトランスポート サーバーは、その送信者に与えられたアクセス許可をセッション アクセス トークンに適用します。

Exchange 2007 では、送信コネクタと受信コネクタがメール フローを管理します。これらのコネクタには、電子メールの送受信に関連したアクセス許可が定義された随意アクセス制御リスト (DACL) が保持されています。受信コネクタ上のアクセス許可が最も重要です。受信コネクタ上の DACL によって、その受信コネクタ経由で送信されるメッセージに対する送信者のアクセス許可が決定されます。受信コネクタへの SMTP セッションが確立されると、そのセッションに対する匿名アクセス トークンを使用してセッションが開始されます。続いて行われる認証に成功すると、このアクセス トークンが変更されます。セッションが認証されない場合、アクセス トークン内の許可グループは同じ状態のまま残ります。セッションが認証された場合、そのセッションには、個々のアカウントまたは役割に割り当てられているアクセス許可と、そのアカウントが属する任意のセキュリティ グループに割り当てられているアクセス許可が与えられます。

図 2 のフローチャートは、Exchange 2007 トランスポート サーバーが SMTP セッションで認証と承認を使用する方法を示しています。

認証の構成

受信コネクタに対して構成されている一連の認証機構によって、その受信コネクタにメッセージを送信するセッションで使用できる認証機構が決定されます。送信コネクタに対して構成されている認証機構によって、送信コネクタがスマート ホストを認証するために使用する認証機構が決定されます。

受信コネクタでの認証

受信コネクタに対して複数の認証機構を構成できます。受信コネクタの場合は、認証設定によって、サーバーがそのサーバーにメッセージを送信してくるセッションを認証するために有効にする認証機構のセットが決定されます。送信側のサーバーによって、どの認証機構を使用するかが決定されます。

表 1 は、受信コネクタで構成できる認証機構を示しています。受信コネクタの認証機構を構成するには、Exchange 管理コンソールで受信コネクタのプロパティの [認証] タブを使用するか、または Exchange 管理シェルで Set-ReceiveConnector コマンドレットに AuthMechanism パラメータを指定します。

表 1   受信コネクタの認証機構

認証機構	説明
なし	認証のオプションは提供されません。
トランスポート層セキュリティ (TLS)	コネクタはクライアントに STARTTLS を提供します。
統合 Windows 認証	コネクタはクライアントに AUTH と NTLM GSSAPI を提供します。GSSAPI を使用すると、クライアントは NTLM または Kerberos のどちらかをネゴシエートできます。
基本認証	コネクタはクライアントに AUTH と LOGIN を提供します。クライアントからのユーザー名とパスワードがクリア テキストで受信されます。資格情報を検証するために、この機構では Windows アカウントが必要です。
TLS 経由の基本認証	これは基本認証に対するポリシー修飾子です。コネクタは、クライアントが TLS をネゴシエートした後でのみ、クライアントに AUTH と LOGIN を提供します。また、この機構では、TLS も認証機構として設定する必要があります。
Exchange Server 認証	コネクタは Exchange 2007 サーバーのクライアントに、以前のバージョンの Exchange Server を実行している Exchange サーバー用の EXPS と GSSAPI、および X-ANONYMOUSTLS を提供します。
外部的にセキュリティで保護 (たとえば、IPsec を使用)	このオプションは、任意の接続を、権限のある別のサーバーからのものと見なします。

スマート ホストの送信コネクタでの認証

送信コネクタの場合は、SmartHostAuthMechanism 設定によって、送信側のサーバーが送信先のスマート ホストを認証する方法が決定されます。SmartHostAuthMechanism は 1 つの値しか持つことができません。SmartHostAuthMechanism が構成されている場合は、メールの送信前に認証に成功する必要があります。送信側の Exchange 2007 サーバーで使用する認証機構がスマート ホストによって提供されない場合、そのサーバーは電子メール メッセージを送信せず、セッションは終了します。送信側の Exchange 2007 サーバーで使用する認証機構が提供された場合でも認証に失敗すると、やはりサーバーは電子メール メッセージを送信せず、セッションは終了します。

表 2 は、送信コネクタで構成できる認証機構を示しています。送信コネクタの認証機構を構成するには、Exchange 管理コンソールで送信コネクタのプロパティの [ネットワーク] タブにある [スマート ホスト認証の構成] ダイアログ ボックスを使用するか、または Exchange 管理シェルで Set-SendConnector コマンドレットに SmartHostAuthMechanism パラメータを指定します。

表 2   スマート ホスト コネクタの認証機構

認証機構	説明
なし	匿名アクセスが許可されます。
基本認証	コネクタは、AUTH と LOGIN を使用する必要があります。この認証では、ユーザー名とパスワードを指定する必要があります。基本認証では、資格情報がクリア テキストで送信されます。この送信コネクタが認証される必要のあるすべてのスマート ホストが、同じユーザー名とパスワードを受け付けるようになっている必要があります。RequireTLS パラメータも $True に設定されている場合、コネクタは資格情報を送信する前に TLS を使用する必要がありますが、サーバー証明書の検証は実行されません。
TLS を必要とする基本認証	これは基本認証に対するポリシー修飾子です。コネクタは、AUTH を試行する前に TLS を使用する必要があります。また、送信側のサーバーも、受信側のサーバーの X.509 証明書の検証を実行する必要があります。証明書の検証には、AUTH の試行前に証明書失効リスト (CRL) をチェックしたり、サーバーの識別情報をコネクタに構成されているスマート ホストの一覧と照合したりすることが含まれます。名前の照合に成功するには、スマート ホストの一覧に示されている完全修飾ドメイン名 (FQDN) のいずれかがサーバー証明書に存在する必要があります。したがって、スマート ホストの FQDN が MX レコードを指している場合は、一覧に示されているスマート ホストの FQDN が証明書に存在する必要があります。
Exchange Server 認証	コネクタは、以前のバージョンの Exchange Server を実行している Exchange サーバー用の EXPS と GSSAPI、または Exchange 2007 サーバー用の X-ANONYMOUSTLS のいずれかを使用する必要があります。
外部的にセキュリティで保護 (たとえば、IPsec を使用)	Exchange サーバーの外部の機構を使用することにより、ネットワーク接続がセキュリティで保護されます。

トランスポート層セキュリティ

TLS プロトコルは RFC 2246 に定義されています。TLS では X.509 証明書を使用します。これらは電子資格情報の形式をしています。TLS は、次の目的に使用できます。

• 機密保持のみのため。
• サーバー証明書が検証される、機密性を備えたサーバー認証のため。
• クライアントとサーバーの両方の証明書が検証される、機密性を備えた相互認証のため。

SMTP プロトコル通信中に、クライアントは SMTP STARTTLS コマンドを発行して、このセッションのために TLS をネゴシエートするよう要求します。クライアントは、TLS プロトコル ネゴシエーションの一部として、サーバーから X.509 証明書を受信します。次に、クライアントの認証ポリシーによって、受信したサーバー証明書を検証する必要があるかどうか、およびこの証明書に名前の照合などの他の条件を適用する必要があるかどうかが決定されます。

TLS ネゴシエーションのオプションの部分を使用すると、受信側のサーバーも送信側のサーバーに証明書を要求できます。送信側のサーバーが受信側のサーバーに証明書を送信した場合は、受信側のサーバーのローカル ポリシーによって、証明書の検証方法と、認証の結果によって送信側サーバーに与えられるアクセス許可が決定されます。

サーバーの認証に TLS が使用された場合は、受信側サーバーの証明書のみが検証されます。相互認証に TLS が使用された場合は、送信側サーバーの証明書と受信側サーバーの証明書の両方を検証する必要があります。

Exchange 2007 の受信コネクタで TLS が構成されるとき、サーバーには X.509 証明書が存在する必要があります。この証明書は、自己署名入りの証明書、または証明機関 (CA) によって署名された証明書のどちらでもかまいません。Exchange サーバーは、コネクタの FQDN に一致する証明書をローカル ストア内で検索します。送信側のサーバーは、TLS プロトコルの使用方法を選択します。Exchange が機密保持のみのために TLS を使用する場合は、Exchange クライアントは証明書を検証しません。たとえば、Exchange が TLS プロトコルによる Kerberos を使用してハブ トランスポート サーバー間で TLS を使用する場合は、サーバー間に機密のチャネルを確立し、証明書に対する検証を実行しません。TLS プロトコルが完了した後、Kerberos を使用してサーバー間の認証が行われます。

TLS 認証が必要な場合は、Exchange は証明書を検証する必要があります。Exchange は、直接信頼または X.509 検証の 2 つの方法で証明書を検証できます。TLS がエッジ トランスポート サーバーからハブ トランスポート サーバーへの通信に使用される場合、Exchange は直接信頼の機構を使用して証明書を検証します。

直接信頼は、Exchange が、Active Directory や Active Directory Application Mode (ADAM) などの信頼されているストアを使用することを示します。また、ストア内に証明書が存在することで証明書が検証されることも示しています。直接信頼を使用する場合は、証明書が自己署名されているか、または証明機関によって署名されているかはどちらでもかまいません。Exchange 組織でエッジ トランスポート サーバーを購読すると、検証するハブ トランスポート サーバーの Active Directory にエッジ トランスポート サーバー証明書が発行されます。Microsoft Exchange Edgesync サービスが、検証するエッジ トランスポート サーバー用のハブ トランスポート サーバー証明書のセットを使用して ADAM を更新します。

Exchange が証明書を検証するために使用する他の方法として、X.509 検証があります。X.509 検証を使用する場合は、証明書が CA によって署名されている必要があります。Exchange は、スマート ホストを認証する場合や、ドメイン セキュリティを使用する場合に X.509 検証を使用します。ドメイン セキュリティについては、次のセクションで説明します。

ドメイン セキュリティ

ドメイン セキュリティとは、S/MIME やその他のメッセージ レベルのセキュリティ ソリューションに代わる比較的低コストのソリューションを提供する、Exchange 2007 および Microsoft Office Outlook の一連の機能を指します。ドメイン セキュリティの目的は、セキュリティで保護された、ビジネス パートナーとのインターネット経由のメッセージ パスを管理するための手段を管理者に提供することにあります。これらのセキュリティで保護されたメッセージ パスを構成した後、認証された送信者からセキュリティで保護されたパス上を正常に転送されたメッセージは、Outlook および Outlook Web Access のインターフェイスで "セキュリティで保護されたドメイン" としてユーザーに表示されます。

次の条件が満たされた場合、送信コネクタは、対象のドメインがドメイン セキュリティ用に構成されている送信者ドメインの一覧に含まれていることを確認します。

• 送信コネクタが、ドメイン ネーム システム (DNS) の MX (Mail Exchange) リソース レコードを使用してメッセージをルーティングするように構成されている。
• 送信コネクタが、セキュリティで保護されたドメインとして構成されている。

対象のドメインが一覧に含まれている場合、トランスポート サーバーは、そのドメインに電子メールを送信するときに相互 TLS 認証を強制的に適用します。

次の条件が満たされた場合、受信側のサーバーは SMTP QUIT コマンドで応答します。

• Exchange が TLS をネゴシエートできない。
• サーバー証明書の検証または CRL 検証が失敗する。

メッセージは次に、送信側サーバーのキューに入れられます。このキューは再試行状態になります。この動作は、名前の確認に失敗した場合も実行されます。

受信コネクタがセキュリティで保護されたドメインである場合は、トランスポート サーバーが受信メールを確認します。次に、送信者がドメイン セキュリティ用に構成されている受信者ドメインの一覧に含まれている場合、トランスポート サーバーは相互 TLS 認証を強制的に適用します。すべてのチェックに合格すると、受信メッセージが "セキュリティで保護されたドメイン" としてマークされます。送信者が TLS をネゴシエートできない場合や、サーバー証明書の検証または CRL の検証が失敗した場合、トランスポート サーバーは SMTP プロトコルの REJECT コマンドを使用してメッセージを拒否します。名前の確認に失敗した場合も、SMTP プロトコルの REJECT コマンドが発行されます。次に、Exchange サーバーは、一時的な SMTP エラー (4xx) を含むメッセージを送信側のサーバーに送信します。このエラーは、送信側のサーバーが後で再試行する必要があることを示します。この動作によって、一時的な CRL 検証の失敗によって一時エラーが発生しても、直ちに送信者に NDR が通知されることはなくなります。このエラーによって、メッセージ配信の遅延だけが発生します。

詳細については、「ドメインのセキュリティの管理」を参照してください。

外部的にセキュリティで保護された認証

サーバー間のネットワーク接続を信頼できることが保証されている場合は、[外部的にセキュリティで保護] の認証オプションを選択できます。この接続には、IPsec アソシエーションや仮想プライベート ネットワークなどがあります。または、このサーバーは信頼できる物理的に制御されたネットワークに属している場合があります。この構成は、次の場合に有効です。

• Exchange 2007 トランスポート サーバーと以前のバージョンの Exchange Server またはその他の SMTP サーバーとの間にメール フローを確立する。
• 基本認証を使用したくない。

[外部的にセキュリティで保護] として構成されている Exchange コネクタは、コネクタへのすべての接続がセキュリティで保護されていると見なされるため、専用の送信コネクタと受信コネクタを使用する必要があります。したがって、[外部的にセキュリティで保護] として構成されている送信コネクタは、メッセージのルーティングにスマート ホストを使用する必要があります。また、コネクタで、送信先のスマート ホストの IP アドレスを構成することも必要です。[外部的にセキュリティで保護] として構成されている受信コネクタは、RemoteIPRanges が送信側サーバーの IP アドレスの範囲に設定されている必要があります。また、TLS を [外部的にセキュリティで保護] の認証オプションと組み合わることにより、セッションの機密性を向上させることもできます。Exchange 管理シェルでこれを実現するには、コネクタの RequireTLS パラメータを $True に設定します。

承認

メッセージ トランスポート中に、SMTP セッションに対して、メールの送信などの要求された操作を許可するかどうかを決定するプロセスが承認です。

Exchange 2007 のトランスポート アクセス許可

Exchange 2007 トランスポート サーバーは、SMTP セッションに対する Windows 承認モデルを使用して、たとえば、送信者が特定のコネクタまたは特定の受信者へのメッセージ送信を承認されているかどうかや、特定の送信者として承認されているかどうかを判断します。SMTP セッションは、初期のアクセス許可のセット (匿名) を受信します。セッションが認証された後、そのセッションに対してより多くのアクセス許可が使用可能になります。これにより、そのセッションに対して承認されている操作のセットが変化します。

Windows 承認モデルの場合、アクセス許可は、アクセス トークンとアクセス制御リスト (ACL) を比較するアクセス制御操作を通して与えられます。アクセス トークンによって、セキュリティ プリンシパルのセットが示されます。セキュリティ プリンシパルには、ユーザー アカウント、コンピュータ アカウント、またはセキュリティ グループがあります。すべてのセキュリティ プリンシパルに、セキュリティ識別子 (SID) が関連付けられています。各セッションには、アクセス トークンが割り当てられます。ACL は、Active Directory または ADAM 内のコネクタ オブジェクトで定義されます。DACL には、一連のアクセス制御エントリ (ACE) が含まれています。各 ACE によって、セキュリティ プリンシパルへのアクセス許可が許可または拒否されます。トランスポート サーバーは、セッションに電子メールの送信などのアクセス許可を与えるかどうかを決定する場合、API に対する Windows のアクセスの確認を呼び出し、要求されたアクセス許可と共に、セッション アクセス トークンとコネクタの DACL をパラメータとして提供します。

このプロセスは、ファイルの読み取りアクセス許可を決定する方法と同じです。アクセス トークン、DACL ファイル、および要求されたアクセス許可が、同じ API に送信されます。この API は、アクセス トークンに示されている各セキュリティ プリンシパルを DACL 内の各 ACE と照合して、要求されたアクセス許可を許可するか、または拒否するかを決定します。Active Directory、ADAM、またはコンピュータ上のローカルのセキュリティ アカウント マネージャ (SAM) データベースによって提供される Windows SID に加え、Exchange 2007 は追加の SID を定義します。これらの SID は論理グループを表します。表 3 は、トランスポートの認証中に使用するために Exchange 2007 によって定義される SID の一覧を示しています。

表 3   Exchange 2007 の SID

表示名	SID	論理グループ
パートナー サーバー	S-1-9-1419165041-1139599005-3936102811-1022490595-10	ドメイン セキュリティ用に構成されている送信者ドメインおよび受信者ドメイン。
ハブ トランスポート サーバー	S-1-9-1419165041-1139599005-3936102811-1022490595-21	同じ Exchange 組織内のハブ トランスポート サーバー。
エッジ トランスポート サーバー	S-1-9-1419165041-1139599005-3936102811-1022490595-22	信頼されているエッジ トランスポート サーバー。
外部的にセキュリティで保護されたサーバー	S-1-9-1419165041-1139599005-3936102811-1022490595-23	同一の権限のあるドメイン内に存在する信頼されているサード パーティ製サーバー。
従来の Exchange サーバー	S-1-9-1419165041-1139599005-3936102811-1022490595-24	同じ Exchange 組織内の Exchange Server 2003 サーバー。

受信コネクタのアクセス許可

受信コネクタは、サーバーへの受信セッションを処理します。このセッションは、認証された送信者または匿名の送信者によって確立される可能性があります。セッションが正常に認証されると、セッション アクセス トークン内の SID が更新されます。表 4 は、受信コネクタに接続しているセッションに与えることのできるアクセス許可の一覧を示しています。

表 4   受信コネクタのアクセス許可

アクセス許可	表示名	説明
ms-Exch-SMTP-Submit	メッセージをサーバーに発信する	セッションにはこのアクセス許可を与える必要があります。そうしないと、セッションはこの受信コネクタにメッセージを送信できません。セッションがこのアクセス許可を持っていない場合、MAIL FROM コマンドは失敗します。
ms-Exch-SMTP-Accept-Any-Recipient	メッセージを任意の受信者に発信する	このアクセス許可によって、セッションはこのコネクタを介してメッセージを中継できます。このアクセス許可が与えられていない場合、このコネクタでは、承認済みドメイン内の受信者宛てのメッセージのみが受け付けられます。
ms-Exch-SMTP-Accept-Any-Sender	すべての送信者を受け入れる	このアクセス許可によって、セッションは送信者アドレスのスプーフィング チェックを省略できます。
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender	権限のあるドメインの送信者を受け入れる	このアクセス許可によって、セッションは、権限のあるドメイン内の電子メール アドレスからの受信メッセージを阻止するチェックを省略できます。
ms-Exch-SMTP-Accept-Authentication-Flag	認証フラグを受け入れる	このアクセス許可によって、以前のバージョンの Exchange Server を実行している Exchange サーバーは、内部の送信者からのメッセージを送信できます。Exchange 2007 サーバーは、このメッセージが内部のメッセージであると認識します。
ms-Exch-Accept-Headers-Routing	ルーティング ヘッダーを受け入れる	このアクセス許可によって、セッションは、すべての受信ヘッダーが変更されていないメッセージを送信できます。このアクセス許可が与えられていない場合、サーバーはすべての受信ヘッダーを削除します。
ms-Exch-Accept-Headers-Organization	組織ヘッダーを受け入れる	このアクセス許可によって、セッションは、すべての組織ヘッダーが変更されていないメッセージを送信できます。組織ヘッダーはすべて、"X-MS-Exchange-Organization-" で始まります。このアクセス許可が与えられていない場合、受信側のサーバーはすべての組織ヘッダーを削除します。
ms-Exch-Accept-Headers-Forest	フォレスト ヘッダーを受け入れる	このアクセス許可によって、セッションは、すべてのフォレスト ヘッダーが変更されていないメッセージを送信できます。フォレスト ヘッダーはすべて、"X-MS-Exchange-Forest-" で始まります。このアクセス許可が与えられていない場合、受信側のサーバーはすべてのフォレスト ヘッダーを削除します。
ms-Exch-Accept-Exch50	Exch50 を受け入れる	このアクセス許可によって、セッションは XEXCH50 コマンドが含まれたメッセージを送信できます。このコマンドは、Exchange 2000 Server および Exchange 2003 との相互運用に必要です。XEXCH50 コマンドは、メッセージの SCL (Spam Confidence Level) などのデータを提供します。
ms-Exch-Bypass-Message-Size-Limit	メッセージ サイズの制限を省略する	このアクセス許可によって、セッションは、コネクタで構成されているメッセージのサイズ制限を超えるメッセージを送信できます。
Ms-Exch-Bypass-Anti-Spam	スパム対策を省略する	このアクセス許可によって、セッションはスパム対策フィルタを省略できます。

送信コネクタのアクセス許可

送信コネクタは、他のサーバーへの送信セッションを処理します。このセッションは、匿名の受信者または認証された受信者への送信者によって確立される可能性があります。セッションが正常に認証されると、セッション アクセス トークン内の一連の SID が更新されます。送信コネクタのアクセス許可によって、このコネクタを使用して送信されるメッセージに含めることのできるヘッダー情報の種類が決定されます。一般に、組織内の他の Exchange サーバー、またはフォレスト間のシナリオにある信頼された Exchange 組織に送信されるメッセージでは、すべてのヘッダーの送信が許可されています。インターネットまたは Exchange 以外の SMTP サーバーに送信されるメッセージの場合は、すべてのヘッダーを含めることは許可されません。メッセージにヘッダーが含まれていると、Exchange 2007 のヘッダー ファイアウォール機能によってこれらのヘッダーが削除されます。表 5 は、送信コネクタに接続しているセッションに与えることのできるアクセス許可の一覧を示しています。

表 5   送信コネクタのアクセス許可

アクセス許可	表示名	説明
ms-Exch-Send-Exch50	Exch50 を送信する	このアクセス許可によって、セッションは EXCH50 コマンドが含まれたメッセージを送信できます。このアクセス許可が与えられていない場合、サーバーはメッセージを送信しますが、EXCH50 コマンドは含まれません。
Ms-Exch-Send-Headers-Routing	ルーティング ヘッダーを送信する	このアクセス許可によって、セッションは、すべての受信ヘッダーが変更されていない状態のメッセージを送信できます。このアクセス許可が与えられていない場合、サーバーはすべての受信ヘッダーを削除します。
Ms-Exch-Send-Headers-Organization	組織ヘッダーを送信する	このアクセス許可によって、セッションは、すべての組織ヘッダーが変更されていないメッセージを送信できます。組織ヘッダーはすべて、"X-MS-Exchange-Organization-" で始まります。このアクセス許可が与えられていない場合、送信側のサーバーはすべての組織ヘッダーを削除します。
Ms-Exch-Send-Headers-Forest	フォレスト ヘッダーを送信する	このアクセス許可によって、セッションは、すべてのフォレスト ヘッダーが変更されていない状態のメッセージを送信できます。フォレスト ヘッダーはすべて、"X-MS-Exchange-Forest-" で始まります。このアクセス許可が与えられていない場合、送信側のサーバーはすべてのフォレスト ヘッダーを削除します。

許可グループ

許可グループは、受信コネクタに与えることのできる定義済みのアクセス許可のセットです。許可グループは受信コネクタでのみ使用できます。許可グループを使用すると、受信コネクタでのアクセス許可の構成が簡略化されます。PermissionGroups プロパティは、受信コネクタにメッセージを送信できるグループまたは役割と、それらのグループに許可されるアクセス許可を定義します。Exchange 2007 では、一連の許可グループがあらかじめ定義されています。したがって、追加の許可グループを作成することはできません。さらに、許可グループのメンバや、関連付けられたアクセス許可を変更することもできません。

表 6 は、許可グループ、許可グループのメンバ、および Exchange 2007 で使用できる関連付けられたアクセス許可の一覧を示しています。

表 6   受信コネクタの許可グループとそれに関連付けられたアクセス許可

許可グループの名前	セキュリティ プリンシパル	エッジ トランスポート サーバーに与えられるアクセス許可	ハブ トランスポート サーバーに与えられるアクセス許可
Anonymous	匿名ユーザー	メッセージをサーバーに発信する すべての送信者を受け入れる ルーティング ヘッダーを受け入れる	メッセージをサーバーに発信する すべての送信者を受け入れる ルーティング ヘッダーを受け入れる
ExchangeUsers	認証済みユーザー (既知のアカウントは除外される)	使用不可	メッセージをサーバーに発信する すべての受信者を受け入れる スパム対策フィルタを省略する
Exchange Servers	Exchange 2007 サーバー	すべての受信アクセス許可	すべての受信アクセス許可
ExchangeLegacyServers	Exchange 2003 および Exchange 2000 サーバー	使用不可	メッセージをサーバーに発信する メッセージを任意の受信者に発信する すべての送信者を受け入れる 権限のあるドメインの送信者を受け入れる 認証フラグを受け入れる ルーティング ヘッダーを受け入れる Exch50 を受け入れる メッセージ サイズの制限を省略する スパム対策フィルタを省略する
パートナー	パートナー サーバー アカウント	メッセージをサーバーに発信する ルーティング ヘッダーを受け入れる	メッセージをサーバーに発信する ルーティング ヘッダーを受け入れる

コネクタの使用法の種類

新しいコネクタを作成するときに、そのコネクタの使用法の種類を指定できます。使用法の種類によって、コネクタの既定の設定が決定されます。この設定には、認証される SID、それらの SID に割り当てられるアクセス許可、認証機構などがあります。

表 7 は、受信コネクタで使用できる使用法の種類を示しています。受信コネクタの使用法の種類を選択すると、そのコネクタに許可グループが自動的に割り当てられます。また、既定の認証機構も構成されます。

表 7   受信コネクタの使用法の種類

使用法の種類	既定の許可グループ	既定の認証機構
クライアント	ExchangeUsers	TLS BasicAuthPlusTLS
カスタム	なし	なし
内部	ExchangeServers ExchangeLegacyServers	Exchange Server 認証
インターネット	AnonymousUsers Partner	なし、または外部的にセキュリティで保護
Partner	Partner	該当なし。この使用法の種類は、リモート ドメインとの相互 TLS 認証を確立したときに選択されます。

表 8 は、送信コネクタで使用できる使用法の種類を示しています。送信コネクタの使用法の種類を選択すると、SID にアクセス許可が自動的に割り当てられます。また、既定の認証機構も構成されます。

表 8   送信コネクタの使用法の種類

使用法の種類	既定のアクセス許可	セキュリティ プリンシパル	スマート ホストに対する既定の認証機構
Custom	なし	なし	なし
Internal	組織ヘッダーを送信する Exch50 を送信する ルーティング ヘッダーを送信する フォレスト ヘッダーを送信する	ハブ トランスポート サーバー エッジ トランスポート サーバー Exchange Servers セキュリティ グループ 外部的にセキュリティで保護されたサーバー Exchange Legacy Interop セキュリティ グループ Exchange 2003 および Exchange 2000 ブリッジヘッド サーバー	Exchange Server 認証
Internet	ルーティング ヘッダーを送信する	匿名ユーザー アカウント	特にありません。
Partner	ルーティング ヘッダーを送信する	パートナー サーバー	該当なし。この使用法の種類は、リモート ドメインとの相互 TLS 認証を確立したときに選択されます。

送信コネクタまたは受信コネクタで使用法の種類として [カスタム] を選択する場合は、認証方法と承認される SID を手動で構成し、それらの SID にアクセス許可を割り当てる必要があります。使用法の種類を指定しない場合、コネクタの使用法の種類は [カスタム] に設定されます。

Enable-CrossForestConnector スクリプトを使用したアクセス許可の設定

Enable-CrossForestConnector.ps1 スクリプトを使用すると、フォレスト間コネクタでアクセス許可を構成する方法が簡略化されます。このスクリプトは、許可グループの場合と同様の方法でアクセス許可を割り当てます。定義済みのアクセス許可のセットが、送信コネクタまたは受信コネクタに割り当てられます。Enable-CrossForestConnector.ps1 スクリプトの内容を変更すると、実際の接続シナリオに応じてアクセス許可のセットを変更できます。詳細については、「フォレスト間コネクタの構成」を参照してください。

Add-AdPermission コマンドレットを使用したアクセス許可の設定

Exchange 管理シェルの Add-AdPermission コマンドレットは、Active Directory に格納されているオブジェクトにアクセス許可を割り当てるために使用されるグローバル コマンドレットです。Add-AdPermission コマンドレットを使用すると、送信コネクタまたは受信コネクタに個別のアクセス許可を与えることができます。Add-AdPermission コマンドレットは一般に、トランスポート アクセス許可の管理には使用されません。ただし、次のシナリオでアクセス許可を構成する場合は、このコマンドレットを使用する必要があります。

• フォレスト間のシナリオでメール フローを確立する。
• 権限のあるドメイン内の送信者から送信された、インターネット経由の匿名の電子メールを受け付ける。

Exchange 2007 のトランスポート アクセス許可は、このコマンドレットを使用して割り当てることのできる拡張権利のセットの一部です。次の手順は、Add-AdPermission コマンドレットを使用してハブ トランスポート サーバーの受信コネクタにアクセス許可を設定することにより、匿名セッションでメッセージを送信できるようにする方法を示しています。

Exchange 管理シェルを使用して受信コネクタにアクセス許可を設定する方法

• 次のコマンドを実行します。

  Add-AdPermission -Identity "Default Hub1" -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam
  

Get-AdPermission コマンドレットを使用して、送信コネクタまたは受信コネクタの DACL を表示することができます。受信コネクタに割り当てられているアクセス許可を取得し、その結果を書式設定された表に表示するには、次のいずれかのコマンドを実行します。

Exchange 管理シェルを使用して受信コネクタ上の拡張されたアクセス許可を表示する方法

• 次のいずれかのコマンドを実行します。

  Get-AdPermission -Identity "Default ServerName" | format-table -view User
  Get-AdPermission -Identity "Default ServerName" | format-table -view Identity
  

Remove-AdPermission コマンドレットを使用して、以前に割り当てられた任意のアクセス許可を削除することができます。

Exchange 管理シェルを使用してアクセス許可を設定、表示、および削除する方法の詳細については、以下のトピックを参照してください。

• Add-ADPermission
• Get-ADPermission
• Remove-ADPermission

ADSI Edit を使用したアクセス許可の設定

Active Directory サービス インターフェイス (ADSI) Edit は、Windows Support Tools で提供されている Microsoft 管理コンソールです。ADSI Edit は、他の管理インターフェイスには表示されない Active Directory または ADAM オブジェクトのプロパティを変更するための、低レベルのエディタとして使用されます。ADSI Edit は、経験豊富な管理者だけが使用するようにしてください。

ADSI Edit を使用すると、送信コネクタや受信コネクタの ACL を表示および変更することができます。ADSI Edit を開いた後、コネクタ オブジェクトを見つけます。Exchange 2007 コネクタは、ディレクトリ サービスの構成パーティション内に格納されています。送信コネクタは、Connections コンテナ内にオブジェクトとして格納されています。受信コネクタは、Exchange 2007 トランスポート サーバーの子オブジェクトとして格納されています。

ADSI Edit を使用して受信コネクタのアクセス許可を変更するには、次の操作を行います。

1. 次の場所に移動して、受信コネクタを見つけます。

   CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<組織>\CN=Administrative Groups\CN=Exchange Administrative Group (FYDIBOHF23SPDLT)\CN=Servers\CN=<サーバー名>\CN=Protocols\CN=SMTP Receive Connectors

2. 結果ウィンドウで受信コネクタを選択します。右クリックし、[プロパティ] をクリックします。

3. [セキュリティ] タブをクリックします。次の画面が表示されます。

   

4. [追加] をクリックして、アクセス許可を与えるユーザーまたはグループを選択するか、または既存の [グループ名またはユーザー名] エントリを選択します。

5. アカウントに割り当てるアクセス許可を選択し、[許可] 列のチェック ボックスをオンにします。

ADSI Edit を使用して送信コネクタのアクセス許可を変更するには、次の操作を行います。

1. 次の場所に移動して、送信コネクタを見つけます。

   CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<組織>\CN=Administrative Groups\CN=Exchange Administrative Group(FYDIBOHF23SPDLT)\CN=Routing Groups\CN=Routing Group (DWBGZMFD01QNBJR)\CN=Connections

2. 結果ウィンドウで送信コネクタを選択します。右クリックし、[プロパティ] をクリックします。

3. [セキュリティ] タブをクリックします。次の画面が表示されます。

   

4. [追加] をクリックして、アクセス許可を与えるユーザーまたはグループを選択するか、または既存の [グループ名またはユーザー名] エントリを選択します。

5. アカウントに割り当てるアクセス許可を選択し、[許可] 列のチェック ボックスをオンにします。

アクセス許可のトラブルシューティング

プロトコル通信中、アクセス許可がないために、SMTP サーバーによって特定のコマンドが拒否されることがあります。表 9 は、最も一般的なプロトコル拒否メッセージと、そのエラーを引き起こすアクセス許可の構成を示しています。

表 9   一般的なプロトコル拒否メッセージとその原因

SMTP サーバー応答	原因
530 5.7.1 Client was not authenticated (クライアントが認証されませんでした)	SMTP プロトコルの MAIL FROM フィールドで指定されている送信者が、このサーバーに送信するためのアクセス許可を持っていません。送信者に ms-Exch-SMTP-Submit アクセス許可を与える必要があります。
535 5.7.3 Authentication unsuccessful (認証に失敗しました)	SMTP プロトコル通信の AUTH フェーズ中、提供された資格情報が正しくなかったか、または認証されたユーザーがこのサーバーに送信するためのアクセス許可を持っていません。
550 5.7.1 Client does not have permission to submit to this server (クライアントにはこのサーバーに送信するためのアクセス許可がありません)	SMTP プロトコル通信の MAIL FROM フィールドで指定されている送信者が認証されましたが、このサーバーに送信するためのアクセス許可を持っていません。
550 5.7.1 Client does not have permission to send as this sender (クライアントにはこの送信者として送信するためのアクセス許可がありません)	SMTP プロトコル通信の MAIL FROM フィールドで指定されている送信者は、権限のあるドメイン内のアドレスです。ただし、セッションに ms-Exch-SMTP-Accept-Authoritative-Domain-Sender アクセス許可がありません。この問題は、メッセージが、Exchange 組織が権限を持つ送信者アドレスからエッジ トランスポート サーバーにインターネット経由で送信された場合に発生することがあります。
550 5.7.1 Client does not have permission to send on behalf of the from address (クライアントには差出人のアドレスを使用して代理で送信するためのアクセス許可がありません)	認証されたユーザーが、メッセージのヘッダーで指定されている送信者に代わってメッセージを送信するためのアクセス許可を持っていません。また、セッションにも ms-Exch-SMTP-Accept-Any-Sender アクセス許可がありません。
550 5.7.1. Unable to relay (中継できません)	メッセージの宛先になっている受信者ドメインが、この組織に対して定義されているどの承認済みドメインにも存在しません。また、セッションにも ms-Exch-SMTP-Accept-Any-Recipient アクセス許可がありません。

詳細情報

詳細については、以下のトピックを参照してください。

• 送信コネクタ
• 受信コネクタ
• Set-SendConnector
• Set-ReceiveConnector
• Add-ADPermission
• Get-ADPermission
• 承認済みドメインの管理

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