Voy a empezar este artículo con una pregunta: ¿Se pueden federar múltiples dominios SIP con un único certificado SAN (dominio único) en nuestro EDGE? Pues la respuesta es ……. SIII!!!

Este suele ser un esquema muy común de una implementación de Lync On Premise con federaciones con IM Públicos, Office 365 y On Premise.

por último necesitamos crear el siguiente registro DNS de tipo SRV obligatorio:

Con estas configuraciones tendríamos  completadas ambas federaciones con nuestro dominio SIP, ahora bien, que ocurre si queremos que nuestro Lync server administre más de un dominio SIP y no queremos invertir en más certificados, aquí os muestro los pasos a seguir para poder configurarlo:

1. Configurar dominios adicionales en el generador de topologías de Lync Server

Una vez añadidos los dominios SIP adicionales, automáticamente se crearán las direcciones simples para las reuniones online: https://meet.dominiosip.xxx de cada dominio.

2. Creación en el dominio de los sufijos UPN de los nuevos dominios SIP para asignar posteriormente a los usuarios creados en el Active Directory, de tal forma que su dirección SIP en Lync coincida con su nombre de usuario en el Active Directory

3. Creamos los usuarios en el Directorio Activo y le asignamos el sufijo UPN creado para su dominio

4. Habilitamos el usuario en Lync y como dirección SIP elegimos la opción de Use the user principal name (UPN)

5. Configurar los nombres de dominio que hemos añadido en los certificados de los Front-END. Esto es opcional si queremos utilizar únicamente Lync desde fuera de la organización.

6. Federaciones: ahora viene lo  más interesante, la posibilidad de federar los nuevos dominios SIP utilizando únicamente el certificado que tenemos para nuestro dominio principal, en mi caso ASIRSL.COM. Voy a mostraros los pasos a seguir en función del tipo de federación:

Federación con MSFT: Necesitamos crear un registro DNS de tipo SRV para el nuevo dominio de la siguiente forma, utilizaremos el dominio traimer.es como ejemplo:

_sipfederationtls._tcp.traimer.es       SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = sip.asirsl.com

Como podéis ve, lo que hacemos es especificar que el srv hostname sea el EDGE que tenemos para el dominio ASIRSL.COM, de tal forma que le presentará el certificado que ya tiene asignado. El  certificado es un de una CA Pública por lo que no le generará error alguno para poder validarlo, y se puede utilizar sin problema. Cuando los servidores de MSFT traten de resolver el registro _sipfederationtls._tcp.traimer.es se conectarán a nuestro EDGE y en función de nuestra configuración se permitirá o no la federación con MSFT. Por supuesto debemos previamente solicitar la federación a MSFT del nuevo dominio (traimer.es), para ello debemos acceder a Microsoft Lync Server Public IM Connectivity Provisioning y añadir el nuevo dominio traimer.es utilizando el mismo Access Edge Server que ya tenemos para el dominio ASIRSL.COM

Una vez que hayamos actualizado la configuración de la federación con MSFT, en unos días nos llegará un correo similar a este confirmado la federación, por lo que tendremos que probarla

Ahora iniciamos el cliente de Lync con una cuenta del dominio traimer.es y tratamos de contactar con un usuario de Skype (migrado de MSN)

Como vemos funciona perfectamente, podemos ver la presencia desde ambos clientes de mensajería, mantener conversaciones de IM y Audio.

Federación con Google: Para federarnos con sistemas XMPP y en este caso con Google para utilizar GTalk  es más sencillo todavía, debemos crear el siguiente registro DNS de tipo SRV:

_xmpp-server._tcp.traimer.es   SRV service location:
          priority       = 1
          weight         = 100
          port           = 5269
          svr hostname   = sip.asirsl.com

Como podéis apreciar el srv hostname sigue siendo el mismo!!! Ahora solo toca agregarnos mutuamente como contactos en GMAIL y Lync para completar la "federación". Una vez completados estos pasos, ya podemos ver la disponibilidad de los usuarios de GMAIL

Federación con otro Lync Server On Premise: Esta es la federación más sencilla y habitual, podemos hacerlo de dos formas o bien de forma explícita añadiendo el dominio desde la opción de dominio federado y poniendo como  Servicio perimetral de Acceso el FQDN del EDGE de ASIRSL.COM que es quien tiene el certificados público.

Y como previamente ya teníamos creado el registro SRV para la federación con MSFT, solo debemos asegurarnos de que nuestro servidor lo tenemos habilitado para el descubrimiento del partner federado si queremos configurar la federación de esta forma

_sipfederationtls._tcp.traimer.es       SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = sip.asirsl.com

Ahora agregamos desde nuestra cuenta de Lync un nuevo usuario de Lync buscándolo por su dirección SIP y ya podremos ver su presencia y utilizar todas las funcionalidades habilitadas mediante este tipo de federación

Federación con Office 365: solo debemos agregar como dominio permitido para la federación al dominio traimer.es y mediante la resolución de nombres de dominio (otra vez el registro SRV (_sipfederationtls._tcp.traimer.es) podremos completar la federación.

Como vemos podemos utilizar un único certificado (para un solo dominio: asirsl.com) público para federarnos con otros sistemas de IM Público, Lync o XMPP. Y si queremos utilizar la autoconfiguración del cliente para que los usuarios del nuevo dominio SIP no tengan que configurar el cliente, debemos crear el siguiente registro DNS de tipo SRV:

_sip._tls.traimer.es   SRV service location:
          priority       = 1
          weight         = 100
          port           = 443
          svr hostname   = sip.asirsl.com

Como siempre el srv hostname será el FQDN de EDGE que tiene el certificado público, y con esto más que suficiente para iniciar sesión sin configurar el cliente. Ahora bien, si queremos utilizar los distintos servicios Web de Lync o Exchange (Mobile en Autodiscover, ABS, EWS) sí que vamos a necesitar un certificado SAN con todos los nombres de dominio, de tal forma que el navegador o app no os muestre el típico error de certificado inválido porque el nombre del certificado no coincide con el nombre del sitio. Pero ahí, lo suyo siempre es tener un certificado SAN con los nombres alternativos de los otros dominios, pero del tipo wildcard (ejemplo: *.traimer.es, *.asirsl.com).

Aquí os dejo un artículo que había escrito en su momento sobre los certificados que se necesitaban para una implementación básica de Lync: ¿Qué certificados necesitamos para Lync? También comentaros que en las conferencias no tendréis problemas con el certificado del dominio ASIRSL.COM para compartir las presentaciones de PowerPoint , puesto que si el certificado es público no tendréis problemas por conectaros a la URL del WAC (ejemplo: office.asirsl.com). Puesto que como no se visualiza "nunca" la URL a la que se conecta desde el cliente Lync o el Lync Web App "nadie" sabrá que certificado se está utilizando. Pero aquí lo importantes es que se conecten de forma transparente sin que os alerta de alguna forma, y esto es viable con el certificado que utilicemos del dominio ASIRSL.COM en nuestro proxy inverso.

Os recuerdo que siempre he comentado que esta configuración es para las conexiones que se realicen desde fuera de la zona de seguridad de la empresa, siempre que lo hagamos desde dentro de la organización y utilicemos certificados emitidos por nuestra CA debemos realizar ciertas modificaciones (esto lo dejamos para otro artículo)

Ahora sí que doy por cerrado este artículo 🙂

Espero que os sea de utilidad!!!