Outlook Anywhere についての推奨事項

  • [アーティクル]

 

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

トピックの最終更新日: 2007-10-24

ここでは、Exchange インフラストラクチャ上で Outlook Anywhere を使用する場合の推奨事項を示します。

Microsoft Exchange と Outlook Anywhere を使用する場合は、以下の構成を使用することをお勧めします。

  • SSL (Secure Sockets Layer) 経由の NTLM 認証   クライアント アクセス サーバーの役割がインストールされた Microsoft Exchange Server 2007 コンピュータで、クライアントからサーバーへのすべての通信について SSL を有効にし、SSL を要求することをお勧めします。また、NTLM 認証を使用することもお勧めします。HTTP セッションは常に SSL (ポート 443) 経由で確立する必要があります。SSL を使用する Outlook Anywhere 認証の構成方法については、「Outlook Anywhere のセキュリティの管理」を参照してください。

    important重要 :
       NTLM に対応しないファイアウォールを使用している場合は、SSL 経由の基本認証を使用する必要があります。

  • 境界ネットワークでの拡張ファイアウォール サーバーの使用   専用のファイアウォール サーバーを使用して、Exchange コンピュータのセキュリティを強化することをお勧めします。専用ファイアウォール サーバー製品の一例としては、Microsoft Internet Security and Acceleration (ISA) Server 2006 があります。また、ISA Server 2006 は NTLM 認証情報を理解しているので、ISA Server 2006 でも基本認証の代わりに NTLM 認証を使用することができます。その他のファイアウォール サーバーも、NTLM 認証の使用方法を理解している場合があります。ファイアウォール サーバーで NTLM 認証を使用できるかどうかについては、そのファイアウォール製品の製品ドキュメントを参照してください。

  • サード パーティの証明機関 (CA) からの証明書の取得   クライアント アクセス サーバーと Outlook クライアントとのすべての通信について SSL を有効にし、要求するには、既定の Web サイト レベルで証明書を取得し、発行する必要があります。証明書は、幅広い Web ブラウザから証明書を信頼されているサード パーティの証明機関から購入することをお勧めします。

Exchange 2007 Service Pack 1 (SP1) での Outlook Anywhere の認証オプション

Exchange 2007 の元のリリース (RTM) バージョンでは、既定では /rpc 仮想ディレクトリが基本認証と統合 Windows 認証の両方に対して有効になっており、変更できません。1 つの認証方法のみを使用している場合でも、/rpc 仮想ディレクトリでは常に両方の認証方法が有効になっています。この動作はセキュリティの脆弱性であると判断されたため、Exchange 2007 SP1 では /rpc 仮想ディレクトリで 1 つの認証方法のみを選択できるようになりました。基本認証と統合 Windows 認証の両方を許可することもできますが、この設定はお勧めしません。

Exchange 2007 SP1 の新しいインストールでは、/rpc 仮想ディレクトリの認証方法は既定で、Outlook Anywhere を有効にするウィザードを使用して Outlook Anywhere を有効にしたときに選択した認証方法と同じになります。インターネット インフォメーション サービス (IIS) の既定の認証方法は、Set-OutlookAnywhere コマンドレットを使用して、統合 Windows 認証または基本認証のどちらかに変更できます。Outlook Anywhere を有効にするウィザードを使用する代わりに、Enable-OutlookAnywhere コマンドレットを使用して Outlook Anywhere を構成できます。

important重要 :
Exchange 2007 の RTM 版から Exchange 2007 SP1 にアップグレードした後では、Set-OutlookAnywhere コマンドレットを使用して手作業で 1 つの認証方法のみを指定することをお勧めします。

Outlook Anywhere で複数の認証方法を使用する場合

認証の委任を実行するファイアウォール サーバーを展開する場合、/rpc 仮想ディレクトリの認証方法を、クライアントによって使用される認証方法とは別のものに変更する必要があります。たとえば、認証の委任を実行するファイアウォール サーバーを展開する場合、ファイアウォール サーバーは NTLM 認証を使用してクライアント アクセス サーバーに対して認証を行います。これに対して、クライアントは基本認証を使用します。この例では、ユーザーの認証の委任はファイアウォール サーバーが行います。この理由から、IIS の /rpc 仮想ディレクトリは NTLM 認証を使用するように構成する必要があります。

Exchange 2007 SP1 では IIS の /rpc 仮想ディレクトリが NTLM 認証と基本認証の両方を使用するように構成できますが、この設定はお勧めしません。両方の認証方法を使用できる一般的な状況として、RPC over HTTP の追加サービスが、Outlook Anywhere アクセスを提供する同じクライアント アクセス サーバーにプロキシされる場合があります。この例では、各サービスに両方の認証方法が必要です。IIS の /rpc 仮想ディレクトリで NTLM 認証と基本認証の両方を使用するように構成するには、次のコマンドを実行します。

Set-OutlookAnywhere -Name Server01 -IISAuthenticationMethod Basic,NTLM

独自の証明機関の使用

Microsoft Windows で証明機関ツールを使用して、独自の証明機関をインストールすることもできます。既定では、独自の証明機関をインストールすると、アプリケーションと Web ブラウザはルート証明機関を信頼しません。ユーザーが Microsoft Office Outlook 2007 または Outlook 2003 で Outlook Anywhere を使用して接続を試みると、そのユーザーは Microsoft Exchange への接続を失います。ユーザーには通知されません。ユーザーが接続を失うのは、次の条件のいずれかが満たされる場合です。

  • クライアントが証明書を信頼していない。
  • 証明書とクライアントが接続しようとしている名前とが一致していない。
  • 証明書の日付が誤っている。

したがって、クライアント コンピュータが証明機関を信頼していることを確認する必要があります。また、独自の証明機関を使用する場合は、クライアント アクセス サーバーに証明書を発行するときに、その証明書の "共通名" フィールドまたは "発行先" フィールドの内容が、インターネット上で使用できるクライアント アクセス サーバーの URL と同じ名前であることを確認する必要があります。たとえば、"共通名" フィールドまたは "発行先" フィールドの内容は、mail.contoso.com のような名前である必要があります。これらのフィールドの内容は、コンピュータの内部の完全修飾ドメイン名であってはなりません。たとえば、mycomputer.contoso.com のような名前であってはなりません。

詳細情報

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

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