Cerrar
InicioCertificadosMúltiples Dominios SIP en un tu Infraestructura de Lync-SkypefB On-Premises

Múltiples Dominios SIP en un tu Infraestructura de Lync-SkypefB On-Premises

Es posible que en alguna ocasión (o muchas) te hayas planteado la posibilidad de tener una topología de Lync/SkypefB que de soporte a múltiples dominios SIP, algo que, además, es muy habitual. Esto, para empezar, es algo que MSFT ha implementado en su versión Online (luego explicaré este concepto).

Empecemos por recordar que tener múltiples dominios en nuestras plataformas es algo muy común, por ejemplo, el correo electrónico.  En casi todas (o en muchas de ellas) las implementaciones de Exchange, solemos tener varios dominios configurados en él. Esto es algo que también podemos hacerlo en Lync/SkypefB, pero en vez de dominios para el correo, son dominios para SIP. Conceptualmente es lo mismo, pero uno es para correo y otro para IM/AV/WebConf. Aquí es donde algunos técnicos, le ven el primer problema, puesto que Lync/SkypefB “exige” ciertos requisitos en cuanto a la utilización de certificados se refiere (¿Qué certificados necesitamos para Lync?). Aquí es donde viene el problema, puesto que si pensamos que por cada dominio necesitamos una serie de certificados o un certificado con múltiples nombres (SAN), tendremos dos problemas:

Ambas limitaciones son importantes, pero es posible que nos “cueste” menos salvar la económica que la del límites de nombres que podemos tener en un certificado SAN. Sobre todo, porque queremos utilizar la topología en la que ya tenemos desplegado Lync/SkypefB, porque tendríamos que empezar a desplegar diferentes topologías, con todo lo que ello implica. Llegado a este punto, creo que deberíamos pensar en voz alta y reflexionar sobre esto:

¿ENTONCES COMO HACE MICROSOFT PARA OFRECERNOS SKYPE FOR BUSINESS ONLINE SIN NUESTRO DOMINIO EN SU CERTIFICADO?

Porque claramente no va a adquirir un certificado público para cada dominio SIP que tengan configurado en cada tenant, a parte de inviable en cuanto a topología (por tiempos y escalabilidad), tendría que cobrarnos un plus por el certificado que compraría para cada cliente y dominio SIP que queremos utilizar. Por el contrario, que es lo que hace? Pues básicamente lo que nos solicita, que configuremos nuestros registros DNS de tipo CNAME apuntando a sus servidores. Estos servidores si que tienen sus certificados, pero únicamente los nombres principales y que tiene en sus certificados. Dicho esto, repasemos los registros DNS que debemos crear para configurar nuestro dominio SIP en SkypefB On-Line: ¿Qué registros DNS debemos configurar para utilizar nuestro dominio SIP en Lync On-Line?

DNS-Externos-para-Lync-On-Line.jpg

MSFT de lo que se encarga “únicamente”, es de añadir el dominio SIP en su topología de SkypefB On-Line. Si lo hiciéramos nosotros, lo configuraríamos a nivel de topología y luego ya podríamos crear usuarios con ese dominio SIP:

Certificado_Multiples_Dominios_44

Aquí os dejo como se forman las URL para las reuniones de las en línea: DNS requirements for Skype for Business, puesto que los usuarios enviarán a los usuarios sus reuniones vía Outlook, la cual formará la URL en base a la configuración del servidor. En Microsoft, siempre se forman de la siguiente forma: https://meet.online.lync.com/tenant/usuario/código_reunión

Luego cuando vamos a habilitar un usuario en Skype, podemos elegir el dominio SIP asociado al usuario:

Certificado_Multiples_Dominios_45

Si nos fijamos en el certificado que utiliza MSFT, veremos que nombres tiene en sus certificados SAN. Vamos a comprobar por cada FQDN público de Skype, que nombres tienen sus certificados públicos (SAN y Wildcard):

  • sipdir.Online.Lync.com (Servicio de Acceso)

Certificado_Multiples_Dominios_MSFT_00 Certificado_Multiples_Dominios_MSFT_01

  • WebDir.Online.Lync.com (Servicios Web de SkypefB)

Certificado_Multiples_Dominios_MSFT_02 Certificado_Multiples_Dominios_MSFT_03

  • sipfed.Online.Lync.com (Servicio de Federación), como podéis ver es el mismo certificado utilizado para el servicio de acceso. Además, MSFT no da soporte al certificado wildcard como nombre de sujeto para el EDGE, pero si en el certificado SAN, mientras el nombre del sujeto sea un nombre único (el cual es el caso: sipfed.Online.Lync.com)

Certificado_Multiples_Dominios_MSFT_04 Certificado_Multiples_Dominios_MSFT_05

Aquí tenéis el KB de MSFT en donde nos dice explícitamente que no está soportado el certificado Wildcard para el EDGE en el nombre de sujeto:

The subject name of the certificate is the Access Edge service external interface fully qualified domain name (FQDN) or hardware load balancer VIP (for example, access.contoso.com). ). The subject name can’t have a wildcard character, it must be an explicit name.

Y aquí os dejo un artículo propio en donde explico la utilización de un certificado wildcard para el EDGE: Pon un Certificado Wildcard (Comodín) en tu Infraestructura IT.

Explicado todo esto, de ahí que MSFT nos indique de creemos registros DNS de tipo CNAME para conectarnos a nuestras cuentas de SkypefB On-Line:

Certificado_Multiples_Dominios_46

Una vez aclarado esto (creo o espero que sí), veamos realmente como se comporta un cliente de SkypefB cuando se conecta a los servidores de SkypefB Online. Para ello, he capturado algunas tramas con Wireshark, para ver que hace un cliente SkypefB al conectarse, desde la resolución DNS hasta los puertos y servicios que utiliza. En este artículo explico como se conecta un cliente Lync 2010/2014 a los servidores On-Premises, la idea es la misma únicamente que a los servidores Online: ¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?

Una vez que hayáis visto ese artículo, esta explicación será muy sencilla de entender. Las siguientes capturas mostrarán como un cliente SkypefB busca al servidor de SkypefB y como se conecta:

  • Lo primero es resolver de forma automática (para ello tenemos los registros DNS que tenemos que crear) los nombres de los servidores a los que queremos conectarnos, esto lo hará en base al nombre de dominio que hemos especificado en el inicio de sesión del cliente de Lync/Skype. Como podéis apreciar, se busca lyncdiscover.dominio.com y él resuelve el CNAME configurado, que es WebDir.Online.Lync.com.

Certificado_Multiples_Dominios_18

  • Se intenta conectar a WebDir.Online.Lync.com, pero previamente vía HTTP (si, si, HTTP no HTTPS) a HTTP://lyncdiscover.dominio.com y como sabéis luego ese servicio le indicará donde está el Servicio Web Externo del Pool de SkypefB al que nos tenemos que conectar para iniciar sesión. Esto es muy importante, porque si fuese HTTPS en la conexión al lyncdiscover.dominio.com es cuando al no tener el certificado con el nombre de nuestro dominio, nos encontraríamos con un error de certificado al conectarnos.

Certificado_Multiples_Dominios_37

Luego ya se conecta a los servicios Web vía 443, etc… pero como veis la conexión al lyncdiscover.dominio.com se hace al puerto 80, que tampoco es problema, puesto que no hay autenticación a ese nivel de servicio:Certificado_Multiples_Dominios_39

Como se puede apreciar, así es como funciona el inicio de Skype for Business en Online y así tenemos que hacerlo nosotros para On-Premises. Pero antes de esto, me gustaría comentaros algo “curioso” cuando nos conectamos a Skype for Business. MSFT siempre nos dice que nuestros datos residen en el centro regional donde le hemos indicado en al subscripción y es tal cual, pero los servicios de autenticación están  en otras ubicaciones (USA por ejemplo): Aquí os muestro una captura del wireshark con GEO habilitado, en donde podemos ver un inicio de sesión en el cliente de SkypefB desde España, comentar que se utiliza ADFS, de ahí que la conexión final nos venga de vuelta para solicitar la autenticación a nuestro ADFS:

Certificado_Multiples_Dominios_26

Vamos que los Front-END donde están nuestro usuarios están en Europa, pero parte de los servicios web están en USA. Bien porque estén allí directamente o porque nos lleven a un balanceador centralizado en USA, pero bueno, aquí cada uno que saque sus propias conclusiones y si hace alguna prueba más .. por favor, dejad un comentario en el blog.

Creo que a estas alturas del artículo, parece obvio lo que tenemos que hacer a nivel teórico para tener múltiples dominios SIP en nuestra topología On-Premises y sólo disponer de un certificado con los nombres del dominio SIP principal. Aquí os dejo un esquema que espero que sea representativo de lo que necesitáis para implementar este modelo de servicio:

Certificado_Multiples_Dominios_MSFT

Creo que ha quedado claro la configuración de registros DNS, puesto que únicamente tenemos que crear los registros DNS de tipo CNAME para que se conecte a los servicios Web y EDGE del SkypefB que tenemos. Como estos servicios tienen un certificado digital asociado, con el nombre del dominio principal y los registros DNS son CNAME apuntando a los registros DNS del dominio principal, nos conectará sin problemas y dar problemas de certificado. También es cierto, que todo esto es para que el cliente de SkypefB/Lync encuentre de forma automática los servidores (que es lo suyo), porque si los especificamos de manual en el cliente, también se conectará sin problemas. Si ahora, le damos una vuelta a este último comentario y lo asociamos a la creación de registros DNS de tipo CNAME … encontramos nuevamente la respuesta a la configuración DNS que debemos establecer y el porqué funciona.

Por último voy a comentar la configuración que debería tener la publicación de los servicios Web de Lync/SkypefB, porque me parece muy representativa. Los servicios web como bien sabemos, deberíamos publicarlos vía reverse-proxy:

Esto es más característicos de los clientes móviles, que obligatoriamente necesitan conectarse a dichos servicios, puesto que los clientes de escritorio, aunque lo utilizan también utilizan la conexión directa vía EDGE. Dicho esto, veamos que configuración debemos especificar en nuestro proxy (voy a utilizar el TMG porque me parece muy gráfico para estas cosas) para publicar los servicios web de dominios SIP que no están especificados en los certificados.

Si probamos desde un navegador de un equipo al acceso a HTTPS://lyncdiscover.dominioA.com y ese dominio no está en el certificado que tenemos configurado en el reverse-proxy, nos dará el siguiente error:

Certificado_Multiples_Dominios_00

Como si estamos en el navegador podemos darle a Continuar en esta página web (no recomendado), podremos avanzar, esto en el móvil sería imposible y nos daría un error de conexión. Si pulsamos en continuar y no tenemos ninguna regla configurada para ese nombre de dominio, pues el TMG nos mostrará el siguiente error:

Certificado_Multiples_Dominios_01

Lo que tenemos que hacer es lo siguiente, configurar el registro lyncdiscover.dominioX.com (para todos los dominios que no tengamos en el certificado instalado en el reverse-proxy), enviando la solicitud al Front-END o Pool:

Certificado_Multiples_Dominios_11 Certificado_Multiples_Dominios_12

Debemos especificar que el listener es un HTTP, si, en HTTP (está soportado por MSFT) y especificamos aquí los FQDN de los lyncdiscover.dominioX. com (escribimos todos los nombres aquí, puesto que la regla es la misma para todos)

Certificado_Multiples_Dominios_13 Certificado_Multiples_Dominios_14

Y especificamos el puerto interno al que enviaremos la conexión, y recordad, para el servicio web externo el puerto es el 8080

Certificado_Multiples_Dominios_15

Con esto ya tenemos una regla para que los clientes móviles (y de escritorio) se puedan conectar, porque buscar el registro lyncdiscover.domnioX.com primero en HTTP y luego en HTTPS, si la conexión en HTTP está configurada, se conectará al Front-END:

Certificado_Multiples_Dominios_09

Con esto, se le da acceso al lyncdiscover.dominioX.com donde se le llevará aun servicio JSON en donde no se indicar la URL del servicio web “real” a donde se deben conectar los dispositivos para iniciar sesión y consumir distintos servicios desde ahí:

Certificado_Multiples_Dominios_47

Como ese servicio web también lo tenemos publicado por el FQDN que SI está como dominio registrado en el certificado, la conexión funcionará sin problemas. Aquí es ve más claro, primero tira de lyncdiscover.dominioX.com …

Certificado_Multiples_Dominios_07

Y luego se envía la conexión al servicio web publicado ya en HTTPS:Certificado_Multiples_Dominios_08

Como veis es muy sencillo, es cuestión de ajustar los registros DNS en base a CNAME (casi todos) y luego configurar nuestro reverse-proxy para que publique vía HTTP las peticiones del lyncdiscover.dominioX.com y la envíe al Front-END o Pool al puerto 8080. Y una vez que acceder al lyncdiscover.dominioX.com vía JSON se le envía al HTTPS://serviciowebexterno.dominio.com y ahí se autenticará sin problema.

Los registros DNS de tipo SRV son para que los clientes que no se puedan conectar vía lyncdiscover.dominioX.com lo hagan directamente al EDGE (esto ocurre para los clientes NO móviles). Aquí os dejo una captura escenificando como se conecta un cliente móvil y desktop que no tiene su dominio SIP configurado en el certificado:

Certificado_Multiples_Dominios_55Por último nos quedarían las federaciones, esto es algo que ocurre entre servidores EDGE, por lo que es muy sencilla su configuración. Básicamente es crear los registros DNS de tipo SRV apuntando todos hacia el FQDN del servicio de acceso del nombre que está asociado al certificado que tiene el EDGE configurado. Aquí muestro la configuración de los registros DNS de los diferentes dominios que tenemos configurados, el que está asociado en el certificado y los dominios que no lo están. Los que no lo están, el srv hostname tienen configurados el FQDN del dominio principal que sí está asociado en el certificado:

Certificado_Multiples_Dominios_56

Con esto hemos finalizado la configuración, como resumen final:

  • Creación de registros DNS de tipo CNAME para los servicios Web (obligatorio para los clientes de móvil)
  • Creación de registros DNS de tipo SRV: para el descubrimiento automático de los servidores de acceso y para las federaciones
  • Publicar  en el reverse-proxy las URL de lyncdiscover.dominioX.com en HTTP

Espero que haya quedado más o menos claro, porque ha costado buscar la forma de explicarlo. Yo lo veo muy claro, pero entiendo que será porque en mi cabeza lo tengo claro. Creo que es cuestión de analizar como lo hace MSFT y como funciona, a partir de ahí .. es cuestión de configurar nuestro entorno en base a ese criterio.
Por favor, si alguien no lo tiene claro o he dejado algo sin explicar o no todo lo bien que debería, por favor, dejar un comentario y lo comentamos!!

Operadores Automáti
Skype for Business O
NO HAY COMENTARIOS

Ningún comentario en este momento.

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This