Controlador de dominio: qué es y por qué es el primer objetivo

Qué es un controlador de dominio

Un controlador de dominio (DC) es un servidor Windows que guarda el directorio de un dominio y responde a dos preguntas todo el día: quién eres y qué te dejo hacer. Ese directorio no son solo cuentas de personas: son también los equipos, los grupos, las impresoras, los servicios y las reglas de configuración que se aplican a todos ellos.

Un dominio es el conjunto de recursos que comparten ese directorio y confían en él. Y esa confianza es literal: cuando metes un portátil en el dominio, ese portátil acepta que el controlador de dominio le diga quién puede entrar y con qué permisos. La comodidad de administrar mil equipos desde un sitio y el riesgo de que ese sitio caiga son exactamente la misma propiedad vista de dos maneras.

La tecnología que hay debajo es Active Directory, en su versión de servicios de dominio. En una red con varios controladores, todos replican la misma base de datos, de modo que si uno se cae los demás siguen atendiendo.

Qué hace exactamente

Tres cosas, y conviene separarlas porque cada una se ataca distinto.

• Autenticar. Comprobar que eres quien dices. En un dominio moderno eso lo hace Kerberos, que en vez de andar mandando contraseñas por la red reparte tiques temporales: uno que dice quién eres y otro por cada servicio al que vas a hablar. Detrás sigue existiendo el mecanismo antiguo, NTLM, encendido en muchísimas redes por compatibilidad, y buena parte de los problemas de esta página vienen de ahí.
• Autorizar. Decidir a qué llegas. Se resuelve con los grupos a los que perteneces, y por eso la pertenencia a un grupo es un objetivo en sí misma: no hace falta robarle la contraseña al administrador si te puedes meter en su grupo.
• Aplicar política. Empujar configuración a todos los equipos del dominio, desde el fondo de pantalla hasta qué se puede ejecutar. Es la herramienta más potente de administración que hay en una red Windows, y por lo mismo es un mecanismo de distribución perfecto para quien la controle.

¿Necesitas uno hoy? Dominio, Entra ID e identidad híbrida

Esta es la parte que faltaba en la versión anterior de este artículo, escrita cuando la respuesta parecía obvia. Hoy hay tres escenarios y elegir mal cuesta caro.

• Solo nube. Si tu gente trabaja con portátiles, servicios en la nube y ningún servidor de ficheros ni aplicación antigua, probablemente no necesites un dominio: la identidad vive en Microsoft Entra ID (lo que hasta hace poco se llamaba Azure AD) y los equipos se unen directamente allí. Es lo que suele encajar en una empresa nueva.
• Solo dominio. Sigue teniendo sentido cuando hay que autenticar contra cosas que no hablan protocolos de nube: servidores de ficheros, impresión, aplicaciones internas antiguas, maquinaria, entornos industriales.
• Híbrido. Es lo que nos encontramos en la mayoría de las empresas: dominio local sincronizado con Entra ID para que la gente entre con las mismas credenciales dentro y fuera.

Y aquí está el aviso, porque es el error de diseño que más vemos. Entra ID no es un controlador de dominio en la nube. No es lo mismo ni hace lo mismo, y la sincronización que los une es un puente en los dos sentidos. El servidor que sincroniza las identidades es, en la práctica, tan crítico como un controlador de dominio, y casi nunca se trata como tal: se instala una vez, se olvida y vive con permisos enormes sobre los dos lados. En un entorno híbrido, comprometer el directorio local suele acabar alcanzando el de la nube, y comprometer ciertos roles de la nube suele acabar alcanzando el local.

La otra deuda que arrastran casi todos los híbridos es la autenticación heredada: protocolos antiguos que siguen encendidos, que no admiten segundo factor y que convierten cualquier contraseña filtrada en una entrada directa. Apagarla es la medida más barata con más efecto que existe en este terreno, y es lo primero que miramos en un trabajo de bastionado de Microsoft 365.

Por qué es el primer objetivo de cualquiera que entre en tu red

Cuando entramos en una red interna con permiso del cliente, el guion casi siempre es el mismo: no vamos a por los datos, vamos a por el directorio, porque el directorio da los datos y todo lo demás. Estas son las vías que más veces funcionan, dichas por su nombre y sin receta.

• Contraseñas donde no deberían estar. El volcado de credenciales aprovecha que los sistemas guardan restos de sesiones anteriores. Basta con un equipo donde se conectó una vez alguien con más permisos.
• Kerberos contra sí mismo. El Kerberoasting pide tiques de servicio, que van cifrados con la contraseña de la cuenta que ejecuta ese servicio, y los ataca cómodamente fuera de la red. Funciona cuando esa contraseña es débil o antigua, cosa habitual en cuentas de servicio que nadie toca desde hace años. El AS-REP roasting es la variante para cuentas a las que alguien, en algún momento, les quitó la preautenticación.
• Reutilizar la sesión en vez de la contraseña. Con pass the hash no hace falta conocer la contraseña: basta con el material que el sistema usa para demostrar que la conoces.
• Hacer de intermediario. El NTLM relay coge una autenticación legítima que iba a un sitio y la reenvía a otro. No rompe nada criptográfico: aprovecha que la red deja hablar a máquinas que no deberían hablarse.
• La autoridad de certificación de la que nadie se acuerda. El abuso de AD CS es hoy uno de los caminos más rentables: una plantilla de certificado mal configurada permite pedir un certificado a nombre de otro, y con él autenticarse como esa persona. Suele estar montada desde hace diez años y no aparece en ningún inventario.
• Y el final del camino. Cuando alguien alcanza cierta cuenta del dominio puede fabricarse tiques válidos por su cuenta: es el golden ticket. A partir de ahí no se trata de un atacante con acceso, sino de un atacante que emite identidades. Recuperarse de eso no es cambiar una contraseña.

Ninguna de estas seis vías es una vulnerabilidad con parche. Todas son configuración, herencia y permisos acumulados. Por eso un escáner no las encuentra y por eso siguen funcionando en 2026 igual que hace diez años.

Cómo se comprueba si el tuyo aguanta

La forma barata de engañarse es mirar la lista de administradores del dominio, ver que son cuatro y quedarse tranquilo. Lo que importa no es quién es administrador, sino quién puede llegar a serlo encadenando permisos que uno a uno parecen inofensivos. Eso no se ve leyendo: se ve recorriéndolo.

• Un pentest de red interna arranca desde dentro, con o sin credenciales, y responde a hasta dónde llega alguien que ya entró. Es el ejercicio que encuentra las seis vías de arriba. Si quieres ver cómo se hace, lo contamos paso a paso en cómo funciona un pentest de red interna.
• Un ejercicio de red team responde a la otra mitad, que casi nadie mide: si alguien se entera mientras ocurre. Se puede tener un directorio razonablemente sano y aun así no ver a nadie moverse por él durante semanas.
• Y si tu entorno es híbrido, la revisión no termina en el dominio: el bastionado de Microsoft 365 mira el otro lado del puente, que es por donde entra hoy la mayoría de las intrusiones que empiezan con una credencial válida.

Qué hacer con esto

Si administras un dominio, hay tres cosas que puedes mirar esta semana sin contratar a nadie y que cierran una parte notable de lo anterior. Primero, las cuentas de servicio: cuáles tienen contraseñas de hace años y cuáles tienen más permisos de los que necesitan para su tarea. Segundo, la autenticación heredada: qué protocolos antiguos siguen encendidos y quién los usa de verdad. Tercero, tu autoridad de certificación, si la tienes: quién puede pedir certificados y a nombre de quién.

Y una cuarta que no es técnica: comprueba si sabrías responder a la pregunta "¿qué hacemos si el controlador de dominio deja de ser nuestro?". No es una pregunta retórica. Es un plan que hay que tener escrito antes, porque el día que hace falta ya no hay directorio en el que apoyarse para escribirlo.

Última revisión: 3 de agosto de 2026. Publicada originalmente el 19 de noviembre de 2023.