Windows Server 2025: “An extended error has occurred” al mapear SMB en NAS/Samba — causa y solución

En Windows Server 2025, algunos intentos de mapear unidades SMB alojadas en NAS/Samba fallan con “An extended error has occurred”. Aquí verás por qué ocurre (endurecimiento de SMB signing) y varias formas seguras de solucionarlo sin volver a configuraciones inseguras.

Índice

Resumen del problema

Tras actualizar o desplegar Windows Server 2025, el mapeo de una carpeta compartida por un NAS o un servidor Samba devuelve el mensaje genérico “An extended error has occurred”. El mismo recurso, sin embargo, se montaba con normalidad desde Windows Server 2022 o Windows 11, y los recursos compartidos alojados en Windows siguen funcionando.

Aunque actives “Insecure guest logons”, el problema persiste en muchos entornos. La causa no es un bug aislado, sino un cambio de seguridad deliberado en el cliente SMB de 2025.

Qué está pasando

Windows Server 2025 endurece la pila SMB del cliente y, por defecto, exige firma digital (SMB signing) en todas las conexiones salientes. Cuando el destino no negocia firma —o intenta acceso como invitado (guest), que no admite firma ni cifrado— la conexión se rechaza en la fase de negociación y el Explorador muestra el error genérico.

En otras palabras: si el NAS/Samba permite acceso anónimo o no tiene la firma correctamente habilitada, Windows 2025 se negará a montar la unidad. Esto explica por qué “habilitar guest” no arregla nada: una sesión invitado no puede firmar.

Indicadores y síntomas

El mapeo de \\NAS\Share falla con “An extended error has occurred”.
Al probar con un recurso compartido alojado en Windows, el mapeo funciona.
Con un usuario y contraseña válidos en el NAS, a veces funciona; con invitado, casi siempre falla.
En entornos con Samba antiguos o con “acceso abierto”, el problema es sistemático.

Cómo confirmarlo en minutos

Comprueba la configuración del cliente SMB:

# Ejecuta PowerShell como administrador
Get-SmbClientConfiguration | Select RequireSecuritySignature, EnableSecuritySignature, EnableInsecureGuestLogons

En Windows Server 2025 verás normalmente RequireSecuritySignature : True. Esto obliga a firmar todas las conexiones salientes.

Revisa eventos del cliente SMB:

Visor de eventos → Applications and Services Logs → Microsoft → Windows → SMBClient → Security y Connectivity. Encontrarás eventos que indican negociación fallida por requisitos de firma o por sesión invitado.

Descarta problemas de red:

Test-NetConnection -ComputerName NOMBREOIPDELNAS -Port 445

Si el puerto 445 está accesible, el fallo no es de conectividad, sino de seguridad/negociación.

Soluciones posibles

Hay varias formas de resolverlo. La recomendada es corregir el lado servidor para cumplir el requisito de firma y autenticación. Como alternativa temporal, puedes relajar la exigencia de firma en el cliente 2025 (con impacto de seguridad). Y, solo si es imprescindible, permitir invitado y quitar la exigencia de firma sabiendo que estás abriendo una brecha importante.

Habilitar firma y autenticación en el NAS/Samba — Recomendado

Esta opción alinea el servidor de ficheros con las expectativas de Windows Server 2025. Implica:

Usar SMB2/SMB3 (no SMB1).
Exigir autenticación con usuario/contraseña (evitar guest).
Habilitar firma (signing) en el servidor.

Ejemplo de `smb.conf` en Samba

Abre /etc/samba/smb.conf y, en la sección [global], ajusta:

[global]
   workgroup = WORKGROUP
   server min protocol = SMB2
   # Habilita y/o exige firma en el servidor
   server signing = auto        # o 'mandatory' para forzarla siempre
   # Opcional: si tus clientes lo soportan, permite cifrado SMB
   smb encrypt = desired        # 'required' para forzar cifrado
   # Evita el acceso anónimo siempre que sea posible
   map to guest = Bad User

Y define el recurso con usuarios válidos:

[datos]
   path = /srv/samba/datos
   read only = no
   valid users = usuario1

Checklist del NAS/Samba

Crear un usuario local en el NAS (p. ej., usuario1) y asignarle permisos en la carpeta.
Deshabilitar “acceso invitado” a ese recurso o limitarlo a lectura temporalmente mientras migras.
Reiniciar Samba/NAS para aplicar cambios.
Probar mapeo desde Windows Server 2025 con credenciales:

net use Z: \\NAS\datos /user:usuario1 Tu_Secreta /persistent:yes

Notas

En SMB2/3 la firma se negocia de forma nativa; con server signing = mandatory te aseguras de que el servidor no acepte conexiones sin firmar.
Si tu NAS ofrece una casilla de “SMB signing” en su panel, actívala. Evita SMB1.
Si puedes, habilita también cifrado (SMB encryption) en recursos sensibles; añade coste CPU, pero protege en redes no confiables.

Relajar el requisito de firma en el cliente 2025 — Temporal y con riesgo

Úsalo solo en redes muy controladas y mientras actualizas el NAS/Samba. Desactiva la exigencia de firma en el cliente:

# Ver estado actual
Get-SmbClientConfiguration | Select RequireSecuritySignature,EnableSecuritySignature

Desactivar la exigencia de firma para conexiones salientes

Set-SmbClientConfiguration -RequireSecuritySignature \$false

Reiniciar el servicio del cliente SMB

Restart-Service LanmanWorkstation

También puedes aplicar una GPO: Equipo → Configuración de Windows → Configuración de seguridad → Directivas locales → Opciones de seguridad → “Microsoft network client: Digitally sign communications (always)” = Deshabilitado.

Riesgo: al permitir conexiones sin firma, abres la puerta a ataques de manipulación (tampering) y retransmisión. Documenta la excepción, limítala por OU/grupo y réstaurala cuanto antes.

Permitir invitado y quitar firma para ese escenario — No recomendado

El invitado no puede firmar ni cifrar; por eso, para que funcione, además de permitir guest debes dejar de exigir firma en el cliente. Es una concesión fuerte y solo debería usarse puntualmente:

# Permitir invitado y dejar de exigir firma en el cliente
Set-SmbClientConfiguration -EnableInsecureGuestLogons $true
Set-SmbClientConfiguration -RequireSecuritySignature $false

Restart-Service LanmanWorkstation

En cuanto termines la tarea puntual, revierte a un estado seguro (ver más abajo).

Validaciones y pruebas tras aplicar cambios

Mapeo con usuario real:

net use Z: \\NAS\datos /user:usuario1 Tu_Secreta /persistent:yes

Comprobación de políticas y estado del cliente:

Get-SmbClientConfiguration | fl RequireSecuritySignature,EnableSecuritySignature,EnableInsecureGuestLogons

Eventos SMB del cliente: confirma que ya no aparecen rechazos por firma o por invitado en SMBClient → Security/Connectivity.

Tabla comparativa de opciones

Opción	Seguridad	Cuándo usar	Ventajas	Riesgos
Habilitar firma y autenticación en NAS/Samba	Alta	Entornos en producción, datos sensibles, cumplimiento	Compatible con 2025, alineado a buenas prácticas, sin excepciones de cliente	Requiere tocar NAS/Samba y crear cuentas
Relajar firma en el cliente 2025	Media–Baja	Temporal mientras actualizas NAS/Samba	Rápido de aplicar, sin cambios en el NAS	Exposición a manipulación/relay en SMB si la red es hostil
Permitir invitado y quitar firma	Baja	Casos puntuales de legado sin alternativa	Permite convivir con equipos muy antiguos	Pérdida de garantías de autenticidad e integridad; no usar en producción

Procedimiento recomendado paso a paso

Identifica el recurso afectado y confirma si se usa guest o cuentas locales.
Crea un usuario en el NAS/Samba y dale permisos explícitos en la carpeta.
Habilita firma en el servidor (en Samba, server signing = auto o mandatory; en NAS, marca la opción equivalente).
Deshabilita acceso invitado en ese recurso o déjalo solo para transición.
Reinicia servicios de archivos en el NAS y vuelve a mapear desde Windows 2025 con credenciales.
Revisa eventos y deja constancia del cambio en tu documentación.
Si no puedes tocar el NAS, aplica la excepción de cliente con GPO/PowerShell, limitada y temporal.

Buenas prácticas que marcan la diferencia

Evita SMB1 por completo. Si un equipo solo habla SMB1, aísla y planifica su retirada.
Segmenta por OU las GPO que relajen firma. No apliques una excepción global por un único NAS antiguo.
Audita periódicamente en SMBClient → Security/Connectivity y en el servidor de archivos.
Usa Kerberos cuando haya dominio AD; reduce la dependencia de NTLM y mejora la seguridad de la sesión.
Activa cifrado SMB en recursos con información sensible o expuestos a redes menos confiables.

Cosas que no lo arreglan

Marcar solo “Enable insecure guest logons”: el invitado no puede firmar; el cliente 2025 seguirá rechazando la sesión si exige firma.
Forzar SMB1: además de inseguro, introduces compatibilidad frágil y problemas de rendimiento.
Desactivar el firewall de Windows: no tiene relación con la negociación de firma SMB.

Apéndice de directivas y registro

Cliente SMB de Windows (GPO)

Microsoft network client: Digitally sign communications (always) → controla la exigencia de firma.
Microsoft network client: Digitally sign communications (if server agrees) → controla si se intenta firmar cuando el servidor lo soporta.
Enable insecure guest logons → Plantillas administrativas → Red → Estación de trabajo Lanman.

Claves de registro útiles (editar solo si sabes lo que haces):

HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature (DWORD 0/1)
HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\EnableSecuritySignature (DWORD 0/1)
HKLM\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation\AllowInsecureGuestAuth (DWORD 0/1)

Revertir a un estado seguro

Si aplicaste excepciones en el cliente, vuelve a la configuración reforzada en cuanto actualices el NAS/Samba:

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbClientConfiguration -EnableInsecureGuestLogons $false
Restart-Service LanmanWorkstation

Preguntas frecuentes

¿Por qué funcionaba en Windows Server 2022 o Windows 11 y ahora no?
Porque en 2025 la exigencia de firma es más estricta por defecto para conexiones salientes. Un NAS que dependía de invitado o de sesiones sin firma ahora queda fuera.

¿La firma SMB impacta rendimiento?
Sí, añade cómputo (hash por paquete). En redes rápidas y hardware actual el impacto suele ser moderado. Para cargas pesadas, valida con pruebas y considera hardware con aceleración.

¿Puedo forzar firma solo para ciertos servidores?
En Windows, la exigencia de firma del cliente es global. Si necesitas excepciones selectivas, controla el alcance con GPO por OU o WMI targeting, y limita la excepción a los equipos que realmente lo requieran.

¿Qué pasa con invitado y cifrado SMB?
Las sesiones invitado no admiten firma ni cifrado en SMB2/3. Si requieres cifrado o firma, el invitado no es opción; usa cuentas autenticadas.

¿Cómo verifico si una conexión quedó firmada?
En el cliente, revisa los eventos en SMBClient → Security/Connectivity. En servidores Windows, Get-SmbSession puede mostrar si hay cifrado activo. En Samba, smbstatus ayuda a inspeccionar sesiones. Para un nivel forense, usa capturas con Message Analyzer/Wireshark.

Ejemplo completo de remediación en Samba

# 1) Editar /etc/samba/smb.conf

[global]

workgroup = OFICINA server min protocol = SMB2 server signing = mandatory smb encrypt = desired \[proyectos] path = /srv/samba/proyectos read only = no valid users = proyectos\_rw 2) Crear usuario del sistema y en Samba useradd -M -s /sbin/nologin proyectos\_rw smbpasswd -a proyectos\_rw 3) Reiniciar servicios systemctl restart smb nmb 4) Mapear desde Windows Server 2025 (PowerShell, como admin) net use P: \NAS\proyectos /user\:proyectos\rw Tu\Secreta /persistent\:yes

Checklist de diagnóstico rápido

¿RequireSecuritySignature está en True en el cliente? → Esperable en 2025.
¿El NAS permite guest o no anuncia firma SMB? → Debes habilitar firma y autenticación.
¿Eventos del cliente muestran negociaciones fallidas por firma/invitado? → Confirma la causa raíz.
¿Tras activar firma y usar usuario real, el mapeo funciona? → Caso resuelto sin concesiones inseguras.

Conclusión

No es, en general, un fallo de Windows Server 2025, sino un endurecimiento intencionado del cliente SMB. La forma limpia de resolver el error “An extended error has occurred” al mapear unidades en NAS/Samba es activar firma y autenticación en el servidor y abandonar el acceso invitado. Si necesitas una solución temporal, puedes relajar la exigencia de firma en el cliente 2025 mediante PowerShell o GPO, entendiendo y acotando el riesgo. Solo como último recurso combinar guest y ausencia de firma.

Fuentes consultadas

SMB security hardening in Windows Server 2025 & Windows 11 (Microsoft Tech Community).
Overview of Server Message Block (SMB) signing in Windows (Microsoft Learn).
Manual de smb.conf (Samba Project).
Control SMB signing behavior (Microsoft Learn).
How to enable insecure guest logons in SMB2 and SMB3 (Microsoft Learn).
Event log data for troubleshooting SMB (Microsoft Support).

Reversión rápida (por si aplicaste una excepción temporal):

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbClientConfiguration -EnableInsecureGuestLogons $false
Restart-Service LanmanWorkstation

En resumen: Windows Server 2025 ahora exige integridad de extremo a extremo para SMB. Ajusta tu NAS/Samba para firmar y autenticar, y el problema desaparecerá sin sacrificar seguridad.