Endurecimiento de SMB: Soluciona ‘Acceso denegado’ sin volver a activar SMB1

Qué significa realmente “Acceso denegado” (no es un único problema)

SMB es una pila de decisiones. “Acceso denegado” es el resumen visible al usuario cuando cualquiera de estas decisiones va en tu contra:

• Negociación de protocolo: cliente y servidor acuerdan dialectos SMB (SMB2/SMB3) y capacidades (firma, cifrado, multicanal). Si no pueden, puedes ver “Access Denied”, “The specified network name is no longer available” o comportamientos silenciosos de retroceso dependiendo del cliente.
• Autenticación: el cliente demuestra identidad usando Kerberos, NTLMv2, o cuentas locales. Fallos aquí pueden aparecer como acceso denegado, solicitudes de contraseña errónea, o “Logon failure”.
• Autorización: una vez autenticado, el token se comprueba frente a permisos del recurso compartido y ACLs del sistema de archivos. Este es el clásico “eres quien dices ser, pero aun así no puedes entrar”.
• Política y ajustes de endurecimiento: el servidor exige firma SMB; el cliente no la usa. El servidor exige cifrado; el recurso no está configurado; el cliente es demasiado antiguo. El dominio prohíbe NTLM. Todo esto parece acceso denegado porque el servidor se niega a continuar.
• Resolución de nombres / orientación SPN: Kerberos es quisquilloso. Nombre de host equivocado, alias sin SPN, o desfase horario pueden conducir a fallback de autenticación o a rechazo total.

Aquí está la mentalidad operativa útil: “Acceso denegado” es un problema de clasificación. No estás “arreglando SMB”. Estás encontrando qué portón se está cerrando.

Datos históricos e contexto interesante (breve, útil)

1. SMB empezó como un protocolo de intercambio de archivos en la era DOS y más tarde se convirtió en “CIFS” en la época de Windows NT/2000—mismo linaje, distintas capacidades y marca.
2. SMB2 (Vista/Server 2008) fue una reescritura importante que redujo el tráfico innecesario y mejoró el rendimiento sobre enlaces de alta latencia.
3. SMB3 (Windows 8/Server 2012) introdujo cifrado a nivel de protocolo—no se requiere VPN para confidencialidad en tránsito.
4. La firma SMB existía mucho antes de que la mayoría de organizaciones la usara; es integridad, no cifrado, y a menudo se aplica por política de dominio por buenas razones.
5. El impulso de “SMB1 es legado” se aceleró tras gusanos importantes que explotaron debilidades de la era SMB1 y hábitos de parcheo descuidados. Los equipos de seguridad no lo olvidan.
6. El trabajo de Samba es traducir: permisos Unix, semántica de ACL de Windows, mapeo de identidades y autenticación de red se encuentran en un mismo demonio. La traducción es donde nacen errores y malas configuraciones.
7. “Acceso denegado” puede ser una postura de seguridad deliberada: el endurecimiento moderno prefiere “fallar cerrado” cuando hay desajuste de políticas (p. ej., rechazar NTLM) en lugar de degradar silenciosamente.
8. Kerberos es sensible al tiempo por diseño; unos minutos de desfase de reloj pueden convertir un recurso sano en una fábrica de “Acceso denegado”.

Guion de diagnóstico rápido (primero/segundo/tercero)

Primero: ¿es esto autenticación, autorización o negociación de protocolo?

• Intenta listar recursos anónimamente y autenticado: si el anónimo falla pero la autenticación funciona, hay un cambio en la política de invitado (bien). Si la autenticación falla, es identidad o política. Si listar funciona pero abrir una carpeta falla, es autorización (permiso del recurso vs ACL del sistema de archivos).
• Verifica el dialecto y el estado de firma: si el cliente está negociando SMB1 o falla al negociar SMB2/3, estás en problemas de compatibilidad/política, no de “permisos”.

Segundo: valida el mapeo de identidad y la pertenencia a grupos

• En servidores miembro AD/Samba: si el usuario se mapea a “nobody” o a un UID/GID inesperado, las comprobaciones del sistema de archivos denegarán aunque los permisos del recurso parezcan correctos.
• En clientes Windows: credenciales en caché y sesiones con “usuario equivocado” son comunes. Una conexión obsoleta puede envenenar todos los intentos al mismo nombre de servidor.

Tercero: revisa desajustes de política (restricciones NTLM, firma, cifrado)

• Dominio prohíbe NTLM: un cliente Linux que use NTLM será denegado hasta que lo cambies a Kerberos (o ajustes la política, lo cual probablemente no debas hacer).
• Firma requerida: clientes antiguos o montajes mal configurados fallan.
• Cifrado requerido: el cliente debe soportar cifrado SMB3 y negociarlo.

Idea parafraseada, atribuida: Werner Vogels ha dicho que construyes sistemas fiables asumiendo que las cosas fallan y diseñando para ello. Trata la autenticación y la política de SMB como un dominio de fallos que puedes instrumentar, no como un apretón de manos místico.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las comprobaciones que ejecuto cuando alguien escribe “SMB access denied” y espera un milagro. Cada tarea incluye: comando, salida de ejemplo y la decisión que guía.

Tarea 1: Confirma que el servidor realmente escucha en el puerto 445

cr0x@server:~$ sudo ss -lntp | egrep ':445|:139'
LISTEN 0      128          0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=1223,fd=52))
LISTEN 0      128             [::]:445           [::]:*    users:(("smbd",pid=1223,fd=54))

Qué significa: SMB es accesible a nivel TCP. Si no ves 445, aún no es un problema de permisos.

Decisión: Si 445 no está escuchando, arregla el servicio (smbd no en ejecución, enlazado a la interfaz incorrecta, red de contenedores) antes de tocar ACLs.

Tarea 2: Revisa reglas de firewall para 445/tcp

cr0x@server:~$ sudo nft list ruleset | sed -n '1,140p'
table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    tcp dport 445 ip saddr 10.20.0.0/16 accept
  }
}

Qué significa: Solo 10.20.0.0/16 puede alcanzar SMB. Todos los demás fallarán de maneras interesantes.

Decisión: Si los clientes están fuera de ese CIDR, arregla la política de red. No “depures SMB” mientras paquetes son descartados a propósito.

Tarea 3: Comprueba qué dialectos SMB negociará Samba

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'server min protocol|server max protocol'
	server min protocol = SMB2_10
	server max protocol = SMB3_11

Qué significa: SMB1 ya está deshabilitado. Bien. Esto también fija expectativas para clientes más antiguos.

Decisión: Si ves SMB1 permitido, endurece la configuración. Si un cliente legado no soporta SMB2, migra el cliente; no debilites el servidor.

Tarea 4: Valida la definición del recurso y su visibilidad efectiva

cr0x@server:~$ testparm -s 2>/dev/null
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_MEMBER_SERVER

[global]
	workgroup = EXAMPLE
	security = ADS

[finance]
	path = /srv/samba/finance
	read only = No

Qué significa: El recurso existe y apunta a un lugar real (lo verificaremos a continuación). “Weak crypto allowed” no es un crimen, pero es una pista sobre modos de autenticación en juego.

Decisión: Si el recurso no está presente o apunta a la ruta equivocada, arréglalo. Si el modo de seguridad no es el que esperas (ADS vs user), detente y revisa el diseño.

Tarea 5: Verifica la ruta del sistema de archivos, propiedad y bits de modo

cr0x@server:~$ sudo ls -ld /srv/samba/finance
drwxrwx--- 3 root "EXAMPLE\\finance-rw" 4096 Jan 12 09:40 /srv/samba/finance

Qué significa: Los bits de modo permiten acceso al grupo, pero solo si el mapeo de identidad sitúa a los usuarios en ese grupo.

Decisión: Si los permisos son 700 o pertenecen al grupo incorrecto, obtendrás acceso denegado incluso con “valid users” configurado correctamente. Arregla permisos POSIX o ACLs primero.

Tarea 6: Revisa SELinux/AppArmor bloqueando (el portero silencioso)

cr0x@server:~$ sudo getenforce
Enforcing

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 5
type=AVC msg=audit(1739201151.441:812): avc:  denied  { read } for  pid=1223 comm="smbd" name="finance" dev="sda2" ino=393220 scontext=system_u:system_r:smbd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0

Qué significa: El kernel está negando a smbd independientemente de tu configuración de Samba. Esto a menudo parece “permisos” pero no lo es.

Decisión: Corrige el etiquetado (por ejemplo, establece el contexto adecuado) en lugar de ampliar permisos del recurso compartido.

Tarea 7: Demuestra que el mapeo de identidad funciona (usuario AD → UID/GID)

cr0x@server:~$ id "EXAMPLE\\alice"
uid=220110(EXAMPLE\alice) gid=220051(EXAMPLE\domain users) groups=220051(EXAMPLE\domain users),220220(EXAMPLE\finance-rw)

Qué significa: El usuario se resuelve y pertenece al grupo esperado.

Decisión: Si id falla o faltan grupos, arregla winbind/sssd/idmap antes de tocar ACLs. IDs erróneos equivalen a decisiones de acceso erróneas.

Tarea 8: Confirma que el servidor puede hablar con AD y ve el dominio

cr0x@server:~$ wbinfo -t
checking the trust secret for domain EXAMPLE via RPC calls succeeded

Qué significa: La unión está lo bastante sana para RPC trust. No es garantía, pero es una base sólida.

Decisión: Si esto falla, “Access Denied” puede ser que el servidor no valida credenciales. Arregla la unión al dominio, DNS, tiempo y keytabs.

Tarea 9: Revisa Kerberos y tiempo (el culpable aburrido)

cr0x@server:~$ timedatectl | sed -n '1,8p'
Local time: Wed 2026-02-05 14:31:10 UTC
Universal time: Wed 2026-02-05 14:31:10 UTC
RTC time: Wed 2026-02-05 14:31:10
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active

cr0x@server:~$ kinit alice@EXAMPLE.COM
Password for alice@EXAMPLE.COM:

cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: alice@EXAMPLE.COM

Valid starting     Expires            Service principal
02/05/26 14:31:25  02/06/26 00:31:25  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Qué significa: El tiempo está sincronizado y los tickets Kerberos funcionan. Si el tiempo está mal, Kerberos falla y los clientes retroceden—o fallan—dependiendo de la política.

Decisión: Si NTP no está activo o kinit falla, arregla tiempo/DNS/acceso a KDC. No empieces a relajar políticas NTLM como solución temporal.

Tarea 10: Reproduce desde el lado del servidor con smbclient (evita la UX de Windows)

cr0x@server:~$ smbclient -m SMB3 -L //files01 -U 'EXAMPLE\alice'
Password for [EXAMPLE\alice]:
	Sharename       Type      Comment
	---------       ----      -------
	finance         Disk
	IPC$            IPC       IPC Service (Samba)
SMB1 disabled -- no workgroup available

Qué significa: El usuario puede enumerar recursos vía SMB3. La línea “SMB1 disabled” es informativa y está bien.

Decisión: Si el listado falla con NT_STATUS_ACCESS_DENIED, es autenticación/política. Si listar funciona pero las operaciones de archivos fallan, son ACLs o módulos VFS.

Tarea 11: Intenta acceder al recurso y realizar una operación de archivo

cr0x@server:~$ smbclient -m SMB3 //files01/finance -U 'EXAMPLE\alice' -c 'ls; mkdir _diag_test; rmdir _diag_test'
Password for [EXAMPLE\alice]:
  .                                   D        0  Wed Feb  5 14:22:01 2026
  ..                                  D        0  Wed Feb  5 13:59:11 2026
  budgets                             D        0  Tue Feb  4 18:04:41 2026

Qué significa: El listado de directorio y crear/eliminar funcionaron. Esto no es un problema de autorización para este usuario.

Decisión: Si mkdir falla con ACCESS_DENIED, inspecciona “write list” a nivel de recurso y ACLs del sistema de archivos; si ls falla, revisa permiso de execute/search en directorios.

Tarea 12: Inspecciona registros de Samba para la causa real (no el diálogo de Windows)

cr0x@server:~$ sudo tail -n 30 /var/log/samba/log.smbd
[2026/02/05 14:24:33.112233,  1] smbd/service.c:1234(make_connection_snum)
  create_connection_session_info: guest user (from session setup) not permitted to access this share (finance)
[2026/02/05 14:24:33.112544,  1] smbd/service.c:987(make_connection_snum)
  files01 (ipv4:10.20.5.44:51022) connect to service finance initially as user nobody (uid=65534, gid=65534) (pid 1422)

Qué significa: El cliente está entrando como guest/nobody. Por eso se le niega el acceso—aun si “alice” escribió una contraseña en algún lugar.

Decisión: Arregla la negociación de autenticación (NTLM/Kerberos), el gestor de credenciales de Windows, o el comportamiento de Samba “map to guest”. No amplíes ACLs para permitir a “nobody” el acceso.

Tarea 13: Detecta “map to guest” y ajustes de acceso invitado

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'map to guest|guest ok|restrict anonymous'
	map to guest = Bad User
	restrict anonymous = 2

Qué significa: Usuarios desconocidos se mapean a guest. Combinado con “restrict anonymous”, esto puede convertirse en negaciones confusas.

Decisión: En entornos endurecidos, prefiere fallar la autenticación en lugar de mapear a guest. Considera map to guest = Never a menos que tengas un caso de uso controlado para invitados.

Tarea 14: Comprueba si Windows tiene una sesión obsoleta hacia el servidor bajo otro usuario

cr0x@server:~$ smbstatus -b
Samba version 4.18.6
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
--------------------------------------------------------------------------------------------------------------------------------------------
2311    bob          domain users  10.20.5.44 (ipv4:10.20.5.44:51210)        SMB3_11           -                    partial(AES-128-CMAC)

Qué significa: Ese cliente ya tiene una sesión SMB como bob. Windows es famoso por reutilizar sesiones por nombre de servidor, y entonces aparece “Access Denied” cuando esperabas que fuera alice.

Decisión: En el cliente, desconecta los mapeos existentes y vuelve a conectar con la identidad correcta. En el servidor, no “arregles” permisos para el usuario equivocado.

Tarea 15: Valida controles de acceso a nivel de recurso (“valid users”, “write list”)

cr0x@server:~$ grep -nE '^\[finance\]|valid users|write list|read only' /etc/samba/smb.conf
42:[finance]
45:	valid users = @EXAMPLE\finance-rw
46:	read only = no

Qué significa: Solo miembros del grupo finance-rw pueden conectarse. Eso tiene sentido. Pero la resolución de grupo debe funcionar.

Decisión: Si ves un error tipográfico en el nombre del grupo, o el prefijo de dominio es incorrecto, arréglalo. Si quieres acceso de solo lectura para otros, crea un grupo separado y especifícalo explícitamente—no confíes en la pertenencia general a “Domain Users”.

Tarea 16: Revisa si la firma SMB es obligatoria y qué hace el servidor

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'server signing|client signing'
	server signing = mandatory
	client signing = mandatory

Qué significa: Este servidor exige SMB firmado. Algunos clientes/opciones de montaje no lo soportarán, y fallarán de maneras que parecen problemas de acceso.

Decisión: Mantén la firma como obligatoria en la mayoría de redes corporativas. Si un cliente no puede hacer firma SMB, el problema está en el cliente. Actualízalo o aíslalo.

Broma corta #1: SMB1 es como un teléfono plegable: nostálgico, sorprendentemente resistente, y absolutamente no lo que quieres custodiando la nómina.

Endurecimiento que no rompe el acceso

Deja de tratar SMB1 como una muleta de compatibilidad

Reactivar SMB1 para “arreglar acceso” normalmente está enmascarando uno de estos problemas:

• Un dispositivo antiguo solo soporta SMB1 (los MFP son reincidentes).
• El cliente está mal configurado para SMB2/3 (opciones de montaje incorrectas, DNS roto, nombre de host equivocado).
• Desajuste de política de autenticación (restricciones NTLM, Kerberos fallando por tiempo o SPN).

SMB1 oculta el problema subyacente al cambiar la ruta de negociación. Eso no soluciona; solo redirige la alarma hacia otro altavoz.

Usa SMB2/3 deliberadamente: dialectos, firma, cifrado

Endurecer SMB no es “activar todos los botones”. Es seleccionar los controles correctos para tu modelo de amenaza y base de clientes.

• Dialectos: Establece server min protocol = SMB2_10 (o superior). SMB2_10 es un suelo pragmático para Windows moderno y la mayoría de clientes Linux.
• Firma: Mantén server signing = mandatory en servidores miembro en entornos de dominio a menos que tengas una razón medida de rendimiento. La firma previene la manipulación y algunos ataques de degradado.
• Cifrado: Usa cifrado SMB3 para recursos que atraviesan redes no confiables o contienen datos sensibles. Pero entiende los costes operativos: CPU, complejidad para depurar y compatibilidad de clientes.

Haz la autorización aburrida: ACLs de recurso + ACLs del sistema de archivos + mapeo de identidad

La forma más rápida de generar tickets de “Acceso denegado” es dejar que permisos de recurso y ACLs del sistema de archivos discrepen. Elige un modelo:

• Modelo A (recomendado): Usa grupos AD como fuente de la verdad. Controla acceso al recurso con valid users y aplica en disco con ACLs. Mantén bits de modo POSIX mínimos pero no engañosos.
• Modelo B: Usa grupos POSIX locales (no AD) y mapealos cuidadosamente. Funciona, pero es fácil desviarse entre servidores.

En Samba, la capa de “traducción” es el mapeo de identidad. Si idmap es inestable, verás usuarios perder acceso aleatoriamente tras reinicios, actualizaciones o cambios de dominio.

No rompas Kerberos con alias

Los tickets Kerberos se emiten para principals de servicio. Si los usuarios se conectan a \\files-alias\share pero tus SPN sólo cubren files01, los clientes pueden retroceder a NTLM o fallar si NTLM está bloqueado. Esto puede manifestarse como “Acceso denegado” aunque la contraseña sea correcta.

Mantén el acceso de invitado explícito, no accidental

El acceso de invitado es o bien un requisito deliberado del producto o bien una mala configuración. No hay mucho punto intermedio. La versión peligrosa es “es invitado porque algo más falló”. Si no necesitas recursos de invitado, establece map to guest = Never, desactiva recursos de invitado y deja que los fallos de autenticación sean ruidosos.

Tres minihistorias corporativas (qué sucede en la práctica)

Mini-historia 1: El incidente provocado por una suposición equivocada

Migraron un servidor de archivos desde una VM Windows envejecida a una caja Linux nueva con Samba. El plan del proyecto tenía el optimismo habitual: “Mismos nombres de recurso, mismos permisos, corte por la noche.” El equipo probó con una cuenta de administrador, entró, creó una carpeta y declaró victoria.

El lunes por la mañana, Finanzas no podía abrir nada. RRHH podía explorar pero no guardar. Ingeniería estaba bien, porque su grupo tenía permisos Unix amplios desde una era anterior. Se acumularon tickets con la misma captura de pantalla: “Access Denied.” El ingeniero de guardia hizo lo que hacen los humanos bajo presión: buscó la palanca más rápida. Alguien dijo: “¿Tal vez el servidor viejo usaba SMB1?”

No fue así. La suposición equivocada era más sutil: asumieron que los permisos de Windows eran toda la historia. En el lado Linux, el árbol de directorios tenía bits de modo POSIX demasiado restrictivos en un directorio padre. Las pruebas de admin pasaron porque los administradores se mapeaban a un grupo privilegiado. Los usuarios normales chocaron con un “no execute/search” en un directorio intermedio y fueron denegados. La interfaz de Windows lo reportó como si el archivo los rechazara personalmente.

Lo solucionaron alineando los modelos: grupos AD mapeados correctamente, ACLs del sistema aplicadas a la ruta completa, y dejaron de usar “a mí me funciona” como plan de pruebas. El postmortem fue claro: el control de acceso no es un único interruptor, es una cadena. Si solo pruebas con palancas grandes, todas las puertas parecen abiertas.

Mini-historia 2: La optimización que salió mal

Otra empresa tenía problemas de rendimiento en un recurso concurrido. Los usuarios se quejaban de listados lentos y aperturas de archivos. Un ingeniero detectó que la firma SMB tenía sobrecarga. Cambió la configuración de Samba para hacer la firma “auto” y celebró cuando los benchmarks sintéticos mejoraron.

Dos semanas después, seguridad desplegó una política de dominio que requería firma SMB para ciertos clientes y servidores. De repente, un subconjunto de clientes Windows empezó a fallar al acceder al recurso. No de forma consistente. No de forma ruidosa. Solo “Access Denied” e “The request is not supported”, dependiendo de la versión del cliente y de lo que negociara.

El problema no fue solo el cambio de configuración—fue la falta de un contrato explícito. Cuando dejas que la firma flote según la negociación, estás externalizando la postura de seguridad a lo que el cliente quiera hacer ese día. Mezcla eso con aplicación de políticas y obtienes caos disfrazado de compatibilidad.

Revirtieron a server signing = mandatory, luego arreglaron el verdadero problema de rendimiento: demasiados archivos pequeños en el sistema de respaldo que necesitaba ajuste, además de un punto caliente en el escaneo antivirus del lado cliente. La lección quedó clara: una “optimización” que debilita la corrección es simplemente deuda técnica con mejor marketing.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización global ejecutaba servidores miembro Samba en múltiples sitios. Nada sofisticado: autenticación AD, recursos cerrados, SMB3. La práctica aburrida: cada cambio en la configuración SMB requería una prueba canaria desde tres tipos de cliente (Windows, montaje CIFS en Linux y una cuenta de servicio usando smbclient), además de revisión de logs por fallos de autenticación.

Un trimestre, una actualización rutinaria del SO trajo una actualización de Samba con defaults ligeramente distintos alrededor de NTLM y mapeo de invitado. La mayoría de equipos la habrían desplegado y esperaron que las quejas de usuarios fueran QA gratis. Este equipo ejecutó la canaria. El montaje CIFS de Linux empezó a fallar con “permission denied” mientras Windows funcionaba.

La verificación canaria apuntó directamente al problema: el montaje usaba NTLM donde el entorno esperaba Kerberos, y la nueva compilación de Samba era menos tolerante. Actualizaron el montaje para usar Kerberos correctamente y rotaron el enfoque de la cuenta de servicio donde fue necesario. Los usuarios no se enteraron. Ese es el punto.

Broma corta #2: El sistema más fiable es el que nadie menciona en la reunión de estado—porque se negó a convertirse en “una oportunidad de aprendizaje emocionante”.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Windows pide credenciales repetidamente y luego “Access Denied”

Causa raíz: Se está usando la identidad equivocada (credenciales en caché), o el servidor rechaza el método de autenticación (NTLM deshabilitado, Kerberos fallando).

Solución: Borra sesiones existentes hacia ese nombre de servidor, asegura el SPN/nombre de host correcto, verifica que Kerberos funcione (kinit en Linux, inicio de sesión de dominio correcto en Windows) y revisa logs de Samba por “mapped to guest” o bloqueos NTLM.

2) Síntoma: Puedo listar el recurso, pero no abrir subcarpetas

Causa raíz: Falta permiso de “execute/search” en algún directorio del camino, o desajuste de herencia entre ACLs de Windows y POSIX.

Solución: Inspecciona la cadena completa de directorios y ACLs; no mires solo la carpeta final. En Samba, considera manejo consistente de ACLs (p. ej., vfs objects apropiados para tu diseño) y garantiza que el mapeo de identidad sea estable.

3) Síntoma: Linux mount -t cifs devuelve “Permission denied”, Windows funciona

Causa raíz: El montaje de Linux usa NTLM por defecto mientras el servidor espera Kerberos o rechaza NTLM. O el cliente Linux está negociando un dialecto antiguo.

Solución: Monta con Kerberos (sec=krb5) y especifica vers=3.1.1 (o al menos SMB3). Asegura que la máquina tenga tickets Kerberos válidos y DNS correcto.

4) Síntoma: Todo dejó de funcionar tras “deshabilitar SMB1”

Causa raíz: Un dispositivo legado (escáner, NAS, sistema embebido antiguo) solo soporta SMB1, o dependía de comportamiento anónimo/invitado.

Solución: Reemplaza o actualiza el dispositivo, o aíslalo en un servidor/VLAN de legado con controles compensatorios. No vuelvas a habilitar SMB1 en tus servidores principales.

5) Síntoma: El acceso funciona vía \\server\share pero falla vía \\alias\share

Causa raíz: Desajuste SPN Kerberos; alias no registrado, provocando fallback a NTLM o fallo cuando NTLM está bloqueado.

Solución: Usa el nombre canónico, registra SPNs adecuados para el alias, o configura DFS correctamente. Trata la arquitectura de nombres como parte del diseño de autenticación, no como cosmética.

6) Síntoma: Algunos usuarios en el grupo AD correcto siguen siendo denegados

Causa raíz: Pertenencia a grupos no visible por problemas de tamaño de token, límites de resolución de grupos anidados, o inconsistencias de idmap entre servidores.

Solución: Reduce anidamientos excesivos, valida el mapeo de identidad y comprueba la lista efectiva de grupos en el servidor con id / getent group. Estabiliza rangos y backend de idmap.

7) Síntoma: Los logs de Samba muestran que el usuario se convierte en “nobody”

Causa raíz: Falla de autenticación mapeada a guest (map to guest = Bad User), o winbind/sssd no resuelve la identidad.

Solución: Deshabilita mapeo a guest salvo que sea necesario, arregla resolución NSS, corrige la unión al dominio y confirma wbinfo -t y id DOMAIN\\user.

8) Síntoma: “Access Denied” solo para escrituras, lecturas funcionan

Causa raíz: read only o mismatch en write list a nivel de recurso; ACL del sistema de archivos niega creación/eliminación; o un producto antivirus/EDR bloquea escrituras vía políticas SMB.

Solución: Confirma opciones del recurso Samba y prueba con smbclient mkdir/rmdir; luego inspecciona ACLs del sistema. Si hay políticas implicadas, coordina con equipos de endpoint/seguridad aportando evidencia.

Listas de verificación / plan paso a paso

Paso a paso: arreglar “Acceso denegado” sin debilitar SMB

1. Prueba conectividad: el servidor escucha en 445, el firewall lo permite para la subred cliente.
2. Confirma política de dialectos: SMB1 deshabilitado; SMB2/3 activados. Asegúrate de que el cliente lo soporte.
3. Reproduce con smbclient: prueba listado de recursos y operaciones simples con las mismas credenciales.
4. Lee los logs del servidor: identifica si el usuario está autenticado, mapeado a guest, o falla por política.
5. Valida mapeo de identidad: id DOMAIN\\user y pertenencia a grupos coinciden con el acceso esperado.
6. Revisa reglas a nivel de recurso: valid users, read only, write list, force user/force group.
7. Chequea ACLs del sistema de archivos de extremo a extremo: asegura execute/search a lo largo de la ruta y semántica de herencia correcta.
8. Verifica ajustes de seguridad obligatorios: ¿firma requerida? ¿cifrado requerido? ¿NTLM restringido?
9. Corrige el desajuste, no el síntoma: actualiza opciones de montaje del cliente, arregla SPNs, sincroniza tiempo, estabiliza idmap, ajusta ACLs.
10. Fíjalo: añade una prueba canaria y alertas basadas en logs para mapeo a guest/fallos de autenticación.

Lista de endurecimiento que no debería causar incidentes de acceso

• Establece SMB1 desactivado por política (server min protocol en SMB2_10 o superior).
• Exige firma SMB en entornos de dominio salvo excepciones medidas.
• Usa cifrado SMB para recursos sensibles que crucen redes menos confiables; no lo habilites a ciegas sin presupuesto de CPU.
• Prefiere Kerberos para clientes de dominio; restringe NTLM con pruebas para clientes Linux/servicios.
• Mantén sincronía de tiempo saludable en clientes y servidores.
• Haz estable el mapeo de identidad (mismo backend idmap y rangos consistentes entre servidores).
• Audita mapeo a guest y elimina accesos invitados accidentales.
• Usa acceso explícito por grupos y mantiene ACLs consistentes entre capas.
• Activa logging suficiente para distinguir fallos de autenticación vs ACL vs políticas.

Preguntas frecuentes

1) ¿Por qué ocurre “Acceso denegado” justo después de deshabilitar SMB1?

Porque un cliente/dispositivo dependía silenciosamente de SMB1 (o de comportamiento anónimo de la era SMB1). Deshabilitar SMB1 eliminó la ruta de retroceso y reveló la incompatibilidad real.

2) ¿La firma SMB es lo mismo que el cifrado SMB?

No. La firma protege integridad (evita manipulación). El cifrado protege confidencialidad (evita espionaje). Puedes tener firma sin cifrado, y a menudo deberías.

3) Si Windows puede acceder al recurso, ¿por qué el montaje CIFS en Linux recibe “permission denied”?

Windows en dominio suele usar Kerberos automáticamente. Los montajes Linux pueden usar NTLM por defecto. Si el servidor o la política del dominio bloquean NTLM, Linux falla mientras Windows funciona.

4) ¿Debo poner “map to guest = Bad User”?

Sólo si tienes un caso de uso de invitados bien definido. En entornos corporativos endurecidos, es más seguro fallar la autenticación de forma ruidosa que mapear silenciosamente a guest y generar negaciones confusas.

5) ¿Puede el cifrado SMB causar “Acceso denegado”?

Sí, de forma indirecta. Si el cifrado es obligatorio y el cliente no puede negociarlo (SO antiguo, firmware antiguo del NAS, cliente mal configurado), el setup de sesión puede fallar y manifestarse como problemas de acceso.

6) ¿Cuál es la forma más rápida de saber si son ACLs o autenticación?

Si smbclient -L falla para un usuario, es autenticación/política. Si listar funciona pero mkdir falla, es autorización (reglas del recurso o ACLs del sistema). Los registros confirman cuál.

7) ¿Necesito habilitar SMB1 para escáneres antiguos?

Prefiere reemplazarlos o actualizarlos. Si absolutamente debes soportar dispositivos solo SMB1, aíslalos en un endpoint legado dedicado con controles de red estrictos—nunca en tus servidores principales.

8) ¿Por qué funciona el acceso por IP del servidor pero no por nombre de host?

Porque Kerberos depende del nombre de host (SPN). Usar una IP a menudo fuerza NTLM o rompe la política. Arregla DNS/SPN y usa nombres de host correctos.

9) ¿Cómo evito futuras tormentas de “Acceso denegado” tras actualizaciones?

Ejecuta pruebas canarias desde múltiples tipos de cliente, monitoriza logs de Samba por fallback de autenticación/mapeo a guest, y mantén tu mapeo de identidad y sincronía de tiempo aburridos y consistentes.

Conclusión: próximos pasos que puedes hacer hoy

Si te quedas con una regla operativa: nunca “arregles” Access Denied bajando el piso del protocolo. Deshabilitar SMB1 es la línea base; depuras por encima de ella, no alrededor.

Haz esto a continuación:

1. Ejecuta el guion de diagnóstico rápido: determina si fallas en negociación, autenticación o autorización.
2. Usa smbclient y los logs del servidor para reproducir y clasificar la falla—no discutas con un cuadro de diálogo de Windows.
3. Estabiliza el mapeo de identidad y la resolución de grupos, luego alinea reglas de recurso con ACLs del sistema.
4. Aplica firma, usa cifrado donde esté justificado y prueba clientes antes de cambiar políticas.
5. Añade una canaria y mantenla: un cliente Windows, un montaje Linux, una cuenta de servicio con smbclient. Ser aburrido salva fines de semana.