クライアント アクセス用の Exchange 2003 の構成

  • [アーティクル]

 

ここでは、クライアント アクセス用に Microsoft® Exchange Server 2003 を構成する方法について説明します。具体的には、次の内容について説明します。

  • Exchange メッセージング環境のセキュリティ保護
  • サーバー アーキテクチャの展開
  • サポートされているクライアント アクセス方法に対する Exchange サーバーの構成

クライアント アクセス用に Exchange 2003 を構成するためのアクセス許可

表 1 は、ここで説明する手順に必要なアクセス許可または役割を示しています。

表 1   ここで説明する手順および対応するアクセス許可

手順 必要なアクセス許可または役割

サーバー上での SSL (Secure Sockets Layer) のセットアップ
  • ローカル管理者

証明機関からのサーバー証明書の取得
  • ローカル管理者

Microsoft 管理コンソール (MMC) への証明書マネージャの追加
  • ローカル管理者

サーバー証明書のバックアップ
  • ローカル管理者

SSL の要求
  • ローカル管理者

フロントエンド サーバーの指定
  • ローカル管理者

RPC over HTTP (HTTP を経由したリモート プロシージャ コール) を使用するための Exchange フロントエンド サーバーの構成
  • ローカル管理者

RPC 仮想ディレクトリの構成
  • ローカル管理者
  • Domain Admins グループのメンバ

企業ネットワーク内で RPC over HTTP に対して指定された既定のポートを使用するための RPC プロキシ サーバーの構成
  • ローカル管理者
  • Domain Admins グループのメンバ

境界ネットワーク内で RPC over HTTP に対して指定された既定のポートを使用するためのグローバル カタログ サーバーの構成
  • ローカル管理者
  • Domain Admins グループのメンバ

RPC over HTTP を使用するための Microsoft Office Outlook® プロファイルの作成
  • 特定のアクセス許可は不要

Microsoft Exchange ActiveSync® を使用するための Exchange 2003 の構成
  • ローカル管理者

Exchange ActiveSync を使用するための Pocket PC Phone Edition デバイスの構成
  • 特定のアクセス許可は不要

ACE/Agent が Web サーバー全体を保護するように構成されていることの確認
  • ローカル管理者

SecurID 認証の Microsoft-Exchange-ActiveSync 仮想ディレクトリへの制限
  • ローカル管理者

デバイス用のカスタム HTTP 応答の構成
  • ローカル管理者

Microsoft Outlook Mobile Access の有効化
  • ローカル管理者

Outlook Mobile Access を使用するための Pocket PC Phone Edition デバイスの構成
  • 特定のアクセス許可は不要

フォーム ベース認証の有効化
  • ローカル管理者
  • Exchange 管理者

データ圧縮の有効化
  • ローカル管理者
  • Exchange 管理者

仮想サーバーの開始、一時停止、または停止
  • ローカル管理者
  • Exchange 管理者

Exchange メッセージング環境のセキュリティ保護

Exchange メッセージング環境のセキュリティ保護には、以下の展開手順が必要となります。

  1. サーバー ソフトウェアの更新
  2. メッセージング環境のセキュリティ保護
  3. 通信のセキュリティ保護

メッセージング システムをセキュリティで保護するには、これらの手順を記載された順序で完了します。

サーバー ソフトウェアの更新

Exchange Server 2003 をインストールした後、Exchange サーバー、およびグローバル カタログ サーバーやドメイン コントローラなどの Exchange が通信するサーバー上のサーバー ソフトウェアを更新する必要があります。最新のセキュリティ修正プログラムでソフトウェアを更新する方法の詳細については、Exchange Server セキュリティ センターの Web サイト (英語ページの可能性があります) (https://go.microsoft.com/fwlink/?LinkId=18412) を参照してください。

Microsoft セキュリティの詳細については、Microsoft セキュリティの Web サイト (http://go.microsoft/com/fwlink/?linkid=21633) を参照してください。

Exchange メッセージング環境のセキュリティ保護

フロントエンドの Exchange 2003 サーバーを境界ネットワークに配置する代わりとなるベスト プラクティスは、Microsoft Internet Security and Acceleration (ISA) Server 2000 の展開です。ISA Server は、ネットワークに入ってくるインターネット トラフィックを制御する拡張ファイアウォールとして機能します。この構成を使用する場合、すべての Exchange 2003 サーバーを企業ネットワーク内に配置し、ISA Server を境界ネットワーク内でインターネット トラフィックに公開される拡張ファイアウォール サーバーとして使用します。

Exchange サーバー宛てのすべての受信インターネット トラフィック (Microsoft Office Outlook Web Access、Outlook 2003 クライアントからの RPC over HTTP 通信、Outlook Mobile Access、POP3 (Post Office Protocol Version 3)、IMAP4 (Internet Message Access Protocol Version 4rev1) など) は ISA Server によって処理されます。ISA Server が Exchange サーバーへの要求を受信すると、ISA Server はその要求を、内部ネットワーク上の適切な Exchange サーバーにプロキシします。内部 Exchange サーバーは要求されたデータを ISA Server に返し、次に ISA Server がインターネット経由で情報をクライアントに送信します。図 1 は、推奨される ISA Server 展開の例を示しています。

境界ネットワーク上の ISA Server

通信のセキュリティ保護

Exchange メッセージング環境に対する通信をセキュリティで保護するには、以下の作業を実行する必要があります。

  • クライアント メッセージング アプリケーションと Exchange フロントエンド サーバー間の通信のセキュリティ保護
  • Exchange フロントエンド サーバーと内部ネットワークの間の通信のセキュリティ保護

以下では、これらの 2 つの状況での通信のセキュリティ保護について説明します。

クライアントと Exchange フロントエンド サーバーの間の通信のセキュリティ保護

クライアントとフロントエンド サーバーとの間で送信されるデータをセキュリティで保護するには、フロントエンド サーバーが SSL (Secure Sockets Layer) を使用できるようにすることを強くお勧めします。さらに、ユーザー データが常に安全であることを保証するには、SSL なしでのフロントエンド サーバーへのアクセスを無効にする必要があります (このオプションは SSL 構成で設定できます)。基本認証を使用する場合は、SSL を使用してユーザー パスワードをネットワーク パケットの傍受から守ることによって、ネットワーク トラフィックを保護することが重要です。

note注 :
クライアントとフロントエンド サーバーとの間で SSL を使用しない場合、フロントエンド サーバーへの HTTP データ送信はセキュリティで保護されません。SSL を要求するようにフロントエンド サーバーを構成することを強くお勧めします。

サード パーティの証明機関 (CA) から証明書を購入して SSL 証明書を取得することをお勧めします。証明機関から証明書を購入する方法がよく使用されるのは、ほとんどのブラウザがこれらの証明機関の多くを信頼するからです。

または、証明書サービスを使用して、独自の証明機関をインストールすることができます。独自の証明機関をインストールする方が安価な場合がありますが、独自の証明書はブラウザによって信頼されず、ユーザーには証明書が信頼されていないことを示す警告メッセージが表示されます。SSL の詳細については、マイクロソフト サポート技術情報の文書番号 320291「[XCCC] Exchange 2000 Server Outlook Web Access の SSL をオンにする」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=320291) を参照してください。

Secure Sockets Layer の使用

送信および受信メールを保護するには、SSL を展開してメッセージング トラフィックを暗号化します。内容の整合性を確認し、ユーザーの ID を確認し、ネットワーク送信を暗号化するように、Exchange サーバー上で SSL セキュリティ機能を構成できます。他の Web サーバーと同様、Exchange は、SSL 通信を確立するために有効なサーバー証明書を必要とします。Web サーバー証明書ウィザードを使用して、証明機関に送信できる証明書要求ファイル (既定では NewKeyRq.txt) を生成したり、証明書サービスなどのオンライン証明機関に対する要求を生成することができます。

証明書サービスを使用して独自のサーバー証明書を発行しない場合は、サード パーティの証明機関によって要求が承認され、サーバー証明書が発行される必要があります。サーバー証明書の詳細については、このトピックの「サーバー証明書の取得とインストール」を参照してください。サーバー証明書によって提供される ID 保証のレベルによっては、証明機関が要求を承認し、証明書ファイルを送信するまで数日から数か月待つことになる場合があります。サーバー証明書は Web サイトごとに 1 つだけ持つことができます。

受信したサーバー証明書ファイルは、Web サーバー証明書ウィザードを使用してインストールします。インストール プロセスにより、証明書が Web サイトにアタッチ (またはバインド) されます。

詳細な手順については、「サーバー上で SSL をセットアップする方法」を参照してください。

important重要 :
前の手順を実行するには、ローカル コンピュータ上の Administrators グループのメンバであるか、または適切な権限を委任されている必要があります。セキュリティに関するベスト プラクティスとしては、Administrators グループに含まれていないアカウントを使用してコンピュータにログオンし、runas コマンドを使用して管理者として IIS マネージャを実行します。コマンド プロンプトで、次のコマンドを入力します。runas /user:administrative_accountname "mmc%systemroot%\system32\inetsrv\iis.msc"

128 ビット キー暗号化を要求する場合、ユーザーは 128 ビット暗号化をサポートする Web ブラウザを使用する必要があります。128 ビット暗号化機能へのアップグレードについては、マイクロソフト製品サポート サービスの Web サイト (https://go.microsoft.com/fwlink/?linkid=14898) を参照してください。

サーバー証明書の取得とインストール

外部の証明機関 (CA) からサーバー証明書を取得したり、証明書サービスを使用して独自のサーバー証明書を発行することができます。取得したサーバー証明書は、インストールが可能です。Web サーバー証明書ウィザードを使用してサーバー証明書を取得およびインストールする場合、そのプロセスは、サーバー証明書の作成と割り当てと呼ばれます。

詳細な手順については、「証明機関からサーバー証明書を取得する方法」を参照してください。

ここでは、外部 CA からサーバー証明書を取得するか、または独自のサーバー証明書を発行するかを決定する際の考慮事項について説明します。以下の情報について説明します。

  • 証明機関からのサーバー証明書の取得
  • 独自のサーバー証明書の発行
  • サーバー証明書のインストール
  • サーバー証明書のバックアップ

証明機関からのサーバー証明書の取得

現在のサーバー証明書を置き換える場合、IIS は、新しい要求が完了されるまで現在の証明書を引き続き使用します。CA を選択する際は、以下の点について考慮します。

  • その CA は、サーバーにアクセスするために使用されるすべてのブラウザと互換性を持つ証明書を発行できるかどうか。
  • その CA が、承認され、信頼された組織かどうか。
  • その CA は ID の確認をどのように提供するか。
  • その CA には、Web サーバー証明書ウィザードによって生成される要求など、オンライン証明書要求を受信するためのシステムがあるかどうか。
  • 証明書の初期コストはどの程度か、また、更新やその他のサービスにかかるコストはどの程度か。
  • その CA は、証明書を取得する側の組織または企業のビジネス利益を理解しているかどうか。
note注 :
一部の証明機関は、要求を処理したり、証明書を発行したりする前に、ID の提供を要求します。

独自のサーバー証明書の発行

独自のサーバー証明書を発行するかどうかを決定する際には、以下の点を考慮します。

  • 証明書サービスはさまざまな証明書形式に対応しており、証明書関連の処理の監査およびログ出力が用意されていることを理解する。
  • 独自の証明書を発行するコストと証明機関から証明書を購入するコストを比較する。
  • 組織が、証明書サービスについて学習し、証明書サービスを実装して既存のセキュリティ システムおよびポリシーと統合するための初期調整期間を必要とすることに注意する。
  • 接続元のクライアントが証明書の供給元として組織を積極的に信頼するかどうかを評価する。

証明書サービスを使用して、証明書の発行および管理のためのカスタマイズ可能なサービスを作成します。インターネットまたは企業イントラネット用のサーバー証明書を作成すると、証明書管理ポリシーに対する完全な制御を組織に与えることができます。詳細については、Windows Server™ 2003 ヘルプの「証明書サービス」を参照してください。

サーバー証明書に対するオンライン要求は、ローカルやリモートのエンタープライズ証明書サービス、およびリモートのスタンドアロン証明書サービスに対してのみ行うことができます。Web サーバー証明書ウィザードは、証明書を要求する際に、同じコンピュータ上にある証明書サービスのスタンドアロン インストールを認識しません。同じコンピュータ上の Web サーバー証明書ウィザードをスタンドアロンの証明書サービス インストールとして使用する必要がある場合は、オフライン証明書要求を使用して要求をファイルに保存してから、オフライン要求として処理します。詳細については、Windows Server 2003 ヘルプの「証明書サービス」を参照してください。

note注 :
SGC (Server Gated Cryptography) 証明書を開いた場合、[全般] タブに次の注意事項が表示されることがあります。"情報不足のため、この証明書を検証できません。"この注意事項は、SGC 証明書が Microsoft Windows® と対話する方法が原因で発行されるもので、必ずしも証明書が正しく動作していないことを示すわけではありません。

サーバー証明書のインストール

CA からサーバー証明書を取得するか、または証明書サービスを使用して独自のサーバー証明書を発行した後、Web サーバー証明書ウィザードを使用してインストールします。

サーバー証明書のバックアップ

Web サーバー証明書ウィザードを使用して、サーバー証明書をバックアップできます。IIS は Windows と緊密に動作するため、Microsoft 管理コンソール (MMC) では [証明書] と表示されている証明書マネージャを使用して、サーバー証明書のエクスポートとバックアップを行うことができます。

空の MMC に証明書マネージャを追加する詳細な手順については、「Microsoft 管理コンソールに証明書マネージャを追加する方法」を参照してください。

証明書マネージャをインストールした後、証明書をバックアップできます。詳細な手順については、「サーバー証明書をバックアップする方法」を参照してください。

サーバー証明書を発行するようにネットワークを構成した後、Exchange フロントエンド サーバーへの SSL 通信を要求することによって、Exchange フロントエンド サーバーおよび Exchange サーバー用のサービスをセキュリティで保護する必要があります。次のセクションでは、既定の Web サイトに対して SSL を有効にする方法について説明します。

既定の Web サイトに対する SSL の有効化

既定の Web サイト、または \RPC、\OWA、\Microsoft-Server-ActiveSync、\Exchange、\Exchweb、および \Public 仮想ディレクトリをホストするサイト上の Exchange フロントエンド サーバーで使用するための SSL 証明書を取得した後、既定の Web サイトに対して SSL の要求を有効にすることができます。

詳細な手順については、「SSL を使用するように仮想ディレクトリを構成する方法」を参照してください。

note注 :
\Exchange、\Exchweb、\Public、\OMA、および \Microsoft-Server-ActiveSync 仮想ディレクトリは、すべての Exchange 2003 インストール環境に既定でインストールされます。RPC over HTTP 通信用の \RPC 仮想ディレクトリは、RPC over HTTP をサポートするために、Exchange を構成するときに手動でインストールされます。RPC over HTTP を使用するように Exchange をセットアップする方法の詳細については、Exchange Server 2003 での RPC over HTTP の展開シナリオについてのドキュメント (英語ページの可能性があります) (https://go.microsoft.com/fwlink/?LinkId=47577) を参照してください。

この手順を完了した後、既定の Web サイトにある Exchange フロントエンド サーバー上のすべての仮想ディレクトリは、SSL を使用するように構成されます。

Exchange フロントエンド サーバーと他のサーバーの間の通信のセキュリティ保護

クライアント コンピュータと Exchange フロントエンド サーバーの間の通信をセキュリティで保護した後、Exchange フロントエンド サーバーと組織内のバックエンド サーバーの間の通信をセキュリティで保護する必要があります。フロントエンド サーバーとフロントエンド サーバーが通信するすべてのサーバー (バックエンド サーバー、ドメイン コントローラ、グローバル カタログ サーバーなど) の間の HTTP、POP、および IMAP 通信は暗号化されません。フロントエンド サーバーおよびバックエンド サーバーが信頼された物理ネットワークまたは交換網にある場合は、暗号化されなくても問題にはなりません。ただし、フロントエンド サーバーとバックエンド サーバーが個別のサブネットに配置される場合は、ネットワーク トラフィックがネットワークのセキュリティで保護されていない領域を通過する可能性があります。このセキュリティ上のリスクは、フロントエンド サーバーとバックエンド サーバーの間の物理的な距離が大きくなるほど増大します。この場合、このトラフィックを暗号化してパスワードとデータを保護することをお勧めします。

IPSec を使用した IP トラフィックの暗号化

Windows 2000 はインターネット プロトコル セキュリティ (IPSec) をサポートします。IPSec は、サーバーがブロードキャストまたはマルチキャスト IP アドレスを使用するトラフィックを除く、すべての IP トラフィックを暗号化できるようにするインターネット標準です。通常は、IPSec を使用して HTTP トラフィックを暗号化します。ただし、IPSec を使用して LDAP (Lightweight Directory Access Protocol)、RPC、POP、および IMAP トラフィックを暗号化することもできます。IPSec を使用すると、次のことを行うことができます。

  • Windows 2000 を実行している 2 つのサーバーを、信頼されたネットワーク アクセスを要求するように構成する。
  • すべてのパケットに対する暗号チェックサムを使用して、変更から保護されるデータを転送する。
  • 2 つのサーバー間のすべてのトラフィックを IP 層で暗号化する。

フロントエンドおよびバックエンド トポロジでは、IPSec を使用して、通常は暗号化されないフロントエンド サーバーとバックエンド サーバーの間のトラフィックを暗号化できます。ファイアウォールで IPSec を構成する方法の詳細については、マイクロソフト サポート技術情報の文書番号 233256「ファイアウォール経由での IPSec トラフィックを有効にする方法」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=233256) を参照してください。

Exchange サーバー アーキテクチャの展開

Exchange メッセージング環境をセキュリティで保護した後、Exchange フロントエンド/バックエンド サーバー アーキテクチャを展開できます。Exchange フロントエンドおよびバックエンドのサーバー アーキテクチャの詳細については、Microsoft Exchange Server 2003 メッセージング システムの計画に関するガイド (英語ページの可能性があります) (https://go.microsoft.com/fwlink/?linkid=47584) のプロトコルについてのトピックを参照してください。

Exchange フロントエンドおよびバックエンドのサーバー アーキテクチャを構成するには、1 つの Exchange サーバーをフロントエンド サーバーとして構成する必要があります。インストール プロセスを続行する前に、展開オプションを再確認することが重要です。次のセクションは、Exchange 2003 をフロントエンドおよびバックエンドのサーバー構成で展開するかどうかを決定するのに役立ちます。

フロントエンドおよびバックエンド構成は、Outlook Web Access、POP、または IMAP を使用する複数のサーバーを備えた組織、または社員に HTTP、POP、または IMAP アクセスを提供する組織に対して推奨されます。

フロントエンド サーバーの構成

フロントエンド サーバーは、フロントエンド サーバーとして構成されるまでは普通の Exchange サーバーです。フロントエンド サーバーにはユーザーまたはパブリック フォルダを配置しないようにする必要があります。また、バックエンド サーバーと同じ Exchange 2003 組織のメンバ (したがって、同じ Windows 2000 Server または Windows Server 2003 フォレストのメンバ) である必要があります。Exchange Server 2003 Enterprise Edition または Exchange Server 2003 Standard Edition を実行しているサーバーを、フロントエンド サーバーとして構成できます。

詳細な手順については、Exchange Server 2003 および Exchange 2000 Server のフロントエンドおよびバックエンド サーバー トポロジに関するガイド (英語ページの可能性があります) (https://go.microsoft.com/fwlink/?LinkId=47567) のフロントエンド サーバーを指定する方法についてのトピックを参照してください。

サーバーをフロントエンド サーバーとして使用し始めるには、サーバーを再起動します。フロントエンドおよびバックエンド シナリオ、構成、およびインストールの詳細については、以下のリソースを参照してください。

クライアント アクセス用の Exchange の構成

クライアント アクセス用の Exchange の構成では、サポートする必要があるプロトコルおよびクライアントを処理するように Exchange を構成します。以下では、Exchange によってサポートされるクライアント プロトコルを Exchange サーバー上で有効にする方法について説明します。以下の情報について説明します。

  • モバイル デバイス サポートの構成
  • Outlook Web Access の構成
  • POP3 および IMAP4 仮想サーバーの有効化

Outlook 2003 に対して RPC over HTTP を構成する方法については、Exchange Server 2003 RPC over HTTP 展開シナリオについてのページ (https://go.microsoft.com/fwlink/?LinkId=47577) を参照してください (このサイトは英語の場合があります)。

モバイル デバイス サポートの構成

Exchange 2003 のモバイル デバイス サポートの構成では、以下の作業を行います。

  • 同期の構成
  • RSA SecurID を使用するための Exchange ActiveSync の構成
  • Outlook Mobile Access の有効化

同期の構成

Exchange をインストールすると、Exchange への同期アクセスは、組織内のすべてのユーザーに対して既定で有効になります。また、[Active Directory ユーザーとコンピュータ] スナップインを使用して、ユーザーごとに同期アクセスを有効にすることもできます。

Exchange ActiveSync の構成

Exchange ActiveSync は、Exchange の組織レベルとユーザー レベルで有効および無効にできます。

Exchange ActivceSync を組織レベルで有効および無効にする方法の詳細については、「組織レベルで Exchange ActiveSync の機能を有効または無効にする方法」を参照してください。

Exchange ActivceSync を個別のユーザーについて有効および無効にする方法の詳細については、「ユーザー レベルで Exchange ActiveSync の機能を有効または無効にする方法」を参照してください。

Exchange ActiveSync を有効にした後で、Pocket PC Phone Edition デバイスなどのモバイル デバイスが Exchange ActiveSync を使用するように構成できます。この手順は、組織内の各モバイル デバイスに対して実行します。または、自分のデバイスを構成する方法をユーザーに説明できます。

詳細な手順については、「モバイル デバイスを Exchange ActiveSync を使用するように構成する方法」を参照してください。

Up-to-date の通知

Microsoft Windows Mobile™ 2003 デバイスは、Exchange 2003 によって生成される、ユーザーのデバイスとそのユーザーの Exchange メールボックスとの間の Exchange ActiveSync 同期を開始する通知を受信することができます。この同期により、ユーザーはモバイル デバイスを最新の Exchange 情報で最新状態にすることができます。詳細な手順については、「デバイスで Up-to-date の通知用のモバイル オペレータを指定する方法」を参照してください。

RSA SecurID を使用するための Exchange ActiveSync の構成

セキュリティのレベルをさらに高める方法として、Microsoft Windows Mobile デバイスと Exchange ActiveSync を、RSA SecurID の 2 要素による認証と組み合わせて使用することができます。

note注 :
RSA SecurID をサポートするための追加のデバイス構成は必要ありません。デバイスは、RSA SecurID によって保護されている Exchange ActiveSync サーバーとの同期を行う際に、自動的に適切な認証を提示します。

RSA SecurID を Exchange ActiveSync と共に使用するには、以下の手順を実行します。

  1. RSA SecurID サーバー コンポーネントのセットアップ
  2. RSA SecurID を使用するためのインターネット インフォメーション サーバー (IIS) の構成
  3. ユーザー アカウントのセットアップ
  4. ISA Server 2000 の構成

RSA SecurID サーバー コンポーネントのセットアップ

RSA SecurID サーバー コンポーネントを構成するには、以下のことを行う必要があります。

  • RSA ACE/Server のセットアップ   RSA ACE/Server は、ユーザー用の認証チケットと資格情報を格納および管理する RSA サーバーです。RSA ACE/Server をセットアップするには、RSA Security Inc. が提供する RSA SecurID のドキュメントに記載されている手順を実行します。
  • フロントエンド サーバーでの RSA ACE/Agent のセットアップ   RSA ACE/Agent は、認証を実行し、ACE/Server と通信して SecurID 資格情報を取得する ISAPI (Internet Server Application Programming Interface) フィルタです。RSA ACE/Agent をセットアップするには、RSA のドキュメントに記載されている手順を実行します。

RSA SecurID を使用するための IIS の構成

RSA および Exchange ActiveSync に対する IIS の構成では、以下の手順を実行します。

  1. Exchange ActiveSync 仮想ディレクトリを保護する。
  2. カスタム HTTP 応答ヘッダーをカスタマイズする。
  3. SecurID 画面をインストールする (オプション)。これらの画面のインストールについては、RSA SecurID のドキュメントを参照してください。

これらの手順を完了して、SecurID および Exchange ActiveSync 処理に対して IIS を正しく構成します。

Exchange ActiveSync 仮想ディレクトリの保護

IIS を構成するための最初の手順は、ユーザーが Exchange ActiveSync を使用する際にアクセスする仮想ディレクトリの保護です。Exchange Server 2003 では \Microsoft-Server-ActiveSync 仮想ディレクトリを使用します。

この仮想ディレクトリは、以下のいずれかの方法で保護できます。

  • サーバー全体を保護する (推奨)   フロントエンド サーバーによって実装されるその他すべてのサービスを含め、RSA ACE/Agent が構成された IIS サーバー上のすべての仮想ルートが保護されます。たとえば、Outlook Mobile Access または Outlook Web Access 用のアクセス ポイントとしてフロントエンド Exchange サーバーを構成した可能性があります。既定では、ACE/Agent は Web サーバー全体を保護するように構成されます。この構成を確認する詳細な手順については、「ACE/Agent が Web サーバー全体を保護するように構成されていることを確認する方法」を参照してください。
  • Exchange ActiveSync 仮想ディレクトリのみを保護する   Exchange ActiveSync のみが SecurID によって保護されるように、RSA ACE/Agent が構成されます。Outlook Web Access や Outlook Mobile Access などの追加のサービスを、SecurID でこれらのサービスを保護せずに同じサーバー上で有効にする予定がある場合は、このオプションを使用します。詳細な手順については、「SecurID 認証を Microsoft-Exchange-ActiveSync 仮想ディレクトリに制限する方法」を参照してください。

デバイス用の HTTP 応答ヘッダーのカスタマイズ

Microsoft Windows Mobile デバイス上の ActiveSync クライアントは、RSA SecurID 認証と Exchange ActiveSync の応答の違いを区別できる必要があります。この機能を有効にするには、RSA ACE/Agent によって構成される HTML フォームを含む WebID 仮想ディレクトリ上で、カスタム HTTP 応答ヘッダーを構成する必要があります。

詳細な手順については、「デバイス用にカスタム HTTP 応答を構成する方法」を参照してください。

ユーザー アカウントのセットアップ

SecurID のユーザー アカウントは、RSA SecurID の製品ドキュメントで推奨されているように、管理者によって以下の制限を課してセットアップされる必要があります。

  • すべてのユーザーに対し、SecurID のユーザー ID は、Windows アカウント名と一致するものを選択する必要があります。Exchange ActiveSync と SecurID は、Windows アカウント名に一致しない別個の RSA ユーザー ID を持つユーザーに対しては機能しません。

ISA Server 2000 の構成

ISA Server 2000 Feature Pack 1 と RSA SecurID テクノロジは、ISA Server 上に統合されています。現在、RSA SecurID と ISA Server 2000 Feature Pack 1 の同時使用はサポートされていません。RSA SecurID を ISA Server 2000 Feature Pack 1 と共に展開することはできますが、パススルー認証を有効にするように ISA Server を構成する必要があります。このシナリオでも、RSA 認証は、ISA Server ではなく、フロントエンド サーバーで発生します。パススルー認証を有効にする方法については、ISA Server 2000 のドキュメントを参照してください。

Outlook Mobile Access の有効化

既定では、すべてのユーザーが Exchange ActiveSync および Outlook Mobile Access に対して有効になっています。ただし、Exchange サーバー上では Exchange ActiveSync のみが有効になっています。既定では、Outlook Mobile Access は無効になっています。ここでは、Exchange サーバー上で Outlook Mobile Access を有効にする方法について説明します。

Exchange 2003 ユーザーが Outlook Mobile Access を使用できるようにするには、次の手順を実行します。

  1. Exchange 2003 フロントエンド サーバーを Outlook Mobile Access 用に構成します。
  2. Exchange サーバー上で Outlook Mobile Access を有効にします。
  3. ユーザーのデバイスを、モバイル接続を使用するように構成します。
  4. ユーザーに対して Outlook Mobile Access の使用方法を説明します。

手順 1: Exchange 2003 フロントエンド サーバーを Outlook Mobile Access 用に構成する

既定では、Outlook Mobile Access 仮想ディレクトリ (ユーザーがモバイル デバイスから Exchange にアクセスできるようにするためのもの) は Exchange 2003 と共にインストールされます。この仮想ディレクトリは、Outlook Web Access 仮想ディレクトリと同じ機能と構成設定を持っています。Outlook Mobile Access を使用するようにサーバーを構成するときは、そのサーバーを、Outlook Web Access 用に構成するときと同様に構成する必要があります。Outlook Web Access を使用するために Exchange 2003 サーバーを構成する方法の詳細については、Microsoft Exchange 2000 フロントエンド サーバーの使用に関するドキュメント (英語ページの可能性があります) (https://go.microsoft.com/fwlink/?linkid=14575) を参照してください。

手順 2: Exchange サーバー上で Outlook Mobile Access を有効にする

Outlook Mobile Access を使用するようにフロントエンド サーバーを構成した後、Exchange サーバーで Outlook Mobile Access を有効にする必要があります。Outlook Mobile Access は、組織レベルと個別のユーザー レベルで有効にできます。

組織レベルで Outlook Mobile Access を有効にする詳細な手順については、「組織レベルで Outlook Mobile Access を有効または無効にする方法」を参照してください。

Outlook Mobile Access を有効にした後、Active Directory ユーザーとコンピュータ スナップインを使用して、ユーザーまたはユーザーのグループの Outlook Mobile Access 設定を変更できます。ユーザー レベルで Outlook Mobile Access を有効にする詳細な手順については、「ユーザー レベルで Outlook Mobile Access を有効または無効にする方法」を参照してください。

手順 3: モバイル接続を使用するためのユーザーのデバイスの構成

ユーザーが Outlook Mobile Access を使用して Exchange 2003 にアクセスするには、モバイル データ用の確立されたデータ ネットワークを持つモバイル オペレータによるモバイル デバイスが必要です。ユーザーが Exchange 2003 に接続してモバイル接続経由で Outlook Mobile Access または Exchange ActiveSync を使用する前に、モバイル ネットワークを使用するようにデバイスを構成する方法についてユーザーに説明するか、またはその方法について説明したリソースを提供します。モバイル デバイスと Exchange ActiveSync を構成する方法の詳細については、「モバイル デバイスを Exchange ActiveSync を使用するように構成する方法」を参照してください。

手順 4: ユーザーに対して Outlook Mobile Access の使用方法を説明する

Outlook Mobile Access 用に Exchange 2003 を構成しました。また、ユーザーはモバイル ネットワークを使用して Exchange 2003 サーバーにアクセスできるモバイル デバイスを持っています。次の段階として、ユーザーは Exchange サーバーにアクセスして Outlook Mobile Access を使用する方法を知る必要があります。Pocket PC ベースのモバイル デバイスが Outlook Mobile Access を使用するように構成する詳細な手順については、「Outlook Mobile Access を使用して Exchange データにアクセスする方法」を参照してください。

Outlook Web Access の構成

既定では、Exchange 2003 をインストールした後、Outlook Web Access はすべてのユーザーに対して有効になります。ただし、Outlook Web Access に対して以下の機能を有効にすることができます。

  • フォーム ベース認証
  • Outlook Web Access の圧縮

フォーム ベース認証

Outlook Web Access の新しいログオン ページを有効にして、ユーザーの名前とパスワードをブラウザではなく Cookie に格納することができます。ユーザーがブラウザを閉じると、Cookie は消去されます。また、非アクティブな状態が一定期間続くと、Cookie は自動的に消去されます。新しいログオン ページでは、ドメイン、ユーザー名 (<ドメイン>\<ユーザー名> の形式) とパスワード、または電子メールにアクセスするための完全なユーザー プリンシパル名 (UPN) 電子メール アドレスとパスワードのいずれかを入力する必要があります。

Outlook Web Access のログオン ページを有効にするには、サーバーでフォーム ベース認証を有効にする必要があります。詳細な手順については、「フォーム ベース認証を有効にする方法」を参照してください。

Outlook Web Access の圧縮

Outlook Web Access は、データ圧縮をサポートしており、ネットワーク接続が低速な環境に適しています。Outlook Web Access の圧縮では、圧縮設定に応じて、静的または動的、あるいはその両方の Web ページが圧縮されます。詳細な手順については、「Outlook Web Access のデータ圧縮を有効にする方法」を参照してください。

表 4 は、Exchange Server 2003 で Outlook Web Access 用に使用できる圧縮設定の一覧を示しています。

表 4   Outlook Web Access で使用できる圧縮設定

圧縮設定 説明

高

静的なページと動的なページの両方が圧縮されます。

低

静的なページのみが圧縮されます。

なし

圧縮は行われません。

データ圧縮を使用すれば、従来のダイヤルアップ アクセスなどのネットワーク接続が低速な環境でのパフォーマンスが約 50% 向上します。

Outlook Web Access での圧縮の要件

Exchange Server 2003 の Outlook Web Access でデータ圧縮を使用するには、以下の前提条件が満たされていることを確認する必要があります。

  • Outlook Web Access のユーザー認証に使用する Exchange サーバーは、Windows Server 2003 を実行している必要があります。

  • ユーザーのメールボックスは、Exchange 2003 サーバー上にある必要があります。Exchange メールボックスが混在して展開されている場合は、Exchange サーバー上に Exchange 2003 ユーザー専用の独立した仮想サーバーを作成し、その仮想サーバー上で圧縮を有効にすることができます。

  • クライアント コンピュータは、Internet Explorer Version 6 以降を実行している必要があります。また、コンピュータは、Windows XP または Windows 2000 を実行していて、マイクロソフト セキュリティ情報の Internet Explorer 用の累積的な修正プログラム (Q328970) (MS02-066) に関するページ (英語ページの可能性があります) (https://go.microsoft.com/fwlink/?LinkId=16694) に説明されているセキュリティ アップデートがインストールされている必要があります。

    note注 :
    圧縮がサポートされているブラウザがなくても、クライアントは正常に動作します。

  • 一部のダイヤルアップ接続では、プロキシ サーバー経由の HTTP 1.1 サポートを有効にすることが必要な場合があります。圧縮が正常に機能するには、HTTP 1.1 サポートが必要です。

POP3 および IMAP4 仮想サーバーの有効化

既定では、POP3 および IMAP4 仮想サーバーは、新規インストールされた Exchange Server 2003 上では無効になっています。POP3 および IMAP4 仮想サーバーを有効にするには、まず MMC への [サービス] スナップインを使用し、自動的に開始するようにサービスを設定する必要があります。自動的に開始するようにサービスを設定した後で、サービスを開始、一時停止、または停止する必要がある場合は、Exchange システム マネージャを使用します。詳細な手順については、「仮想サーバーを開始、一時停止、または停止する方法」を参照してください。

note注 :
IMAP4 と POP3 の有効化、およびこれらのリソースの Exchange クラスタへの追加については、『Exchange Server 2003 管理ガイド』(https://go.microsoft.com/fwlink/?LinkId=47617) の「Exchange クラスタの管理」を参照してください。