Créer ou modifier une configuration de partenaire XMPP dans Lync Server 2013
Rubrique Dernière modification : 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 qui est 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 d’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, consultez Les outils d’administration d’Open 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 configuration, 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 des 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 répertoriez tous les autres domaines sous fabrikam.com avec lesquels vous communiquerez via 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 principal 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 public vérifié est lorsque les contacts qui font partie d’un déploiement vérifié par le fournisseur peuvent être ajoutés à la liste des contacts de votre utilisateur. Les invitations peuvent être envoyées par l’utilisateur Lync ou l’utilisateur Lync peut accepter les invitations du contact partenaire.
Public non vérifié. Une relation non vérifiée publique implique qu’il n’existe aucun état établi et vérifiable entre les deux déploiements. Un utilisateur Lync doit inviter le contact non vérifié pour ce contact à 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 l’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. Dans le document XEP-0178 des normes XMPP, « spécifie un flux de protocole recommandé pour l’utilisation du mécanisme EXTERNAL SASL avec des certificats PKIX, en particulier lorsqu’un service XMPP indique que le protocole 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 XEP-0178 XSF pour plus d’informations sur les exigences XMPP. Pour plus d’informations, reportez-vous à « XEP-0178: Best Practices for Use of SASL EXTERNAL with Certificates ». http://xmpp.org/extensions/xep-0178.html
Reportez-vous au document IETF « Extensible Messaging and Presence Protocol (XMPP): Core », section 5.0, NÉGOCIATION https://tools.ietf.org/html/rfc6120STARTTLS .
Négociation TLS. Définit les règles de négociation TLS. Un service XMPP peut exiger TLS, peut rendre TLS facultatif ou vous définissez que TLS n’est pas pris en charge. Le choix de l’option laisse au service XMPP la condition requise pour une décision de négociation obligatoire. 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 les 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 à négocier.
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 avoir besoin de SASL, peut rendre SASL facultatif ou vous définissez que SASL n’est pas pris en charge. Le choix facultatif laisse au service XMPP partenaire la condition requise pour une décision de négociation obligatoire.
Avertissement
SASL requiert TLS. Pour utiliser SASL, TLS doit être obligatoire ou facultatif. Toute configuration qui définit SASL comme obligatoire ou facultative doit avoir la prise en charge de 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 avoir la prise en charge de 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 prise en charge. Vérifiez auprès du service XMPP quels sont les flux de négociation appropriés pour TLS et l’interruption de service ou SASL se produit.
Obligatoire. Le service XMPP nécessite une négociation SASL.
Facultatif. Le service XMPP indique que SASL est obligatoire pour 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 le fichier XSF dans le document XEP-220 : Numérotation duhttp://xmpp.org/extensions/xep-0220.html serveur. 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 résultante, probablement le serveur de réception. À la réception de la clé sur le flux XML, le serveur de réception 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 valide. S’il n’est pas valide, le serveur de réception 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 dialback :
C’est vrai. Le serveur XMPP est configuré pour utiliser la négociation dialback si une demande doit être reçue d’un serveur d’origine
Faux. Le serveur XMPP n’est pas configuré pour utiliser la négociation dialback et, si une demande doit être reçue d’un serveur d’origine, elle est ignorée.