Integración de sistemas operativos libres y propietarios

La integración de sistemas operativos libres y propietarios es una realidad habitual en empresas, centros educativos y organizaciones de todo tipo. Aunque a veces imaginamos una red formada únicamente por equipos Windows o por servidores GNU/Linux, lo normal es encontrar una combinación de plataformas, aplicaciones y dispositivos de distintos fabricantes.

Un servidor GNU/Linux puede almacenar archivos utilizados desde ordenadores Windows. Una impresora administrada mediante CUPS puede recibir trabajos desde varios sistemas operativos. Un usuario de Active Directory puede iniciar sesión en un equipo Linux. También es posible que una aplicación alojada en GNU/Linux dependa del DNS, los certificados o las cuentas gestionadas desde una infraestructura Windows.

El objetivo no consiste en conseguir que todos los equipos sean iguales. Lo importante es que puedan localizarse, autenticarse, intercambiar información y utilizar servicios comunes de una forma segura y predecible.

Por eso, la integración de sistemas operativos libres y propietarios no puede reducirse a instalar Samba, activar un recurso compartido y comprobar que aparece en el explorador de archivos. Una solución completa debe ocuparse de la red, los nombres, los protocolos, las identidades, los permisos, la seguridad y las pruebas.

En mis clases de Sistemas Operativos en Red suelo insistir en una idea: que dos equipos respondan al ping no significa que la integración esté terminada. El ping solo confirma una parte de la conectividad. Todavía debemos comprobar que el nombre se resuelve, que el puerto del servicio responde, que el usuario puede autenticarse y que sus permisos efectivos son los esperados. Mi experiencia en desarrollo, consultoría tecnológica y docencia me ha enseñado a abordar estos problemas dividiéndolos en partes, evitando cambios al azar y buscando soluciones que después puedan mantenerse.

En esta guía veremos cómo diseñar una red mixta, elegir entre SMB, NFS e IPP, configurar Samba, integrar GNU/Linux con Active Directory, compartir impresoras y diagnosticar los problemas más frecuentes. El contenido técnico procede del documento facilitado sobre integración de sistemas operativos libres y propietarios.

Qué es la integración de sistemas operativos libres y propietarios

Una red heterogénea es aquella en la que conviven sistemas operativos, dispositivos, protocolos o aplicaciones de diferentes fabricantes y familias tecnológicas. Esta diversidad no representa necesariamente un problema. De hecho, puede permitir que cada plataforma se utilice allí donde aporta más valor.

La interoperabilidad es la capacidad de varios sistemas distintos para intercambiar información y utilizarla correctamente. Para conseguirla no basta con emplear dispositivos conectados a la misma red. Es necesario que las distintas plataformas compartan protocolos, reglas de identificación y criterios de autorización compatibles.

Redes heterogéneas e interoperabilidad

Algunos escenarios habituales de integración son los siguientes:

• Un servidor Windows comparte carpetas con clientes Windows y GNU/Linux.
• Un servidor GNU/Linux con Samba proporciona almacenamiento a equipos Windows.
• Un servidor NFS publica directorios para estaciones Unix o Linux.
• Una impresora administrada mediante CUPS se utiliza desde Windows y GNU/Linux a través de IPP.
• Los usuarios de Active Directory acceden a estaciones de trabajo Linux.
• Una aplicación web alojada en GNU/Linux utiliza DNS y certificados gestionados por la infraestructura de la organización.

Todos estos casos comparten una característica: intervienen varias capas. Los equipos deben poder comunicarse por IP, localizarse mediante un nombre, utilizar un protocolo común, reconocer la identidad del usuario y decidir qué operaciones puede realizar.

Un fallo en una sola capa puede hacer que el servicio completo deje de funcionar. Por ejemplo, el servidor puede estar activo y correctamente configurado, pero un registro DNS antiguo puede dirigir al cliente hacia una dirección equivocada. Del mismo modo, el usuario puede autenticarse correctamente y seguir sin poder escribir porque los permisos del sistema de archivos local no se lo permiten.

Ventajas y dificultades de combinar Windows y GNU/Linux

La integración de sistemas operativos libres y propietarios permite aprovechar las herramientas especializadas de cada plataforma. También facilita las migraciones graduales y reduce la dependencia de un solo fabricante.

Una organización puede mantener determinados servicios en Windows, utilizar GNU/Linux para almacenamiento o aplicaciones web y permitir que todos los usuarios trabajen sobre recursos compartidos. No es necesario reemplazar toda la infraestructura al mismo tiempo.

Sin embargo, una red mixta también introduce dificultades:

• Los modelos de permisos e identidades son diferentes.
• No todos los clientes admiten las mismas versiones de los protocolos.
• La resolución de nombres y la sincronización horaria adquieren una importancia especial.
• El diagnóstico se complica porque intervienen varias plataformas.
• Las pruebas deben realizarse desde distintos clientes y con diferentes usuarios.
• La configuración necesita documentación para poder reproducirse y repararse.

La idea fundamental es diseñar la integración a partir de las necesidades reales. Instalar componentes sin una arquitectura previa puede conseguir que una prueba concreta funcione, pero suele generar una solución frágil.

Cómo planificar una red mixta antes de configurarla

Antes de instalar Samba, configurar NFS o unir un equipo a un dominio, conviene responder a una serie de preguntas básicas:

• ¿Qué equipo ofrecerá el servicio?
• ¿Qué clientes van a utilizarlo?
• ¿Qué datos o impresoras se compartirán?
• ¿Qué usuarios necesitan acceso?
• ¿Quién podrá leer, escribir, modificar o administrar?
• ¿Cómo se comprobará que el resultado es correcto?
• ¿Qué ocurrirá si el servicio deja de estar disponible?

En consultoría tecnológica aprendí que resulta fácil empezar hablando de herramientas demasiado pronto. Sin embargo, entender primero qué necesita la persona o la organización evita muchas configuraciones innecesarias. Esa misma forma de trabajar es útil en la integración de sistemas operativos libres y propietarios: primero se define el problema y después se elige la tecnología. Mi trayectoria combina desarrollo, integraciones, documentación, mejora de procesos y relación con clientes, un enfoque que me ayuda a tratar la infraestructura como una solución completa y no como una colección de comandos.

Inventario de servidores, clientes, usuarios y recursos

El inventario previo debería incluir, como mínimo:

Elemento	Información necesaria
Servidores	Nombre, FQDN, dirección IP, sistema operativo, versión, rol y responsable
Clientes	Sistema operativo, edición, arquitectura y pertenencia a dominio
Red	Subredes, VLAN, puertas de enlace, DNS, NTP y reglas de firewall
Identidades	Origen de las cuentas, grupos, SID, UID, GID y política de contraseñas
Recursos	Ruta local, nombre publicado, protocolo, permisos y cuotas
Impresoras	Modelo, controlador, cola, URI, ubicación y usuarios autorizados
Pruebas	Cliente, usuario, operación esperada y evidencia necesaria

Este inventario permite descubrir incompatibilidades antes del despliegue. Por ejemplo, puede revelar que un cliente no dispone del componente NFS necesario o que dos servidores utilizan el mismo nombre.

Elección de protocolos y arquitectura

Después del inventario deben tomarse varias decisiones:

1. Determinar si las cuentas serán locales o centralizadas.
2. Elegir el protocolo adecuado para cada recurso.
3. Decidir si el servidor trabajará de forma autónoma o dentro de un dominio.
4. Separar los datos, la configuración y las copias de seguridad.
5. Asignar permisos a grupos en lugar de hacerlo usuario por usuario.
6. Definir las necesidades de cifrado, firma, auditoría y conservación de registros.
7. Preparar un procedimiento de recuperación y reversión.

Un modelo de laboratorio podría utilizar un dominio como aula.local, un controlador de dominio y DNS llamado dc01.aula.local, un servidor Linux fs01.aula.local y clientes Windows y GNU/Linux. Los recursos podrían publicarse como carpetas SMB, exportaciones NFS y colas IPP.

Los nombres son secundarios. Lo importante es que todos los elementos estén registrados y que cada uno tenga un propósito definido.

Cuentas locales o identidades centralizadas

Las cuentas locales duplicadas pueden ser suficientes en un laboratorio muy pequeño. El problema aparece cuando las contraseñas, los grupos o los identificadores dejan de coincidir entre los distintos equipos.

Un servidor Samba autónomo centraliza las cuentas necesarias para sus recursos, pero esas identidades no se reutilizan automáticamente en toda la infraestructura.

Active Directory permite centralizar usuarios, grupos, políticas y autenticación. A cambio, exige un DNS correcto, sincronización horaria y componentes de integración. También pueden utilizarse tecnologías como LDAP, Kerberos o FreeIPA, aunque los clientes Windows pueden necesitar configuraciones adicionales.

La decisión debe tomarse pensando en el tamaño del entorno y en su mantenimiento futuro, no solo en la rapidez de la primera instalación.

Las capas que deben funcionar en una integración

Una integración puede analizarse mediante seis capas:

Capa	Pregunta principal
Red	¿Los equipos pueden comunicarse?
Nombre	¿El cliente puede localizar el servidor?
Servicio	¿Ambos utilizan un protocolo compatible?
Identidad	¿Cómo demuestra el usuario quién es?
Autorización	¿Qué operaciones puede realizar?
Datos	¿Los nombres y contenidos se interpretan igual?

Este modelo resulta especialmente útil para diagnosticar incidencias. En lugar de cambiar simultáneamente permisos, firewall y contraseñas, podemos comprobar cada capa por separado.

Conectividad IP y resolución de nombres

En GNU/Linux podemos comenzar con comandos como:

ip address
ip route
resolvectl status
ping -c 4 fs01.aula.local
dig fs01.aula.local
getent hosts fs01.aula.local
nc -vz fs01.aula.local 445

En Windows podemos utilizar:

ipconfig /all
route print
ping fs01.aula.local
nslookup fs01.aula.local
Resolve-DnsName fs01.aula.local
Test-NetConnection fs01.aula.local -Port 445

Cada comando responde a una pregunta diferente. ping comprueba la comunicación básica, mientras que dig, nslookup o Resolve-DnsName permiten revisar la resolución DNS. nc y Test-NetConnection comprueban si un puerto está accesible.

Antes de revisar contraseñas o permisos, conviene confirmar la dirección IP, las rutas, el DNS directo e inverso, la hora y el puerto del servicio.

Protocolos y puertos de red

Los servicios más frecuentes utilizan puertos conocidos:

Servicio	Puertos habituales	Uso
DNS	53 TCP/UDP	Resolución de nombres
Kerberos	88 TCP/UDP	Autenticación centralizada
LDAP/LDAPS	389/636 TCP	Consulta del directorio
SMB	445 TCP	Archivos e impresoras
NFSv4	2049 TCP	Sistemas de archivos en red
IPP	631 TCP	Impresión
SSH	22 TCP	Administración remota

No se deben abrir todos estos puertos de forma general. Solo deben permitirse los necesarios, desde las redes y equipos autorizados.

Identidad, autenticación y autorización

Estos tres conceptos suelen confundirse:

• La identidad representa a un usuario, equipo o servicio.
• La autenticación demuestra que esa identidad es auténtica.
• La autorización determina las operaciones que puede realizar.

Un usuario puede autenticarse correctamente y no tener autorización para acceder a una carpeta. También puede pertenecer al grupo adecuado y utilizar, sin darse cuenta, unas credenciales antiguas almacenadas en el cliente.

Diferencias entre SID, UID y GID

Windows utiliza identificadores de seguridad o SID para representar cuentas y grupos. GNU/Linux emplea normalmente UID para los usuarios y GID para los grupos.

Cuando Samba se integra con un dominio debe existir un mecanismo estable que relacione los SID con UID y GID. Si ese mapeo cambia después de haber creado archivos, los propietarios pueden empezar a interpretarse de forma incorrecta.

Por este motivo, la integración de sistemas operativos libres y propietarios exige una estrategia de identidad coherente desde el principio.

Qué protocolo utilizar: SMB, NFS o IPP

No existe un único protocolo válido para todos los escenarios. La elección depende del tipo de recurso, de los clientes y del modelo de seguridad.

Protocolo	Uso principal	Entorno habitual
SMB	Archivos e impresoras	Windows y redes mixtas
NFS	Sistemas de archivos en red	Unix y GNU/Linux
IPP	Impresión en red	Multiplataforma
SFTP	Transferencia de archivos	Multiplataforma
WebDAV	Acceso y edición mediante HTTP	Clientes diversos

SFTP es útil para transferir archivos, pero no equivale a una carpeta compartida destinada al trabajo colaborativo. WebDAV puede resolver determinados flujos, aunque tampoco sustituye siempre a SMB o NFS.

SMB para redes Windows y entornos mixtos

SMB es el protocolo habitual para compartir archivos e impresoras en Windows y en redes mixtas. Admite autenticación local o de dominio, sesiones, bloqueos de archivos, atributos y listas de control de acceso.

Las versiones modernas también pueden utilizar firma y cifrado. El término CIFS suele asociarse a una implementación histórica de SMB. En una configuración actual debe evitarse SMB1, salvo que exista una necesidad excepcional, temporal y documentada.

Los recursos SMB se identifican mediante rutas UNC:

\\servidor\recurso

NFS para sistemas Unix y GNU/Linux

NFS permite montar un directorio remoto dentro del árbol de directorios local. Las aplicaciones pueden utilizarlo como si se tratara de otro sistema de archivos.

Su integración con los permisos POSIX lo convierte en una opción natural para Unix y GNU/Linux. Sin embargo, obliga a coordinar correctamente los UID y GID. Un mismo número debe representar a la misma identidad en los equipos implicados.

IPP y CUPS para compartir impresoras

IPP permite describir impresoras, consultar su estado y enviar trabajos a través de la red. CUPS lo utiliza para gestionar colas de impresión en numerosos sistemas Unix y GNU/Linux.

Una cola IPP puede ser utilizada por clientes diferentes, siempre que dispongan de un controlador compatible y de los permisos necesarios. IPPS permite proteger la comunicación mediante TLS.

Cómo acceder desde GNU/Linux a una carpeta compartida de Windows

GNU/Linux puede conectarse a recursos SMB mediante herramientas de consola, exploradores gráficos o montajes persistentes.

Comprobar el recurso con smbclient

En una distribución basada en Debian podemos instalar las herramientas habituales:

sudo apt install smbclient cifs-utils

Después podemos enumerar los recursos disponibles:

smbclient -L //srvwin.aula.local -U 'AULA\alumno01'

Y conectarnos a uno de ellos:

smbclient //srvwin.aula.local/comun -U 'AULA\alumno01'

smbclient resulta muy útil porque permite probar la resolución del servidor, la disponibilidad de SMB y la autenticación antes de crear un montaje.

Realizar un montaje temporal

Primero creamos el punto de montaje:

sudo mkdir -p /mnt/comun

Después montamos el recurso:

sudo mount -t cifs //srvwin.aula.local/comun /mnt/comun \
  -o username=alumno01,domain=AULA,vers=3.0,uid=$(id -u),gid=$(id -g)

La opción vers=3.0 solicita una versión moderna de SMB, aunque debe ajustarse a la política del servidor. Las opciones uid y gid determinan cómo se presentan los archivos localmente cuando no se utilizan ACL integradas.

La contraseña no debería incluirse directamente en el comando porque podría quedar almacenada en el historial.

Configurar un montaje persistente de forma segura

Podemos crear un archivo de credenciales protegido:

sudo install -m 600 /dev/null /root/.smb-comun
sudo nano /root/.smb-comun

Su contenido sería:

username=alumno01
password=CONTRASENA_DE_LABORATORIO
domain=AULA

El montaje puede declararse en /etc/fstab:

//srvwin.aula.local/comun /mnt/comun cifs credentials=/root/.smb-comun,vers=3.0,_netdev,nofail 0 0

_netdev indica que el recurso depende de la red. nofail evita que una indisponibilidad remota bloquee innecesariamente el arranque en determinados escenarios.

Después debemos probar la configuración:

sudo mount -a
findmnt /mnt/comun
touch /mnt/comun/prueba-alumno01.txt

Una práctica que recomiendo en el aula es no considerar terminado el ejercicio después de ejecutar mount. También hay que crear, leer, modificar y borrar archivos con el usuario real. Un montaje visible puede seguir teniendo permisos incorrectos.

Cómo configurar Samba para clientes Windows y Linux

Samba implementa SMB en sistemas Unix y GNU/Linux. Puede funcionar como servidor autónomo, miembro de un dominio o controlador de dominio.

Para un escenario pequeño, un servidor autónomo puede ser suficiente. En una organización con identidades centralizadas, lo habitual es integrarlo con el dominio.

Preparar usuarios, grupos y directorios

En una distribución basada en Debian podemos instalar Samba y las herramientas de ACL:

sudo apt update
sudo apt install samba acl

Creamos el directorio y el grupo:

sudo mkdir -p /srv/samba/comun
sudo groupadd recursos_comun
sudo chgrp recursos_comun /srv/samba/comun
sudo chmod 2770 /srv/samba/comun

El bit setgid del directorio hace que los nuevos elementos hereden el grupo. Si necesitamos permisos más precisos, tendremos que utilizar ACL.

Configurar el servidor y publicar un recurso

Una configuración global sencilla podría ser:

[global]
   workgroup = AULA
   server role = standalone server
   security = user
   map to guest = never
   server min protocol = SMB2
   log file = /var/log/samba/log.%m
   max log size = 1000

A continuación publicamos el recurso:

[comun]
   path = /srv/samba/comun
   browseable = yes
   read only = no
   valid users = @recursos_comun
   force group = recursos_comun
   create mask = 0660
   directory mask = 2770
   inherit permissions = yes

Antes de reiniciar debemos validar la sintaxis:

sudo testparm

Dar de alta un usuario

En un servidor autónomo puede ser necesaria una cuenta local asociada:

sudo useradd -M -s /usr/sbin/nologin alumno01
sudo usermod -aG recursos_comun alumno01
sudo smbpasswd -a alumno01
sudo systemctl restart smbd

Después comprobamos el recurso localmente:

smbclient //localhost/comun -U alumno01

Probar el acceso desde Windows y GNU/Linux

Desde Windows podemos acceder mediante:

\\fs01.aula.local\comun

También podemos asignar una unidad:

net use Z: \\fs01.aula.local\comun /user:FS01\alumno01 *

El asterisco solicita la contraseña de forma interactiva.

Desde GNU/Linux podemos utilizar:

smbclient //fs01.aula.local/comun -U alumno01

La integración no debe considerarse correcta hasta verificar el acceso desde todos los tipos de cliente previstos.

Cómo gestionar permisos y ACL en Samba

Configurar correctamente el recurso en smb.conf no garantiza que el usuario pueda escribir. Samba debe coordinar los permisos SMB con los permisos del sistema de archivos local.

Permisos del recurso y del sistema de archivos

Podemos distinguir cuatro capas:

Capa	Qué controla
Recurso Samba	Quién se conecta y si dispone de lectura o escritura
Sistema de archivos	Acceso real a archivos y directorios
Identidad	Usuario y grupos reconocidos por el servidor
Cliente	Credenciales y sesiones utilizadas

El acceso efectivo nunca puede superar lo permitido por el sistema de archivos. Aunque Samba indique que un recurso es de lectura y escritura, el kernel denegará la operación si la cuenta no tiene permisos locales.

Herencia, máscaras y permisos efectivos

Las ACL POSIX permiten asignar derechos a grupos concretos:

sudo setfacl -m g:profesorado:rwx /srv/samba/comun
sudo setfacl -m g:alumnado:rx /srv/samba/comun
sudo setfacl -d -m g:profesorado:rwx /srv/samba/comun
sudo setfacl -d -m g:alumnado:rx /srv/samba/comun
getfacl /srv/samba/comun

Las ACL predeterminadas se aplican a los nuevos elementos.

En Samba también intervienen varias opciones:

• create mask limita los permisos máximos de los archivos.
• directory mask limita los permisos máximos de los directorios.
• force group impone un grupo común.
• inherit permissions hereda los permisos del directorio padre.

Estas opciones no corrigen una propiedad local incorrecta.

Errores habituales de identidad y credenciales

Uno de los errores más engañosos aparece cuando Windows conserva una sesión SMB anterior. Podemos cambiar la contraseña, modificar los grupos o corregir una ACL y seguir probando con las credenciales antiguas.

Para eliminar conexiones en Windows:

net use * /delete

También puede ser necesario limpiar tickets:

klist purge

En mis clases he comprobado que este detalle puede hacer perder bastante tiempo. El estudiante modifica correctamente los permisos del servidor, pero el cliente sigue utilizando una sesión anterior. Por eso, cuando cambia la identidad de prueba, siempre recomiendo cerrar las conexiones existentes antes de sacar conclusiones.

El diagnóstico debe revisar usuario, grupos, ACL, máscara, propiedad de los archivos, recurso Samba y credenciales utilizadas por el cliente.

Cómo integrar Samba y GNU/Linux con Active Directory

Un servidor Samba miembro de un dominio puede utilizar las identidades centralizadas de Active Directory. Los usuarios acceden con su cuenta habitual y los permisos se conceden mediante grupos del dominio.

Esta arquitectura reduce la duplicación de cuentas, pero depende de varios servicios.

Requisitos de DNS, Kerberos y sincronización horaria

Antes de unir un servidor al dominio debemos comprobar:

• Que utiliza el DNS autorizado del dominio.
• Que su FQDN se resuelve directa e inversamente.
• Que la hora está sincronizada.
• Que no existe una cuenta de equipo conflictiva.
• Que los puertos necesarios están permitidos.
• Que disponemos de una copia de la configuración y de un procedimiento de reversión.

Kerberos depende especialmente del DNS y de una hora coherente. Si el servidor localiza un controlador incorrecto o existe una diferencia temporal excesiva, la autenticación puede fallar.

Podemos realizar comprobaciones previas:

host dc01.aula.local
timedatectl status
kinit [email protected]
klist

Unión al dominio y resolución de usuarios

Una unión conceptual mediante herramientas de Samba podría utilizar:

sudo net ads join -U Administrador

Los paquetes y parámetros exactos dependerán de la distribución.

Después debemos verificar usuarios y grupos:

wbinfo -u
wbinfo -g
getent passwd 'AULA\alumno01'
getent group 'AULA\GG_Departamento_RW'
id 'AULA\alumno01'

La unión no está terminada simplemente porque el comando devuelva un mensaje correcto. Debemos confirmar que el sistema resuelve las identidades y que los permisos funcionan.

Mapeo de identidades

Winbind puede asignar UID y GID a las identidades del dominio. Una configuración conceptual sería:

[global]
   security = ADS
   realm = AULA.LOCAL
   workgroup = AULA

   idmap config * : backend = tdb
   idmap config * : range = 3000-7999

   idmap config AULA : backend = rid
   idmap config AULA : range = 10000-999999

Los rangos no deben solaparse ni cambiarse después de crear archivos. Si se modifican, un número que antes representaba a un usuario podría pasar a representar a otro.

Autorización mediante grupos del dominio

Un recurso autorizado por un grupo podría configurarse así:

[departamento]
   path = /srv/samba/departamento
   read only = no
   valid users = @"AULA\GG_Departamento_RW"
   inherit acls = yes
   map acl inherit = yes

La práctica recomendable es conceder permisos mediante grupos, no directamente a usuarios. Esto simplifica las altas, bajas y cambios de función.

Un cliente GNU/Linux también puede unirse a Active Directory mediante herramientas como realmd y SSSD:

realm discover aula.local
sudo realm join aula.local -U Administrador
realm list
getent passwd [email protected]
id [email protected]
kinit [email protected]
klist

Después conviene restringir quién puede iniciar sesión:

sudo realm deny --all
sudo realm permit -g "[email protected]"

Unir el equipo al dominio no implica que todos los usuarios deban poder utilizarlo.

Compartir archivos mediante NFS

NFS está especialmente orientado a sistemas Unix y GNU/Linux. Permite montar directorios remotos dentro del árbol local.

Configurar una exportación NFS

En el servidor podemos instalar el servicio:

sudo apt install nfs-kernel-server
sudo mkdir -p /srv/nfs/proyectos
sudo chgrp proyectos /srv/nfs/proyectos
sudo chmod 2770 /srv/nfs/proyectos

La exportación se define en /etc/exports:

/srv/nfs/proyectos 192.168.50.0/24(rw,sync,no_subtree_check,root_squash)

Las opciones indican lo siguiente:

• rw: permite lectura y escritura según los permisos locales.
• sync: confirma las operaciones de forma coherente con el almacenamiento.
• no_subtree_check: evita determinadas comprobaciones de subárbol.
• root_squash: evita que root del cliente se convierta automáticamente en root del servidor.

Aplicamos la configuración:

sudo exportfs -rav
sudo exportfs -v
sudo systemctl enable --now nfs-server
showmount -e localhost

Montar el recurso desde un cliente Linux

En el cliente:

sudo apt install nfs-common
sudo mkdir -p /mnt/proyectos
sudo mount -t nfs4 fs01.aula.local:/srv/nfs/proyectos /mnt/proyectos

Comprobamos el resultado:

findmnt /mnt/proyectos
touch /mnt/proyectos/prueba-cliente.txt

Para hacerlo persistente:

fs01.aula.local:/srv/nfs/proyectos /mnt/proyectos nfs4 _netdev,nofail 0 0

Coordinar UID, GID y permisos

En configuraciones sencillas, NFS confía en los UID y GID presentados por el cliente. Si un usuario tiene UID 1500 en el servidor y 1700 en el cliente, los propietarios no se interpretarán correctamente.

NFS no sustituye la gestión de identidades. Compartir un directorio sin coordinar usuarios, grupos y permisos puede bloquear a usuarios legítimos o exponer información.

Algunos sistemas propietarios incluyen componentes NFS opcionales, pero su disponibilidad depende de la edición y la configuración. Antes de utilizarlos deben probarse la lectura, escritura, eliminación, concurrencia, bloqueo y representación de identidades.

También es posible publicar un mismo almacenamiento mediante SMB y NFS, aunque aumenta la complejidad. Los dos protocolos pueden interpretar de forma distinta las ACL, los nombres, los bloqueos y la caché. No recomiendo una publicación dual sin realizar pruebas específicas con las aplicaciones reales.

Compartir impresoras entre Windows y GNU/Linux

La integración de impresoras no consiste únicamente en alcanzar el dispositivo por la red. Es necesario crear una cola, configurar los permisos, seleccionar un controlador compatible y confirmar que el trabajo llega hasta la impresora.

Configurar CUPS e IPP

En GNU/Linux podemos instalar y activar CUPS:

sudo apt install cups
sudo systemctl enable --now cups
sudo cupsctl --share-printers
lpstat -t

Una URI de ejemplo sería:

ipp://print01.aula.local/printers/Aula

Podemos consultar la cola:

lpstat -h print01.aula.local -p

Y enviar un trabajo:

lp -d Aula documento-prueba.pdf

La interfaz de CUPS utiliza habitualmente el puerto 631. El acceso remoto debe limitarse a las redes y administradores autorizados.

Acceder desde clientes Windows

Windows puede agregar una impresora mediante su nombre, dirección IP o URL IPP, dependiendo de la edición y de la configuración.

Después de agregarla debemos comprobar:

• El controlador.
• La arquitectura.
• La página de prueba.
• El estado de la cola.
• La cancelación de trabajos.
• Los permisos del usuario.

Samba también puede publicar colas gestionadas por CUPS para clientes que esperan una impresora compartida mediante SMB.

Probar la cola y los permisos de impresión

Una matriz mínima debería incluir:

Cliente o usuario	Operación	Resultado esperado
Cliente Windows	Agregar la cola	La impresora aparece y acepta trabajos
Cliente GNU/Linux	Agregar la cola IPP	La cola queda disponible
Usuario autorizado	Imprimir y cancelar su trabajo	Operación permitida
Usuario no autorizado	Intentar imprimir	Acceso denegado
Administrador	Pausar y reanudar la cola	Gestión disponible

En la integración de sistemas operativos libres y propietarios, la impresión debe probarse de extremo a extremo. Que el trabajo aparezca en CUPS no significa necesariamente que el dispositivo físico lo haya procesado.

Seguridad en una red heterogénea

Un recurso compartido amplía la superficie de ataque. La seguridad debe aplicarse al protocolo, la identidad, el sistema de archivos, la red y los datos.

Aplicar el principio de mínimo privilegio

Cada usuario debe disponer únicamente del acceso necesario para su función. Los permisos deberían concederse mediante grupos y partir de una denegación por defecto.

Una matriz sencilla podría distinguir:

• Alumnado: escritura limitada en la carpeta común y sin acceso administrativo.
• Profesorado: lectura y escritura en los recursos docentes.
• Administración: acceso a su área documental.
• Administradores TI: acceso técnico auditado.

La pertenencia al equipo de sistemas no debería utilizarse como una excusa para acceder de forma indiscriminada a todos los datos.

Proteger SMB, NFS e IPP

Para endurecer SMB:

• Deshabilitar SMB1.
• Exigir autenticación.
• Evitar recursos de invitado innecesarios.
• Utilizar firma o cifrado cuando el riesgo lo requiera.
• Restringir el puerto 445.
• Revisar sesiones y errores de autenticación.
• Mantener actualizados Samba y Windows.

NFS:

• Exportar solo a redes o equipos concretos.
• Mantener root_squash salvo necesidad justificada.
• Coordinar los UID y GID.
• Evitar exportar directorios sensibles.
• Limitar el servicio mediante firewall.

Para la impresión:

• Restringir quién puede imprimir y administrar.
• Utilizar IPPS cuando sea necesaria la confidencialidad.
• Proteger la administración web de CUPS.
• Evitar controladores no confiables.
• Eliminar trabajos retenidos según la política definida.

Evitar protocolos obsoletos y accesos generales

Las configuraciones antiguas suelen mantenerse porque “siempre han funcionado”. Sin embargo, esto puede implicar protocolos obsoletos, permisos generales o credenciales compartidas.

Mi experiencia en mantenimiento e integraciones me ha enseñado que una solución debe revisarse después de ponerse en marcha. No basta con configurarla una vez. Hay que actualizar componentes, eliminar cuentas sin uso, revisar permisos y comprobar que las decisiones originales siguen teniendo sentido.

Además, compartir datos no equivale a realizar copias de seguridad. Una eliminación accidental o un cifrado malicioso puede propagarse al recurso compartido. Las copias y las pruebas de restauración forman parte de la seguridad.

Cómo comprobar que la integración funciona

Una única captura de pantalla no demuestra que la integración sea correcta. Debemos probarla desde cada tipo de cliente, con usuarios autorizados y no autorizados.

Matriz de pruebas permitidas y denegadas

Una matriz básica podría ser:

Cliente	Usuario	Recurso	Operación	Resultado
Windows	alumno01	común	Crear y editar	Permitido
GNU/Linux	alumno01	común	Leer el archivo anterior	Permitido
Windows	invitado	común	Abrir el recurso	Denegado
GNU/Linux	profesor01	profesorado	Crear y borrar	Permitido
Windows	alumno01	profesorado	Abrir	Denegado
Dos clientes	profesor01	común	Editar simultáneamente	Comportamiento documentado

Las pruebas denegadas son tan importantes como las permitidas. Un sistema que permite trabajar a los usuarios correctos, pero también a los incorrectos, no está bien configurado.

Evidencias que deben recopilarse

Las evidencias útiles incluyen:

• Configuración de red.
• Resolución de nombres.
• Puertos accesibles.
• Estado del servicio.
• Configuración relevante del recurso.
• Identidad y grupos efectivos.
• Prueba permitida.
• Prueba denegada.
• Registro del servidor relacionado con la operación.
• Conclusión y limitaciones.

Los secretos y contraseñas deben ocultarse antes de almacenar las evidencias.

Pruebas desde distintos clientes y usuarios

El orden recomendado es:

1. Comprobar IP, rutas y DNS.
2. Verificar la hora y los servicios de identidad.
3. Comprobar el puerto.
4. Enumerar el recurso.
5. Autenticarse.
6. Probar lectura, creación, modificación, renombrado y borrado.
7. Probar una cuenta sin permiso.
8. Cerrar sesiones o volver a montar.
9. Revisar registros.
10. Documentar el resultado.

Cuando planteo una práctica, intento que el estudiante no se limite a conseguir una captura “correcta”. La parte realmente útil llega cuando debe demostrar por qué un usuario puede entrar y otro no. Esa comparación obliga a comprender la identidad y los permisos en lugar de repetir comandos.

Diagnóstico de problemas de integración

El diagnóstico debe seguir una secuencia. Cambiar simultáneamente el firewall, los permisos y la contraseña puede ocultar la causa original.

Un método útil es:

Síntoma → alcance → capa probable → evidencia → hipótesis
→ prueba controlada → corrección → verificación → documentación

El nombre del servidor no se resuelve

Debemos comprobar:

• La configuración DNS del cliente.
• El registro directo.
• El registro inverso.
• El FQDN utilizado.
• La existencia de nombres duplicados.
• La caché local.

Probar la dirección IP puede ayudar a separar un problema de red de un problema de nombres, pero no debe convertirse en la solución definitiva.

El puerto no responde

Si el nombre se resuelve, comprobamos el puerto:

Test-NetConnection fs01.aula.local -Port 445

O desde GNU/Linux:

nc -vz fs01.aula.local 445

Si el puerto no responde, revisamos el servicio, el firewall, la ruta y la dirección en la que escucha el proceso.

Las credenciales son rechazadas

Debemos comprobar:

• Nombre del usuario.
• Dominio.
• Contraseña.
• Estado de la cuenta.
• Hora.
• DNS.
• Sesiones almacenadas.
• Tickets Kerberos.

Un problema de autenticación de dominio puede parecer un error de contraseña cuando en realidad el cliente está consultando un DNS incorrecto.

El usuario accede pero no puede escribir

En este caso deben revisarse:

• read only.
• write list.
• valid users.
• Propietario y grupo local.
• Permisos POSIX.
• ACL.
• Máscara de ACL.
• create mask.
• directory mask.
• Sistema de archivos montado en solo lectura.
• Cuotas.

El hecho de que testparm no muestre errores solo confirma la sintaxis de Samba. No demuestra que el directorio exista ni que los permisos locales sean correctos.

Windows utiliza credenciales antiguas

Antes de probar con otro usuario:

net use * /delete
klist purge

También conviene revisar el Administrador de credenciales y cerrar la sesión cuando sea necesario.

Problemas con NFS

Si el montaje es rechazado, revisamos la red autorizada en /etc/exports, la versión, el firewall y la salida de exportfs.

Si el montaje funciona, pero la escritura falla, comprobamos los UID, GID, permisos locales, root_squash y el modo ro o rw.

Problemas de impresión

Cuando una cola no aparece, comprobamos DNS, el puerto 631, la URL y el firewall.

Cuando el trabajo queda detenido, revisamos el estado de CUPS, el filtro, el controlador y la comunicación con el dispositivo:

lpstat -t
sudo journalctl -u cups --since "15 minutes ago"
sudo tail -n 100 /var/log/cups/error_log

La secuencia general puede resumirse así:

¿Resuelve el nombre?
 ├─ No → revisar DNS y nombre.
 └─ Sí → ¿responde el puerto?
      ├─ No → revisar servicio, firewall y ruta.
      └─ Sí → ¿autentica?
           ├─ No → revisar identidad, contraseña, hora y dominio.
           └─ Sí → ¿los permisos son correctos?
                ├─ No → revisar grupos, ACL, recurso y caché.
                └─ Sí → revisar aplicación, bloqueo, cuota y registros.

Este método es una de las partes más importantes de la integración de sistemas operativos libres y propietarios porque evita convertir el diagnóstico en una sucesión de reinicios y cambios sin control.

Documentación y mantenimiento de la solución

Una lista de comandos no es documentación suficiente. La solución debe poder reproducirse, auditarse y repararse por otra persona.

Qué debe incluir la documentación técnica

El documento debería registrar:

• Objetivo y alcance.
• Diagrama de red.
• Nombres y direcciones de los equipos.
• Sistemas operativos y roles.
• Protocolos y puertos.
• Fuente de identidades.
• Grupos de acceso.
• Rutas locales y nombres publicados.
• Opciones relevantes.
• Matriz de permisos.
• Matriz de pruebas.
• Procedimiento de instalación.
• Copias de seguridad.
• Procedimiento de reversión.
• Incidencias conocidas.
• Responsables y fecha de revisión.

Cada recurso debería disponer de una ficha con el servidor, protocolo, nombre compartido, ruta local, grupos autorizados, política de copia y responsable.

Revisiones periódicas, copias y recuperación

El mantenimiento debe incluir:

• Actualizaciones de Windows, GNU/Linux, Samba, NFS y CUPS.
• Revisión del espacio y las cuotas.
• Comprobación del almacenamiento.
• Eliminación de cuentas sin uso.
• Revisión de ACL.
• Comprobación de certificados y protocolos.
• Análisis de errores de autenticación.
• Ejecución de pruebas tras cambios relevantes.
• Actualización de diagramas.
• Pruebas de restauración.

Tanto en consultoría como en docencia he comprobado que una configuración sin documentación suele depender demasiado de la persona que la creó. Cuando esa persona no está disponible, cualquier cambio se vuelve arriesgado. Por eso prefiero documentar no solo qué comando se utilizó, sino también qué problema resolvía y cómo se verificó su resultado. Mi trayectoria profesional destaca precisamente la importancia de estructurar los problemas, documentar procesos y explicar la tecnología con claridad.

La documentación no es un añadido al final del proyecto. Es una parte esencial de una integración mantenible.

Conclusión

La integración de sistemas operativos libres y propietarios permite que Windows, GNU/Linux y otros sistemas utilicen recursos, identidades y servicios comunes. Para conseguirlo no necesitamos que todas las plataformas funcionen de la misma forma, sino establecer puntos de acuerdo claros.

SMB y Samba son especialmente útiles para compartir archivos en redes Windows y mixtas. NFS se integra de manera natural en entornos Unix y GNU/Linux. CUPS e IPP permiten compartir impresoras entre plataformas. Active Directory puede centralizar las identidades utilizadas por servidores y clientes Linux.

Sin embargo, el protocolo solo es una parte de la solución. También deben funcionar la conectividad, el DNS, la sincronización horaria, la autenticación, los permisos y el sistema de archivos local.

Una buena integración parte de un inventario, utiliza grupos para gestionar el acceso, aplica el mínimo privilegio y evita protocolos obsoletos. Después se valida mediante una matriz que incluya operaciones permitidas y denegadas.

Cuando aparece una incidencia, la mejor estrategia es avanzar por capas: nombre, puerto, autenticación, autorización y aplicación. Esta forma de trabajar permite encontrar la causa sin introducir nuevos errores.

Por último, toda la configuración debe quedar documentada. La integración de sistemas operativos libres y propietarios no termina cuando un usuario abre una carpeta o imprime una página. Termina cuando la solución puede utilizarse, comprobarse, mantenerse y recuperarse de forma segura.

Preguntas frecuentes sobre la integración de Windows y Linux

¿Qué es una red heterogénea?

Es una red en la que conviven sistemas operativos, aplicaciones o dispositivos de diferentes fabricantes y familias tecnológicas. Su objetivo es permitir que todos ellos intercambien información y utilicen servicios comunes.

¿Qué significa interoperabilidad entre sistemas operativos?

Es la capacidad de sistemas diferentes para comunicarse y utilizar la información intercambiada de forma correcta, segura y predecible.

¿Qué protocolo permite compartir archivos entre Windows y Linux?

SMB es la opción habitual en redes Windows y mixtas. GNU/Linux puede actuar como cliente SMB o publicar recursos mediante Samba.

¿Cuál es la diferencia entre SMB y NFS?

SMB es habitual en Windows y redes mixtas. NFS está orientado principalmente a sistemas Unix y GNU/Linux y se integra con el modelo de permisos POSIX.

¿Para qué sirve Samba?

Samba implementa servicios SMB en sistemas Unix y GNU/Linux. Permite compartir archivos e impresoras con clientes Windows y puede integrarse con Active Directory.

¿Puede un equipo Linux utilizar usuarios de Active Directory?

Sí. Herramientas como realmd, SSSD, Kerberos, Samba o Winbind permiten unir equipos y servidores GNU/Linux a un dominio y resolver usuarios y grupos.

¿Qué diferencia existe entre SID, UID y GID?

Windows utiliza SID para identificar usuarios y grupos. GNU/Linux utiliza UID para usuarios y GID para grupos. En una integración debe existir un mapeo estable entre estos identificadores.

¿Por qué funciona el ping, pero no se abre la carpeta compartida?

Porque ping solo comprueba una parte de la conectividad. Todavía pueden existir problemas de DNS, puerto 445, servicio SMB, firewall, autenticación o permisos.

¿Por qué debe evitarse SMB1?

Porque es una versión obsoleta. En una instalación moderna deben utilizarse versiones actuales de SMB y reservar SMB1 únicamente para excepciones temporales y documentadas.

¿Cómo se comprueba que una integración funciona?

Debe probarse desde distintos sistemas, con diferentes usuarios y con operaciones permitidas y denegadas. También hay que revisar los registros y documentar las evidencias.