Microsoft Lync Server
Header

Esta es una de las fases sino más importante, si la que muchas empresas temen .. sobre todo cuando no se tienen claro muchos conceptos sobre su Directorio Activo. Siempre que instalamos Lync o Skype For Businesss por primera vez, tenemos que preparar el Directorio Activo ​Instalación Skype For Business 2015_Instalacion_5.png

El proceso para nosotros es un paso trivial, simplemente iniciamos el Asistente de instalación y ejecutamos las opción de preparación de Directorio Activo (imagen de MSFT)

IC792005.png

Aquí tenéis los cambios que se realizan en el Directorio Activo con Lync Server 2013

De momento poco he visto sobre que cambios hará en el esquema la instalación de Skype For Business, pero por lo visto no hará más cambios que Lync 2013. Si actualizamos de Lync 2013 a Skype For Business al parecer no hay cambios en el Active Directory, solo cuando se instala porprimera vez y hará los mismos cambios que Lync.

 

Nota: El proceso no ha variado en absoluto de lo que hacíamos con Lync, , además de que si actualizamos no actualizará nuestro Directorio Activo.

La revocación de un certificado es anular su validez, además desde el mismo momento en que es revocado. Este proceso es muy común cuando se ha comprometido la seguiridad del certificado, y creemos que alguien conoce las claves privadas del mismo. O también porque queremos simplemente darlo de baja porque dejará de estar vigente y no queremos tener problemas con el mismo. Os comento esto por lo siguiente, es posible que tengáis que renovar vuestro certificado y a alguien se le de por revocar el certificado antes de tiempo … Son dos procesos que pueden ir por separado sin problema, puesto que si nosotros tenemos que renovar nuestro certificado  (para Lync o Skype For Business por ejemplo) el hacerl no invalida el que está a punto de caducar. Por lo que podemos renovar el certificado x días de antes de que expire el actual certificado, y este seguirá funcionando sin problema. Y si instalamos el nuevo certificado también funcionará sin problemas, el antiguo lo hará hasta que expire. El proceso "normal" sería renovar el certificado y si el anterior no ha expirado, pues revocarlo e instalar el nuevo en los servicios que lo necesitemos. La revocación en una CA Pública (DigiCert, Verisign, Geotrust, etc..) es responsabilidad suya, y si configuramos una CA interna clarament es algo que podemos hacer nosotros mismos.

Dicho todo esto, veamos que ocurre cuando se aplica esto a Lync o Skype For Business en el proceso de la federación. Pensemos que tenemos todo nuestro escenario implementado y está funcioando sin problemas, pero llega el momento de renovar el certificado y mientras estamos esperando a que el proveedor nos haga llegar el certificado nuevo nos damos cuenta de que la federación no funciona y porqué …. puesto por cosas como esto:

Certificado_Revocado_4.png

Y aquí es donde no hay que volverse loco revisando y cambiando todo lo que está a nuestro alcance, si hasta la fecha ha funcionado sin problema, empecemos por revisar algo básico:

  • Registros DNS Públicos (NSLOOKUP es nuestro mejor amigo): Revisad este artículo que había publicado en su momento Problema con la federación de dominio por socio detectado
  • Puerto 5061 (TELNET es nuestro mejor amigo): Ejecutamos desde el EDGE un telnet hacia el otro EDGE el cual tiene el dominio con el cual queremos federanos y como puedo de destino el 5061 (telnet sip.dominio.com 5061). Si se conecta se os quedará la pantalla del telnet en negro, en el caso contrario se quedará con el texto Conectándose a sip.dominio.com…, por lo que o bien tenemos filtrado el acceso hacia ese host o simplemente el HOST de destino lo tiene filtrado.
  • Visor de Eventos (el mejor amigo de cualquier ADMINISTRADOR DE IT): Esto es lo primero que debéis revisar, porque a buen seguro tendremos información muy útil sobre el problema. En este caso esto es lo que tenemos:

Este evento es del servidor EDGE el cual quiere conectarse al otro EDGE el cual tiene el certificado revocado, y como vemos no los dice claramente: 0X80092010 (CRYP_E_REVOKED).

Certificado_Revocado_2.png

 Aquí no hay lugar a duda, puesto que como sabéis en el proceso de conexión y verificación del certificado los sistemas siempre comprueban varias cosas antes de dar como bueno el certificado presentado por el servidor al que nos queremos conectar:

  • Si el certificado no está expirado en base a la validez del certificado, que esto lo vemos en las propiedades del mismo (Válido desde xx/xx/xxxx hasta xx/xx/xxxx

Certificado_Revocado_8.png

  • Si el certificado es de confianza para nosotros, para ello necesitaremos tener el certificado raíz de la entidad certificadora que ha emitido el certificado para el servidor de destino en nuestro almacén local de certificados. Porque sino es así, es cuando nos encontramos el error de que no podemos verificar el certificado que nos presenta el servidor y no podremos conectarnos (para ver el almacén local de certificados de equipo abriremos la consolsa certlm.msc). Si nos vamos a la capeta certificados dentro de Entidades de certificación de Confianza podemos ver las entidades públicas y privadas (las instaladas por nosotros) más importantes, por eso los equipos se conectan a sitios públicos con SSL, TLS, etc.. sin que nos muestre el error de que no confiamos en el certificado porque no podamos verificarlo por su ruta de certificación). En el caso que os muestro, el certificado es uno wildcard (*.asirsl.com) que ha sido emitido por DigiCert y que nosotros en nuestro almacén local de certificados tenemos el certificado raíz de la CA que ha emitido nuestro certificado.

Certificado_Revocado_9.png

Pero el problema es más "simple", porque nos lo indica de forma clara, el certificado ha sido revocado, por lo que el proceso de federación no se puede completar. Eso es justamente lo que tiene que hacer, además de todo lo anterior, verificiar que el certificado no esté revocado. Para ello se conectará a las CRL o OCSP para ver si el número de serie del certificado presentado por el servidor al que queremos conectarnos está incluido en dicha lista, si lo está, es que ha sido revocado, en caso contrario nuestro servidor lo vería como válido (siempre y cuando los puntos anteriores se verificasen con éxito: Fecha y Entidad Raíz de Confianza). La información  de la comprobación de la CRL (Certificate Revocation List)  o OCSP (Online Certificate Status Protocol) en donde se encuentra? .. esa información la tenemos en el certificado y que los sistemas la consultará para saber donde están las CRL  (sistema bastante precario en la actualidad, es un fichero que se actualiza en modo "offline" (es mucho más que eso, pero eso lo comentaremos en otro artículo)) o OCSP (más moderno y actual, es un sistema "online" de comprobar los certificados (es mucho más que eso, pero eso lo comentaremos en otro artículo)). Si vamos a la pestaña Detalles dentro de las propiedades del certificado podemos ver las URL de las CRL y OCSP de la CA que ha emitido este certificado, las cuales están disponibles para que los sistemas puedan connectarse y ver si el certificado está o no en dichas listas.

Certificado_Revocado_10.png

Ahora como siempre, vamos a ver que realmente esto es así , para ello utilizaremos nuestro amigo Wireshark para que podemos ver de forma "gráfica" el resultado de la consulta de la CRL u OCSP. Aquí teneís una traza de wireshark en donde ya tenemos la consulta al OCSP de la CA (Thawte SSL CA) que ha emitido el certificado que nos muestra el otro EDGE con el que queremos federarnos y vemos claramente el resultado: 

Certificado_Revocado_7.png
 
Claramente vemos que el Certstatus es Revoked y la razón de la revocación es KeyCompromise, por lo que automáticamente Lync rechazará la conexión  con dicho servidor, por lo que en este caso la federación no se completará. La razón de la revocación es meramente informativa, porque en este caso pone que se ha comprometido la clave y no ha sido así, es que el proveedor cuando se le solicitó renovarlo automáticamente lo revocó y ha puesto esa razón de revocación. Si lo hacemos nosotros en nuestra CA estas son las opciones disponibles de revocación.
 
Certificado_Revocado_12.png
 
Como vemos el proceso está bien definido y es mucho más extenso que todo esto claramente, pero bueno es únicamente para explicar el problema de un certificado revocado en un proceso de federación (u otro proceso que compruebe la revocación de los certificados, porque no todos lo hacne (y deberían)). Y sobre todo que tengáis en cuenta que cuando renovéis el certificado, si queréis seguir manteniento el actual hasta que lo tengáis ya cambiado en todos los sitios en donde tengáis que instalarlo, comentárselo a vuestro proveedor, que no lo revoque sino ….
 
Por último como os comentaba, como no todos los servicios o aplicaciones verifican las CRL u OCSP,  sino que simplemente se fijan en la fecha, Certificado Raíz Local y nombre  común del certificado con respecto a donde nos conectamos, es posible que el certificado esté revocado y nos permita conectarnos sin avisar. De ahi que siempre es recomendable habilitar que se verifique la revocación de los certificados, en Internet Explorer es muy sencillo de configurarlo desde las Opciones Avanzadas desde Opciones de Internet :
Certificado_Revocado_13.png
Por si fuese de interés os dejo un vídeo de como configurar una CA con las CRL y OCSP: Windows Server 2012, Instalación de una CA
 
Espero que os sea de utilidad!!!

​En esta fase lo que  haremos será instalar las herramientas de administración de Skype For Business 2015 (Panel de Control y Generador de Topologías)

Instalación Skype For Business 2015_Instalacion_4.png
 
 

El proceso es muy simple, únicamente introducimos el CD  de instalación de Skype For Business y ejecutamos el instalador (Setup.exe) y avanzar en el proceso de instalación según nos va llevando el asistente. Lo primero que hará instalará Microsoft Visual C++ , puesto que será como requisito para realizar la instalación. Una vez que finalice se instalarán los componentes Core de Skype For Business,  ya tenemos instaladas las siguientes herramientas de implementación (imagen de la web de MSFT):

IC791979.png

  • Herramienta de instalación Skype For Business Server
  • PowerShell para Skype For Business

Ejecutamos las herramientas de instalación de Skype For Business e instalamos las herramientas adminstrativas (Imagen de la web de Microsoft):

IC791980.png

Con esto ya tenemos las herramientas que necesitamos para iniciar la creación de nuestra primera topología de Skype For Business (Imagen de la web de Microsoft):

IC791981.png

Panel de Control de Skype For Business: Nos permite administrar nuestra instalación (usuario, federación, grupos de respuesta, etc…)

Generador de Topologías de Skype For Business: No permite crear, descargar y publicar nuestra topología de Skype For Business

Nota: El proceso no ha variado en absoluto de lo que hacíamos con Lync, , por lo que si lo habéis hecho en más ocasiones, no vais a notar cambio alguno.

Este sería el segundo paso (Instalación Skype For Business 2015 en 8 pasos (Paso I)) dentro del proceso de instalación de Skype For Business 2015

Instalación Skype For Business 2015_Instalacion_3.png
 
Básicamente crearemos un recurso compartido que será utilizado en la topología Skype For Business, aquí tenéis una artículo de Jeff Schertz's (http://blog.schertz.name/2013/03/breaking-down-lync-file-share) un MVP de Lync (ahora de Skype For Business). Para su configuración lo único que debemos hacer es crear carpeta y compartirla aplicando los siguientes permisos:
  • Carpeta Compartida:  Usuario: Administrador, Permiso: Control Total.
  • NTFS:  Se aplicarán una vez que se  publique la topología y se ajustarán de forma automática vía grupos RTCxxxxxxx, pero teniendo previamente el Administrador Control Total
Nota: La configuración de la carpeta compartida para Skype For Business no ha cambiado en absoluto con respecto a Lync Server 2013. Además, si queremos ofrecer tolerancia a fallas podemos implementar DFS, al igual también como con Lync Server 2013 (Lync Server 2013: Configuración de Alta Disponibilidad (Almacén de Archivos con DFS))

div class=»ExternalClassED63BBD6101149CEBADCBAF301164ADB»>

El primer paso que debemos llevar a cabo para la implementación de Skype For Business, es la instalación de requisitos previos. Siguiendo el proceso indicado en el primer artículo (Instalación Skype For Business 2015 en 8 pasos) de esta seria de 9 artículos, nos encontramos en el primero paso: Instalación de Requisitos

Instalación Skype For Business 2015_Instalacion_2.png

 

Como os comentaba en el artículo de introducción (Instalación Skype For Business 2015 en 8 pasos) de esta serie de 8, se utilizará como sistema operativo Windows Server 2012 R2, creo que por razones obvias. Además, claramente se recomienda que el sistema operativo esté completamente actualizado desde Windows Update.  Dicho esto ahora debemos instalar las siguientes características y podemos hacerlo mediante powershell, ahora bien los requisitos difieren en base al rol de Skype For Business que vayamos a instalar (https://technet.microsoft.com/en-us/library/dn951388.aspx):

Todos los servidores

  • Windows PowerShell 3.0
  • Microsoft .Net Framework 4.5 (HTTP Activation)
  • Windows Identity Foundation
  • Remote Server Administration Tools (AD DS y AD LDS)

Y además de estas instalaciones debemos añadir por rol de Lync los siguientes requisitos:

Front-END

Add-WindowsFeature NET-Framework-Core, RSAT-ADDS, Windows-Identity-Foundation, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Dir-Browsing, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Mgmt-Tools, Web-Scripting-Tools, Web-Mgmt-Compat, Server-Media-Foundation, BITS

Director

Add-WindowsFeature RSAT-ADDS, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth, Web-Filtering, Web-Stat-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Scripting-Tools, Web-Mgmt-Compat, Desktop-Experience, Telnet-Client

Chat Persistente: Además de los requisitos anteriores debemos instalar Message Queuing (MSMQ https://technet.microsoft.com/en-us/library/cc771474.aspx)

Una vez instalados tenemos que reiniciar y volveremos a buscar más actualizaciones posibles, las cuales debemos completarlas hasta que tengamos el sistema operativo 100% actualizado hasta el momento.

Nota: todos los requisitos son  muy similares a Lync  Server 2013, y con powershell los requisistos son muy simples de implementar. Se debería prestar siempre especial anteción a las actualizaciones de Windows Server y el resto de componentes, puesto que es más que recomendable estar 100% actualizado.