El futuro de WindowsServicios de directorio de Windows Server "Longhorn"

Byron Hynes

Esta columna se basa en una versión preliminar de Windows Server, denominada "Longhorn". Por tanto, es necesario tener en cuenta que toda la información de este documento está sujeta a cambios.

En la próxima versión de Windows Server, denominada "Longhorn", verá que Active Directory ha mejorado considerablemente. Algunos cambios resultan importantísimos y abren nuevos caminos para simplificar el uso y mejorar el rendimiento. Entre los cambios más notables de Active Directory se encuentra la nomenclatura de las características y las funciones. Todo lo que tiene que ver con la administración de identidades se agrupa bajo el encabezado de Active Directory®. Lo que anteriormente considerábamos Active Directory en Microsoft® Windows Server® 2003 se denomina ahora Servicios de dominio de Active Directory (ADDS). Además, se incluyen otros servicios, por ejemplo, Servicios de federación de Active Directory (ADFS), Active Directory Lightweight Directory Services (ADLDS, anteriormente Active Directory Application Mode, o ADAM), Active Directory Certificate Services (ADCS) y Servicios de Active Directory Rights Management (ADRMS).

Cada servicio representa una función de servidor, un nuevo concepto en Windows Server "Longhorn". Puede tener un equipo dedicado a una función de servidor o a varias, así como administrarlas mediante el Administrador del servidor, como se muestra en la figura 1. A partir de ahí, puede agregar funciones, buscar temas de ayuda y realizar otras tareas administrativas.

Figure 1 Administrador del servidor

Figure 1** Administrador del servidor **(Hacer clic en la imagen para ampliarla)

Como verá, el nuevo enfoque organiza las funciones y características más usadas en grupos lógicos a los que se tiene acceso mediante el Administrador del servidor.

Niveles funcionales

Windows Server "Longhorn" presenta un nuevo nivel funcional para los bosques y dominios. Aunque el nivel de bosques de Windows Server "Longhorn" (que saldrá al mercado con otro nombre) no aporta ninguna función nueva, garantiza que todos los dominios del bosque estén en el nivel funcional de Windows Server "Longhorn", lo que permite dos mejoras. La primera, el motor de replicación más actual del sistema de archivos distribuido (DFS) para el recurso compartido SYSVOL, que ofrece mayor estabilidad, seguridad y rendimiento. La segunda, compatibilidad del cifrado AES de 256 bits con el protocolo de autenticación Kerberos. Aunque el nivel funcional más reciente proporciona el mejor rendimiento, podrá seguir usando los niveles inferiores al migrar a Windows Server "Longhorn".

También se han introducido varias extensiones de esquema para admitir nuevas características, todas compatibles con los esquemas que se usan actualmente. Los controladores de dominio que se ejecuten en Windows Server "Longhorn" podrán coexistir y funcionar en combinación con los que se ejecuten en Windows Server 2003.

Compatible con Server Core

Entre las funciones de servidor, Servicios de dominio de Active Directory funcionará en una instalación Server Core de Windows Server "Longhorn". Server Core, que no abordamos en profundidad en este artículo, es una opción de instalación mínima para que sólo se aproveche la funcionalidad principal del servidor. Tampoco instala el shell de Windows ni usa una interfaz gráfica para el usuario, con lo cual, se ahorran muchos recursos.

Controlador de dominio de sólo lectura

En algunos entornos, la característica más destacable de ADDS en Windows Server "Longhorn" es el controlador de dominio de sólo lectura (RODC), que permite implementar un controlador que alberga una réplica de sólo lectura de la base de datos del dominio. Resulta especialmente útil donde no pueda garantizarse la seguridad física del controlador de dominio o donde deban ejecutarse otras aplicaciones en el controlador, que mantiene un administrador de servidor (a ser posible, que no pertenezca al grupo Administradores del dominio). Ambas situaciones resultan comunes en las sucursales.

Un controlador de dominio de sólo lectura se instala al marcar una casilla de verificación en el Asistente, como se muestra en la figura 2.

Figure 2 Instalación del controlador de dominio de sólo lectura

Figure 2** Instalación del controlador de dominio de sólo lectura **(Hacer clic en la imagen para ampliarla)

Antes de Windows Server "Longhorn", si los usuarios debían autenticarse a un controlador remoto, el tráfico atravesaba un vínculo WAN (red de área extensa). Los vínculos WAN suelen ser más lentos y más costosos que las conexiones LAN (red de área local), y, a veces, más propensos a que se interrumpa el funcionamiento. Como posible solución, se implementaba un DC en la oficina remota o la sucursal. Sin embargo, eso ocasionaba otros problemas, como el tráfico de replicación y la necesidad de garantizar la seguridad física del DC en la sucursal, algo de lo que suelen carecer las oficinas remotas pequeñas. En otros casos, las sucursales disponen de un ancho de banda limitado, lo que aumenta el tiempo requerido para iniciar sesión.

Con la excepción de las contraseñas de cuenta (salvo que se configure de otro modo), un RODC mantiene los mismos objetos y atributos de Servicios de dominio de Active Directory que un controlador de dominio con capacidad de escritura. Sin embargo, no se pueden realizar cambios locales en la réplica almacenada en el RODC. En su lugar, se realizan en un controlador de dominio con capacidad de escritura y se replican al RODC. Así evitamos que los cambios realizados en las sucursales dañen el bosque debido a la replicación y tapamos, a la vez, una posible vía de ataque.

Las aplicaciones locales que requieran acceso de lectura a la información del directorio del dominio pueden obtenerlo desde el RODC, mientras que las aplicaciones LDAP (protocolo ligero de acceso a directorios) que requieran acceso de escritura reciben una respuesta de referencia LDAP. Esta respuesta de referencia las dirige a un controlador de dominio con capacidad de escritura, por lo general, en la oficina central.

Ya que no se realizan cambios directamente en el RODC, éste tampoco origina ninguno. Por consiguiente, los controladores de dominio con capacidad de escritura que sean asociados de replicación no tienen que recuperar los cambios del RODC. Así se reduce la carga de los servidores cabeza de puente en la oficina central y el esfuerzo requerido para supervisar la replicación. La replicación unidireccional del RODC se aplica a las replicaciones ADDS y DFS (sistema de archivos distribuido). El RODC realiza la replicación de entrada normal para los cambios de las replicaciones ADDS y DFS.

En la base de datos del dominio, cada entidad principal de seguridad tiene un conjunto de diez contraseñas aproximadamente, denominadas credenciales. Un RODC no almacena las credenciales de equipo ni de usuario, salvo para la cuenta de su propio equipo y una cuenta especial para cada RODC, denominada "krbtgt" (usada para la autenticación Kerberos). El RODC se anuncia como el KDC (centro de distribución de claves) de su oficina, por lo general, la sucursal. Cuando el RODC firma o cifra una solicitud de TGT (vale concedido por el servicio de concesión de vales), emplea una contraseña y una cuenta krbtgt distintas a las que usa el KDC en un controlador de dominio con capacidad de escritura.

La primera vez que una cuenta intenta autenticarse a un RODC, éste envía la solicitud a un controlador de dominio con capacidad de escritura de la oficina central. Si la autenticación es correcta, el RODC también solicita una copia de las credenciales pertinentes. El controlador de dominio con capacidad de escritura reconoce que la solicitud proviene de un RODC y consulta la directiva de replicación de contraseña vigente para ese RODC.

Esta directiva determina si se pueden replicar las credenciales y almacenarlas en el RODC. En tal caso, un controlador de dominio con capacidad de escritura las envía al RODC, que las almacena en caché, como se muestra en la barra lateral "Funcionamiento de un controlador de dominio de sólo lectura".

Cuando las credenciales se almacenan en el RODC, la próxima vez que el usuario intenta iniciar sesión, el mismo RODC puede tramitar la solicitud hasta que las credenciales cambien. Cuando un TGT está firmado con la cuenta krbtgt del RODC, éste reconoce que tiene una copia de las credenciales almacenada en caché. Si otro DC ha firmado el TGT, el RODC reenviará las solicitudes a un controlador de dominio con capacidad de escritura.

Al limitar el almacenamiento de las credenciales sólo a aquellos usuarios que se hayan autenticado al RODC, también se limita el posible riesgo de desvelar las credenciales.

De forma predeterminada, ninguna contraseña de usuario se almacena en un RODC, aunque esa opción no tiene por qué ser la más adecuada. Por lo general, tan sólo unos pocos usuarios del dominio requieren que las credenciales se almacenen en un RODC en concreto, si los comparamos con los usuarios totales. Puede usar la directiva de replicación de contraseña para especificar los grupos de usuarios que requieren el almacenamiento en caché de las credenciales. Por ejemplo, al limitar el almacenamiento en el RODC tan sólo a los usuarios que estén asiduamente en esa sucursal, o bien al impedir que se almacenen las credenciales de alto valor, como las de los administradores, se reduce el riesgo de que se desvelen.

Así, en caso de que roben el RODC o corra peligro su seguridad, sólo habrá que restablecer las credenciales almacenadas en caché y, como argumentaremos, sabrá exactamente cuáles son esas cuentas, como se muestra en la figura 3.

Figure 3 Información de cuenta almacenada en caché

Figure 3** Información de cuenta almacenada en caché **(Hacer clic en la imagen para ampliarla)

Separación de funciones de administrador

En muchas sucursales, a un controlador se le asignan varias funciones de servidor, por ejemplo, que haga de servidor de archivos o de impresión. En otros casos, se instala una aplicación de línea de negocios en un controlador por pura necesidad. Eso acarrea un problema: Para administrar las aplicaciones y los servidores, un empleado de la sucursal necesita unas credenciales administrativas. Y cualquiera que administre el controlador de dominio de Windows Server 2003 puede administrar todo el dominio.

En Windows Server "Longhorn", a un administrador se le asignan permisos para administrar un RODC en concreto, pero no tiene acceso a otros controladores ni pertenece al grupo de seguridad Administradores del dominio de forma innecesaria.

Mejoras en las herramientas y la interfaz de usuario

Para admitir las funciones del RODC y facilitar la supervisión de las contraseñas replicadas, aparece la ficha Directiva de replicación de contraseña en la página de propiedades del controlador de dominio, en Usuarios y equipos de Active Directory, como se muestra en la figura 4.

Figure 4 Ficha Directiva de replicación de contraseña

Figure 4** Ficha Directiva de replicación de contraseña **(Hacer clic en la imagen para ampliarla)

Al hacer clic en el botón Opciones avanzadas de la ficha, verá qué contraseñas se han enviado al RODC, cuáles se han almacenado ahí y qué cuentas se han autenticado a ese RODC, como se muestra en la figura 5. Como en la lista aparecen las cuentas que se han autenticado, aunque estén fuera de los grupos que pueden tener las contraseñas replicadas, verá esa información y podrá decidir qué grupos deberían estar en la directiva de replicación de contraseña.

Figure 5 Directiva de replicación de contraseña avanzada

Figure 5** Directiva de replicación de contraseña avanzada **(Hacer clic en la imagen para ampliarla)

Se han realizado varios cambios a la venerable utilidad dcpromo, más conocida como Asistente para la instalación de Servicios de dominio de Active Directory. Este asistente se puede ejecutar como aplicación gráfica si elegimos el comando para agregar funciones en la página ICT (tareas de configuración inicial) que se ejecuta justo después de la instalación del sistema operativo. Elija ese comando y, a continuación, ADDS en el Administrador del servidor o invoque dcpromo en una línea de comandos o en el cuadro Ejecutar.

En cuanto use el asistente en el modo gráfico, verá una mejor organización de las opciones, ya que los elementos relacionados aparecen agrupados. Y tiene más opciones. Puede obtener acceso al modo avanzado desde la interfaz de usuario sin usar el conmutador /adv para, por ejemplo, crear otro árbol de dominios, ni instalar desde un medio (para reducir la replicación inicial en una WAN) ni seleccionar el controlador de origen para la replicación inicial.

Se han llevado a cabo ciertas mejoras para facilitarle el trabajo y reducir esos errores frustrantes. Por ejemplo, si usa el asistente para crear otro controlador en un dominio o bosque existente, puede explorar los dominios que hay en lugar de tener que escribir el nombre de NetBIOS.

Se han agregado páginas nuevas para especificar más opciones, para configurar el DC como servidor de catálogo global, como servidor DNS y como RODC. En el asistente, también podrá seleccionar la oficina, establecer los niveles funcionales, crear una directiva de replicación de contraseña para los RODC y configurar la delegación DNS.

Como herramienta de línea de comandos, dcpromo puede ejecutarse de forma desatendida. A diferencia de la misma herramienta en Windows Server 2003, una instalación desatendida no requiere ninguna respuesta por parte del usuario, como la necesidad de reiniciar el equipo. De este modo, resulta facilísimo usar ADDS en las instalaciones Server Core de Windows Server "Longhorn".

Auditoría de ADDS

Microsoft agrega muchas más funciones a la auditoría de los servicios de directorio en Windows Server "Longhorn". En Windows Server 2003, podía activar la auditoría o desactivarla para obtener acceso al directorio, pero aunque tuviera acceso total, el código de auditoría no incluía la información que había cambiado. Ahora, sí.

En Windows Server "Longhorn", la directiva de auditoría de ADDS tiene estas cuatro subcategorías:

  • Acceso del servicio de directorio
  • Cambios del servicio de directorio
  • Replicación del servicio de directorio
  • Replicación detallada del servicio de directorio

Para casi todos los profesionales informáticos, hay dos cambios clave que deben recordar. Primero, la auditoría Acceso del servicio de directorio ofrece básicamente la misma información que en Windows Server 2003, aunque el identificador de evento ha cambiado de 566 a 4662. Anótelo si usa herramientas para analizar el registro de seguridad. Segundo, la nueva categoría de cambios del servicio de directorio registra los valores anterior y actual del atributo modificado.

Para implementar la auditoría en ADDS, se emplea la directiva de auditoría global, las listas de control de acceso al sistema (SACL) y el esquema de ADDS. Los componentes colaboran para ofrecerle un sistema de auditoría extenso a la vez que flexible.

La directiva de auditoría global controla si se realizan auditorías en ADDS. Si la auditoría está habilitada, la directiva global controla cuál de las cuatro subcategorías de acceso se audita (consulte la lista anterior). La directiva de auditoría global suele aplicarse al objeto directiva de grupo predeterminada de controladores de dominio, es decir, se aplica a todo el directorio del controlador.

Aunque las herramientas de la directiva de grupo pueden activar o desactivar la directiva global, debe usar la herramienta de línea de comandos Auditpol.exe para ver las subcategorías o configurarlas, ya que no aparecen en la interfaz gráfica para el usuario.

Una SACL forma parte del descriptor de seguridad de un objeto. Al especificar las entradas de la SACL, le dice dos cosas al sistema: qué acciones y qué usuarios (o entidades principales de seguridad) le interesan. En resumen, especifica qué usuarios que intentan realizar según qué acciones deben aparecer en el registro. Es decir, si desea registrar los cambios en los objetos usuario que hayan realizado los administradores del dominio, pero no los usuarios, puede hacerlo con las SACL. Una SACL se aplica a un objeto (y puede definirse para objetos nuevos y venir heredada de objetos contenedor).

También puede configurar el esquema de ADDS para restringir los cambios en ciertos atributos. Como las SACL se aplican al objeto de forma predeterminada, cualquier acceso o cambio en los atributos queda registrado. Eso podría generar mucha actividad en el registro y quizá no le interesen todos los atributos. Así pues, puede marcar un atributo para que no se registren los cambios que sufra.

Como SearchFlags es un atributo definido en la clase que define los atributos, es el atributo de un atributo. También es una máscara de bits, donde cada bit con valor de un byte representa un parámetro de activación o desactivación distinto. Quizá lo comprenda mejor si lo considera la propiedad de un atributo. En Windows Server 2003, se emplean siete valores para controlar varios parámetros, por ejemplo, la indización y la replicación GC del atributo. En Windows Server "Longhorn", el octavo bit (con un valor de 128) se emplea para decidir si los cambios se registran o no. Si ese bit está configurado, ADDS no registrará los cambios cuando se realicen modificaciones en ese atributo. Lo anterior se aplica a todos los objetos que contengan el atributo. En la versión beta 2, el usuario no puede usar la interfaz gráfica para configurar el octavo bit.

De forma predeterminada, en Windows Server "Longhorn", la directiva de auditoría global está activada y los cambios del servicio de directorio registran las modificaciones correctas.

Reinicio de ADDS

En Windows Server "Longhorn", ADDS se puede reiniciar. Así pues, los servicios ADDS se pueden detener e iniciar sin necesidad de reiniciar el controlador de dominio. De ese modo, los administradores realizan funciones que no pueden hacerse mientras el servicio se ejecuta, por ejemplo, desfragmentar la base de datos sin conexión, sin tener que recurrir al modo de restauración de servicios de directorio.

Un controlador de dominio puede adoptar tres estados en Windows Server "Longhorn": ADDS iniciado, ADDS detenido y modo de restauración de servicios de directorio. Vamos a examinarlos.

ADDS iniciado El controlador funciona con normalidad.

ADDS detenido El servidor tiene características de un controlador en modo de restauración de servicios de directorio y de un servidor miembro unido al dominio.

Igual que el modo de restauración de servicios de directorio, la base de datos de ADDS (Ntds.dit) está sin conexión. Puede usar la contraseña del modo de restauración de servicios de directorio para iniciar sesión de forma local si no puede contactar con otro controlador de dominio.

Igual que el servidor miembro, el servidor se une al dominio. Los usuarios pueden iniciar sesión de forma interactiva o a través de la red si usan otro controlador de dominio. Sin embargo, un controlador no debería permanecer en ese estado mucho tiempo, ya que no puede tramitar las solicitudes de inicio de sesión ni replicarse a otros controladores.

Modo de restauración de servicios de directorio Este modo (o estado) no ha cambiado desde Windows Server 2003.

En el diagrama de flujo de la figura 6 apreciará cómo un controlador que se ejecuta en Windows Server "Longhorn" puede pasar de un estado a otro.

Figure 6 Un controlador de dominio en Windows Server 'Longhorn' puede pasar de un estado a otro entre tres estados posibles

Figure 6** Un controlador de dominio en Windows Server 'Longhorn' puede pasar de un estado a otro entre tres estados posibles **

¿Busca más información?

Resulta imposible explicar en un breve artículo las nuevas características de ADDS en Windows Server "Longhorn". Pero, como hemos visto, las nuevas funciones de Active Directory le resolverán bastantes problemas que antes tenían difícil solución, si la tenían. A medida que se vaya acercando la salida al mercado de la nueva versión del producto, tenga por seguro que pondremos a su alcance más documentación. Por ahora, qué mejor lugar para buscar información durante la fase beta que el sitio web de Windows Server "Longhorn".

Byron Hynes trabaja en el grupo de asistencia al usuario de Windows Server, en Microsoft. También ha trabajado de consultor y profesor. Además cuenta con un amplio currículum, donde se incluye la dirección de una red troncal regional de Internet, la solución de problemas en aplicaciones cliente-servidor y compatibles con Web, así como el diseño de esquemas de bases de datos, infraestructuras de red y modelos de seguridad. Puede ponerse en contacto con él en bhynes@microsoft.com.

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