サインインと検出に関する一般的な問題

間違ったユーザー情報

次のシナリオは、ユーザーのアカウントまたはユーザーがサインイン時に使用する情報に関連する、サインインの一般的な問題を示しています。

間違ったサインイン アドレス

Communicator にサインインしようとすると、"入力したサインイン アドレス、ユーザー名、またはパスワードが正しくないか、認証サービスがこのバージョンのプログラムと互換性がないため、Communicator にサインインできません。" というメッセージが表示される場合があります。

多くの場合、ユーザーは、ユーザーの Active Directory プロパティで指定されている SIP URI と一致しないサインイン アドレスでサインインしようとしています。SIP URI の形式は、Office Communications Server に対してユーザーを有効にするときに管理者によって決定されます。SIP URL は、ユーザーの電子メール アドレス、ユーザー プリンシパル名、フル ネーム、またはセキュリティ アカウント マネージャ (SAM) アカウント (以前のバージョンの Windows オペレーティング システムで使用されていたログオン名) から生成できます。ユーザーは、正しい形式の SIP URI を使用してサインインを再試行する必要があります。

Office Communications Server に対して有効になっていないユーザー アカウント

ユーザーが正しい形式の SIP URI を入力していても、サインインが継続的に失敗する場合、ネットワーク管理者は、ユーザー アカウントが有効になっていること、ユーザーが Office Communications Server に対して有効になっていること、およびアカウントのパスワードが失効していないことまたはリセットされていないことを確認する必要があります。

ユーザー アカウントを有効にする方法の詳細については、Microsoft Office Communications Server 2007 R2 テクニカル ライブラリ (https://go.microsoft.com/fwlink/?Linkid=144479) で、「Operations (操作)」 > 「Administering Office Communications Server 2007 R2 (Office Communications Server 2007 R2 の管理)」 > 「Managing User Accounts (ユーザー アカウントの管理)」を参照してください。

ユーザーに [プロファイル] フォルダに対するアクセス許可がない

サーバーが利用できないというエラーが個々のユーザーに返される場合は、Communicator の Windows イベント ログをオンにして、Windows イベント トレース ログを確認します。C:\Documents and Settings\<user name>\Local Settings\Application Data\Microsoft に Communicator フォルダを作成しているときに、ログに "アクセスが拒否されました" というエラーが表示される場合があります。この問題を解決するには、Communicator フォルダに対する適切な権限をユーザーに付与します。

手動構成によるサインインの失敗

手動構成におけるサインインの問題は、通常、クライアントの接続の詳細設定でサーバー名エントリが間違っていることが原因です。クライアントのイベント ビューアに、"Communicator はエラー 10061 によりサーバー 192.168.0.2 (192.168.0.2) (ポート 5060) への接続に失敗しました。" というメッセージが表示される場合があります。これは、クライアントが接続できなかったサーバーの IP アドレスを指しています。サーバーが提示したサーバーが、予期されるホスト名と一致していないという情報が表示されることもあります。多くの場合、これらのエラーは、クライアントの [接続の詳細設定] ダイアログ ボックスにサーバーの IP アドレスが入力されていることが原因です。

[接続の詳細設定] には、サーバーの IP アドレスまたは NetBIOS 名ではなく、サーバーの FQDN を入力します。

接続設定で手動構成を使用する場合、クライアントと Office Communications Server の接続に TLS が必要かどうかを確認することも必要です。TLS が必要な場合は、[接続の詳細設定] で TLS オプションを選択し、既に使用されている証明書とサーバー名が一致するように、(サーバーの IP アドレスまたは NetBIOS 名ではなく) サーバーの FQDN を指定する必要があります。

サーバーへの接続で TCP が使用される場合は、Office Communications Server のプール プロパティが TCP リッスン ポート 5060 に設定されていることを確認します。

自動構成によるサインインの失敗

自動構成では、DNS 構成、証明書、またはサーバーの名前付けに関する問題が発生する可能性があります。

DNS の構成

自動構成を使用している場合は、DNS で公開されているサーバー名がサーバー証明書でサポートされていることを確認します。クライアントとサーバーの検出を可能にする DNS レコードの作成が必要かどうか、および自動クライアント サインインのサポート (組織がサポートを必要とする場合) については、Microsoft Office Communications Server 2007 R2 の記事「ドメイン ネーム システム (DNS) の要件」(https://go.microsoft.com/fwlink/?linkid=146936) を参照してください。

クライアントが自動的にサインインするように構成されている場合は、適切な DNS SRV レコードが存在することを確認します。TLS 接続を使用する場合は、次の SRV レコードを追加し、サーバーのホスト レコードにマップします。

ポート 5061 経由の _sipinternaltls._tcp.<ドメイン>

注:
SIP ドメインが Office Communications Server ドメインと異なる場合は、Office Communications Server ホスト レコードではなくホスト レコード sip.<ドメイン> を作成することをお勧めします。

TCP 接続を使用する場合は、次の SRV レコードを追加し、サーバーのホスト レコードにマップします。

ポート 5060 経由の _sipinternal._tcp.<ドメイン>

厳密な名前の確認

クライアントが自動構成を使用してサインインし、TLS が必要な場合、接続の失敗は EnableStrictDNSNaming ポリシーの設定が原因である可能性があります。Communicator が自動接続用に構成されており、TLS が適用されている場合、このポリシーにより Office Communicator は SIP コミュニケーション サービスを使用するときにインスタント メッセージを安全に送受信できます。このポリシー設定は、Windows .NET サービスと Microsoft Exchange Server サービスには影響しません。EnableStrictDNSNaming ポリシーに関する混乱の多くは、ポリシーの説明が不明確であることが原因です。このポリシーを間違って設定すると、TLS ネゴシエーションとクライアント サインインで予期しない問題が発生する可能性があります。このポリシーの正しい説明は次のとおりです。

EnableStrictDNSNaming ポリシーを [有効] に設定すると、Communicator クライアントは、名前がユーザーの SIP URI ドメインと一致する場合、または FQDN が sip.<URI ドメイン> の場合のみサーバーに接続できます。たとえば、ユーザーの SIP URI が someone@contoso.com の場合、Communicator は次のサーバーにのみ接続できます。

• contoso.com
• sip.contoso.com

このポリシーを構成していないか、[無効] に設定している場合、Communicator クライアントはユーザーの SIP URI のドメイン部分で終わる FQDN を使用している任意の SIP サーバーと通信できます。たとえば、Communicator は sip.division.contoso.com または lc.contoso.com という名前のサーバーと通信できます。欠点は、悪意のあるユーザーが attacker.contoso.com などのサーバー名で最初の DNS クエリに応答する可能性がある点です。このポリシーを構成しないか、または無効にすると、man-in-the-middle 攻撃を受けやすくなります。

このポリシーを有効にしない理由の 1 つは、組織に複数のサブドメインがあり、証明書を設定する場合、厳密でないサーバー名を許可する柔軟性が必要とされることです。

このポリシーを有効にするには、SIP サーバーの FQDN が厳密な命名形式の 1 つと一致することを確認します。

注:
このポリシー設定は、コンピュータの構成とユーザーの構成の両方で構成できますが、コンピュータの構成のポリシー設定が優先されます。

外部ユーザーがサインインできない

内部ユーザーがサインインでき、外部ユーザーに問題が生じる場合は、認証プロトコルの構成方法、サインイン時に指定したポート、またはサーバー側の暗号設定に問題がある可能性があります。

認証プロトコルを [NTLM と Kerberos の両方] に設定する

Office Communications Server 2007 R2 は、ユーザーの場所に応じて Kerberos 認証プロトコルまたは NTLM 認証プロトコルを使用します。Kerberos プロトコルは Active Directory へのクライアント接続を必要とし、Active Directory の資格情報を持つ内部ユーザーに使用されます。Active Directory の資格情報を持ち、企業ファイアウォールの外部から接続している外部ユーザーは NTLM を使用します。

外部ユーザーが認証できない場合は、Office Communications Server のフロントエンド サーバー プロパティの認証プロトコルが [NTLM と Kerberos の両方] に設定されていることを確認します。

5061 上のクライアントの手動サインイン、443 上のアクセス エッジ リッスン

企業ファイアウォールの外部から接続するクライアントは、エッジ サーバーとの SIP 通信にポート 443 を使用します。クライアントが手動構成を使用してサーバーに接続するように構成されており、外部サーバーが間違ったポートで構成されている場合があります。たとえば、クライアントがポート 5061 のサーバーに接続するように手動で構成され、アクセス エッジ サーバーがポート 443 をリッスンしている場合、接続は失敗します。[外部サーバー名または IP アドレス] でクライアントの [接続の詳細設定] を確認し、エントリでポート 443 (sip.domain.com:443 など) が指定されていることを確認します。

グループ ポリシーを使用して外部サーバー名を指定する場合は、ポート 443 も指定します。

NTLMMINCLIENTSEC と NTLMMINSERVERSEC の不一致

組織はローカル ポリシーとグループ ポリシーを使用して、セキュリティを強化するように Windows Server ドメインで特定のセキュリティ設定を構成できます。このような設定の 1 つに NTLMv2 認証設定があります。これは、サーバーとクライアントとの間の通信に暗号化を要求するように構成できます。クライアント側とサーバー側の設定が一致しない場合、通信は確立されません。

NTLMv2 認証の設定は、次のレジストリにあります。

HKey_Local_Machine\System\CurrentControlSet\Control\Lsa\MSV1_0ntlmminclientsec

HKey_Local_Machine\System\CurrentControlSet\Control\Lsa\MSV1_ ntlmminserversec

サーバーは暗号化を要求するように構成され、クライアントはそのように構成されていない場合があります。この場合、フロントエンド サーバーはクライアントの NTLM 要求を渡しません。この状況は、主に外部ユーザーに影響します。これは、NTLM は外部クライアントがサインインに使用できる唯一の認証プロトコルであるためです。たとえば、サーバー キーが 128 ビット暗号化を指定する値 0x20080030 を使用するように構成され、クライアントがそのように構成されていない場合、クライアントはサインインできません。クライアントのこのキーが、サーバーの設定と一致するように構成されていることを確認する必要があります。

詳細については、マイクロソフト サポート技術情報の記事 823659「セキュリティ設定およびユーザー権利の割り当てを変更すると、クライアント、サービス、およびプログラムの互換性がなくなる」(https://go.microsoft.com/fwlink/?linkid=147230) を参照してください。