Regreso con gloria: Controladores de Dominio solo lectura (reloaded)

Lo nuevo (nuevo?) de Active Directory en Longhorn Server.

Una de las grandes novedades de Active Directory cuando salió al mercado allá por el año 2000 fue el hecho de que a diferencia de los esquemas anteriores, ahora todos los controladores de dominio serían lectura/escritura. ¿Qué paso entonces con Active Directory de Longhorn Server? ¿Qué es esta suerte de revival? ¡Vuelven los Controladores de dominio solo lectura!

Un poco de historia.

Quienes han usado Windows NT recordarán con nostalgia aquellos tiempos de PDC\BDC, donde solo el PDC era el controlador de dominio que podía convertirse en “originating update” y replicar sus cambios al resto de los BDC, no importa cuantos controladores de dominio hubiese, solo el PDC podía “recibir cambios”, esto era así (entre otras cosas) por que NT no poseía un mecanismo de resolución de conflictos, y así entonces, no había problemas de discrepancias ni conflictos.

Modelo de replicación en NT 4

Con el advenimiento de Active Directory, uno de los grandes cambios fue justamente ese, el cambio en el escenario de replicación pasando de un modelo “single master replication model” a “multimaster replication model” , entonces ahora cualquier controlador de dominio podría convertirse en “originating update” dando así más dinamismo y respondiendo de esta manera a necesidades tales como servicios de directorio mas extensos y esparcidos en geografías distintas.

Modelo de replicación en Active Directory (Windows 2000 y Windows 2003)

El Nuevo Concepto: RODC

En la medida que Active Directory va evolucionando y se va consolidando como el servicio de directorio mas utilizado por las empresas, nuevos desafíos y necesidades aparecen. Por lo tanto, la seguridad reincide en ser uno de los puntos más importantes a considerar hoy en día y donde Active Directory da respuesta.

Un RODC permite a las empresas colocar su Active Directory en sucursales o lugares remotos donde la seguridad física y lógica no pueden ser garantizadas.

Pero entonces, que es un RODC?

Un RODC (Read Only Domain Controller) es un controlador de dominio adicional que mantiene una copia de parte de la base de datos y en modo solo lectura de Active Directory para su dominio y esta diseñado para ser implementado en sucursales, Las sucursales normalmente tienen pocos usuarios, relativamente poco ancho de banda y profesionales con pocos conocimientos técnicos.

Modelo de replicación de RODC en Active Directory Longhorn Server

Características de un RODC

Tal como hemos visto un RODC puede solucionar muchos de los desafíos planteados en escenarios con sucursales debido a la falta de seguridad, ancho de banda y experiencia técnica. Las principales características de un RODC son

• Replicación Unidireccional
• Base de datos de Active Directory solo lectura
• Cacheo de Credenciales

Replicación Unidireccional

Al no haber cambios directamente hechos en los RODC no hay replicación en dirección a los DC normales (RWDC) esto reduce el esfuerzo de los DC/BHS en la coordinación/sincronización de la replicación inter-sitios.

La replicación RODC aplica tanto a la base de Active Directory como al sistema de archivos distribuidos (DFS).

Base de Datos de Active Directory Solo Lectura

Los RODC contienen todos los objetos y atributos que posee un DC normal, pero los clientes no pueden escribir cambios directamente en un RODC. Esto significa que los cambios mal intencionados hechos en una sucursal no podrán corromper las bases del árbol/dominio de Active Directory. Las aplicaciones que necesiten lectura LDAP podrán hacerlo mientras que las que requieran operaciones de escrituras serán desviadas a la locación central donde el personal especializado determinara quien y bajo que condiciones podrá escribir en Active Directory.

Almacenamiento temporal (Cache) de Credenciales

El Almacenamiento temporal de credenciales es el proceso por el cual se almacenan las credenciales de usuarios y/o computadoras. La credencial se compone de un pequeño conjunto de aproximadamente 10 passwords que están asociadas a un security principal. De manera predeterminada un RODC no almacena estas credenciales, excepto para su propia cuenta y para una cuenta krbtgt para ese RODC, En caso de ser necesario el administrador debe especificar explícitamente que otro security principal almacenar.

El RODC es anunciado en su propio sitio como el Key Distribution Center (KDC) para ese sitio. Tal como dijimos antes el RODC usa una cuenta krbtgt y password distintas que un KDC en un DC normal usa cuando este firma o encripta un TGT, por lo tanto este procedimiento brinda aislamiento criptográfico entre DCs en diferentes sitios evitando de esta manera que un RODC dé tickets en otras sucursales ó incluso en el sitio central.

El RWDC reconoce que el pedido viene de un RODC justamente por el uso de la cuenta krbtgt especial, la política de replicación de passwords determinará si las credenciales del usuario ó computadora a validar debe ser replicadas desde el RWDC al RODC, si la política lo permite, la credencial será replicada y el RODC podrá seguir autenticando directamente al usuario ó computadora hasta que la credencial cambie.

Limitando la replicación de credenciales explícitamente a los usuarios que residen en esa sucursal para ser autenticados por ese RODC, la posibilidad de exponer credenciales en ese sitio esta limitada a unos pocos usuarios normalmente con pocos privilegios.

Por lo tanto en caso de ser literalmente robado o atacado solo el pequeño subset de usuarios puede ser potencialmente crackeado.

A Considerar

Para implementar RODC se deberá tener en cuenta los siguientes puntos

• Un controlador de dominio corriendo Windows Longhorn Server, este controlador de dominio debe serle PDC emulator de ese dominio a fin de poder crear la cuenta krbtgt del RODC.

• El RODC necesita enviar el pedido de autenticación a un DC corriendo Longhorn Server. La política de replicación de passwords determinara si las credenciales serán replicadas a ese RODC

• El nivel funcional del dominio debe ser al menos Windows 2003 para que la delegación Kerberos pueda ser implementada.

• Aunque no es necesario, es recomendable que el nivel funcional del árbol sea también Windows 2003, de tal manera que la característica de replicación de atributos con multivalor (ejemplo: grupos) sean replicados a nivel de cambio de valor y no todo el atributo completo. Esto proporciona un alto nivel de consistencia en la replicación.

• No esta soportado múltiples RODC para el mismo dominio en el mismo sitio por que los RODC no comparten información entre si. Por ese motivo implementando múltiples RODC podrían significar distintos cacheos para la misma autenticación en un momento dado significando inconsistencias en el inicio de sesión si el vinculo WAN entre el sitio y la central está fuera de línea.

Como se hace un RODC

A continuación se muestra el procedimiento de creación de un RODC. Para ello vamos a necesitar un Active Directory con al menos dos sitios

En el ejemplo vemos el sitio Casa Central y Sucursal Boedo, además existe una subset asociada con cada sitio.

Por otro lado, necesitamos que el modo funcional de dominio sea al menos Windows 2003.

El hecho de cambiar el modo de dominio hace que este cambio sea irreversible y al seleccionar Windows 2003 significa que no deberá haber en ese domino controladores de dominio Windows 2000 o NT.

Creación del RODC

Como cualquier otro DC el proceso se inicia ejecutando dcpromo.exe. La mayor parte del proceso es igual a los anteriores, pero existen nuevas opciones que mostraremos a continuación.

Aquí se indica en que sitio se implementara el RODC, eligiendo Default, el DC se colocará en el sitio correspondiente a la subred según su propia dirección IP.

En la pantalla superior se muestra la opción que define si el DC será RODC. Las demás partes del proceso son idénticas a las anteriores por lo tanto serán omitidas en este articulo.

La propuesta del RODC

• Superficie de ataque reducida en los Controladores de dominio en locaciones inseguras

• De manera predeterminada no hay passwords almacenadas en o replicadas en los RODC.

• Instancia Solo Lectura de la base de datos de dominio

• Server Core + RODC Reduce la superficie de ataque aun mas

• Replicacion unidireccional de AD y FRS\DFSR

• Clave Kerberos separada: el RODC tiene su propia cuenta KDC Krbtgt

• Derechos limitados dentro del servicio de directorio, el RODC no es miembro de “Enterprise DC” o “Domain DC”.

• Implementacion y administracion de sucursales mucho mas facil, simple y segura.

• Replicacion unidireccional hace que esta sea mas simple y concisa

• Es posible delegar la promoción y recuperación de RODCs

• La administracion de los RODCs pueden independizarse del resto de los DCs facilitando la delegación de control del dominio.

• Previene la modificación accidental del dominio.

Las distintas perspectivas

En el caso de que un RODC sea sustraído obtendrán un subconjunto del servicio de directorio para luego intentar trabajar sobre la base, pero del lado del administrador del dominio la situación es diferente y tranquila, veamos :

Perspectiva del atacante

Perspectiva del administrador

Como puede observarse, el administrador puede facilmente resetear las passwords de los usuarios y maquinas almacenados en el RODC faltante e incluso exportarlos a un archive para saber exactamente cuales fueron las cuentas comprometidas, para cuando el atacante obtenga (si lo logra) las passwords de los usuarios del RODC estas serán historia.

Esta característica es una de las tantas que incorporará Longhorn Server cuando salga al mercado. Recién estamos analizando Beta 3,como toda beta, está sujeta a cambios en la medida que vamos probando y sugiriendo opciones. Pero es muy importante el análisis en profundidad en épocas tempranas, el trabajo de los betatesters se vuelve imprescindible a la hora de analizar y evaluar los productos en esta etapa.

Solo resta esperar al lanzamiento de Longhorn Server y ver como se comporta esta característica en escenarios productivos, pero estoy seguro que la implementación de RODC redundará en la seguridad de uno de los puntos clave de la seguridad de, tal vez, una de las partes mas sensibles de toda empresa, su servicio de directorio, justamente por lo critico de su contenido.

Comments

• Anonymous
  January 01, 2003
  Hoy en cosas interesantes: De Notes a Sharepoint 2007 y Exchange 2007, Pack Intaller Beta 2 para VS 2005,

• Anonymous
  January 01, 2003
  Aproposito de CAPA8. tengo algunas dudas. 1.- No me queda claro porque se toma la decicion de usar 3 dominios, capa8.local, ar.capa8.local, cl.capa8.local no hubiera sido mejor uno solo capa8.local, que ocurre cuando alguien de Chile (CL), va a argentina y quiere logiarse en Dominio AR.? No genera este modelo mas trabajo a la gente de TI, y se duplica el hardware subiendo los costos. - Como seria las relaciones de confianza entre estos dominios. 2.- DNS, no me queda claro el modelo de alta disponibilidad y replicacion de DNS y la salida a internet, BA. Principal, Cor. Secundario. de Principal. CL. Principal, estas replicaciones multisitios. no aumentan el uso de los enlaces WAN. No seria mejor en Chile tener dos DNS intregrados con AD. para que resulvan entre ellos y un forwarding a el DNS de argentina y de este un formwarding al ISP. lo mismo con cordoba. stgo.cl.latam.capa8.local--consulta--->cl.latam.capa8.local---->router---->DNS ar.capa8.local----->firewall---->DNS ISP. o un modelo maestro, con delegacion no me queda muy claro cual seria el mejor y como seria el esquema. 3.- DHCP no seria mejor el modelo 80/20 dentro del mismo sitio. que ocurrio con la instalacion en Chile.(hubieron problemas con DNS y el DHCP no se implenmento y se hiso DCPROMO antes de configurar los DNS que es una buena practica.) diagrama tu antes hacias un resumen de cada sesion que era muy bueno. 4.- como seria la configuracion del dns, para compatbilisar con el dns de internet. 5.- Podrias publicar los Diagramas actualisados, fisicos con tipo de enlace subredes MPLM  y logicos. 6.-Podrian hacer un blog como este dedicado exclusivamente a capa8 7.-El video del capitulo del 7 DIC. no esta disponible 8.-Cual fue la nomenclatura que se eligio para los nobres de usuarios maquinas. 9-En el webcast de Respaldo no se vio un modelo de rotacion de cintas. Por favor si me puedes ayudar con estas inquietudes.

• Anonymous
  January 01, 2003
  Intesante que pasa con la integracion con DNS. yo en la sucursal podria tener este DC intregrado con AD. Pero como es solo de lectura. hay cambios en el DNS.