Cómo cambiar permisos NTFS y ACLs en profundidad

Inicio » Seguridad » Cómo cambiar permisos NTFS y ACLs en profundidad

Si trabajas con servidores Windows, escritorios en red o recursos compartidos en la nube, tarde o temprano te tocará pelearte con los permisos NTFS y las ACL. Y ahí es donde empiezan las dudas: herencias que no se entienden, usuarios que no pueden borrar sus propios archivos, roles en Azure que no encajan con lo que ves en las propiedades de Seguridad…

En esta guía vamos a ver, paso a paso, cómo funcionan las listas de control de acceso (ACL), cómo se combinan con Azure RBAC, qué tipos de cuentas y SIDs intervienen, cómo modificar permisos desde la interfaz gráfica, con comandos como ICACLS y TAKEOWN y cómo aprovechar la herencia sin romper nada. La idea es que, al terminar, puedas moverte con soltura entre NTFS, permisos de compartición y controles de acceso en Azure Files.

Conceptos básicos: NTFS, ACL, ACE y orden de evaluación

Todo el mecanismo de permisos que usa Windows sobre archivos y carpetas se apoya en el sistema de archivos NTFS (New Technology File System). NTFS no solo almacena datos, también define quién puede hacer qué sobre cada objeto: leer, escribir, ejecutar, borrar, cambiar permisos, etc.

Cada elemento que quieras proteger (un archivo, una carpeta, una clave de registro, un proceso…) se considera un objeto securizable. Sobre ese objeto Windows asocia un descriptor de seguridad que incluye el propietario, el grupo primario y varias listas de control de acceso.

Descriptor de seguridad, DACL y SACL

El Security Descriptor (SD) es la estructura que agrupa toda la información de seguridad de un objeto: quién es el propietario, cuál es su grupo principal y qué listas de control de acceso se aplican. Dentro del SD destacan dos listas:

• DACL (Discretionary ACL): lista discrecional controlada por el propietario que determina qué identidades tienen acceso permitido o denegado al objeto.
• SACL (System ACL): lista del sistema que define qué acciones deben registrarse en los logs de seguridad (auditoría de accesos correctos o fallidos).

Si un objeto no tiene DACL, Windows interpreta que cualquiera puede acceder (acceso abierto). Si tiene DACL pero está vacía, el acceso se rechaza a todo el mundo.

ACL y ACE: qué se guarda realmente

Una Access Control List (ACL) es simplemente una colección ordenada de entradas de control de acceso. Cada una de esas entradas se denomina ACE (Access Control Entry) y contiene cuatro elementos clave:

• SID (identificador de seguridad) de la cuenta o grupo al que afecta.
• Máscara de permisos que indica qué operaciones se permiten o se deniegan (lectura, escritura, eliminación, etc.).
• Tipo de ACE: permiso concedido, permiso denegado o entrada de auditoría.
• Indicadores de herencia: determinan si la ACE aplica solo al objeto actual, a sus hijos, o a ambos.

El orden de las ACE en una DACL no es aleatorio: Windows las reordena para que primero vayan las denegaciones explícitas, luego los permitidos explícitos, después las denegaciones heredadas y finalmente los permitidos heredados. Esto es crucial para entender por qué un usuario a veces tiene acceso y a veces no.

Herencia de permisos

La herencia permite que una carpeta padre propague sus ACL a subcarpetas y archivos. Al definir una ACE puedes indicar si:

• Solo afecta al objeto actual.
• Solo afecta a hijos (IO – Inherit Only).
• Se aplica tanto al objeto como a su descendencia.

Por diseño, cuando creas un nuevo archivo o carpeta dentro de otra, el nuevo objeto hereda todas las ACL heredables de su padre, tanto las explícitas del padre como las ya heredadas de niveles superiores, salvo que la herencia se haya roto en algún punto.

Lenguaje SDDL

Para representar descriptores de seguridad como texto, Windows usa SDDL (Security Descriptor Definition Language). Herramientas como sc sdshow muestran el descriptor de un servicio en este formato, lo que resulta muy útil para scripts y automatización de cambios de permisos a bajo nivel.

Orden de interpretación de permisos

Cuando un usuario intenta acceder a un objeto, el motor de seguridad evalúa las ACE en este orden lógico:

• Denegaciones explícitas para el usuario o grupos a los que pertenece.
• Permisos explícitos concedidos.
• Denegaciones heredadas.
• Permisos heredados permitidos.

En cuanto encuentra una ACE que resuelve el permiso concreto que se está evaluando, deja de procesar el resto. Por eso una única entrada DENY heredada puede tumbar un acceso que, en apariencia, debería estar permitido por otras ACE.

Tipos de cuentas, grupos especiales y SIDs relevantes

En Windows no todo son usuarios y grupos “normales”. Existen identidades especiales y cuentas de servicio cuyo SID tiene un comportamiento particular en ACLs. Entenderlas ayuda a no romper el sistema cambiando permisos a lo loco.

TrustedInstaller y cuentas de servicio

La cuenta de servicio TrustedInstaller (SID base S-1-5-80) es la encargada de instalar y actualizar componentes del sistema operativo, hotfixes y paquetes MSI. Se ejecuta como el servicio “Instalador de módulos de Windows” y suele figurar como propietaria de muchos archivos críticos en C:\Windows y System32, de modo que ni siquiera los administradores pueden sobrescribirlos sin cambiar antes la propiedad.

Creator Owner, Creator Group y Owner Rights

Los SIDs genéricos CREATOR OWNER y CREATOR GROUP actúan como marcadores: cuando se evalúa la ACL de un objeto, se sustituyen por el SID del propietario o por su grupo principal. Esto permite definir reglas del tipo “el creador de un objeto tendrá control total sobre ese objeto” sin saber de antemano quién será el creador.

Desde Windows Vista y Windows 7 aparece además el SID Owner Rights. Este SID sirve para acotar qué puede hacer el propietario de un objeto, algo que por defecto era muy amplio (el dueño puede siempre modificar las ACL aunque un administrador intente bloquearle). Si añades Owner Rights con, por ejemplo, una denegación de WRITE_DAC, el propietario ya no podrá cambiar la ACL de los objetos que cree en esa ubicación.

Usuarios NT AUTHORITY y SIDs habituales

El espacio NT AUTHORITY engloba identidades internas usadas por el sistema para representar tipos de sesión o cuentas especiales. Algunas de las más importantes son:

• Authenticated Users (S-1-5-11): todos los usuarios que han iniciado sesión con credenciales válidas, típicamente en un dominio.
• ANONYMOUS LOGON (S-1-5-7): acceso anónimo, sin identidad autenticada.
• IUSR (S-1-5-17): cuenta utilizada por IIS para ejecutar aplicaciones web.
• INTERACTIVE (S-1-5-4): sesiones iniciadas localmente en la máquina.
• NETWORK (S-1-5-2): accesos que llegan a recursos a través de la red.
• SERVICE (S-1-5-6): procesos que inician sesión como servicio.
• LOCAL SERVICE (S-1-5-19) y NETWORK SERVICE (S-1-5-20): cuentas predefinidas para servicios con diferentes niveles de privilegio local y en red.
• SYSTEM / Local System (S-1-5-18): el propio sistema operativo, con más privilegios que cualquier administrador.

En cuanto a cuentas locales clásicas, el administrador integrado tiene el SID S-1-5-500, el Invitado S-1-5-501 y los usuarios adicionales se crean a partir de S-1-5-1000 en adelante. Estos SIDs aparecen en las ACL incluso si más tarde cambias el nombre visible de la cuenta.

Permisos NTFS: básicos y avanzados

Cuando abres la pestaña Seguridad de un archivo o carpeta verás una serie de permisos “básicos” (Control total, Modificar, Lectura y ejecución, etc.). Por debajo, cada uno de estos perfiles se compone de un conjunto de permisos avanzados granulares.

Permisos básicos NTFS

Los permisos estándar que verás en la interfaz son:

• Control total: acceso completo, incluida la capacidad de cambiar permisos y tomar propiedad.
• Modificar: lectura, escritura, ejecución y eliminación, pero sin todos los privilegios administrativos.
• Leer y ejecutar: permite ver el contenido y ejecutar programas o scripts.
• Mostrar el contenido de la carpeta (para directorios): permite listar archivos y subcarpetas.
• Leer: acceso de solo lectura al contenido y metadatos.
• Escribir: capacidad de crear o modificar datos sin necesariamente poder borrarlos.

El comportamiento exacto varía si aplicas estos permisos sobre una carpeta o sobre un archivo, por lo que cuando necesitas hilar fino es mejor ir a la pestaña de permisos avanzados.

Permisos avanzados NTFS

Los permisos avanzados se pueden asignar individualmente y definen con gran granularidad qué puede hacer un usuario. Algunos de los más relevantes son:

• Navegar por carpeta / Ejecutar archivo: permite moverse por directorios aunque no se pueda listar su contenido completo, y ejecutar binarios.
• Listar carpeta / Leer datos: ver el contenido de carpetas y abrir archivos para lectura.
• Leer atributos y Leer atributos extendidos: consultar atributos estándar y extendidos de archivos y carpetas.
• Crear archivos / Escribir datos y Crear carpetas / Agregar datos: crear nuevos elementos o añadir información al final de un archivo existente.
• Escribir atributos y Escribir atributos extendidos: modificar metadatos estándar y extendidos.
• Eliminar subcarpetas y archivos y Eliminar: posibilidades de borrar contenido, aunque la ACE de eliminación puede estar en el padre.
• Leer permisos, Cambiar permisos y Tomar propiedad: lectura y administración de las ACL, incluida la capacidad de adueñarse del objeto.
• Sincronizar: usado internamente por procesos que necesitan esperar a operaciones de E/S.

La combinación de estos permisos avanzados es lo que ICACLS representa con abreviaturas como F (full), M (modify), RX (read/execute) o máscaras más detalladas como (D,WDAC) para permitir borrar y modificar el DAC.

Herencia en NTFS: explícitos vs heredados

En un árbol de carpetas amplio, asignar permisos uno a uno sería ingobernable. Por eso NTFS permite que la mayoría de objetos hereden los permisos de su carpeta padre. Esta herencia se controla desde las opciones avanzadas de seguridad.

Cuando una ACE procede del padre, aparece marcada como heredada y, en la interfaz gráfica, sus checkboxes suelen verse en gris. Para cambiarla tienes que:

• Modificar la ACL en la carpeta padre, o
• Romper la herencia en el objeto hijo y convertir esas ACE heredadas en explícitas o eliminarlas.

La interfaz permite:

• Incluir permisos heredables del objeto primario: si lo desmarcas, puedes elegir entre copiar las ACE heredadas como explícitas o borrar todas.
• Reemplazar todos los permisos de objeto secundario con permisos heredables de este objeto: fuerza a que todos los hijos vuelvan a alinearse con la ACL del padre.

Manejar bien estas opciones es clave para evitar situaciones extrañas donde una carpeta intermedia rompe la herencia y provoca que, de repente, los usuarios pierdan acceso a documentos en niveles inferiores.

Conflictos de permisos: pertenencia a grupos y prioridad

Un usuario normalmente pertenece a varios grupos, y cada uno de ellos puede tener permisos diferentes sobre un mismo recurso. En estos casos, NTFS combina todas las ACE relevantes para el usuario y sus grupos, respetando el orden que veíamos antes.

Por ejemplo, si el grupo Empleados solo tiene lectura sobre una carpeta compartida, pero al usuario Pepe se le asigna explícitamente escritura sobre esa misma carpeta, Pepe podrá leer y escribir mientras el resto de empleados solo leerán. El permiso directo sobre la cuenta tiene prioridad sobre el permiso más genérico del grupo, salvo que exista una denegación explícita que bloquee la acción.

Propietarios de objetos y control de ACL

Ser propietario de un archivo o carpeta no otorga automáticamente todos los permisos, pero sí concede un derecho muy potente: la capacidad de modificar las ACL del objeto (WRITE_DAC). Con ese simple permiso, el propietario puede darse a sí mismo control total, aunque previamente no lo tuviera.

Por eso, si quieres evitar que un usuario que deja un departamento siga tocando sus antiguos archivos, basta con quitarlo del grupo que le daba acceso. Pero seguirá siendo propietario de los documentos que creó, y puede reconfigurar las ACL a su favor. La solución es cambiar el propietario de esas carpetas/archivos a otro usuario o grupo (por ejemplo, Administradores o un grupo de gestores de datos) y, si procede, limitar los derechos del SID Owner Rights en la ACL del contenedor padre.

Modificar permisos desde la interfaz gráfica

En muchos escenarios de administración diaria es suficiente usar el Explorador de archivos para ajustar los permisos NTFS:

1. Clic derecho sobre el archivo o carpeta > Propiedades.
2. Pestaña Seguridad > Editar para cambiar permisos básicos.
3. Opciones avanzadas para entrar en detalles: propietario, herencia, permisos avanzados, auditoría y permisos efectivos.

Desde la ficha de Permisos efectivos puedes comprobar qué permisos tiene en realidad un usuario o grupo concreto, teniendo en cuenta todos sus grupos y las ACE heredadas. La pestaña de Auditoría sirve para registrar en el Visor de eventos intentos de acceso correctos o fallidos, siempre que tengas configuradas las directivas de auditoría adecuadas en gpedit.msc.

Habilitar, deshabilitar y elevar una cuenta a Administrador

A menudo, para poder cambiar permisos en todo el sistema necesitas operar con una cuenta del grupo Administradores. En equipos de escritorio puedes:

• Usar “Administrar equipo” (lusrmgr.msc) para habilitar o deshabilitar la cuenta Administrador integrada.
• Ir a Panel de control > Cuentas de usuario y cambiar el tipo de una cuenta estándar a Administrador.

Desde la consola CMD elevada también puedes activar o desactivar la cuenta integrada con:

net user administrador /active:yes
net user administrador /active:no

Si al ejecutar estos comandos ves un Error de sistema 5 – Acceso denegado, suele ser porque la consola no se ha abierto con privilegios elevados, porque la cuenta no tiene permisos suficientes o por problemas de autenticación/netlogon en entornos de dominio.

ICACLS y TAKEOWN: gestión de permisos por línea de comandos

Para cambios masivos o automatizados, la herramienta recomendada es ICACLS, disponible en Windows Server y versiones de escritorio modernas. Combinada con TAKEOWN permite tomar propiedad y ajustar las DACL de forma recursiva.

Comando TAKEOWN: tomar propiedad

El comando takeown sirve para asignar la propiedad de archivos y carpetas a la cuenta que ejecuta el comando (o al grupo Administradores, según parámetros). Un uso típico para asumir control del disco del sistema sería:

takeown /F «%SYSTEMDRIVE%\*» /R /D S

Aquí:

• /F indica la ruta objetivo (en este caso, todo el disco del sistema).
• /R hace el proceso recursivo en subdirectorios.
• /D S responde automáticamente “Sí” a las preguntas de confirmación que aparecen en determinadas carpetas.

Comando ICACLS: modificar DACL y herencia

ICACLS permite listar, guardar, restaurar y modificar ACLs. Algunos usos frecuentes:

• Guardar ACLs:
  icacls c:\test\* /save c:\acl-backup\ACL_backup.txt /T
• Restaurar ACLs:
  icacls c:\test\ /restore c:\acl-backup\ACL_backup.txt
• Quitar herencia y aplicar nuevas ACL:
  icacls "c:\test" /inheritance:r /grant:r DOM\Administradores:(OI)(CI)(F)
• Conceder permisos granulares:
  icacls file /grant DOM\Pepe:(D,WDAC)

Los modificadores más útiles de ICACLS incluyen:

• /grant[:r] SID:perm: concede permisos. Con :r reemplaza permisos explícitos anteriores para ese SID; sin :r los añade.
• /deny SID:perm: crea entradas de denegación explícita y elimina esos permisos de ACE de permitido.
• /remove[:g|:d] SID: borra ACE de conceder (g), de denegar (d) o ambas para ese SID.
• /inheritance:e|d|r: habilita herencia (e), la deshabilita copiando ACE heredadas (d) o elimina todas las ACE heredadas (r).
• /reset: restablece DACL al estado heredado predeterminado.

Las máscaras de permisos pueden ser simples (F, M, RX, R, W, D, N) o detalladas (DE, RC, WDAC, WO, GR, GE, GA, RD, WD, AD, REA, WEA, X, DC, RA, WA). Los indicadores de herencia más habituales son:

• (OI) – Object Inherit: se aplica a archivos dentro de la carpeta.
• (CI) – Container Inherit: se aplica a subcarpetas.
• (IO) – Inherit Only: la ACE solo se aplica a hijos, no al objeto actual.
• (NP) – No Propagate: la herencia no se aplica recursivamente más allá del primer nivel.

Un patrón muy típico para configurar completamente una carpeta compartida sería:

icacls «C:\test» /inheritance:r /grant:r DOM\Pepe:(OI)(CI)(M) /grant:r DOM\Administradores:(OI)(CI)(F) /T

Con esto quitas la herencia, das a Pepe permisos de Modificar y a Administradores Control total, propagando todo a subcarpetas y archivos.

Permisos NTFS frente a permisos de compartición

En un entorno Windows clásico no solo entran en juego los permisos NTFS; también existen los permisos de compartición, que regulan lo que se puede hacer al acceder a una carpeta por red (SMB). A estos se suman, en entornos modernos, los roles de Azure RBAC cuando hablamos de Azure Files.

Permisos de compartición

Los permisos de compartición se aplican únicamente al acceso remoto a una carpeta compartida. Son más simples que NTFS y no permiten granularidad por archivo dentro de la compartición. Tienen tres niveles:

• Read: ver nombres, leer datos y ejecutar.
• Change: todo lo anterior más escribir, crear y borrar elementos.
• Full Control: incluye la posibilidad de cambiar permisos (a nivel NTFS) sobre los objetos en la compartición.

Lo habitual es conceder permisos de compartición relativamente amplios (por ejemplo, Cambiar para Usuarios del dominio, Control total para Administradores) y utilizar NTFS para afinar quién ve y modifica qué dentro de cada carpeta.

Cómo se combinan permisos NTFS y de compartición

Cuando un usuario accede a un recurso compartido, Windows combina el permiso de compartición con el permiso NTFS efectivo y se aplica siempre la opción más restrictiva. Algunos ejemplos:

• Compartición: Control total, NTFS: Lectura → el usuario solo puede leer.
• Compartición: Read, NTFS: Modificar → el usuario se queda en lectura, porque la compartición le frena.

Esto mismo se aplica cuando añades a la ecuación Azure Files con RBAC: los roles de SMB a nivel de recurso compartido actúan como una puerta de granulado grueso y las ACL NTFS dentro del share aportan el detalle fino.