Restablecer permisos NTFS tras quitar un recurso compartido en Windows Server 2022

¿Alguna vez has descompartido una carpeta en Windows Server 2022 y al volver a la pestaña Seguridad has descubierto que faltan entradas NTFS? Tranquilo: Windows no ha “borrado” tus permisos de forma caprichosa. En esta guía profunda aclaramos qué ocurre realmente, por qué la interfaz puede confundir y, sobre todo, cómo proteger y restaurar tus listas de control de acceso (ACL) para evitar sorpresas en producción.

Diferencias entre permisos de recurso compartido y NTFS

Windows expone la misma carpeta a dos capas de control totalmente independientes:

• Permisos de recurso compartido (SMB): se aplican únicamente al tráfico de red. Se configuran en la pestaña “Uso compartido”.
• Permisos NTFS: gobiernan el acceso local y remoto. Se gestionan desde la pestaña “Seguridad” o con herramientas CLI/PowerShell.

Cuando haces clic en Dejar de compartir, Windows solo elimina la ACL de recurso compartido. A nivel NTFS, las ACE (Access Control Entries) permanecen tal cual a menos que el asistente de uso compartido las haya modificado previamente para cumplir tus selecciones (por ejemplo, al marcar “Permitir que todos lean”).

Qué sucede internamente al compartir una carpeta en Windows Server 2022

1. El administrador lanza el Asistente para uso compartido.
   Opcional: si elige “Usuarios concretos” y asigna Everyone → Lectura/Escritura, el asistente:
   • Crea una ACE NTFS para Everyone en la carpeta raíz a nivel Allow → Modify.
   • Configura la lista de permisos del recurso compartido acorde a la selección.
2. Cuando se pulsa Detener uso compartido, Windows:
   • Elimina la lista SMB (solo afecta a la red).
   • No revierte ningún cambio NTFS introducido en el paso 1, porque no guarda instantáneas de la ACL previa.

Por qué parece que “desaparecen” permisos al dejar de compartir

Las causas más habituales son:

• Herencia oculta: la vista básica de la pestaña Seguridad agrupa o esconde ACE heredadas. Haz clic en Opciones avanzadas y marca Muestra entradas heredadas para verla completa.
• Confusión entre cuentas locales y de dominio: Administrador y DOMAIN\Administrador son objetos diferentes. El cuadro de diálogo los muestra por separado; si has iniciado sesión con credenciales de dominio, verás resaltado ese contexto.
• Modificaciones del asistente: si en el pasado permitiste Everyone → Modificar, al detener el uso compartido sigues viendo esa ACE y podrías pensar que “faltan” las entradas originales (en realidad, fueron reemplazadas cuando creaste el share).

Cómo evitar la pérdida accidental de entradas NTFS

Acción	Herramienta/Comando	Descripción
Exportar ACL antes de cambios	icacls "D:\Datos" /save acl.bak	Guarda la ACL recursivamente en un archivo plano con formato SDDL.
Restaurar ACL original	icacls "D:\Datos" /restore acl.bak	Revierte la ACL completa tal y como estaba al exportarla.
Auditar modificaciones	Directiva de auditoría avanzada	Activa Auditar cambios de permisos para registrar cada escritura en la ACL.
Comparar versiones	Get-Acl + Compare-Object	Identifica diferencias entre la ACL actual y la respaldada.
Aplicar estándar corporativo	GPO (Objetos de directiva de grupo)	Reimpone permisos correctos en inicio de sesión o en horario programado.

Procedimiento paso a paso para guardar y restaurar ACL con ICACLS

1. Respaldar la ACL antes de compartir: icacls "D:\Finanzas" /save "C:\Backups\ACL_Finanzas.bak" /t /t procesa subcarpetas.
2. Compartir la carpeta con el asistente sin temor a perder configuraciones.
3. Detener el recurso compartido cuando ya no sea necesario.
4. Si observas permisos inesperados, restaura: icacls "D:\Finanzas" /restore "C:\Backups\ACL_Finanzas.bak"
5. Verifica con: Get-Acl "D:\Finanzas" | Select -Expand Access

Ejemplo real: laboratorio reproducible

Prueba en una VM de prueba para ver el fenómeno:

1. Crea D:\Lab y asigna permisos NTFS predeterminados (heredados desde D:).
2. Desde el Explorador, elige Compartir → Compartir con usuarios específicos → Everyone → Lectura/Escritura.
3. Ejecuta icacls D:\Lab y comprueba que Everyone (Modify) aparece en la ACL NTFS.
4. Pulsa Detener uso compartido y repite icacls. Verás que la ACE para Everyone se mantiene: Windows no la quita.
5. Restaura tu backup y compara de nuevo para confirmar que la ACL vuelve a su estado original.

Buenas prácticas de gestión de permisos

• Principio de mínimo privilegio: empieza siempre por la ACL NTFS más restrictiva (normalmente Lectura) y usa permisos de recurso compartido para relajar el acceso si es imprescindible.
• No edites la ACL NTFS desde el asistente: opta por Uso compartido avanzado y limita solo la lista SMB.
• Usa grupos en lugar de cuentas sueltas: facilita auditoría y rotación de personal.
• Evita híbridos local/dominio: mezcla de identidades dificulta el soporte y genera confusión en la consola.
• Automatiza la corrección: un script PowerShell diario que aplique la ACL oficial elimina el riesgo humano.

Herramientas adicionales y auditoría

Además de ICACLS y Get-Acl, considera:

• Security Configuration Wizard (SCW): define plantillas de seguridad reproducibles.
• NTFS Rights Reporter (GUI gratuita): genera diagramas y exporta a CSV los permisos efectivos de todo un árbol.
• Eventos 4670 (Security Log): indican cada vez que se modifica la ACL de un objeto.
• Advanced Threat Analytics o SIEM corporativo: correlaciona cambios de permisos con otras actividades sospechosas.

Preguntas frecuentes

¿Puedo forzar a Windows a “recordar” la ACL previa al compartir?

No. Windows Server no almacena instantáneas de la ACL al iniciar el asistente. La única solución fiable es exportar la lista con ICACLS o una copia de seguridad que incluya permisos.

¿Por qué la pestaña Seguridad agrupa varias entradas como “Authenticated Users”?

Cuando hay muchas ACE análogas, la interfaz reduce el ruido usando identificadores bien conocidos. Expande desde Avanzadas para ver cada línea en detalle.

¿Cambiar la herencia afecta al recurso compartido?

No directamente. La herencia es propiedad de NTFS. Sin embargo, si revocas herencia y eliminas ACE, los usuarios pueden perder acceso incluso aunque la lista SMB diga “Control total”.

¿Y si uso DFS Namespaces?

DFS aplica la misma lógica: la ACL NTFS reside en los servidores de destino. La ACL de recurso compartido es la del path compartido. Mantén backups igualmente.

Conclusión

Lo que a primera vista parece un “borrado” de permisos tras descompartir es en realidad una consecuencia de no separar claramente las dos capas de seguridad. Si respaldas la ACL antes de abrir el recurso, documentas tus cambios y aplicas el principio de menor privilegio, jamás volverás a perder entradas NTFS críticas.