Windows Server 2025 / Cómo diseñar permisos de recursos compartidos de archivos departamentales

Para administrar los permisos de archivos por departamento, incorpore los usuarios a grupos de negocio y estos a grupos de permisos del recurso; conceda el acceso a las carpetas mediante estos últimos. En este laboratorio separaremos Sales (Ventas) y Support (Soporte), y comprobaremos tanto los cambios permitidos en el propio departamento como el acceso denegado al otro.

Separe cuentas, grupos de negocio y grupos de recursos

En un solo dominio, AGDLP significa Accounts → Global groups → Domain Local groups → Permissions: cuentas, grupos globales, grupos locales de dominio y permisos. Es un patrón de partida, no la única arquitectura posible. Los ámbitos de los grupos de Active Directory permiten anidar los grupos globales en los locales de dominio. Estos últimos pertenecen al directorio; no son grupos locales de la máquina FS1.

Use FS1 unido al dominio y su volumen con el sistema de archivos NTFS (New Technology File System). La práctica de permisos SMB y NTFS, donde SMB significa Server Message Block, explica las dos capas que configurará aquí. Antes de crear D:\Shares\Sales y D:\Shares\Support, compruebe que no existan ni se usen sus nombres de recurso. Cree únicamente carpetas vacías nuevas; no sustituya configuraciones de producción. Los nombres de la tabla son identificadores literales: mantenga Sales, Support y los nombres de grupo sin traducir.

Cree los grupos y las cuentas de prueba normales

1. En Usuarios y equipos de Active Directory, abra Lab → LabGroups. Use Nuevo → Grupo para crear los cuatro grupos de la tabla: los GG con ámbito Global y los DL con ámbito Local de dominio. En los cuatro casos seleccione Seguridad, no Distribución, y conserve los nombres exactos.
2. En Lab → LabUsers cree sales.user1 y support.user1 con contraseñas iniciales distintas que cumplan la directiva aplicable. Si exige el cambio en el primer inicio de sesión, complételo al iniciar sesión en CLIENT1 antes de probar los recursos.
3. En las propiedades de cada grupo global, abra Miembros → Agregar: incluya sales.user1 solo en GG_Sales y support.user1 solo en GG_Support para las pertenencias de negocio de esta práctica.
4. En Miembros de DL_FS_Sales_Modify agregue GG_Sales; en Miembros de DL_FS_Support_Modify agregue GG_Support. Así, el grupo local de dominio contiene al grupo global, no al revés.
5. Confirme que ninguna cuenta de prueba sea administradora ni pertenezca directa o indirectamente a los grupos del otro departamento. No elimine grupos predeterminados de las cuentas sin comprender su función.

Consulte los parámetros de creación y ámbito de New-ADGroup. Para el procedimiento gráfico, utilice Usuarios y equipos de Active Directory en DC1 o una estación con las herramientas de administración remota y permisos sobre las unidades organizativas de laboratorio. Ejecute estas consultas de pertenencia en PowerShell con el módulo ActiveDirectory disponible; normalmente un cambio de departamento se administra en los grupos de negocio, no agregando cada usuario a todas las listas de control de acceso (ACL) de las carpetas.

Get-ADGroupMember 'GG_Sales'
Get-ADGroupMember 'DL_FS_Sales_Modify'
Get-ADGroupMember 'GG_Support'
Get-ADGroupMember 'DL_FS_Support_Modify'

Sin -Recursive, Get-ADGroupMember muestra miembros directos: GG_Sales debe contener sales.user1 y DL_FS_Sales_Modify debe contener GG_Sales; el mismo patrón se aplica a Support. Encontrar el grupo global dentro del grupo de recursos es el resultado esperado, no significa que falten los usuarios. Revise también las pertenencias indirectas antes de probar la separación.

Conceda Modificar en NTFS a los grupos de recursos

1. En FS1 abra las propiedades de D:\Shares\Sales → Seguridad → Opciones avanzadas. Examine y registre las entradas y su ámbito antes de cambiar nada.
2. Solo en esta carpeta nueva y vacía, deshabilite la herencia y convierta las entradas heredadas en explícitas. Conserve el Control total necesario de SYSTEM y administradores; convertir las entradas no elimina las concesiones amplias.
3. Revise Usuarios, Usuarios autenticados, Todos y otros grupos generales. Retire de esta carpeta las concesiones innecesarias, incluso las de lectura que permitirían entrar al departamento contrario.
4. Conceda a AD\DL_FS_Sales_Modify Modificar con ámbito Esta carpeta, subcarpetas y archivos. No agregue sales.user1 directamente a la ACL.
5. Repita en D:\Shares\Support con AD\DL_FS_Support_Modify. Verifique que cada carpeta incluya solo el grupo de recursos que le corresponde, además de los derechos administrativos necesarios.

Modificar permite los cambios normales de contenido; no equivale a Control total ni debe usarse como sinónimo de administrar todos los permisos. Las concesiones Permitir de varios grupos pueden acumularse. Por eso, primero establezca las concesiones necesarias y elimine el acceso amplio innecesario de estas carpetas nuevas; no empiece añadiendo una denegación al otro departamento.

Configure los recursos compartidos y el nombre del servidor

1. En las propiedades de D:\Shares\Sales abra Compartir → Uso compartido avanzado y comparta la carpeta con el nombre literal Sales.
2. En Permisos permita Cambiar a AD\DL_FS_Sales_Modify y conserve los derechos administrativos necesarios. Quite las concesiones amplias innecesarias que dejarían acceder a otros usuarios; no otorgue Control total a todo el dominio.
3. Comparta D:\Shares\Support como Support y use AD\DL_FS_Support_Modify con Cambiar. Revise los valores predeterminados y guarde ambas configuraciones por separado.
4. En PowerShell de FS1 consulte rutas y permisos con los comandos siguientes. Name y Path deben coincidir con la tabla, y cada grupo de recursos debe tener Allow y Change solo en su recurso, además de las entradas administrativas previstas.

Get-SmbShare -Name Sales,Support | Select-Object Name,Path
Get-SmbShareAccess -Name Sales
Get-SmbShareAccess -Name Support

Utilice \\fs1.ad.example.test\Sales y \\fs1.ad.example.test\Support. Mantenga el mismo nombre de servidor en las pruebas, sin mezclar direcciones IP ni alias improvisados. La enumeración basada en el acceso puede ocultar elementos, pero ocultar un nombre no demuestra que se haya denegado el acceso: pruebe también la ruta directa del recurso contrario.

Pruebe ambas identidades y el acceso entre departamentos

En CLIENT1, cierre la sesión e inicie una nueva como sales.user1; compruebe whoami, whoami /groups y que no se reutilice una conexión SMB de administrador. En Sales cree un archivo de prueba, edítelo, vuelva a abrirlo y elimínelo; intente abrir Support por su ruta directa y confirme el rechazo. Repita intercambiando los departamentos con support.user1. Guarde los resultados de ambas identidades. Si no coinciden con la tabla, examine por separado los permisos del recurso, las ACL NTFS, la herencia, las pertenencias y las credenciales reales; no conceda Control total para ocultar el fallo.

Para simular un traslado, registre las pertenencias iniciales de sales.user1, retírelo solo de GG_Sales y agréguelo a GG_Support, manteniendo intactas las ACL y las demás cuentas. Cierre su sesión y vuelva a iniciarla: debe poder trabajar en Support y perder el acceso a Sales bajo las condiciones de esta práctica. Después restaure exactamente sus pertenencias originales, renueve la sesión y repita la comprobación inicial. Antes de cualquier limpieza, localice las referencias de permisos; borrar primero los grupos puede dejar identificadores de seguridad (SID) sin resolver en las ACL. Conserve las carpetas, recursos y registros para la práctica posterior de DFS, el sistema de archivos distribuido.