Créer ou modifier une configuration de partenaire XMPP dans Lync Server 2013
Dernière modification de la rubrique : 2014-09-03
Microsoft Lync Server 2013 intègre un proxy XMPP (Extensible Messaging and Presence Protocol) sur le serveur Edge et une passerelle XMPP sur le serveur frontal ou le pool frontal. Pour autoriser les connexions à partir d’autres déploiements XMPP, vous devez configurer XMPP dans le Panneau de configuration Lync Server. Vous configurez les paramètres sur une base de domaine XMPP. Pour créer une association de partenaires, procédez comme suit :
Pour créer un partenaire fédéré ou modifier une configuration existante
À partir d’un compte d’utilisateur membre du groupe RTCUniversalServerAdmins (ou disposant de droits d’utilisateur équivalents), ou affecté au rôle CsAdministrator, connectez-vous à n’importe quel ordinateur de votre déploiement interne.
Ouvrez une fenêtre de navigateur, puis entrez l’URL Administration pour ouvrir le Panneau de configuration Lync Server. Pour plus d’informations sur les différentes méthodes que vous pouvez utiliser pour démarrer Lync Server Panneau de configuration, voir Ouvrir les outils d’administration Lync Server 2013.
Dans la barre de navigation de gauche, cliquez sur Fédération et accès externe, puis sur Partenaires fédérés XMPP.
Pour créer une configuration, cliquez sur Nouveau
Pour modifier une configuration existante, sélectionnez-la, puis cliquez sur Modifier
Pour créer ou modifier des configurations pour les partenaires fédérés XMPP, vous définissez les paramètres suivants :
Domaine principal (obligatoire). Le domaine principal est le domaine de base du partenaire XMPP. Par exemple, vous devez entrer fabrikam.com pour le nom de domaine du partenaire XMPP. Il s’agit d’une entrée obligatoire.
Description. La description concerne les notes ou d’autres informations d’identification pour cette configuration particulière. Cette entrée est facultative.
Domaines supplémentaires. Les domaines supplémentaires sont des domaines qui font partie du domaine de votre partenaire XMPP qui doivent être inclus dans le cadre de la communication XMPP autorisée. Par exemple, si le domaine principal est fabrikam.com, vous devez répertorier tous les autres domaines qui sont sous fabrikam.com avec lesquels vous allez communiquer par le biais de XMPP. Par exemple, vous pouvez entrer corp.fabrikam.com et it.fabrikam.com pour le domaine XMPP d’entreprise et le domaine XMPP des technologies de l’information sous le domaine XMPP main de fabrikam.com.
Type de partenaire. Le type partenaire est un paramètre obligatoire et vous offre une sélection de trois choix dans un menu déroulant. Vous devez choisir l’une des options suivantes pour décrire et appliquer les contacts qui peuvent être ajoutés. Vous pouvez sélectionner parmi :
Fédéré. Un type de partenaire fédéré est une connexion approuvée entre un déploiement de partenaire Lync Server ou Office Communications Server 2007 R2.
Public vérifié. Un partenaire vérifié public est lorsque les contacts qui font partie d’un déploiement vérifié par le fournisseur peuvent être ajoutés à la liste de contacts de votre utilisateur. Les invitations peuvent être envoyées à partir de l’utilisateur Lync ou l’utilisateur Lync peut accepter les invitations du contact partenaire.
Public non vérifié. Une relation publique non vérifiée implique qu’il n’existe aucune status établie et vérifiable entre les deux déploiements. Un utilisateur Lync doit inviter le contact non vérifié pour ce contact pour pouvoir ajouter l’utilisateur Lync à sa liste de contacts. Par exemple, Google GTalk n’est pas un service XMPP vérifié public en ce qui concerne Lync Server. Un utilisateur GTalk ne peut pas ajouter l’utilisateur Lync en tant que contact, sauf s’il y a une invitation explicite envoyée par l’utilisateur Lync.
Remarques sur la négociation de flux et les méthodes de sécurité TLS (Transport Layer Security) et SASL (Software Authentication and Security Layer) :
XMPP Standards Foundation (XSF) et Internet Engineering Task Force (IETF) définissent un ensemble de règles et de normes pour l’utilisation et la gestion des certificats clients TLS, des certificats de serveur TLS et du mécanisme SASL. L’utilisation de TLS et SASL est le processus requis pour sécuriser le flux XMPP. D’après le document XMPP Standards XEP-0178, « spécifie un flux de protocole recommandé pour l’utilisation du mécanisme SASL EXTERNAL avec des certificats PKIX, en particulier lorsqu’un service XMPP indique que TLS est obligatoire à négocier ». PKIX, comme indiqué dans la documentation XSF, fait référence à l’infrastructure à clé publique, également appelée PKI.
Reportez-vous au document XSF XEP-0178 pour plus d’informations sur la configuration requise pour XMPP. Pour plus d’informations, reportez-vous à « XEP-0178 : Meilleures pratiques pour l’utilisation de SASL EXTERNAL avec des certificats ». http://xmpp.org/extensions/xep-0178.html
Reportez-vous au document IETF « Extensible Messaging and Presence Protocol (XMPP) : Core », Section 5.0, STARTTLS Negotiation https://tools.ietf.org/html/rfc6120.
Négociation TLS. Définit les règles de négociation TLS. Un service XMPP peut nécessiter TLS, peut rendre TLS facultatif, ou vous définissez que TLS n’est pas pris en charge. Choisir Facultatif laisse la nécessité au service XMPP pour une décision obligatoire de négociation. Pour afficher tous les paramètres et détails possibles pour la négociation SASL, TLS et dialback, y compris les configurations d’erreur non valides et connues, consultez Paramètres de négociation pour les partenaires fédérés XMPP dans Lync Server 2013.
Obligatoire. Le service XMPP nécessite une négociation TLS.
Facultatif. Le service XMPP indique que TLS est obligatoire pour la négociation.
Non pris en charge. Le service XMPP ne prend pas en charge TLS.
Négociation SASL. Définit les règles de négociation SASL. Un service XMPP peut nécessiter UNE SASL, peut rendre SASL facultatif ou vous définissez que SASL n’est pas pris en charge. Choisir Facultatif laisse au service XMPP partenaire l’exigence d’une décision obligatoire de négociation.
Avertissement
SASL nécessite TLS. Pour utiliser SASL, TLS doit être obligatoire ou facultatif. Toute configuration qui définit SASL comme obligatoire ou facultative doit prendre en charge TLS. Lorsque vous cliquez sur Valider pour enregistrer vos modifications, si vous n’avez pas défini TLS sur obligatoire ou facultatif, vous serez averti que SASL doit prendre en charge TLS et que vos modifications ne sont pas enregistrées. Pour résoudre l’erreur, définissez TLS sur Obligatoire ou Facultatif. Si l’utilisation de SASL est facultative et que la prise en charge de la négociation TLS n’est pas possible, vous devez définir la négociation SASL sur Non pris en charge. Vérifiez auprès du service XMPP ce que les flux de négociation appropriés doivent être pour TLS et SASL ou une interruption de service se produit.
Obligatoire. Le service XMPP nécessite une négociation SASL.
Facultatif. Le service XMPP indique que SASL est obligatoire à négocier.
Non pris en charge. Le service XMPP ne prend pas en charge SASL.
Négociation de numérotation. La négociation de numérotation est définie par XSF dans le document XEP-220 : Server Dialbackhttp://xmpp.org/extensions/xep-0220.html. Le processus de numérotation du serveur utilise le système de noms de domaine (DNS) et un serveur faisant autorité pour vérifier que la demande provient d’un partenaire XMPP valide. Pour ce faire, le serveur d’origine crée un message d’un type spécifique avec une clé de numérotation générée et recherche le serveur de réception dans DNS. Le serveur d’origine envoie la clé dans un flux XML à la recherche DNS obtenue, probablement le serveur de réception. À la réception de la clé sur le flux XML, le serveur récepteur ne répond pas au serveur d’origine, mais envoie la clé à un serveur faisant autorité connu. Le serveur faisant autorité vérifie que la clé est valide ou non. S’il n’est pas valide, le serveur récepteur ne répond pas au serveur d’origine. Si la clé est valide, le serveur de réception informe le serveur d’origine que l’identité et la clé sont valides et que la conversation peut commencer.
Il existe deux états valides pour la négociation de numérotation :
True. Le serveur XMPP est configuré pour utiliser la négociation de numérotation si une requête doit être reçue d’un serveur d’origine
False. Le serveur XMPP n’est pas configuré pour utiliser la négociation de numérotation et si une demande doit être reçue d’un serveur d’origine, elle sera ignorée