Microsoft Lync Server
Header

Algo que debemos tener en cuenta cuando implementamos Lync, es conocer la topología de red de nuestro cliente. En muchas ocasiones nos encontramos con Firewalls, IDS, IPS, VLAN, IPSec, etc…, por lo que debemos realizar algunos cambios para ajustarlo para obtener el mejor rendimiento de Lync. Lo más común es modificar las reglas de publicación de puertos de los Firewalls, ACLs en los Switchs L3 para permitir la comunicación entres VLANs, etc… pero que ocurre si tenemos implementado IPSec? Es probable que en el momento de asociar los puertos de medios, tengamos problemas con el tiempo de negociación de IPSec y por tanto las llamadas no se establezcan o problemas similares. Para evitar este más que probable comportamiento, debemos habilitar las siguientes excepciones del tráfico de IPSec:

Excepciones_IPSec_Para_Lync_1.png
Por supuesto esto también dependerá del hardware que utilicemos para implementar IPSec (Firewalls, Routers, etc…), si por el contrario utilizamos las Directivas de seguridad IP en Equipo Local debemos modificar la regla correspondiente puesto que además esto de por sí tiene un impacto importante en las comunicaciones del servidor/equipo.
Excepciones_IPSec_Para_Lync_2.png

Espero que os sea de utilidad!!!

Muchos de vuestros clientes cuentan con distintas oficinas en ubicaciones geográficamente distantes, y seguro que con la necesidad de comunicarlas para poder ofrecer los mismos servicios que en las oficinas centrales. Ahora llega la pregunta del millón, cómo conectar las distintas oficinas? Todos los ISP nos ofrecen múltiples tecnologías para ello:

Estas tecnologías son las que suelen manejar los ISP cuando queremos disponer de conectividad entre distintas ubicaciones, además nos permite contratar distintos servicios de alto valor añadido:

  • Redundancia
  • QoS
  • Ancho de Banda
  • Monitorización
  • Seguridad

Pero por supuesto esto tiene un coste que no todas las empresas pueden asumir, a pesar de que ahora mismo tiene un coste más que razonable. De ahí que tengamos la necesidad de buscar alternativas, que a pesar de no tener estos servicios de valor añadido. También es cierto que no en todas las ocasiones necesitamos todas las funcionalidades de este tipo de enlaces, y únicamente buscamos conectar las distintas sedes del cliente. Pero claro, aquí no se nos puede pasar por alto lo más importante cuando utilizamos la WAN (insegura por defecto) para conectar distintas oficinas, que es ofrecer una capa de seguridad importante para que nadie libremente pueda interceptarlas, analizarlas y/o ser capaz de modificarlas. También es cierto que siempre debemos alinear las necesidades de seguridad con el coste que ello supone, pero hoy en día cualquier hardware que se precie soporta ciertos protocolos de seguridad. Existen múltiples tipos de VPN, esto es algo que debemos tener en cuenta en función del diseño que hagamos de la solución. Lo más común y sencillo de implementar es una VPN con IPSec Site-to-Site, para ello debemos tener dispositivos que soporten IPSec (es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos) y sobre él realizar las configuraciones necesarias. Yo os voy a mostrar como configurar un VPN con IPSec Site-to-Site con hardware Cisco, en este caso entre dos routers Cisco de la serie 1800. Este sería el esquema sobre el que se fundamentará la configuración de IPSec:

Esquema: Empresa con dos delegaciones que tiene los servidores principales en la sede central y una replicación de ficheros vía DFSLync_VPN_IPSec_Empresa.jpg

Como esta configuración "tipo" ya os la había comentado en su momento en otro artículo (La Nube Privada: Migración de Oficina, Beneficios del CPD y la VoIP) , me voy a centrar en configurar la autenticación de la Fase 1 utilizando certificados digitales emitidos por nuestra CA. Para refrescarnos la memoria, aquí os dejo la configuración que había utilizado en este artículo de la Nube Privada …. pero cambiando la autenticación de Preshared Key a RSA-SIG, aportando un plus de seguridad y escalabilidad:

La configuración de IPSec mediante dispositivos Cisco y solo con una IP fija en uno de los extremos es la siguiente:
​Data Center ​Nueva Oficina
 crypto isakmp policy 10
 encr aes 192
 authentication rsa-sig
 group 2
 
crypto ipsec transform-set ipsec esp-aes 192 esp-sha-hmac
crypto dynamic-map vpneq2b 10
 set transform-set ipsec
 match address 180
crypto map vpnipsec 10 ipsec-isakmp dynamic vpneq2b
access-list 180 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 180 deny   ip 192.168.200.0 0.0.0.255 host 0.0.0.0
No NAT
access-list 110 deny   ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 110 permit ip any any​
crypto isakmp policy 10
 encr aes 192
 authentication rsa-sig
 group 2
crypto ipsec transform-set ipsec esp-aes 192 esp-sha-hmac
crypto map vpneq2b 10 ipsec-isakmp
 set peer 213.60.255.111
 set transform-set ipsec
 match address 180
access-list 180 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
access-list 180 deny ip 192.168.100.0 0.0.0.255 0.0.0.0 0.0.0.0
No NAT
access-list 110 deny   ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
access-list 110 permit ip any any​
​Por último se deben aplicar los crypto-map a las interfaces WAN ​

 

Ahora debemos configurar nuestra CA para que los dispositivos de red puedes solicitar su certificado, para ello vamos a utilizar el Servicio de Inscripción de Dispositivos de Red de nuestra CA en Windows Server. Yo utilizaré Windows Server 2012, y lo primero que debemos hacer es configurar primero nuestra CA: Windows Server 2012, Instalación de una CA. Y durante la instalación o a posteriori configuraremos el Servicio de Inscripción de Dispositivos de Red, yo ya tengo la CA instalada y vamos a ver como podemos configurar el servicio de Servicio de Inscripción de Dispositivos de Red. Para ello vamos a la consola de Administración de nuestro servidor, vamos a Administrar – Agregar Roles y Características y seguimos el asistente hasta que se complete la instalación:

vpn_con_certificados_ndes_45.png

vpn_con_certificados_ndes_46.png

vpn_con_certificados_ndes_47.png

vpn_con_certificados_ndes_48.png

Ahora debemos seleccionar Servicio de inscripción de dispositivos de red y pulsamo en Siguiente

vpn_con_certificados_ndes_1.png

Pulsamos en Siguiente
vpn_con_certificados_ndes_2.png

Una vez que se ha completado la instalación debemos pulsar en Configurar Servicios de certificados de Active Directory en el servidor de destinovpn_con_certificados_ndes_4.png
Por defecto el usuario que instalará que configurará los servicios del ROL será el usuario con el que hayáis iniciado sesión, ya doy por hecho que sois miembros del grupo Admins. del Dominio. Pero en todo caso si queréis elegir otro usuario para realizar la  configuración de este servicio

vpn_con_certificados_ndes_5.png

Debemos seleccionar un usuario que se usará para el servicio de inscripción de certificados, como véis nos avisa de que debe ser miembro del grupo IIS_IUSRS local, pulsamos en seleccionar

vpn_con_certificados_ndes_7.png

Introducimos el nombre del usuario del dominio (debe ser miembro únicamente del grupo de Usuarios del Dominio) e introducimos sus credenciales

vpn_con_certificados_ndes_8.png

pulsamos en Siguiente
vpn_con_certificados_ndes_9.png

Cubrimos los datos de nuestra organización y pulsamos en Siguiente
vpn_con_certificados_ndes_10.png
Podemos dejarlo por defecto y pulsamos en Siguiente

vpn_con_certificados_ndes_11.png

Por último nos muestra un resumen de la configuración y pulsamos en Configurar
vpn_con_certificados_ndes_12.png
vpn_con_certificados_ndes_13.png
vpn_con_certificados_ndes_14.png

Ahora que hemos finalizado veremos que los certificados que tenemos disponibles para la inscripción desde los dispositivos de red serán de la plantila de IPSecCIntermediateOffline. Si quisieramos utilizar una plantilla de certificado personalizada, tendríamos que crear nueva plantilla y editar el registro para cambiar el nombre del certificado a emitir: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP: EncryptionTemplate, GeneralPurposeTemplate, SignatureTemplate y luego reiniciar el IIS para que los cambios se hayan aplicado correctamente.

vpn_con_certificados_ndes_49.png

Ahora vamos a revisar que el usuario asignado para el servicio de inscripción de certificados para dispositivos de red tiene acceso de inscripción de esta plantilla, para ello vamos a la consola de la entidad certificadora, vamos a Plantillas de Certificado y pulsamos con el botón secundario del ratón y pulsamos en Administrar

vpn_con_certificados_ndes_50.png
Debemos ir a las propiedades de la plantilla de  IPSECIntermediateOffline y vamos a la pestaña de seguridad para poder verificar que el usuarios NDES (es el usuario comentario anteriormente) tiene acceso de inscripción sobre esta plantilla

vpn_con_certificados_ndes_51.png
Una vez revisado los permisos básicos y que en nuestro caso la plantilla de certificado que necesitamos es esta, ahora debemos acceder a la URL de administración de emisión de certificados para dispositivos de red. Para ello debemos escribir la siguiente URL: http(s)://fqdn_servidor/certsrv/mscep_admin, ahora os solicitará las credenciales de acceso y debéis iniciar sesión con  un usuario que tenga acceso de inscripción de certificados para las plantillas de IPSECIntermediateOffline, en caso contrario os dará acceso denegado. 

Si cuando accedemos a la URL comentada nos encontramos con este errorvpn_con_certificados_ndes_15.png
debemos revisar el méto de inicio de sesión, que por defecto es negotiate pero si no tenemos los registros SPN actualizados no nos permitirá autenticar. En mi caso como no utlizo el FQDN del sevidor sino un registro CNAME para darle otra URL al acceso web de inscripción de certificados y no tener el SPN creado, no me permitirá autenticarme por Kerberos por lo que tengo que modificarlo de Negotiate a NTLM. Si bien es cierto que puedo crear el SPN adecuado y demás, pero por agilizar la guía no lo he hecho cambiando solo lo he modificado el orden de los proveedores habilitados y  he puesto NTLM el primero en la lista

vpn_con_certificados_ndes_16.png
Ahora he vuelto a acceder a la URL comentada anteriormente y me muestra el siguiente errorvpn_con_certificados_ndes_17.png
Para solucionar este problema he utilizado est KB de MSFT: http://support.microsoft.com/kb/2800975 y debéis seguir estos pasos para solucionarlo

1) Install and configure NDES (and CEP/CES).
2) Open IIS.
3) Select “Default Web Site”. 
4) Click “View Applications” in the action panel on the right.
5) Double click the mscep application.
6) Double click “Handler Mappings”.
7) Click “View Ordered List…” in the action panel.
8) Select ExtensionlessUrlHandler-ISAPI-4.0_64bit and move it down so it is below StaticFile.
9) Repeat steps 6-8 for the mscep_admin application.
10) Restart IIS.

Aquí so muestro los pasos en imágenes

vpn_con_certificados_ndes_18.png
vpn_con_certificados_ndes_19.png

Nota: Esto me ha pasado en casi todas las implementaciones de NDES con Windows Server 2012

Ahora volvemos a tratar de acceder a la URL de NDES y ya podemos acceder correctamente, como vemos nos ofrece la huella digital del certificado a emitir y su clave de solicitud, que como podéis obsevar tendrá una validez de 60 min y solo se puede usar una vez. Este comportamiento se puede modificar editando el registro, pero yo prefiero que dejarlo así. Se puede quitar la solicitud de contraseña, etc.. pero mejor dejémoslo así.

Nota a tener en cuenta de MSFT

De forma predeterminada, el Servicio de inscripción de dispositivos de red solamente puede almacenar en caché cinco contraseñas cada vez. Si la memoria caché de contraseñas está llena al enviar una solicitud de contraseña, debe realizar una de las siguientes acciones antes de enviar la solicitud
  • Espere hasta que una de las contraseñas haya expirado antes de enviar una solicitud nueva.
  • Detenga y reinicie Internet Information Services (IIS) para eliminar todas las contraseñas almacenadas en la memoria caché.
  • Configure el servicio para que almacene en la memoria caché más de cinco contraseñas.

vpn_con_certificados_ndes_21.png

Ya tenemos todo preparado para que nuestros dos routers Cisco puedan solicitar su certificado, para ello debemos seguir los siguientes pasos:

Crear los RSA necesarios: crypto key generate rsa general-keys label <Etiqueta> modulus 2048

vpn_con_certificados_ndes_22.png

(Opcional) Configurar un servidor DNS para que el router pueda resolver nombres de dominio: ip name-server <dirección_IP>. Esto nos ayudará a resolver el nombre de la URL del NDES, y no tenemos que estar utilizando la dirección IP.

vpn_con_certificados_ndes_23.png

Configuramos las opciones de inscripción del certificado por parte del router

crypto pki trustpoint EQ2B
 enrollment mode ra
 enrollment url http://ca.eq2b.com:80/certsrv/mscep/mscep.dll
 usage ike
 serial-number
 revocation-check none
 rsakeypair EQ2BRSA
 auto-enroll

vpn_con_certificados_ndes_24.png

Enviaremos la solictud de autenticación a la CA: crypto pki authenticate <nombre_trustpoint>

vpn_con_certificados_ndes_26.png

Como vemos en la URL del NDES MD5 la huella digital que nos está mostrando en la misma que nos devuelve en el router

vpn_con_certificados_ndes_27.png

Enviaremos la solicitud de inscripción del certificado a la CA: crypto pki enroll <nombre_trustpoint>. Como vemos nos solicita una clave para poder solicitar el certificado, la clave es la que nos muestra en la página en la URL de NDES

vpn_con_certificados_ndes_28.png

Ahora si queremos ver el certificado  recibido escribiremos: sh crypto ca certificates EQ2B

vpn_con_certificados_ndes_29.png

Ahora ya tenemos nuestro certifcado en el router, y si nos vamos a la consola de la CA a Certificados Emitidos y vemos que se ha emitido el certificado en base a la plantilla IPSEC (solicitud sin conexión) y el nombre del solicitante es el usuario NDES. Este usuario es el que previamente habíamos configurado con el asistente inicial

vpn_con_certificados_ndes_30.png

Ahora debemos cambiar el modo de autenticación de nuestra configuración de IPSec en la Fase 1: authentication rsa-sig
 crypto isakmp policy 10 

  authentication rsa-sig

Si ahora escribimos el siguiente comando nos mostrará un resumen de como ha quedado configurado nuestra Policy: sh crypto isakmp policy
vpn_con_certificados_ndes_33.png
 
Esto es todo lo que debemos hacer en cada uno de los routers que, así que debemos repetir los seis pasos en el otro router del otro extremo de la VPN. Una vez completados si vamos a la consola de administración de la CA vemos que ya aparecen los dos certificados emitidos.
vpn_con_certificados_ndes_34.png

Una vez que ambos routers están configurados con sus correspondientes certificados, y que se ha cambiado la configuración de Preshared key a RSA-SIG  los routers volverán a negociar IPSec y tratar de conectarse. Aquí os muestro parte de un log de la negociación de IPSec entre ambos routers:

 
May  4 15:33:57.044: ISAKMP:(0): sending packet to XXX.XXX.XXX.XXX my_port 4500 peer_port 4500 (R) MM_KEY_EXCH
May  4 15:33:57.044: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
May  4 15:33:57.044: ISAKMP:(0):Old State = IKE_R_MM3  New State = IKE_R_MM4
May  4 15:33:57.336: ISAKMP (0:0): received packet from XXX.XXX.XXX.XXX dport 4500 sport 4500 Global (R) MM_KEY_EXCH
May  4 15:33:57.336: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
May  4 15:33:57.336: ISAKMP:(0):Old State = IKE_R_MM4  New State = IKE_R_MM5
May  4 15:33:57.336: ISAKMP:(0): processing ID payload. message ID = 0
May  4 15:33:57.336: ISAKMP (0:0): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : XXXXXXXXXXXXXX
        protocol     : 17
        port         : 0
        length       : 21
May  4 15:33:57.380: ISAKMP:(0): processing SIG payload. message ID = 0
May  4 15:33:57.412: ISAKMP:received payload type 17
May  4 15:33:57.412: ISAKMP:(0):SA authentication status:
        authenticated
May  4 15:33:57.412: ISAKMP:(0):SA has been authenticated with XXX.XXX.XXX.XXX
May  4 15:33:57.412: ISAKMP:(0):Detected port floating to port = 4500
May  4 15:33:57.412: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
May  4 15:33:57.412: ISAKMP:(0):Old State = IKE_R_MM5  New State = IKE_R_MM5
May  4 15:33:57.420: ISAKMP:(0):SA is doing RSA signature authentication using id type ID_IPV4_ADDR
May  4 15:33:57.420: ISAKMP (0:0): ID payload
        next-payload : 6
        type         : 1
        address      : XXXXXXXXXXXXXXXXXXXXX
        protocol     : 17
        port         : 0
        length       : 12
May  4 15:33:57.420: ISAKMP:(0):Total payload length: 12
May  4 15:33:57.432: ISAKMP (0:0): constructing CERT payload for hostname=EQ2B.asirsl.com,ipaddress=YYY.YYY.YYY.YYY,serialNumber=FCZ102990AA
May  4 15:33:57.432: ISKAMP: growing send buffer from 1024 to 3072
May  4 15:33:57.432: ISAKMP:(0): using the EQ2B trustpoint's keypair to sign
May  4 15:33:58.452: ISAKMP:(0): sending packet to XXX.XXX.XXX.XXX my_port 4500 peer_port 4500 (R) MM_KEY_EXCH
May  4 15:33:58.456: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
May  4 15:33:58.456: ISAKMP:(0):Old State = IKE_R_MM5  New State = IKE_P1_COMPLETE
May  4 15:33:58.456: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
May  4 15:33:58.456: ISAKMP:(0):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
May  4 15:34:08.955: ISAKMP (0:0): received packet from XXX.XXX.XXX.XXX dport 4500 sport 4500 Global (R) QM_IDLE
May  4 15:34:08.959: ISAKMP: set new node 452620383 to QM_IDLE
May  4 15:34:08.959: ISAKMP:(0): processing HASH payload. message ID = 452620383
May  4 15:34:08.959: ISAKMP:(0): processing NOTIFY DPD/R_U_THERE protocol 1
        spi 0, message ID = 452620383, sa = 63F8B86C
May  4 15:34:08.959: ISAKMP:(0):deleting node 452620383 error FALSE reason "Informational (in) state 1"
May  4 15:34:08.959: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
May  4 15:34:08.959: ISAKMP:(0):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
May  4 15:34:08.959: ISAKMP:(0):DPD/R_U_THERE received from peer XXX.XXX.XXX.XXX, sequence 0x36323CCE
May  4 15:34:08.959: ISAKMP: set new node 1455114095 to QM_IDLE
May  4 15:34:08.959: ISAKMP:(0):Sending NOTIFY DPD/R_U_THERE_ACK protocol 1
        spi 1683670752, message ID = 1455114095
May  4 15:34:08.959: ISAKMP:(0): seq. no 0x36323CCE
May  4 15:34:08.959: ISAKMP:(0): sending packet to XXX.XXX.XXX.XXX my_port 4500 peer_port 4500 (R) QM_IDLE
May  4 15:34:08.959: ISAKMP:(0):purging node 1455114095
May  4 15:34:08.959: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MESG_KEEP_ALIVE
May  4 15:34:08.963: ISAKMP:(0):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
Si queremos verificar que se ha establecido la VPN correctamente, escribimos el siguiente comando en el router: sh crypto isakmp sa y como vemos está en estado QM_IDLE por lo que estamos conectados
vpn_con_certificados_ndes_52.png
 
Esto mismo lo podemos repetir en tantos routers como queramos conectar entre si. Esto permite aumentar el nivel de seguridad y  escalabilidad de nuestra infraestructura de comunicaciones. Si os habéis fijado he puesto este comando en la configuración de  solicitud de los certificados:  revocation-check none

crypto pki trustpoint EQ2B
 revocation-check none

Esto evita que compruebe las CRL para saber si hemos o no revocado algún certificado, pero siempre es más que recomendable que se comprueben  las CRLs. Su configuración es muy sencilla, únicamente los routers debens poder conectarse a las URLS en donde tengamos publicada la CRL y en el router cambiar  revocation-check none por revocation-check crl ocsp
vpn_con_certificados_ndes_53.png

 
Con esta configuración hemos logrado conectar las sedes de nuestros cliente, y además ofrecer un plus de seguridad adicional. También comentaros que si tenemos múltiples sedes, yo siempre configuro DMVPN (esto lo veremos en otro artículo) puesto que me reporta múltiples beneficios en su configuración y gestión, pero esto lo veremos en otro artículo.
 
Y por último, recordaros que en uno de los últimos artículos que había subido en los últimos días (Lync Server: Recomendaciones para Securizar un Trunk SIP o Direct SIP) os comentaba que siempre que configuréis un SIP TRUNK sin TLS es más que recomendable establecer un túnel IPSEC entre ambos extremos. Pues con este artículo también daríamos cabida a este escenario, nuestra infraestructura de Lync conectada a un ITSP mediante una VPN IPSec con autenticación RSA-SIG.
 
Lync_VPN_IPSec_Imagen.jpg
 
Existen múltiples combinaciones y formas de establecer túneles VPN, esta simplemente es una más y muy sencilla. Además, con la CA de Windows Server 2012 es muy sencillo desplegar  el Servicio de inscripción de dispositivos de red (NDES) y ofrecer estos servicios de seguridad algo más avanzados.
 
Espero que os sea de utilidad!!!