Microsoft Lync Server
Header

Poco a poco ya vamos teniendo más documentación sobre Skype For​ Business, ya podemos ver información sobre la federación de Skype con Skype For Business. En la siguiente captura de pantalla podemos ver que ahora tenemos un puerto nuevo que abrir nuestros Firewall/Routers para la federación con Skype el puerto 4443 hacia la IP de acceso del EDGE de Skype For Business

Federación Skype con Skype For Business.png
Lo de la apertura del puerto entiendo que es así, al igual que lo hacemos con el  5061, pero sin embargo en el poster de cargas de trabajo de Skype For Business no lo veo: Esquemas de las cargas de trabajo de Skype For Business

Esto nos permitirá buscar y añadir a usuarios de Skype (versión de consumo) en nuestro Skype For Business, algo que ya estábamos esperando desde hace mucho tiempo. Además, tendremos las siguientes búsquedas disponibles cuando queramos agregar a usuarios de Skype:

  • Search by display name plus location, example “John Doe in Barcelona”– This will narrow the results of the search down considerably.
  • Search by email, example “johndoe@outlook.com” – This should return one result in most cases; the one that matches the specified email exactly. But if the same email is associated with more than one account, multiple results may be returned.
  • Search by phone number, example “123-123-1234” – This should return one result in most cases; the one that matches the specified phone exactly. Phone number must include the country code (i.e. 1-xxx-yyy-zzzz). If the same phone number is associated with more than one account, multiple results may be returned.
  • Search by Skype ID, example “JohnDoe1456” – If exact match is found, it will be returned as the first result. Other possible “name” matches may be return

 

 

Como requisitos de plataforma que debemos tener para poder realizar dicha configuración, es la siguiente:

 

Skype for Business Server 2015 Front End
Lync Server 2013 (or older) Front End
Comments
Skype for Business Server 2015 Edge
Supported
Not Supported
Skype for Business Server 2015 and Edge are prerequisites for Skype Directory Search
Skype for Business Server 2015 Edge + Lync Server 2013 Edge deployed side-by-side
Supported
Not Supported
Skype Directory Search traffic flows through Skype for Business Server Edge servers. Federation traffic goes through edge configured by the administrator. For example, the administrator could choose to continue to send federation traffic through Lync Server 2013 Edge servers which would not support Skype Directory Search.
Lync Server 2013 (or older) Edge
Not Supported
Not Supported

 

 

En cuanto a la configuración de nuestro EDGE, difiere poco de lo que hacíamos antes para configurar la federación con Skype. Los pasos a seguir son los mismos y requisitos de certificados y puertos son los mismos, a excepción que debemos abrir ahora el puerto 4443 y antes solo el 5061:

  • Registrar en el PIC (https://pic.lync.com) nuestro EDGE y dominio
  • Tener el registro DNS de tipo SRV configurado correctamente (_sipfederationtls._tcp.dominio.com)
  • El EDGE debe tener certificados públicos
  • Configurar la Federación en Skype For Business como  os muestro en la siguiente imagen (imagen de la web de Microsoft), para instalaciones nuevas

Federación Skype con Skype For Business_1.png

Si actualizamos nuestra topología a Skype For Business tenemos que reconfigurar nuestras federaciones, podemos hacerlo mediante PowerShell con los siguientes cmdlets:

  • Primero borramos el proveedor que tenemos: Remove-CsPublicProvider -Identity <identity-name>
  • Segundo configuramos el nuevo proveedor con los datos que nos ponen aquí: New-CsPublicProvider Identity Skype ProxyFqdn federation.messenger.msn.com IconUrl https://images.edge.messenger.live.com/Messenger_16x16.png –NameDecorationRoutingDomain msn.com NameDecorationExcludedDomainList «msn.com,outlook.com,live.com,hotmail.com»VerificationLevel UseSourceVerification Enabled $trueEnableSkypeIdRouting $true EnableSkypeDirectorySearch $true

Nota: Added in Lync Server 2013 CU5 & Lync desktop client in Office 2013 SP1, the NameDecorationRoutingDomain and NameDecorationExcludedDomainList improve the situation where Lync users adding Skype contacts needed to “decorate” non-Microsoft domains to identify and route them to Skype (the format of: user(contoso.com)@msn.com). These new settings will allow automatic formatting of the address user’s enter in the “Add Skype contact” dialog box with the NameDecorationRoutingDomain (which should be set to msn.com) if it does not contain the domains in the NameDecorationExcludedDomainList (we currently can support msn.com, live.com, Hotmail.com, outlook.com).

Con todo esto bien configurado, ya deberíamos poder buscar contactos de Skype en nuestro cliente de Skype For Business:

Federación Skype con Skype For Business_2.png

Aquí tenéis también la integración y soporte de los diferentes clientes de Lync/Skype4B (Skype For Business) con Skype (Versión de consumo):

Skype consumer interop with Skype for Business
Skype Clients
Add contacts, IM, presence, audio
Video
Skype Windows Desktop
MSA: 6.3 or higher
Skype ID: 7.3 or higher
MSA: 7.3 or higher (not XP or Vista)
Skype ID: 7.3 or higher
Skype Mobile – Windows Phone
Coming Soon
Coming Soon
Skype Mobile – Android Phone
Coming Soon
Coming Soon
Skype Mobile – iOS
Coming Soon
Coming Soon
Skype Mac
Microsoft Accounts: 6.4 and higher
Skype Name: Coming Soon
Coming Soon
Skype for Business interop with Skype consumer
Client
Skype Directory Search and Add Contacts
Skype A/V, IM interop
Skype for Business 2015
Yes
Yes
Lync Desktop 2013
Can add (no search)
Yes
Lync Web App – online and on-premises
N/A
N/A
Lync Mobile – Windows Phone
Coming Soon
Yes
Lync Mobile – Android
Coming Soon
Yes
Lync Mobile – iOS
Coming Soon
Yes
Lync Room System
Coming Soon
Yes
Lync Modern App (Win 8.1)
Yes
Yes
Lync Mac 2011
Can add (no search)
Yes
Lync Desktop 2010
Can add (no search)
Yes
Lync Phone Edition
N/A
N/A
Lync Attendant
N/A
N/A

 

Ahora toca esperar a tener la versión de Skype For Business 2015 y que esté habillitad la federación ya con Skype buscándolos por su ID de Skype!!!

Información ampliada: https://technet.microsoft.com/en-us/library/dn705313.aspx

Microsoft ha publicado tres checklists para que revisemos nuestra implementaciones de Lync, dándonos los puntos que debemos revisar de forma diaria, semanal y mensual:

Lync 2013 Operations Checklists_1_Diario.PNG

Checklist Diario: Operations Daily.xlsxOperations Daily.xlsx

Checklist Semanal: Operations Weekly.xlsxOperations Weekly.xlsx

Checklist Mensual: Operations Monthly.xlsxOperations Monthly.xlsx

Ya no tenemos excusa para saber que debemos revisar de nuestras topologías de Lync!!!

Como sabéis el 1 de Mayo del 2015 deberíamos tener la versión de servidor de Skype For Business, pero para poder migrar de cumplir una serie de requisitos que os comento a continuación:
  • Instalar el CU5 o superior en vuestra topología de Lync Server
  • PowerShell RTM version (6.2.9200.0) o superior
  • Disponer de un SQL Server 2008 R2 SP2 o SQL server 2012 SP1
  • Kb2533623 Windows Server 2008 R2
  • Kb2858668 Windows Server 2012
  • KB2982006 Windows Server 2012 R2
Si actualizamos de Lync 2013 Standard a Skype For Business Standard se actualizará automáticamente la versión de SQL Server Express 2012 a la 2014. Aquí tenéis el mapa de rutas de migración de lync 2010 o 2013 a Skype For Business: Ruta de migración de Lync Server 2010 o 2013 a Skype For Business
Migración Lync2010-2013 a Skype For Business-2.PNG
Yo ya tengo todo preparado para migrar de Lync Server 2013 Enterprise a Skype For Business 2015 Enterprise, y vosotros?!!!!

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!!!