Controladores de dominio de Windows Server 2008 R2: Planificación cuidadosa de los controladores de dominio de sólo lectura (RODC)
Paul Yu
Cuando no se cuenta con seguridad física, es fundamental incrementar la atención en la seguridad de los datos. Windows Server 2008 y R2 proporcionan nuevas formas de lograr esto diseñadas exclusivamente para entornos como oficinas remotas, donde es posible que la seguridad física no sea tan estricta. Los controladores de dominio de sólo lectura (RODC) son una nueva característica de los servicios de dominio de Active Directory (ADDS) en los sistemas Windows Server. Representan un cambio fundamental respecto del uso habitual de los controladores de dominio (DC).
Debido a que las nuevas capacidades de los RODC afectan aspectos clave del proceso de diseño e implementación, es importante comprender cómo puede aprovecharlas en su empresa. También debe tener en cuenta consideraciones de planificación y diseño esenciales antes de introducirlas en su entorno. Los RODC son DC que hospedan, copias completa de sólo lectura de las particiones de la base de datos de Active Directory, una copia de sólo lectura de SYSVOL y un conjunto de atributos con filtro (FAS) que restringe la replicación entrante de ciertos datos de aplicación de los DC modificables.
De forma predeterminada, los RODC no almacenan selectivamente las credenciales de las cuentas de usuario y equipo, pero puede configurarlos para que lo hagan. Esto garantiza el uso de los RODC en sucursales remotas o redes perimetrales que no cuentan con la seguridad física comúnmente presente en la intranet de los centros de datos. Los RODC también proporcionan otras funciones de seguridad menos conocidas, como la cuenta especial de concesión de vales de Kerberos, que contrarresta los ataques basados en vales asociados a las amenazas que sufren los RODC mismos.
Aunque las cuestiones de seguridad son el principal motivo de implementación de los RODC, también brindan otras ventajas, como la escalabilidad y administración empresarial. En términos generales, los RODC están diseñados para los entornos que requieren autorizaciones y autenticaciones locales, pero que carecen de la seguridad física que protege a los DC modificables. Por eso, los RODC son más comunes en las redes perimetrales de los centros de datos o en las ubicaciones de las sucursales.
Un ejemplo de buen uso de los RODC es un centro de datos que requiere ADDS pero que, debido a restricciones de seguridad, no puede aprovechar el bosque corporativo de dichos ADDS en la red perimetral. En este caso, los RODC deben cumplir importantes requisitos de seguridad, que cambiarán el alcance de la infraestructura de la implementación de los ADDS corporativos. Este tipo de situación probablemente se torne más frecuente. Además, refleja modelos de prácticas recomendadas de ADDS actuales para las redes perimetrales, como el modelo de bosque corporativo extendido.
Diversificación de actividades con los RODC
Los entornos más comunes de uso de RODC con ADDS siguen siendo las sucursales. Este tipo de entornos generalmente son puntos finales en la topología de red central y perimetral. Cuentan con una amplia distribución geográfica, son muchos e individualmente hospedan pequeñas poblaciones de usuarios, se conectan a las oficinas centrales mediante vínculos de red lentos y poco confiables, y frecuentemente carecen de administradores experimentados en el lugar.
En las sucursales que ya hospedan DC modificables, probablemente no es necesario implementar RODC. En este caso, sin embargo, es posible que los RODC no sólo cumplan los requisitos existentes de los ADDS, sino también que los superen en términos de una seguridad más estricta, una administración mejorada, una arquitectura simplificada y un costo de propiedad total (TCO) inferior. En las ubicaciones en las que los requisitos de administración o seguridad prohíben el uso de DC, los RODC pueden ayudarlo a introducir DC en el entorno y proporcionar cierta cantidad de servicios localizados y beneficiosos.
Aunque las nuevas funciones y beneficios hacen que la consideración de RODC sea atractiva, hay otros factores a tener en cuenta, como los problemas de compatibilidad de aplicaciones y las condiciones que afectan a los servicios. Esto puede hacer que la implementación de RODC sea inaceptable en ciertos entornos.
Por ejemplo, dado que muchos servicios y aplicaciones con directorios habilitados leen los datos de los ADDS, deben seguir funcionando y trabajando con los RODC. No obstante, si ciertas aplicaciones requieren accesos modificables en todo momento, los RODC no son aceptables. Los RODC además dependen de la conectividad de la red de los DC modificables para escribir operaciones. A pesar de que los errores de escritura de las operaciones pueden ocasionar la mayoría de los problemas más comunes de aplicación, hay otras cuestiones que debe considerar, como las operaciones ineficientes o sus errores de lectura, los errores de lectura-escritura de las operaciones y los errores generales de la aplicación asociados a los RODC mismos.
Además de los problemas de aplicaciones, se pueden ver afectadas las principales operaciones de equipo y usuario cuando se interrumpe o pierde la conectividad de los DC modificables. Por ejemplo, es posible que los servicios básicos de autenticación fallen si las contraseñas de la cuenta no están almacenadas en caché y localmente en los RODC. Puede solucionar fácilmente este problema almacenando las cuentas en caché a través de la Directiva de Replicación de Contraseñas (PRP) del RODC y almacenando luego las contraseñas a través del rellenado previo. La realización de estos pasos también requiere la conectividad a un DC modificable.
Junto con otros problemas de autenticación, la caducidad de la contraseña y los bloqueos de cuentas se ven gravemente afectados cuando no se puede acceder a la conectividad del DC modificable. Las solicitudes de cambio de contraseña y los intentos de desbloquear manualmente una cuenta bloqueada seguirán fallando hasta que se restaure la conectividad del DC modificable. Comprender esta dependencia y los cambios subsiguientes del comportamiento operativo es fundamental para garantizar sus requisitos y cualquier acuerdo de nivel de servicio (SLA).
Existen varias situaciones generales en las que puede implementar RODC. Son útiles en las ubicaciones que no cuentan con DC existentes, o en las ubicaciones que actualmente hospedan DC que se reemplazarán o actualizarán a una nueva versión de Windows. Aunque existen consideraciones de planificación integral específicas para cada situación, aquí nos centraremos en los enfoques no específicos. Con todo, son característicos de los RODC en lugar de los DC modificables tradicionales.
Planificación previa
Antes de comenzar la planificación formal de los RODC, debe realizar la planificación previa de los ADDS básicos y del nivel de diligencia adecuado. Esto debe incluir tareas clave, como validar la estructura lógica de los ADDS existentes y garantizar que el modelo de administración y la estructura física de los ADDS respalden los requisitos técnicos y empresariales existentes. Además deberá considerar los requisitos de hardware, las estrategias de actualización de software, los problemas conocidos del sistema de operación aplicable, y deberá evaluar los requisitos previos de los ADDS de los RODC. Esta información es esencial para los procesos de implementación y planificación. Todo esto está bien documentado en listas de comprobación detallada de la implementación.
Instalación y administración
Los RODC poseen una función de administración sustancial denominada Separación de Funciones de Administrador (ARS). Esta función delega a los administradores ajenos a los servicios la capacidad de instalar y administrar servidores de RODC sin conceder derechos de Active Directory. Se trata de un cambio importante de las consideraciones tradicionales respecto de los procedimientos de implementación, delegación de la administración y diseño del servidor de DC. Esta separación de funciones es sumamente importante en las aplicaciones básicas que requieren la instalación directa de DC o las ubicaciones que hospedan un solo servidor multipropósito.
Funciones adicionales del servidor
Como regla general, debe eliminar del servidor todas las funciones no requeridas para que funcione el RODC. Por lo tanto, las únicas funciones que debe agregar a los RODC son las funciones del servidor del catálogo global y el DNS. Debe instalar la función del servidor del DNS en cada RODC para que los clientes del DNS local puedan realizar resoluciones del DNS cuando la conectividad de red de un DC modificable no está disponible. No obstante, si la función del servidor del DNS no se instaló mediante Dcpromo.exe, deberá instalarla posteriormente. Debe utilizar Dnscmd.exe para dar de alta los RODC en las particiones del directorio de aplicación del DNS que hospeda las zonas integradas de Active Directory. También debe configurar los RODC como servidores de catálogo global, de manera que puedan realizar solicitudes de catálogo global y autenticación simplemente a través del RODC. Desde el punto de vista de la autenticación, si la función de catálogo global no es una opción, puede usar el almacenamiento en caché del grupo universal. La autenticación exitosa de un RODC puede depender en última instancia de la configuración de la PRP del RODC.
Ubicación de los RODC
La ubicación de los DC ha cambiado considerablemente con la introducción de la PRP de los RODC. Los RODC deben ser capaces de replicar la partición del dominio de un DC modificable que ejecuta Windows Server 2008 o Windows Server 2008 R2 en el mismo dominio, porque sólo estos DC pueden cumplir la PRP de los RODC. Para garantizar la replicación correcta, se debe colocar el DC modificable en el sitio de los ADDS que cuenta con un vínculo de sitio de costo mínimo al sitio que contiene los RODC.
Si no puede establecer esta configuración, la replicación de los RODC dependerá de la opción Enlazar todos los vínculos del sitio (es decir, de la transitividad del vínculo del sitio) o de los puentes de vínculos del sitio entre los vínculos a sitios que contienen el sitio de los RODC y el sitio del DC modificable. Si la transitividad del sitio o los puentes de vínculos del sitio no son una opción viable, puede crear nuevos vínculos al sitio para conectarse directamente al sitio de los RODC y el sitio de los DC modificables.
Como práctica recomendada general, no debe colocar otros DC en el mismo sitio de ADDS que los RODC, ya que las operaciones del cliente pueden tornarse inconsistentes, ocasionando que el comportamiento del cliente sea impredecible. Las operaciones básicas, tales como autenticaciones, lecturas y escrituras de LDAP, y cambios de contraseña, pueden comportarse de manera diferente según las distintas configuraciones de los RODC, la versión de Windows de los DC modificables, y la disposición de la conectividad de red de otros DC modificables. Además, debe mantener todos los recursos y usuarios de un dominio en el sitio de los RODC. Los RODC no almacenan contraseñas confiables y requieren una autorización entre dominios para enviar solicitudes de autenticación a distintos DC modificables en cada dominio. Suponiendo que los DC modificables residen en sitios separados, las solicitudes de autenticación entre dominios dependerán de la conectividad de la red y no funcionarán si ésta falla.
Rendimiento y escalabilidad
Los RODC también proporcionan beneficios de escalabilidad útiles para implementaciones de ADDS más grandes y complejas. Por ejemplo, los RODC brindan replicación unidireccional. Por lo tanto, la implementación de RODC en sucursales reduce la carga de rendimiento en servidores de cabeza de puente de oficina central que normalmente procesan la replicación entrante de los DC de las sucursales. Desde la perspectiva del TCO, esto disminuye la cantidad de objetos de conexión necesarios de creación y administración. También puede reducir la cantidad requerida de DC de la oficina central.
Los RODC además proporcionan mejoras en el equilibrio de carga que ayudan a distribuir automáticamente objetos de conexión saliente de manera uniforme en los servidores de cabeza de puente de la oficina central. En las versiones anteriores de Windows, esto requería una intervención manual de rutina. Ahora, cuando el comprobador de coherencia de la información (KCC) de un RODC detecta que se agregó o se eliminó un servidor de cabeza de puente de la oficina central, determina si se deben cambiar los socios de replicación a una nueva cabeza de puente. Esto se realiza mediante la ejecución de un algoritmo y un equilibrio de carga probabilístico. Si se agregan RODC a las ubicaciones de la sucursal, el KCC equilibrará las conexiones entrantes de equilibrio de los servidores de cabeza de puente existentes en la oficina central.
Almacenamiento de credenciales en caché
La PRP de los RODC determina si las cuentas se almacenan en caché en un RODC en particular. De forma predeterminada, la lista “permitir” de la PRP especifica que no se pueden almacenar en caché las contraseñas de las cuentas. Además, rechaza explícitamente el almacenamiento en caché de ciertas cuentas. Esto tiene precedencia sobre las configuraciones manuales de “permitir”. Como mencioné anteriormente, es posible que deba configurar la PRP de cada RODC para que permita el almacenamiento en caché de las contraseñas de dichas cuentas.
Este paso debe tomarse con precaución, dado que las modificaciones de la PRP afectan tanto la disponibilidad de la seguridad como de los servicios. Por ejemplo, la situación predeterminada de no almacenar en caché las cuentas da como resultado mayor seguridad, pero no proporciona acceso sin conexión en caso de que la conectividad de la red de un DC modificable no esté disponible. Por otro lado, cuando un gran porcentaje de cuentas se almacena en caché (por ejemplo, un grupo de usuarios de dominio), la seguridad es menor si el RODC está comprometido, pero se cuenta con un mayor nivel de disponibilidad de servicios para las cuentas almacenadas en caché. Debido a los requisitos técnicos y comerciales exclusivos de los diferentes entornos de infraestructura, los diseños de las PRP variarán de una organización a otra.
Una vez establecido el modelo de PRP, deberá configurar la PRP de cada RODC para poder almacenar en caché las cuentas correspondientes. Como práctica recomendada, configure las PRP con admisiones explícitas y no modifique la lista “denegar” predeterminada. Esta lista es fundamental porque evita que se almacenen en caché las credenciales de cuentas críticas (como el administrador de ADDS) en los RODC.
Otro aspecto clave del diseño de la PRP es determinar si el almacenamiento en caché de las cuentas se rellenará previamente con contraseñas. De forma predeterminada, las credenciales de las cuentas almacenadas en caché no se almacenan en caché realmente hasta después del primer inicio de sesión en el RODC, cuando se envía la solicitud de autenticación al DC modificable de Windows Server 2008 o Windows Server 2008 R2 y se replican las credenciales en el RODC. Esto quiere decir que, si la conectividad de la red de un DC modificable no está disponible antes de autenticar las cuentas almacenadas en caché en el RODC, el inicio de sesión no será exitoso aunque las cuentas se hayan configurado para que se almacenen en caché.
Para resolver este problema, puede rellenar previamente las contraseñas en caché de forma manual ni bien la PRP se haya configurado y las cuentas se hayan marcado para que se almacenen en caché. Esta operación también requiere una conectividad de red entre el DC modificable de Windows Server 2008 o Windows Server 2008 R2 y el RODC. Puede hacer esto anticipadamente durante el proceso de implementación, mucho antes de que los usuarios en caché inicien sesión por primera vez.
Puede usar esta guía de diseño arquitectónico fundamental como base para planificar sus RODC. Al tratar las consideraciones de diseño clave, este artículo proporciona un punto de partida eficaz para el diseño de una solución de RODC completa y detallada. No se trata de un proceso simple y requiere un período de tiempo considerable para reconciliar nuevas funciones y diseñar consideraciones respecto de los requisitos y el entorno exclusivo de su organización.
Paul Yu*(Paul.Yu@microsoft.com) es consultor senior de los Servicios de Consultoría de Microsoft y trabaja en Microsoft desde hace diez años proporcionando soluciones de infraestructura empresarial a corporaciones comerciales y organizaciones del sector público.*