Windows Server 2025 / Comprobar la firma SMB y probar el cifrado de un recurso compartido

La firma del protocolo de Bloque de mensajes del servidor (Server Message Block, SMB) protege la integridad de los mensajes; el cifrado SMB protege el contenido durante la transmisión. Si falla el acceso a una carpeta compartida, compruebe el nombre del servidor, la identidad, la compatibilidad y la conexión real antes de modificar sus protecciones.

Distinga firma, cifrado y permisos

Control Finalidad
Firma SMB Detectar la alteración de mensajes y proteger la comunicación autenticada
Cifrado SMB Proteger el contenido de los archivos durante su transmisión por la red
Permisos del recurso y de NTFS Limitar las operaciones permitidas a una identidad autenticada

Una conexión firmada no implica que su contenido esté cifrado; cifrar el tráfico tampoco corrige permisos de archivos excesivos ni cifra los datos guardados en disco. La guía específica de firma SMB distingue los requisitos de salida de Windows Server 2025: FS1 actúa como cliente cuando accede a otro servidor. No presuponga el mismo requisito de entrada para todas las funciones de servidor. Los objetos de directiva de grupo (GPO) y el papel del equipo pueden cambiar la configuración efectiva. NTFS significa New Technology File System, el sistema de archivos cuyos permisos se combinan con los del recurso compartido.

Consulte los requisitos antes de cambiarlos

En PowerShell elevado de FS1, consulte por separado el cliente SMB, que se conecta a otros servidores, y el servidor SMB, que ofrece sus archivos. Use el recurso LabRead de la práctica de permisos SMB y NTFS; confirme su ruta real y que el usuario de prueba puede leer un archivo conocido antes de cambiar nada. Si LabRead no existe o el acceso inicial falla, resuelva eso primero:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EncryptData,RejectUnencryptedAccess
Get-SmbShare -Name 'LabRead' | Select-Object Name,Path,EncryptData

RequireSecuritySignature indica si se exige firma; no demuestra que una sesión concreta esté firmada. EncryptData pertenece aquí al servidor o al recurso según la fila consultada, y RejectUnencryptedAccess controla el rechazo de clientes sin cifrado en el contexto correspondiente. No cambie esos valores globales en esta prueba. La guía de refuerzo de SMB resume las funciones nuevas; para los valores de firma por dirección, use la guía específica anterior y compruebe su equipo. La exigencia de cifrado del cliente puede proceder de otra directiva y no aparece en esta selección de columnas.

Active el cifrado solo en el recurso de prueba

Use únicamente el LabRead del laboratorio aislado y una cuenta de dominio válida. Cierre los archivos abiertos antes de cambiar el recurso. Ejecute primero la asignación de $previousEncryption y compruebe que obtuvo un valor booleano; anótelo también fuera de la sesión para poder restaurarlo si la ventana se cierra. No repita esa asignación después de activar el cifrado, porque perdería el valor inicial. Ejecute las líneas siguientes una a una; confirme el cambio de LabRead si PowerShell lo solicita y deténgase ante un error:

$previousEncryption = (Get-SmbShare -Name 'LabRead').EncryptData
Set-SmbShare -Name 'LabRead' -EncryptData $true
Get-SmbShare -Name 'LabRead' | Select-Object Name,EncryptData

La consulta final debe mostrar LabRead con EncryptData=True. El cifrado SMB requiere compatibilidad en ambos extremos: SMB 3.x anunciado por un equipo no basta si no implementa el cifrado necesario. Mantenga las políticas globales existentes, incluido el rechazo del acceso no cifrado; si el laboratorio ya tiene una excepción que impide una prueba concluyente, revísela antes de continuar. Guarde el trabajo y cierre únicamente las conexiones implicadas antes de volver a conectar por el nombre normal. Si otras aplicaciones mantienen una sesión con FS1, coordine su cierre; cerrar solo la ventana del Explorador no garantiza una conexión nueva. No desconecte indiscriminadamente todas las unidades.

En CLIENT1, abra \\fs1.ad.example.test\LabRead con la misma identidad de dominio y lea el archivo conocido. Ejecute esta consulta en ese cliente, dentro del contexto que abrió la conexión; una consola con otras credenciales puede mostrar sesiones distintas:

Get-SmbConnection | Where-Object ShareName -eq 'LabRead' | Select-Object ServerName,ShareName,Dialect,Encrypted

Compruebe ServerName además de ShareName: el filtro solo selecciona LabRead y podría devolver varios servidores. En la fila de fs1.ad.example.test, Dialect debe identificar una versión SMB 3.x compatible y Encrypted debe ser True. La referencia de Get-SmbConnection explica que las conexiones dependen del usuario y las credenciales. Si no aparece la fila, confirme que leyó un archivo por esa ruta y que consulta la identidad correcta. Si Encrypted=False, la prueba no ha demostrado cifrado: revise la conexión conservada, el destino y las políticas, en lugar de darla por válida. Esta consulta no muestra el estado Signed. Los permisos de lectura no se convierten en escritura por activar cifrado.

Separe los errores de compatibilidad y autenticación

Síntoma Primera comprobación
Fallo al conectar por nombre DNS, nombre real del servidor y comunicación con el dominio
Error de credenciales o invitado Identidad efectiva, conexiones guardadas y autenticación del dispositivo
Error de firma Soporte y configuración del otro extremo y requisito del cliente
Fallo al activar el cifrado Versión SMB, compatibilidad de cifrado, políticas y eventos del fallo

En el dominio, use el nombre correcto del servidor y autenticación Kerberos cuando corresponda; no intente solucionar un problema de identidad accediendo por IP o por un alias arbitrario. En un almacenamiento conectado a la red (NAS) antiguo, revise sus actualizaciones, cuentas autenticadas y soporte de firma/cifrado. Valore sustitución o aislamiento si no es compatible. No desactive globalmente la firma ni habilite acceso de invitado inseguro o SMB1 como arreglo rápido.

Abra el Visor de eventos → Registros de aplicaciones y servicios → Microsoft → Windows y revise los canales pertinentes de SMBClient en CLIENT1 y SMBServer en FS1. Busque el mismo intervalo del fallo, conserve el código y el mensaje completo y anote equipo, recurso y cuenta; no publique credenciales. Compare el fallo con la tabla: una denegación puede deberse a permisos o a una negociación de seguridad, por lo que el texto aislado «acceso denegado» no determina la causa. Correlacione configuración y eventos antes de cambiar una sola condición y repetir la lectura.

Restaure únicamente el cambio de la prueba

Al terminar la comparación, use la misma sesión de PowerShell de FS1 para restaurar exactamente el valor guardado. Verifique que la variable conserva el booleano original; si se perdió, recupere el valor anotado antes de ejecutar esta línea, sin adivinarlo. No convierta una configuración originalmente cifrada en una sin cifrar:

Set-SmbShare -Name 'LabRead' -EncryptData $previousEncryption

Compruebe de nuevo EncryptData con la consulta anterior y vuelva a establecer la conexión de CLIENT1 para leer el mismo archivo y revisar Encrypted. Si el valor inicial era True, debe seguir siendo True. Si era False, la exigencia de cifrado del cliente u otra política puede mantener la conexión cifrada aun después de restaurar el recurso. No relaje una directiva global para forzar un resultado de comparación. Para un despliegue real, valore los datos protegidos, la compatibilidad, el rendimiento medido en ese entorno y una vía de recuperación; esta prueba no mide rendimiento ni sustituye la revisión de permisos.