Freigeben über


Erstellen oder Bearbeiten einer XMPP-Verbundpartnerkonfiguration in Lync Server 2013

 

Letztes Änderungsdatum des Themas: 2014-09-03

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 Öffnen der Lync Server 2013-Verwaltungstools.

  3. Klicken Sie in der linken Navigationsleiste auf Verbund und externer Zugriff, und klicken Sie dann auf XMPP-Verbundpartner.

  4. Um eine neue Konfiguration zu erstellen, klicken Sie auf Neu.

  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 würden Sie fabrikam.com für den XMPP-Partnerdomänennamen eingeben. Dies ist ein erforderlicher Eintrag.

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

  9. Zusätzliche Domänen. Zusätzliche Domänen sind Domänen, die Teil der Domäne Ihres XMPP-Partners sind und als Teil der zulässigen XMPP-Kommunikation einbezogen werden sollten. Wenn die primäre Domäne beispielsweise fabrikam.com ist, listen Sie alle anderen Domänen auf, die sich unter fabrikam.com befinden, mit denen Sie über XMPP kommunizieren. Sie können beispielsweise corp.fabrikam.com und it.fabrikam.com für die XMPP-Domäne "Unternehmen" und die XMPP-Domäne "Informationstechnologien" unter fabrikam.com Standard XMPP-Domäne 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 zwischen folgenden Optionen wä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 verifizierter Partner ist, wenn Kontakte, die Teil einer Bereitstellung sind und vom Anbieter überprüft werden, der Kontaktliste 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 nicht überprüfte Public-Beziehung impliziert, dass zwischen den beiden Bereitstellungen keine festgelegte und überprüfbare status vorhanden ist. Ein Lync-Benutzer muss den nicht überprüften Kontakt für diesen Kontakt einladen, um den Lync-Benutzer zu seiner Kontaktliste hinzufügen zu können. Google GTalk ist beispielsweise kein öffentlich überprüfter XMPP-Dienst in Bezug auf Lync Server. Ein GTalk-Benutzer kann den Lync-Benutzer nicht als Kontakt hinzufügen, es sei denn, es wird eine explizite Einladung vom Lync-Benutzer gesendet.

  11. Hinweise zur Streamaushandlung 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 Schützen des XMPP-Datenstroms. Aus dem XMPP-Standarddokument XEP-0178 heißt es: "Gibt einen empfohlenen Protokollfluss für die Verwendung des SASL EXTERNAL-Mechanismus mit PKIX-Zertifikaten an, insbesondere wenn ein XMPP-Dienst angibt, dass TLS für die Aushandlung obligatorisch ist." PKIX bezieht sich, wie in der XSF-Dokumentation angegeben, auf eine Public Key-Infrastruktur, die auch als PKI bezeichnet wird.

    Weitere Informationen zu den XMPP-Anforderungen finden Sie im XSF-Dokument XEP-0178. Weitere Informationen finden Sie unter "XEP-0178: Best Practices for Use of SASL EXTERNAL with Certificates" (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-Aushandlung 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. Wenn Sie Optional auswählen, bleibt die Anforderung an den XMPP-Dienst für eine aushandlungspflichtige Entscheidung. Informationen zum Anzeigen aller möglichen Einstellungen und Details für SASL, TLS und Dialback-Aushandlung – einschließlich ungültiger und bekannter Fehlerkonfigurationen – finden Sie unter Aushandlungseinstellungen für XMPP-Verbundpartner in Lync Server 2013.


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


      • Optional. Der XMPP-Dienst gibt an, dass TLS für die Aushandlung obligatorisch 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. Wenn Sie Optional auswählen, bleibt die Anforderung an den Partner-XMPP-Dienst für eine aushandlungspflichtige Entscheidung.

      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 TLS-Unterstützung aufweisen. Wenn Sie tls nicht auf erforderlich oder optional festgelegt haben, wenn Sie auf Commit klicken, um Ihre Änderungen zu speichern, 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 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, welche Aushandlungsdatenströme für TLS und SASL oder Dienstunterbrechungen erforderlich sind.


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


      • Optional. Der XMPP-Dienst gibt an, dass SASL für die Aushandlung obligatorisch ist.


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

    • Dialback-Aushandlung. Die Rückrufverhandlung wird von der XSF im Dokument XEP-220 : Server Dialbackhttp://xmpp.org/extensions/xep-0220.html definiert. Der Serverrückwahlprozess verwendet das Domain Name System (DNS) und einen autoritativen Server, um zu überprüfen, ob die Anforderung von einem gültigen XMPP-Partner stammt. Dazu erstellt der ursprungsbasierte Server eine Nachricht eines bestimmten Typs mit einem generierten Rückrufschlüssel und sucht den empfangenden Server im DNS. Der Ursprungsserver sendet den Schlüssel in einem XML-Datenstrom an die resultierende DNS-Suche, vermutlich an den empfangenden Server. Beim Empfang des Schlüssels über den XML-Stream antwortet der empfangende Server nicht auf den Ursprungsserver, sondern sendet den Schlüssel an einen bekannten autoritativen Server. Der autoritative Server überprüft, ob der Schlüssel entweder gültig oder ungültig ist. Wenn dies nicht gültig ist, 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, dass die Identität und der Schlüssel gültig sind und die Konversation 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 sie ignoriert.