Lync Server 2013 での XMPP パートナー構成の作成または編集
トピック最終更新日時: 2014-09-03
Microsoft Lync Server 2013 は、エッジ サーバー上の拡張可能メッセージングプレゼンス プロトコル (XMPP) プロキシと、フロントエンド サーバーまたはフロントエンド プール上の XMPP ゲートウェイを統合します。 他の XMPP 展開からの接続を許可するには、Lync Server コントロール パネルで XMPP を構成する必要があります。 XMPP ドメインベースで設定を構成します。 新しいパートナー関連付けを作成するには、次の操作を行います。
新しいフェデレーション パートナーを作成したり、既存の構成を編集したりするには
RTCUniversalServerAdmins グループ (または同等のユーザー権限を持つグループ) のメンバーであるユーザー アカウントまたは CsAdministrator の役割に割り当てられているユーザー アカウントから、内部展開の任意のコンピューターにログオンします。
ブラウザー ウィンドウを開き、管理 URL を入力して Lync Server コントロール パネルを開きます。 Lync Server コントロール パネルの起動に使用できるさまざまな方法の詳細については、「Lync Server 2013 管理ツールを開く」を参照してください。
左側のナビゲーション バーで 、[ フェデレーションと外部アクセス] をクリックし、[ XMPP フェデレーション パートナー] をクリックします。
新しい構成を作成するには、[新規] をクリックします。
既存の構成を編集するには、構成を選択して [編集] をクリックします。
XMPP フェデレーション パートナーの構成を作成または編集するには、次の設定を定義します。
プライマリ ドメイン (必須)。 プライマリ ドメインは、XMPP パートナーのベース ドメインです。 たとえば、XMPP パートナー ドメイン名 の fabrikam.com を入力します。 これは必須のエントリです。
説明。 説明は、この特定の構成に関するメモまたはその他の識別情報用です。 このエントリは省略可能です。
その他のドメイン。 追加ドメインは、XMPP パートナーのドメインの一部であるドメインであり、許可された XMPP 通信の一部として含める必要があります。 たとえば、プライマリ ドメインが fabrikam.com されている場合は、XMPP を使用して通信する fabrikam.com 下にある他のすべてのドメインを一覧表示します。 たとえば、fabrikam.com の メイン XMPP ドメインの下に、企業 XMPP ドメインと Information Technologies XMPP ドメインの corp.fabrikam.com と it.fabrikam.com を入力できます。
パートナーの種類。 パートナーの種類は必須の設定であり、ドロップダウン メニューで 3 つの選択肢を選択できます。 追加できる連絡先を記述して適用するには、次のいずれかを選択する必要があります。 次の中から選択できます。
フェデレーション。 フェデレーション パートナーの種類は、Lync Server または Office Communications Server 2007 R2 パートナーの展開間の信頼できる接続です。
パブリック検証済み。 パブリック検証済みパートナーは、プロバイダーによって検証される展開の一部である連絡先をユーザーの連絡先の一覧に追加できる場合です。 Lync ユーザーから招待を送信することも、Lync ユーザーがパートナーの連絡先からの招待を受け入れることも可能です。
パブリック未検証。 パブリック未検証リレーションシップは、2 つのデプロイ間に確立された検証可能な状態がないことを意味します。 Lync ユーザーが自分の連絡先リストに Lync ユーザーを追加できるようにするには、その連絡先の未確認の連絡先を招待する必要があります。 たとえば、Google GTalk は Lync Server に関連しているため、パブリック検証済みの XMPP サービスではありません。 GTalk ユーザーは、Lync ユーザーから明示的な招待が送信されない限り、Lync ユーザーを連絡先として追加できません。
ストリーム ネゴシエーションとセキュリティ方法トランスポート層セキュリティ (TLS) とソフトウェア認証とセキュリティ層 (SASL) に関する注意事項:
XMPP Standards Foundation (XSF) とインターネット エンジニアリングタスクフォース (IETF) は、TLS クライアント証明書、TLS サーバー証明書、SASL メカニズムを使用および管理するための一連の規則と標準を定義します。 TLS と SASL を使用することは、XMPP ストリームをセキュリティで保護するために必要なプロセスです。 XMPP Standards ドキュメント XEP-0178 から、「PKIX 証明書で SASL EXTERNAL メカニズムを使用するために推奨されるプロトコル フローを指定します。特に、XMPP サービスで TLS が必須のネゴシエートであることが示されている場合)。 PKIX は、XSF ドキュメントで説明されているように、公開キーインフラストラクチャ (PKI とも呼ばれます) を参照します。
XMPP の要件の詳細については、XSF ドキュメント XEP-0178 を参照してください。 詳細については、「XEP-0178: 証明書で SASL EXTERNAL を使用するためのベスト プラクティス」を参照してください。 http://xmpp.org/extensions/xep-0178.html
IETF ドキュメント「拡張可能なメッセージングとプレゼンス プロトコル (XMPP): Core」のセクション 5.0、STARTTLS ネゴシエーション https://tools.ietf.org/html/rfc6120を参照してください。
TLS ネゴシエーション。 TLS ネゴシエーション規則を定義します。 XMPP サービスでは TLS を必要とするか、TLS を省略可能にするか、TLS がサポートされていないことを定義できます。 オプションを選択すると、必須のネゴシエートの決定のために XMPP サービスまで要件が残されます。 SASL、TLS、ダイヤルバック ネゴシエーションのすべての可能な設定と詳細 (無効で既知のエラー構成を含む) を表示するには、 Lync Server 2013 の XMPP フェデレーション パートナーのネゴシエーション設定に関するページを参照してください。
必須。 XMPP サービスには TLS ネゴシエーションが必要です。
省略可能です。 XMPP サービスは、TLS が必須のネゴシエートであることを示します。
サポートされていません。 XMPP サービスは TLS をサポートしていません。
SASL ネゴシエーション。 SASL ネゴシエーション 規則を定義します。 XMPP サービスでは SASL を必要とするか、SASL を省略可能にするか、SASL がサポートされていないことを定義できます。 オプションを選択すると、必須のネゴシエートの決定のために、パートナーの XMPP サービスに要件が任されます。
警告
SASL には TLS が必要です。 SASL を使用するには、TLS が必須であるか省略可能である必要があります。 必要または省略可能として SASL を定義するすべての構成には、TLS サポートが必要です。 [ コミット] をクリックして変更を保存するときに、TLS を必須または省略可能に設定していない場合は、SASL に TLS サポートが必要であり、変更が保存されないことが警告されます。 エラーを解決するには、TLS を [必須] または [省略可能] に設定します。 SASL の使用が省略可能で、TLS ネゴシエーションのサポートが不可能な場合は、SASL ネゴシエーションを [サポートされていません] に設定する必要があります。 TLS と SASL またはサービスの中断に対して適切なネゴシエーション ストリームが必要であることを XMPP サービスで確認します。
必須。 XMPP サービスには SASL ネゴシエーションが必要です。
省略可能です。 XMPP サービスは、SASL が必須のネゴシエートであることを示します。
サポートされていません。 XMPP サービスは SASL をサポートしていません。
ダイヤルバック ネゴシエーション。 ダイヤルバック ネゴシエーションは、ドキュメント XEP-220 : サーバー ダイヤルバックhttp://xmpp.org/extensions/xep-0220.htmlの XSF によって定義されます。 サーバー ダイヤルバック プロセスでは、ドメイン ネーム システム (DNS) と権限のあるサーバーを使用して、要求が有効な XMPP パートナーから送信されたことを確認します。 これを行うために、送信元サーバーは、生成されたダイヤルバック キーを使用して特定の種類のメッセージを作成し、DNS で受信サーバーを検索します。 元のサーバーは、XML ストリーム内のキーを結果の DNS ルックアップ (おそらく受信サーバー) に送信します。 XML ストリーム経由でキーを受信すると、受信側サーバーは送信元サーバーに応答せず、既知の権限のあるサーバーにキーを送信します。 権限のあるサーバーは、キーが有効であるか無効であるかのどちらかであることを確認します。 無効な場合、受信側サーバーは送信元サーバーに応答しません。 キーが有効な場合、受信側サーバーは、ID とキーが有効であり、会話を開始できることを送信元サーバーに通知します。
ダイヤルバック ネゴシエーションには、次の 2 つの有効な状態があります。
True。 元のサーバーから要求を受信する必要がある場合は、ダイヤルバック ネゴシエーションを使用するように XMPP サーバーが構成されている
False。 XMPP サーバーはダイヤルバック ネゴシエーションを使用するように構成されておらず、要求を送信元サーバーから受信する必要がある場合は無視されます。