Ver el código de «Estrategias de grupos en Active Directory: AGP y AGDLP»


== Estrategias de Arquitectura de Grupos en Active Directory: Un Análisis Exhaustivo de los Modelos AGP y AGDLP para la Gestión de Identidades y Seguridad Corporativa ==

== 1. Introducción a la Gestión de Identidades y Accesos en Infraestructuras Microsoft ==
La administración de identidades y accesos (IAM) dentro de los ecosistemas de Active Directory Domain Services (AD DS) representa la piedra angular de la seguridad y la eficiencia operativa en las infraestructuras de TI modernas. A medida que las organizaciones transitan desde modelos de administración hacia marcos de trabajo estructurados y auditables, la elección de la estrategia de anidamiento de grupos se convierte en una decisión arquitectónica crítica.

Este informe técnico profundiza en las metodologías predominantes para la asignación de permisos: el modelo '''AGP''' (Cuentas, Global, Permisos) y el modelo '''AGDLP''' (Cuentas, Global, Dominio Local, Permisos). El objetivo es proporcionar una justificación técnica y operativa detallada para la adopción de estas estrategias en función de la topología de la red (dominio único frente a bosque multidominio), así como analizar las implicaciones de seguridad inherentes, incluyendo el principio de mínimo privilegio y los riesgos asociados al uso indiscriminado de Grupos Universales.

La gestión de acceso en Active Directory no es meramente una tarea administrativa rutinaria; es la implementación lógica de las políticas de seguridad de la organización. Un diseño deficiente de grupos conduce inevitablemente a la "deriva de permisos", vulnerabilidades de seguridad por escalada de privilegios y cuellos de botella en el rendimiento de la red debido a la replicación ineficiente de datos.1 Por el contrario, la implementación rigurosa de modelos basados en roles (RBAC) mediante estrategias de anidamiento adecuadas garantiza la escalabilidad, facilita la auditoría y asegura que los usuarios mantengan únicamente el acceso necesario para desempeñar sus funciones laborales.3

== 2. Fundamentos Técnicos de los Objetos de Grupo en Active Directory ==
Para comprender la idoneidad de las estrategias AGP y AGDLP, es imperativo disecar primero la naturaleza técnica de los grupos en Active Directory. Los grupos son objetos de directorio que actúan como contenedores de ''security principals'' (usuarios, equipos y otros grupos), permitiendo la gestión colectiva de permisos y derechos.

=== 2.1 Tipología de Grupos: Seguridad vs. Distribución ===
Active Directory distingue fundamentalmente entre dos tipos de grupos, cada uno con un propósito distinto en la infraestructura:

* '''Grupos de Seguridad:''' Estos objetos poseen un Identificador de Seguridad (SID) único y se utilizan para conceder acceso a recursos (carpetas compartidas, impresoras) y asignar derechos de usuario (como el derecho a iniciar sesión localmente). Son los bloques de construcción de las estrategias AGP y AGDLP. Su función crítica es poblar el token de acceso Kerberos del usuario durante el proceso de autenticación, determinando así sus capacidades efectivas en la red.5

* '''Grupos de Distribución:''' Diseñados exclusivamente para aplicaciones de correo electrónico como Microsoft Exchange, estos grupos no tienen capacidad de seguridad intrínseca. No pueden ser listados en las Listas de Control de Acceso Discrecional (DACL) de los recursos y no otorgan permisos. Aunque son vitales para la comunicación, quedan fuera del alcance de las estrategias de control de acceso de seguridad.5

=== 2.2 Ámbitos de Grupo y Mecanismos de Replicación ===
La distinción más crítica para la arquitectura de permisos reside en el '''ámbito''' (scope) del grupo. El ámbito define dos parámetros esenciales: la visibilidad del grupo a través del bosque y la elegibilidad de sus miembros. La interacción entre estos ámbitos dicta la lógica detrás de AGP y AGDLP.

La siguiente tabla desglosa las características técnicas de cada ámbito, fundamentales para entender las recomendaciones posteriores:
{| class="wikitable"
!Característica técnica
!Grupo Global (G)
!Grupo de Dominio Local (DL)
!Grupo Universal (U)
|-
|Membresía permitida
|Cuentas y Grupos Globales del mismo dominio.
|Cuentas, Grupos Globales y Universales de cualquier dominio del bosque o de confianza.
|Cuentas, Grupos Globales y Universales de cualquier dominio del bosque.
|-
|Visibilidad y uso
|Visible en todo el bosque. Puede recibir permisos en cualquier dominio de confianza.
|Visible solo en su propio dominio. Solo puede recibir permisos sobre recursos en su mismo dominio.
|Visible en todo el bosque. Puede recibir permisos en cualquier sitio.
|-
|Replicación
|Membresía replicada solo dentro del dominio. El objeto grupo se lista en el GC, pero no sus miembros.
|Membresía replicada solo dentro del dominio. No se replica en el GC.
|Membresía replicada en el Catálogo Global (GC) para todo el bosque.
|-
|Función estratégica
|Definición de '''ROLES''' (quiénes son). Agrupa usuarios por función de negocio.
|Definición de '''REGLAS''' (qué pueden hacer). Agrupa permisos sobre recursos específicos.
|Agregación de roles a nivel de bosque (uso restringido).
|}
Esta matriz revela por qué la combinación de estos grupos es necesaria. Los Grupos Globales son excelentes para agrupar usuarios porque son "ligeros" en replicación, pero están limitados a contener usuarios locales. Los Grupos de Dominio Local son excelentes para asignar permisos porque pueden aceptar miembros de cualquier lugar, actuando como receptores universales, pero su visibilidad está restringida localmente.5

== 3. Estrategia AGP: El Estándar de Oro para Entornos de Dominio Único ==
En arquitecturas donde la organización reside dentro de un límite lógico único, es decir, un solo dominio de Active Directory, la estrategia '''AGP''' (Cuentas → Global → Permisos) se establece como la recomendación preeminente. Este modelo aboga por la simplicidad y la eficiencia administrativa, eliminando capas de abstracción innecesarias que no aportan valor en un entorno monolítico.1

=== 3.1 Mecánica de Implementación AGP ===
El flujo operativo de AGP es lineal y directo:

# '''A (Accounts - Cuentas):''' Las identidades de usuario se crean en el dominio.

# '''G (Global Groups - Grupos Globales):''' Las cuentas se agregan a Grupos Globales que representan estructuras organizativas o roles laborales (por ejemplo, ''GG_Contabilidad'' o ''GG_Desarrolladores'').

# '''P (Permissions - Permisos):''' Estos Grupos Globales se añaden directamente a las Listas de Control de Acceso (ACL) de los recursos, asignándoles los permisos necesarios (Lectura, Modificación, Control Total).1

=== 3.2 Justificación Técnica y Beneficios en Dominio Único ===
La superioridad de AGP en escenarios de dominio único se sustenta en varios pilares técnicos que optimizan tanto el rendimiento del sistema como la carga cognitiva de los administradores.

==== 3.2.1 Simplicidad y Reducción de Gastos Administrativos ====
En un dominio único, la frontera de seguridad es el dominio mismo. No existe la necesidad de cruzar límites de confianza para autenticar usuarios externos. Por lo tanto, la capacidad del Grupo Global de ser visible y utilizable dentro de su propio dominio es suficiente para cubrir todas las necesidades de asignación de permisos. Introducir un grupo intermedio de Dominio Local (como en AGDLP) en este escenario añadiría una tarea administrativa redundante, crear y mantener dos grupos para lograr el mismo resultado, sin ofrecer ninguna ventaja funcional de conectividad.

==== 3.2.2 Optimización del Token Kerberos y Prevención de "Token Bloat" ====
Cuando un usuario inicia sesión, el Centro de Distribución de Claves (KDC) genera un Ticket Granting Ticket (TGT) que contiene el atributo '''TokenGroups''', una lista de los SIDs de todos los grupos a los que pertenece el usuario, incluyendo anidamientos. Existe un límite finito en el tamaño de este token ('''MaxTokenSize'''). Si el token crece demasiado, el usuario no podrá autenticarse o acceder a aplicaciones web que dependen de encabezados HTTP (que transportan el token).

Al utilizar AGP, se minimiza la profundidad del anidamiento. El usuario pertenece al Grupo Global y este tiene el permiso. Si se forzara el uso de AGDLP en un dominio único, se duplicaría efectivamente el número de grupos en el token del usuario (el Global más el Dominio Local) para cada recurso accedido, acelerando innecesariamente el consumo del espacio del token y aumentando el riesgo de fallos de autenticación por "Token Bloat".

==== 3.2.3 Eficiencia en la Autenticación ====
En un dominio único, todos los Controladores de Dominio (DC) tienen una copia completa de la base de datos del dominio. Cuando un usuario se autentica, el DC no necesita consultar un servidor de Catálogo Global externo para resolver la membresía de grupos globales, ya que esa información es local. Esto contrasta con los Grupos Universales, que siempre requieren una consulta al GC (o el uso de caché de membresía universal) para validar el inicio de sesión, añadiendo latencia potencial y puntos de fallo.

==== 3.2.4 Facilidad de Auditoría ====
La auditoría de seguridad se beneficia de la transparencia. En un modelo AGP, un auditor que examina la ACL de una carpeta confidencial verá directamente ''GG_RecursosHumanos''. La relación entre el permiso y el rol es explícita e inmediata. No se requiere navegar a través de capas intermedias de grupos de recursos para determinar quién tiene acceso, lo que agiliza las revisiones de acceso y el cumplimiento normativo.

== 4. Estrategia AGDLP: La Arquitectura Esencial para Entornos Multi-Dominio ==
A medida que las organizaciones escalan y su infraestructura se fragmenta en múltiples dominios dentro de un bosque (por ejemplo, por razones geográficas como ''us.empresa.com'', ''eu.empresa.com'' o legales), la estrategia AGP se vuelve técnicamente inviable debido a las restricciones de alcance de los grupos. En este contexto, '''AGDLP''' (Cuentas → Global → Dominio Local → Permisos) emerge no como una opción, sino como un requisito estructural para mantener la gobernanza.

=== 4.1 Mecánica de Implementación AGDLP ===
Este modelo introduce una capa de abstracción crítica: el "Grupo de Recurso" o '''Dominio Local'''.

# '''A (Cuentas):''' Los usuarios residen en sus respectivos dominios de origen.

# '''G (Global):''' Se crean grupos de roles en cada dominio de origen (por ejemplo, ''US\GG_Ventas'', ''EU\GG_Ventas''). Estos grupos contienen solo usuarios de su propio dominio.

# '''DL (Dominio Local):''' En el dominio donde reside el recurso (por ejemplo, el servidor de archivos central en el dominio raíz ''CORP''), se crean grupos de Dominio Local que representan el nivel de acceso específico (por ejemplo, ''CORP\DL_Finanzas_Lectura'', ''CORP\DL_Finanzas_Modificar'').

# '''Anidamiento (el cruce de fronteras):''' Los Grupos Globales de los distintos dominios (''US\GG_Ventas'', ''EU\GG_Ventas'') se añaden como miembros del Grupo de Dominio Local (''CORP\DL_Finanzas_Lectura'').

# '''P (Permisos):''' Los permisos NTFS o de recurso compartido se asignan exclusivamente al Grupo de Dominio Local.1

=== 4.2 Justificación Técnica y Beneficios en Entornos Distribuidos ===

==== 4.2.1 Superación de las Barreras de Confianza ====
La limitación fundamental del Grupo Global es que no puede contener miembros de otros dominios. Si intentáramos usar AGP en un entorno multi-dominio para dar acceso a usuarios de Europa en un servidor de América, tendríamos que añadir las cuentas de usuario individuales de Europa directamente en la ACL del servidor americano (mala práctica) o crear un grupo global en Europa y tratar de anidarlo, lo cual no siempre es directo dependiendo de la dirección de la confianza.

El Grupo de Dominio Local resuelve esto actuando como un conector universal. Puede aceptar miembros (Grupos Globales) de cualquier dominio confiado. Esto permite consolidar el acceso: un solo grupo DL en el recurso gestiona la entrada de usuarios de docenas de dominios diferentes.

==== 4.2.2 Desacoplamiento de Roles y Recursos (Role-Based Access Control) ====
AGDLP implementa una separación de responsabilidades perfecta, vital en grandes empresas:

* '''Administradores de Cuentas (Dominios Regionales):''' Gestionan los Grupos Globales. Su responsabilidad es asegurar que "Juan pertenece a Ventas". No necesitan saber qué carpetas existen en los servidores centrales.

* '''Administradores de Recursos (Dominio de Infraestructura):''' Gestionan los Grupos Dominio Local. Su responsabilidad es definir "quién puede leer la carpeta Finanzas". Deciden qué roles (Grupos Globales) entran, pero no gestionan a los usuarios individuales.

Este desacoplamiento permite que los cambios organizativos (un usuario cambia de departamento) se gestionen localmente sin afectar la configuración de seguridad de los servidores, y viceversa.

==== 4.2.3 Escalabilidad y Flexibilidad ante Fusiones ====
En escenarios de fusiones y adquisiciones (M&A), AGDLP brilla por su flexibilidad. Si la empresa adquiere una nueva compañía con su propio dominio, simplemente se establece una confianza y se añaden los Grupos Globales del nuevo dominio a los Grupos de Dominio Local existentes. El acceso se aprovisiona instantáneamente para miles de usuarios nuevos sin tener que reconfigurar las ACLs de millones de archivos.

==== 4.2.4 Estabilidad de las Listas de Control de Acceso (ACL) ====
Modificar una ACL en un servidor de archivos es una operación costosa y arriesgada. En sistemas de archivos grandes, propagar un cambio de permisos puede tomar horas y consumir recursos del servidor. Con AGDLP, las ACLs son estáticas; contienen solo los Grupos de Dominio Local. Para dar o quitar acceso, se modifica la membresía del grupo en Active Directory, una operación de milisegundos que no toca el sistema de archivos. Esto reduce drásticamente el riesgo de corrupción de ACLs o errores operativos.

== 5. Análisis de Seguridad: Implementando el Mínimo Privilegio ==
La seguridad no es un producto, sino un proceso, y las estrategias AGP y AGDLP son los mecanismos procesales que habilitan una postura de seguridad robusta.

=== 5.1 Implementación del Principio de Mínimo Privilegio ===
El principio de mínimo privilegio dicta que un usuario debe tener solo el nivel de acceso necesario para realizar su trabajo, y nada más. AGDLP facilita esto mediante la granularidad de los Grupos de Dominio Local.

En lugar de dar "Control Total" a un grupo genérico, se crean grupos DL específicos para cada nivel de permiso: ''DL_Recurso_Lectura'', ''DL_Recurso_Modificar'', ''DL_Recurso_Full''. Los grupos de roles (Globales) se anidan solo en el DL que corresponde a su necesidad exacta. Si un rol solo necesita leer informes, se coloca en el grupo de Lectura. Esto evita la "sobre-concesión" de permisos habitual cuando se usan asignaciones directas o grupos mal definidos.1

=== 5.2 Prevención de Escalada de Privilegios y Movimiento Lateral ===
El uso de grupos intermedios (DL) actúa como un cortafuegos lógico. Nunca se deben asignar permisos a usuarios individuales ("Juan Pérez"). Si una cuenta de usuario es comprometida y tiene permisos directos, el atacante hereda esos accesos de manera difícil de auditar. Si el acceso es vía grupo, la remediación es centralizada: al remover al usuario del Grupo Global, se revocan instantáneamente todos los accesos derivados en todo el bosque.2

Además, el modelo de administración por niveles ('''Tiered Administration''') recomendado por Microsoft se apoya en esta estructura para asegurar que los administradores de dominio (Tier 0) no inicien sesión en estaciones de trabajo inseguras, utilizando grupos restringidos y políticas de grupo aplicadas a estos objetos de seguridad.2

=== 5.3 Auditoría y Cumplimiento Normativo (SOX, GDPR, ISO 27001) ===
Las normativas exigen saber "quién tiene acceso a qué". AGDLP ofrece una trazabilidad superior:

* '''Auditoría de Recursos:''' Al auditar el servidor, vemos el grupo ''DL_Finanzas''. Sabemos qué permite ese grupo.

* '''Auditoría de Identidad:''' Al auditar el grupo DL, vemos los grupos ''GG_Ventas''. Sabemos quiénes son funcionalmente.

Esta estructura jerárquica permite responder a auditorías sin necesidad de investigar usuario por usuario, proporcionando una visión clara de la relación Rol-Permiso.3

== 6. La Problemática de los Grupos Universales: Por Qué No Son la Opción Predeterminada ==
Existe una idea errónea común de que los Grupos Universales (UG), al ser visibles en todo el bosque y aceptar miembros de cualquier lugar, son la "solución mágica" para evitar la complejidad de AGDLP. Sin embargo, la investigación es contundente al desaconsejar su uso como mecanismo principal de gestión de acceso diario. Los riesgos asociados son significativos y afectan tanto a la disponibilidad como al rendimiento de la red.1

=== 6.1 El Impacto en la Replicación del Catálogo Global (GC) ===
Esta es la razón técnica más crítica. En Active Directory, los datos de los Grupos Globales y de Dominio Local se replican solo dentro de sus respectivos dominios. El Catálogo Global (GC) mantiene un índice parcial de los objetos del bosque, pero generalmente no incluye la lista de miembros de estos grupos.

Por el contrario, la definición misma de un Grupo Universal dicta que su membresía se almacena en el Catálogo Global.

* '''Mecanismo del problema:''' Cada vez que se añade o elimina un usuario de un Grupo Universal, este cambio se considera un cambio en el esquema global que debe replicarse a todos los servidores de Catálogo Global en todo el bosque.

* '''Consecuencia ("tormentas de replicación"):''' En una organización dinámica donde los usuarios se mueven frecuentemente, el uso de Grupos Universales para roles diarios generaría un tráfico de replicación masivo y constante a través de los enlaces WAN. Esto puede saturar conexiones lentas entre sedes geográficas y causar latencia en la convergencia de datos del directorio.27

=== 6.2 Dependencia Crítica de Disponibilidad ===
Para que un usuario que pertenece a Grupos Universales pueda iniciar sesión, el Controlador de Dominio autenticador debe poder comunicarse con un servidor de Catálogo Global para enumerar estas membresías y construir el token de seguridad.

Si el enlace WAN se cae y el sitio remoto no tiene un GC local (y no se ha habilitado el "Universal Group Membership Caching"), el usuario podría experimentar fallos en el inicio de sesión o recibir un token incompleto, denegándole el acceso a recursos críticos. Los Grupos Globales y de Dominio Local no tienen esta dependencia estricta de disponibilidad forestal para la autenticación intra-dominio, lo que los hace más resilientes.16

=== 6.3 Riesgos de Seguridad por Alcance Excesivo ===
Los Grupos Universales rompen el principio de "aislamiento de fallos". Un error en la gestión de un Grupo Universal (por ejemplo, añadir un grupo de "Usuarios Externos" por error) se propaga inmediatamente a todo el bosque, exponiendo recursos en todos los dominios. En contraste, AGDLP confina el impacto de los errores de gestión de usuarios al dominio de origen y los errores de permisos al dominio del recurso, proporcionando compartimentación de riesgos.

=== 6.4 Excepciones: ¿Cuándo Usar Grupos Universales? ===
No deben ser eliminados, sino usados estratégicamente. El caso de uso aceptable es para grupos cuya membresía es estática o cambia muy raramente, o para consolidar grupos en estructuras muy complejas (modelo AGUDLP).

* '''Listas de Distribución de Correo:''' Su uso nativo en Exchange.

* '''Modelo AGUDLP:''' Si una organización tiene 50 dominios, añadir 50 Grupos Globales a cada Grupo de Dominio Local puede ser tedioso. Se puede crear un Grupo Universal intermedio para agrupar los 50 GGs.

** '''Estructura:''' A → G → U → DL → P.

** '''Ventaja:''' Los miembros del Grupo Universal son Grupos Globales, no usuarios. Como los Grupos Globales raramente se crean o eliminan, la membresía del Universal es estable, minimizando el impacto en la replicación del GC.

== 7. Comparativa Estructural y Matriz de Decisión ==
Para facilitar la selección de la estrategia adecuada, se presenta la siguiente comparativa estructurada basada en los hallazgos de la investigación:
{| class="wikitable"
!Parámetro de decisión
!Estrategia AGP
!Estrategia AGDLP
!Estrategia de Grupos Universales
|-
|Escenario objetivo
|Dominio único
|Múltiples dominios (mismo bosque)
|Bosques masivos con cambios estáticos
|-
|Complejidad de gestión
|Baja (1 grupo por rol)
|Media (2 grupos: rol + acceso)
|Alta (gestión de impacto en replicación)
|-
|Tráfico de replicación
|Bajo (confinado al dominio)
|Bajo (confinado al dominio + referencias)
|Alto (forest-wide vía GC)
|-
|Escalabilidad
|Limitada al límite del dominio
|Alta (soporta expansión y fusiones)
|Alta, pero con penalización de red
|-
|Auditoría de seguridad
|Simple y directa
|Estructurada y jerárquica
|Difusa (difícil rastrear origen)
|-
|Resiliencia de red
|Alta (autónoma)
|Alta (depende de confianza)
|Media (depende de disponibilidad de GC)
|-
|Tamaño del token
|Optimizado (mínimos SIDs)
|Moderado (SIDs de G + DL)
|Moderado, pero requiere consulta GC
|}

== 8. Consideraciones Operativas y Mejores Prácticas ==
La implementación exitosa de estas estrategias requiere más que un diseño técnico; exige disciplina operativa.

=== 8.1 Convenciones de Nomenclatura Estrictas ===
Dado que AGDLP multiplica el número de grupos (separando roles de permisos), una convención de nombres lógica es vital para evitar el caos administrativo. Se recomienda codificar el tipo de grupo, el ámbito y el propósito en el nombre.

* '''Grupos Globales:''' <code>GG_&#x3C;Departamento&#x3E;_&#x3C;Rol&#x3E;</code> (por ejemplo, <code>GG_Ventas_Managers</code>).

* '''Grupos de Dominio Local:''' <code>DL_&#x3C;Servidor/Recurso&#x3E;_&#x3C;Permiso&#x3E;</code> (por ejemplo, <code>DL_SrvFile01_Data_Modificar</code>).

Esto permite a los administradores entender la función del grupo y su lugar en la jerarquía AGDLP simplemente leyendo su nombre.1

=== 8.2 Higiene del Directorio y Ciclo de Vida ===
La acumulación de grupos obsoletos es un riesgo de seguridad. Se deben implementar procesos de revisión periódica ('''Access Reviews''') para:

# Verificar que los Grupos Globales tienen los usuarios correctos (validación con RRHH).

# Verificar que los Grupos de Dominio Local tienen los Grupos Globales correctos (validación con dueños de recursos).

# Eliminar grupos vacíos o circulares que contribuyan al "Token Bloat".

=== 8.3 Ejercicio práctico: Diseño de permisos para el área de Mercadeo (AGP) ===
En este ejercicio se aplica el modelo '''AGP''' (''Accounts → Global → Permissions'') para resolver un caso realista de control de acceso en un entorno de dominio único de Active Directory.

==== 8.3.1 Escenario y requisitos de negocio ====
[[index.php?title=Archivo:1.png|miniaturadeimagen|<gallery>
Archivo:Escenario del ejercicio.png
</gallery>Escenario del ejercicio: estructura de carpetas (Principal, Secundaria, Terciaria) y requisitos de acceso para el personal de Mercadeo.]]
El servidor de archivos dispone de la siguiente estructura de carpetas:

* '''Principal'''
** Archivo 1
** Archivo 2
* '''Secundaria'''
** Informe 1.docx
** Calculo 1.xlsx
* '''Terciaria'''

El personal de '''Mercadeo''' debe cumplir:

* No podrá consultar (ni obtener ningún otro acceso) a los archivos colocados en la carpeta '''Principal'''.
* Podrá modificar el contenido del archivo '''Informe1.docx''' (carpeta '''Secundaria'''), pero no podrá consultar ningún otro archivo de dicha carpeta.
* Podrá colocar archivos en la carpeta '''Terciaria''', pero no podrá acceder a ninguna subcarpeta dentro de Terciaria.

==== 8.3.2 Grupos de seguridad en Active Directory (A → G) ====
[[index.php?title=Archivo:9.png|centro|miniaturadeimagen|Vista general de la OU '''OU Accesos''' con los grupos globales y de dominio local usados en el laboratorio.]]
[[index.php?title=Archivo:14.png|centro|miniaturadeimagen|Detalle de la OU '''OU Accesos''' con el grupo global '''gGre2Mercadeo''' (rol del personal de Mercadeo).]]
En la OU '''OU Accesos''' se han definido, entre otros, los grupos globales:

* <code>gGre2Mercadeo</code>: agrupa a todas las cuentas de usuario del departamento de Mercadeo.
* <code>gInformesLectura</code>, <code>gInformesEscribir</code>, <code>gInformesModificar</code>, <code>gInformesControlTotal</code>: niveles de permiso sobre información de informes.
* <code>gTerciariaEspeciales</code>: grupo con permisos especiales sobre la carpeta Terciaria.

En el modelo AGP:

* '''A''' (Accounts): usuarios finales del dominio.
* '''G''' (Global): cada usuario se agrega al grupo de rol que le corresponde (por ejemplo, <code>gGre2Mercadeo</code> y <code>gInformesEscribir</code>).
* '''P''' (Permissions): estos grupos globales se usan directamente en las ACL NTFS y de recurso compartido.

==== 8.3.3 Matriz de permisos de los recursos (P) ====
[[index.php?title=Archivo:2.png|centro|miniaturadeimagen|Matriz de permisos: principales de seguridad, tipo de permiso (Shared/NTFS) y nivel de acceso para cada recurso del ejercicio.]]
Resumen del diseño:

; Carpeta '''Principal'''

* <code>gGre2Mercadeo</code> – NTFS: ''Mostrar el contenido de la carpeta''.

; Carpeta '''Secundaria'''

* <code>gGre2Mercadeo</code> – NTFS: ''Mostrar el contenido de la carpeta''.

; Archivo '''Informe1.docx'''

* <code>gInformesEscribir</code> – NTFS: ''Escribir'' (lectura + escritura sobre el archivo).

; Carpeta '''Terciaria'''

* <code>gTerciariaEspeciales</code> – NTFS: ''Permisos especiales'' (escritura en la carpeta raíz, sin heredar a subcarpetas).

Auth Users, SYSTEM y Administradores del dominio conservan permisos administrativos (por simplicidad del laboratorio).

==== 8.3.4 Permisos de recurso compartido (Shared) ====
Los permisos de compartición se dejan amplios y la seguridad real se aplica con NTFS.

===== 8.3.4.1 Carpeta Principal (share) =====
[[index.php?title=Archivo:8.png|centro|miniaturadeimagen|Uso compartido avanzado de la carpeta '''Principal''', publicada como recurso compartido llamado ''principal''.]]
La carpeta <code>C:\principal</code> se comparte con el nombre '''principal'''.  Más adelante, los permisos NTFS restringirán lo que realmente puede hacer el grupo de Mercadeo.

===== 8.3.4.2 Carpeta Secundaria (share) =====
[[index.php?title=Archivo:7.png|centro|miniaturadeimagen|Permisos del recurso compartido de la carpeta '''secundaria''' para el grupo ''Usuarios autenticados''.]]
En la pestaña de permisos del recurso compartido de '''secundaria''' se configura:

* '''Usuarios autenticados''' – Control total, Cambiar y Leer.

===== 8.3.4.3 Carpeta Terciaria (share) =====
[[index.php?title=Archivo:12.png|centro|miniaturadeimagen|Permisos del recurso compartido de la carpeta '''terciaria''' para ''Usuarios autenticados''.]]
La carpeta '''terciaria''' también se comparte otorgando a '''Usuarios autenticados''' control total a nivel de share.  El detalle fino se controla con los permisos NTFS.

==== 8.3.5 Permisos NTFS por recurso ====
En esta parte se muestra cómo se aplican los permisos NTFS para cumplir exactamente los requisitos de Mercadeo.

===== 8.3.5.1 Carpeta Principal: Mercadeo no abre archivos =====
[[index.php?title=Archivo:3.png|centro|miniaturadeimagen|Permisos NTFS en '''C:\principal''' para el grupo global '''gGre2Mercadeo'''. Solo está permitido ''Mostrar el contenido de la carpeta''.]]
En <code>C:\principal</code> el grupo <code>gGre2Mercadeo</code> solo tiene:

* '''Mostrar el contenido de la carpeta''' (sin lectura de archivos).

Así, el personal de Mercadeo no puede abrir ni leer los archivos que se coloquen en '''Principal'''.

===== 8.3.5.2 Carpeta Secundaria: acceso mínimo =====
[[index.php?title=Archivo:10.png|centro|miniaturadeimagen|Permisos NTFS de la carpeta '''C:\principal\secundaria''' para el grupo '''gGre2Mercadeo''' y administradores.]]
En la carpeta <code>C:\principal\secundaria</code> se mantiene el mismo patrón:  <code>gGre2Mercadeo</code> tiene permisos limitados (por ejemplo, solo mostrar el contenido de la carpeta).  El acceso a los documentos se controla caso por caso, como se ve a continuación con '''Informe1.docx'''.

===== 8.3.5.3 Archivo Informe1.docx: Mercadeo puede modificar solo este archivo =====
[[index.php?title=Archivo:11.png|centro|miniaturadeimagen|Lista de control de acceso de '''Informe01.docx''', donde aparece el grupo '''gInformesEscribir''' junto a SYSTEM y administradores.]]
[[index.php?title=Archivo:4.png|centro|miniaturadeimagen|Detalle de los permisos de '''gInformesEscribir''' sobre '''Informe1.docx''': lectura y escritura (escribir).]]
En el archivo <code>C:\principal\secundaria\Informe01.docx</code> se agrega el grupo:

* <code>gInformesEscribir</code> – Lectura y Escritura.

De este modo, los usuarios de Mercadeo que pertenezcan a <code>gInformesEscribir</code> pueden leer y modificar exclusivamente '''Informe1.docx''', sin que esto les conceda permisos sobre otros archivos en la carpeta '''Secundaria'''.

===== 8.3.5.4 Carpeta Informes: lectura para lectores de informes =====
[[index.php?title=Archivo:6.png|centro|miniaturadeimagen|Configuración de seguridad avanzada de '''C:\Informes''' con el grupo '''gInformesLectura''' en modo ''Lectura y ejecución'' aplicado a esta carpeta, subcarpetas y archivos.]]
En la carpeta <code>C:\Informes</code> se configura el grupo global <code>gInformesLectura</code> con:

* Acceso: '''Lectura y ejecución'''.
* Alcance: ''Esta carpeta, subcarpetas y archivos''.

Este patrón crea un repositorio de informes de solo lectura para cierto conjunto de usuarios.

===== 8.3.5.5 Carpeta Terciaria: escribir sin heredar a subcarpetas =====
[[index.php?title=Archivo:13.png|centro|miniaturadeimagen|Permisos NTFS de la carpeta '''C:\principal\terciaria''', donde participa el grupo '''gTerciariaEspeciales'''.]]
[[index.php?title=Archivo:5.png|centro|miniaturadeimagen|Entrada de permisos avanzada de '''gTerciariaEspeciales''' en la carpeta '''terciaria''', aplicada solo a ''Esta carpeta''. Se permiten lectura y creación de archivos/carpetas.]]
En <code>C:\principal\terciaria</code> se utiliza el grupo global <code>gTerciariaEspeciales</code> con una entrada avanzada:

* '''Tipo''': Permitir.
* '''Se aplica a''': ''Solo esta carpeta''.
* Permisos seleccionados:
** Atravesar carpeta / ejecutar archivo.
** Mostrar carpeta / leer datos.
** Leer atributos y atributos extendidos.
** Crear archivos / escribir datos.
** Crear carpetas / anexar datos.
** Permisos de lectura.

Así, el usuario puede crear archivos y carpetas directamente en '''Terciaria''', pero como la entrada no se hereda, las subcarpetas internas pueden mantenerse inaccesibles o gestionarse con otros grupos.

==== 8.3.6 Comprobación visual del acceso en Terciaria ====
[[index.php?title=Archivo:15.png|centro|miniaturadeimagen|Carpeta '''C:\principal\terciaria''' vista desde el explorador de archivos: el usuario puede crear carpetas y documentos de texto según los permisos otorgados.]]
La vista del explorador muestra varias carpetas y documentos de texto creados en '''Terciaria''', lo que confirma que los usuarios del grupo <code>gTerciariaEspeciales</code> pueden escribir en la carpeta raíz.  El acceso adicional a las subcarpetas dependerá de permisos NTFS específicos en cada una.

==== 8.3.7 Resumen del flujo AGP aplicado ====
En el caso del departamento de Mercadeo, el flujo completo es:

* '''Accounts (A)''': usuarios finales del dominio.
* '''Global (G)''':
** <code>gGre2Mercadeo</code>: rol general de Mercadeo.
** <code>gInformesEscribir</code> y <code>gInformesLectura</code>: niveles de acceso a informes.
** <code>gTerciariaEspeciales</code>: escritura controlada en la carpeta Terciaria.
* '''Permissions (P)''': estos grupos se usan directamente en las ACL NTFS y en los permisos de recurso compartido para controlar el acceso a:
** Carpeta '''Principal'''.
** Carpeta '''Secundaria'''.
** Archivo '''Informe1.docx'''.
** Carpeta '''Informes'''.
** Carpeta '''Terciaria'''.

Este ejercicio muestra cómo un diseño basado en AGP permite traducir requisitos de negocio muy concretos (lo que el departamento de Mercadeo puede o no puede hacer) en una configuración de grupos y permisos que es coherente, auditables y alineada con el principio de mínimo privilegio.

== 9. El Imperativo de Seguridad: La Filosofía de "Lo Justo y Necesario" (Ni Más, Ni Menos) ==
En el ámbito de la ciberseguridad, el exceso de permisos no es una "comodidad administrativa", sino una vulnerabilidad crítica. Esta sección enfatiza por qué la aplicación estricta de permisos exactos, ni más ni menos, es obligatoria para la supervivencia de la red.

=== 9.1 Definición Estricta del Mínimo Privilegio ===
El Principio de Mínimo Privilegio establece que a un usuario, proceso o programa se le deben otorgar solamente los permisos exactos necesarios para completar su tarea asignada, y por el tiempo estrictamente necesario.

* '''Ni más:''' Otorgar permisos adicionales "por si acaso" o para evitar tickets de soporte crea brechas de seguridad. Si un usuario solo necesita leer un archivo, darle permisos de "Modificar" es un fallo de seguridad.

* '''Ni menos:''' Restringir demasiado impide la productividad, lo que lleva a los usuarios a buscar atajos inseguros (como compartir contraseñas). El equilibrio debe ser quirúrgico.

=== 9.2 El Riesgo Mortal del "Over-Provisioning" y el Movimiento Lateral ===
La razón fundamental para ser tan estrictos con los permisos no es la burocracia, sino detener a los atacantes una vez que han entrado.

* '''Bloqueo del movimiento lateral:''' Si un atacante compromete la cuenta de un usuario de Marketing que, por error o pereza administrativa, tiene permisos de lectura sobre carpetas de Finanzas, el atacante se moverá lateralmente hacia esos datos sensibles sin necesidad de escalar privilegios. Al limitar los permisos a "lo justo", confinamos al atacante en una "caja" pequeña, impidiendo que salte de un servidor a otro.

* '''Contención de ransomware:''' El ransomware moderno utiliza los permisos del usuario infectado para cifrar todo lo que este puede acceder. Si aplicamos AGDLP para dar solo acceso de lectura donde no se requiere escritura, el ransomware no podrá cifrar esos archivos. Cada permiso de escritura innecesario es una puerta abierta a la destrucción masiva de datos.

=== 9.3 Reducción de la Superficie de Ataque ===
Cada permiso otorgado es una expansión de la superficie de ataque. Las cuentas sobre-privilegiadas son los objetivos predilectos para el robo de credenciales. Al adherirse a "lo justo y necesario", se minimiza el impacto de una credencial robada. Si la cuenta comprometida solo tiene acceso a su propio buzón y carpeta personal, el daño a la organización es insignificante en comparación con una cuenta que tiene acceso amplio a recursos.

== 10. Conclusión ==
La investigación confirma que la dicotomía entre AGP y AGDLP no es una cuestión de preferencia personal, sino de adecuación arquitectónica. Para entornos de dominio único, AGP ofrece la máxima eficiencia, seguridad y simplicidad, evitando la sobrecarga administrativa. Para entornos de múltiples dominios, AGDLP es la única metodología sostenible que garantiza la seguridad a través de las fronteras de confianza, la escalabilidad ante el crecimiento organizacional y la estabilidad de los permisos de recursos.

El rechazo al uso de Grupos Universales para la gestión de permisos dinámicos está firmemente fundamentado en la preservación de la integridad del ancho de banda de replicación y la independencia de fallos de los dominios. La adhesión a estos modelos, complementada con el principio de mínimo privilegio, constituye la base de una infraestructura de Active Directory segura, auditada y resiliente.

== Identificación de Fuentes de Investigación ==
Este informe ha sido elaborado integrando información técnica de múltiples fuentes documentales y bases de conocimiento de Microsoft. Las referencias insertadas en el texto corresponden a los fragmentos de investigación analizados, garantizando la trazabilidad de las recomendaciones presentadas.

== Obras citadas ==

# EstrategiasGrupos.docx

# Best Practices for Securing and Managing Active Directory – An In-depth Guide, fecha de acceso: noviembre 29, 2025, https://questsys.com/security-blog/Best-Practices-for-Securing-and-Managing-Active-Directory-An-In-depth-Guide/

# AGDLP - ITFreeTraining, fecha de acceso: noviembre 29, 2025, https://itfreetraining.com/lesson/agdlp/

# AGDLP - Wikipedia, fecha de acceso: noviembre 29, 2025, https://en.wikipedia.org/wiki/AGDLP

# Active Directory Security Groups | Microsoft Learn, fecha de acceso: noviembre 29, 2025, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups

# Active Directory Group Management Best Practices - Netwrix, fecha de acceso: noviembre 29, 2025, https://netwrix.com/en/resources/guides/active-directory-group-management-best-practices/

# What is a Global Security Group? - JumpCloud, fecha de acceso: noviembre 29, 2025, https://jumpcloud.com/it-index/what-is-a-global-security-group

# Campus Active Directory - Security Group Management Recommendation, fecha de acceso: noviembre 29, 2025, https://kb.wisc.edu/iam/38033

# AGDLP: global vs local groups for job/role groups - Server Fault, fecha de acceso: noviembre 29, 2025, https://serverfault.com/questions/886792/agdlp-global-vs-local-groups-for-job-role-groups

# Best Practices for Active Directory Domains that Use Single-label DNS Names - Windows Server | Microsoft Learn, fecha de acceso: noviembre 29, 2025, https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/deployment-operation-ad-domains

# O'Reilly - Windows 2000 Administration in a Nutshell.pdf - elhacker.INFO, fecha de acceso: noviembre 29, 2025, https://elhacker.info/manuales/OReilly%204%20GB%20Collection/O'Reilly%20-%20Windows%202000%20Administration%20in%20a%20Nutshell.pdf

# Determining Group Requirements for Resource Access | MCSE: Windows Server 2003 Active Directory and Network Infrastructure Design Study Guide (70-297) - Flylib.com, fecha de acceso: noviembre 29, 2025, https://flylib.com/books/en/4.340.1.72/1/

# Best practice for authorization on file servers - migRaven, fecha de acceso: noviembre 29, 2025, https://www.migraven.com/en/best-practice-for-granting-permissions-on-file-servers/

# AGLP vs AGP - Any benefits? - PC Review, fecha de acceso: noviembre 29, 2025, https://www.pcreview.co.uk/threads/aglp-vs-agp-any-benefits.1435289/

# Building Modern Active Directory - Engineering, Building, and - Evgenij Smirnov - 1, 2024 - Apress - 9788868809409 - Anna's Archive | PDF - Scribd, fecha de acceso: noviembre 29, 2025, https://ru.scribd.com/document/832036325/Building-Modern-Active-Directory-Engineering-Building-and-Evgenij-Smirnov-1-2024-Apress-9788868809409-abf44c3ad4063c520c18ec70bcdf5

# Planning Global Catalog Server Placement | Microsoft Learn, fecha de acceso: noviembre 29, 2025, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/planning-global-catalog-server-placement

# Six ways to apply the principle of least privilege to your Active Directory - Specops Software, fecha de acceso: noviembre 29, 2025, https://specopssoft.com/blog/six-ways-to-apply-the-principle-of-least-privilege-to-your-active-directory/

# AGDLP - Grokipedia, fecha de acceso: noviembre 29, 2025, https://grokipedia.com/page/AGDLP

# AGDLP: Microsoft's Best Practice for Group Structure - tenfold, fecha de acceso: noviembre 29, 2025, https://www.tenfold-security.com/en/wiki/agdlp/

# Domain-Local vs Universal, help me : r/sysadmin - Reddit, fecha de acceso: noviembre 29, 2025, https://www.reddit.com/r/sysadmin/comments/17nm4ws/domainlocal_vs_universal_help_me/

# Active Directory Migration Strategic Planning Built for Your Peace of Mind - Formula5, fecha de acceso: noviembre 29, 2025, https://formula5.com/active-directory-migration-strategic-planning-built-for-your-peace-of-mind/

# Best Practices Guide - AGDLP Model - 1.0 | PDF | System Software | Computing - Scribd, fecha de acceso: noviembre 29, 2025, https://www.scribd.com/document/825977817/Best-Practices-Guide-AGDLP-Model-1-0

# PowerShell PKI (PSPKI) 3.7 enhancements – security descriptors, fecha de acceso: noviembre 29, 2025, https://www.pkisolutions.com/powershell-pki-pspki-3-7-enhancements-security-descriptors/

# Implementing Least-Privilege Administrative Models - Microsoft Learn, fecha de acceso: noviembre 29, 2025, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models

# Best practices for securing Active Directory | Microsoft Learn, fecha de acceso: noviembre 29, 2025, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory

# Groups spanning domains with Microsoft Active Directory - IBM, fecha de acceso: noviembre 29, 2025, https://www.ibm.com/docs/en/was/8.5.5?topic=umada-groups-spanning-domains-microsoft-active-directory-1

# Is there a performance impact of direct AD universal groups assignment? - Server Fault, fecha de acceso: noviembre 29, 2025, https://serverfault.com/questions/538688/is-there-a-performance-impact-of-direct-ad-universal-groups-assignment

# Risk converting Domain Local Groups to Universal prior AD migration? - Microsoft Learn, fecha de acceso: noviembre 29, 2025, https://learn.microsoft.com/en-us/answers/questions/640661/risk-converting-domain-local-groups-to-universal-p

# What Is a Universal Security Group? - JumpCloud, fecha de acceso: noviembre 29, 2025, https://jumpcloud.com/it-index/what-is-a-universal-security-group

# Fixing Global Catalog issues in Active Directory - ManageEngine, fecha de acceso: noviembre 29, 2025, https://www.manageengine.com/log-management/ad-troubleshoot/global-catalog.html

# What are Active Directory Groups? Definition, Types & Scope - Lepide Software, fecha de acceso: noviembre 29, 2025, https://www.lepide.com/blog/what-are-active-directory-groups/

# Microsoft AD nested groups depth/levels best practice : r/activedirectory - Reddit, fecha de acceso: noviembre 29, 2025, https://www.reddit.com/r/activedirectory/comments/1ff6fx2/microsoft_ad_nested_groups_depthlevels_best/

# Learn about groups, group membership, and access - Microsoft Entra, fecha de acceso: noviembre 29, 2025, https://learn.microsoft.com/en-us/entra/fundamentals/concept-learn-about-groups