Crear o editar la configuración de socios de XMPP en Lync Server 2013
Última modificación del tema: 2014-09-03
Microsoft Lync Server 2013 integra un proxy de Protocolo de mensajería y presencia extensible (XMPP) en el servidor perimetral y una puerta de enlace XMPP en el servidor front-end o el grupo de servidores front-end. Para permitir conexiones desde otras implementaciones de XMPP, debe configurar XMPP en el Panel de control de Lync Server. Las opciones se configuran en base a un dominio XMPP. Para crear una nueva asociación de partner, haga lo siguiente:
Para crear un nuevo partner federado o editar una configuración existente
Desde una cuenta de usuario que sea miembro del grupo RTCUniversalServerAdmins (o que tenga derechos de usuario equivalentes), o esté asignada al rol CsAdministrator, inicie sesión en cualquier equipo en la implementación interna.
Abra una ventana del explorador y, a continuación, escriba la dirección URL del Administración para abrir la Panel de control de Lync Server. Para obtener más información sobre los diferentes métodos que puede usar para iniciar Lync Server Panel de control, vea Abrir herramientas administrativas de Lync Server 2013.
En la barra de navegación izquierda, haga clic en Federación y acceso externo y, a continuación, haga clic en Socios federados XMPP.
Para crear una nueva configuración, haga clic en Nuevo
Para editar una configuración existente, seleccione la configuración y haga clic en Editar
Para crear o editar configuraciones para socios federados XMPP, defina las siguientes opciones:
Dominio principal (obligatorio). El dominio principal es el dominio base del partner XMPP. Por ejemplo, escriba fabrikam.com para el nombre de dominio del partner XMPP. Esta es una entrada obligatoria.
Descripción. La descripción es para notas u otra información identificativa para esta configuración concreta. Esta entrada es opcional.
Dominios adicionales. Los dominios adicionales son dominios que forman parte del dominio de su partner XMPP que se debe incluir como parte de la comunicación XMPP permitida. Por ejemplo, si el dominio principal está fabrikam.com, enumería todos los demás dominios que están en fabrikam.com con los que se comunicará mediante XMPP. Por ejemplo, puede escribir corp.fabrikam.com y it.fabrikam.com para el dominio XMPP corporativo y el dominio XMPP de Information Technologies en el dominio XMPP principal de fabrikam.com.
Tipo de partner. El tipo de partner es una configuración obligatoria y te ofrece una selección de tres opciones en un menú desplegable. Debe elegir una de las siguientes opciones para describir y exigir qué contactos se pueden agregar. Puede seleccionar entre:
Federado. Un tipo de partner federado es una conexión de confianza entre una implementación de partner de Lync Server u Office Communications Server 2007 R2.
Verificada públicamente. Un partner comprobado público es cuando los contactos que forman parte de una implementación verificada por el proveedor se pueden agregar a la lista de contactos del usuario. Las invitaciones se pueden enviar desde el usuario de Lync o el usuario de Lync puede aceptar invitaciones del contacto del partner.
Público sin verificación. Una relación pública sin comprobar implica que no hay ningún estado establecido y verificable entre las dos implementaciones. Un usuario de Lync debe invitar al contacto no comprobado para que pueda agregar el usuario de Lync a su lista de contactos. Por ejemplo, Google GTalk no es un servicio XMPP comprobado público en lo que respecta a Lync Server. Un usuario de GTalk no podrá agregar el usuario de Lync como contacto a menos que haya una invitación explícita enviada desde el usuario de Lync.
Notas sobre la negociación del flujo y los métodos de seguridad Seguridad de la capa de transporte (TLS) y la Capa de seguridad y autenticación de software (SASL):
Xmpp Standards Foundation (XSF) y el Grupo de tareas de ingeniería de Internet (IETF) definen un conjunto de reglas y estándares para usar y administrar certificados de cliente TLS, certificados de servidor TLS y el mecanismo SASL. El uso de TLS y SASL es el proceso necesario para proteger la transmisión xmpp. A partir del documento de estándares XMPP XEP-0178, "especifica un flujo de protocolo recomendado para el uso del mecanismo EXTERNO DE SASL con certificados PKIX, especialmente cuando un servicio XMPP indica que TLS es obligatorio para negociar". PKIX, como se indica en la documentación de XSF, se refiere a la infraestructura de clave pública, también conocida como PKI.
Refiera al documento XSF XEP-0178 para más detalles sobre los requisitos xmpp. Para obtener más información, consulte "XEP-0178: Procedimientos recomendados para el uso de SASL EXTERNO con certificados". http://xmpp.org/extensions/xep-0178.html
Consulte el documento de IETF "Protocolo de mensajería y presencia extensible (XMPP): Core", Sección 5.0, Negociación https://tools.ietf.org/html/rfc6120STARTTLS.
Negociación tls. Define las reglas de negociación de TLS. Un servicio XMPP puede requerir TLS, puede hacer que TLS sea opcional o definir que TLS no es compatible. La elección opcional deja el requisito hasta el servicio XMPP para una decisión de negociación obligatoria. Para ver todas las configuraciones y detalles posibles de SASL, TLS y negociación de devolución de marcado, incluidas las configuraciones de errores no válidos y conocidos, consulte Configuración de negociación para partners federados XMPP en Lync Server 2013.
Necesario. El servicio XMPP requiere negociación de TLS.
Opcional. El servicio XMPP indica que TLS es obligatorio para negociar.
No compatible. El servicio XMPP no admite TLS.
Negociación SASL. Define las reglas de negociación SASL. Un servicio XMPP puede requerir SASL, hacer que SASL sea opcional o definir que SASL no es compatible. La elección opcional deja el requisito del servicio XMPP del partner para una decisión de negociación obligatoria.
Advertencia
SASL requiere TLS. Para usar SASL, TLS debe ser obligatorio u opcional. Cualquier configuración que defina SASL como obligatoria u opcional debe tener compatibilidad con TLS. Al hacer clic en Confirmar para guardar los cambios, si no ha configurado TLS como obligatorio u opcional, se le advertirá de que SASL debe tener compatibilidad con TLS y los cambios no se guardan. Para resolver el error, establezca TLS en Obligatorio u Opcional. Si el uso de SASL es opcional y no es posible el soporte de negociación de TLS, debe establecer la negociación SASL en No compatible. Confirme con el servicio XMPP cuáles deben ser las secuencias de negociación adecuadas para TLS y SASL o se producirá una interrupción del servicio.
Necesario. El servicio XMPP requiere negociación SASL.
Opcional. El servicio XMPP indica que SASL es obligatorio para negociar.
No compatible. El servicio XMPP no admite SASL.
Negociación de devolución de marcado. La negociación del dialback es definida por el XSF en el documento XEP-220 : Server Dialbackhttp://xmpp.org/extensions/xep-0220.html. El proceso de devolución de acceso telefónico del servidor utiliza el sistema de nombres de dominio (DNS) y un servidor autoritativo para verificar que la solicitud proviene de un socio XMPP válido. Para ello, el servidor de origen crea un mensaje de un tipo específico con una clave de devolución de marcado generada y busca el servidor receptor en DNS. El servidor de origen envía la clave en una secuencia XML a la búsqueda DNS resultante, presumiblemente el servidor de recepción. Al recibir la clave sobre la transmisión XML, el servidor de recepción no responde al servidor de origen, sino que envía la clave a un servidor autoritativo conocido. El servidor autoritativo comprueba que la clave sea válida o no válida. Si no es válido, el servidor de recepción no responde al servidor de origen. Si la clave es válida, el servidor de recepción informa al servidor de origen de que la identidad y la clave son válidas y la conversación puede comenzar.
Hay dos estados válidos para la negociación de devolución de marcado:
Es verdad. El servidor XMPP se configura para utilizar la negociación de devolución de marcado si se debe recibir una solicitud de un servidor de origen
Falso. El servidor XMPP no está configurado para utilizar la negociación de devolución de marcado y, si se debe recibir una solicitud de un servidor de origen, se ignorará