次の方法で共有

ドメイン セキュリティのために相互 TLS を構成する方法

  • [アーティクル]

 

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

トピックの最終更新日: 2009-04-20

ここでは、Exchange 管理シェルを使用して、Microsoft Exchange Server 2007 と Microsoft Office Outlook 2007 の一連の機能である、ドメイン セキュリティのための相互 TLS を構成して、S/MIME およびその他のメッセージレベルのセキュリティ ソリューションに対して比較的低コストな代替方法を提供する方法について説明します。

わかりやすくするために、ここでは、Contoso という架空の企業の Exchange 管理者が、パートナーである Woodgrove 銀行と、ドメインのセキュリティで保護された電子メールを交換するように、Exchange 2007 環境を構成する方法を説明します。このシナリオでは、Contoso は、Woodgrove 銀行と送受信する電子メールはすべて相互 TLS で確実に保護されるようにしたいと考えています。また、Contoso は、相互 TLS を使用できない場合、Woodgrove 銀行と送受信する電子メールはすべて拒否されるようにドメイン セキュリティ機能を構成したいとも考えています。

Contoso は、証明書を生成する内部公開キー基盤 (PKI) を持っています。PKI のルート証明書は、主要な第三者の認証機関 (CA) によって署名されています。Woodgrove 銀行は、同じ第三者 CA を使用して、証明書を生成します。したがって、Contoso と Woodgrove 銀行は互いに相手のルート CA を信頼しています。

相互 TLS を設定するために、Contoso の Exchange 管理者は次の手順を実行します。

  1. TLS 証明書用の証明書要求を生成します。
  2. 証明書をエッジ トランスポート サーバーにインポートします。
  3. 送信ドメイン セキュリティを構成します。
  4. 受信ドメイン セキュリティを構成します。
  5. メール フローをテストします。

開始する前に

相互 TLS の構成には、以下のものが必要です。

  • 送信コネクタを構成していない場合の、Set-TransportConfig コマンドレットと New-SendConnector コマンドレットを使用した内部 Exchange 2007 サーバーへのアクセス。
  • ExchangeCertificate コマンドレットが実行されているエッジ トランスポート サーバー コンピュータへのアクセス。

通常は、ExchangeCertificate コマンドレットを使用しないドメイン セキュリティ機能に対して行われる構成の変更は組織内で行い、Microsoft Exchange EdgeSync サービスを使用してエッジ トランスポート サーバーと同期する必要があります。

ExchangeCertificate コマンドレットを使用して TLS 証明書をインポートおよび構成する場合、構成する対象のエッジ トランスポート サーバーでコマンドレットを実行する必要があります。エッジ トランスポート サーバーの役割がインストールされているコンピュータで ExchangeCertificate コマンドレットを実行するには、そのコンピュータのローカルの Administrators グループのメンバであるアカウントを使用してログオンする必要があります。

Set-TransportConfig コマンドレットを実行するには、使用するアカウントに Exchange 組織管理者の役割が委任されている必要があります。

New-SendConnector コマンドレットを実行するには、使用するアカウントに Exchange サーバー管理者の役割、および対象のコンピュータのローカルの Administrators グループが委任されている必要があります。

アクセス許可、役割の委任、および Exchange 2007 を管理するために必要な権限の詳細については、「アクセス許可に関する考慮事項」を参照してください。

このトピックは、読者が既に「TLS の証明書または証明書の要求の作成」を読んで理解していることを前提としています。

Microsoft Exchange EdgeSync サービスは、ドメイン セキュリティのために完全に展開されている必要があります。

エッジ トランスポート サーバーで相互 TLS を正常に実行できるようにする前に、証明書の検証と証明書失効リストのチェックが有効になるように、コンピュータと PKI 環境を構成しておく必要があります。詳細については、「ドメイン セキュリティのためにエッジ トランスポート サーバーの PKI を有効にする方法」を参照してください。

TLS 証明書のための証明書要求の生成

前に説明したように、Contoso は、第三者 CA の下位にある内部 PKI を持っています。このシナリオでは、下位とは、Contoso が自身の企業インフラストラクチャに展開している CA に、公的な第三者 CA によって署名されたルート証明書が含まれていることを指します。既定では、公的な第三者 CA は、Microsoft Windows 証明書ストアにある信頼されたルート証明書の 1 つです。したがって、信頼されたルート ストアに同じ第三者 CA が含まれ、Contoso に接続するクライアントは、Contoso が提示する証明書によって認証を受けることができます。

Contoso には、mail1.contoso.com と mail2.mail.contoso.com という、TLS 証明書が必要な 2 つのエッジ トランスポート サーバーがあります。したがって、Contoso の電子メール管理者は、各サーバーに 1 つずつ、2 つの証明書要求を生成する必要があります。

次の手順は、管理者が Base64 で符号化された PKCS#10 証明書要求の生成に使用するコマンドを示しています。Contoso 管理者は、このコマンドを 2 回実行する必要があります。1 回は CN=mail1.contoso.com 用で、もう 1 回は CN=mail2.mail.contoso.com 用です。

note注 :
コマンドを実行して得られた証明書のサブジェクト名の共通名 (CN) はそれぞれ、mail1.contoso.com と mail2.mail.contoso.com です。サブジェクトの別名には "mail.contoso.com" が含まれていますが、これは Contoso 用に構成されている、いずれかの承認済みドメインの完全修飾ドメイン名 (FQDN) です。

TLS 証明書要求を作成するには、次の操作を行います。

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

    New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate" -Path c:\certificates\request.p7c -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com"  -DomainName mail.contoso.com

構文およびパラメータの詳細については、「New-ExchangeCertificate」を参照してください。

important重要 :
作成する証明書または証明書の要求の具体的な詳細は、多くの変数に依存します。要求を生成している場合、証明書を発行する CA または PKI 管理者と緊密に連携して作業するようにしてください。TLS の証明書の要求を作成する方法の詳細については、「TLS の証明書または証明書の要求の作成」を参照してください。

証明書および関連するキーのトランスポート

PKI または CA プロバイダから証明書を受信したら、災害対策の一環としてバックアップできるように、発行された証明書を PFX (PKCS#12) ファイルに変換します。PFX ファイルには、証明書および関連するキーが含まれます。証明書とキーをトランスポートして別のコンピュータに移動することが必要な場合もあります。たとえば、ドメインのセキュリティで保護された電子メールを送受信する複数のエッジ トランスポート サーバーがある場合、すべてのサーバーで機能する 1 つの証明書を作成できます。この場合、各エッジ トランスポート サーバーに TLS の証明書をインポートして有効にする必要があります。

PFX ファイルのコピーを安全な場所にアーカイブして保存する限り、証明書をいつでもインポートして有効にすることができます。PFX ファイルには秘密キーが含まれるので、安全な場所の記憶装置に保存することで、物理的にファイルを保護することが重要です。

Import-ExchangeCertificate コマンドレットは常に PFX からの秘密キーをエクスポート不可としてマークします。この機能は意図的なものです。

Microsoft 管理コンソール (MMC) で証明書マネージャ スナップインを使用して PFX ファイルをインポートする場合、秘密キーをエクスポート可能にして、強力なキー保護を指定することができます。

important重要 :
TLS 用の証明書に対しては強力なキー保護を有効にしないでください。強力なキー保護を有効にすると、秘密キーにアクセスするたびにプロンプトが表示されます。ドメイン セキュリティを使用する場合、"ユーザー" はエッジ トランスポート サーバー上の SMTP サービスです。

証明書のエッジ トランスポート サーバーへのインポート

管理者は、証明書要求を生成した後で、その要求を使用してサーバーの証明書を生成します。生成された証明書は、単一の証明書または証明書チェーンとして発行され、適切なエッジ トランスポート サーバーにコピーされる必要があります。

important重要 :
証明書をインポートするには、Import-ExchangeCertificate コマンドレットを使用する必要があります。詳細については、「Import-ExchangeCertificate」を参照してください。
important重要 :
TLS の証明書は、MMC で証明書マネージャ スナップインを使用して Exchange サーバーにインポートしないでください。証明書マネージャ スナップインを使用して証明書を Exchange サーバーにインポートしても、この手順で作成される要求は発行済みの証明書にはバインドされません。したがって、TLS は失敗する可能性があります。PFX ファイルとして保存される証明書およびキーは、証明書マネージャ スナップインを使用してローカル コンピュータ ストアにインポートすることができます。証明書をインポートした後、Enable-ExchangeCertificate コマンドレットを実行して、TLS の証明書を有効にすることができます。

証明書をエッジ トランスポート サーバーにインポートするときは、SMTP (簡易メール転送プロトコル) サービスの証明書も有効にする必要があります。Contoso 管理者は、各エッジ トランスポート サーバー上で、各証明書に 1 回ずつ次のコマンドを実行します。

エッジ トランスポート サーバーにドメイン セキュリティのための TLS 証明書をインポートして有効にするには、次の操作を行います。

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

    Import-ExchangeCertificate -Path c:\certificates\import.pfx | Enable-ExchangeCertificate -Services SMTP

このコマンドは、Enable-ExchangeCertificate コマンドレットをパイプライン処理することによって、TLS 証明書をインポートして有効にします。

また、インポートした後で証明書を有効にすることもできます。証明書をインポートするには、次のコマンドを実行します。

Import-ExchangeCertificate -Path c:\certificates\import.pfx

その後、拇印を Windows のクリップボードにコピーします。インポートした証明書の拇印を表示するには、次のコマンドを実行します。

Get-ExchangeCertificate |FL

"拇印" フィールドのデータを Windows のクリップボードにコピーします。

最後に、証明書を有効にするには、次のコマンドを実行します。

Enable-ExchangeCertificate -Thumbprint AB493A0C9A6C0327162FE04EF74609CB8FB7FE24 -Services SMTP

送信ドメイン セキュリティの構成

送信ドメイン セキュリティを構成するには、次の 3 つの手順を実行する必要があります。

  1. Set-TransportConfig コマンドレットを実行して、ドメインのセキュリティで保護された電子メールを送信するために使用するドメインを指定します。
  2. Set-SendConnector コマンドレットを実行して、ドメインのセキュリティで保護された電子メールを送信するために使用するドメインにメールを送信する送信コネクタの DomainSecureEnabled プロパティを設定します。
  3. Set-SendConnector コマンドレットを実行して、以下のことを確認します。
    • ドメインのセキュリティで保護された電子メールを送信するために使用するドメインにメールを送信する送信コネクタが、DNS (ドメイン ネーム システム) を使用してメールをルーティングしている。
    • ドメイン セキュリティに使用する証明書のサブジェクト名またはサブジェクトの別名と一致させるために、FQDN が設定されている。

これらの 3 つの手順で行う変更はグローバルなので、変更は内部の Exchange サーバー上で行う必要があります。構成に加えた変更は、Microsoft Exchange EdgeSync サービスを使用して、エッジ トランスポート サーバーにレプリケートされます。

トランスポート構成の送信側ドメインの指定

ドメインのセキュリティで保護された電子メールを送信するために使用するドメインを指定することは、比較的簡単です。Contoso 管理者は、内部の Exchange 2007 サーバーで次のコマンドを実行します。

Set-TransportConfig -TLSSendDomainSecureList woodgrovebank.com

詳細については、「Set-TransportConfig」を参照してください。

note注 :
TLSSendDomainSecureList パラメータには、ドメイン名を複数値の一覧で指定できます。Set-TransportConfig コマンドは、TLSSendDomainSecureList のすべての値を、コマンドレットで指定された新しい値に置き換えます。したがって、新しいドメインを追加するときは、指定する値には既存の一覧と新しいドメインを含める必要があります。

送信コネクタの構成

Contoso は、既定の DNS ルーティングの対象となる送信コネクタを使用して、ドメインのセキュリティで保護された電子メールをパートナーに送信します。既定の DNS ルーティングの対象となる送信コネクタは既定のインターネット送信コネクタなので、スマート ホストではなく、DNS を使用してメールがルーティングされます。FQDN は、既に mail.contoso.com に設定されています。Contoso 管理者が作成した証明書は、New-ExchangeCertificate の DomainName パラメータを mail.contoso.com に設定しているので、送信コネクタは、追加の構成なしで証明書を使用することができます。

テスト用のサブドメインを構成している場合は、作成した証明書と一致するように、送信コネクタの FQDN を更新することが必要な場合があります (subdomain.mail.contoso.com など)。一方、"サブジェクト" または "サブジェクトの別名" フィールドにサブドメインを含む証明書を作成した場合は、送信コネクタの FQDN を更新する必要はありません。

したがって、Contoso 管理者が送信コネクタに対して行う必要のある構成は、DomainSecureEnabled パラメータを設定することだけです。この設定を行うには、Contoso 管理者は、"インターネット" 送信コネクタ用の内部の Exchange 2007 サーバーで次のコマンドを実行します。

Set-SendConnector Internet -DomainSecureEnabled:$True

詳細については、「Set-SendConnector」を参照してください。

また、Exchange 管理コンソールを使用して、送信コネクタでドメインのセキュリティで保護された電子メールを有効にすることもできます。

Exchange 管理コンソールを使用して、ドメイン セキュリティのための送信コネクタを構成するには、次の操作を行います。

  1. ハブ トランスポート サーバーで、Exchange 管理コンソールを開き、[組織の構成] をクリックし、[ハブ トランスポート] をクリックします。次に、結果ウィンドウの [送信コネクタ] タブをクリックします。

  2. ドメインのセキュリティで保護された電子メールの送信元となるドメインにメールを送信する送信コネクタを選択し、次に、操作ウィンドウの [プロパティ] をクリックします。

  3. [ネットワーク] タブで、[ドメイン セキュリティを有効にする (相互認証 TLS)] を選択し、[適用] をクリックして、[OK] をクリックします。

受信ドメイン セキュリティの構成

受信ドメイン セキュリティを構成するには、次の 2 つの手順を実行する必要があります。

  1. Set-TransportConfig コマンドレットを実行して、ドメインのセキュリティで保護された電子メールの送信元であるドメインを指定します。
  2. エッジ トランスポート サーバーで、Exchange 管理シェルまたは Exchange 管理コンソールを使用して、ドメインのセキュリティで保護された電子メールの送信元である受信コネクタのドメイン セキュリティを有効にします。ドメイン セキュリティには、相互 TLS 認証が必要なので、受信コネクタの TLS も有効にする必要があります。

トランスポート構成の受信者ドメインの指定

ドメインのセキュリティで保護された電子メールを受信するために使用するドメインを指定することは、比較的簡単です。ドメインを指定するには、Contoso 管理者は、内部の Exchange 2007 サーバーで次のコマンドを実行します。

Set-TransportConfig -TLSReceiveDomainSecureList woodgrovebank.com

詳細については、「Set-TransportConfig」を参照してください。

note注 :
TLSReceiveDomainSecureList パラメータには、ドメイン名を複数値の一覧で指定できます。Set-TransportConfig コマンドは、TLSReceiveDomainSecureList パラメータのすべての値を、Set-TransportConfig コマンドレットで指定された新しい値に置き換えます。したがって、新しいドメインを追加するときは、指定する値には既存の一覧と新しいドメインを含める必要があります。

受信コネクタの構成

ドメインのセキュリティで保護された電子メールの送信元であるドメインからのメールを受け付ける、各エッジ トランスポート サーバーに受信コネクタを構成する必要があります。Contoso 環境は、両方のエッジ トランスポート サーバーに Inet という ID で、単一のインターネット受信コネクタを持つように構成されています。したがって、Woodgrove 銀行とのメールを送受信するときに TLS を有効にするには、Contoso 管理者は、両方のエッジ トランスポート サーバーの既定のインターネット受信コネクタで TLS が有効になっていることを確認する必要があります。

Exchange 管理シェルを使用して、ドメイン セキュリティのための受信コネクタを構成するには、次の操作を行います。

  • エッジ トランスポート サーバーで、次のコマンドを実行します。

    Set-ReceiveConnector Inet -DomainSecureEnabled:$True -AuthMechanism TLS

構文およびパラメータの詳細については、「Set-ReceiveConnector」を参照してください。

Exchange 管理コンソールを使用して、ドメイン セキュリティのための受信コネクタを構成するには、次の操作を行います。

  1. エッジ トランスポート サーバーで、Exchange 管理コンソールを開き、[エッジ トランスポート] をクリックします。次に、結果ウィンドウの [受信コネクタ] タブをクリックします。

  2. ドメインのセキュリティで保護された電子メールの送信元となるドメインからのメールを受け付ける受信コネクタを選択し、次に、操作ウィンドウの [プロパティ] をクリックします。

  3. [認証] タブで、[トランスポート層セキュリティ (TLS)] と [ドメイン セキュリティを有効にする (相互認証 TLS)] を選択し、[OK] をクリックします。

認証機構に TLS を指定しても、TLS は必ずしもすべての受信接続に適用されるわけではないことに注意してください。

TLS は、次の理由から、Woodgrove 銀行からの接続に適用されます。

  • Woodgrove 銀行は、Set-TransportConfig コマンドレットの TLSReceiveDomainSecureList パラメータで指定されている。
  • DomainSecureEnabled パラメータが受信コネクタで $True に設定されている。

Set-TransportConfig コマンドレットの TLSReceiveDomainSecureList パラメータに指定されていないその他の送信者は、送信側システムが TLS をサポートしている場合は、TLS のみを使用することになります。

note注 :
受信コネクタのドメイン セキュリティを有効にした場合の副作用として、TLS ネゴシエーション中にクライアント証明書が要求されます。クライアントの送信元ドメインがセキュリティで保護されたドメイン一覧にない場合、クライアントは証明書を送信する必要はありません。

ドメインのセキュリティで保護されたメール フローのテスト

ドメインのセキュリティで保護された電子メールを構成した後は、パフォーマンス ログとプロトコル ログを確認して、接続をテストすることができます。メッセージが、ドメインのセキュリティで保護されたメール フロー パス経由で正常に認証されると、Outlook 2007 に "ドメインのセキュリティで保護されている" メッセージとして表示されます。

パフォーマンス カウンタ

ドメイン セキュリティ機能としては、[MSExchange セキュリティで保護されたメール トランスポート] にある、次の一連のパフォーマンス カウンタが挙げられます。

  • ドメインのセキュリティで保護された受信メッセージ数
  • ドメインのセキュリティで保護された送信メッセージ数
  • ドメインのセキュリティで保護された送信セッションのエラー数

これらのパフォーマンス カウンタを使用して、ドメインのセキュリティで保護されたメール フロー用の新しいカウンタ ログ ファイルを作成し、送受信したメッセージ数を監視したり、失敗した相互 TLS セッションを監視したりすることもできます。カウンタ ログを作成して構成する方法の詳細については、[パフォーマンス ログと警告] MMC スナップインに含まれているヘルプ ファイルを参照してください。

プロトコル ログ

送信と受信のプロトコル ログを確認して、TLS ネゴシエーションが正常に実行されたかどうかを判断することができます。TLS ネゴシエーションが正常に実行されると、次の例のようなログが生成されます。

詳細なプロトコル ログを表示するには、組織がドメインのセキュリティで保護された電子メールの送受信に使用するコネクタの、プロトコルのログ出力レベルを Verbose に設定する必要があります。

Exchange 管理シェルを使用して、詳細なプロトコル ログ出力を行うように受信コネクタを構成するには、次の操作を行います。

  • エッジ トランスポート サーバーで、次のコマンドを実行します。

    Set-ReceiveConnector Inet -ProtocolLoggingLevel Verbose

    Inet は、ドメインのセキュリティで保護された電子メールが有効な受信コネクタの名前です。

Exchange 管理シェルを使用して、詳細なプロトコル ログ出力を行うように送信コネクタを構成するには、次の操作を行います。

  • エッジ トランスポート サーバーで、次のコマンドを実行します。

    Set-SendConnector Internet -ProtocolLoggingLevel Verbose

    Internet は、ドメインのセキュリティで保護された電子メールが有効な送信コネクタの名前です。

送信ログの例

<220 edgedns3 ESMTP Microsoft ESMTP MAIL Service, Version: 8.0.647.0; Tue, 29 Aug 2006 04:22:00 -0700 (PDT)
>EHLO edgea36.dns.contoso.com
<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you
<250-ENHANCEDSTATUSCODES
<250-PIPELINING
<250-EXPN
<250-VERB
<250-8BITMIME
<250-SIZE
<250-DSN
<250-ETRN
<250-STARTTLS
<250-DELIVERBY
<250 HELP
>STARTTLS
<220 2.0.0 Ready to start TLS
*Sending certificate
*CN=edgea36, Certificate subject
*CN=edgea36, Certificate issuer name
*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
*edgea36;edgea36.dns.contoso.com, Certificate alternate names
*Received certificate
*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
*446DD186000A00002819, Certificate serial number
*DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
*smi.extest.contoso.com, Certificate alternate names
>EHLO edgea36.dns.contoso.com
<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you
<250-ENHANCEDSTATUSCODES
<250-PIPELINING
<250-EXPN
<250-VERB
<250-8BITMIME
<250-SIZE
<250-DSN
<250-ETRN
<250-DELIVERBY
<250 HELP
*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, sending message
>MAIL FROM:<user@example.com> SIZE=614
>RCPT TO:<root@smi.extest.contoso.com>
<250 2.1.0 <user@example.com>... Sender ok
<250 2.1.5 <root@smi.extest.contoso.com>... Recipient ok
>DATA
<354 Enter mail, end with "." on a line by itself
<250 2.0.0 k7TBM0BZ000043 Message accepted for delivery
>QUIT
<221 2.0.0 edgedns3 closing connection

受信ログの例

>220 edgea36 Microsoft ESMTP MAIL Service, Version: 8.0.647.0 ready at Mon, 28 Aug 2006 15:37:53 -0700
<EHLO edgedns3
>250-edgea36.dns.contoso.com Hello [192.168.0.1]
>250-SIZE 15728640
>250-PIPELINING
>250-DSN
>250-ENHANCEDSTATUSCODES
>250-STARTTLS
>250-AUTH
>250-8BITMIME
>250-BINARYMIME
>250 CHUNKING
<STARTTLS
>220 2.0.0 SMTP server ready
*Sending certificate
*CN=edgea36, Certificate subject
*CN=edgea36, Certificate issuer name
*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
*edgea36;edgea36.dns.contoso.com, Certificate alternate names
*Received certificate
*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
*446DD186000A00002819, Certificate serial number
*DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
*smi.extest.contoso.com, Certificate alternate names
<EHLO edgedns3
>250-edgea36.dns.contoso.com Hello [192.168.0.1]
>250-SIZE 15728640
>250-PIPELINING
>250-DSN
>250-ENHANCEDSTATUSCODES
>250-AUTH
>250-8BITMIME
>250-BINARYMIME
>250 CHUNKING
<MAIL From:<user@smi.extest.contoso.com> SIZE=16
*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, receiving message
>250 2.1.0 user@smi.extest.contoso.com Sender OK
<RCPT To:<user@woodgrove.com>
>250 2.1.5 user@woodgrove.com Recipient OK
<DATA
>354 Start mail input; end with <CRLF>.<CRLF>
>250 2.6.0 <200608281121.k7SBHYi0004586@edgedns3> Queued mail for delivery
<QUIT
>221 2.0.0 Service closing transmission channel

プロトコル ログを参照する方法の詳細については、「プロトコルのログ出力を構成する方法」を参照してください。

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

公開キー基盤の構成方法の詳細については、「Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure」 (このサイトは英語の場合があります) を参照してください。

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