materials

Active Directory

Introducción

El nombre que da Microsoft al servicio de directorio es Active Directory y, al igual que los usados en GNU/Linux, sigue el estándar LDAP (Lightweight Directory Access Protocolo, protocolo ligero de acceso al directorio).

Para tener un directorio en una red Windows necesitaremos un servidor con un sistema operativo Windows Server en el que instalaremos el rol de “Servicios de dominio de Active Directory” que lo convertirá a dicho servidor en un Controlador de Dominio (DC, Domain Controller). En cada dominio Active Directory habrá al menos un controlador de dominio, pero pueden haber más. Antiguamente el primer DC se llamaba controlador de dominio principal (PDC, Primary Domain Controller) y era el único que podía hacer cambios en el dominio. Los otros tenían copias del directorio, y se llamaban BDC (Backup Domain Controllers). En la actualidad todos los DC son iguales y pueden hacer cambios en el dominio.

Si en una red montamos un dominio Active Directory se necesitará un servidor DNS que resuelva dicho dominio para los equipos de la red. Si no hay ninguno al instalar Active Directory en el servidor se instalará el servicio DNS y se configurará automáticamente para poder responder al nombre del servidor y del dominio.

Notación de los objetos del Active Directory

Como hemos visto todos los objetos de AD (usuarios, equipos, grupos, …) tienen un identificador único que es su DN (Distinguished Name). Podemos verlos con los cmdlets Get-ADUser, Get-ADComputer, Get-ADGroup, etc:

Get-ADUser

Get-ADComputer

Get-ADGroup

Como vemos, además del DN cada objeto tiene un SID (Security IDentifier) que también és único. Este SID esta formado por 3 partes:

Este es el identificador que usa internamente Microsoft para identificar los objetos y por eso, en ocasiones, al mirar los permisos de una carpeta vemos un SID en lugar de un nombre de usuario o grupo (siempre lo traduce pero a veces tarda un instante, o no puede).

Añadir más DC a un dominio

El DC es un equipo crítico en nuestra red por lo que es una buena idea que sea tolerante a fallos. Esto se consigue muy fácilmente añadiendo a la red un segundo DC.

La principal función de un DC es autenticar a los usuarios y en ese proceso intervienen varios elementos:

El GC es un repositorio de datos con información (no toda) de cada objeto del dominio. Puede estar en varios DC y se utiliza en el inicio de sesión y en las búsquedas en el dominio (Más información: Microsoft).

La opción por defecto al promover un servidor a DC es que se instale en el mismo el GC y también el servicio DNS. También al promover un servidor a DC de un dominio ya existente.

Por tanto para tener tolerancia a fallos respecto al DC en nuestra red debemos hacer que los 2 DC tengan el GC y el servicio DNS y configurar en todos los clientes como DNS a ambos DC.

NOTA: un usuario puede iniciar sesión aunque no haya disponible ningún DC si ya ha iniciado sesión anteriormente en ese equipo porque el cliente usa siempre en primer lugar las credenciales cacheadas de ese usuario (en su perfil se guarda también su contraseña encriptada de forma que es el propio cliente quien hace la comprobación). Sin embargo no podrá conectarse a ningún recurso de otro equipo porque necesita un ticket Kerberos que sólo proporciona un DC.

IMPORTANTE: un DC sólo debería dedicarse a autenticar usuarios y a servidor DNS. Como mucho le podríamos poner un servicio ligero como DHCP pero no es recomendable que haga también de servidor de ficheros, de impresión o de aplicaciones. Tampoco debería hacer nunca de servidor de comunicaciones ya que contiene información muy importante y no debería estar expuesto a internet sino protegido dentro de la LAN.

Roles FSMO

Si nuestra infraestructura de red consta de un sólo dominio con un único DC su administración es muy sencilla, pero cuando tenemos un bosque con varios dominios y subdominios gestionados por diferentes DC (cada dominio/subdominio debe contar al menos con un DC pero pueden haber más) la cosa puede complicarse.

Por ejemplo podría suceder que dos administradores estén creando simultáneamente 2 subdominios con el mismo nombre. O que en 2 DC se estén creando 2 usuarios y se les esté asignando el mismo identificador (SID) a ambos.

Para solucionar los problemas derivados de la administración distribuida del bosque Microsoft ha definido 5 roles cada uno de los cuales sólo puede ejecutarse en un único DC del bosque llamado Maestro de operaciones único flexible (FSMO). Estos roles son:

Podemos ver qué máquinas ejecutan cada uno de estos roles con el comando:

NETDOM QUERY FSMO

Maestro de Esquema (Schema Master)

Hay 1 por bosque (estará en un DC del dominio raíz). Es el único que puede hacer modificaciones en el esquema de directorio (por ejemplo cambiar el nivel funcional del bosque) y, una vez hechas, las replica al resto de DC.

Maestro de Nombres de Dominios (Domain Naming Master)

También es único en el bosque y su función es garantizar de que los nombres de los Dominios que se agreguen al bosque sean únicos. Es el único que añade o elimina dominios del directorio.

Maestro de ID relativo (Relative IDentifier Master)

Hay 1 maestro por dominio y se encarga de asignar RIDs a los DC de ese dominio. A cada DC le asigna 500 RID (a partir del 1000) y cuando les quedan menos de 50 vuelven a solicitar al RID Master otros 500. Así se asegura de que 2 DC distintos no puedan asignar un mismo RID a 2 objetos.

Emulador del Controlador Principal de Dominio (PDC Emulator)

Antiguamente en cada dominio sólo hablia un DC principal (PDC) y el resto eran DC de backup (BDC). Sólo el PDC podía efectuar cambios en el dominio. Este rol se mantiene por compatibilidad y además se encarga de gestionar el tiempo en el dominio (obtiene la hora de una fuente externa y todos los demás usarán la hora de este DC).

Además tiene otras funciones como procesar los bloqueos de cuenta, recibir los cambios de contraseña de los usuarios o administar los objetos de directiva de grupo (GPO) del dominio.

Maestro de Infraestructura (Infrastructure Master)

Se encarga de actualizar el SID de los objetos al hacer referencia a ellos desde otro dominio.

Podéis ampliar la información en páginas como:

Transferir roles FSMO

Cuando un DC es correctamente degradado sus roles FSMO son asignados automáticamente a otros DC. También puede suceder que se apague el DC correctamente, por ejemplo por mantenimiento programado, y sus roles FSMO sean asignados a otro DC “activo”.

Sin embargo en ocasiones puede ser necesario que un Administrador deba transferir manualmente un rol a otro DC, por ejemplo si el titular del mismo ha dejado de funcionar y se ha degradado con el comando dcpromo /forceremoval. El comando para transferir roles FSMO es

ntdsutil /roles

Podéis ampliar la información en Microsoft: Transferir o aprovechar roles FSMO en servicios de dominio de Active Directory.

This site is open source. Improve this page.