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

Filtrado de atributos en Azure Active Directory, consideraciones a tener en cuenta

Cuando trabajamos con sincronización de Azure Active Directory (por ejemplo, para Office 365) podemos hacer el filtrado de objetos a sincronizar por unidad organizativa (OU) o bien por sus atributos.

En caso de que queramos hace el filtrado por atributo hay algunas cosas importantes que tener en cuenta:

  • El “filtrado” consiste en definir una regla para especificar qué objetos NO van a sincronizar. Todo lo que no cumpla esta regla sincronizará.
  • Sólo es válido para usuarios. Todos los grupos de distribución y seguridad del AD no se verán afectados por la regla, así como los contactos; por lo que sincronizarán independientemente de los que establezcamos. Esto se debe a que en el FIM subyacente a AAD Sync Tool estos objetos se encuentran ya filtrados mediante reglas de extensión que no son fácilmente modificables.
  • El filtrado en el FIM se establece de acuerdo a comparadores de cadenas, estando disponibles los siguientes:

    Captura del FIM incorporado en AAD Sync Tool, mostrando propiedades de filtrado de atributos que podemos encontrar en el Management Agent de Active Directory
    Captura del FIM incorporado en AAD Sync Tool, mostrando propiedades de filtrado de atributos que podemos encontrar en el Management Agent de Active Directory
  • Se pueden combinar múltiples operadores con múltiples atributos, pero la regla lógica que sigue para aplicar el filtro es siempre AND. Por ejemplo: si extensionAttribute15 equivale a “estudiante” y extensionAttribute14 equivale a “nosync” entonces filtrar (no sincronizar) el objeto.

Happy syncing!

Microsoft Azure Site to Site cross-premises usando GNU/Linux (Ubuntu 12.04 LTS) y StrongSwan

Siempre comento en los eventos y charlas que la realidad de las empresas y organizaciones no son escenarios donde puedan afrontar un cambio total de infraestructuras a la nube. Normalmente, tendremos una serie de servidores y un espacio habilitado como nuestro CPD que no pueden ser descartados de forma inmediata. Es por ello que si bien la nube puede ser el futuro, los escenarios híbridos son el presente. Un escenario híbrido en Microsoft Azure es aquel que nos permite utilizar las capacidades de la plataforma de Microsoft como si se tratase de una red que forma parte de la nuestra, de forma transparente.

Los más aventajados en redes entenderéis perfectamente de qué estoy hablado. Si es posible conectar múltiples sucursales con una oficina central a través de túneles site to site entre ellos, ¿por qué no íbamos a poder hacer lo mismo con una red virtual de Azure?

Escenario tipo de VPN site to site con Azure, usado en este caso para hospedar servidores de identidad para Office 365
Escenario tipo de VPN site to site con Azure, usado en este caso para hospedar servidores de identidad para Office 365

Microsoft Azure nos permite realizar conexiones site to site a sus redes virtuales a través de túneles IPsec, utilizando IKEv1 (enrutado estático) ó IKEv2 (enrutado dinámico) con -en teoría- cualquier dispositivo que cumpla con las especificaciones. Este un listado de dispositivos soportados y sus respectivos scripts de configuración. Veréis que es posible usar una máquina genérica con GNU/Linux y openSwan, sin embargo, este sólo soporta enrutamiento estático y en mi experiencia, el enrutamiento dinámico propicia enlaces más estables con Azure. Que un dispositivo o software no esté en esta lista no implica que no funcione, sino que Microsoft no ha certificado ni da soporte al mismo.

Por diversos motivos de redes que explicaré en otro post, en Plain Concepts utilizamos GNU/Linux como router y servidor de perímetro, por lo que necesitábamos un stack IPsec que funcionase bien con Microsoft Azure y soportase enrutamiento dinámico. strongSwan parecía la solución más obvia y… ¡acertamos de pleno! Tanto openSwan como strongSwan son forks del descontinuado freeSwan. No voy a entrar a valorar cual de las dos implementaciones es mejor, así que sólo comentaré que openSwan funcionó bien con enrutamiento estático y strongSwan con dinámico.

Requerimientos

  • Una máquina GNU/Linux con el kernel 2.6 o superior.
  • Al menos dos interfaces físicas ethernet.
  • Conectividad directa a Internet sin NAT. Una de las interfaces debe recibir directamente la IP pública de nuestro proveedor.

Como soy muy de Debian y distribuciones basadas en el mismo, como Ubuntu, vamos a hacer la instalación y configuración en esta última, concretamente en Ubuntu 12.04 LTS.

Configurar Microsoft Azure

  1. Configurar una nueva red virtual de Azure preparada para la conexión VPN site to site. Hay un artículo detallado aquí; pero también podéis ver el video de la charla que Alberto y servidor dimos en el TechDays 2014 de Microsoft.
  2. Crear una puerta de enlace. Basta con hacer clic en la opción correspondiente. Recordad que utilizaremos enrutamiento dinámico. Este proceso es simple pero a Azure le llevará entre 15-30 minutos en completarlo. Tenemos la excusa perfecta para un café 🙂

    Botón de selección de tipo de gateway en el momento de su creación.
    Botón de selección de tipo de gateway en el momento de su creación.
  3. Tomar nota de la IP de gateway y de la pre-shared key. Las necesitaremos para configurar strongSwan en Linux.

    Pre-Shared Key del gateway de Azure
    Pre-Shared Key del gateway de Azure

Configuración de Ubuntu con strongSwan

  1. En primer lugar instalamos strongSwan:

  2. Editamos el archivo de configuración /etc/ipsec.conf:

  3. Ahora debemos editar /etc/ipsec.secrets para establecer nuestra pre-shared key:

  4. Para finalizar, debemos instruir a iptables qué trafico es el que debe direccionar a través del túnel que hemos establecido:

Si todo ha ido bien, deberíamos ver la siguiente pantalla en el portal de Azure:

Pantalla de estado de nuestra conexión VPN site to site con Microsoft Azure
Pantalla de estado de nuestra conexión VPN site to site con Microsoft Azure

No hay que olvidar también que para que el kernel de Linux haga forwarding de nuestros paquetes es necesario habilitar dicha característica:

Si queremos que este cambio sea permanente hay que eliminar la marca de comentario (#) en la línea net.ipv4.ip_forward=1 en el archivo /etc/sysctl.conf.

Hecho esto, nuestras máquinas on-premises deberían ver perfectamente las que se encuentran en nuestra red virtual de Azure y viceversa.

Os dejo por último con la charla que Alberto y servidor dimos sobre estos temas, que aunque hablábamos de openSwan, la configuración y el trabajo para ponerlo a punto era muy análogo, por lo que lo podéis ver todo de forma muy gráfica.

Happy networking!

Write-Host “Hola Mundo”

Con este post pretendo inaugurar el blog corporativo del equipo de Enterprise IT en Plain Concepts. Queremos utilizar este espacio para comentar aquellas cuestiones o curiosidades técnicas con las que tratamos en nuestro día y a día y que sirva como ventana para mostrar ejemplos de áreas de trabajo y actuación del equipo.

Participantes en este blog:

  • Alberto Marcos González – Enterprise Architect
  • Antonio López Márquez – Cloud SaaS Specialist
  • Carlos Milán Figueredo – Enterprise Team Lead
  • Elena Sebastián Peña – IT Support Officer

¡Los comentarios y sugerencias serán bienvenidos!