Erstellen oder Bearbeiten einer XMPP-Verbundpartnerkonfiguration in Lync Server 2013

 

Thema Letzte Änderung: 03.09.2014

Microsoft Lync Server 2013 integriert einen XMPP-Proxy (Extensible Messaging and Presence Protocol) auf dem Edgeserver und ein XMPP-Gateway auf dem Front-End-Server oder Front-End-Pool. Um Verbindungen von anderen XMPP-Bereitstellungen zuzulassen, müssen Sie XMPP im Lync Server-Systemsteuerung konfigurieren. Sie konfigurieren Einstellungen auf XMPP-Domänenbasis. Gehen Sie wie folgt vor, um eine neue Partnerzuordnung zu erstellen:

So erstellen Sie einen neuen Verbundpartner oder bearbeiten eine vorhandene Konfiguration

  1. Melden Sie sich mit einem Benutzerkonto, das Mitglied der Gruppe "RTCUniversalServerAdmins" ist (oder über gleichwertige Benutzerrechte verfügt) oder dem die Rolle "CsAdministrator" zugewiesen ist, auf einem beliebigen Computer in Ihrer internen Bereitstellung an.

  2. Öffnen Sie ein Browserfenster, und geben Sie dann die Admin-URL ein, um die Lync Server-Systemsteuerung zu öffnen. Ausführliche Informationen zu den verschiedenen Methoden, die Sie zum Starten von Lync Server Systemsteuerung verwenden können, finden Sie unter Open Lync Server 2013 administrative tools.

  3. Klicken Sie in der linken Navigationsleiste auf "Partnerverbund" und "Externer Zugriff" und dann auf "XMPP-Partnerverbundpartner".

  4. Klicken Sie auf "Neu", um eine neue Konfiguration zu erstellen.

  5. Um eine vorhandene Konfiguration zu bearbeiten, wählen Sie die Konfiguration aus, und klicken Sie auf "Bearbeiten".

  6. Zum Erstellen oder Bearbeiten von Konfigurationen für XMPP-Verbundpartner definieren Sie die folgenden Einstellungen:

  7. Primäre Domäne (erforderlich). Die primäre Domäne ist die Basisdomäne des XMPP-Partners. Beispielsweise geben Sie fabrikam.com für den Namen der XMPP-Partnerdomäne ein. Dies ist ein erforderlicher Eintrag.

  8. Beschreibung. Die Beschreibung betrifft Notizen oder andere identifizierende Informationen für diese bestimmte Konfiguration. Dieser Eintrag ist optional.

  9. Zusätzliche Domänen. Weitere Domänen sind Domänen, die Teil der Domäne Ihres XMPP-Partners sind, die als Teil der zulässigen XMPP-Kommunikation enthalten sein sollten. Wenn beispielsweise die primäre Domäne fabrikam.com ist, würden Sie alle anderen Domänen auflisten, die sich unter fabrikam.com befinden, mit denen Sie über XMPP kommunizieren. Sie können z. B. corp.fabrikam.com und it.fabrikam.com für die XMPP-Domäne des Unternehmens und die XMPP-Domäne für Informationstechnologien unter der XMPP-Hauptdomäne von fabrikam.com eingeben.

  10. Partnertyp. Der Partnertyp ist eine erforderliche Einstellung und bietet Ihnen eine Auswahl von drei Optionen in einem Dropdownmenü. Sie müssen eine der folgenden Optionen auswählen, um zu beschreiben und zu erzwingen, welche Kontakte hinzugefügt werden können. Sie können folgende Optionen auswählen:

    • Verbund. Ein Partnerverbundtyp ist eine vertrauenswürdige Verbindung zwischen einer Lync Server- oder Office Communications Server 2007 R2-Partnerbereitstellung.

    • Öffentlich überprüft. Ein öffentlich überprüfter Partner ist, wenn Kontakte, die Teil einer Bereitstellung sind, die vom Anbieter überprüft werden, der Liste der Kontakte Ihres Benutzers hinzugefügt werden können. Einladungen können vom Lync-Benutzer gesendet werden, oder der Lync-Benutzer kann Einladungen vom Partnerkontakt annehmen.

    • Öffentlich nicht überprüft. Eine öffentlich nicht überprüfte Beziehung impliziert, dass zwischen den beiden Bereitstellungen kein festgelegter und überprüfbarer Status vorhanden ist. Ein Lync-Benutzer muss den nicht überprüften Kontakt einladen, damit dieser den Lync-Benutzer zu seiner Kontaktliste hinzufügen kann. Google GTalk ist beispielsweise kein öffentlich überprüfter XMPP-Dienst, da er sich auf Lync Server bezieht. Ein GTalk-Benutzer kann den Lync-Benutzer nur dann als Kontakt hinzufügen, wenn eine explizite Einladung vom Lync-Benutzer gesendet wird.

  11. Hinweise zur Stream-Aushandlung und zu den Sicherheitsmethoden Transport Layer Security (TLS) und Software Authentication and Security Layer (SASL):

    Die XMPP Standards Foundation (XSF) und die Internet Engineering Task Force (IETF) definieren eine Reihe von Regeln und Standards für die Verwendung und Verwaltung von TLS-Clientzertifikaten, TLS-Serverzertifikaten und dem SASL-Mechanismus. Die Verwendung von TLS und SASL ist der erforderliche Prozess zum Sichern des XMPP-Datenstroms. Aus dem XMPP-Standards-Dokument XEP-0178 gibt "einen empfohlenen Protokollfluss für die Verwendung des EXTERNEN SASL-Mechanismus mit PKIX-Zertifikaten an, insbesondere wenn ein XMPP-Dienst angibt, dass TLS obligatorisch auszuhandeln ist." PKIX, wie in der XSF-Dokumentation angegeben, bezieht sich auf public key infrastructure, auch bekannt als PKI.

    Weitere Informationen zu den XMPP-Anforderungen finden Sie im XSF-Dokument XEP-0178. Ausführliche Informationen finden Sie unter "XEP-0178: Bewährte Methoden für die Verwendung von SASL EXTERNAL mit Zertifikaten". http://xmpp.org/extensions/xep-0178.html

    Weitere Informationen finden Sie im IETF-Dokument "Extensible Messaging and Presence Protocol (XMPP): Core", Abschnitt 5.0, STARTTLS Negotiation https://tools.ietf.org/html/rfc6120.

    • TLS-Aushandlung. Definiert die TLS-Aushandlungsregeln. Ein XMPP-Dienst kann TLS erfordern, TLS optional machen, oder Sie definieren, dass TLS nicht unterstützt wird. Die Wahl von Optional überlässt die Anforderung an den XMPP-Dienst für eine obligatorische Aushandlungsentscheidung. Informationen zum Anzeigen aller möglichen Einstellungen und Details für SASL-, TLS- und Dialback-Aushandlungen – einschließlich ungültiger und bekannter Fehlerkonfigurationen – finden Sie unter Aushandlungseinstellungen für XMPP-Partnerverbundpartner in Lync Server 2013.


      • Erforderlich. Der XMPP-Dienst erfordert TLS-Aushandlung.


      • Optional. Der XMPP-Dienst gibt an, dass TLS obligatorisch auszuhandeln ist.


      • Nicht unterstützt. Der XMPP-Dienst unterstützt TLS nicht.

    • SASL-Aushandlung. Definiert die SASL-Aushandlungsregeln. Ein XMPP-Dienst kann SASL erfordern, SASL optional machen, oder Sie definieren, dass SASL nicht unterstützt wird. Die Auswahl von Optional überlässt die Anforderung an den XMPP-Partnerdienst für eine obligatorische Aushandlungsentscheidung.

      Warnung

      SASL erfordert TLS. Um SASL verwenden zu können, muss TLS entweder erforderlich oder optional sein. Jede Konfiguration, die SASL als erforderlich oder optional definiert, muss ÜBER TLS-Unterstützung verfügen. Wenn Sie beim Klicken auf " Commit " klicken, um Ihre Änderungen zu speichern, wenn Sie TLS nicht auf "Erforderlich" oder "Optional" festgelegt haben, werden Sie gewarnt, dass SASL TLS-Unterstützung haben muss und Ihre Änderungen nicht gespeichert werden. Um den Fehler zu beheben, legen Sie TLS auf "Erforderlich" oder "Optional" fest. Wenn die Verwendung von SASL optional ist und die TLS-Aushandlungsunterstützung nicht möglich ist, müssen Sie die SASL-Aushandlung auf "Nicht unterstützt" festlegen. Vergewissern Sie sich mit dem XMPP-Dienst, was die richtigen Aushandlungsstreams für TLS und SASL oder Dienstunterbrechungen sein müssen.


      • Erforderlich. Der XMPP-Dienst erfordert SASL-Aushandlung.


      • Optional. Der XMPP-Dienst gibt an, dass SASL obligatorisch auszuhandeln ist.


      • Nicht unterstützt. Der XMPP-Dienst unterstützt SASL nicht.

    • Dialback-Aushandlung. Die Dialback-Aushandlung wird durch den XSF im Dokument XEP-220 : Server Dialbackhttp://xmpp.org/extensions/xep-0220.html definiert. Der Server-Dialbackprozess verwendet das Domänennamensystem (DNS) und einen autoritativen Server, um zu überprüfen, ob die Anforderung von einem gültigen XMPP-Partner stammt. Dazu erstellt der Ursprungsserver eine Nachricht eines bestimmten Typs mit einem generierten Dialbackschlüssel und sucht den empfangenden Server im DNS nach. Der Ursprungsserver sendet den Schlüssel in einem XML-Stream an die resultierende DNS-Suche, vermutlich an den empfangenden Server. Beim Empfang des Schlüssels über den XML-Datenstrom antwortet der empfangende Server nicht auf den ursprünglichen Server, sondern sendet den Schlüssel an einen bekannten autorisierenden Server. Der autoritative Server überprüft, ob der Schlüssel gültig oder ungültig ist. Wenn ungültig, antwortet der empfangende Server nicht auf den ursprünglichen Server. Wenn der Schlüssel gültig ist, informiert der empfangende Server den ursprünglichen Server darüber, dass die Identität und der Schlüssel gültig sind und die Unterhaltung beginnen kann.

      Es gibt zwei gültige Zustände für die Dialback-Aushandlung:


      • True. Der XMPP-Server ist für die Verwendung der Dialback-Aushandlung konfiguriert, wenn eine Anforderung von einem ursprünglichen Server empfangen werden soll.


      • False. Der XMPP-Server ist nicht für die Verwendung der Dialback-Aushandlung konfiguriert. Wenn eine Anforderung von einem ursprünglichen Server empfangen werden soll, wird er ignoriert.