Documento aquí el armado y la puesta en marcha del NAS que sirve como almacenamiento central de mi homelab. La pieza que me importa más en el post no es el ensamblaje físico —que es relativamente directo— sino la decisión de usar el Active Directory existente como única fuente de verdad de los usuarios que acceden al disco, en lugar de mantener cuentas locales en el NAS. Esa decisión cambia por completo cómo se opera el dispositivo en el día a día.

Hardware utilizado

El chasis es un AOOSTAR WTR Pro: mini-NAS con 4 bahías hot-swap para 3.5", 2 slots M.2 NVMe internos y 2 slots SODIMM. Está pensado para vivir encendido 24×7 sin hacer ruido y sin ocupar el espacio de un servidor rack.

• Chasis: AOOSTAR WTR Pro — 4× SATA hot-swap, 2× M.2 NVMe, 2× SODIMM DDR5.
• Almacenamiento principal: 4× Toshiba N300 de 6 TB (modelo HDWG760, 7200 RPM, firmware 0502). Estos discos están diseñados específicamente para NAS — workload rating 180 TB/año, MTBF alto, anti-vibración para chasis multi-disco.
• SSD de boot / cache: Kingston KC3000 NVMe (PCIe Gen4).
• RAM: 2× SODIMM DDR5, configuradas en dual-channel.

Ensamblaje

La placa madre va accesible por la tapa inferior del chasis. Primero RAM y NVMe, después los HDDs en sus bahías frontales.

Los HDDs van en caddies con tornillos laterales estándar. Es montaje sin herramientas en el frente del chasis — se introducen los caddies en sus bahías hasta que clickean.

Sistema operativo: TrueNAS Scale

Elegí TrueNAS Scale Goldeye (rama 25.10) por tres razones concretas:

• ZFS nativo: snapshots baratos, scrub periódico, integridad por checksum, replication a otro NAS si lo necesito.
• Base Linux moderna: a diferencia de TrueNAS Core (FreeBSD), permite ejecutar contenedores y apps modernos directamente desde el NAS.
• Integración SMB + Active Directory madura: Winbind, Kerberos y Samba están perfectamente cableados desde el web UI — sin tocar archivos de configuración a mano.

La instalación se hace booteando desde un pendrive con la imagen oficial; el target del SO es el NVMe (no se desperdicia una bahía HDD para el sistema). Lo único que conviene tener anotado antes de empezar es la IP/hostname que tendrá el NAS, la zona horaria, y la dirección de un servidor NTP interno si existe.

Topología ZFS

Sobre los 4 discos N300 monté un único pool en RAIDZ1 (3 datos + 1 paridad). Eso me da ≈ 18 TB usables, tolerancia a la pérdida de cualquier disco, y rendimiento de lectura agregado de los 4 discos. RAIDZ2 (doble paridad) sería más conservador, pero con solo 4 discos el costo de capacidad lo hace poco práctico — prefiero monitorear los discos y reemplazar proactivamente.

El pool se divide en datasets según el tipo de contenido (no comparto el detalle exacto del lab), cada uno con su propia política de snapshots:

• Datasets de trabajo activo: snapshots cada hora, retención 48 h.
• Datasets de archivo: snapshot diario, retención 90 días.
• Compresión lz4 habilitada por default (es esencialmente gratis en CPU).

La parte que importa: Active Directory como única fuente de verdad

Aquí la decisión de diseño que define toda la operación del NAS.

El problema con las cuentas locales

Por default, un NAS te invita a crear sus propios usuarios locales. Eso funciona si tienes 2 personas en una casa; deja de funcionar en cuanto:

• Hay más de un servicio que requiere identidad (NAS + dominio + correo + VPN + apps).
• Alguien debe entrar y salir limpiamente (un colaborador temporal, una persona que ya no debe tener acceso).
• Las ACLs del filesystem terminan apuntando a UIDs/SIDs locales que no significan nada en otro sistema.
• Necesitas auditar "quién accedió a qué" y los logs muestran usuarios distintos en cada servicio.

La consecuencia inevitable de mantener usuarios locales en el NAS es shadow accounts: copias divergentes de la misma persona en cada sistema, sin un dueño claro de la verdad. Cuando alguien sale del laboratorio, queda al menos una cuenta huérfana que nadie acuerda desactivar.

La solución: domain join

El NAS no tiene base de usuarios propia. Se une al dominio AD existente y delega toda la autenticación al Domain Controller vía Kerberos. Un solo lugar para crear, editar, deshabilitar y auditar identidades.

Concretamente, el flujo es:

1. En el web UI del NAS, en Directory Services → Active Directory, se ingresa el FQDN del dominio y una cuenta con permiso para unir máquinas (no es necesario que sea Domain Admin — basta con privilegio Join computer to domain sobre la OU destino).
2. El NAS crea su propio computerObject en AD y obtiene su keytab para Kerberos.
3. Desde ese momento, los usuarios del dominio existen para el NAS sin haberlos creado allí. Hacer id [email protected] en una shell del NAS resuelve UID/GID válidos.

Mapeo de identidades AD → POSIX (Winbind)

El subsistema de filesystem Unix no entiende SIDs de Windows — necesita UID/GID enteros. Winbind hace la traducción de forma determinística:

• Cada SID de un usuario AD se mapea a un UID = base + RID, donde base es un offset configurable en el NAS (por ejemplo 100000000).
• El mapeo es persistente y reproducible: el mismo SID siempre devuelve el mismo UID. Eso significa que las ACL almacenadas en el filesystem siguen siendo válidas aunque reinstale el NAS — basta con volver a unirlo al mismo dominio.
• Para grupos AD: GID = base + RID + 1. Útil para mapear ACLs a membresías.

Para resolver el GID exacto de un grupo desde la API REST del NAS:

POST /api/v2.0/group/get_group_obj
Authorization: Bearer <token>
Content-Type: application/json

{ "groupname": "DOMINIO\\NAS-Admins" }

# response
{
  "gr_name": "DOMINIO\\NAS-Admins",
  "gr_gid": 100004106,
  "gr_mem": ["DOMINIO\\sarah.connor", "DOMINIO\\felipe.h"],
  "source": "ACTIVEDIRECTORY"
}

Privilegios administrativos delegados a un grupo AD

Para administrar el NAS, en lugar de un usuario root local con su propia password (otro shadow account esperando expirar), creé un grupo de seguridad en AD —digamos NAS-Admins— y le asigné en TrueNAS un Privilege Profile con role FULL_ADMIN y web_shell=true.

# En el DC, agregar usuario al grupo AD
Add-ADGroupMember -Identity 'NAS-Admins' -Members 'sarah.connor'

Quien está en ese grupo entra al web UI con sus credenciales AD y administra el NAS con privilegios completos. Quien sale del grupo en AD pierde acceso inmediatamente — no hay que tocar el NAS.

ACL de shares

Las ACLs del filesystem apuntan directamente a SIDs/UIDs derivados de AD. Por ejemplo, un share de fotos al que escriben los miembros del grupo Lab-Users y administran los miembros de NAS-Admins:

/mnt/tank/photos
├── owner@:  DOMINIO\NAS-Admins      rwxpDdaARWcCos  ALLOW
├── group@:  DOMINIO\Lab-Users       rwxpDdaARWc--s  ALLOW
└── everyone@:                         -------       (deny implicit)

Los cambios de membresía en AD se propagan al siguiente login Kerberos del cliente (klist purge fuerza la renovación inmediata si se necesita testear).

Beneficios operacionales

• Onboarding: crear usuario AD + agregarlo al grupo correspondiente → acceso inmediato al share. Cero pasos en el NAS.
• Offboarding: deshabilitar el usuario en AD → al instante deja de poder montar el share, sin acordarme de borrar nada en el NAS.
• Auditoría unificada: los logs SMB del NAS muestran el mismo UserPrincipalName que el resto de los sistemas — un solo nombre por persona en todos los logs.
• Cero shadow accounts. La única fuente de verdad es el directorio.

Conclusión

El armado del hardware es la parte fácil y reversible — si decidiera cambiar de chasis o de discos, no se pierde el trabajo importante. Lo que sí persiste y vale la pena hacer bien desde el día uno es la integración con AD: una vez que los shares apuntan a SIDs del dominio en sus ACLs, todo el resto del setup pasa a ser intercambiable. Reinstalar el sistema operativo del NAS y volver a unirlo al dominio reconstruye todos los permisos sin tocar archivos por archivo.

Si está montando algo similar en su homelab y dudaba entre cuentas locales y dominio, mi recomendación es clara: dominio desde el primer minuto. La fricción inicial de configurar el join es trivial comparada con la deuda operacional de mantener cuentas paralelas en varios dispositivos.