> For the complete documentation index, see [llms.txt](https://4lec4st.gitbook.io/4lec4st/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://4lec4st.gitbook.io/4lec4st/active-directory/introduccion-a-active-directory/fundamentos-de-active-directory/estructura-de-active-directory.md).
# Estructura de Active Directory
## ¿Qué es Active Directory?
**Active Directory (AD)** es un servicio de directorio creado por Microsoft para gestionar de forma centralizada los recursos dentro de redes Windows. Se basa en una **estructura jerárquica y distribuida**, que permite a las organizaciones administrar usuarios, equipos, grupos, dispositivos de red, políticas, servidores, estaciones de trabajo y relaciones de confianza. Su componente principal, **Active Directory Domain Services (AD DS)**, proporciona autenticación, autorización y almacenamiento seguro de datos, como nombres de usuario, contraseñas y permisos.
***
## Seguridad, legado y superficie de ataque
AD fue introducido con **Windows Server 2000** y ha mantenido compatibilidad con versiones anteriores, lo cual ha dificultado su endurecimiento de forma predeterminada. En consecuencia, muchas funciones no son seguras por defecto. Administrar correctamente AD en entornos grandes es una tarea compleja, y cualquier configuración incorrecta puede convertirse en una puerta de entrada para atacantes. Esto, sumado a su enorme superficie de ataque, ha convertido a AD en un objetivo constante de evaluación y explotación en entornos internos.
***
## Enumeración desde cuentas sin privilegios
Una característica crítica de AD es que incluso una **cuenta de usuario básica del dominio** puede realizar amplias tareas de enumeración. Esto se debe a que gran parte de la base de datos de AD es accesible para todos los usuarios del dominio. Así, es posible recolectar información clave para el reconocimiento y posterior escalada de privilegios. Entre los objetos que pueden ser enumerados se encuentran:
* Computadoras del dominio
* Usuarios del dominio
* Grupos y membresías
* Unidades organizativas (OU)
* Políticas de grupo (GPO)
* Configuración de contraseñas y nivel funcional del dominio
* Listas de control de acceso (ACL)
* Relaciones de confianza entre dominios
Por esto, **comprender cómo funciona y se estructura AD es vital antes de atacarlo**. Al igual que con cualquier sistema, es más fácil comprometerlo si entendemos primero cómo está construido.
***
## Estructura jerárquica de AD
AD se organiza en forma de **árbol**, con un **bosque (forest)** en la cúspide que contiene uno o más **dominios**. Cada dominio puede tener **subdominios**, y dentro de ellos se definen las **unidades organizativas (OU)**, que sirven para clasificar objetos como usuarios, grupos y equipos. Esta estructura jerárquica permite delegar administración y aplicar políticas específicas a distintos subconjuntos.
Un **bosque** representa un límite de seguridad; los objetos dentro del mismo bosque están bajo control administrativo común. En cambio, los **dominios** dentro de un bosque definen límites administrativos más granulares. A su vez, las **OU** permiten aplicar **políticas de grupo diferentes** y segmentar recursos lógicamente.
***
## Ejemplo de estructura simplificada
Un esquema básico de un dominio y sus subdominios podría verse así:
```
INLANEFREIGHT.LOCAL/
├── ADMIN.INLANEFREIGHT.LOCAL
│ ├── GPOs
│ └── OU
│ └── EMPLOYEES
│ ├── COMPUTERS
│ │ └── FILE01
│ ├── GROUPS
│ │ └── HQ Staff
│ └── USERS
│ └── barbara.jones
├── CORP.INLANEFREIGHT.LOCAL
└── DEV.INLANEFREIGHT.LOCAL
```
En este caso, `INLANEFREIGHT.LOCAL` es el **dominio raíz**, y contiene los subdominios `ADMIN`, `CORP` y `DEV`. Cada subdominio puede contener sus propias OUs, objetos, políticas y configuraciones independientes.
***
## Relaciones de confianza entre dominios
Es común que una organización que adquiera otras cree **relaciones de confianza** entre distintos dominios o incluso entre bosques diferentes, en lugar de migrar todos los usuarios a un solo dominio. Estas confianzas permiten que los usuarios de un dominio accedan a recursos en otro, pero también pueden introducir riesgos si no se administran adecuadamente.
Por ejemplo, si dos bosques tienen una **confianza bidireccional** (como `INLANEFREIGHT.LOCAL` y `FREIGHTLOGISTICS.LOCAL`), los usuarios pueden autenticarse en ambos entornos. Sin embargo, esto no implica que los subdominios hereden automáticamente esas confianzas. Para que un usuario de `admin.dev.freightlogistics.local` pueda acceder a recursos en `wh.corp.inlanefreight.local`, se debe configurar explícitamente una nueva confianza directa entre esos dominios.
***
## Representación visual de confianzas
El siguiente esquema conceptualiza lo anterior:
* **Bosque A:** `inlanefreight.local` con subdominios `corp`, `dev`, `admin.dev`, `wh.corp`
* **Bosque B:** `freightlogistics.local` con subdominios `corp`, `dev`, `admin.dev`
* **Confianza bidireccional** entre los dominios raíz de ambos bosques
* **Confianzas internas** entre los dominios secundarios y el dominio raíz
⚠️ Sin una confianza directa entre dos dominios secundarios, no habrá autenticación entre ellos aunque exista una relación de confianza en el nivel superior. Esto es clave para la evaluación de rutas de ataque y diseño de seguridad.