Active directory #3

1. Implementacion de funcion Active Directory

Antes que nada tenemos que asegurarnos que nuestro trabajo anterior (el de los DNS ) este correcto.

Para eso vamos a la powershell y ponemos hostname tenemos que ver dc01 luego nslookup y tenemos que poder ver el NS junto con la ip correspondiente. Acto seguido revisamomos en nuestra configuracion de red en cmd ncpa.clp tengamos como DNS primario nuestra propia IP. Ya que el DC actua como servidor y cliente del servicio DNS.

El operativo Windows server tiene funciones y caracteristicas.

Las funciones son servicios principales. Mientras que las caracteristicas no son tan importantes, mas bien complementan a las funciones.

El Active directory es una funcion.

1.1 Como implementar AD?

1. Desde el Dashboard vamos a manage y le damos click en add roles and features.
2. Se nos abre el asistente
   • next
   • Le damos a la primera opcion, funciones y caracteristicas
   • Elegimos nuestro DC como destino.
   • Activamos Active Directory Domain Services o servicios de directorio activo.
   • next
   • next
   • next
   • Install
3. Cuando termina la instalacion veremos en el Dashboard un signo de admiracion. Lo que se nos notifica es que tenemos que tenemos que promover el controlador a servidor de dominio.
4. Le damos click y se nos abre el asistente.
5. En este punto se nos presentan 3 opciones, cada una de ellas tiene un diagrama, la primer opcion nos pregunta si queremos agregar al controlador de dominio a un dominio existente.

1.2 Add domain controller to a existing domain

Esto en realidad lo que esta planteando es que ya habiendo existiendo un DC queremos agregar otro, si hay uno antes, este seria el segundo.

Porque nos ofrece esto ? esto es conocido como best practice o una recomendacion. Lo que estamos haciendo es una replica. Esto es conocido en el escenario de AD como una operacion de controladores de domino multi maestra/multi master. Cuando realicemos un cambio este se replicara exactamente en el otro DC, independientemente de en cual lo hagamos.

1.3 Que logramos haciendo una replica multi master?

Logramos obtener algo conocido como un DRP(Disaster Recovery Plan o Plan de Recuperacion de Desastre).

En el caso de que alguno de los dos le pase algo, aun tendremos el otro como una copia exacta y funcional.

Microsoft nos recomienda que al tener un DC tengamos otro. Ganamos asi :

• Alta disponibilidad.
• Recuperacion de Desastres.

1.4 Add a new domain to an existing forest

Lo primero que nos pregunta es que tipo de dominio vamos a agregar:

• child domain:
  • Si elegimos este,nos preguntara por el nombre del padre.
• tree domain:
  • Si este nos pregunta por el nombre del bosque.

Cuando elegimos la opcion child domain tenemos que tener antes un DC(DC01) conocido como forest root domain (FRM). Es el primer dominio que se monta en todo el bosque.Luego se ira escalando.

Entonces el child domain sera otro DC(DC02), estos al igual que el tree domain estan vinculados por una relacion de confianza ademas de eso, comparten el nombre. dc01 -> cetec.local | dc02 -> tech.cetec.local, en otras palabras el DC02 tiene el nombre FQDN donde tech es el netbios. Mientras que el el root domain (dc01) cetec es el netbios y cetec.local el FQDN.

La opcion tree domain nos va a servir para cuando una empresa se une a otra y comparten relacion de confianza entre ellas (las fusionamos). Lo que significa que comparten sus bases de datos y otros servicios.Sin embargo vamos a mantener los nombre originales de cada una, Por ejemplo el DC01 de la empresa1 es cetec.local mientras que la empresa2 el dc03 fcm.local. Como vemos no comparten nombre de dominio.

Otra observacion es que se comunican a traves de una relacion de confianza. Entre quienes? entre el FRD(dc01) y el tree root domain(dc03) que seria el FDR del otro bosque, osea el primero del otro bosque.

Lo que pasa con la opcion a tree domain es que el FRD se expande hacia otro arbol.

Mientras que child domain se expande hacia un arbol propio.

Para comunicar el FDR con el TRD esta red tiene que estar enrutada ya que pueden estar en distintos lugares geograficamente hablando.

Cuando usar child domain?

Cuando tenemos relacion de confianza en comun y sabemos que vamos a heredar los nombres.

Cuando usar tree domain?

Cuando vamos a unirlo con otro arbol, y no necesariamente tienen que compartir el mismo nombre de dominio pero si se comparte la relacion de confianza.

1.5 Add a new forest

Con esta opcion vamos a pasar de tener una PC SA (stand alone) a ser nuestro primero dominio (DC01) El forest root domain (FRD)

Cuando nos pregunte el nombre de nuestro root domain vamos a poner el que ya pensamos en la fase de planeacion y el que usamos para la configuracion de los DNS en la zona directa. o forward lookup zones, entonces podriamos el sufijo de la zona principal del dns: cetec.local

Para entrar al manager de dns por terminal usamos en cmd dnsmgmt.msc la traduccion seria dns magnament y msc es la extension de las consolas de administracion de Microsoft.

En el paso siguiente veremos esto:

Como vemos en la imagen tenemos ya seleccionado el checkbox DNS, esto esta asi porque nosotros en los pasos previos ya habiamos configurado el servidor DNS. Si no lo hubieramos hecho estaria desseleccionado.

En forest funcional level(FFL) tengo que partir en el controlador de dominio con SO mas bajo dentro del bosque. Si me puede llegar de otro lado un dominio con un sistema operativo windows server r2. Elijo esa opcion.

En este ejemplo usaremos la opcion windows server 2016

La opcion Domain functional level (DFL) se refiere al nivel de funcionalidad del dominio que estás creando o modificando. Específicamente, afecta a un solo dominio en el bosque de Active Directory.

Recuerda que, al igual que con el FFL, una vez que elevas el DFL, no puedes revertirlo. Asegúrate de que todos los controladores de dominio en ese dominio sean compatibles con el nivel funcional que elijas.

Te dejo esta lectura adicional sobre niveles funcionales de bosque y dominio.

1.5 Catalogo global - RODC - DRSM

Catalogo global: es un subconjunto de atributos del AD.

Que es un atributo?. Cuando tenemos un AD, internamente en una de sus particiones (son 4 en total) mas Específicamente en el esquema, en esta vamos a encotrar todos los objetos y los atributos.Como el objeto usuario, objeto equipo, objeto grupo. Estos objetos podemos usarlos todas las veces que queramos, asi tendriamos multiples usuarios a partir de la plantilla base users. Cada uno de estos usuario tienen atributos Específicos. Nombre de usuario,area, numero de telefono, miembro de.., etc.

El catalogo global lo que tiene es una replica parcial de esos atributo del directorio. De esta manera al hacerce una consulta el AD responde con un subconjunto de estos atributos, que seran lo mas consultados. Asi las respuestas seran mas optimas.Podriamos pensarlo como un indice.

Si quisieramos editar que atributos se tienen en cuenta, tenemos que acceder a active directory schemma, pero este esta oculto para acceder a el, hacemos lo siguiente.

1. abrimos la powershell y ponemos regsrv32 schmmgmt.dll
2. tipeamos mmc (microsoft magnament console)
3. Vamos a file agregar o remover complemento, elegimos active directory schemma.
4. dentro veremos las clases y objetos, si vemos sus propiedades podremos ver el checkbox replicate this atribute to the global catalog.
5. Para deshabillitar la el ad schemma regsrv32 /u schemmgmt.dll

Cuando realizas cambios en el esquema (schema) de Active Directory, estos cambios se aplican de inmediato y son permanentes, incluso si deshabilitas la extensión del esquema utilizando regsvr32 /u schmmgmt.dll. Deshabilitar la extensión simplemente oculta las herramientas administrativas relacionadas con el esquema en la interfaz gráfica de usuario (GUI) de las herramientas de administración, como el “Active Directory Schema” en el “Active Directory Users and Computers” (ADUC).

La desactivación de la extensión del esquema no revierte los cambios realizados en el esquema de Active Directory. Los cambios persisten independientemente de si la extensión está habilitada o deshabilitada. La extensión simplemente proporciona una interfaz gráfica para ver y modificar el esquema.

Es importante mencionar que realizar cambios en el esquema es una acción significativa que afecta la estructura global de Active Directory. Antes de realizar cambios en el esquema, se recomienda realizar copias de seguridad y realizar pruebas en un entorno de laboratorio para comprender completamente el impacto de los cambios planificados. Además, modificar el esquema generalmente requiere privilegios elevados y debe realizarse con precaución.

1.5 RODC (controladores de dominio solo lectura)

Depende de que exista un controlador de dominio de escritura lectura. Este le enviara una copia al RODC

La replica solo funcionara a los usuarios que yo determine que van a existir en ese controlador de dominio.

Un Read-Only Domain Controller (RODC) es un controlador de dominio en un entorno de Active Directory que tiene una función específica: proporcionar servicios de autenticación y autorización en sitios remotos o en ubicaciones con baja seguridad. A diferencia de un controlador de dominio estándar, un RODC tiene algunas características y restricciones particulares:

1. Sólo lectura:

   • Como su nombre indica, un RODC es solo lectura. No almacena ni permite realizar modificaciones directas a la base de datos de Active Directory. Todas las actualizaciones se originan desde un controlador de dominio de escritura en la red.

2. Caché de contraseña:

   • Almacena en caché contraseñas de usuarios y grupos para proporcionar autenticación en caso de pérdida de la conectividad con un controlador de dominio de escritura. Esta caché ayuda a reducir la exposición de las contraseñas en ubicaciones remotas.

3. No almacena todas las contraseñas:

   • Un RODC no almacena todas las contraseñas de usuarios; solo almacena las contraseñas de los usuarios y grupos que se han configurado previamente para replicación en el RODC.

4. Control de acceso mejorado:

   • Proporciona un control de acceso mejorado para minimizar el riesgo en ubicaciones físicamente no seguras. Los administradores pueden especificar qué usuarios y grupos tienen permisos para administrar el RODC.

5. Consulta de catálogo global:

   • Puede responder a consultas de catálogo global para proporcionar información sobre objetos de Active Directory, aunque no tenga la capacidad de realizar modificaciones.

6. Requisitos mínimos de ancho de banda:

   • Diseñado para ubicaciones con ancho de banda limitado, realiza la replicación de datos de forma selectiva para reducir la carga en la red.

En resumen, un RODC almacena información que le permite proporcionar servicios de autenticación y autorización, pero lo hace de manera segura y limitada. Su diseño está orientado a mejorar la seguridad en ubicaciones remotas o no seguras.

Si venis siguiendo los pasos , no vas a poder seleccionar esta opcion de RODC ya que a esta altura solo tenemos un DC y este sera de lectura y escritura, los siguientes si que pueden ser de solo lectura.

1.5 DSRM (Directory Services Restore Mode)

Si tenemos problemas con el AD y reiniciamos al servidor, tocamos f8 veremos la siguiente opcion.

Al darle a directory services repair mode, va a cargar una cuenta administrativa, esa cuenta administrativa va a usar la contraseña DSRM que pusimos antes.

Esta opcion lo que hace es poner la DB del AD (ntds.dit) en modo offline, de esta manera podemos trabajar sobre ella y hacer mantenimiento o arreglarla.

En otras ocaciones podremos trabajar sobre servicios, poniendo de modo offline ese servicio por terminal.

Ya podemos dar a siguiente.

Como ya tenemos configurado nuestro DNS, destildamos el checkbox.

En additional Options solo tenemos que ver el nombre netbios sin un cero al final. Si lo vemos quiere decir que este nombre netbios no es unico.

Damos a siguiente.

Ahora vemos tres rutas:

• Database folder: es la ruta donde va a quedar la db.
• Log files folder: es la ruta donde va a quedar el archivo de log de la db .
• SYSVOL folder: ruta donde va a quedar el volumen del sistema del AD. Este alamacena scripts de inicio de sesion y los archivos de las politicas de grupo.

Podriamos querer tener los logs en un disco y la db en otro, para tener mejor rendimiento , esto en casode que las consultas sean demasiadas y tengamos discos magneticos.

Si fuera que tenemos un ssd podemos dejarlo todo en uno solo, como lo esta por default.

De todas maneras no es obligatorio esto. Podemos tener todo en el mismo disco aunque sea magnetico.

Damos siguiente con todo por default y en la review damos a next.

Una vez pasen los checkeos dame a install y asi nuestra maquina pase de ser un stand alone a un domain controller. El server se reinicia con los nuevos servicios implementados. La primera vez es un poco lento.

Ahora ya veremos que aparece nuestro dominio cetec con el usuario Administrator

Si vamos a manage veremos:

• AD Administrative center.
• AD domain and trusts: nos permite analizar y crear relaciones de confianza entre dominios.
• AD module for windows powershell.
• AD Sites and services:nos permite trabajar con todos los sitios y procesos de replicacion, conectores de replicacion, enlaces,etc.
• AD users and computers: nos permite trabajar con grupos, usarios , unidades organizativas,etc.
• ADSI edit:permite hacer ediciones en diferentes objetos ya creados del AD.
• Group policy management: nos permite manejar las politicas de los grupos.

A partir de aca , ya esta funcional para produccion, pero tenemos que analizar el tener DRP, ver de crear dominios hijos, etc.

Revisemos mas en detalle estas herramientas que nos trajo la instlacion del AD.

1. Active directory - domain and trust

Nos mostrara las relaciones de confianza que se hayan creado de manera automatica como las relaciones de confianza que creemos de manera manual.

2. Module for windows powershell

Es una terminal que nos permite realizar tareas administratifas referente con el AD.

Por ejemplo Get-ADuser -Filter * -SearchBase "ruta LDAP"

LDAP (Lightweight Directory Access Protocol / (Protocolo Ligero de Acceso a Directorios)

LDAP maneja el puerto 389

Internamente los objetos del AD tienen una sintaxis LDAP dn="" dc=cetec,dc=local Internamente este componente de domninio es reconocido de esa manera.

• dn es distinguished name
• cn es component name

Entonces si quiero hacer una busqueda de todos los usuarios de mi dominio tenemos que hacer: Get-ADuser -Filter * -SearchBase "dc=cetec,dc=local"

3. Sites and services

Nos permite trabajar sitios y replicacion, podemos reflejar nuestra parte fisica a traves de subredes.

4. Ad users and computers.

• Builtin

Vamos a encontrar grupos ya incorporados los cuales tienen tareas predeterminadas.

Cuando queremos que un usurio realice cierta tarea , lo agregamos al grupo correspondiente.

• Computers

Toda maquina que se una al dominio, automaticamente su cuenta queda en este contenedor.

Esto podemos configurarlo para que no se creen automaticamente, porque no lo haria? porque yo quiero que queden en una unidada organizativa a la cual le voy a aplicar unas politicas de grupo exclusivas a todas aquellas maquinas que de unan por primera vez.

• Domain controllers

Esta es una unidad organizativa. tiene los controladores de dominio que tengo en mi dominio.con esto ya estamos identificando cuales son los controladores de dominio que hemos implementado.

• Foreing security principals

Aca vemos las cuentas que pertenecen a otro dominio pero que tenemos vinculadas a travez de relacion de confianza con otros arboles.

• Managed service accounts

Maneja las cuentas de usuarios que se utilizan para hacer funcionar a los diferentes servicios que corren en el servidor, estas cuentas no tienen que ser usadas por usurios finales ni cambiar sus contraseñas a mano. Sus contraseñas por default se revalidan y cambian cada 30 dias contra el servicio. Los servicios podemos verlos en cmd > services.msc. Si se presentase el caso de quen alguien cambio la password de manera manual, hay q ir al servicio > porpiedades y cambiar el password manualmente. De no ser asi el servicios no volvera a funcionar.

• Users

Tenemos grupos creados adicionales y usuarios como Administrator.

• ADSI

Sirve para editar el AD, podemos ver y cambiar atributos especificos.

Se usa en casos muy especiales y para cambios muy especiales.

2.1 Componente motor ESE

El AD maneja una db y esa db usa un moto llamado ESE(extensible storage engine)

2.1 Ubicacion

c://windows/NTDS ahi dentro tenemos los archivos encargados de trabajar con el motor ESE.Cada uno tiene su funcion especifica.

• edb.chk

Archivo de punto de control, es el encargado de verificar que lo cambios se les haga un commit a la DB.

Es un puntero en la secuencia de los logs de transacciones que mantienen estado entre la memoria y el archivo de la DB que esta en el disco.

El archivo “edb.chk” se asocia comúnmente con Microsoft Exchange Server, un servidor de correo y colaboración. Sin embargo, no es un archivo que deba ser manipulado manualmente, ya que forma parte del funcionamiento interno de la base de datos de Exchange. El archivo “edb.chk” es un archivo de verificación de integridad que se utiliza para ayudar a mantener la integridad de las bases de datos de Exchange.

A continuación, algunas características clave relacionadas con el archivo “edb.chk”:

1. Integridad de la Base de Datos:

   • El archivo “edb.chk” se utiliza para verificar y mantener la integridad de las bases de datos de Exchange. Es parte del mecanismo que garantiza que la base de datos esté en un estado coherente y sin corrupciones.

2. Exchange Database (EDB):

   • El archivo principal asociado con las bases de datos de Exchange es el archivo de base de datos EDB (por ejemplo, “priv1.edb” para buzones de correo privados). El archivo “edb.chk” trabaja junto con los archivos EDB para garantizar la consistencia de la base de datos.

3. No Manipulación Manual:

   • A menos que seas un administrador de Exchange con un conocimiento profundo del sistema y estés siguiendo procedimientos específicos de recuperación, no se recomienda manipular manualmente el archivo “edb.chk” ni realizar cambios en los archivos de base de datos de Exchange.

4. Funcionamiento Interno de Exchange:

   • Los archivos de verificación de integridad, como “edb.chk”, son parte de la estructura interna de Exchange para asegurar la integridad y la consistencia de los datos. Estos archivos son gestionados automáticamente por el sistema y suelen requerir intervención manual solo en situaciones de recuperación o reparación.

• edb.log

Aca estan los logs de las operaciones realizadas por el motor.

• edb00001.jrs

Son archivos de reserva para que cuando la particion o el volumen donde esta la DB se quede sin espacio y el motor no pueda seguir trabajando sobre los logs, en ese caso va a tener que detener el servicio,pero los motores siempre buscan hacer un detenido limpio clean shutdown, haciendo un rollback transaction, y para eso necestia espacio, este archivo le da el espacio necesario para deternerse de manera correcta.

• edbtmp.log

Los los se van escribiendo ahi y luego se convierte en el archivo de log original.

• ntds.dit (nt directory services . directory information tree )

Es la base de datos como tal.

• ntds.jfm

Es conocido como un archivo de mapa de descargas, se usa para darle un nivel mas de proteccion contra escrituras perdidas sobre las bases de datos.

Esto pasa cuando le llega el mensaje al motor de que algo se agrego correctamente a al db pero esto nunca sucedio.

• temp.edb

Es una db temporal que se usa como almacen de respaldo para tablas temporales y tambien se usa al momento de la creacion de indices de las db

Todos estos mensionados son administrados por ESE.

3.1 Controlador de dominio replica.

Ahora vamos a iniciar la segunda implementacion de un servidor de dominio.

Hacemos esto para tener un plan DRP(Disaster Recovery Plan) DC01 es DNS de el mismo. El DC02 tambien va a ser DNS de el mismo tambien.

Pero inicialmente sera cliente del controlador de dominio y luego de el mismo.

Si revisamos el AD Users and computers en domain controllers vamos a ver que solo tenemos dc01.

Tenemos que hacer todos los pasos al igual que lo hicimos con dc01 pero poniendo dc02, en ncpa.cpl ponemos ip:192.168.10.101, subred 255.255.255.0, Gateway 192.168.10.1 y en DNS temporalmente ponemos la de dc01 192.168.10.100.

Ahora agregamos dc02 al dominio cetec.local

Nos pide validarnos usamos la credencial de administrator Una vez unidos reniciamos la pc y al iniciar ya podemos logearnos con usuarios de AD.

Probamos la resolucion de nombres con nslookup

Si vamos al dc01 veremos que tenemos a dc02 en computers, ya que es un member server no un domain controller

Esto significa que aun no tenemos un DRP ni una replica del DNS. Ya que no es un controlador de dominio ni es servidor DNS de el mismo (dc02).

Cuando los logeamos por primera vez en dc02 luego de unirnos al dominio tenemos quen poner cetec\administrator ya que al haber una cuenta administrator local, intentara usar la de la maquina en vez la del dominio.

Para corroborar que este todo bien, en la powershell ponemos whoami y tenemos que ver cetec/administrator.

Ahora haremos que dc02 sea un controlador de dominio.

1. En Dashboard > roles y caracteristicas
2. siguiente
3. Implemetacion basa en roles.
4. Seleccionamos el server
5. DNS server y AD
6. Siguiente
7. Install

Lo que vamos a buscar en la replicacion es que las db del dc01 se replique en dc02, recordemos que los DNS con sus zonas estan almacenadas localmente, la idea seria que estas zonas esten almacenadas en las db para que tambien se repliquen en dc02. De esa manera no tenemos que estar a mano creando esas zonas en los DNS de los otros dominios.

Como hacerlo?

Si vamos a las zonas del dc01 y vemos las propiedades , por default veremos que la replicacion no esta integrada. Lo muestra en gris.

Como la integramos?

En las propiedades de la zona directa vamos a:

1. type, click en change.
2. Tildamos store the zone in active directory

Esta opcion estara disponible si el dns server es un controlador de dominio.

Hacemos lo mismo con la zona de reversa.

Si vamos a las propiedades nuevamente de la zona directa, veremos que tenemos activada la replicacion.

Tenemos disponible el boton change este nos pregunta hacia donde queremos replicar la zona.

La opcion por default es que solo se replique en servidores dns que esten en mi dominio cetec.local

Volvemos al dc02 y elegimos la primera opcion, la que agrega un doamin controller aun domino existente. Como dc02 ya esta unido al domino y los DNS estan funcionando, automaticamente rellena los input por nosotros con el dominio cetec.local.

En la siguiente pantalla (domain controller options). Tenemos pre seleccionado DNS server y global catalog.

Ahora RODC podemos activarlo,pero lo dejamos sin tildar.

Siguiente en dns options

En additional options

Tenemso la opcion install from media, esto se usa cuadno el dc01 no tiene conectividad por algun motivo y tenemos exportada la config en algun medio extraible. De esa manera hace la replicacion de manera offine

Como no es nuestro caso la dejamos destildada.

Luego nos pregunta desde donde queremos replicar.Dejamoa por default.

Siguiente e install.

Si todo salio bien , cuando vayamos al dc01 en AD users and computers, el dc02 se cambio automaticamente de computers a domain controllers.

Si vamos al DC02 Y vemos sites and servicse veremos que tenemos dos controladores de dominio.

En este punto podemos decir que tenemos dos controladores de dominio en el mismo dominio (cetec.local).

Pero aun dc02 esta apuntando al dns del dc01, vamos a ncpa.cpl y ponemos como dns primario a si misma, 192.168.1.101 y como secundario al dc01.

Si vamos a las zonas de DC02 veremos que se replicaron, estan igual que dc01

En powershell validamos que dc02 es cliente de si mismo con nslookup tenemos que ver el FQDN de si mismo.

Cuando un usuario se va a autenticar , este nescesita saber quein le ofrece el servicio de kerberos, ldap, global catalog, quien se lo dice? el DNS Porque tiene el registro SRV location. Este tabaja de la mano con el registro tipo A ya que este convierte direcciones netbios a ips.

Con todo esto ya tenemos nuestro DRP.

4.1 Creando Domain child

Ahora que ya tenemos las replicas. Tenemos que comenzar a crear al dominio hijo tech.cetec.local

Comenzamos con dc03 agregando la ip 192.168.1.105 En la zona de DNS este servidor comenzara siendo cliente del DNS de dc01, luego el mismo tendra su propio servidor DNS y aputara a su propia IP como hicimos con dc02.

El siguiente paso es cambiar el nombre de la maquina y el suffijo primario DNS el cual es tech.cetec.local.

Con esto ya sabemos que tech es un dominio hijo de cetec.local.

El FQDN seria dc02.tech.cetec.local

Una vez reiniciamos para ver los cambios de nombre del dc03,vamos a dc01 y verificamos las zonas dns con dnsmgmt.msc y veremos que automaticamente el dns sabe que tech.cetec.local es un hijo.

Volvemos a Dc03 y activamos el AD y los DNS como venimos haciendo hasta ahora en roles y caracteristicas.

Validamos con nslookup que el 1.100 sea el servidor DNS.

Probamos que nosn responde dc01 , dc02, dc03.

Una vez validamos la resolucion de nombres, creamos en dc03 las zonas (directa y reversa).

Cuando nos pregunte le nombre de la zona, tenemos que poner el nombre el cual va a tener el domino,tech.cetec.local

Lo mismo con la de reversa.

Luego promovemos al servidor como controlador de dominio, eso lo vemos en el Dashboard en la alerta de post-deployment.

Elegimos la opcion add a new domain to an existing forest

En Parent name damos a select y ponemos las credenciales del dominio padre cetec\administrador automaticamente nos aparece para elegir al padre cetec.local.

EN new domain name ponemos tech. y le damos a siguiente.

En la siguente pantalla ponemos la contraseña de recuperacion.

y el subsiguiente, veremos que no podemos desactivar la delegacion DNS.

Damos a todo siguiente e install.

Cuando termine se reiniciara y dc03 sera un controlador de dominio.

Si volvemos a dc01 y vemos las zonas, notaremos que tech cambio de color, ahora es un subdominio.

Ahora que nuestro Dc03 es un DC Y DNS volvemos a configurar los dns en ncpa.cpl con su propia ip 105.

Como siempre revisamos con nslookup que tech.cetec.local sea el servidor DNS.

Nos queda ir a la zona directa de Dc03 y hacer la integracion con el AD.

1. En dc01 click derecho propiedades en zona directa.
2. marcamos el checkbox store zone in AD (si es que no esta)
3. Una vez tengamos habilitada la casilla replication elegimos la primera opcion.to all dns servers running on domain controllers in the forest:cetec.local
4. repetimos el proceso en dc03
5. Vamos a dc01 y refrescamos las zonas directas.Veremos que tenemos tech.cetec.local.
6. Lo mismo en Dc03.

Adicionalmente en Dc03 podemos ir a cetec.local y elevar la seguridad de dynamic updates a solo segura. Esto lo que hace es que se registren automaticamente en nuestros dns los equipos que pertenecen al dominio.Lo mismo con tech.cetec.local.

Si nos dirigimos a dc01 y en tools ingresamo a active directory domains and trust y alli veremos la relacion de confianza con tech.cetec.local.

Si vamos cetec.local y vamos a propiedades > trusts veremos que se agrego automaticamente.

Si hacemos lo mismo en dc03 veremos la misma relacion de confianza, pero de tipo parent.

OJO! En el dominio raiz cetec.local el administrator pertenece a enterprise admin y schemma admin este tiene la potestad de crear usuarios entre otras cosas en los dc hijos, pero los hijos no pueden manipular al dc root.

Vamos al dc01 y entramos a users and computers podemos usar el shortcut dsa.msc

Dentro de users verem os los grupos enterprise admin y schema admins . Quien pertenezca a estos dos grupos podra administrarse tanto a si mismo como a los dominios del bosque.

Si revisamos lo mismo en dc03 veremos que hay menos grupos, no esta ni enterprise admin ni schema admin

Podemos validar esto desde Dc01, entrando a domain and trusts , seleccionamos tech.cetec.local click derecho > manage y abre el ad de dc03.tech.cetec.local pero con las credenciales de dc01 , ahi podemos ir a users y crear un nuevo usuario.

Si hacemos el mismo proceso desde dc03 veremos que al momento de crear un nuevo usuario no tenemos la opcion para realizar esta opcion.Esto es correcto.

4.2 Testeando relacion de confianza.

1. Creamos un usuario comun en el AD del Dc01.
2. Hacemos lo mismo en Dc02
3. Creamos una carpeta en el DISCO C , en cada servidor.
4. En dc01 damos click derecho en la carpeta que creamos luego propiedades > seguridad y agregamos al usuario que creamos en Dc02. Presta atencion que hay un input que dice : from this location ahi tenes que poner el servidor hijo, asi encuentra al usuario en ese servidor.
5. Lo mismo en dc02.

Si todo sale bien sin errores y logramos agregar a los usuarios de manera cruzada sobre la carpeta. quiere decir que las relaciones de confianza y los dns estan funcionando correctamente.

4.3 Agregando maquina cliente a cetec.local

1. ncpa.cpl ponemos la ip con el dns del dc01
2. Configuramos el FQDN contra cetec.local
3. reiniciamos la pc
4. Agregamos la pc al dominio cetec.local

Por defecto se agregara la maquina cliente en dc01 en computers. Pero si quiero que las pc recien unidas al dominio se inserten en otro grupo oganizacional lo hacemos de la siguiente manera:

1. Abrimos el AD
2. Sobre cetec.local click derecho.
3. new > organizational unit
4. Ponemos el nombre, en este ejemplo EPE(Equipos Por Estandarizar) esto nos sirve para poner unas GPO especiales a las maquinas recien unidas.
5. Vamos al powershell y ponemos redircmp "ou=epe,dc=cetec,dc=local" este es el distinguished name de la OU donde mis equipos nuevos se agregaran.

Si agregamos al dominio ahora una pc , ya no estara en computers sino en EPE.

En el primer reinicio del cliente podemos probar ingresar con la cuenta adminsitrator asi : CETEC\administrator de esta manera tendremos el primer inicio hacia nuestro dominio raiz.

1. vamos al cmd
2. whoami
3. `cetec\administrador

Ahora veremos como usar la relacion de confianza entre el padre y el hijo desde la maquina cliente.

Tenemos dos maneras de validarnos.

1. dominio\usurio => CETEC\Administrator.
2. UPN (User Principal Name) => usuario@domino -> username@cetec.local
3. Para logearme en el dominio hijo -> username@tech.cetec.local

Como tenemos relacion de confianza entre el DC padre y el hijo podemos logearnos con el usuario del subdominio, aunque la pc cliente esta directamente unida a cetec.local.

Si hacemos ipconfig /all veremos el sufijo primario a cetec.local

Advertencia desde aca los pasos de replicacion no funcionan correctametne por lo que no acosejo serguir los pasos de Tree domain La prueba fue realizada con windows server 2019 datacenter y standar en ambos casos las replicas en dc01 nunca funcionaron.

5.1 DC04

Ahora crearemos el otro arbol:

1. ncpa.cpl

   • 192.168.1.115

   • 255.255.255.0

   • 192.168.1.1

   • 192.168.1.100

2. Cambio de netbios: dc04

3. activamos AD.

4. Promovemos al servidor como DC.

5. Elegimos la opcion 2, add to an existing domain.

6. En domain type podemos tree domain

7. En supply the credentials, vamos a change y las agregamos admistrator@cetec.local. debe rellenarce con cetec.local

8. En new domain name ponemos fcm.local

9. En este caso detecta que no tenemos implementado el servidor DNS asi que lo dejamos marcado al igual que el catalogo global.

10. Ponemos la contrasena del restore mode (DSRM)

11. Todo next e install.

12. reiniciar.

5.2 Revisando domain and trusts en dc01

Si vamos a domain and trusts tenemos que ver:

1. cetec.local
2. fcm.local

Uno debajo del otro.

cetec.local
└──
    └── tech.cetec.local
└── fcm.local

Como podemos ver , el subdominio de cetec.local es tech.cetec.local en cambio la unio con el otro arbol los deja al mismo nivel (fcm.local).

Si en cetec.local damos click derecho > propiedades, y vamos a la pestania trusts veremso la relacion de confianza de tipo tree root

5.3 Revisando domain and trust en dc04

Tenems que ver exactamente lo mismo que en Dc01 cuando vayamos a domain and trusts.

5.4 DNS manager en dc04

Si vamos al manager dnsmgmt.msc vamos a ver las replicas de las zonas directas de los demas DC