次の方法で共有


Lync Server 2013 での XMPP パートナー構成の作成または編集

 

トピック最終更新日: 2014-09-03

Microsoft Lync Server 2013 は、エッジ サーバー上の拡張メッセージングおよびプレゼンス プロトコル (XMPP) プロキシと、フロントエンド サーバーまたはフロント エンド プール上の XMPP ゲートウェイを統合します。 他の XMPP 展開からの接続を許可するには、Lync Server コントロール パネルで XMPP を構成する必要があります。 XMPP ドメインごとに設定を構成します。 新しいパートナー関連付けを作成するには、次の操作を行います。

新しいフェデレーション パートナーを作成するか、既存の構成を編集するには

  1. RTCUniversalServerAdmins グループ (または同等のユーザー権限を持つグループ) のメンバーであるユーザー アカウントまたは CsAdministrator の役割に割り当てられているユーザー アカウントから、内部展開の任意のコンピューターにログオンします。

  2. ブラウザー ウィンドウを開き、管理 URL を入力して Lync Server コントロール パネルを開きます。 Lync Server コントロール パネルの起動に使用できるさまざまな方法の詳細については、「Open Lync Server 2013 管理ツール」を参照してください。

  3. 左側のナビゲーション バーで、[ フェデレーションと外部アクセス] をクリックし、[ XMPP フェデレーション パートナー] をクリックします。

  4. 新しい構成を作成するには、[新規] をクリックします。

  5. 既存の構成を編集するには、構成を選択し、[編集] をクリックします。

  6. XMPP フェデレーション パートナーの構成を作成または編集するには、次の設定を定義します。

  7. プライマリ ドメイン (必須)。 プライマリ ドメインは、XMPP パートナーの基本ドメインです。 たとえば、XMPP パートナー ドメイン名 に「fabrikam.com 」と入力します。 これは必須のエントリです。

  8. 説明。 説明は、この特定の構成に関するメモやその他の識別情報を対象とします。 このエントリは省略可能です。

  9. その他のドメイン。 追加のドメインは、XMPP パートナーのドメインの一部であり、許可されている XMPP 通信の一部として含める必要があるドメインです。 たとえば、プライマリ ドメインが fabrikam.com されている場合は、XMPP を使用して通信する fabrikam.com の下にある他のすべてのドメインを一覧表示します。 たとえば、fabrikam.com の メインXMPP ドメインの下に、企業 XMPP ドメインと Information Technologies XMPP ドメインの corp.fabrikam.com と it.fabrikam.com を入力できます。

  10. パートナーの種類パートナーの種類は必須の設定であり、ドロップダウン メニューで 3 つの選択肢を選択できます。 追加できる連絡先を説明して適用するには、次のいずれかを選択する必要があります。 次の中から選択できます。

    • フェデレーション。 フェデレーション パートナーの種類は、Lync Server または Office Communications Server 2007 R2 パートナー展開間の信頼された接続です。

    • パブリック検証済みパブリック検証パートナーは、プロバイダーによって検証された展開の一部である連絡先をユーザーの連絡先の一覧に追加できる場合です。 Lync ユーザーから招待を送信することも、Lync ユーザーがパートナーの連絡先からの招待を受け入れることもできます。

    • 未検証のパブリックパブリック検証されていない関係は、2 つのデプロイ間に確立された検証可能な状態がないことを意味します。 Lync ユーザーが連絡先リストに Lync ユーザーを追加できるようにするには、その連絡先の未確認の連絡先を招待する必要があります。 たとえば、Google GTalk は、Lync Server に関連するため、パブリック検証済みの XMPP サービスではありません。 Lync ユーザーから明示的な招待が送信されない限り、GTalk ユーザーは Lync ユーザーを連絡先として追加できません。

  11. ストリーム ネゴシエーションとセキュリティ方法のトランスポート層セキュリティ (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 : Server Dialbackhttp://xmpp.org/extensions/xep-0220.html のドキュメントの XSF によって定義されます。 サーバー ダイヤルバック プロセスでは、ドメイン ネーム システム (DNS) と権限のあるサーバーを使用して、要求が有効な XMPP パートナーから送信されたことを確認します。 これを行うために、送信元サーバーは、生成されたダイヤルバック キーを使用して特定の種類のメッセージを作成し、DNS で受信サーバーを検索します。 送信元サーバーは、XML ストリーム内のキーを結果の DNS 参照 (おそらく受信サーバー) に送信します。 XML ストリーム経由でキーを受信すると、受信側サーバーは送信元サーバーに応答せず、既知の権限のあるサーバーにキーを送信します。 権限のあるサーバーは、キーが有効か無効かのどちらかであることを確認します。 有効でない場合、受信側サーバーは送信元サーバーに応答しません。 キーが有効な場合、受信側サーバーは、ID とキーが有効であり、会話を開始できることを送信元サーバーに通知します。

      ダイヤルバック ネゴシエーションには、次の 2 つの有効な状態があります。


      • True。 XMPP サーバーは、発信側サーバーから要求を受信する必要がある場合にダイヤルバック ネゴシエーションを使用するように構成されています


      • False。 XMPP サーバーはダイヤルバック ネゴシエーションを使用するように構成されておらず、送信元サーバーから要求を受信する必要がある場合は無視されます