Usuarios, grupos y permisos NTFS

Nunca se dan permisos a personas

Es la regla que ordena todo lo demás, y la que casi nadie sigue al principio: los permisos se dan a grupos, y las personas se meten en grupos.

La razón se ve el día que entra alguien nuevo. Si los permisos están en grupos, se le añade a «Contabilidad» y ya tiene lo que le toca. Si están puestos persona a persona, hay que recorrer las carpetas adivinando dónde tenía acceso quien se fue, y siempre queda alguna suelta.

Usuarios y grupos locales

# Crear un usuario local
New-LocalUser -Name "jgomez" -FullName "Julia Gomez" `
  -Description "Contabilidad" -Password (Read-Host -AsSecureString)

# Crear el grupo y meter a la persona dentro
New-LocalGroup -Name "Contabilidad" -Description "Acceso a la carpeta contable"
Add-LocalGroupMember -Group "Contabilidad" -Member "jgomez"

# Ver quien esta en un grupo
Get-LocalGroupMember -Group "Contabilidad"

Read-Host -AsSecureString pide la contraseña sin mostrarla y sin dejarla escrita en el comando. Es lo correcto: una contraseña escrita en la línea de comandos queda en el historial y en los registros.

La trampa: hay dos capas de permisos

Aquí está lo que hace que Windows desconcierte a quien viene de otro sistema. Una carpeta compartida en red tiene dos juegos de permisos distintos, y los dos se aplican a la vez.

Las dos capas, y cómo se combinan

Permisos del recurso compartido

Solo actúan cuando se llega por la red. Son gruesos: leer, cambiar, control total.

Si te sientas delante del servidor, esta capa no existe.

Permisos NTFS

Los del sistema de archivos. Actúan siempre, por red y en local, y son finos: se puede permitir escribir pero no borrar.

Es la capa que de verdad protege.

Manda el MÁS RESTRICTIVO

Al entrar por la red se aplican los dos, y gana el más cerrado.

De ahí el clásico: «le di control total y sigue sin poder escribir». Sí, en una capa; la otra lo estaba frenando.

La práctica que evita el problema de raíz, y es la que recomienda Microsoft: en el recurso compartido se da control total al grupo «Todos», y todo el control real se hace con permisos NTFS.

No es «abrir todo»: es desactivar una de las dos capas para que solo mande la que es fina y funciona igual en red y en local. Con una sola capa que revisar, los permisos dejan de ser un misterio.

Compartir una carpeta, bien hecho

1. Crear la carpeta
New-Item -Path "D:\Datos\Contabilidad" -ItemType Directory

En una unidad de datos, no en la del sistema: si se llena, no debe tumbar el servidor.
2. Compartirla con control total a Todos
New-SmbShare -Name "Contabilidad" -Path "D:\Datos\Contabilidad" -FullAccess "Todos"

Aquí es donde se «desactiva» la capa de recurso compartido, a propósito. Todavía nadie puede entrar: falta NTFS.
3. Dar el permiso NTFS al GRUPO
Sobre la carpeta, permiso de Modificar al grupo «Contabilidad».

Es el permiso normal de trabajo: leer, escribir y borrar sus archivos, sin poder cambiar los permisos de la carpeta.
4. Quitar lo que sobra
Por defecto suele haber un permiso amplio para «Usuarios». Se revisa y se quita lo que no corresponda.

Para eso hay que romper la herencia: es el paso siguiente.
5. Comprobar con el rol más bajo
Entra desde otro equipo con un usuario que no esté en el grupo y confirma que no ve nada.

Un permiso que no se ha probado con quien no debería entrar no está comprobado.

Ver y ajustar permisos NTFS

# Ver quien tiene que sobre una carpeta
Get-Acl "D:\Datos\Contabilidad" | Format-List

# Anadir permiso de modificacion al grupo
$acl = Get-Acl "D:\Datos\Contabilidad"
$regla = New-Object System.Security.AccessControl.FileSystemAccessRule(
    "Contabilidad", "Modify", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.SetAccessRule($regla)
Set-Acl "D:\Datos\Contabilidad" $acl

Ese ContainerInherit,ObjectInherit es lo que hace que el permiso baje a las subcarpetas y a los archivos. Sin él, el permiso se queda solo en la carpeta de arriba y la gente entra pero no ve nada dentro.

La herencia, y por qué se rompe

Los permisos bajan de una carpeta a lo que contiene. Es lo que permite gestionar una estructura entera desde arriba, y funciona muy bien hasta que alguien la rompe sin darse cuenta.

Al quitar un permiso heredado en una subcarpeta, Windows pregunta si quieres convertir los heredados en permisos propios. Si aceptas, esa carpeta queda desconectada del padre: a partir de ahí, los cambios de arriba ya no llegan.

Ese es el origen de la mitad de los «permisos raros» de una empresa. Se añade un grupo nuevo en la carpeta principal, funciona en todas partes menos en tres subcarpetas, y nadie entiende por qué. La herencia estaba rota desde hacía dos años.

Get-Acl lo delata: los permisos heredados aparecen marcados como tales, y los propios no. Antes de pelear con un permiso, comprueba si la carpeta sigue heredando.

Qué permiso dar

Windows ofrece muchos niveles, pero en la práctica se usan tres. La regla es siempre la misma: el mínimo que permita trabajar.

Los tres permisos que se usan

Piensa qué permite cada uno antes de voltear.

Los casos que vas a ver

«Le di permisos y sigue sin poder entrar»

Tres causas, en este orden: la otra capa de permisos lo está frenando, la herencia está rota en esa subcarpeta, o hay un Denegar heredado de otro grupo.

Y una cuarta muy frecuente: los grupos se leen al iniciar sesión. Si acabas de meter a alguien en un grupo, tiene que cerrar sesión y volver a entrar.

Puede entrar en la carpeta pero no ve los archivos

Falta la herencia hacia los objetos de dentro: el permiso se aplicó solo a la carpeta.

Se corrige aplicando el permiso a «esta carpeta, subcarpetas y archivos».

Quiero que cada uno vea solo lo suyo

Existe la enumeración basada en el acceso: quien no tiene permiso sobre una carpeta ni siquiera la ve en la lista.

Se activa por recurso compartido y evita muchas preguntas incómodas sobre carpetas que no deberían estar a la vista.

Nadie puede tocar una carpeta, ni el administrador

Suele pasar cuando se quitan todos los permisos por error. El administrador puede tomar la propiedad de la carpeta y volver a asignarlos.

Se hace desde las opciones avanzadas de seguridad, y queda registrado.

Compruébalo tú mismo

Diste control total en el recurso compartido y el usuario sigue sin poder escribir. ¿Qué pasa?

Añades un grupo en la carpeta principal y funciona en todas las subcarpetas menos en tres. ¿Qué revisas?

Metiste a un usuario en un grupo con permisos y dice que sigue sin acceso. ¿Qué es lo primero?

Lo que sigue

Ya sabes repartir el acceso. La siguiente lección es dar de alta lo que el servidor tiene que hacer: instalar roles y características con PowerShell, y la regla que ya viste en el lado Linux -no instalar nada que no se vaya a usar-.