Túneles Site-2-Site en Azure con Windows Server 2012

Hola a todos,

Hoy nos toca hablar de un tema que afecta a toda empresa que quiera integrar su infraestructura local con su infraestructura en Azure. Por supuesto, me refiero a los túneles S2S. Aunque ya hemos hablado de ellos, en este post vamos a detallar cómo hacer la configuración en el caso de usar una máquina Windows Server 2012.

A modo de resumen, un túnel Site-to-Site (S2S para los amigos), nos permite extender nuestra red local hasta Azure, de forma que las máquinas virtuales allí hospedadas puedan acceder a nuestros recursos locales y viceversa, todo de forma transparente al usuario.

Diagrama básico de la conexión.
Diagrama básico de la conexión.

Para llevar a cabo esta tarea, los requisitos no son muy elevados. En uno de los casos más básicos, nos basta con disponer de una suscripción a Azure, y una máquina con Windows Server 2012 (o 2012 R2) en nuestra intranet, que esté conectado directamente a Internet (con una IP pública). Hay otras posibles configuraciones, como una implementación con GNU/Linux que ya publicamos en nuestro blog.

Seguir leyendo Túneles Site-2-Site en Azure con Windows Server 2012

Cuidado con los puertos dinámicos

Aunque el soporte de Windows Server 2003 ya acabó hace tiempo (el principal, el extendido todavía está vigente), al igual que pasa con el puesto cliente y Windows XP, seguimos encontrándolos en la mayoría de proyectos.

Es por eso que me gustaría recuperar un post de mi blog personal que escribí hace tiempo y que fue un caso recurrente en mis días de soporte en Microsoft.

Nos podemos encontrar con problemas de comunicación en un entorno donde tenemos servidores con Windows Server 2003 mezclados con Windows Server 2008 o superior. Esto viene por un cambio importante relativo al rango de los puertos dinámicos o efímeros que se produjo entre ambas versiones.

En la documentación oficial de Microsoft, esta es la razón que se dio para este cambio:

A fin de cumplir las recomendaciones de la Agencia de asignación de números Internet (IANA), Microsoft ha aumentado el intervalo de puertos de cliente dinámicos para las conexiones de salida en Windows Vista y en Windows Server 2008. El nuevo puerto de inicio predeterminado es el 49152 y el puerto de fin predeterminado es 65535. Se trata de un cambio con respecto a la configuración de versiones anteriores de Microsoft Windows, que utilizaban un intervalo de puertos predeterminado comprendido entre el 1025 y el 5000.

Este es el artículo de KB donde viene toda la información: http://support.microsoft.com/kb/929851

Debemos tener esto en cuenta a la hora de configurar nuestros Firewall si estos son restrictivos con los puertos utilizados internamente para conectar nuestras máquinas.

Si tenemos un entorno con Windows Server 2003 con el rango de puertos dinámicos que va del puerto 1025 al 5000, los firewalls pueden estar configurados para aceptar únicamente conexiones dirigidas a estos puertos.

Si añadimos equipos con Windows Server 2008 o superior, debido a este nuevo rango de puertos, podemos experimentar problemas con la comunicación RPC entre los servidores.

  • Una opción en estos casos sería añadir las reglas del firewall que permitan el tráfico en el intervalo de puertos dinámicos comprendido entre el 49152 y el 65535.
  • Otra opción es modificar en cada servidor Windows Server 2008 el intervalo de puertos dinámicos utilizado para que se ajuste a los de 2003 (con la pérdida en cantidad de ellos que supone).

Este intervalo se ajusta mediante el comando netsh:

El puerto de inicio es número y el número total de puertos es intervalo.

A continuación se muestran algunos ejemplos de comandos:

El puerto de inicio mínimo que puede establecer es el 1025. El puerto de fin máximo, según el intervalo establecido, no puede superar el 65535.

Para duplicar el rango al comportamiento predeterminado de Windows Server 2003 (1025 – 5000) podemos utilizar en los servidores con 2008 o superior el ejemplo expuesto, en el que 1025 es el puerto de inicio y 3975 es el intervalo para TCP y UDP.

Esperamos que esta información os sirva, sobre todo en entornos donde empezáis a actualizar la infraestructura de servidores a versiones más modernas y tenéis un Firewall restrictivo por ahí.

Happy networking!

RADIUS, NPS y certificados Wildcard (2/2)

En el artículo de ayer veíamos un escenario donde queríamos configurar la autenticación de nuestra red Wireless para utilizar las credenciales de dominio. Para ello configurábamos un NPS como servidor RADIUS y como certificado utilizábamos un wildcard.

Veíamos que una vez configurado todo y cogiendo un cliente Windows cualquiera recibíamos un error y no podíamos iniciar sesión y conectarnos.

Hoy vamos a ver como analizar el problema y posibles soluciones.

Para ello lo mejor es empezar activando el tracing en el servidor NPS y ver que pasa cuando el punto de acceso nos manda la información con las credenciales del usuario a autenticar:

Esto nos genera dos ficheros de log en C:Windowstracing que son svchost_RASCHAP y svchost_RASTLS correspondientes a las 2 fases que se tienen lugar en la autenticación que hemos especificado. Nos fijamos en el segundo.

[1360] 08-09 14:02:30:859: EapPeapBegin

[1360] 08-09 14:02:30:859: EapPeapBegin – flags(0x2)

[1360] 08-09 14:02:30:859: PeapReadUserData dwSize:0x38

[1360] 08-09 14:02:30:859:

[1360] 08-09 14:02:30:859: EapTlsBegin(PLAINCONCEPTSamarcos)

[1360] 08-09 14:02:30:859: SetupMachineChangeNotification

[1360] 08-09 14:02:30:859: State change to Initial

[1360] 08-09 14:02:30:859: EapTlsBegin: Detected PEAP authentication

…..

[1360] 08-09 14:02:30:938: EapTlsSMakeMessage, state(3)

[1360] 08-09 14:02:30:938: Client sent an alert; negotiation unsuccessful

[1360] 08-09 14:02:30:938: GetAlert

[1360] 08-09 14:02:30:938: Error 0x8009030c

 

El error y sobre todo la razón del mismo, fue lo que nos dieron una pista muy importante. El cliente es el que manda la alerta de que la autenticación no se ha podido realizar correctamente.

Si vemos el siguiente artículo de Microsoft, se entiende mejor:

Certificates and NPS

http://technet.microsoft.com/en-us/library/cc772401(WS.10).aspx

IEEE 802.1X authentication provides authenticated access to 802.11 wireless networks and to wired Ethernet networks. 802.1X provides support for secure EAP types, such as TLS with smart cards or certificates. You can configure 802.1X with EAP-TLS in a variety of ways. If the Validate server certificate option is configured on the client, the client authenticates the server by using its certificate. Client computer and user authentication can be accomplished using certificates from the client certificate store or a smart card, providing mutual authentication.

With wireless clients, PEAP-MS-CHAP v2 can be used as the authentication method. PEAP-MS-CHAP v2 is a password-based user authentication method that uses TLS with server certificates. During PEAP-MS-CHAP v2 authentication, the IAS or RADIUS server supplies a certificate to validate its identity to the client. Client computer and user authentication is accomplished with passwords, which eliminates some of the difficulty of deploying certificates to wireless client computers.

 

Si las credenciales son correctas, y el cliente es el que está mandando la alerta, debe estar fallando el paso en el que “the IAS or RADIUS server supplies a certificate to validate its identity to the client”

Acudimos a los requisitos necesarios en cuanto a certificados para este tipo de escenarios:

Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS

http://support.microsoft.com/kb/814394/en-us

You can configure clients to validate server certificates by using the Validate server certificate option on the Authentication tab in the Network Connection properties. When a client uses PEAP-EAP-MS-Challenge Handshake Authentication Protocol (CHAP) version 2 authentication, PEAP with EAP-TLS authentication, or EAP-TLS authentication, the client accepts the server’s certificate when the certificate meets the following requirements:

  • The computer certificate on the server chains to one of the following:
    • A trusted Microsoft root CA.
    • A Microsoft stand-alone root or third-party root CA in an Active Directory domain that has an NTAuthCertificates store that contains the published root certificate. For more information about how to import third-party CA certificates, click the following article number to view the article in the Microsoft Knowledge Base:
      295663
      How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store
  • The IAS or the VPN server computer certificate is configured with the Server Authentication purpose. The object identifier for Server Authentication is 1.3.6.1.5.5.7.3.1.
  • The computer certificate does not fail any one of the checks that are performed by the CryptoAPI certificate store, and it does not fail any one of the requirements in the remote access policy.
  • The name in the Subject line of the server certificate matches the name that is configured on the client for the connection.
  • For wireless clients, the Subject Alternative Name (SubjectAltName) extension contains the server’s fully qualified domain name (FQDN).
  • If the client is configured to trust a server certificate with a specific name, the user is prompted to make a decision about trusting a certificate with a different name. If the user rejects the certificate, authentication fails. If the user accepts the certificate, the certificate is added to the local computer trusted root certificate store.

 

Y aquí viene nuestro problema. Al estar utilizando un certificado wildcard, el SAN del mismo va dirigido a *.plainconcepts.com, pero eso no es explícitamente el FQDN del servidor RADIUS. Por tanto, la validación del certificado y del servidor no se produce correctamente, y la autenticación falla.

Los clientes Windows son los únicos que por defecto en una conexión de este tipo verifican el certificado del servidor. Los otros clientes con los que hemos probado (Android, iOS o OSX) te advierten previamente de que no van a verificar el certificado del servidor y funcionan OK. Esto aun así puede provocar un problema de seguridad si te realizan un man in the middle.

Comprobamos que efectivamente este es el problema desactivando en el cliente la opción de la conexión Wireless de la oficina que verifica el certificado del servidor:

VerificarCert
Casilla para desactivar la validación del certificado del servidor

 

Si volvemos a probar y cogemos una traza de red vemos como todo va sobre ruedas:

4181        14:03:51 09/08/2013        180.2069361        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = Identity

4182        14:03:51 09/08/2013        180.2129407        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP,PEAP start

4183        14:03:51 09/08/2013        180.2269086        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Client Hello.

4184        14:03:51 09/08/2013        180.2278678        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 HandShake: Encrypted Handshake Message.

4186        14:03:51 09/08/2013        180.2469132        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4187        14:03:51 09/08/2013        180.2475661        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4188        14:03:51 09/08/2013        180.2669155        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Certificate. Client Key Exchange.

4189        14:03:51 09/08/2013        180.2736570        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message.

4190        14:03:51 09/08/2013        180.2868939        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4192        14:03:51 09/08/2013        180.2880059        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4193        14:03:51 09/08/2013        180.2968700        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4194        14:03:51 09/08/2013        180.2976007        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4195        14:03:51 09/08/2013        180.3069125        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4196        14:03:51 09/08/2013        180.3121415        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4197        14:03:51 09/08/2013        180.3269171        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4198        14:03:51 09/08/2013        180.3294832        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4199        14:03:51 09/08/2013        180.3370064        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4200        14:03:51 09/08/2013        180.3387234        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4201        14:03:51 09/08/2013        180.3570453        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4202        14:03:51 09/08/2013        180.3598720        svchost.exe        DC5         192.168.2.1        EAP        EAP:Success

 

¿Qué soluciones planteamos ante un escenario así?

Estas son las que nosotros pusimos encima de la mesa:

  1. Comprar un certificado para el NPS que cumpla estrictamente con los requisitos que comentábamos arriba. Sobre todo que el SAN sea el FQDN del NPS. Unos 300€ al año.
  2. Crear uno auto-firmado y distribuirlo a todos los clientes.
  3. Por GPO deshabilitar la verificación del certificado del servidor. Como es algo que hay que cambiar a nivel de la conexión wifi en el cliente, hay que generar una conexión wifi para el perfil con el mismo nombre y con la casilla desactivada.

Esperamos que os haya gustado el artículo. Happy networking!

RADIUS, NPS y certificados Wildcard (1/2)

Hace un tiempo en Plain Concepts nos planteamos la posibilidad de cambiar la autenticación en la red wifi para poder utilizar nuestro usuario y contraseña de dominio. Este tipo de autenticación es conocida como RADIUS, y en el caso de las redes Wireless el AP o punto de acceso actúa como cliente RADIUS, hablando luego con el servidor RADIUS que realiza la autenticación en última instancia contra el directorio de usuarios correspondiente.

Como servidor RADIUS nos planteamos utilizar NPS (Network Policy Server), un rol incluido dentro de Windows Server de Microsoft, y que podíamos instalar en una VM.

Al intentar utilizar NPS nos encontramos con un problema que es el que intentaremos plasmar en este artículo, así como posibles soluciones.

La configuración es muy simple en el caso del AP, únicamente hay que especificar la dirección IP, el puerto (por defecto RADIUS trabaja con el 1812, y la clave compartida que van a utilizar cliente y servidor):

AP
Nuestro punto de acceso wifi y la configuración para conectarse al servidor RADIUS

Configurar el servidor NPS también es bastante sencillo, definiendo el grupo de usuarios que van a poder acceder a la red interna utilizando su usuario y contraseña corporativos y el método de autenticación a utilizar, en nuestro caso PEAP con MSCHAPv2,  usando como certificado un wildcard que utilizamos para multitud de cosas.

users
Usuarios que van a poder autenticar utilizando RADIUS
wildcard
Configuración del servidor RADIUS / NPS

Completamos el resto de la configuración, cogemos un cliente con Windows 8.1 cualquiera, nos vamos a conectar y ouch! recibimos un error. No tengo pantallazo del mismo, pero si tenemos una bonita traza de red 🙂

Esto es lo que se ve entre el cliente RADIUS (AP) y nuestro servidor RADIUS  / NPS (DC5). Como os comentábamos antes, el servidor RADIUS en última instancia autenticará al usuario contra el directorio correspondiente, en nuestro caso al ser un entorno Windows lo hará contra un Controlador de Dominio utilizando Kerberos, por lo que el instalar el rol de NPS en un DC nos dará mayor rapidez en la operación.

2719        14:02:30 09/08/2013        99.9773874        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = Identity

2720        14:02:30 09/08/2013        99.9832878        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP,PEAP start

2721        14:02:30 09/08/2013        99.9973892        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Client Hello.

2722        14:02:30 09/08/2013        99.9983551        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate.

2724        14:02:30 09/08/2013        100.0173182        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

2725        14:02:30 09/08/2013        100.0180056        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

2726        14:02:30 09/08/2013        100.0374329        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Certificate. Client Key Exchange.

2727        14:02:30 09/08/2013        100.0441988        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message.

2728        14:02:30 09/08/2013        100.0672320        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 Encrypted Alert

2729        14:02:30 09/08/2013        100.0681224        svchost.exe        DC5         192.168.2.1        EAP        EAP:Failure

 

Toda la comunicación se realiza correctamente pero falla en uno de los últimos pasos. El error que veis en las trazas suele aparecer cuando no se ha podido autenticar correctamente al cliente, es decir, normalmente ocurre cuando las credenciales no son correctas.

Pero nos hemos asegurado de que sean correctas. ¿Qué puede fallar entonces?

Lo veremos en el próximo capítulo 🙂

 

Problemas mezclando controladores de dominio de Windows Server 2003 con controladores de dominio de Windows Server 2012 R2

Actualización (2015/1/22): Ya hay disponible un hotfix en http://support.microsoft.com/kb/2989971

Estoy trabajando en un proyecto donde estamos haciendo una extensión de red en Microsoft Azure a través de tunel Site to Site y entre las primeras tareas a llevar a cabo es replicar un par de controladores de dominio en máquinas de Azure.

El dominio se encuentra en modo funcional de Windows Server 2003 y los servidores son, evidentemente, Windows Server 2003 (en efecto, ¡están fuera de soporte!). Más allá de lo poco recomendable que es a día de hoy mantener sistemas con Windows XP o Windows Server 2003, me he topado con este post del blog oficial del equipo de soporte de AD DS.

El problema consiste en un fallo en la autenticación por Kerberos que ocasiona que los usuarios no puedan iniciar sesión de forma aleatoria. El problema aparece si tenemos el siguiente cóctail:

  • Controladores de dominio con Windows Server 2003.
  • Controladores de dominio con Windows Server 2012 R2.
  • Ambos tipos de controladores sirviendo para el mismo dominio.

El problema se produce por el cifrado utilizado a la hora de generar los hashes de las contraseñas en la autenticación por Kerberos, debido a que:

  • Los DC con Windows Server 2003 no soportan usar AES para generar los hashes. Estos utilizan DES.
  • Los DC con Windows Server 2012 R2 no soportan usar DES para generar los hashes. Estos utilizan AES.

Algunas de las posibles soluciones son:

  • Utilizar Windows Server 2012 para nuestros controladores de dominio, que no está afectado por el problema.
  • Desactivar el cifrado por AES en el apartado de “Tipos de cifrado soportados” en las GPO. Esto hará que los controladores de dominio usen RC4-HMAC que está soportado tanto en 2003 como en 2012 y 2012 R2.
  • Otras opciones detalladas en el artículo original.

Mientras tanto, Microsoft ha confirmado oficialmente que están trabajando en un hotfix para el problema.

Enlace relacionado: It turns out that weird things can happen when you mix Windows Server 2003 and Windows Server 2012 R2 domain controllers