Communicator Web Access 仮想サーバーの作成
トピックの最終更新日: 2009-03-06
Communicator Web Access (2007 R2 リリース) をインストールしてアクティブ化したら、少なくとも 1 つの Communicator Web Access 仮想サーバーを作成する必要があります。ユーザーは、ログオンできる仮想サーバーがないと、インスタント メッセージングや電話会議などの Communicator Web Access の機能を使用できません。
.gif "Dd441275.note(ja-jp,office.13).gif") 注: |
|---|
| 仮想サーバーの大部分は Web サイトです。ユーザーが https://im.contoso.com という URL を使用して Communicator Web Access にログオンする場合、https://im.contoso.com は Web サイトであるだけでなく Communicator Web Access 仮想サーバーでもあります。仮想サーバーの価値は、単一のインターネット インフォメーション サービス (IIS) コンピュータが複数の Web サイトをホストできるようになる点です。たとえば、1 台のコンピュータに https://im.fabrikam.com と https://im.contoso.com をホストできます。 |
内部ユーザー (組織のファイアウォールの内側にいるユーザー) と外部ユーザー (組織のファイアウォールの外側にいるユーザー) の両方からの要求を処理する場合は、2 つの仮想サーバーを作成する必要があります (内部ユーザー用と外部ユーザー用)。1 つ目の仮想サーバーを展開ウィザードを使用して作成してから、2 つ目の仮想サーバーを Communicator Web Access スナップインを使用して作成できます。
| 注: |
|---|
| 外部ユーザーからの要求を処理する場合は、リバース プロキシ サーバーを使用してその仮想サーバーを Web に公開することを強くお勧めします。リバース プロキシ サーバーを使用した Communicator Web Access 仮想サーバーの公開の詳細については、「リバース プロキシの使用によるリモート ユーザー アクセスの有効化」を参照してください。また、セキュリティ上の理由から、内部ユーザー用の仮想サーバーと外部ユーザー用の仮想サーバーを別々のコンピュータでホストすることをお勧めします。 |
コンピュータに 1 つ目の仮想サーバーを作成するには、「展開ウィザードを使用した Communicator Web Access 仮想サーバーの作成」の手順「1 つ目の仮想サーバーを作成するには」を参照してください。同じコンピュータに 2 つ目の仮想サーバーを作成する場合は、Communicator Web Access スナップインを使用して作成する必要があります。コンピュータに 2 つ目の仮想サーバーを作成するには、次の操作を行います。
- Communicator Web Access スナップインを開いて、仮想サーバーを作成するサーバーの名前を右クリックし、[仮想サーバーの作成] をクリックします。
- 仮想サーバー作成ウィザードが表示されたら、コンピュータに 1 つ目の仮想サーバーを作成したときと同じ手順を実行します。
仮想サーバーを作成する前に、認証方法、接続の種類、および次ホップ サーバーを選択する必要があります。
認証方法
仮想サーバーを作成するときに、いくつかの主要プロパティの値を指定する必要があり、最初に認証メカニズムを指定します。Communicator Web Access には、さまざまな認証オプションが用意されています。
統合 (NTLM/Kerberos) パスワード認証
このオプションは最も安全性が高い認証で、必要な手間を最小限に抑えることができます。統合パスワード認証では、ユーザーはユーザー名とパスワードを入力する必要がありません。代わりに、各自のコンピュータへのログオンに使用した資格情報を使用して認証されます。
ただし、統合パスワード認証には 2 つの欠点があります。1 つ目は、この種類の認証は内部仮想サーバーでしか使用できないという点です。外部ユーザーは常に資格情報を提示する必要があります。つまり、外部ログオン要求を処理するサイトではフォーム ベース認証またはカスタム認証を使用する必要があります。
2 つ目は、統合パスワード認証を使用できるのは、Microsoft Windows を実行しているコンピュータからログオンするユーザーと NTLM 認証または Kerberos 認証をサポートしている Web ブラウザを使用しているユーザーのみであるという点です。すべてのユーザーが Internet Explorer と Microsoft Windows を実行している内部ユーザーである場合は、統合パスワード認証を唯一の認証メカニズムとして使用できます。それ以外の場合は、統合パスワード認証とフォーム ベース認証の両方を使用するか、カスタム認証方法を使用する必要があります。
| 注: |
|---|
| 統合パスワード認証とフォーム ベース認証の両方を使用する場合、Communicator Web Access はまず統合パスワード認証を使用してユーザーのログオンを試みます。その認証が失敗した場合、ユーザーはフォーム ベース認証を使用してログオンを試行できます。 |
フォーム ベース認証
フォーム ベース認証では、Communicator Web Access 仮想サーバーにアクセスしようとしているユーザーに対してログオン ダイアログ ボックスが表示されます。認証されてサイトにアクセスできるようになるには、ユーザーは自身の資格情報 (ドメイン、ユーザー名、およびパスワード) を提示する必要があります。フォーム ベース認証を使用すると、次のユーザーがサポートされます。
- Macintosh ユーザーと Linux ユーザー
- Internet Explorer を実行していないユーザー
- 外部ユーザー (組織のファイアウォールの外側からログオンするユーザー)
フォーム ベース認証の欠点は、あまり安全性の高いメカニズムではないという点です。たとえば、ユーザーの資格情報がプレーンテキスト形式でサーバーに渡されます。そのため、フォーム ベース認証を許可する仮想サーバーでは HTTPS 接続を採用することを強くお勧めします。
カスタム認証
Windows オペレーティング システムに組み込まれた認証メカニズムのほかに、Communicator Web Access では、カスタムまたはサードパーティの認証方法もサポートされています。たとえば、Communicator Web Access では、認証されるために 2 つの識別情報 (通常はスマート カードと暗証番号 (PIN)) を提示する必要がある 2 要素認証の使用がサポートされています。
また、Microsoft Internet Security and Acceleration Server (ISA) 2006 を使用している場合に限り、シングル サインオン認証もサポートされます。シングル サインオンでは、ユーザーは 1 回ログオンするだけで複数のアプリケーションにアクセス可能になります。たとえば、Microsoft Outlook Web Access にログオンしたユーザーは、Communicator Web Access にも自動的にログオンできます (逆も可能です)。
| 注: |
|---|
| シングル サインオンを使用する場合は、[サインアウト URL] オプションを指定する必要があります。この URL は、Communicator Web Access からのサインアウト後に表示されるページの URL です。このページに移動することで、ユーザーのコンピュータに保存されているすべての認証 Cookie が削除されます。詳細については、カスタム認証方法のドキュメントを参照してください。 |
接続の種類
認証メカニズムを指定した後に、接続の種類を指定する必要があります。Communicator Web Access では、2 つの異なる接続プロトコル HTTP および HTTPS がサポートされています。HTTPS プロトコルの方が安全性が高いので推奨されます。特に、HTTPS ではサーバーとブラウザ間のすべてのトラフィックが暗号化されます。HTTPS (推奨プロトコル) を使用する場合は、この接続を証明書に割り当てる必要があります。詳細については、「Communicator Web Access の証明書の準備」を参照してください。
| 注: |
|---|
| デスクトップ共有を実装する場合は、HTTPS プロトコルが必要です。HTTP プロトコルを使用する Communicator Web Access Web サイトにログオンすると、デスクトップ共有ボタンが無効になります。マウスでこのボタンをポイントすると、"デスクトップ共有にはセキュリティで保護された接続 (HTTPS) が必要です。システム管理者に問い合わせてください。" というヒントが表示されます。 |
各仮想サーバーに IP アドレスとポートを割り当てる必要もあります。仮想サーバーは IP アドレスを共有することはできますが、ポートを共有することはできません。各仮想サーバーに、他のアプリケーションで使用されない専用のポートが必要です。セットアップでは、既定で、HTTPS 接続にはポート 443、HTTP 接続にはポート 80 が使用されています。これらのポートはインターネット インフォメーション サービス (IIS) の既定の Web サイトでも使用されるので、これらのポートを Communicator Web Access に割り当てる前にそのサイトをシャットダウンする必要があります。
既に説明したように、仮想サーバーを作成するときに、そのサーバーで使用するポートを指定する必要があります。指定したポートが別のアプリケーションで既に使用されている場合は、ポートが既に予約されていることがセットアップ プログラムによって通知され、別のポート番号を選択するように求められます。たとえば、ポート 443 は IIS の既定の Web サイトで使用されています。この Web サイトを無効にしないと、セットアップでポート 443 を仮想サーバーのポートとして使用することはできません。
ただし、Communicator Web Access では、Windows システム コンポーネントで現在使用されているポートが必ずしも認識されるとは限りません。たとえば、仮想サーバーの作成時にポート 137 を選択するとします。セットアップではそのポート番号を使用でき、仮想サーバーが自動的に作成されます。ただし、この新しい仮想サーバーを開始することはできません。これは、このポートがファイルとプリンタの共有で使用されているためです。この場合、Communicator Web Access スナップインを使用してポート番号を変更する必要があります。
次ホップ サーバー
最後に、仮想サーバーに "次ホップ サーバー" を割り当てる必要があります。ユーザーが電話会議に参加しているときに、Communicator Web Access サーバーとユーザーのホーム サーバーの間でメッセージの受け渡しが行われる必要があります。匿名ユーザー (Active Directory ドメインまたはフェデレーション パートナーのドメインにアカウントを持っていないユーザー) も会議に参加できます。ただし、匿名ユーザーにはホーム サーバーがないので、Communicator Web Access がメッセージを中継する場所がありません。
このため、匿名ユーザーのホーム サーバーとして機能できるサーバー (またはサーバー プール) である "次ホップ" サーバーを各仮想サーバーに割り当てる必要があります。Office Communications Server 2007 R2 を実行しているフォレスト内のコンピュータであれば、どれでも次ホップ サーバーに指定できます。
次ホップ サーバーを割り当てるときは、次ホップ サーバーが稼働していることを確認してください。現在オフラインの次ホップ サーバーまたはオフラインにする予定の次ホップ サーバーは割り当てないでください。次ホップ サーバーに障害が発生した場合は、Communicator Web Access も停止します。このため、サーバー プールを次ホップ サーバーとして使用することをお勧めします。これにより、1 台のサーバーに障害が発生しても、Communicator Web Access は引き続き使用できるようになります。
既に説明したように、セットアップ ウィザードでは、Communicator Web Access コンピュータごとに 1 つの仮想サーバーしか作成できません。同じコンピュータに 2 つ目の仮想サーバーを作成する場合 (1 台の Communicator Web Access サーバーで内部ユーザーと外部ユーザーの両方をサポートできるようにする場合など) は、Communicator Web Access スナップインを使用して 2 つ目のサーバーを作成する必要があります。詳細については、「Communicator Web Access スナップインを使用した Communicator Web Access 仮想サーバーの作成」を参照してください。