Un directorio es también un sistema de autoridad
Active Directory Domain Services (AD DS) suele presentarse como una base de datos de usuarios y equipos. La descripción es cierta, pero insuficiente para seguridad. AD DS almacena identidades, grupos, equipos, servicios, políticas y relaciones de control; replica ese estado entre controladores de dominio; autentica principales; y entrega información que otros sistemas emplean para autorizar acciones.
El resultado es un plano de identidad y administración distribuido. Una modificación aparentemente pequeña —agregar un miembro a un grupo, cambiar una lista de control de acceso o enlazar una Group Policy Object— puede cambiar la autoridad efectiva sobre cientos de sistemas. La pregunta importante no es sólo «¿qué objetos existen?», sino «¿quién puede transformar qué objeto y qué consecuencias produce esa transformación?».
Este capítulo construye el modelo desde cuatro capas:
- estructura lógica y replicación;
- principales y autenticación;
- tokens, security descriptors y decisiones de acceso;
- política y confianza entre dominios o bosques.
Antes de empezar
El capítulo presupone cuatro capacidades, no una lista de productos memorizados. Del modelo de control de acceso debes poder identificar sujeto, objeto, operación y decisión; del capítulo de identidad, separar principal, credencial y sesión; de Kerberos, distinguir autenticación de autorización; y de infraestructura, reconocer que el Domain Name System (DNS) y el tiempo forman parte de la ruta de confianza. Hasta la decisión token–descriptor trabajaremos en nivel N2. Desde delegación, Group Policy y grafos de control, el razonamiento pasa a N3: cada conclusión deberá nombrar precondiciones, efecto observable y evidencia.
Bosque, dominio y unidad organizativa (OU) no son tres tamaños del mismo contenedor
Un bosque agrupa uno o más dominios que comparten schema, configuración y capacidades de búsqueda global. Los dominios de un bosque mantienen relaciones de confianza transitivas bidireccionales por defecto. El bosque define una comunidad administrativa profunda: quienes controlan componentes y administradores forestales pueden afectar el resto de la infraestructura. Microsoft, modelo lógico de AD DS
Un dominio define una partición de dominio (domain naming context) y un ámbito de identidad, replicación y administración; no es el único naming context posible del bosque. Sus controladores almacenan cuentas y credenciales, autentican y aportan memberships que otros sistemas emplean al autorizar. Varios controladores replican la partición del dominio; no existe un único servidor cuya copia sea siempre «la base de datos real».
Una organizational unit (OU) organiza objetos dentro de un dominio. Sirve principalmente para delegar administración y para enlazar GPO que entran en el cálculo de alcance; el vínculo no garantiza aplicación porque filtros, herencia, precedencia y procesamiento del cliente todavía cuentan. Una OU no aísla a sus objetos de los administradores con autoridad superior ni crea por sí misma una frontera comparable con un bosque.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Particiones y replicación
El directorio separa información en naming contexts o particiones. La partición de dominio contiene objetos propios de ese dominio. Schema y configuration poseen alcance forestal. Las application partitions permiten otros patrones de replicación. Un global catalog mantiene un subconjunto de atributos de objetos del bosque para búsquedas y ciertos procesos de autenticación.
Replicar mejora disponibilidad, pero convierte consistencia y privilegio en problemas distribuidos. Un cambio puede llegar a controladores diferentes en momentos distintos; los conflictos requieren reglas de resolución; y obtener control de un controlador no equivale a comprometer un servidor periférico. Un domain controller conserva material y autoridad capaces de afectar identidades y decisiones de todo su ámbito.
El Domain Name System (DNS) y el tiempo son dependencias de seguridad, no simples servicios auxiliares. Los clientes localizan controladores y servicios mediante DNS. Kerberos depende de una noción de tiempo suficientemente coordinada. Resolver hacia un servicio equivocado o perder sincronización puede producir fallos que parecen de credenciales pero pertenecen a infraestructura.
Un cambio de grupo ilustra la consecuencia distribuida: el controlador que recibe la escritura puede mostrarla antes que otro controlador, y una sesión ya creada puede conservar un token anterior. Antes de culpar a la contraseña hay que identificar qué controlador respondió, si la replicación convergió y si el sujeto obtuvo un contexto nuevo.
Los objetos tienen identidad y relaciones
Un objeto AD posee una clase definida por el schema y un conjunto de atributos: nombre, identificadores, memberships, claves o referencias, flags y metadatos. Un distinguished name expresa posición en la jerarquía; no es el identificador de seguridad que Windows utiliza al autorizar.
Los usuarios, equipos, servicios y grupos que pueden participar en seguridad son security principals. Al crearlos reciben un Security Identifier (SID). El SID persiste durante la vida del principal y es el valor que aparece en tokens y listas de control. Renombrar una cuenta no cambia su SID; eliminarla y crear otra con el mismo nombre produce otro principal.
Esta distinción explica un artefacto común: una Access Control List (ACL), o lista de control de acceso, puede mostrar un SID sin nombre después de eliminar la cuenta correspondiente. El permiso no «se transfirió» a una nueva cuenta homónima; quedó una referencia a un identificador que ya no resuelve.
Grupos como composición de autoridad
Los grupos permiten que una regla se refiera a un conjunto cambiante de principales. Pero la pertenencia no es sólo una lista plana. Hay scopes, grupos anidados, memberships construidas durante el logon y atributos especiales. Evaluar autoridad efectiva requiere seguir las relaciones que realmente llegan al token o que permiten modificar otro objeto.
Una cuenta puede no pertenecer hoy a un grupo privilegiado y aun así controlar quién pertenece mañana si posee derechos para modificarlo. Por eso inventariar únicamente nombres como Domain Admins pierde caminos de control indirecto.
Del principal al token
Autenticar credenciales establece un principal bajo un mecanismo y contexto. Windows construye después un access token que representa el contexto de seguridad utilizado por procesos o threads. Puede contener el SID del usuario, SIDs de grupos, privilegios, restricciones y otra información relevante.
El token no es la contraseña ni un ticket Kerberos. Es el objeto local que el sistema operativo utiliza al comparar el sujeto con recursos securables. Un proceso suele portar un primary token; un thread puede operar temporalmente con un impersonation token para actuar en nombre de un cliente bajo reglas específicas. Microsoft, Security Principals
Cambiar membership en el directorio no reescribe mágicamente todos los tokens existentes. Según el tipo de sesión y recurso, puede ser necesario obtener un contexto nuevo para que la modificación se refleje. Esta diferencia entre estado del directorio y estado de una sesión explica resultados que de otro modo parecen inconsistentes.
Security descriptor, listas de acceso y entradas de control
Un objeto securable posee un security descriptor. Entre otros elementos, identifica owner y contiene listas de control:
- la Discretionary Access Control List (DACL) expresa quién puede o no realizar accesos;
- la System Access Control List (SACL) gobierna qué intentos generan auditoría;
- cada Access Control Entry (ACE) relaciona un principal o condición con derechos, tipo y reglas de herencia.
Cuando un sujeto solicita acceso, el sistema compara el token con el security descriptor y evalúa los derechos pedidos. «Tiene algún permiso» no basta: la decisión depende del derecho exacto, de ACE aplicables, herencia, denies, atributos y semántica del objeto.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Derechos sobre objetos de directorio
AD aplica este modelo a sus propios objetos. Además de derechos genéricos aparecen derechos sobre propiedades, creación o eliminación de hijos y extended rights. Una ACE puede permitir restablecer una contraseña, escribir un atributo determinado, modificar una membership o delegar otra capacidad sin otorgar control total visible.
La herencia simplifica administración, pero amplía consecuencias. Una ACE heredable aplicada sobre una OU puede alcanzar muchos objetos descendientes; una protección contra herencia o una ACE específica puede alterar el resultado. La autoridad efectiva debe calcularse sobre el objeto y operación reales, no a partir de la apariencia de una carpeta.
Por ejemplo, una ACE que permite a Soporte restablecer contraseñas sobre usuarios de OU=Personal no autoriza crear cuentas, editar GPO ni cambiar cualquier atributo. Tampoco demuestra que la delegación sea segura: hay que comprobar qué usuarios están realmente en el ámbito, si la ACE se hereda y si alguno de esos usuarios posee autoridad sobre sistemas sensibles.
Delegación: distribuir trabajo sin crear una frontera
Delegar consiste en conceder derechos limitados sobre objetos o contenedores. Un equipo de soporte puede restablecer contraseñas dentro de una OU sin convertirse formalmente en administrador de dominio. Esa granularidad es valiosa, pero sólo si los derechos delegados coinciden con la intención.
Un derecho aparentemente operativo puede componer autoridad mayor. Restablecer la contraseña de una cuenta privilegiada puede abrir un camino posterior de autenticación, pero no asume automáticamente su identidad ni crea por sí solo un token o una sesión; también hay que comprobar MFA, emisión de credenciales, contexto y enforcement. Escribir un service principal name, modificar una GPO aplicable a servidores sensibles o controlar un equipo donde inicia sesión un administrador puede producir otros caminos indirectos hacia Tier 0.
El modelo moderno de privilegio trata como Tier 0 no sólo a domain controllers y grupos incorporados, sino también a sistemas de gestión, backups, hipervisores, agentes o identidades capaces de controlarlos. Un jump server hereda el nivel de confianza de las credenciales que lo atraviesan. Microsoft, AD DS Tier Model
Group Policy: política distribuida, no «un script central»
Una Group Policy Object (GPO) combina un Group Policy Container (GPC) almacenado en el directorio con un Group Policy Template (GPT) distribuido mediante el volumen compartido System Volume (SYSVOL). El GPC conserva metadatos y el GPT contiene los archivos de política. Las GPO se enlazan a sitios, dominios u OU y se aplican según alcance, precedencia, herencia, seguridad y otros filtros; controlar el objeto, el contenido o el enlace son capacidades distintas.
Empieza por un caso mínimo: Baseline-Workstations está enlazada a OU=Workstations, el equipo WS-17 está dentro de esa OU y un setting no compite con otro. Sólo si el equipo tiene permisos de lectura y aplicación, el cliente recupera las dos partes coherentes de la GPO y procesa el setting. El enlace por sí solo no prueba aplicación.
La regla mnemónica Local–Site–Domain–OU ayuda a orientarse, pero no resuelve todos los casos. Enforced links, block inheritance, múltiples OU, security filtering, filtros de Windows Management Instrumentation (WMI) y loopback processing pueden cambiar el conjunto o precedencia efectiva. El análisis debe preguntar:
- ¿Qué GPO existen y dónde están enlazadas?
- ¿A qué principal y equipo se aplica cada una?
- ¿Qué filtros o excepciones intervienen?
- ¿Qué setting gana cuando hay conflicto?
- ¿Quién puede modificar el objeto, el contenido o el enlace?
Una GPO capaz de ejecutar configuración o código sobre equipos es un mecanismo de administración con impacto de seguridad. Controlarla puede equivaler a controlar los sistemas que la consumen.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Trust: aceptar autenticación no concede acceso
Una relación de confianza permite que un dominio acepte autenticación respaldada por otro bajo reglas determinadas. Puede ser unidireccional o bidireccional, transitiva o no transitiva. La dirección suele describirse mal porque «A confía en B» y «usuarios de B acceden a recursos de A» observan la misma relación desde lados distintos.
El punto estable es éste: un trust crea un camino de autenticación. El recurso del lado que acepta esa identidad todavía evalúa su propia autorización. Si ninguna ACL concede derechos al principal o a sus grupos, autenticarse a través del trust no abre el recurso.
Fija la dirección con un caso: el servidor files.a.example pertenece al dominio A y acepta una identidad respaldada por B conforme a la política del trust. Eso no significa que “B controla A”. El servidor de A todavía valida el contexto aceptado y evalúa el derecho solicitado —por ejemplo read— contra la DACL de su recurso. Sin una ACE aplicable, el resultado es deny aunque la autenticación haya cruzado correctamente.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Los trusts también amplían el razonamiento sobre transitividad, espacios de SID, referrals y administración. Una relación entre dos bosques no se extiende implícitamente a un tercero sólo porque éste confíe en uno de ellos. SID filtering restringe qué SID del contexto externo se aceptan; selective authentication exige autorizar qué principales pueden autenticarse ante equipos concretos. Son condiciones posibles de ciertos trusts, no propiedades automáticas de toda relación.
El bosque como frontera administrativa de seguridad
Compartir bosque significa compartir componentes y administradores capaces de producir efectos forestales. Microsoft advierte que los participantes deben confiar en forest owners y service administrators; el acceso privilegiado o físico a controladores puede afectar datos y servicios más allá de un dominio aislado. Microsoft, Service Administrator Scope of Authority
Por eso separar departamentos en dominios u OU no crea autonomía frente a operadores del bosque. Si dos organizaciones no pueden aceptar esa comunidad de confianza, la discusión correcta no es diseñar una OU más estricta, sino evaluar fronteras separadas y los costes de integración entre ellas.
Desliza horizontalmente para consultar todas las columnas.
Leer autoridad como grafo
El organigrama muestra responsabilidades declaradas. La autoridad técnica forma un grafo: principales controlan grupos; grupos aparecen en DACL; GPO alcanzan equipos; equipos reciben sesiones privilegiadas; servicios poseen credenciales; trusts aceptan identidades externas; y administradores controlan la infraestructura que conserva todo ese estado.
Preguntar «¿quién es administrador?» produce una lista incompleta. Conviene preguntar:
- ¿quién puede modificar el principal o su método de autenticación?
- ¿quién puede cambiar memberships o ACE relevantes?
- ¿quién controla equipos donde aparecen credenciales privilegiadas?
- ¿quién modifica GPO, scripts, agentes o pipelines de administración?
- ¿qué relaciones de trust introducen identidades de otros ámbitos?
- ¿qué control permite transformar una autoridad limitada en otra?
Éste es el puente entre arquitectura, defensa y assessment. El mismo grafo ayuda a reducir privilegio, diseñar detecciones y validar caminos de compromiso.
Un caso completo: la cuenta de soporte que parecía limitada
Supongamos que el equipo de soporte recibe permiso para restablecer contraseñas de usuarios en una OU. La intención es razonable: resolver bloqueos sin entregar membresía en grupos administrativos. Una revisión superficial confirma que sus cuentas no pertenecen a Domain Admins y concluye que la delegación es segura.
El análisis correcto comienza por la operación concreta. Si dentro de esa OU existe una cuenta que administra servidores, restablecer su contraseña puede habilitar un intento posterior de autenticación como esa cuenta, sujeto a los controles de autenticación y a la emisión de un contexto nuevo; no demuestra por sí solo que la identidad haya sido asumida. Si la cuenta no está allí, aún puede haber otros caminos: soporte quizá modifica un grupo al que pertenece una cuenta privilegiada; controla una estación donde ésta inicia sesión; o puede editar una GPO que alcanza el equipo desde el que se administra el dominio. Ninguno de esos caminos aparece al consultar sólo la membresía directa del operador.
También hay que separar capacidad presente y capacidad derivada. Una ACE puede no conceder acceso al servidor final, pero sí permitir modificar un objeto que concede ese acceso. En términos de grafo, el primer derecho es una arista de control y el segundo objeto es un nodo intermediario. La severidad depende de que la composición sea realizable: objeto en alcance, herencia efectiva, sesión válida, política aplicada y ausencia de otro control que rompa el camino.
La remediación tampoco consiste siempre en eliminar toda delegación. Puede requerir mover cuentas sensibles fuera del ámbito, limitar el derecho a propiedades precisas, proteger grupos privilegiados, separar estaciones administrativas, revisar quién modifica las GPO y observar cambios de ACL o membresía. El objetivo es conservar la operación legítima mientras se corta la composición peligrosa.
Cómo investigar sin confundir evidencia con inferencia
Una evaluación profesional combina varias vistas. El directorio revela objetos, atributos, memberships y ACL; los controladores aportan eventos de autenticación y cambios; los equipos muestran tokens, sesiones y aplicación de políticas; DNS y tiempo explican dependencias que afectan el protocolo. Ninguna vista aislada demuestra toda la autoridad efectiva.
Conviene registrar cada afirmación con su procedencia y su alcance temporal. Una exportación de ACL demuestra el estado observado en ese momento, no que el permiso se haya utilizado. Un evento de logon demuestra una autenticación o sesión bajo condiciones concretas, no todos los accesos posteriores. Una ruta calculada por una herramienta es una hipótesis de composición que debe contrastarse con filtros, herencia, versiones y controles compensatorios.
Este cuidado evita dos errores simétricos. El primero es subestimar el riesgo porque «la cuenta no es administradora». El segundo es declarar compromiso total a partir de una arista teórica que no puede ejecutarse en el entorno real. Un hallazgo sólido describe el estado inicial, las operaciones necesarias, las condiciones previas, el efecto observable y aquello que todavía no se ha probado.
Fallos conceptuales frecuentes
«El árbol refleja la frontera de seguridad». La jerarquía ayuda a administrar nombres, delegaciones y policy; no elimina la autoridad de operadores superiores ni de componentes compartidos.
«Deny siempre gana». Es una regla pedagógica demasiado burda. El orden y aplicabilidad de las ACE, la herencia, el tipo de derecho y la forma en que se solicita acceso importan. La práctica segura es calcular la decisión para el objeto y operación concretos.
«Un trust conecta dos redes». Un trust trata identidades y autenticación. La conectividad, resolución de nombres, exposición de servicios y autorización de recursos son condiciones separadas.
«La GPO está enlazada, por tanto se aplica». El enlace es sólo una entrada al cálculo. Scope, filtrado, herencia, precedencia y procesamiento del cliente determinan el resultado efectivo.
«Replicado significa instantáneo». AD ofrece replicación distribuida, no simultaneidad perfecta. Diagnosticar cambios exige saber qué controlador atendió cada operación y si el estado ya convergió.
Criterio de diseño
Diseñar AD de forma segura significa reducir autoridad ambiental y hacer visibles sus composiciones. Las cuentas administrativas deben operar desde sistemas acordes con su nivel de confianza; las delegaciones necesitan alcance mínimo y dueño explícito; los cambios a grupos, ACL, trusts y GPO requieren trazabilidad; y las dependencias capaces de controlar domain controllers deben entrar en el mismo modelo de privilegio.
La revisión debe repetirse porque la autoridad cambia con cada objeto, enlace, agente o integración. Un diseño que era razonable antes de instalar una plataforma de gestión puede dejar de serlo cuando esa plataforma obtiene ejecución en todos los controladores. El modelo no es una fotografía decorativa: es una representación mantenida de quién puede transformar el sistema.
Síntesis
Active Directory es una base de datos distribuida y un plano de autoridad. Bosques, dominios y OU tienen funciones diferentes; sólo el bosque representa la comunidad administrativa más amplia. Los SIDs identifican principales, los tokens reúnen contexto de seguridad y los security descriptors expresan reglas sobre objetos. La autenticación produce identidad; la DACL decide una operación; la SACL gobierna auditoría.
Delegación, Group Policy y trusts permiten escalar administración y colaboración, pero también crean caminos indirectos. La seguridad no se deduce de nombres de grupos ni de la forma del árbol. Requiere seguir relaciones de control y comprender qué cambio puede producir cada derecho.
Comprobación de comprensión
- ¿Por qué una OU no constituye una frontera de seguridad frente a administradores del bosque?
- ¿Qué diferencia existe entre distinguished name y SID?
- ¿Qué información aporta un access token a una decisión de acceso?
- ¿Por qué SACL y DACL no son dos listas de permisos equivalentes?
- Un usuario cruza correctamente un trust. ¿Por qué aún puede recibir acceso denegado?
- ¿Cómo puede el control de una GPO producir autoridad sobre equipos sin cambiar sus grupos locales manualmente?
- ¿Por qué un agente de gestión instalado en domain controllers debe tratarse como Tier 0?
Problema de transferencia
Una empresa coloca Finanzas y Operaciones en OU distintas y delega cada OU a su propio equipo. Ambos equipos comparten bosque, los mismos administradores forestales y una plataforma de gestión instalada en todos los domain controllers. Evalúa qué autonomía proporciona realmente la separación y qué decisiones necesitarían bosques diferentes.
Fuentes principales
- Microsoft. Understanding the Active Directory Logical Model.
- Microsoft. Security Principals.
- Microsoft. AD DS Tier Model.
- Microsoft. Service Administrator Scope of Authority.
- IETF. RFC 4120: The Kerberos Network Authentication Service (V5).
- IETF. RFC 4511: Lightweight Directory Access Protocol.