Office Communicator へのサインインとその検出
トピックの最終更新日: 2009-04-02
Office Communicator は、ユーザーの URI (jeremy@contoso.com など)、およびクライアントに構成されている手動の設定を使用して、ログオンするサーバーを判別する必要があります。手動の設定が行われている場合、使用するサーバーは明白です。しかし、URI が唯一の提供されている手掛かりの場合、検出処理が必要です。
Communicator の検出機能は、構成によって異なります。クライアントは、接続するサーバーを検出後、TCP、または TLS over TCP を使用して接続しようとします。TLS が使用されると、サーバーはクライアントに対して自身を認証するために証明書を提示します。クライアントは、続行する前に証明書を検証する必要があります。クライアントは、まず圧縮を取り扱う場合があり (TLS over TCP を使用している場合)、それから SIP 登録を開始します。
次に、クライアントは、資格情報なしに SIP REGISTER メッセージをサーバーに送信します。これにより、Office Communications Server がユーザーの資格情報を求めるようになり、Communicator クライアントが受け入れる認証プロトコルが指定されます。
資格情報の提供方法として、Communicator には 2 つの選択肢があります。Communicator は、ユーザーの現在の Windows 資格情報を使用してログオンすることも、ユーザーに資格情報の入力を求めることもできます。
.gif "Dd637152.note(ja-jp,office.13).gif") 注: |
|---|
| Windows の資格情報マネージャも、資格情報の管理に使用できます。資格情報マネージャの詳細については、Microsoft TechNet の記事「Windows XP Resource Kit: Understanding Logon and Authentication (Windows XP Resource Kit: ログオンと認証の理解)」(https://go.microsoft.com/fwlink/?Linkid=133674) を参照してください。 |
認証エラーは、ログオン処理の最初の部分で発生することがあります。これは、資格情報がまだ保存されていないか、Communicator が使用しようとしているアカウントとデスクトップの資格情報が一致しないときに発生することがあります。これは、SIP URI、アカウント名、またはパスワードが誤って入力されたか、資格情報が SIP URI と一致しないときにも発生することがあります。この例としては、Jeremy が URI sip:jeremy@contoso.com を使用してログオンしようとしたが、ユーザー アカウントとパスワードにはアカウント所有者自身の資格情報 CONTOSO\jeremy ではなく、CONTOSO\vadim を使用する場合が考えられます。
クライアントの自動構成および DNS 検出の理解
自動構成の使用を予定している組織において、サーバー展開中の要件の 1 つは、次のレコードの 1 つを、クライアントのサインイン要求を処理するエンタープライズ プールまたは Standard Edition サーバーの完全修飾ドメイン名 (FQDN) にマップする内部 DNS SRV レコードを作成することです。
- _sipinternaltls._tcp.<ドメイン> (内部 TLS 接続の場合)
- _sipinternal._tcp. <ドメイン> (内部 TCP 接続の場合。TCP が許可されている場合のみ実行)
クライアントは、自動構成を使用するように設定されている場合、ユーザーから指定された SIP URI を使用して、サインインするサーバーを検出します。Communicator は、SIP URI のドメイン部分に対して発行された DNS SRV レコードを使用して、これを実行します。
たとえば、ユーザーが URI として「sip:jeremy@contoso.com」と入力すると、Communicator は contoso.com を使用して DNS を使用する SIP サーバーを検出します**。Communicator は、該当するサーバーの検索中に次の SRV レコードを検索します。
- _sipinternaltls._tcp.contoso.com
- _sipinternal._tcp.contoso.com
- _sip._tls.contoso.com
これらのレコードが存在しない場合、Communicator は次のホスト (A) レコードについてクエリを実行します。
- sipinternal.contoso.com
- sipexternal.contoso.com
1 つ目のクエリは、TLS over TCP をサポートするポートをクライアントに対して提供する、contoso.com ドメイン内の内部サーバーを検索します。2 つ目のクエリは、TCP ポートをクライアントに対して提供する、contoso.com ドメイン内の内部サーバーを検出しようとします。最後に、3 つ目のクエリは、TLS over TCP をサポートするポートをクライアントに対して提供する、contoso.com ドメインに対してインターネットで到達可能なサーバーを検索します。TCP をサポートする、インターネットで到達可能なサーバーを Communicator が検索することはありません。インターネット上でクリア テキスト SIP を使用することは、セキュリティの観点からは無意味であるためです。つまり、Communicator は使用するネットワークが内部であるか、外部であるかを関知しません。Communicator は、すべての DNS SRV レコードに対してクエリを実行します。ただし、TLS over TCP 接続を最初に試します。TLS over TCP は、エッジ サーバーを通じて適用されます (セキュリティで保護されていない TCP 接続を許可するオプションはありません)。
最後に、すべての DNS SRV レコードが存在しない場合 (レコードが無効な場合ではなく、まったく存在しない場合のみ)、クライアントは sipinternal.<URI ドメイン> にフォールバックし、そのホスト名を解決しようとします**。ホスト名が 1 つの IP アドレスに解決されると、Communicator は TLS over TCP、TCP、またはその両方をポリシーの許可に基づいて使用して、接続しようとします。これが失敗すると、sipexternal.<URI ドメイン> を使用して、最後の 1 回を試行します**。
TCP が使用されないように、Communicator のポリシーを配置できます。これにより、2 つ目のクエリは発行されなくなります。コンピュータが検出されるためには厳密な名前を必要とする、EnableStrictDNSNaming ポリシーも指定できます。この場合、Communicator は、名前がユーザー SIP URI のドメイン部分のドメインと一致するか、FQDN が sip.<URI ドメイン> である場合にのみ、サーバーへの接続が許可されます**。このポリシーが有効になっていない場合は、形式 <サーバー名>.<URI ドメイン> のサーバー名が許可されます。たとえば、sip:jeremy@contoso.com の場合、ホスト sip.contoso.com は常に許可されます (厳密なポリシーであるかどうかに関係なし)。厳密な命名規則が有効になっていない場合、Server77.contoso.com、sipfed.contoso.com、および ap.contoso.com もすべて許可されます。次のサーバー名は、ユーザーの URI で指定されたドメインに緊密に適合しないため、許可されることはありません。このため、クライアントは、sip.eng.contoso.com、sip.contoso.net、sip.com、sip.contoso.com.cpandl.com などのサーバーを有効なログオン ポイントとして認めません。
ホスト名と URI との間でこのように緊密な検証が実行されるのは、クライアントに提供されている唯一の構成が SIP URI であるためです。このため、クライアントは、介入者に接続を許可する DNS 攻撃ができないように、十分注意する必要があります。接続できると、そこから Communicator のトラフィックを介入者が監視できる可能性があります。URI とログオンが許可されるホスト名との間に緊密な関係を設定することにより、ユーザーがログオンしようとしているドメインに対する権限を、ユーザーが検証している証明書が実際に保有していることをより確実に確認できます。
ホスト名の特定後、Communicator はホスト名の IP アドレスへの解決も行います。これは通常、DNS SRV 要求の結果として起こりますが、IP アドレスが解決されるまでは、Communicator は接続できません。これも、ログオン時に問題になる場合があります。
Communicator の最新版では、ログオン対象の内部サーバーと外部サーバーの "両方を" 手動で指定する機能が有効になっています**。Communicator は常に、内部サーバーが使用可能であればそれに接続しようとしますが、外部サーバーにフォールバックします。以前は、Communicator には単一の手動エントリしかないため、モバイル ワーカーにとっては問題がありました。内部サーバーと外部サーバーを指定できる機能により、内部ネットワークと外部ネットワークをまたがって機能するラップトップ構成を、管理者が構成および有効化しやすくなりました。この機能強化は、ユーザーの URI のドメインが SIP エンタープライズ サーバーのドメインとは異なる会社にとっても重要です。管理者は Communicator (ラップトップ上など) を 1 回のみ構成するため、内部サーバーであるか、外部サーバーであるかをユーザーが意識する必要がなく、リモート アクセス ユーザーをサポートするすべてのドメインについて DNS SRV レコードを管理者が発行する必要もありません。
Office Communicator クライアントは、実際にサーバー名を入力することなく、ユーザーが自動的に該当する Office Communications Server に接続できるようにします。クライアントが内部ネットワーク内に存在するか、外部で作業しているかに関係なく、この機能により、クライアントがリダイレクトされ、自身の Office Communications Server (Standard Edition の場合) またはホーム プール (Enterprise Edition の場合) に対して認証および接続できます。この機能は、DNS に大幅に依存します。これを正常に機能させるためには、内部と外部の両方で、適切な SRV レコードを発行する必要があります。
Office Communicator クライアントが最初に開始し、ユーザーが接続しようとするときは常に、Office Communicator は同じドメイン内のサーバーまたはホーム プールに接続しようとするか、同じ SIP URI をサインイン アドレスとして使用することで接続しようとします。たとえば、使用されるサインイン名が kim.akers@fabrikam.com である場合、Office Communicator は、同じ DNS 名前空間である fabrikam.com 内のホーム プールまたは Office Communications Server を検索します。このプロセスは、DNS SRV レコードを使用することで簡単になりました。このレコードが最終的に、クライアントを正しいドメイン内のホーム プールまたはサーバーの FQDN に結び付けます。このプロセスは、クライアントが内部ネットワークと外部ネットワークのいずれに存在するかに関係なく、同じように機能します。
クライアントは、SRV レコードに対するクエリの実行を開始し、既定では、常に TLS を認証のために使用しようとします。TLS が失敗した場合のみ、伝送制御プロトコル (TCP) にフォールバックします。
- _sipinternaltls._tcp.fabrikam.com
- _sipinternal._tcp.fabrikam.com
この最初の 2 件の DNS レコードのいずれかは、内部 DNS 名前空間に発行され、使用可能です。このため、これまでにクライアントがホスト名を入手している場合、クライアントは直接ホーム プールまたは Office Communications Server に接続します。それ以外の場合、クライアントは、内部ネットワークに現在存在しないことを認識しながら、クエリ プロセスを続行します。
- _sip._tls.fabrikam.com
- _sip._tcp.fabrikam.com
これらのクエリのいずれかが正常に実行されると、クライアントはアクセス エッジ サーバーの外部エッジにリダイレクトされ、その後、内部のホーム プールまたは Office Communications Server にリダイレクトされます。ただし、それでも失敗する場合は、最後の試みとして、次の 2 つの例にあるようにホスト レコードを直接検索しようとします。設定を自動的に構成するこの試みが失敗すると、Office Communicator が失敗し、手動での介入が必要になります。
- sip.fabrikam.com
- sipinternal.fabrikam.com