Microsoft Lync Server
Header

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.

Como ya sabéis ya está disponible la documentación de Skype For Business 2015 en la web de Microsoft (https://technet.microsoft.com/library/gg398616(v=ocs.16).aspx), voy a tratar de explicar brevemente la instalación de Skype For Business en base a la documentación que tenemos disponible. La idea es ir analizando las diferencias existentes entre la instalación de Lync y Skype. No podré poner capturas de pantalla porque aún no tenemos la versión de servidor de Skype For Business 2015, la cual llegará el 1 de Mayo, y simplemente trataré de ir describiendo lo que voy leyendo,  tratando de poner mis propios comentarios. Dicho esto, vamos a seguir este esquema de 8 pasos descritos por Microsoft para realizar la instalación de Skype For Business 2015 (que ya os digo que difiere poco o casi nada de Lync Server 2013): 

Instalación Skype For Business 2015_Instalacion_1.png
 En los siguiente artículos iré poco a poco describiendo el proceso, espero que sea de vuestro interés. La idea es simplemente ir describiendo y comparando el proceso de instalación de Skype For Business con relación a su antecesor (Lync Server 2013). Antes de continuar con la serie de 8 artículos, veamos los requisitos a nivel de hardware, dominio, bosque, bases de datos, etc… :
 
Sistemas operativos soportados para instalar Skype For Business son los siguientes:
  • Windows Server 2008 R2: Instalando previamente el KB2533623
  • Windows Server 2012: Instalando previamenete el KB2858668
  • Windows Server 2012 R2: Instalando previamente el KB2982006
A nivel de Controladores de Dominio están soportados desde Windows  Server 2008 en adelante, y el nivel funcional del dominio y bosque están soportados desde 2003 en adelante. Se sigue soportado el tener RODC mientras tengamos un controlador de dominio de escritura, vamos, lo lógico.
  • Un único bosque y dominio
  • Un único bosque, un único árbol y múltiples dominios
  • Un único bosque con múltiples árboles y espacios de nombres distintos
  • Múltiples bosques con un topología central de bosque
  • Múltiples bosques con un bosque de recursos central
  • Múltiples bosques con una topología de recursos para Skype For Business con Exchange Online
Para mostrar gráficamente estos escenarios, Microsoft ha publicado una serie de esquemas muy interesantes:
Un único bosque y dominio
Instalación Skype For Business 2015_Bosques_1.png
Un único bosque, un único árbol y múltiples dominios
Instalación Skype For Business 2015_Bosques_2.png

Un único bosque con múltiples árboles y espacios de nombres distintos

Instalación Skype For Business 2015_Bosques_3.png

Múltiples bosques con un topología central de bosque

Instalación Skype For Business 2015_Bosques_4.png

Múltiples bosques con un bosque de recursos central

Instalación Skype For Business 2015_Bosques_5.png
Para el último escenario soportado (Múltiples bosques con una topología de recursos para Skype For Business con Exchange Online) no tenemos una imagen ahora mismo, pero seguro que en breve la tendremos disponible. Si queréis  ampliar más información sobre cada esquema, aquí tenéis el enlace original: https://technet.microsoft.com/en-us/library/dn933910.aspx
En cuanto al SQL comentaros que si instalamos un Skype For Business 2015 Standard se intalará automaticamente un SQL Server Express 2014 (64bits), pero si instalamos la versión Enterprise estas son las versiones soportadas:
  • Microsoft SQL Server 2008 R2 Standard (64Bits) con las últimas actualizaciones
  • Microsoft SQL Server 2008 R2 Enterprise (64Bits) con las últimas actualizaciones
  • Microsoft SQL Server 2012 Standard (64Bits) con las últimas actualizaciones
  • Microsoft SQL Server 2012 Enterprise (64Bits) con las últimas actualizaciones
  • Microsoft SQL Server 2014 Standard (64Bits)  con la CU6 instalada y las últimas actualizaciones
  • Microsoft SQL Server 2014 Enterprise (64Bits) con la CU6 instalada y las últimas actualizaciones
  • El hardware como siempre hemos venido escuchando es que no habrá que realizar actualizaciones, los requisitos son los mismos que para Lync Server 2013:

Hardware recomendado para los servidores front-end, back-end, Standard Edition, de chat persistente y para el Almacén de chat persistente y el Almacén de cumplimiento de chat persistente (roles de servidor back-end del servidor de chat persistente)

Componente de hardware Recomendado
CPU
Procesador dual de 64 bits, de seis núcleos, 2,26 gigahercios (GHz) o superior.
Los roles de servidor de Lync Server no admiten los procesadores Intel Itanium.
Memoria
32 gigabytes (GB).
Disco
  • 8 o más unidades de disco duro (HHD) de 10.000 RPM con al menos 72 GB de espacio libre en disco.
    Dos de los discos deben usar RAID 1 y seis deben usar RAID 10.
    O BIEN:
  • Unidades de estado sólido (SSD) con un rendimiento igual al de 8 unidades de disco duro mecánicas de 10.000 rpm.
Red
  • 1 adaptador de red de puerto dual, 1 Gbps o superior (2 recomendados, lo que requiere la formación de equipos con una sola dirección MAC y una sola dirección IP).

Hardware recomendado para los servidores perimetrales, los servidores de mediación autónomos y los Directores

Componente de hardware Recomendado
CPU
  • Procesador dual de 64 bits, cuatro núcleos, 2,0 gigahercios (GHz) o superior.
    O BIEN:
  • Procesador de cuatro vías de 64 bits, de doble núcleo, 2,0 GHz o superior. 8Los roles de servidor de Lync Server no admiten los procesadores Intel Itanium.)
Memoria
16 gigabytes (GB).
Disco
  • 4 o más HHD de 10.000 RPM con al menos 72 GB de espacio libre en disco.
    Los discos deben presentar una configuración de 2 unidades RAID 1.
    O BIEN:
  • Unidades de estado sólido (SSD) con un rendimiento igual al de 4 unidades de disco duro mecánicas de 10.000 rpm.
Red
  • 1 adaptador de red de puerto doble, 1 Gbps o superior (recomendado: 2, lo que requiere la formación de equipos con una sola dirección MAC y una sola dirección IP). En los servidores perimetrales, se requieren 2 interfaces de red.

 
En esta serie de artículos 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. 
 
En los próximos artículos me centraré en cada una de las 8 fases de la instalación de Skype For Business 2015!!!