Active Directory

Cada uno de ustedes que está leyendo este libro tendrá un conjunto de habilidades adquiridas
y un nivel de experiencia diferente con el entorno de Windows Server. Como mencioné
anteriormente, ser capaz de hacer que los servidores ejecuten el sistema operativo es
excelente y un paso muy importante para realizar un trabajo real en su entorno. Pero hasta
que no sepas y entiendas cuál es el propósito de los principales roles disponibles para
ejecutarse en Windows Server 2019, lo único que hará tu nuevo servidor será consumir
electricidad.

Un servidor está destinado a servir datos. El tipo de datos que proporciona y con qué
propósito depende completamente de los roles que determines que el servidor debe... bueno...
servir. En consecuencia, debes instalar roles dentro de Windows Server 2019 para que haga
algo. Ya sabemos cómo instalar roles en nuestro servidor, pero no hemos hablado aún de los
propósitos detrás de estos roles. En los próximos capítulos, comenzaremos a examinar lo que
comúnmente me gusta llamar los roles fundamentales de infraestructura disponibles en
Windows Server. Esto incluye discutir el propósito general del rol, así como también incluir
algunas tareas específicas relacionadas con dichos roles que tú serás responsable de realizar
en tus actividades diarias como administrador de servidores.

Comenzamos con el rol más importante de todo el entorno local de Microsoft: Active
Directory (AD), como se le conoce comúnmente. Es un servicio de directorio que funciona
como una especie de base de datos, almacenando y centralizando varios tipos de información
sobre tu organización. Cuentas de usuario, cuentas de computadoras, certificados, políticas e
incluso replicación de archivos son todos elementos que puedes encontrar integrados en AD.

A medida que revisemos las partes y componentes de Active Directory, se volverá más claro
qué información se almacena en él y por qué es tan importante. Si eres nuevo en el área de TI
y aún no tienes un buen dominio de AD, ¡asegúrate de aprender esta tecnología! Active
Directory es el eje sobre el cual gira casi todo en el mundo de Windows Server.
¿Es posible utilizar servidores Windows sin que estén conectados y unidos a Active
Directory?
Sí. ¿Es probable que alguna vez encuentres este escenario en la práctica real?
No.

En este capítulo, aprenderemos lo siguiente:

• ¿Qué es un controlador de dominio?
• Crear tu primer dominio
• Múltiples controladores de dominio para redundancia
• Usuarios y equipos de Active Directory
• Dominios y confianzas de Active Directory
• Sitios y servicios de Active Directory
• Centro de administración de Active Directory
• Controladores de dominio de solo lectura
• Directiva de grupo
¿Qué es un controlador de dominio?

Si vamos a hablar de los servicios de infraestructura fundamentales que necesitas para

construir una red basada en Microsoft, no hay mejor lugar para comenzar que con el
controlador de dominio. Un Controlador de Dominio, comúnmente conocido como DC
(por sus siglas en inglés), es simplemente un servidor que aloja Active Directory. Es un punto
central de contacto, un “centro” por así decirlo, al que se accede antes de casi cualquier
comunicación que tenga lugar entre un cliente y un servidor en tu red.

Quizás la forma más sencilla de describirlo sea como un contenedor de almacenamiento para
toda la identificación que ocurre en la red. Nombres de usuario, contraseñas, cuentas de
computadoras, grupos de computadoras, servidores, grupos y colecciones de servidores,
políticas de seguridad, servicios de replicación de archivos, y muchas otras cosas se
almacenan y se gestionan dentro de los DC.

Si no estás planeando tener un controlador de dominio como uno de los primeros servidores
en tu red centrada en Microsoft, es mejor que ni siquiera empieces a construir esa red. Los
DC son esenciales para la forma en que nuestras computadoras y dispositivos se comunican
entre sí y con la infraestructura de servidores dentro de nuestras empresas.

Servicios de dominio de Active Directory (AD DS)

Si te detuviste en este punto para instalar el rol de Controlador de Dominio en tu servidor,

¡bienvenido de nuevo! En realidad, no existe un rol llamado “Controlador de Dominio”.
El rol que proporciona todas estas capacidades se llama Active Directory Domain Services
(AD DS).
Este es el rol que debes instalar en un servidor. Al instalar este rol, conviertes tu servidor en
un controlador de dominio (Domain Controller).

El propósito de ejecutar un controlador de dominio es, en esencia, crear un directorio o

base de datos de objetos en tu red.
Esta base de datos se conoce como Active Directory, y es una plataforma dentro de la cual se
construye una estructura jerárquica para almacenar objetos, como nombres de usuario,
contraseñas y cuentas de equipos.

Quizás estés pensando: “¿No acabamos de decir eso mismo con otras palabras?”. Y no estás
equivocado. Active Directory es tan importante que es necesario enfatizarlo. Tener una
carrera en el ámbito de TI garantiza que, de alguna forma, vas a interactuar con AD en tu
trabajo.

En la mayoría de los casos, cuando alguien habla de “Active Directory”, probablemente se

está refiriendo a un único dominio dentro del directorio.
Sin embargo, existe toda una jerarquía dentro del esquema de Active Directory,
compuesta por bosques (forests), árboles (trees), dominios (domains) y unidades
organizativas (OUs). Discutiremos cada uno de estos niveles organizativos a medida que
avancemos con las herramientas que usarás para interactuar con AD en este capítulo.

Una vez que has creado un dominio en el cual almacenar cuentas, objetos y dispositivos,
puedes entonces crear cuentas de usuario y contraseñas para que tus empleados las usen
para autenticarse.
Después, puedes unir tus otros servidores y computadoras a ese dominio para que puedan
aceptar y beneficiarse de esas credenciales de usuario.

Tener y pertenecer a un dominio es lo que permite que puedas ir de computadora en

computadora dentro de tu empresa e iniciar sesión en cualquiera de ellas con tu propio
usuario y contraseña, incluso si nunca antes habías usado ese equipo.

Aún más potente es el hecho de que esto permite que las aplicaciones compatibles con
directorios se autentiquen directamente contra Active Directory cuando necesitan
información de autenticación.

Por ejemplo: cuando yo, como usuario del dominio, inicio sesión en mi computadora del
trabajo con mi nombre de usuario y contraseña, el sistema operativo de Windows en mi
equipo se comunica con el controlador de dominio para verificar que mi contraseña sea
correcta.

Una vez que se confirma que realmente soy quien digo ser, se emite un token de
autenticación hacia mi computadora, y se me permite iniciar sesión.
Luego, una vez que ya estoy en el escritorio y abro una aplicación —supongamos que abro
Outlook para acceder a mi correo electrónico— ese programa de correo está diseñado para
contactar a mi servidor de correo, llamado Exchange Server, y autenticarse contra él
para asegurarse de que se muestre mi buzón de correo y no el de otra persona.

¿Significa esto que debo volver a ingresar mi usuario y contraseña para Outlook, o para
cualquier otra aplicación que abra desde mi computadora?
Generalmente no.
Y la razón por la que no necesitas volver a ingresar tus credenciales repetidamente es
porque tu usuario, tu computadora y los servidores de aplicaciones forman parte del
mismo dominio.

Autenticación sin interrupciones gracias a Active Directory

Cuando todos los equipos y servidores forman parte del mismo dominio —como ocurre en la
mayoría de las redes empresariales—, el token de autenticación que se genera al iniciar
sesión puede compartirse entre las aplicaciones.

Esto significa que una vez que inicias sesión en tu computadora, las aplicaciones que
necesitas usar también pueden abrirse y autenticarte automáticamente ante sus
respectivos servidores, sin pedirte nuevamente usuario y contraseña.

👉 Este mecanismo se llama autenticación única o Single Sign-On (SSO).

Permite que, tras una única autenticación inicial, las credenciales se reutilicen de manera
segura para que otras aplicaciones también puedan validarte sin intervención adicional del
usuario.

Imagina lo tedioso que sería si cada vez que abres Outlook, Word, o una aplicación interna de
tu empresa, tuvieras que volver a escribir tu usuario y contraseña. Active Directory elimina
esa fricción mediante la emisión y reutilización del token de autenticación.
Active Directory: una tecnología fundamental

Active Directory es un tema tan amplio y profundo que podría tener su propio libro —y
de hecho, existen muchos dedicados exclusivamente a él—.
Pero con esta explicación ya tienes una base clara de qué es, cómo funciona y por qué es
tan vital en entornos Windows Server.

Ahora, como se indica en el texto, el siguiente paso es aprender a usar las herramientas
que se instalan en el servidor cuando activas el rol de Active Directory Domain Services
(AD DS).
Estas herramientas te permitirán gestionar usuarios, computadoras, políticas de grupo,
unidades organizativas, y más.

Creando tu primer dominio

Debo admitir que he hecho un poco de trampa y ya he estado trabajando dentro de un
dominio con el fin de tomar capturas de pantalla para el libro hasta este punto. Mi laboratorio
de pruebas ya tiene un servidor llamado DC1 en funcionamiento, y en él he configurado un
dominio llamado contoso.local. Sin embargo, decir "los dominios son importantes" y no
mostrarte cómo crear uno no sería útil para ti, el lector, así que ahora vamos a construir un
dominio completamente nuevo, en un servidor completamente nuevo.

Probablemente reconozcas el nombre "Contoso" si alguna vez has leído tutoriales de

Microsoft o documentación de configuración de ejemplo, porque es uno de varios nombres
ficticios de empresas que Microsoft utiliza con frecuencia en su documentación o para
mostrar escenarios de ejemplo. Yo también lo estoy utilizando aquí, pero tú podrías nombrar
tu dominio como quieras. Para configurar nuestro segundo dominio, voy a elegir otro nombre
de empresa del repertorio de Microsoft: Fabrikam.

📌 Uno de los primeros aspectos que se deben decidir antes de poder construir
un dominio es el nombre del dominio.

No queremos profundizar demasiado en el tema de DNS aquí, porque hay otro capítulo
completo dedicado a eso, pero todos usamos DNS todos los días aunque no lo notemos.

Cada vez que escribes el nombre de un sitio web —como microsoft.com, google.com,
bing.com, etc.— estás introduciendo un nombre, que el DNS convierte internamente en una
dirección IP.

También sabes que las terminaciones de los nombres de sitios web pueden tener muchas
formas. La más común es .com, pero también puedes visitar sitios que terminan en .org, .biz,
.info, .tech, .edu, .mil, entre muchos otros.
Tomemos microsoft.com como ejemplo.
Si simplemente visitas microsoft.com, verás la página principal de la compañía.
Si visitas docs.microsoft.com, accederás a su plataforma de documentación.
Al visitar portal.microsoft.com, llegas a una página de inicio de sesión de Office 365, y si
tienes una cuenta de Office 365 puedes iniciar sesión aquí y realizar muchas funciones.

Las diferentes direcciones que escribes en el navegador te llevan a páginas web y sistemas
muy distintos, pero todos terminan con el mismo microsoft.com.
Esto significa que microsoft.com es el nombre de dominio principal para todos estos
servicios, también conocido como sufijo de dominio o dominio de nivel superior (top-level
domain).

¿Por qué me estoy yendo por esta "tangente"?

Porque es información importante que debes entender cuando decidas el nombre de tu

dominio interno.

Así como existe un sufijo de dominio en internet, cuando construyes tu dominio interno y
luego unes computadoras y servidores a ese dominio, cada uno de esos dispositivos tendrá un
nombre completo (FQDN, Fully Qualified Domain Name) del tipo:

nombreDeEquipo.nombreDeDominio.algo

Por ejemplo, en mi dominio actual contoso.local, un nombre completo de servidor que existe
ahora es:
DC1.Contoso.local

¿Qué extensión debería tener tu dominio interno?

La mayoría de dominios internos que he visto en el mundo terminan en .local

¿Es posible nombrar tu dominio interno con un sufijo usado en internet, como
contoso.com?
¡Sí! Puedes nombrar tu dominio interno como quieras, y de hecho, si planeas alojar correos
en Office 365, usar un nombre de dominio interno que coincida con tu dominio público
puede tener algunas ventajas.

Tal vez pienses ahora:

“Yo ya tengo contoso.com (o el nombre real de tu empresa), ¿no sería menos confuso si
también uso ese nombre para el dominio interno?”
La respuesta es sí y no.

 En algunos escenarios con recursos en la nube, como Office 365 o Azure, usar un
dominio interno con terminación .com puede facilitar una transición más fluida hacia
la nube.
  Sin embargo, antes de que existieran estas tecnologías en la nube, la recomendación
de Microsoft era terminar el dominio interno con .local.

Hablaremos más sobre esto en el Capítulo 4, cuando veamos los servicios DNS y DHCP, y
toquemos un concepto llamado "DNS de doble cara" (split-brain DNS).

Prepara tu controlador de dominio

Muy bien, he decidido usar fabrikam.local como el nombre de mi dominio interno.

Ahora, ¿cómo hago eso realidad?

Solo necesitamos un servidor para crear un dominio: el servidor que quieres que sea tu
controlador de dominio.

Tengo una nueva máquina virtual con Windows Server 2019 ejecutándose y conectada a
una red, pero hasta ahora no he configurado nada en ese servidor.

Hay tres cosas simples que deben hacerse en cualquier servidor que planees convertir en un
controlador de dominio:

✅ 1. Asignar una dirección IP estática

Ve a las propiedades de tu tarjeta de red (NIC) y define una dirección IP estática para este
servidor.
Aunque ya tengas un servidor DHCP que esté asignando IPs en tu red, no quieres que los
controladores de dominio cambien de IP nunca.

Es posible hacerlo (cambiar la IP), pero es bastante complicado.

Por eso, la mejor práctica indica que la IP que definas para tu controlador de dominio
(DC), debe ser permanente.

✅ 2. Establecer un buen nombre de host

Al igual que con la IP, no se recomienda cambiar el nombre de un controlador de dominio

una vez configurado.

De hecho, cambiar el nombre del servidor es incluso más complicado que cambiar la IP.
Así que debes asumir que el nombre que le pongas hoy será su nombre para siempre en tu
red, hasta el día en que elimines ese servidor.

✅ 3. Establecer la dirección del servidor DNS

Vuelve a las propiedades de la tarjeta de red (NIC) y configura el servidor DNS que tu
controlador de dominio debe usar.

¿Y cuál es ese DNS? → Él mismo.

¿Él mismo? ¡¿Pero si no es un servidor DNS todavía?!

Aún no lo es, pero en casi todos los casos, un controlador de dominio también será un
servidor DNS.

Esto se debe a que DNS se integra con Active Directory, y tener ambos servicios en el
mismo servidor es muy beneficioso.
Por eso, en la mayoría de entornos de Microsoft, verás que se instalan juntos AD DS y DNS
en los controladores de dominio.

Por lo general, cuando configures tu primer DC, debes poner en los ajustes de DNS de la
NIC la misma IP del servidor.

🔧 En la Figura 3.1 (que no se muestra aquí), el autor ya ha nombrado su servidor como FAB-
DC1, le ha asignado una IP estática y ha configurado el DNS apuntando a sí mismo.