Controlador de dominio secundario con Debian: poniendo los huevos en distintas cestas

Quizá el título sea un poco disruptivo, pero hoy vengo con algo que me sucedió a mi personalmente en el pasado, y que hoy me sirve de ejemplo para esta entrada.

Todos conocemos la importancia de la continuidad de negocio en una empresa y lo crítico que es tener, aunque sea, a 10 personas paradas. Porque no nos engañemos, el tiempo de esas 10 personas paradas es dinero que le cuesta a la empresa.

Como soy una persona que le gusta ser previsora, en su día decidí implantar un controlador de dominio secundario en Linux, por lo que pudiera pasar, adelantandome a posibles errores.

Después de lo que pasó recientemente con Crowdstrike, que dejó miles de equipos Windows inservibles, a nadie le parece raro que de repente toda una infraestructura basada en la misma tecnología deje de funcionar de golpe, ¿verdad?

Pues en aquella época aún no había pasado algo tan gordo como el ejemplo comentado, pero siempre me gusta tener un "por si acaso".

Bien, llegó un día en el que llegué a la oficina, miré la monitorización y... LOS DOS CONTROLADORES DE DOMINIO EN WINDOWS ESTABAN CAÍDOS.

Lo primero que hice fue preguntar a la gente del equipo si estaban haciendo algún tipo de mantenimiento, siendo negativa la respuesta.

Reconozco que aquí me vino un escalofrío.

Cuando entré en el hipervisor para visualizar lo que estaba pasando (quizá simplemente no tenían red) vi que estaban en un bucle infinito de intentar repararse a sí mismos. Menuda casualidad, los dos DC han caído a la vez.

Tardé unas cuantas horas intentando arreglar el problema, pero no había forma de recuperar la situación. Y como todos sabemos, no se debería recuperar de un backup o un snapshot un controlador de dominio. Esto se debe a los USN, y a que se crearía una inconsistencia en el dominio.

Así que me tocó rehacer de nuevo los DC, teniendo como principal en ese momento el servidor que en su día había sido concebido como respaldo para situaciones como esta.

Gracias a esa previsión se evitó tener a 170 personas paralizadas sin poder loggearse en los sistemas y, por ende, sin poder trabajar. Seguro que si pasa eso a nuestro jefe no le haría mucha gracia tener que mandar a todo el mundo a casa.

Desde entonces, mi "manía" por querer diversificar los "huevos en distintas cestas" se ha intensificado.

Y por si alguna vez os planteáis un escenario como el que me pasó a mi, aquí os dejo cómo lo hice. Pero antes...

---

Active Directory: ¿qué es?

Reconozco que en gestión de usuarios, Microsoft siempre se ha llevado la palma. Es simple y sencillo, con una interfaz gráfica amigable. Pero su documentación, como en general con Microsoft, no es del todo buena.

Active directory es una estructura jerarquica que almacena información acerca de objetos de la red, así como dominios, sitios, usuarios, grupos... Está orientado a infraestructuras Microsoft, pero, ¿nos prohíbe usar Linux en estos entornos?

Para nada, ya que Linux nos ofrece herramientas para ser compatible con todo (o casi todo) lo que Windows nos ofrece.

Active directory es un conjunto de protocolos que hacen un todo: LDAP para la gestión de usuarios (concretamente LDAPv3), DNS, DHCP, Kerberos (protocolo de autenticación).

Pero bueno, si Active Directory es propietario de Microsoft, ¿qué podemos hacer al respecto?

---

Linux al rescate: samba-ad como controlador de dominio

Existen varias implementaciones de LDAP en Linux, pero no son más que gestores de identidad, y no ofrecen lo mismo que ofrece Active Directory.

Para esto, tenemos samba, el cual se complementa perfectamente con todos los servicios de Microsoft.

Active directory usa LDAPv3, al igual que samba-ad. Utiliza los puertos 389 para las peticiones LDAP y el puerto 636 para LDAP-S (cifrado con SSL/TLS). Además, utiliza esquemas específicos de Microsoft. Para su compatibilidad, Samba imita el mismo esquema de Active Directory, así como los puertos.

Desde Samba también podemos gestionar las OU (unidades organizativas) así como las GPO.

---

Creando nuestro DC en Linux

El primer paso que tenemos que hacer, como creo que es obvio, es actualizar los repositorios de nuestro servidor. Pero antes de eso, deberemos añadir los repositorios backports de Debian (en mi caso) o compilar nuestra propia versión. Esto tiene un motivo, y es que samba por defecto solo soporta un nivel funcional de bosque hasta 2008. No es hasta las últimas versiones que permite nuevos niveles funcionales.

En mi caso, como el nivel funcional es 2016, necesito la ultima version.

Modificamos el fichero /etc/apt/sources.list:

nano /etc/apt/sources.list

Y añadimos la siguiente linea:

deb http://deb.debian.org/debian/ bookworm-backports main

Y actualizamos con:

apt update -y

Primero añadimos en el archivo /etc/resolv.conf el servidor AD que hace también de DNS, con la siguiente configuración:

Ahora tenemos que instalar ciertos paquetes necesarios para la vinculación y el funcionamiento. Indicamos que queremos que los coja del repositorio de backports:

apt install -t bookworm-backports samba libnss-winbind libpam-winbind winbind krb5-config krb5-user

Nos pedirá el reino predeterminado, es decir, el dominio. Las buenas prácticas dicen que hay que ponerlo en mayúsculas.

Deberemos modificar el fichero /etc/krb5.conf.

En el apartado [libdefaults] vemos que default_realm ya está puesto nuestro dominio, pero hay que hacer una modificación.

En [realms] añadimos según nuestros datos:

Modificamos el /etc/nsswitch y añadimos la opción LDAP:

Y ejecutamos los siguientes comandos:

dpkg-reconfigure libpam-winbind
dpkg-reconfigure libnss-winbind

Pedimos un ticket kerberos al controlador de dominio:

kinit administrador

Y verificamos que tenemos el ticket kerberos:

klist

Antes de todo moveremos el fichero de samba para que no genere problemas:

mv /etc/samba/smb.conf /etc/samba/smb.conf.BAK

Ahora ha llegado el momento de unir el servidor como controlador de dominio con la siguiente instrucción:

samba-tool domain join PRUEBAS.INTERNAL DC -U "administrador" --option="ad dc functional level = 2016"

La flag --option="ad dc functional level = 2016" es la más importante, ya que es la que nos permitirá unirnos a dominios con niveles superiores a 2008.

Y como vemos, se ha añadido como DC:

Si ejecutamos:

samba-tool user list

Podremos ver los usuarios que existen en el dominio.

Pero tenemos un problema, no se replica. Si intentamos forzar la replicación:

Esto es porque necesitamos una librería para RPC, que es el protocolo de comunicación que usa Microsoft.

apt install librpc-xml-perl

Deberemos hacer previamente una modificación en el archivo /etc/hosts.

Ahora, podemos ejecutar el comando:

Vamos a hacer una prueba y vamos a crear varios usuarios que no existen:

Como se ve, no hay usuarios creados, y los vamos a crear desde samba:

samba-tool user add <usuario>

Esta es la sintaxis más sencilla, pero para el ejemplo nos sirve.

Forzamos la replicación o esperamos a la replicación, que suele estar entre 15 y 30 minutos.

Y como vemos, los usuarios se han creado.

Este es un ejemplo de, como digo, no tener los huevos en la misma cesta.

Un ejemplo de todo lo que nos ofrece samba-ad:

¡Espero que os sirva para futuro!

AÑADIDO: Quizá os pase como a mi en una ocasión, y era que no se replicaba. Esto fue porque en el fichero smb.conf no se habían creado las carpetas sysvol y netlogon: