Permisos NTFS avanzados para el Shared drive del almacén (sin Deny, con CREATOR OWNER)

Guía práctica para diseñar permisos NTFS en un “Shared drive” de almacén: todos pueden crear y editar, nadie puede borrar ni mover lo ajeno. Sin usar Deny, con CREATOR OWNER, paso a paso en GUI/PowerShell, checklist de pruebas y consejos para impedir exfiltración.

Índice

Escenario y objetivo

El almacén necesita un recurso compartido donde los usuarios puedan crear y editar carpetas y archivos en todo el árbol, pero sin poder eliminar ni mover elementos que no hayan creado ellos mismos. Al intentar resolverlo con entradas Deny, aparecieron efectos colaterales: se podía crear, pero no renombrar; además, los Deny anulan otros permisos y rompen el comportamiento esperado.

Principio clave

Evita ACEs de Deny salvo casos extremos. En lugar de negar, no concedas “Delete” al grupo general y usa CREATOR OWNER para dar permiso de eliminar únicamente al dueño del objeto. Así:

Todos pueden crear/editar en toda la jerarquía.
Solo el dueño de cada objeto puede eliminar/renombrar ese objeto.
Nadie puede mover fuera del árbol lo que no sea suyo (porque mover = copiar + eliminar en origen, y no tienen “Delete”).

ACL recomendada en la raíz del recurso compartido

Configura la DACL (NTFS) de la carpeta raíz del share con estas entradas, en este orden lógico:

Identidad	Permisos	Aplicar a	Notas
`SYSTEM`	Full control	Esta carpeta, subcarpetas y archivos	Requerido por el sistema.
`Administrators`	Full control	Esta carpeta, subcarpetas y archivos	Administración del servidor.
(Opcional) Data Owners / IT	Modify o Full control	Esta carpeta, subcarpetas y archivos	Según la política de datos.
`Group‑RRG‑WHSusers`	Read & Execute + List folder contents + Read + Write (sin “Delete” ni “Delete subfolders and files”)	Esta carpeta, subcarpetas y archivos	Permite crear/editar en todo el árbol, pero no eliminar ni renombrar lo ajeno.
`CREATOR OWNER`	Modify (no Full control)	Subcarpetas y archivos solamente	Da “Delete” solo al dueño del objeto. Evita que los usuarios modifiquen ACLs heredadas.

Idea clave: “Modificar sin eliminar” para el grupo general + “Modificar (con eliminar)” solo para el CREATOR OWNER. Así, quien crea un archivo/carpeta puede renombrarlo o borrarlo; los demás, no.

Notas importantes sobre esta ACL

Herencia: deja habilitada la herencia desde la raíz para simplificar el mantenimiento y evitar DACLs divergentes.
Evita Deny globales (p. ej., Group‑RRG‑Tserver: Deny sobre todo el árbol). Los Deny se imponen sobre los Allow y pueden impedir renombrar incluso al dueño.
“Aplicar a” correcto: CREATOR OWNER debe ser “Subcarpetas y archivos solamente”. Si se aplica a la carpeta raíz, no tendrá el efecto deseado.
Permisos de recurso compartido: otorga “Change, Read” a Everyone o Authenticated Users y controla el detalle en NTFS.

Por qué antes no se podía renombrar

En NTFS, renombrar requiere el derecho Delete en el objeto o Delete child en la carpeta padre. Si aplicas Deny Delete / Deny Delete subfolders and files al grupo, ese Deny anula cualquier Allow (incluido el que llega vía CREATOR OWNER), y el renombre falla. La configuración propuesta evita Deny y concede “Delete” sólo al propietario del objeto, desbloqueando el renombre de lo propio y bloqueando el de lo ajeno.

Pasos de configuración en la GUI

Propiedades de la carpeta raíz → Seguridad → Avanzadas.
Quita cualquier ACE de Deny existente (especialmente si aplica a “Esta carpeta, subcarpetas y archivos”).
Agrega/ajusta las entradas de la ACL recomendada con los ámbitos “Aplicar a” exactamente como se indican.
Deja la herencia habilitada desde la raíz del share (salvo que tu estructura requiera lo contrario).
En la pestaña Compartir, otorga permisos estándar de Share (p. ej., Everyone/Authenticated Users: Change, Read) y controla el detalle en NTFS.
Tras cambios de permisos o pertenencia a grupos en un servidor de Terminal/RDS, cierra sesión y vuelve a iniciar para refrescar el token de seguridad.

Configuración por PowerShell (recomendado)

El siguiente ejemplo crea la DACL con precisión, concediendo Modify a CREATOR OWNER y para el grupo general concede “Modify sin Delete” (eliminando Delete y DeleteSubdirectoriesAndFiles):

$path = 'D:\Shares\Almacen'
$domain = 'CONTOSO'
$groupUsers = "$domain\Group-RRG-WHSusers"
$admins = "$domain\Administrators"

$acl = Get-Acl -Path $path

Limpia ACEs Deny problemáticos (opcional, filtra por tu necesidad)
$acl.Access | Where-Object { $_.AccessControlType -eq 'Deny' } | ForEach-Object {
    $acl.RemoveAccessRule($_) | Out-Null
}

SYSTEM y Administrators: Full control
$ruleSystem = New-Object System.Security.AccessControl.FileSystemAccessRule('SYSTEM','FullControl','ContainerInherit,ObjectInherit','None','Allow')
$ruleAdmins = New-Object System.Security.AccessControl.FileSystemAccessRule($admins,'FullControl','ContainerInherit,ObjectInherit','None','Allow')

CREATOR OWNER: Modify (solo hereda a subcarpetas/archivos)
$ruleCreatorOwner = New-Object System.Security.AccessControl.FileSystemAccessRule('CREATOR OWNER','Modify','ContainerInherit,ObjectInherit','InheritOnly','Allow')

Derechos "Modify" sin Delete ni DeleteSubdirectoriesAndFiles para el grupo general
$fsr = [System.Security.AccessControl.FileSystemRights]
$inheritFlags = [System.Security.AccessControl.InheritanceFlags]'ContainerInherit, ObjectInherit'
$propagation = [System.Security.AccessControl.PropagationFlags]::None

$modify = [System.Security.AccessControl.FileSystemRights]::Modify -bor [System.Security.AccessControl.FileSystemRights]::Synchronize
$noDeleteMask = -bnot ($fsr::Delete -bor $fsr::DeleteSubdirectoriesAndFiles)
$modifyNoDelete = $modify -band $noDeleteMask

$ruleUsers = New-Object System.Security.AccessControl.FileSystemAccessRule($groupUsers, $modifyNoDelete, $inheritFlags, $propagation, 'Allow')

Aplica reglas (usa SetAccessRule para reemplazo controlado)
$acl.SetAccessRule($ruleSystem)
$acl.SetAccessRule($ruleAdmins)
$acl.AddAccessRule($ruleCreatorOwner)
$acl.SetAccessRule($ruleUsers)

Habilita herencia en la raíz (si procede)
$acl.SetAccessRuleProtection($false, $true) # ($false) = herencia habilitada

Set-Acl -Path $path -AclObject $acl

Consejos de uso:

Ejecuta la consola de PowerShell como Administrador.
Adapta $path y el prefijo de dominio a tu entorno.
Si vas a reconfigurar una jerarquía existente, respalda la ACL con Get-Acl | Export-Clixml antes de cambiar.

¿Y con ICACLS?

icacls es útil para reglas “típicas” (F, M, RX, R, W), pero no es cómodo para “Modify sin Delete”. Por eso, usa PowerShell para esa ACE concreta. Aun así, puedes crear la base con icacls y rematar con PowerShell:

icacls "D:\Shares\Almacen" /inheritance:e
icacls "D:\Shares\Almacen" /grant "SYSTEM:(OI)(CI)(F)"
icacls "D:\Shares\Almacen" /grant "CONTOSO\Administrators:(OI)(CI)(F)"
icacls "D:\Shares\Almacen" /grant "CREATOR OWNER:(OI)(CI)(IO)(M)"
REM Para Group‑RRG‑WHSusers usa el script de PowerShell (Modify sin Delete).

Cómo validar que todo funciona

Antes de liberar el share a producción, valida con un escenario realista:

Crea dos usuarios del grupo (UsuarioA, UsuarioB).
UsuarioA crea una carpeta y un archivo; debe poder editar, renombrar y borrar lo suyo.
UsuarioB sobre el contenido de A: puede abrir/editar (si procede), pero no renombrar ni borrar.
Intentar mover contenido fuera del share:
- UsuarioB (no dueño) ⇒ queda copia en el destino, el origen no se elimina.
- UsuarioA (dueño) ⇒ sí puede mover lo suyo (si eso no es aceptable, ver opciones más abajo).

Impedir mover elementos fuera de la jerarquía

Mover fuera del share es, en esencia, copiar + eliminar en origen. Con la ACL propuesta:

Los no dueños no tienen “Delete” ⇒ no pueden mover hacia fuera (solo logran una copia).
El dueño sí tiene “Delete” sobre lo suyo ⇒ puede mover sus propios elementos.

Si necesitas bloquear totalmente mover hacia fuera (incluso al dueño), eso colisiona con “el dueño puede eliminar lo suyo”. No hay un ajuste NTFS puro que cumpla ambas cosas a la vez. Alternativas complementarias:

Restringe destinos: no concedas Write en otros compartidos a los que acceden estos usuarios.
En RDS/Terminal Server aplica GPO:
- Deshabilita drive redirection y clipboard redirection.
- Restringe/oculta otras unidades (Prevent access to drives from My Computer).
Para escenarios de exfiltración, evalúa Microsoft Purview/Endpoint DLP u otra solución DLP.

Mapa de operaciones y derechos NTFS

Esta tabla ayuda a entender por qué la solución funciona:

Operación	Derechos mínimos típicos	Dónde se evalúa	Con la ACL propuesta
Crear archivo/carpeta	Write, Create files (`WriteData`), Create folders (`CreateDirectories`)	Carpeta destino	Permitido a todos (grupo general).
Editar contenido	Write, AppendData	Archivo	Permitido a todos.
Renombrar archivo/carpeta	Delete en el objeto o Delete child en el padre	Objeto y/o padre	Solo el dueño tiene `Delete` en su objeto; el grupo general no tiene `Delete child` en el padre.
Borrar archivo/carpeta	Delete en el objeto o Delete child en el padre	Objeto y/o padre	Solo el dueño puede borrar lo suyo; los demás, no.
Mover fuera del share	Copy + Delete en origen	Objeto y carpeta origen	El no dueño no puede eliminar en origen ⇒ no puede mover (solo copiar).

Buenas prácticas y matices operativos

Propiedad de los objetos: CREATOR OWNER funciona porque el SID del creador se “inyecta” en el ACE al crear el objeto. Si una multifunción/servicio crea archivos con otra cuenta (p. ej., scanner_svc), esa cuenta será el dueño; planifica si esa cuenta debe poder borrar lo que crea.
Copiar vs mover:
- Mover dentro del mismo volumen conserva DACL y propietario.
- Copiar (o mover a otro volumen) crea un archivo nuevo con herencia de DACL y propietario = usuario que copia.
Supervisores con “papelera”: si hay un grupo que deba poder borrar lo ajeno (p. ej., Group‑RRG‑WHSmanagers), concédele Modify (o Delete subfolders and files) con “Esta carpeta, subcarpetas y archivos”.
Auditoría: activa auditoría de Delete y Delete child fallidos para detectar intentos de borrado no permitidos.
Mantenimiento: documenta la ACL y automatiza su reaplicación periódica (ejemplo de script, más abajo) para revertir cambios accidentales.

Errores comunes que rompen renombres y borrados

Usar Deny Delete o Deny Delete subfolders and files sobre el grupo general.
Aplicar CREATOR OWNER a “Esta carpeta…” en vez de “Subcarpetas y archivos solamente”.
Deshabilitar herencia en subcarpetas sin control, creando islas de permisos inconsistentes.
Confundir permisos de Share con NTFS: el efectivo es la intersección. Un Share muy restrictivo puede bloquear la escritura aunque NTFS la permita.
Olvidar el refresh del token: tras cambios de pertenencia a grupos, el usuario debe cerrar sesión y reingresar (o reiniciar la sesión RDS).
Archivos bloqueados en uso: el renombre/borrado falla si hay handles abiertos (no es un tema de permisos).

Script de mantenimiento para “reaplicar” la ACL

Programa un task nocturno que garantice la consistencia de permisos en la raíz:

# Reaplica la ACL recomendada en la raíz sin tocar DACLs únicas de hijos.
$path = 'D:\Shares\Almacen'
$aclRef = Get-Acl -Path $path
Carga/define aquí el bloque de construcción de ACL (como en la sección anterior)
...

Reaplica en la raíz

Set-Acl -Path \$path -AclObject \$aclRef

Reporte simple: carpetas con herencia deshabilitada

Get-ChildItem -Path \$path -Directory -Recurse -Force |
ForEach-Object {
\$a = Get-Acl \$*.FullName
if (\$a.AreAccessRulesProtected) {
\[PSCustomObject]@{ Ruta = \$*.FullName; Herencia = 'Deshabilitada' }
}
} | Export-Csv -NoTypeInformation -Path 'C:\Temp\Almacen\_HerenciaRota.csv'

Preguntas frecuentes

¿Por qué no dar Modify a todos directamente?
Porque Modify incluye “Delete”. Todos podrían borrar o renombrar lo ajeno. La clave es quitar Delete al grupo general y dárselo solamente al dueño mediante CREATOR OWNER.

¿Por qué CREATOR OWNER con Modify y no Full control?
Para limitar cambios de permisos por parte de los usuarios sobre sus propios archivos. Aunque el propietario tiene capacidades especiales, no exponer “Full control” reduce significativamente el riesgo de que alteren DACLs de forma inadvertida.

¿Se puede impedir mover fuera incluso al dueño?
Con NTFS puro, no sin impedir también que el dueño borre lo suyo. Apóyate en GPO de RDS (bloqueo de redirección), en no conceder Write en otros destinos y, si el riesgo lo exige, en DLP.

¿Cómo trato contenidos heredados con permisos atípicos?
En una migración, considera usar “Reemplazar todas las entradas de permisos de objetos secundarios por entradas de permisos heredables de este objeto” en la raíz solo tras respaldar la ACL, para normalizar. Hazlo fuera de horario y valida con el checklist.

Checklist de validación

Crear dos usuarios del grupo (A y B).
A crea carpeta/archivo → puede editar, renombrar y borrar lo suyo.
B sobre contenido de A → puede abrir/editar (si procede), no puede renombrar ni borrar.
Intento de mover contenido de A o B fuera del share:
- B (no dueño) ⇒ queda copia; el origen no se elimina.
- A (dueño) ⇒ podrá mover lo suyo. Si no es aceptable, aplicar medidas RDS/DLP.
Revisión de herencia en subcarpetas críticas ⇒ debe estar habilitada.
Prueba de auditoría: generar un intento de borrado no autorizado y confirmar eventos.

Resumen ejecutivo

Evita Deny. Da a Group‑RRG‑WHSusers permisos de lectura/escritura sin “Delete”, y concede Modify vía CREATOR OWNER a subcarpetas/archivos. Así todos crean y editan, y solo el dueño puede borrar/renombrar lo suyo. Para bloquear movimientos fuera, apóyate en permisos de destino, GPO de RDS y/o DLP.

Plantilla de documentación de la ACL

Elemento	Valor
Ruta raíz	`D:\Shares\Almacen`
Permisos de Share	Everyone/Authenticated Users: Change, Read (detalle controlado en NTFS)
ACL NTFS	Según tabla de “ACL recomendada”.
Herencia	Habilitada
Grupos clave	`Group‑RRG‑WHSusers`, (opcional) `Group‑RRG‑WHSmanagers`
Auditoría	Delete / Delete Child (Failure)
Notas	Sin ACEs Deny globales. `CREATOR OWNER` = Modify (Subcarpetas y archivos).

Conclusión

Con una sola idea—no negar, sino no conceder—y usando CREATOR OWNER de forma estratégica, puedes construir un Shared drive para almacén donde la colaboración no se vea frenada, los renombres funcionen y los borrados no autorizados desaparezcan. Mantén la herencia, automatiza el mantenimiento de la ACL y complementa con GPO/DLP cuando la política requiera impedir cualquier salida de datos.

Nota final

Evita Deny generales (como Group‑RRG‑Tserver: Deny) porque rompen renombres y la lógica de CREATOR OWNER.
Usa CREATOR OWNER: Modify (subcarpetas y archivos) para que quien crea tenga “Delete” solo sobre lo suyo, sin poder cambiar permisos heredados.
Tras cambios de permisos o de pertenencia a grupos, cierra sesión y vuelve a iniciar en el servidor de Terminal/RDS para refrescar el token de seguridad.