Servidores Windows

Active Directory, en corto

Lección 6 de 8 · 15 min

El problema que resuelve

Una oficina con quince computadores y sin dominio funciona así: quince equipos con sus propios usuarios y sus propias contraseñas. Cuando entra alguien, hay que crearle cuenta en los equipos que vaya a usar. Cuando se va, hay que acordarse de borrarlas todas.

Active Directory centraliza eso: una identidad, válida en toda la organización. Se da de alta una vez y se da de baja una vez.

Qué gana una empresa con un dominio

Una sola identidad

El usuario entra con las mismas credenciales en cualquier equipo, y los permisos de las carpetas se dan a sus grupos del dominio.

La baja es inmediata y completa: se desactiva la cuenta y se acabó el acceso a todo.

Configuración impuesta

Las directivas de grupo aplican configuración a cientos de equipos: contraseñas, fondo, unidades de red, restricciones.

Se define una vez y se cumple sola en toda la empresa.

Estructura que refleja la empresa

Las unidades organizativas agrupan usuarios y equipos por área o sede.

Y sobre cada una se aplican políticas distintas: contabilidad no necesita lo mismo que el taller.

Cuándo NO hace falta

Esto casi nunca se dice, y es la parte más útil de la lección. Active Directory es una infraestructura seria: hay que mantenerla, respaldarla y protegerla. No toda organización la necesita.

Tres casos donde montar un dominio es un error

Cinco personas y todo en la nube

Si el correo, los archivos y las aplicaciones están en servicios en la nube, la identidad ya está centralizada ahí.

Montar un dominio local añade un servidor que mantener, respaldar y proteger para resolver un problema que ya no tienes.

Equipos que casi nunca pisan la oficina

Un dominio clásico asume equipos en la red local. Con gente trabajando fuera la mayor parte del tiempo, la experiencia empeora: hace falta VPN para cosas que deberían ser simples.

Para ese escenario existen las opciones de identidad en la nube, que están pensadas para eso.

No hay quien lo mantenga

Un dominio mal cuidado -sin copias, sin un segundo controlador, con políticas que nadie revisa- es peor que no tenerlo: es un único punto de fallo del que depende toda la empresa.

Si no hay nadie que se haga cargo, la decisión sensata es no montarlo.

La respuesta honesta suele ser «depende del tamaño y de dónde estén los datos». Con veinte equipos en una oficina, carpetas compartidas locales y alguien que lo administre, un dominio ordena mucho. Con cinco personas y todo en la nube, sobra.

Las cuatro palabras que hay que entender

Si decides montarlo, este es el vocabulario mínimo. Con estas cuatro se entiende cualquier documentación.

Vocabulario de Active Directory

Intenta definirlo antes de voltear.

Montar el primer controlador, en el laboratorio
# 1. Instalar el rol
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

# 2. Crear el bosque y el dominio (reinicia al terminar)
Install-ADDSForest -DomainName "empresa.local" -InstallDns

# 3. Tras el reinicio, comprobar que quedo bien
Get-ADDomain
Get-ADDomainController

Dos reglas que se aprenden caro:

1. Nunca uno solo. Un dominio con un único controlador es un único punto de fallo: si ese servidor muere, nadie puede iniciar sesión en ningún sitio. El segundo controlador no es lujo, es el diseño mínimo.

2. Un controlador de dominio no hace nada más. Nada de servidor web, ni aplicaciones, ni servicios expuestos. Si esa máquina se compromete, se compromete la identidad de toda la empresa.

Crear la estructura y dar de alta usuarios
# Unidad organizativa por area
New-ADOrganizationalUnit -Name "Contabilidad" -Path "DC=empresa,DC=local"

# Usuario dentro de esa unidad
New-ADUser -Name "Julia Gomez" -SamAccountName "jgomez" `
  -Path "OU=Contabilidad,DC=empresa,DC=local" `
  -AccountPassword (Read-Host -AsSecureString) -Enabled $true

# Grupo, y la persona dentro
New-ADGroup -Name "GRP-Contabilidad" -GroupScope Global `
  -Path "OU=Contabilidad,DC=empresa,DC=local"
Add-ADGroupMember -Identity "GRP-Contabilidad" -Members "jgomez"

Fíjate en que vuelve la regla de la lección 4: los permisos se dan al grupo, no a Julia. Con un dominio esto escala de verdad: el mismo grupo sirve para las carpetas, para las impresoras y para las políticas.

Las dos dependencias que rompen un dominio

Cuando Active Directory falla, casi siempre es una de estas dos cosas. Y en los dos casos el mensaje de error no las menciona, que es lo que hace difícil el diagnóstico.

DNS y la hora

DNS mal configurado

Los equipos encuentran el controlador de dominio preguntando al DNS. Si apuntan al DNS del proveedor de internet en vez de al del dominio, no lo encuentran.

Síntoma: «no se puede contactar con el dominio». Causa: un servidor DNS mal puesto en la tarjeta de red.

La hora desfasada

La autenticación del dominio no tolera más de unos minutos de diferencia entre el equipo y el controlador. Es una protección deliberada contra ataques de repetición.

Síntoma: no puede iniciar sesión, con un error que no habla de la hora por ningún lado.

Cómo se comprueban

nltest /dsgetdc:empresa.local confirma que se encuentra el controlador.

w32tm /query /status muestra la sincronización horaria. Es lo primero que se mira ante un fallo de inicio de sesión.

Preguntas frecuentes

¿Qué nombre le pongo al dominio?

Terminar en .local es lo tradicional y funciona, pero complica la integración con servicios en la nube y con certificados públicos.

Hoy suele recomendarse un subdominio de un dominio que la empresa posea de verdad -por ejemplo ad.miempresa.com-. Y ojo: renombrar un dominio después es doloroso, así que es otra decisión de una sola oportunidad.

Una directiva de grupo no se aplica

Tres causas por orden: está enlazada a la unidad organizativa equivocada, el equipo aún no la ha recibido, o hay otra directiva con más prioridad ganándole.

gpupdate /force la fuerza y gpresult /r dice qué directivas está aplicando de verdad ese equipo.

¿Cómo se respalda un dominio?

Con una copia de estado del sistema del controlador, no copiando archivos sueltos.

Y hay una restauración especial para volver a levantar un dominio entero, que es distinta de restaurar un servidor normal. Si de verdad dependes del dominio, esa restauración hay que haberla ensayado.

Ya uso identidad en la nube, ¿puedo unir las dos?

Sí: existen mecanismos de sincronización que llevan las identidades del dominio local a la nube, y es lo habitual en empresas que tienen ambas.

Añade otra pieza que mantener, así que se monta cuando hace falta de verdad, no por completitud.

Compruébalo tú mismo

Una oficina de cinco personas con todo en la nube te pide montar un dominio. ¿Qué recomiendas?

Un usuario no puede iniciar sesión en el dominio y el error no es claro. ¿Qué compruebas de las primeras cosas?

¿Por qué no instalar un servidor web en el controlador de dominio?

Lo que sigue

La siguiente lección vuelve al trabajo diario: manejar servicios con PowerShell, programar tareas, y leer el Visor de eventos -que es donde está escrito por qué algo dejó de funcionar, incluidos los intentos de inicio de sesión fallidos-.

Siguiente: Servicios, tareas y registro de eventos

Continuar ← Roles y características