Cobertura especial: Windows Server 2008

Novedades en Servicios de dominio de Active Directory

Gil Kirkpatrick

 

Resumen:

• Uso del nuevo Administrador de servidores con ADDS
• Ejecución de servicios de dominio en Server Core
• Controladores de dominio de sólo lectura
• Cambios en contraseñas, copias de seguridad y auditorías

Con Windows 2000, Microsoft presentó al mundo Active Directory. El siguiente gran lanzamiento, Windows Server 2003, integró mejoras significativas en Active Directory, pero no

fueron cambios de excesiva relevancia. Actualmente, Active Directory® es un servicio de directorio muy consistente y eficaz. Aún así, el equipo de Active Directory ha integrado numerosas mejoras en la última versión para mejorar la seguridad y la capacidad de administración de este servicio de red principal.

Hacia el cambio de siglo, Active Directory se encargaba de autenticar al usuario cuando iniciaba la sesión, aplicaba directivas de grupo al usuario y su equipo, y le ayudaba a encontrar la impresora que estaba buscando. Apenas unos años más tarde, Microsoft lanzó al mercado una variante independiente denominada Active Directory Application Mode (ADAM).

Alrededor del año 2006, todo esto había cambiado. Active Directory ya no era una tecnología específica. En su lugar, se había convertido en un nombre de marca que identificaba un conjunto de servicios de fábrica para el control de identidades y acceso de Windows®. La Figura 1 ofrece un resumen rápido de lo que constituye la marca Active Directory.

Figure 1 Componentes de Active Directory

Tecnología actual de Active Directory	Anteriormente denominada	Descripción
Servicios de dominio de Active Directory (ADDS)	Active Directory	Lo que solíamos llamar Active Directory. Ofrece autenticación basada en NTLM y Kerberos para usuarios y equipos de dominio, y administra unidades organizativas, usuarios, grupos, directivas de grupo y mucho más.
Active Directory Lightweight Directory Services (ADLDS)	Active Directory Application Mode (ADAM)	Servidor LDAP de alto rendimiento basado en el mismo código fuente usado por ADDS.
Servicios de certificados de Active Directory (ADCS)	Servicio de certificado	Ofrece autenticación segura mediante certificados X.509.
Active Directory Rights Management Services (ADRMS)	Servidor de Active Directory Rights Management Services	Protege los activos digitales, como documentos y correo electrónico, del uso no autorizado mediante la creación de archivos y contenedores protegidos con derechos.
Servicios de federación de Active Directory (ADFS)	Servicios de federación de Active Directory	Ofrece inicio de sesión único web y federación de identidades para servicios web compatibles con WS-*.

Así pues, para usar la terminología apropiada, este artículo abarca exactamente los Servicios de dominio. Pero, para ser sincero, se trata del mismo Active Directory que ha aprendido a adorar desde el año 2000.

Administrador de servidores en Windows Server 2008

Las primeras dos mejoras de Active Directory que me dispongo a explicar no son, realmente, cambios aplicados a los Servicios de dominio de Active Directory (ADDS), sino que se trata, más bien, de cambios en Windows que modificarán la manera en que administra Active Directory. La primera, el nuevo Administrador de servidores, se muestra nada más arrancar el servidor Windows Server® 2008 por primera vez. La segunda es la instalación Server Core, la cual explicaré en unos momentos.

Probablemente, el Administrador de servidores le será familiar gracias al Asistente para configurar su servidor de Windows Server 2003, que se muestra de manera predeterminada tras instalar Windows Server 2003. Esta versión, no obstante, no es muy útil para la administración diaria y todos los usuarios que conozco marcan la casilla "No mostrar esta página al iniciar sesión".

El Administrador de servidores en Windows Server 2008, por otro lado, es bastante útil (consulte el artículo de Byron Hynes en este número de TechNet Magazine para obtener información general sobre el Administrador de servidores). En primer lugar, tal como puede observar en la Figura 2, el Administrador de servidores es actualmente un complemento Microsoft® Management Console (MMC) y no una aplicación HTML de Microsoft (HTA). Esto significa que tiene una interfaz de usuario con características completas que es familiar y fácil de personalizar. El Administrador de servidores viene preparado para permitirle administrar la instalación de funciones de servidor (servicios principales como DNS, ADDS e IIS) y características (componentes de software, como Microsoft .NET Framework, cifrado de unidad BitLockerTM y Windows PowerShellTM). Más allá de la capacidad de agregar y quitar software, el Administrador de servidores proporciona también un único punto de contacto para ejecutar herramientas de diagnóstico (como el Visor de eventos y PerfMon) y las utilidades de configuración del sistema (como el Administrador de dispositivos y el Firewall de Windows). Si agrega los complementos MMC para Active Directory, por ejemplo, Usuarios y equipos, Dominios y confianzas, y Sitios y servicios, conseguirá una interfaz muy atractiva para realizar la administración diaria del controlador de dominio (DC) de Windows Server 2008.

Figura 2** Administrador de servidores en Windows Server 2008 **(Hacer clic en la imagen para ampliarla)

Windows Server 2008 Server Core

Windows Server Core constituye una nueva opción de instalación de Windows que proporciona una versión reducida de Windows al contener únicamente los componentes necesarios para ejecutar ciertas funciones clave de servidor, incluidos los Servicios de dominio de Active Directory. La Figura 3 incluye las funciones compatibles con Server Core. Aunque una instalación de Server Core incluye una interfaz gráfica de usuario, no ejecuta el shell de escritorio de Windows y casi todas las herramientas gráficas para administrar y configurar Windows están ausentes (consulte la Figura 4). En su lugar, lo único que obtendrá será una ventana de comandos y un terrible desasosiego al no saber qué hacer a continuación. ¿Cómo cambio el nombre de equipo? ¿Cómo puedo configurar una dirección IP estática?

Figura 4** No hay mucho que ver en la interfaz de usuario de Server Core. **(Hacer clic en la imagen para ampliarla)

Los primeros minutos frente a una instalación de Server Core pueden ser muy frustrantes. Pero, tras emplear un poco de su tiempo en volverse a familiarizar con WMIC, NETSH y NETDOM, podrá llevar a cabo todas las tareas usuales de instalación y configuración sin ninguna dificultad. Y podrá continuar el uso de Regedit y el Bloc de notas para satisfacer sus necesidades de herramientas gráficas.

La ventaja principal de Server Core es que se quita gran parte del código que obtiene con una instalación de Windows normal, que probablemente no necesitará para todas estas funciones de servidor principal. Esto reduce la superficie de ataque potencial para el malware (una cosa buena) y reduce la cantidad de revisiones y reinicios que tendrá que realizar en sus DC (algo incluso más positivo). Además, consigue una superficie de disco mucho más pequeña y unos requisitos de disco duro reducidos, lo cual no supone una gran diferencia, pero sí puede ser de gran ayuda en entornos de servidor virtualizado.

¿Podría la ausencia de utilidades gráficas dificultar la administración de ADDS? No, en absoluto. Puede realizar casi todas sus tareas de administración de forma remota al ejecutar las utilidades en su estación de trabajo y conectar al controlador de dominio a través de la red. La gran mayoría de los DC acabarán por ejecutarse en instalaciones de Server Core.

Cambios de DCPROMO

El primer cambio que advertirá en ADDS es el nuevo DCPROMO. Funciona de la misma manera que DCPROMO en Windows Server 2003, pero se ha vuelto a escribir por completo con el objeto de facilitar su uso. Por ejemplo, ya no tiene que escribir sus credenciales de administrador de dominio; DCPROMO puede usar las credenciales de su inicio de sesión activo para aumentar el nivel del servidor. Tampoco es necesario escribir DCPROMO/ADV para obtener las opciones de Modo avanzado de DCPROMO, puesto que hay una casilla en el primer cuadro de diálogo de DCPROMO para habilitar estas opciones. El Modo avanzado permite también seleccionar el controlador de dominio existente desde el que realizar la replicación. Esto significa que es posible mantener la carga de replicación de DCPROMO fuera de sus DC de producción.

Al aumentar el nivel de un DC a un nuevo dominio o bosque, DCPROMO ofrece la opción de configurar el nivel funcional del bosque y el dominio, en lugar de hacerlo más tarde. También es posible especificar el sitio de Active Directory en el cual desea colocar el DC durante el proceso de aumento de nivel, lo cual es muy útil en el escenario desatendido de DCPROMO. DCPROMO sugerirá incluso el mejor sitio para la ubicación del DC según la dirección IP del DC.

El nuevo DCPROMO reúne también todas las opciones de configuración en una única página; en un mismo lugar, podrá elegir si el nuevo DC será un catálogo global (GC), un servidor DNS o un DC de sólo lectura. No tendrá que acudir a una ubicación confusa del complemento Sitios y servicios de Active Directory para marcar el DC como GC.

Pero quizás la característica más atractiva del nuevo DCPROMO es la capacidad de guardar toda la configuración de DCPROMO en un archivo de respuesta justo antes de que se inicie el proceso de aumento de nivel. Esto es mucho más sencillo, además de reducir las posibilidades de error, que improvisar el archivo de respuesta a mano. Puede usar el archivo de respuesta para realizar DCPROMO desatendidos en otros servidores. Y para aquellos fanáticos del scripting, se puede obtener acceso a todas las opciones de DCPROMO desde la línea de comandos.

Controladores de dominio de sólo lectura

En las primeras etapas de Active Directory, las empresas, con frecuencia, implementaban controladores de dominio en cada uno de los sitios en los que los usuarios iniciaban sesión. Por ejemplo, esto era bastante frecuente en los bancos, que colocaban un DC en cada sucursal. La lógica consistía en que los usuarios de la sucursal bancaria pudiesen iniciar la sesión y obtener acceso a los recursos de la red local incluso en caso de error de la WAN.

En aquellos tiempos, la necesidad de seguridad física de los DC no se comprendía adecuadamente. Incluso me encontré con controladores de dominio debajo de escritorios a los que cualquier persona podía obtener acceso. No fue hasta unos pocos años después que arquitectos de Active Directory comenzaron a apreciar el riesgo de seguridad que suponía un DC sin protección, y las organizaciones de TI comenzaron a consolidar sus DC en centros de datos más centralizados. A partir de entonces, los usuarios de sucursales tuvieron que autenticarse a través de WAN, pero esto supuso un cambio muy importante en cuanto a seguridad añadida.

Active Directory en Windows Server 2008 cambia la ecuación con respecto a implementaciones de sucursal al introducir controladores de dominio de sólo lectura, o RODC. Estos representan el cambio más importante en los Servicios de dominio de Windows Server 2008.

El equipo de Active Directory se centró en los requisitos del escenario de la sucursal a la hora de diseñar el RODC, y adoptaron el siguiente objetivo: "Lo que ocurre en la sucursal, se queda en la sucursal". El hecho es que, si implementa un DC en una sucursal físicamente no segura, hay muy poco que pueda hacer para prevenir que el DC, y los equipos que confían en este DC, sean víctimas de ataques. Sin embargo, puede evitar que los daños causados por estos ataques se extiendan de la sucursal al resto del dominio.

Tenga en cuenta que, a pesar de que constituyen un cambio muy relevante en la infraestructura de ADDS, los RODC son sencillos de implementar. Su dominio debe estar en un nivel funcional de bosque de Windows Server 2003 y debe haber, al menos, un DC de Windows Server 2008 en el dominio. Además de constituir simplemente una solución de sucursal, los RODC tienen sentido en entornos orientados a Internet y en situaciones en las que el DC se ubica en el perímetro de la red.

Deserción del DC

Hay varias clases de amenazas que deben considerarse en una sucursal. La primera es el escenario "DC robado", en el cual alguien "huye" con el DC o el disco del DC. Más allá de la interrupción del servicio local, el riesgo consiste, a fin de cuentas, en que el atacante obtiene acceso a todos los nombres de usuario y contraseñas en el dominio y, desde aquí, eleva sus privilegios para obtener acceso a recursos protegidos o provocar una denegación de servicio. Para solucionar esta amenaza, los RODC, de manera predeterminada, no almacenan los valores hash de contraseña en el Árbol de información del directorio (DIT) del RODC. Así pues, para autenticar a un usuario en el dominio, cuando un usuario se autentica por primera vez en un RODC específico, el RODC pasa la solicitud a un controlador de dominio completo (FDC) en el dominio. El FDC procesa la solicitud y, si es correcta, el RODC emite una solicitud de replicación para el valor hash de la contraseña.

Un RODC comprometido podría solicitar, de manera potencial, valores hash de contraseña para cuentas confidenciales. Para evitarlo, el administrador de dominio puede configurar una directiva de replicación de contraseñas para cada RODC. La directiva de replicación de contraseñas se compone de dos atributos en el objeto de equipo del RODC. El atributo msDS-RevealOnDemandGroup contiene los nombres distintivos de grupos, usuarios o cuentas de equipo cuyas contraseñas se pueden almacenar en caché en el RODC (estos son normalmente los usuarios y los equipos que se encuentran en el mismo sitio que el RODC). msDS-NeverRevealGroup contiene los nombres distintivos de grupos, usuarios o cuentas de equipo cuyas contraseñas no se pueden almacenar en caché en el RODC (por ejemplo, la cuenta del administrador de dominio nunca debe tener los valores hash de la contraseña almacenados en caché en un RODC). Cuando el RODC solicita el valor hash de la contraseña para una cuenta particular, el FDC evalúa la solicitud según la directiva de replicación de contraseñas para determinar si el valor hash de la contraseña debe replicarse en el RODC. Con el robo de un DC, la vulnerabilidad se limita a aquellas contraseñas almacenadas en caché en el RODC robado en el momento en se quitó de la red, y se elimina la posibilidad de compromiso de contraseñas críticas.

El objeto de equipo del RODC contiene otros dos atributos para ayudarle a determinar exactamente qué cuentas deben almacenar sus contraseñas en caché. El atributo msDS-AuthenticatedAtDC enumera las cuentas que se han autenticado en el RODC, y el atributo msDS-RevealedList indica las cuentas cuyas contraseñas están almacenadas actualmente en el RODC.

Los valores hash de las contraseñas de usuarios y equipos no son los únicos secretos almacenados en un DC. La cuenta KrbTGT contiene las claves del servicio Centro de distribución de claves de Kerberos (KDC) que se ejecuta en cada controlador de dominio. En un escenario normal, cada KDC del dominio comparte la misma cuenta KrbTGT, y es posible que un atacante pueda recuperar estas claves de un DC robado y usarlas para atacar el resto del dominio. Sin embargo, cada RODC tiene su propia cuenta y claves de KrbTGT, lo que elimina esta posibilidad.

Tampoco es excepcional que las aplicaciones almacenen contraseñas u otro tipo de información confidencial en el DIT. Si un atacante tiene la intención de robar un DC, podría robar posiblemente estas contraseñas de aplicación y usarlas para obtener acceso a las aplicaciones. Para evitar este riesgo, los Servicios de dominio de Windows Server 2008 permiten a los administradores definir el conjunto de atributos con filtro de DC de sólo lectura (RO-FA). Los atributos que forman parte de RO-FAS nunca se replican en los RODC; por lo tanto, estos no se pueden obtener de un DC comprometido. Debe asignar atributos a RO-FAS mediante la configuración del bit 9 (0x0200) del atributo searchFlags del objeto attributeSchema correspondiente en el esquema.

Ataque de los bárbaros

Otra clase de amenaza para controladores de dominio de sucursal podría ser el caso de un administrador de servidor local que aprovecha los privilegios del DC para obtener acceso a otros recursos de dominio o para diseñar un ataque de denegación de servicio. De nuevo, si el administrador local tiene acceso físico al controlador de dominio, se podrá hacer muy poco para evitar los daños. Pero es posible evitar que el atacante use el controlador de dominio de la sucursal para comprometer otros DC del dominio.

Los RODC no se consideran confiables como controladores de dominio por parte de los DC completos del dominio. Desde el punto de vista de la confianza, los FDC tratan los RODC como servidores miembro del dominio. Un RODC no es miembro de los grupos Controladores de dominio empresariales y Controladores de dominio. La cuenta RODC tiene limitada su capacidad para actualizar cualquier valor del directorio y, por lo tanto, incluso si un atacante compromete la cuenta RODC, no obtendrá prácticamente privilegios útiles.

Los RODC no se muestran tan siquiera en la topología de replicación de DS normal. Puesto que los RODC parecen servidores miembro normales en lugar de controladores de dominio, el Comprobador de coherencia de la información (el proceso responsable en cada DC de calcular la topología de replicación de DS) no creará objetos de conexión a partir de RODC. Ningún DC completo o RODC tratará de llevar a cabo la replicación a partir de un RODC. Por el contrario, el RODC creará un objeto de conexión que representará un acuerdo de replicación entrante a partir de un DC completo, pero este objeto de conexión sólo existe en la réplica del RODC; ningún otro DC tiene una copia de este objeto de conexión. Desde el punto de vista de la replicación, los RODC son como trampas para los objetos de directorio. Los objetos se replican dentro, pero no fuera.

Separación de funciones administrativas en RODC

Es muy común que un DC de sucursal venga administrado por un administrador de servidor local que lleva a cabo todas las funciones, desde la ejecución de copias de seguridad en el controlador de dominio a la limpieza de teclados. Pero otorgar a un administrador de sitio remoto los derechos necesarios para llevar a cabo el mantenimiento general en un controlador de dominio supone un riesgo de seguridad, y la administración del sitio puede elevar posiblemente sus privilegios en el dominio. Los RODC ofrecen dos clases de separación de funciones administrativas para mitigar esta amenaza.

Con la primera clase de separación de funciones, el administrador de dominio puede aumentar el nivel del RODC de la manera normal mediante DCPROMO o puede usar un proceso de dos pasos en el cual el proceso de aumento de nivel real se delega de manera segura al administrador del sitio de la sucursal, sin otorgar ningún derecho de administración de dominio. El administrador de dominio crea previamente la cuenta de equipo del RODC en el dominio mediante el complemento MMC Usuarios y equipos de Active Directory, tal como se muestra en la Figura 5.

Figura 5** Creación previa de una cuenta de equipo del RODC **(Hacer clic en la imagen para ampliarla)

Al seleccionar "Crear previamente una cuenta de controlador de dominio de sólo lectura", se ejecuta una versión abreviada de DCPROMO que realiza todas las tareas que requieren acceso administrativo al dominio, incluidas la creación de la cuenta de equipo, la asignación del RODC a un sitio, la especificación de las funciones del DC, la especificación de la directiva de replicación de contraseñas y la definición del usuario o el grupo que necesitará los derechos para completar la operación DCPROMO en el RODC. El administrador o el grupo delegados se almacenan en el atributo managedBy del objeto de equipo del RODC.

El administrador delegado puede, a continuación, ejecutar DCPROMO en el mismo servidor. DCPROMO detectará la cuenta creada previamente y convertirá el servidor en un RODC. Al ejecutar DCPROMO de esta manera, no se necesitan credenciales de administrador de dominio.

La segunda manera en que los RODC ofrecen separación de funciones administrativas es mediante la creación de funciones administrativas locales en el mismo RODC. Estas funciones parecen grupos locales de equipo que se almacenan en el registro del RODC y sólo se pueden evaluar en el RODC. Pero, en lugar de usar el complemento MMC Administración de equipos, el administrador administra las funciones locales de RODC mediante NTDSUTIL. La Figura 6 indica las funciones administrativas locales en un RODC. Estas funciones se corresponden una a una con los grupos integrados en Windows.

Figure 6 Funciones administrativas locales de RODC

Operadores de cuentas

Administradores

Operadores de copia de seguridad

Acceso de DCOM a servicio de certificados

Operadores de cifrado

Usuarios COM distribuidos

Lectores del registro de eventos

Invitados

IIS_IUSRS

Creadores de confianza de bosque de entrada

Operadores de configuración de red

Usuarios del registro de rendimiento

Usuarios del monitor de rendimiento

Acceso compatible con versiones anteriores de Windows 2000

Operadores de impresión

Usuarios de escritorio remoto

Replicador

Operadores de servidores

Servidores de licencias de Terminal Server

Usuarios

Grupo de acceso de autorización de Windows

Rarezas de RODC

Puesto que los RODC son de sólo lectura y ningún otro controlador de dominio se replicará a partir de ellos, los RODC exhiben ciertos comportamientos inesperados. Por ejemplo, los objetos persistentes (objetos eliminados de todos los sitios menos de un DC particular debido a la incapacidad de replicación del DC por más tiempo que la vigencia del bosque) se detectan normalmente a través de los partners de replicación saliente del DC. Pero, puesto que los RODC no tienen partners de replicación entrante, no existe la detección de objetos persistentes para ellos.

Los RODC no llevarán a cabo operaciones de actualización de LDAP (agregar, modificar, eliminar, cambiar nombre o mover). En su lugar, los RODC devolverán un error con una referencia LDAP a un DC de escritura que puede llevar a cabo la operación. Si la aplicación que emitió la actualización de LDAP no administra adecuadamente la operación de referencia, podría generarse un error en la aplicación.

Finalmente, si un usuario de otro dominio del bosque intenta autenticarse en un RODC, el RODC debe ser capaz de obtener acceso a un DC completo en su propio dominio con el objeto de obtener la contraseña confiable para pasar adecuadamente la solicitud de autenticación al DC en el dominio de usuario. Si la conexión de red entre el RODC y el DC completo en su dominio no está disponible, habrá un error en la autenticación.

Directivas de contraseña muy específicas

La capacidad de definir más de una directiva de contraseña en el dominio fue probablemente la característica más solicitada de Windows Server 2008 ADDS. Como probablemente sepa, en Windows 2000 y Windows Server 2003 Active Directory, cada dominio es compatible sólo con una única directiva de contraseña que se aplica a todas las entidades de seguridad del dominio. Si necesita una directiva de contraseña independiente para un grupo específico de usuarios, tiene que crear un dominio independiente. Pero, ahora, una característica nueva en Windows Server 2008 ADDS, denominada Directivas de contraseña muy específicas, permite definir varias directivas de contraseña en un dominio.

La nueva estrategia usa grupos para aplicar directivas de contraseña muy específicas a usuarios. En primer lugar, debe definir la directiva de contraseña específica mediante la creación de un nuevo objeto msDS-PasswordSettings en el contenedor CN=Password Settings Container, CN=System, DC=<domain>. El objeto msDS-PasswordSettings (PSO) contiene atributos que reflejan la configuración de la directiva de contraseñas en la Directiva de grupo (consulte la Figura 7).

Figure 7 Atributos del objeto mSDS-PasswordSettings

Atributo	Descripción
mSDS-PasswordReversibleEncryptionEnabled	Valor booleano que indica si las contraseñas se han cifrado mediante cifrado reversible.
mSDS-PasswordHistoryLength	Número de entradas conservadas en el historial de contraseñas.
mSDS-PasswordComplexityEnabled	Valor booleano que indica si las restricciones de complejidad de contraseña están habilitadas.
mSDS-MinimumPasswordLength	Número entero que define la longitud mínima de la contraseña.
mSDS-MinimumPasswordAge	INTEGER8 que indica la antigüedad mínima de la contraseña antes de que pueda cambiarse.
mSDS-MaximumPasswordAge	INTEGER8 que indica la antigüedad máxima de la contraseña antes de que deba cambiarse.
mSDS-LockoutThreshold	Número entero que indica el número de inicios de sesión con error antes del bloqueo.
mSDS-LockoutObservationWindow	INTEGER8 que indica el número de nanosegundos dentro de los cuales deben ocurrir los inicios de sesión consecutivos con error para activar el bloqueo.
mSDS-LockoutDuration	INTEGER8 que indica el número de nanosegundos durante los cuales queda bloqueada la cuenta.

A continuación, asigna la directiva de contraseñas a usuarios o grupos al agregar los nombres de usuario o grupo al atributo mDS-PSOAppliesTo de varios valores del PSO. Una vez que acepta la idea de que no tiene que aplicar directivas de contraseña a unidades organizativas (OU), es bastante sencillo. Pero existe alguna complejidad adicional.

Los usuarios son normalmente miembros de muchos grupos. Así pues, ¿qué sucede si hay varias directivas de contraseña conflictivas asociadas a un usuario debido a estas pertenencias a grupos? En este caso, ADDS usa una evaluación de la prioridad para determinar qué directiva de contraseña se debe aplicar. Funciona de este modo:

1. Si una directiva de contraseñas está vinculada directamente a un objeto de usuario (no a través de la pertenencia a grupos), se aplicará esa directiva de contraseña.
2. Si hay varias directivas de contraseña vinculadas directamente al usuario, se aplicará la directiva con el valor más bajo de prioridad (tal como determine el valor del atributo msDS-PasswordSettingsPrecendence del PSO).
3. Si hay varios PSO con la misma prioridad, se aplicará el que tenga el valor objectGUID más bajo.
4. Si ningún PSO está vinculado directamente al usuario, ADDS evaluará los PSO vinculados a los grupos del usuario. Si hay más de un PSO, se aplicará el PSO con el valor más bajo en el atributo msDS-PasswordSettingsPrecedence.
5. Si hay más de un PSO con el mismo valor de prioridad, se aplicará el que tenga un valor objectGUID más bajo.
6. Si no hay ningún PSO asociado con el usuario, se usará la directiva de contraseña del dominio.

Los objetos de usuario tienen un nuevo atributo denominado msDS-ResultantPSO para ayudar a esclarecer exactamente qué PSO se aplica a un usuario. Este atributo contiene el nombre distintivo del PSO que administra la contraseña del usuario.

Las directivas de contraseña muy específicas le ofrecen más flexibilidad de la que posiblemente necesitará jamás, pero debe administrar estas directivas con cuidado para que sean lo más sencillas posible. No existe utilidad de fábrica para definir directivas de contraseña muy específicas; necesitará usar ADSIEdit o buscar una utilidad de terceros.

Servicio reiniciable de Active Directory

Cada vez que detiene un controlador de dominio para el mantenimiento de DIT, puede provocar interrupciones en los niveles de servicio de la red. Los DC de Windows Server 2008 cuentan con una nueva característica que permite detener el servicio de directorio sin desactivar por completo el DC.

El comando NET STOP NTDS detiene ADDS en un DC de Windows Server 2008. Al hacer esto, el proceso de la autoridad de seguridad local (LSASS) en el DC continúa ejecutándose, pero descarga todas las DLL relacionadas con ADDS y el servicio de directorio no está disponible. LSASS se comporta esencialmente como lo haría en un servidor miembro y reenvía solicitudes de autenticación del dominio a un DC. Puesto que se han descargado las DLL que administran ADDS, puede aplicar revisiones relacionadas con ADDS o llevar a cabo una desfragmentación sin conexión del DIT. El inicio de ADDS es tan simple como NET START NTDS. No obstante, para restaurar el DIT a partir de una copia de seguridad del estado del sistema, deberá realizar el arranque en modo de reparación del servicio de directorio.

Es importante que comprenda que el servicio de directorio no es realmente un servicio de Windows. Es, todavía, un componente integrante de LSASS, por lo que no puede detener LSASS sin apagar el equipo. Pero la capacidad de iniciar y detener el servicio de directorio en Windows Server 2008 constituye una opción conveniente.

Copia de seguridad y recuperación

Todo el mecanismo de copia de seguridad y restauración se ha renovado por completo en Windows Server 2008. No entraré en detalles aquí, pero las nuevas Copias de seguridad de Windows Server integran cambios que afectan a ADDS.

Copias de seguridad de Windows Server es una solución de copia de seguridad basada en volúmenes, lo cual significa que realiza copias de seguridad de volúmenes completos de disco de una vez. Sólo realiza copias de seguridad en dispositivos de disco (o similares), no tiene compatibilidad con cinta.

Existe una opción de copia de seguridad del estado del sistema para la utilidad de copia de seguridad de línea de comandos WBADMIN. Mediante el comando START SYSTEMSTATEBACKUP de WBADMIN, puede crear ahora una imagen de copia de seguridad que contiene todos los archivos de sistema críticos necesarios para restaurar Active Directory en un controlador de dominio. Existe, no obstante, capacidad para cinco volúmenes en el conjunto de las copias de seguridad, pero los volúmenes en el conjunto de copias de seguridad contendrán sólo los archivos necesarios para una restauración del estado del sistema. Es incluso más molesto el hecho de que, a partir de la compilación RC0 de Windows Server 2008, no es posible realizar una copia de seguridad del estado del sistema en un recurso compartido de red. Debe tener un volumen de disco local disponible para almacenar imágenes de copia de seguridad del estado del sistema, y este volumen no debe formar parte del conjunto de volúmenes de copia de seguridad del estado del sistema. Puede que tenga que agregar un volumen de disco nuevo a cada controlador de dominio en que realice copias de seguridad de estado del sistema.

La restauración del estado del sistema es bastante sencilla. Simplemente arranque el DC en el modo de restauración de servicios de directorio y ejecute el comando START SYSTEMSTATERECOVERY de WBADMIN. El resultado es un DIT restaurado de manera no autoritativa, en el cual puede restaurar autoritativamente objetos específicos mediante NTDSUTIL, tal como haría en Windows Server 2003.

Un aspecto de las Copias de seguridad de Windows Server merece mención especial: almacena imágenes de copia de seguridad en formato de disco duro virtual (VHD). Se trata del mismo formato que usa Microsoft Virtual Server 2005 para almacenar sus imágenes de disco virtual. Esto significa que puede tomar una imagen de copia de seguridad creada con las Copias de seguridad de Windows Server y montarla como una unidad de disco en un equipo virtual que se ejecute bajo Microsoft Virtual Server. A continuación, podrá examinar el contenido de la copia de seguridad como si se tratara de una unidad de disco normal.

Otro cambio con respecto a la copia de seguridad de ADDS es la capacidad de usar el Servicio de instantáneas de volumen para crear instantáneas de un momento dado de Active Directory. Al crear una instantánea mediante NTDSUTIL, el Servicio de instantáneas de volumen guarda la imagen anterior de cada bloque de disco del DIT antes de que se sobrescriba durante una operación de actualización. Al combinar las imágenes anteriores guardadas con la versión actual del DIT, el Servicio de instantáneas de volumen puede crear una instantánea completa del DIT con muy poca sobrecarga. La creación de una instantánea normal tarda tan sólo unos segundos, independientemente del tamaño del DIT.

En sí misma, se trata de una capacidad interesante, pero no del todo útil. Sin embargo, en Windows Server 2008, ADDS incluye una utilidad de línea de comandos denominada DSAMAIN que monta la imagen de instantánea en modo de sólo lectura. Esto proporciona un servidor LDAP independiente, muy semejante a una sesión de ADLDS que incluye el contenido de su directorio en el momento de la instantánea. Puede examinar el directorio mediante la utilidad LDP u otras herramientas LDAP, y recuperar versiones de objetos de directorio de un momento dado anterior.

Replicación SYSVOL con DFS-R

Windows Server 2003 R2 contaba con un Servicio de archivos distribuidos (DFS) totalmente renovado que integraba un mecanismo de replicación de archivos innovador denominado DFS-R. Este usa la compresión diferencial remota, que reduce sustancialmente el tráfico de replicación de archivos al determinar qué bloques de un archivo de destino necesitan replicarse para presentar sincronización con el archivo de origen. Sin embargo, Windows Server 2003 R2 usa todavía el Servicio de replicación de archivos (no DFS-R) para replicar SYSVOL entre controladores de dominio. Debido a esto, la replicación de SYSVOL continuaba siendo una fuente de problemas para los administradores de Active Directory.

Cuando se lleva a cabo la ejecución en el nivel funcional de dominio de Windows Server 2008, Windows Server 2008 puede replicar SYSVOL mediante DFS-R, lo que mejora la velocidad y la eficacia de la replicación de SYSVOL. De esta manera, es mucho más razonable colocar archivos de gran tamaño en SYSVOL para que estén disponibles en todos los DC. Para usar DFS-R con SYSVOL, debe migrar, en primer lugar, los datos anteriores de SYSVOL a DFS-R mediante la utilidad DFSRMIG. Este proceso consta de cuatro pasos:

• Crear los objetos de Active Directory requeridos por DFS-R.
• Crear la nueva estructura de archivos para SYSVOL en cada controlador de dominio.
• Cambiar todos los controladores de dominio para que usen el nuevo SYSVOL.
• Quitar el SYSVOL anterior.

Según el tamaño de SYSVOL y el número de controladores de dominio que posea, este proceso puede tardar unos momentos en realizarse, pero el rendimiento y la confiabilidad mejorados hacen que la espera merezca la pena.

Mejoras de auditorías

El sistema de auditorías de Active Directory para Windows Server 2003 constituye tanto una bendición como una maldición. Por una parte, ofrece una solución bastante completa, flexible y segura para efectuar el seguimiento de los cambios en el directorio. No obstante, algunos usuarios comentan que presenta problemas de capacidad de uso muy significativos.

Las auditorías de los cambios de directorio en un controlador de dominio de Windows Server 2003 se han convertido en un asunto de "todo o nada", o están activadas o no lo están. El volumen de tráfico de auditorías en un DC empresarial muy activo puede convertir la realización de auditorías en una tarea poco práctica. La configuración de un sistema de auditorías para crear los mensajes que realmente necesita mediante descriptores de seguridad individuales es aburrida y puede llevar fácilmente a error. Los mismos mensajes de auditoría son, con frecuencia, crípticos y, en muchos casos, no contienen la información que necesita, como los valores anteriores y posteriores de los atributos cambiados. Además, la recopilación, la correlación y el archivado de los mensajes procedentes de varios controladores de dominio no son realmente factibles con las herramientas nativas de Windows.

El sistema de auditoría de los servicios de directorio en Windows Server 2008 trata algunos de estos problemas. En primer lugar, hay cuatro nuevas subcategorías de auditoría para auditar los servicios de directorio: Acceso DS, Cambios DS, Replicación DS y Replicación DS detallada. Así pues, si desea simplemente auditar los cambios de directorio, no necesita examinar todos los eventos de lectura y replicación. Pero, si desea incluir las eliminaciones de objetos en su registro de auditoría, debe habilitar Acceso DS. Esto genera mensajes para todos los accesos de objeto de DS, con lo cual generará de nuevo demasiados mensajes. Además, puede configurar los descriptores de seguridad para generar los mensajes de auditoría que desea para los objetos de interés.

Los mensajes de auditoría se han limpiado sustancialmente para que sean legibles y contengan los datos que necesita. En particular, los cambios de directorio generan entradas de registro de auditoría que contienen los valores anteriores y nuevos de los atributos cambiados. Esto constituye una enorme mejora. La única desventaja en este caso es que los valores anteriores y nuevos aparecen en entradas separadas del registro de auditoría, por lo que tiene que llevar a cabo su correlación con el objeto de entender realmente el cambio realizado. Muchos productos complementarios de recopilación de registros de auditoría, incluidos los Servicios de recopilación de auditorías de Microsoft, son compatibles con esta clase de correlación.

Mejoras de la interfaz de usuario

Los complementos MMC Usuarios y equipos, Sitios y servicios, y Dominios y confianzas de Active Directory han sido siempre adecuados para administrar Active Directory. En Windows Server 2008, se han limpiado las herramientas básicas de administración y se ha integrado un par de características nuevas muy atractivas. Si habilita Características avanzadas, el cuadro de diálogo Propiedades muestra para cada objeto una ficha adicional denominada Editor de atributos. Se trata de la misma ficha de editor de atributos usada por ADSIEdit, que permite inspeccionar y editar todos los atributos del objeto. La propia ficha ofrece ahora una mejor descodificación de los atributos codificados, como el atributo userAccountControl. La Figura 8 muestra la adecuada integración del editor de atributos.

Figura 8** Editor de atributos en Usuarios y equipos de Active Directory **(Hacer clic en la imagen para ampliarla)

Conclusión

Además de los puntos clave que he tratado en este artículo, existen otras muchas mejoras integradas en ADDS en Windows Server 2008. Por ejemplo, el KDC usa el Estándar de cifrado avanzado de 256 bits (AES-256) si el dominio se encuentra en el nivel funcional de dominio de Windows Server 2008. Puede habilitar la Prevención de eliminación accidental de objetos al activar la casilla apropiada en la ficha Objeto para cualquier objeto de DS. El Motor de almacenamiento extensible que ofrece el servicio de administración de datos se ha mejorado para usar la corrección de errores de un solo bit, lo que reduce la probabilidad de que un error de hardware o software en el subsistema de disco pueda dañar el DIT. El servicio DNS comienza a procesar solicitudes antes de haber cargado por completo la base de datos DNS. El Servicio de ubicación del controlador de dominio se ha mejorado para que, en caso de no encontrar un DC en el sitio deseado, intente ubicar un DC en el sitio más próximo, en lugar de usar simplemente cualquier DC que pueda encontrar en el dominio. Además, NTDSUTIL es ahora compatible con RODC y las instantáneas del Servicio de instantáneas de volumen.

Claramente, Windows Server 2008 integra un número considerable de mejoras en los Servicios de dominio de Active Directory. En conjunto, estos cambios mejorarán apreciablemente la seguridad y la capacidad de administración de ADDS. Lo mejor, no obstante, es que el integrar Windows Server 2008 en su entorno de Active Directory no implica una migración masiva, es un proceso sencillo e incremental.

Gil Kirkpatrick es director técnico de NetPro y ha desarrollado software para Active Directory desde 1996. Junto con Guido Grillenmeier de HP, imparte los conocidos talleres de Recuperación ante desastres de Active Directory. También es el fundador de la Conferencia de expertos en directorios (visite www.dec2007.com).

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.