Active Directory con Software Libre para Pymes: la versión que sobrevive a producción (Debian 13)

El mito más grande de la informática comercial es que para tener una red segura y profesional hacen falta servidores de miles de dólares y licencias corporativas impagables. Es mentira: con Samba 4 sobre Debian 13 armás un Active Directory libre de licencias, un servidor de archivos centralizado, respaldos automáticos y una VPN para sucursales y teletrabajo, todo sobre hardware modesto.

Pero hay un segundo mito, más peligroso porque viene disfrazado de solución: los tutoriales que circulan en español —traducciones automáticas, scripts copiados que nadie se gastó en auditar— montan una arquitectura que sobrevive a la demo y se desarma en producción. Este artículo es las dos cosas a la vez: la guía para construirlo, y la auditoría brutal de los cinco errores que hacen que esa guía "tipo NASA" se caiga sola tres semanas después. Medimos contra la documentación oficial, el SambaWiki y el comportamiento real de los protocolos, no contra el folclore de los foros.

La arquitectura honesta, en una frase

Separación de funciones. El Controlador de Dominio autentica y nada más; los archivos viven en un servidor miembro; el reloj es un requisito criptográfico, no un adorno; el backup tiene versiones y una copia fuera de la red; y nada entra a producción sin haberse verificado. Todo lo demás son detalles de esa idea.

A partir de acá, cada decisión de diseño viene acompañada del error típico que reemplaza.

---

Parte 1 — Los cinco errores que circulan (y cómo se corrigen)

1. El realm .local es un error de manual (mDNS)

Usar el sufijo .local como TLD del realm de Active Directory es el error de primer año más común. El propio equipo de Samba advierte explícitamente que no se use, porque .local está reservado para Avahi/mDNS (Multicast DNS) y el descubrimiento de servicios en la red local. Hacer coincidir tu dominio de AD con .local genera colisiones de resolución y caídas de paquetes intermitentes.

Y lo que lo vuelve fatal: Samba no soporta renombrar la zona DNS del AD ni el realm de Kerberos una vez provisionado el dominio. Si seguiste la guía típica con EMPRESA.LOCAL, no hay corrección posible sin destruir el dominio y empezar de cero.

• Hacelo bien: Un subdominio bajo tu control (ad.empresa.com.ar) o un sufijo privado dedicado (empresa.internal). Elegilo una sola vez y para siempre.

2. Servidor de archivos sobre el DC: el monolito frágil

Montar las carpetas compartidas directamente sobre el AD/DC es el corazón de casi todos los scripts automatizados, y es justo lo que Samba desaconseja. El AD/DC debe ser un nodo aislado dedicado a autenticación y autorización (Kerberos/LDAP); los recursos compartidos van en servidores miembro unidos al dominio.

Hay un detalle técnico que delata el monolito: poner browseable = yes en los shares del DC no hace nada, porque el smbd operando en modo Active Directory DC no soporta el browsing de red. Además el smb.conf de un DC es autogenerado y especial: inyectarle shares a mano lo vuelve frágil ante cada actualización de paquetes.

# La forma frágil: modificar el smb.conf del propio DC
[ventas]
    path = /srv/samba/ventas
    browseable = yes   ; <- el smbd en modo DC ignora esta directiva
    writable = yes

• Hacelo bien: El DC autentica; un servidor miembro (puede ser otra VM en el mismo fierro físico) sirve los archivos, con ACLs reales del dominio. El "Paso B" del manual lo muestra.

3. Omitir la sincronización horaria es matar a Kerberos

No configurar chrony ni un daemon NTP en un despliegue de AD es dejar una bomba con el reloj andando. Kerberos usa marcas de tiempo para prevenir ataques de repetición: si el desfasaje entre el DC y el cliente supera los 5 minutos (el valor por defecto), la autenticación falla de inmediato. Una demo que "anduvo impecable el primer día" colapsa semanas después por la deriva natural de los relojes de hardware.

• Hacelo bien: chrony en el DC atado a un pool confiable y, además, sirviendo hora firmada a los clientes Windows. Config en el manual.

4. El espejo rsync --delete no es un backup anti-ransomware

Acá está la grieta de honestidad más grande de la internet hispana. Es común ver scripts que prometen "inmunidad total al ransomware" con esto:

# El script que promete inmunidad y entrega lo contrario
rsync -avz --delete /srv/samba/ /mnt/backup/

El --delete destruye cualquier resiliencia. Si un ransomware cifra las carpetas compartidas y el cron corre a las 2:00 AM, rsync mirrors fielmente los archivos cifrados hacia el respaldo y borra las versiones limpias del día anterior. Tu copia queda idéntica de destruida.

Para colmo, dejar el backup en /mnt/backup dentro de la misma máquina viola el 3-2-1: la pata offsite, aislada de la red, es innegociable. (Detalle menor: el -z en un rsync hacia un disco local solo gasta CPU comprimiendo y descomprimiendo sobre el bus interno).

• Hacelo bien: Snapshots versionados y aislados. BorgBackup o Restic (con cifrado y repositorio remoto), rsync --link-dest con rotación de hard-links, o snapshots de ZFS/Btrfs. El backup debe poder mirar al ayer, no solo al ahora.

5. Comandos interactivos colgados en un cron ciego

Para automatizar el respaldo de la base del AD se ve mucho esto:

samba-tool domain backup online --configfile=/etc/samba/smb.conf

Va a fallar en un cron desatendido: el modo online exige --server y credenciales (-U administrator). A las 2:00 AM el proceso se cuelga esperando una contraseña por teclado, o aborta por sintaxis.

• Hacelo bien: Para un respaldo local en el propio DC, el motor correcto es offline, que vuelca las bases (.ldb/.tdb) con los bloqueos internos necesarios, sin autenticación interactiva y sin tirar el servicio abajo:

samba-tool domain backup offline --targetdir=/var/backups/samba/ad

Si insistís con online, va apuntando a localhost y con un archivo de credenciales en chmod 600.

Y las omisiones de producción que nadie cuenta

• Permisos por rol que no son por rol: Prometer "Ventas solo entra a su carpeta" con chown root:"domain admins" + chmod 770 es POSIX plano: hereda en bloque y no distingue grupos del dominio. Para mapear grupos de AD como en Windows hacen falta vfs objects = acl_xattr, map acl inherit = yes y gestión con setfacl.
• Punto único de falla: No es "empresarial" nada que dependa de un solo DC. Mínimo dos, sabiendo que Samba no replica SysVol (las GPO) automáticamente: eso se scriptea aparte.
• Fricción real con Windows 11: "Compatibilidad absoluta plug-and-play" ignora el endurecimiento moderno de Microsoft: las builds actuales exigen firma de paquetes SMB y LDAP channel binding. Funciona muy bien, pero requiere ajustes; transparente no es.

---

Parte 2 — Manual técnico corregido (Debian 13 "Trixie")

Base: Debian 13 estable (kernel 6.12 LTS), IP estática, y el realm elegido para siempre. En los ejemplos uso ad.empresa.com.ar (realm en mayúsculas: AD.EMPRESA.COM.AR) y el DC dc1.ad.empresa.com.ar.

Paso A — Provisión del Controlador de Dominio

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y samba smbclient krb5-user winbind \
                    libpam-winbind libnss-winbind acl attr chrony

En la pantalla de Kerberos, el Realm en mayúsculas: AD.EMPRESA.COM.AR.

El bug más silencioso del despliegue está acá. Casi todo el mundo limpia el /etc/samba/smb.conf antes de provisionar, pero se olvida del /etc/hosts. En un DC, el FQDN y el nombre corto tienen que resolver a la IP de LAN, nunca a loopback: Samba registra sus SPN y sus registros DNS contra esa IP, y si el FQDN cae en 127.0.0.1 el controlador se anuncia mal y rompe la unión de clientes.

El problema es que una instalación fresca de Debian deja por defecto una línea 127.0.1.1 con el nombre de la máquina:

# Lo que Debian deja por defecto (HAY QUE BORRAR la línea 127.0.1.1)
127.0.0.1     localhost
127.0.1.1     dc1.ad.empresa.com.ar   dc1   # <- arrastra el FQDN al loopback

Si la dejás, el FQDN resuelve a 127.0.1.1 y se arruina el provisionamiento. El /etc/hosts del DC tiene que quedar así, con el FQDN apuntado a la IP real:

127.0.0.1     localhost
192.168.1.10  dc1.ad.empresa.com.ar   dc1

Verificalo antes de seguir; estos tres comandos tienen que devolver la IP de LAN y no 127.0.x.x:

hostname -f                          # -> dc1.ad.empresa.com.ar
getent hosts dc1.ad.empresa.com.ar   # -> 192.168.1.10
getent hosts dc1                     # -> 192.168.1.10

Limpieza y provisión (el smb.conf lo genera Samba):

sudo systemctl disable --now smbd nmbd winbind
sudo rm -f /etc/samba/smb.conf
sudo samba-tool domain provision --use-rfc2307 --interactive
# Realm: AD.EMPRESA.COM.AR | Domain: EMPRESA | Role: dc
# DNS backend: SAMBA_INTERNAL | Forwarder: 1.1.1.1

sudo ln -sf /var/lib/samba/private/krb5.conf /etc/krb5.conf
sudo systemctl unmask samba-ad-dc
sudo systemctl enable --now samba-ad-dc
kinit administrator@AD.EMPRESA.COM.AR && klist

El DC debe usarse a sí mismo como DNS. Desactivá lo que reescriba resolv.conf y apuntá nameserver 192.168.1.10.

Paso B — Reloj firmado (chrony en el DC)

Sin esto, todo lo anterior se cae en semanas. En /etc/chrony/chrony.conf:

pool 2.debian.pool.ntp.org iburst
ntpsigndsocket /var/lib/samba/ntp_signd
allow 192.168.1.0/24

sudo systemctl restart chrony
# permitir que chrony firme la hora para los clientes del dominio
sudo setfacl -m u:_chrony:rx /var/lib/samba/ntp_signd

Paso C — Servidor de archivos en un member server (no en el DC)

En una máquina aparte (o una VM en el mismo fierro) unida al dominio, con security = ads y winbind. El smb.conf del miembro, en lo esencial:

[global]
    workgroup = EMPRESA
    realm = AD.EMPRESA.COM.AR
    security = ads
    winbind use default domain = yes
    template shell = /bin/bash
    idmap config * : backend = tdb
    idmap config * : range = 3000-7999
    idmap config EMPRESA : backend = rid
    idmap config EMPRESA : range = 10000-999999
    vfs objects = acl_xattr
    map acl inherit = yes
    store dos attributes = yes

[ventas]
    path = /srv/samba/ventas
    read only = no

sudo net ads join -U administrator
sudo systemctl enable --now smbd winbind
# nsswitch.conf: agregar 'winbind' en passwd y group

Y los permisos sí por grupo del dominio, con ACLs reales:

sudo mkdir -p /srv/samba/ventas
sudo setfacl -m "g:EMPRESA\\ventas:rwx" /srv/samba/ventas
sudo setfacl -m "g:EMPRESA\\gerencia:rwx" /srv/samba/autorizaciones

Paso D — Backup versionado, automatizable y offsite

Dos piezas: la base del AD (en el DC, modo offline) y el árbol de archivos (en el member, con versiones). Borg da cifrado, deduplicación y repositorio remoto en un solo paso.

#!/bin/bash
# /usr/local/bin/backup_ad.sh  (en el DC, chmod 700)
set -euo pipefail
DEST="/var/backups/samba/ad"
mkdir -p "$DEST"
samba-tool domain backup offline --targetdir="$DEST"
# rotación: conservar 14 días
find "$DEST" -name 'samba-backup-*.tar.bz2' -mtime +14 -delete

#!/bin/bash
# /usr/local/bin/backup_files.sh  (en el member server)
set -euo pipefail
export BORG_PASSPHRASE='...'         # mejor: BORG_PASSCOMMAND con un secreto en disco
REPO='ssh://backup@offsite.empresa.com.ar/~/borg-pyme'
borg create --compression zstd "$REPO::{hostname}-{now}" /srv/samba
borg prune "$REPO" --keep-daily=7 --keep-weekly=4 --keep-monthly=6

Crontab de sistema (sudo crontab -e):

0 2 * * * /usr/local/bin/backup_ad.sh    >> /var/log/backup_ad.log    2>&1
30 2 * * * /usr/local/bin/backup_files.sh >> /var/log/backup_files.log 2>&1

Esto sí resiste un ransomware: el repositorio Borg está fuera de la red, cifrado, y guarda el ayer. Si el viernes te cifran producción, restaurás el snapshot del jueves.

Paso E — VPN para sucursales y teletrabajo (WireGuard)

WireGuard va integrado en el kernel de Debian 13. En el nodo perimetral:

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <clave_privada_servidor>

[Peer]                 # un empleado o sucursal
PublicKey  = <clave_publica_peer>
AllowedIPs = 10.10.0.2/32

sudo ufw allow 51820/udp
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wg.conf && sudo sysctl --system
sudo systemctl enable --now wg-quick@wg0

Las restricciones de acceso del dominio siguen al usuario por el túnel: la carpeta de gerencia la ve gerencia, esté en la oficina o en su casa. Para administración visual, un Mikrotik (WireGuard nativo en RouterOS), un gateway UniFi/Omada o un combo TP-Link Deco resuelven el mismo túnel con más comodidad.

Paso F — Lo que falta para merecer el título

Un firewall serio (nftables/ufw) en el DC, SMB1 deshabilitado, monitoreo del RAID (smartd, mdadm --monitor) y un segundo DC unido al dominio para que la palabra "robusto" no sea un chiste. Recordá replicar SysVol aparte: Samba no lo hace solo.

---

El costo real, sin el cuento espacial

Para 10 o 20 empleados, la base puede ser una máquina vieja con una buena fuente, un SSD chico para el sistema y dos HDD en espejo (RAID) para redundancia. Menos de 500 dólares de hardware y cero de licencias. Pero seamos honestos con la etiqueta: esto no es "certificación NASA", es ingeniería sólida y reproducible para una pyme. El RAID no es un backup (protege de un disco muerto, no de un borrado ni de un cifrado), y la resiliencia real la dan la separación de roles, el reloj firmado, el segundo DC y los snapshots offsite. Cuando la organización escala —una Facultad, por ejemplo— el mismo diseño crece con switches gestionados, VLANs y ruteo profesional.

---

Conclusión

Montar Active Directory con software libre es una solución corporativa viable y de alto rendimiento, pero no tolera configuraciones superficiales. La resiliencia no se demuestra en scripts llamativos que se rompen ante la primera actualización o el primer ataque: se demuestra leyendo el código, separando funciones, forzando la sincronización de los protocolos esenciales y diseñando el respaldo para el peor escenario, no para el mejor. El verdadero premio no es "tener un servidor": es tener el dato unificado, ordenado y a salvo, que recién entonces se vuelve una base sobre la que construir —incluida la analítica o la IA que quieras conectarle después. Domá tu infraestructura, auditá tus archivos y nunca pongas en producción una línea que no hayas verificado vos mismo.

Nota sobre las fuentes. Los criterios de diseño se contrastan contra la documentación oficial de Samba (SambaWiki, "Setting up Samba as an Active Directory Domain Controller" y la FAQ), la guía de Ubuntu Server sobre AD/DC, y las notas de versión de Debian 13. Los rangos de idmap, los nombres de grupo y las rutas son ilustrativos: adaptalos y verificalos contra tu propia red antes de llevarlos a producción.