Microsoft Lync Server

¿Qué certificados necesitamos para Lync?

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (1 Comments)

En la fase de planificación de nuestra infraestructura, siempre hay un punto que hace referencia a los certificados que debemos adquirir. Debemos tener muchas cosas en cuenta, pero una básica son que servicios vamos a publicar y con que nombre. Todos sabéis que el nombre del certificado debe coincidir con el nombre del servicio a publicar, sino no funcinarán correctamente o directamente no funcionarán los distintos servicios. Seguro que en alguna ocasión habéis visto esta alerta en vuestro navegador.

En este caso el único problema que tenemos es que el servidor tiene asignado un certificado con un nombre diferente al que nosotros hemos tratado de conectarnos a través de nuestro navegador, y nos avisa de que podemos estar visitando un sitio diferente al que realmente queremos. O bien que estamos utilizando un certificado privado (emitido por nuestra CA en Windows) y no tenemos el certificado raiz instalado en nuestro equipo. Esto no quiere decir que el certificado no esté realizando su función que es la de cifrar el tráfico, pero el nombre que tiene no concuerda con el nombre de la URL que estamos visitando. De ahi que no es solo una cuestión puramente de seguridad, sino también de confianza. Si tenemos un servicio público al que se tienen que conectar nuestros clientes y les aparece esta advertencia, desde luego nuestra imagen como empresa quedaría por lo menos en entredicho. Además a día de hoy un certificado simple tiene un coste inferior a 80€ / año, por lo que no es una cuestión económica el no tener un certificado público.

Comentado esto, vamos a centrarnos en que debemos tener en cuenta a la hora de adquirir un certificado para nuestras implementaciones de Lync. Básicamente yo recomiendo siempre dos certificados: SAN y WILDCARD. Estos certificados serían para servicios diferentes, el certificado SAN para nuestros servidores EDGE y el Wildcard para nuestros Front-END y sus servicios Web. Como todos sabemos los nombres de los servicios que estamos publicando en el EDGE suelen ser los siguientes:

WEBCONF.ASIRSL.COM

AV.ASIRLAB.COM

SIP.ASIRLAB.COM

EDGE.ASIRSL.COM (opcional)

Esto son los nombres que debería tener nuestro certificado SAN (Subjet Alternate Name), de manera que podamos instalarlo en nuestros servidores EDGE y contengan el nombre de todos los servicios que vamos a publicar y en un solo certificado. Siempre estoy hablando de los certificados asignados a las interfaces externas, por lo que son certificados de una entidad certificadora pública (Verisign, Digicert, Thawte). Con esto tendríamos nuestro servidores/es EDGE correctamente configurados en cuanto al certificado se refiere, siempre y cuando los nombres de los certificados se correspondan con los nombres de los servicios (lo doy por hecho).

Ahora vamos a ver los certificados que necesitamos para el resto de servicios y que no pasan por el EDGE, sino por el Front-END o Director. En estos roles publicamos los distintos servicios con los siguientes nombres "por defecto":

lyncdiscover.asirlab.com

lync.asirlab.com o pool.asirlab.com (opcional según el nombre que hayamos configurado)

dialin.asirlab.com

meet.asirlab.com

Estos servicios se suelen publicar a través de un ISA Server, TMG o similar como reverse proxy, y es a ese servidor a cual le tenemos que instalar el certificado externo que adquiramos. El certificado que yo recomiendo siempre es un WILDCARD, porque os permitirá posteriormente utilizarlo para publicar más servicios que los de Lync, por ejemplo: OWA, SharePoint, CRM, WAC y cualquier otra URL del mismo dominio con el siguiente FQDN: loquesea.asirlab.com. De esta forma podéis aprovechar el certificado para publicar más servicios que exclusivamente los de Lync. Y si por ejemplo hoy publicais el meet.asirlab.com únicamente y dentro de 6 meses queréis tener disponible el dialin.asirlab.com o lyncdiscover.asirslab.com ya no tendréis que adquirir más certificados, de cualquier otra forma si. Aqui también podemos disponer de un certificado SAN, pero el coste del certificado con los 3 nombres obligatorios para el EDGE más los dos del Front-END tendrá un sobre coste superior a tener un WildCard y un SAN. Además de que para cada servicio completamente diferenciado es recomendable tener distintos certificados, pero eso ya es otro tema.

Ahora bien, si nuestra infraestructura cuenta con un TMG para publicar las distinas URL, yo recomiendo que el certificado que se instale a los servidores sea de vuestra Entidad Certificadora Privada, puesto que os permite solicitar tantos certificados como queráis sin tener que preocuparos por el coste. Si os olvidáis de algún nombre en la fase piloto, solo tenéis que volver a solicitarlo y no tendréis problema de costes económicos. Tened en cuenta que el TMG presentará en el certificado público al exterior pero hacia los servidores internos se conectará con el certificado interno, y que además el TMG al estar en el dominio ya tiene el certificado raiz de confianza instalado y no tendréis problemas con la publicación de cualquier servicio Web de Lync. Con el certificado Wildcard (*.asirlab.com) podéis publicar con el mismo listener de TMG más servicios como he comentado anteriormente. Esto también es aplicable al EDGE, en su interfaces interna puede tener tener un certificado de nuestra CA Privada y funciona sin problema.

Esto siempre y cuando tengáis un solo dominio SIP, si tenéis varios dominios SIP y queréis tener certificados públicos, el certificado debe contener todos los nombres FQDN de todos los dominios. Como he comentado yo recomiendo hacerlo de esta forma, es de las más económicas, permite la reutilización del certificado para otras publicaciones y nos permite publicar distintos servicios de Lync que inicialmente no lo habíamos hecho sin coste adicional. Todo esto tiene sus matices, pero es cuestión de tener claro que servicios vamos a publicar, que nombres tendrán esos servicios y como se van a publicar al exterior.

Si además implementamos los servicios de UM de Exchange, el certificado que debemos utilizar es también uno de nuestra Entidad Certificadora. Como nuestros servidores de Lync forman parte del dominio, no tendrán problemas con la validación del certificado que ambos se están presentando para la autenticación de servicios. El certificado del servidor Exchange para el ROL de UM debe tener como nombre común el nombre FQDN del servidor sino, no funcionará

Y por último para la integración del OWA con Lync, es más de lo mismo pero teniendo en cuenta algo muy sencillo. Cuando creemos nuestras aplicación de confianza el nombre debe ser el mismo que el nombre común que hemos configurado en el certificado asignado en Exchange para la integración con Lync

Sino es asi podréis encontraros de que todo está correctamente instalado, configurado y publicado pero … error!!! (esta captura representa uno de los posibles errores)

Como véis es muy sencillo, pero es cuestión de tener claras nuestras necesidades y el resto es aplicar el conocimiento que ya tenéis sobre Lync y Certificados. Si no queremos utilizar certificados públicos podemos hacer exactamente lo mismo con nuestra CA Privada, pero al resto de usuarios que no tengan las máquinas en nuestro dominio debemos pasarles nuestro Certificado Raiz para que lo instalen en el contenedor adecuado de sus equipos

Pero si queréis federar vuestro Lync con Microsoft, Google, etc.. debéis disponer de certificados públicos en vuestro EDGE. Si queréis federaros con otras compañias y no tenéis certificados públicos únicamente debéis "intercambiar" vuestras CA.

Aqui os muestro varias capturas de pantalla sobre un certificado WildCard conectándome a distintas URLs y otro SAN:

WildCard: nos conectamos a https://soporte.asirsl.com

WildCard: nos conectamos a https://meet.asirsl.com

SAN: Certificado de un EDGE con los nombres de los distintos servicios publicados

Para terminar este artículo comentaros los servicios que utilizan los distintos clientes de Lync:

Cliente Lync: EDGE

Lync Mobile: Front-END o Director Publicando las distintas URL via TMG u otro proxy

Lync Web APP: Front-END o Director Publicando las distintas URL via TMG y otro proxy

Precios de Certificados

WildCard	SAN

Aqui os dejos algunos interesantes:

Error de certificado cuando usamos Thawte

Windows Server 2012, Instalación de una CA

Creación de CSR para Lync de forma sencilla

Espero que os sea de utilidad!!!

Certificados, Lync

Lync Server: Renovación de Certificados y Alertas

marzo 24th, 2013 | Posted by Santiago Buitrago in Lync Server - (6 Comments)

Una de la cosas que debemos tener en cuenta son las renovaciones de los certificados de nuestros servidores de Lync, pero muchas veces nos enteramos de que tenemos que renovarlos el mismo día que el cliente nos alerta de que no se pueden conectar los usuarios. En ese momento nos conectamos a los servidores para tratar de analizar cual es el problema y … nos encontramos con el siguiente ID de Evento: 19022

Este evento se genera en el propio servidor en donde tenemos instalado Lync Server, y nos alerta de que en X días los certificados expirarán. Esto representa un gran problema sino estamos alertados con anterioridad de esta circunstancia, puesto en caso de no renovarlos antes de su expiración, los servicios de nuestros servidores no se iniciarían. La renovación de los certificados suele ser más o menos rápida, depende del proveedor que tengáis. También es cierto que todos los proveedores de certificados nos avisan entre 30 y 60 días antes de que expira el certificado, pero siempre lo harán al contacto que hemos habilitado en el momento de la compra del mismo. Si es vuestro cliente quien recibe la alerta y no os avisa, pues seguro que es muy probable que os encontréis con la situación en la que los certificados hayan expirado.

Desde luego esto tiene fácil solución, el problema es que al no haberlo previsto ahora los usuarios no se podrán conectar y ahí tenemos el verdadero problema. Si bien es cierto que los servidores deberían estar monitorizados vía SCOM o herramientas similares, pero claro está que no todos los clientes tienen este tipo de soluciones de monitorización. Yo quiero mostraros una solución casera y sin coste que seguro que os vendrá bien. Como el servidor nos alerta cada vez que queden menos de 10 días para expirar los certificados, vamos a ver como podemos crear un sistema de alerta sencillo y que nos avise por e-mail de que los certificados de uno de los servidores está a punto de expirar.

Yo utilizaré varias herramientas, por un lado una herramienta gratuita para enviar e-mails desde la línea de comandos como es SendEmail, esto nos permitirá alertanos vía e-mail con la información del evento. Lo que haré será crear una tarea programa de Windows que se ejecute cuando se produzca el evento 19022, y con PowerShell crearé un fichero de texto con la información del evento 19022. Ahora os detallo paso a paso como he configurado esta alerta, lo primero que he hecho es descargarme el SendEmail y crear una carpeta en C: con el nombre Send_Mail y en donde voy a colocar el SendMail y los dos scripts que voy a crear.

Lo primero es crear una script de PowerShell que nos permita identificar el evento 19022 y extraer sus descripición a un fichero de texto para posteriormente enviarlo por correo. Tenemos un cmdlet para analizar vía CLI los eventos del sistema: Get-WinEvent.

Este script lo que hace es buscar todos los eventos con el ID 19022 (id=19022) dentro de los registros de Lync Server (logname="Lync Server") creados en el mismo dia (StartTime=(Get-Date).date}) y luego enviará el resultado obtenido a un fichero de texto con el nombre CerExp.txt (lo creará automáticamente al ejecutarse el script) (>C:\Send_Email\CerExp.txt). Este script de PowerShell lo he guardado en la misma carpeta que tengo el SendMail y con el nombre Event_19022.ps1

Si lo ejecutamos el resultado sería el siguiente (he modificado el script para que mostrase el resultado que quiero, porque es un evento anterior a este artículo)

Ahora debemos configurar un proceso bat o cmd para ejecutar el sendmail, y enviar el fichero CerExp.txt como adjunto. Si ejecutamos el SendMail podemos ver la sintaxis del comando

Synopsis: sendEmail.exe -f ADDRESS [options]

Required:

-f ADDRESS from (sender) email address

* At least one recipient required via -t, -cc, or -bcc

* Message body required via -m, STDIN, or -o message-file=FILE

Common:

-t ADDRESS [ADDR …] to email address(es)

-u SUBJECT message subject

-m MESSAGE message body

-s SERVER[:PORT] smtp mail relay, default is localhost:25

Optional:

-a FILE [FILE …] file attachment(s)

-cc ADDRESS [ADDR …] cc email address(es)

-bcc ADDRESS [ADDR …] bcc email address(es)

-xu USERNAME username for SMTP authentication

-xp PASSWORD password for SMTP authentication

Paranormal:

-b BINDADDR[:PORT] local host bind address

-l LOGFILE log to the specified file

-v verbosity, use multiple times for greater effect

-q be quiet (i.e. no STDOUT output)

-o NAME=VALUE advanced options, for details try: –help misc

-o message-content-type=<auto|text|html>

-o message-file=FILE -o message-format=raw

-o message-header=HEADER -o message-charset=CHARSET

-o reply-to=ADDRESS -o timeout=SECONDS

-o username=USERNAME -o password=PASSWORD

-o tls=<auto|yes|no> -o fqdn=FQDN

Help:

–help the helpful overview you're reading now

–help addressing explain addressing and related options

–help message explain message body input and related options

–help networking explain -s, -b, etc

–help output explain logging and other output options

–help misc explain -o options, TLS, SMTP auth, and more

Yo lo único que he hecho es enviar el correo y especificar la dirección de origen, destino, servidor, asunto, cuerpo del mensaje y fichero adjunto:

Dirección de Origen: soporte@asirsl.com

Direeción de Destino: sbuitrago@asirsl.com

Asunto: Certificados a punto de expirar en el servidor EDGE de ASIR

Cuerpo: Los certificados configurados para el servicio de autenticacion de audio y video de LS están a punto de expirar, se adjunta un fichero la informacion del evento

Adjunto: CerExp.txt

sendEmail.exe -f soporte@asirsl.com -s smtp.asirsl.com:25 -t sbuitrago@asirsl.com -u "Certificados a punto de expirar en el servidor EDGE de ASIR" -m "Los certificados configurados para el servicio de autenticacion de audio y video de LS estan a punto de expirar, se adjunta un fichero la informacion del evento" -a CerExp.txt

Ahora lo único que debemos hacer es abrir un fichero de texto y copiar el siguiente código:

PowerShell -command .\Event_19022.ps1

sendEmail.exe -f soporte@asirsl.com -s smtp.asirsl.com:25 -t sbuitrago@asirsl.com -u "Certificados a punto de expirar en el servidor EDGE de ASIR" -m "Los certificados configurados para el servicio de autenticacion de audio y video de LS están a punto de expirar, se adjunta un fichero la informacion del evento" -a CerExp.txt

Guardamos el fichero como .BAT o .CMD con el nombre Send_Email_Certificados (o el nombre que queráis no es relevante) dentro de la carpeta Send_Email. Como todos los ficheros están la misma ubicación (c:\Send_Mail\) en el script no le indico ninguna ruta para lanzar el sendEmail.exe o Event_19022.ps1, en caso contrario debéis modificarlo según vuestra ínstalación. Como podéis observar en la raíz de la carpeta Send_Mail se encuentran todos los ficheros que necesitamos: sendEmail.exe, Event_19022.ps1 y Send_Mail_Certificados.bat

Lo normal es que antes de ponerlo en producción probemos que funciona correctamente, para ello ejecutamos el Send_Email_Certificados y debería realizar las siguientes tareas:

Crear o actualizar el fichero CerExp.txt con la descripción del evento 19022
Enviar un e-mail a la cuenta de destino sbuitrago@asirsl.com (el e-mail que le he indicado) con el fichero adjunto

Esperamos unos segundos y si todo ha funcionado correctamente debemos tener en nuestra bandeja de entrada el correo con el adjunto deseado

Ahora por último debemos crear una tarea programada para que ejecute el script Send_Mail_Certificados.bat. Abrimos el Programador de Tareas y creamos una tarea nueva

Escribimos el nombre de la tarea que vamos a crear

nos vamos a la pestaña desencadenadores para especificar cuando queremos que se ejecute esta tarea

como os había comentado antes, nos interesa que se ejecute cuando se registre el evento 19022, para ello elegimos las siguientes opciones y pulsamos en aceptar

ahora vamos a la pestaña acciones para indicarle que debe ejecutarse el script Send_Mail_Certificados.bat, para ello pulsamos en Nueva

Buscamos el script dentro de C:\Send_Mail y pulsamos en Aceptar

Configuramos que se ejecute la tarea tanto si está iniciada la sesión por parte del usuario que especifiquemos a continuación para que ejecute la tarea y pulsamos en Aceptar

Ahora nos solicita el usuario y contraseña con el cual queremos ejecutar dicha tarea, introducimos el usuario deseado y pulsamos en Aceptar

Ahora tenemos nuestro sistema de alertas, es bastante rudimentario pero sino contamos con presupuesto para adquirir ciertas herramientas profesionales seguro que será de gran ayuda. Ahora cada vez que el sistema registre el evento 19022 nos enviará un correo, y podremos enterarnos de que el certificado está a punto de caducar. Como os comentaba anteriormente de estas cosas ya se encarga el proveedor si es un certificado público, de lo contrario debéis tener anotado la fecha de expiración del certificado o bien utilizar algo similar a esto para que no se os olvide!!

Y ahora que tenemos la alerta creada, quedaría el segundo paso que sería renovar el certificado. En mi caso utilizo certificados de DigiCert, por lo que 60 días antes ya me están alertando de que tengo que renovarlo. Lo que tenemos que hacer es acceder a la Web de DigiCert y solicitar la renovación del certificado

Elegimos los años de validez del certificado, en mi caso en elegido 1 año. Por lo que al año siguiente debo realizar el mismo proceso que ahora os estoy describiendo. Además podemos especificar los nombres del certificado, en mi caso he cambiado uno nombre edgeocs.asirsl.com por edge.asirs.com (esto me obligará a crear de nuevo el CSR: Creación de CSR para Lync de forma sencilla)

Cubrimos los datos de contacto y le indicamos que los datos técnicos son los mismos que los datos de contacto, así evitamos tenemos que escribirlos de nuevo y pulsamos en Continue

Elegimos la forma de pago

ya tenemos nuestra orden de renovación en proceso, si tenemos que enviarleyo

Como os había comentado anteriormente he cambiado uno de los nombres del certificado, así que tengo que volver a crear el CSR (Creación de CSR para Lync de forma sencilla), y como tal DigiCert nos informa de ello (sino es imposible completar la solicitud de renovación)

Para hacerlo de forma rápida voy a utilizar la utilidad que DigiCert tiene a disposición de los clientes: Digicert Certificate Utility. Nos muestra los certificados del equipo y podemos pulsar directamente en Create CSR

Como tenía seleccionado uno de los certificados (además el que se corresponde con el certifidado que quiero renovar, pero podría ser cualquier otro) me indica si quiero importar los atributos de este certificado para la nueva solicitu y le indico que si.

De esta forma me cubrirá ya los datos en la nueva solicitud, y como os fijáis aun tengo el nombre edgeocs.asirsl.com

por lo que lo cambio por edge.asirsl.com y pulsamos en generate

ahora podemos pulsar en copiar o guardar el fichero, en función de si lo vamos a enviar ahora o más tarde debemos elegir una u otra opción

Yo lo voy a guardar para posteriormente continuar con la solicitud de renovación del certificado

Ahora abrimos de nuevo la solicitud del certificado en DigiCert y pulsamos en Submit CSR que es lo que tenemos pendiente por enviar al proveedor

seleccionamos el software de servidor en donde vamos a instalar el certificado y ahora pulsa mos en Upload a CSR (también podemos pegar el CSR si en la solicitud hubieramos pulsado en Copiar)

ahora pulsamos en Continue

y nos muestra el resumen de la solicitud, ahora toca esperar unos minutos hasta que se complete por parte de DigiCert.

Este proceso suele llevar entre 15 y 30 min, la verdad es que son muy rápidos y esto siempre es de agradecer. Si ahora nos vamos la página principal de nuestro panel podemos comprobar el estado de la solicitud

Una vez que se haya completadola solicitud del certificado debemos descargárnoslo

pulsamos en Download

Elegimos el tipo de certificado a descargar

ahora nos queda importalo, para ello volvemos a iniciar la utilidad de DigiCert y pulsamos en Import y seleccionamos el certicado que nos hemos descargado

Escribimos un nombre descriptivo para posteriormente reconocerlo a la hora de importarlo y pulsamos en Finalizar

Ahora ya tenemos nuestro certifidado renovado e importado en nuestro servidor de Lync (en mi caso en el EDGE)

Por último para completar todo el proceso únicamente nos queda asignarlo al EDGE, para ello ejecutamos el asistente de implementación de Lync y pulsamos en Instalar o actualizar el sistema Lync Server

Solicitar, instalar o asignar certificados

Seleccionamos los certificados de servidor perimetral y pulsamos en Asignar

No muestra la siguiente advertencia y pulsamos en Sí

pulsamos en siguiente

seleccionamos el certificado a importar y pulsamos en siguiente (yo me he colado y no he puesto el nombre descriptivo, pero por la fecha lo reconozco)

pulsamos en Siguiente

Una vez que haya finalizado la asignación del certificado nos volverá a la pantalla de Asistente para certifiados y podemos ver que ya lo tenemos asignado

Por último y muy importante sobre todo tratándose de un servidor perimetral debemos reiniciar los servicios de Lync para que actualice la asignación del nuevo certifidado sobre los distintos servicios del EDGE. Para automatizar este proceso podemos ejecutar los siguientes cmdlets: Start-CsWindowsService y Stop-CsWindowsService

Por último vamos a revisar el visor de eventos y verificar que todo ha iniciado sin problemas

Para verificar que todo funciona correctamente podéis iniciar sesión en Lync desde fuera de la organización y ver si os inicia sin problemas, y si tenéis alguna federación con otras compañías o sistemas de IM públicos verificad que todo está correcto.

Aqui os dejo como adjunto mi humilde script y demás ficheros por si los necesitáis

Send_Email_Scripts.zip

En mi caso el cambio de uno de los nombres del certificado no implica cambio alguno en la topología, puesto que lo utilizo para otros servicios fuera del AV, Webconf y Acceso. En el caso de que hubiese sido alguno de estos tres servicios si tendría que modificar la topología y volver a publicarla para que se replicase al EDGE.

Espero que os sea de utilidad!!!

Alerta, Certificados, Lync, Renovación

¿Qué certificados necesitamos para Lync?

Lync Server: Renovación de Certificados y Alertas

Santiago Buitrago

Entradas recientes

Comentarios recientes

Archivos

Categorías

Únete y comparte tu conocimiento

Sígueme en Twitter