Continuando con la implementación de nuestra infraestructura propuesta de Active Directory en diferentes sitios geográficos, en esa ocasión implementaremos un Controlador de Dominio de Solo Lectura (RODC = Read Only Domain Controller) en un sitio remoto e inseguro
En esta misma nota, además del proceso propiamente dicho de promoción, veremos alguna de sus ventajas importantes, como son la selección de contraseñas a replicar, y cómo proceder en caso de que se comprometa la seguridad de este Controlador de Dominio
Como recordatorio, incluiré nuevamente el diagrama propuesto en la nota inicial de la infraestructura a crear. En esta nota promoveremos a Controlador de Dominio a RODC1, que será un Controlador de Dominio de tipo RODC
Teniendo ya instalado el equipo necesario (RODC1) debemos configurar los parámetros de IPv4 adecuadamente. Como en el caso anterior lo he dejado en grupo de trabajo, sin unirlo al Dominio
De acuerdo a la planificación propuesta, la he configurado de acuerdo a la siguiente figura
Y como siempre para verificar que no exista ningún inconveniente, debemos verificar la resolución de nombres (NSLOOKUP) y la conectividad IP (PING)
Instalaremos el rol Active Directory Domain Services de la forma normal, y sólo mostraré las pantallas correspondientes a la configuración
Recordar que un RODC es sólo un Controlador de Dominio, adicional en un Dominio existente. Debemos seleccionar el mismo (root.guillermod.com.ar), y configurar una cuenta con privilegios suficientes para agregar Controladores de Dominio que debe ser por lo menos Domain Admins
Debemos marcar la opción “Read Only Domain Controller (RODC), podemos observar que usando la dirección IP ha seleccionado automáticamente el Site, y sólo debemos agregar la contraseña correspondiente DSRM
Como supongo que todos sabemos las características principales de un RODC, o recomiendo lean Windows Server 2012: Por Qué un RODC (Read Only Domain Controller) podemos en este momento seleccionar qué grupos tendrán permitida o denegada la replicacion de la contraseña, yo lo dejaré para configurarlo luego de finalizar la instalación. De todas formas creo interesante observen cuáles son los grupo que por omisión están configurados para permitir o denegar
Trabajará unos momentos
Y cuando finalice automáticamente reinciará la máquina
Luego del reinicio podremos iniciar sesión con un administrador del Dominio
Desde DC1 o DC2 podremos ver que se ha creado la cuenta de RODC1, y que está identificada justamente como RODC
Si abrimos “Active Directory Sites and Services” podremos ver RODC1 está recibiendo replicación desde DC2
Es interesante verificar que ningún otro Controlador de Dominio está recibiendo replicación desde RODC1. Es el comportamiento esperado, ya que ningún Controlador de Dominio debe crear Objetos Conexión desde un RODC. Un RODC nunca replica hacia otro Controlador de Dominio
Si en RODC1 abrimos “Active Directory Users and Computers” podemos observar que por omisión se conecta a un Controlador de Dominio que no sea RODC
Veamos qué sucede si forzamos que la conexión de la consola se haga a RODC1
Avisa …
Por ejemplo, observen que no aparece la opción “New”
Inclusive si abren las propiedades de un usuario, por ejemplo, verán que no pueden modificar ningún atributo
Siguiendo en RODC1 observemos en la consola DNS, que a diferencia de otros Controladores de Dominio, con el servicio DNS, el registro SOA no apunta a sí mismo, lo cual es totalmente lógico ya que en un RODC no se pueden hacer cambios
También podemos verificar que todas las opciones de cambio en DNS están deshabilitadas
Llegados a este punto, vamos a ver cómo configurar la replicación de contraseñas hacia un RODC
He creado, para demostrar con un ejemplo, una Unidad Organizativa llamada Cordoba, donde he creado algunos usuarios que se supone trabajarán en el Site Cordoba, y los he incluido en un grupo llamado “Cordoba Users”
El objetivo a conseguir es que solamente las contraseñas correspondientes a estos usuarios queden almacenadas en RODC1
Entonces ingresemos a las propiedades de RODC1
Y vayamos a la ficha “Passord Replication Policy”. Observen los grupos y permisos por omisión. Como queremos que los usuarios del grupo “Cordoba Users” tengan las contraseñas replicadas en el RODC, ingresamos por el botón “Add”
Elejimos que al grupo que seleccionemos se permitirá la replicación
Seleccionamos el grupo correspondiente
Observemos que aparece el grupo, pero en lugar de aceptar (Ok) seleccionemos solamente aplicar (Apply) para seguir adelante
Entrando por el botón “Advanced” podemos ver qué contraseñas han sido replicadas a RODC1, solamente la cuenta propia de la máquina, y una cuenta especial de Kerberos que es diferente a la que usan el resto de los Controladores de Dominio del Dominio
A medida que los usuarios pertencientes a “Cordoba Users” inicien sesión en alguna máquina del Site Cordoba, comenzarán a “cacharse” sus respectivas contraseñas si está permitido; pero podemos, si lo deseamos, adelantarnos y en este momento enviar dichas contraseñas, por lo que ingresamos por “Prepopulate Passwords”
Seleccionamos los usuarios, no se puede por grupo 🙁
Lean el aviso que es importante. No sólo hay que replicar las contraseñas de cuentas de usuario sino además las de las máquinas correspondientes (procedimiento análogo pero con cuentas de máquina)
En la siguiente captura me equivoqué por apurado 🙁
Si observan la verán que informa que la operación no se completó. Se soluciona esperando sólo unos minutos para que se creen correctamente los Objetos Conexión y se pudiera replicar la información. Y por no mirar atentamente, pasé de largo y no capturé la pantalla correcta. Es sólo esperar unos minutos y repetir el proceso que finalizó correctamente, aunque la captura muestre lo contrario
Cuando todo está bien y se puede replicar, se verá lo siguiente
Y finalmente quedará así
Veamos ahora cómo proceder, si por cualquier motivo ha sido comprometida la seguridad de RODC1
Atención antes de proceder a estos pasos. Estas demostraciones yo las estoy haciendo con máquinas virtuales, por lo tanto haré un “snapshot” de *todos* los Controladores de Dominio instalados, congelando el estado actual, y luego de demostrar esto volveré todo atrás y lo dejaré tal cual está actualmente. Si lo estuvieran haciendo con máquinas reales, no hay forma de congelar estado.
Recordemos que Windows Server 2012 admite el uso de “snapshots” a diferencia de todas las versiones anteriores donde podíamos provocar fallas importantes.
Lo primero que debemos hacer es eliminar la cuenta de máquina correspondiente, y averiguar qué contraseñas han sido comprometidas, para lo más pronto posible, obligar cambiarlas
Esto es muy fácil y rápido de obtener. Comencemos eliminando la cuenta de RODC1
Confirmemos que es lo que realmente queremos hacer
Observen que el sistema automáticamente me ofrece “resetear” las contraseñas replicadas en RODC1. Y si ingresamos por el botón “View list …” podemos ver de qué cuentas se trata
Si queremos guardar una copia de las mismas simplemente seleccionemos dónde y en qué archivo guardar la información
Confirmamos una vez más …
No podrán alegar que el sistema no se aseguró que era lo que realmente deseaban hacer 🙂
Y ahora si, no hay vuelta atrás, no está más RODC1
Por si alguien tiene dudas: las cuentas no las borró
Y como pedimos, nos ha quedado el archivo (.CSV) con la información de las cuentas comprometidas
Esta vez llegamos hasta acá. En la próxima nota comenzaremos con la creación del subdominio del Site Mendoza (mza.root.guillermod.com.ar) en “Instalación de Active Directory – Promoción del Primer Controlador de Dominio de un Site Remoto (Mza) – Nota VII"
