El Blog de Quilez

Ya hace algunas semanas que tenemos entre las manos la Consumer Preview de Windows 8, tanto en su versión cliente como en la versión servidor (Server 2012). Si he de ser sincero, cuando vi por primera vez el nuevo interfaz metro, con la Developer Preview, me echó para atrás, pues aparte de feo, se me hacía incómodo de manejar. No voy a profundizar aquí sobre el tema metro, pues creo que tiene tantos fans como detractores, pero es lo que hay y Microsoft no lo va a cambiar de aquí a la versión final. La verdad es que te terminas acostumbrando, y si no quieres salir del escritorio clásico, tampoco cuesta tanto hacerlo.

Pero independientemente de que te guste o no el sustituto del menú de inicio, la verdad es que Windows 8 está lleno de novedades verdaderamente interesantes, y en particular en la versión servidor son más que suficientes para que valga la pena la actualización.

A continuación voy a enumerar algunas de las novedades que trae el nuevo sistema operativo, y por las que vale la pena planear la migración a esta nueva versión.

HYPER-V v3

La nueva versión de HV trae las siguientes nuevas características:

  o Host: hasta 160 procesadores lógicos y 2 Tb RAM

  o Máquinas Virtuales: hasta 32 procesadores virtuales y 1 Tb RAM

  o Soporte arquitectura NUMA (para máquinas multiprocesador)

  o Mejoras en la gestión de memoria

  o Soporte para discos con sectores de 4 Kb

  o Almacenamiento de vhx,s en SMB shares

  o Nuevo formato de disco vhxd (mejoras de rendimiento, 16 Tb, mejoras anticorrupción en caídas de corriente, estructura adecuada a discos con sectores grandes)

Ya no es necesario exportar una máquina virtual previamente a su importación en otro host. Esto es mucho más práctico y permite recuperar más rápido las máquinas virtuales alojadas en un servidor caído.

· Virtual switches. Si siempre les habíamos llamado así, ¿por qué han tardado tanto en cambiar el nombre?

· Virtual SAN. Permite a las máquinas virtuales acceder directamente a una SAN de fibra óptica, sin depender del host. Permite mover máquinas virtuales de host sin perder el acceso a la SAN.

· Live Migrations. Nos va a permitir migrar una máquina virtual a otro servidor en caliente, sin que los usuarios pierdan acceso a la misma.

· Réplica a través de LAN/WAN, SAN o SMB Share. Con esta característica podemos tener una réplica en otro Hyper-V de una máquina virtual, y que ésta pase a dar servicio en caso de fallo de la original.

· Mejoras para soportar controladores de dominio en máquinas virtuales. Se ha mejorado la sincronización de ntp directa al reloj del host, evitando fallos de sincronía, y también se ha implementado una mejora sustancial en la gestión de instantáneas, evitando las inconsistencias causadas por forzar un DC a volver al estado de una instantánea anterior.

· Hyper-V metering. Permite evaluar el costo de uso de recursos por las máquinas virtuales por parte de los usuarios.

ReFS (Resilient File System)

· Mantiene principales características de NTFS: ACL,s, Enlaces, Bitlocker, etc. No dispone de cuotas de disco ni encriptación a nivel de fichero. Tampoco deduplicación. La verdad es que la falta de estas características puede echarnos para atrás a la hora de montarlo en un servidor de archivos, en particular la falta de cuotas de disco, pero es una primera versión, que evolucionará con el tiempo y terminará añadiendo (esperemos) las funcionalidades que nos son imprescindibles. No obstante, para otros usos, como albergar bases de datos o máquinas virtuales, por ejemplo, es totalmente funcional.

· Concepto de “Integrity Streams” para evitar la corrupción de ficheros. Cuando se modifica un fichero, el nuevo fichero se guarda en otros sectores del disco distintos del fichero original, lo que permite revertir al estado anterior en caso de corrupción.

· “Scrubbing” feature. En combinación con los storage spaces, hace un expurgado de todas las copias de un fichero en los Storage Spaces, y compara sus metadatos. Si se encuentra un fichero corrupto, se sustituye automáticamente por una copia buena.

· Solo está implementado por ahora en versiones servidor, y no soporta particiones de arranque (por ahora). En un futuro se implementará en las versiones cliente de Windows 8, probablemente en un Service Pack o como actualización independiente.

· Al hacer un “check and repair” sobre la marcha, evitamos los tiempos fuera de servicio de NTFS mientras hacemos un chkdsk offline.

Storage Spaces

· Organización de discos físicos en “Storage Pools”, y “virtual disks” o “Spaces”, que se ven como un único disco lógico, y que pueden tener distintas tecnologías (USB, SATA, SAS). En un “Pool” podemos crear uno o varios “Spaces”.

· Dispone de características de paridad y mirroring.

    o Paridad: almacena información adicional para permitir recuperar datos en caso de error

    o Mirroring: se asegura de que la información se almacena en al menos dos discos físicos

· El tamaño del volumen lógico puede ser mayor que la suma de los discos iniciales, y se puede aumentar con posterioridad.

· “Thin provisioning”: cuando el SO vea que necesita más espacio físico, pedirá que se añada un disco.

SMB 3.0

El protocolo SMB se actualiza a la versión 3, y presenta las siguientes nuevas características

· SMB for Server Applications. El nuevo SMB está optimizado para aquellas aplicaciones que pueden alojar datos en SMB Shares, tales como SQL Server o Hyper-V. En determinados escenarios va a  rivalizar con el almacenamiento por Fibra, a un coste menor y más sencillo de implementar.

· Activo-Activo File Shares. En Server 2008 R2 teníamos el modelo Activo-Pasivo, en el que en un cluster con un File Share solo uno de los nodos estaba activo. En Server 2012 se añade el tipo File Server For Scale-Out Application Data, que permite que un Share esté activo en varios nodos. Está pensado para aplicaciones tipo SQL Server o Hyper-V.

· SMB Direct (SMB over Remote Direct Memory Access (RDMA)). Permite transferencias directas de datos de memoria a memoria entre los procesos de origen y destino, con mínima latencia y uso de CPU. Para ello es preciso que las tarjetas de red de ambos servidores soporten RDMA.

· SMB Multichannel. Esta característica permite aprovechar la disponibilidad de varias conexiones de red para sumar ancho de banda en el acceso a los shares de un servidor, así como tener tolerancia a fallos de red mediante el uso de múltiples rutas de acceso al recurso compartido.

· Failover transparente de nodos mejorado para mejorar la alta disponibilidad en el acceso a los SMB Shares.

· VSS para SMB File Shares. Ahora es posible el uso de VSS (Volume ShadowCopy Service) para la creación de Shadow Copies de datos almacenados en File Shares.

· Encriptado SMB. Permite aumentar la seguridad en las transferencias de datos encriptando los datos a copiar.

· SMB Directory Leasing. Mejora el rendimiento de acceso a documentos a través de redes con altas latencias.

Soporte nativo de teaming para tarjetas de red.

Incrementa la disponibilidad de la red, rendimiento y fiabilidad, sin necesidad de instalar software de teaming de terceros. Ahora está implementado en el propio Sistema Operativo.

Conectividad a servicios de nube.

Simplifican el acceso a los recursos desde dentro y fuera de las fronteras de nuestra organización, manteniendo la seguridad de las aplicaciones y proporcionando un servicio de login único (single sing-on) a los usuarios.

· Servicios de Identidad común

· Federación de identidades

· Protección de datos

· Relaciones de confianza entre federaciones

Cross-premises connectivity: permite conectar varias LAN de nuestra organización de forma segura a través de la nube, entre ellos y con servicios alojados en la nube (p.e. subredes privadas), mediante el rol de “remote access server”. La seguridad se basa en IKEv2-IPSEC.

Flexibilidad en la instalación de servidores.

En Windows 8 se puede cambiar de server core a completo con GUI sobre la marcha, e incluso revertir de nuevo a core. Se puede comenzar con una instalación de server core e ir añadiendo roles y características conforme vayan siendo necesarias.

Offload Data Transfer (ODX)

Windows 8 incorpora un nuevo sistema de copia para movimientos de grandes volúmenes de datos, el ODX. En lugar de la copia tradicional, este sistema se basa en aprovechar el administrador de copia de datos que tenga implementado nuestro sistema de almacenamiento. ODX inicia una operación de copia mediante una lectura offload, obteniendo un token que representa los datos a copiar en origen. A continuación realiza una escritura offload con el citado token; el administrador de copia del dispositivo de almacenamiento realiza el movimiento de datos de acuerdo a la información en el token. Con este sistema se reduce considerablemente el tráfico de red y el uso de procesador. ODX se puede usar para despliegue de máquinas virtuales, migraciones masivas de datos, etc.

ODX tiene los siguientes requisitos para poder funcionar:

· El sistema de almacenamiento debe soportar ODX

· El origen y destino de los datos deben estar en el mismo sistema de almacenamiento

· Si la copia offload falla, Windows 8 realiza la copia con el sistema tradicional de lecturas y escrituras con buffer.

Novedades en el Directorio Activo

· Clonado de VM,s con DC,s virtualizados simplificado

       o Copia del vhd, script de configuración

       o Permite el despliegue rápido de DCs adicionales

       o Solo los admins del dominio pueden preparar y autorizar DCs para clonado

       o La nueva VM contacta con el DC con rol de emulador PDC, que debe ser W8

       o El PDC comprueba si la operación está autorizada, y en caso afirmativo asigna SID, nombre y contraseña a la VM, la cual completa el proceso de promoción a DC clonado.

       o http://technet.microsoft.com/en-us/library/hh831734.aspx

· Seguridad en la virtualización de DC,s

       o Detección de aplicación de instantáneas y copia de VM,s

       o Generación de un VM-GenerationID asociado al DC en VM durante el dcpromo

       o Mediante comparación del VM-GenerationID en el AD y en el DIT (Windows\NTDS) determina si es correcto: en cada reinicio del DC y en cada transacción

       o Si no coincide, descarta el RID pool actual y crea uno nuevo para evitar inconsistencias en la creación de USN

· Integración de AD DS en Server Manager

       o ADprep está integrado en la promoción con Server Manager

       o Validación de prerrequisitos antes del despliegue de DCs

       o Todo el proceso está integrado en Server Manager, también para equipos remotos

       o Construido en Powershell para consistencia entre Server Manager y línea de comandos

· AD FS (Active Directory Federation Services) ahora es un rol de W8

· Unión de Equipos al Dominio desde Internet si tiene habilitado “Direct Access”

       o Preparación del “blob” con certificados y GPOs

       o Admin aplica el “blob” offline al equipo

· Interfaz gráfico para la papelera de reciclaje del AD (en AD Administrative Center)

       o Permite recuperar objetos borrados accidentalmente (hasta 180 días)

        o Es preciso habilitar la papelera expresamente, y no tiene vuelta atrás

· Visor de Powershell scripts en AD AC (Administrative Center)

         o En AD AC un admin realiza una operación

         o El UI muestra el script powershell equivalente

         o El administrador puede copiar el resultado y usarlo en sus propios scripts

         o Reduce la curva de aprendizaje

         o Proporciona a los administradores confianza en el uso de scripts

         o Genera mayor interés en el descubrimiento de powershell

· AD AC facilita aplicación de Fine-Grained Password Policies, ya presentes desde Server 2008, permitiendo diferentes políticas de contraseñas a distintos grupos de usuarios.

· Cmdlets de Powershell para administración de AD

          o Creación y configuración de Sitios de AD, enlaces, subredes, etc

          o Configuración y supervisión de la réplica entre DCs

· AD BA (AD Based Activation)

          o Activación de clientes mediante el AD (sin necesidad de servidor KMS)

          o AD BA es un rol de W8 server

          o Puede coexistir con servidores KMS

· KCD (Kerberos Constrained Delegation) entre dominios y bosques

          o Añade KCD intra-dominios e intra-bosques

          o La autorización se hace en el back-end que posee los recursos

          o Ya no requiere permisos de admin del dominio, solo admin de la cuenta en el back-end que proporciona los servicios

· Flexible Authentication Secure Tunneling (FAST): Kerberos Armoring

          o Reduce ataques de diccionario a logons basados en contraseña

          o Proporciona protección adicional entre clientes y DCs evitando ataques de spoofing

          o El admin puede exigir FAST a todos los clientes (GPO, todos los DCs W8)

1.- DE DÓNDE VENIMOS

Antes de comenzar a instalar un dominio es preciso saber de qué se trata; para ello, lo mejor es echar un vistazo al pasado y ver cómo se han relacionado los ordenadores con Windows a lo largo del tiempo.

En los tiempos de Windows 3.1 el uso normal de los ordenadores era de forma aislada, basando los intercambios de información en soportes físicos como disquettes de 5″1/4 ó 3 «1/2, y hubo que esperar hasta la versión «Windows 3.1 para trabajo en grupo (1992)» para poder encontrar una versión de Windows enfocada hacia la cooperación en red. Esta versión basaba las comunicaciones en el uso como protocolo principal de Netbeui, un protocolo sencillo que usaba mayoritariamente mensajes de broadcast a la red, no tenía posibilidades de encaminamiento de mensajes a través de routers, pero que en aquel momento era lo más práctico dado que la mayoría de las pequeñas redes que se montaban estaban compuestas por unos pocos ordenadores unidos por cable coaxial.

Con Windows para Trabajo en Grupo se introducía en Windows el concepto de compartición de recursos por la red, de forma muy simple, y con la posibilidad de compartir carpetas mediante contraseñas o, si el equipo se unía a un dominio Windows (que comenzaron a existir casi simultáneamente), estableciendo permisos a usuarios. El protocolo tcpip todavía tardaría unos años en implementarse en Windows.

Evidentemente, había otros sistemas de conexión en red, de los que el más común de encontrar en los 90 era el sistema operativo de red Novell Netware, con el que se extendió en las redes pequeñas y medianas el concepto de Directorio. Microsoft, consciente de la necesidad de organizar las comunicaciones en red, centró sus desarrollos en la familia Windows NT, que apareció en su versión 3.1 allá por el verano de 1993, con una versión Workstation y una Servidor.

Y aquí es donde aparece la gran diferencia entre el Grupo de Trabajo y el Dominio. Un Grupo de Trabajo es un conjunto de ordenadores conectados en red en el que cada equipo, sea cliente o servidor, en una Unidad de Administración en sí mismo. Esto se traduce en que todas las tareas de configuración y administración que queramos hacer en los equipos de nuestro grupo de trabajo tenemos que realizarlas de forma individual en todos y cada uno de los equipos. Para redes pequeñas no supone un gran problema, pero conforme las redes van creciendo los problemas de administración se multiplican.

Además, y hasta la implantación generalizada como sistema operativo cliente de Windows 2000 profesional y posteriormente XP (Windows NT profesional, como cliente, apenas suponía un mínimo porcentaje en comparación con los Windows 9x instalados), el usuario de un ordenador tenía plenos poderes sobre el mismo, salvo que se usaran determinados programas específicos para controlar la configuración, con lo que el laborioso trabajo de configuración realizado por los administradores podía ser fácilmente saltado por los usuarios, más si tenían conocimientos de informática.

2.- DE GRUPO DE TRABAJO A DOMINIO

El trabajo en Dominio supone un cambio radical en el concepto de uso de los recursos de la red. En lugar de que cada equipo de la red sea una Unidad de Administración, éstos pasan a ser meros componentes de una única entidad, el dominio, que es en conjunto lo que podríamos llamar una Unidad de Administración Global. De esta forma, en un único punto de administración podemos definir todos los parámetros que necesitemos de comportamiento de todos los recursos que pertenezcan al dominio, y hacer que estos parámetros se distribuyan en la forma que queramos por todos los equipos del mismo.

Tareas tan simples como establecer la longitud de la contraseña de los usuarios, en un grupo de trabajo implica configurarlo en todos y cada uno de los ordenadores, y cada vez que queramos cambiar un parámetro tendremos que volver a pasar por todos los equipos. En un dominio, lo definimos es un único sitio y hacemos que se distribuyan estas modificaciones.

Otra gran ventaja que nos va a proporcionar un dominio es la gestión única de las cuentas de usuario. En un grupo de trabajo, éstas se definen localmente en cada uno de los equipos, en una base de datos de usuarios local. En un dominio, las cuentas se definen en una base de datos centralizada, lo que nos permitirá en todo momento saber el estado de cada una de ellas, y gestionar una política de cuentas común. Una gran dificultad en los grupos de trabajo es compartir recursos en red a usuarios de otros equipos. Para validarse, es preciso hacerlo definiendo en cada equipo el acceso con las credenciales de un usuario y contraseña del equipo que comparte. Si posteriormente en éste se cambia la contraseña, hay que realizar la modificación en todos y cada uno de los equipos que acceden a ese recurso. En un dominio, sin embargo, en el que desde todos los equipos del mismo se puede leer la base de datos de usuarios común, se comparten los recursos con permisos a los usuarios del dominio, y simplemente con estar en la lista de usuarios con permisos ya se puede acceder al recurso compartido, sin tener más que hacer.

Un concepto importante a la hora de trabajar en dominio es el de la pertenencia al mismo. En un grupo de trabajo, tan sólo con conectar un equipo físicamente a la red y ponerle una configuración de red adecuada, ya está en igualdad de oportunidades que los demás para poder acceder a los recursos de la red. En dominio, el primer paso que hay que hacer para poder acceder a todos los recursos del mismo es establecer la pertenencia al dominio del equipo. Es decir, que salvo determinados accesos a recursos compartidos, para aprovechar la inmensa mayoría de lo que nos ofrece un dominio es preciso primero pertenecer al mismo, proceso que podemos hacer que sea totalmente controlado por quién se hace.

El concepto de dominio en las redes Microsoft apareció de la mano de Windows NT, como una base de datos plana en la que definíamos usuarios y equipos, y roles tanto para los usuarios como para los equipos. Este primer concepto de dominio se mantuvo hasta Windows NT 4.0, y con Server 2000 cambió al modelo vigente hasta ahora con Server 2008, el Directorio Activo, en el que nos vamos a centrar.

¿Y por qué este cambio al Directorio Activo? Como he dicho antes, la base de datos de un dominio NT era plana, lo que quiere decir que todos los usuarios y equipos se definen y ven en una única lista, todos juntos. Para dominios pequeños no supone gran problema, pero si empieza a crecer el número de usuarios y equipos, la dificultad de su gestión aumenta de forma considerable. Por otro lado, si queremos relacionar recursos de nuestro dominio con otros dominios de nuestra misma organización, es preciso realizar expresamente una serie de operaciones para poder establecer las relaciones de confianza adecuadas, y en ningún momento vamos a poder gestionar una política común a todos los dominios de nuestra organización.

Con el concepto de Directorio Activo (AD = Active Directory) disminuyen en gran manera esas dificultades; por un lado, en un dominio vamos a poder organizar los recursos en una estructura similar a un árbol de carpetas de archivos, y establecer parámetros comunes a los componentes de cada rama. Por otro lado, la estructura ya no va a estar ligada solamente a un único dominio, sino que comenzaremos definiendo una superestructura común para toda nuestra organización, en la que colgarán todos los dominios que necesitemos para nuestras empresas y departamentos, permitiendo por un lado tener organismos con administración independiente de los demás (cada dominio), pero manteniendo un margen de gestión común a todos los elementos de nuestra organización.

3.- CONCEPTOS

A esta superestructura que va a albergar todos los recursos de nuestra organización la vamos a llamar bosque (o bosque de dominios). Puede tener un único dominio o varios, según nuestras necesidades. El bosque se caracteriza por tener un esquema (que ahora veremos lo que es) común para todos los dominios del mismo, y gestiona las relaciones entre todos los componentes de cualquier dominio perteneciente al mismo.

El sistema más simple es el de un bosque compuesto por un dominio único. Realmente ésta es la situación más común, ya que gracias a la alta capacidad de organización de un dominio en el Directorio Activo, ha disminuido en gran manera la necesidad en las empresas de mantener dominios independientes para sus componentes.

Este primer dominio del bosque, que se crea al mismo tiempo que este último, es lo que llamaremos «Dominio Raíz del Bosque». Es un dominio más, similar a todos los que posteriormente podamos añadir al bosque, pero tiene dos diferencias fundamentales con el resto: la primera, que una vez creado ya no se puede eliminar mientras queden otros dominios en el bosque, y la segunda, que en éste dominio raíz se gestionan de forma única para todos los dominios del bosque el esquema común y la nomenclatura de todos los dominios del bosque (controla los nombres para evitar que en un momento dado pudiéramos crear un dominio con un nombre ya existente en el bosque).

El bosque está compuesto de objetos. Desde cada dominio definido en el bosque hasta el último usuario o impresora son objetos componentes de esta estructura. Cada uno de estos objetos tiene una serie de atributos, que definen las características de los mismos. Así, por ejemplo para un usuario determinado, le habremos definido un nombre, apellidos, teléfono y un sinfín de atributos más que le identificarán en bosque de forma única.

El esquema es una base de datos del Directorio Activo donde se definen los distintos tipos de objetos que podremos crear en el bosque. A cada uno de estos tipos le llamaremos «Clase», y en ella estarán definidos todos los atributos que luego rellenaremos con los datos propios que identifican al objeto. Por poner un ejemplo, en el esquema tenemos la clase «User», la cual tiene definidos, entre muchos otros, los atributos «Name» y «Phone». Cuando desde la herramienta adecuada decimos al sistema que cree una cuenta de usuario, el sistema crea en AD un objeto usuario basado en la clase «User», con espacio para albergar todos los atributos que lo identifican. En el momento de crear el usuario, rellenamos los datos de aquellos atributos que son obligatorios, y tanto entonces como en cualquier momento podemos ampliar la información rellenando aquellos que no lo son. El hecho de que el esquema sea común a todos los dominios del bosque hace que cuando creamos una cuenta de usuario en un dominio, ésta tiene exactamente los mismos atributos y con las mismas características que las creadas en cualquiera de los otros dominios.

El esquema es algo dinámico. Cuando creamos un bosque, por ejemplo, con un servidor 2003, este Sistema Operativo trae una determinada versión del esquema, por lo que los atributos de los objetos que creemos serán los que estén definidos en esa versión. Posteriormente podemos instalar en el bosque un software, como Exchange, que amplía el esquema para añadir clases completamente nuevas, y añade nuevos atributos a clases ya existentes (por ejemplo, para añadir atributos relacionados con el correo a la clase «User»). Una vez hecha esta modificación del esquema, los objetos nuevos y los creados con anterioridad pasarán a disponer de estos nuevos atributos, con lo que habremos aumentado la funcionalidad de nuestra organización.

Generalmente, cada nueva versión de sistema operativo servidor viene preparada con una versión nueva del esquema de AD, más completa que las anteriores, y siempre conteniendo todo lo anterior más lo nuevo. Cuando creamos un bosque nuevo con la última versión, su Directorio Activo tiene automáticamente el último esquema definido. Sin embargo, si a un bosque definido con el esquema de una versión determinada de Windows, por ejemplo Server 2003, queremos añadirle determinadas funcionalidades correspondientes a versiones más modernas (2003 R2 ó 2008), como que pueda albergar controladores de dominio con Server 2008, nos será preciso en primer lugar ampliar el esquema actual con la versión correspondiente a la última versión que necesitemos tener.

Una vez hemos creado el primer dominio, es posible añadir más dominios al bosque. Sin embargo, lo más importante en esto es realizar a priori una planificación exhaustiva de lo que necesitamos. Tan malo es crear un único dominio mal organizado como empezar a crear subdominios sin ton ni son, que luego complican en exceso la administración centralizada de los mismos.

El concepto que tenemos que tener más en cuenta a la hora de decidir nuestra estructura de dominios es el de la administración única de los objetos de los mismos. Y por única no quiero decir que la haga un solo administrador, pues se pueden delegar permisos de administración a partes del dominio, sino que se tiene una política de administración conjunta para todo el dominio (mismas políticas de contraseñas, administradores centrales del dominio, gestión de las políticas comunes y particulares, etc). Cuando realmente necesitamos tener independencia total, aunque manteniendo la pertenencia al bosque, es cuando crearemos dominios adicionales en el bosque.

Una vez hemos decidido una estructura de dominios en el bosque, vemos que la topología de los mismos es función de la nomenclatura que establezcamos. Partiendo siempre del nombre que hayamos dado al dominio raíz, en el ejemplo «gericom.es», si necesitamos mantener el mismo como sufijo de otros, hablaremos de subdominios (p.e. sevilla.gericom.es), o dominios padres e hijos. Entre todos los que cuelgan de un mismo padre forman lo que en AD se llama un árbol de dominios. En el caso de que queramos crear dominios con una nomenclatura que no esté ligada al dominio raíz, éstos formarán nuevos árboles de dominios (que pueden ser árboles de un único dominio) dentro del bosque.

Un primer detalle a tener en cuenta con esta estructura de dominios es que, dando los permisos adecuados, cualquier usuario de cualquier dominio puede acceder a cualquier recurso ofrecido en cualquiera de los dominios del bosque.

Fijémonos en el gráfico anterior, y en particular en los nombres dados a los dominios. La estructura de nombres coincide con el tipo de nomenclatura de dominios DNS. Aunque son cosas distintas, la estructura de nombres de dominio en el Directorio Activo está totalmente ligada a una estructura de dominios DNS del mismo nombre. De hecho, gran parte de las funcionalidades del Directorio Activo dependen totalmente del servicio DNS y su correcta configuración.

Por fin, en esta estructura podemos definir el dominio como un conjunto de equipos, usuarios y otros recursos que se administran como una entidad única. Debe disponer de al menos un servidor Windows que realice las funciones de Controlador de Dominio, que es un servidor que aloja los servicios correspondientes al Directorio Activo en el dominio.

Hasta ahora hemos hablado de una estructura lógica del bosque, en la que, por ahora, hemos organizado los recursos en una estructura de dominios, pero hay que notar que esta estructura no tiene absolutamente ninguna relación con la estructura física de nuestra red. Del mismo modo podemos tener objetos de un mismo dominio repartidos por múltiples redes, como elementos de distintos dominios dentro de la misma red, con todas las combinaciones que queramos.

Por ello, para reflejar en el AD la estructura física de nuestra red aparece el concepto de Sitio de AD. Un Sitio es un conjunto formado por una o varias subredes que estén unidos entre sí por enlaces de alta capacidad. Nos permitirán por un lado gestionar de forma eficiente las réplicas del AD entre los servidores del propio o distintos Sitios, y también permiten que el inicio de sesión de los usuarios se realice en controladores de dominio del propio Sitio del equipo del usuario de forma preferente.

4.- CREAR EL PRIMER DOMINIO

Ahora que ya hemos visto algunos conceptos, es el momento de crear nuestro primer dominio. Para ello necesitamos una máquina adecuada y el software servidor, sea Server 2000, 2003 ó 2008. De todos los servidores que montemos en un dominio, al menos uno tiene que configurarse como Controlador de Dominio (DC, de Domain Controller), aunque es más seguro disponer de más de uno, más aún si tenemos nuestro dominio repartido en varias redes o Sitios de AD. A los servidores del dominio que no sean DC,s les llamaremos «Servidor Miembro».

Para que un servidor pueda ser promovido a Controlador de Dominio es preciso que tenga instalados los archivos necesarios para ello. En Server 2000 y 2003 lo están por defecto, mientras que en Server 2008 es necesario primero usar el asistente de instalación de roles para añadir los servicios del Directorio Activo. Por otro lado, he comentado antes que el Directorio Activo depende al cien por cien de una estructura DNS, por lo que será preciso crear ésta de forma adecuada. Aunque podemos hacerlo a mano, la verdad es que lo mejor es dejar que el propio asistente instale y configure el servicio «Servidor DNS» en el equipo durante el propio proceso de promoción. De hecho, en Server 2008, si le instalamos el rol de servicios de AD, veremos que ni siquiera nos va a permitir instalar el rol de servidor DNS por nuestra cuenta, sino que lo hará él mismo cuando promocionemos el servidor.

Con el servidor iniciado, y configurada su tarjeta de red con una dirección IP fija y poniéndole como servidor DNS principal a sí mismo, pinchamos en Inicio – Ejecutar y tecleamos el comando «dcpromo».

Tras comprobar que se han instalado previamente los archivos correspondientes al rol de servidor de directorio activo, se inicia el asistente. Para controlar todos los aspectos seleccionaremos la instalación en modo avanzado.

Nos muestra una advertencia de compatibilidad con determinados clientes antiguos, que generalmente podremos ignorar. Si nos afecta, el artículo indicado tiene información más completa.

Lo primero que nos pregunta el asistente es qué es lo que queremos hacer. Desde crear un bosque nuevo, a añadir un nuevo controlador de dominio a uno ya existente, crear un subdominio, o crear un nuevo árbol en un bosque existente.

En nuestro caso, como estamos creando el bosque desde cero, seleccionaremos la opción de crear un dominio nuevo en un bosque nuevo.

El resto de opciones en esta pantalla está muy claro: si queremos añadir más controladores de dominio a un dominio que ya existe para tener redundancia usaremos la opción de la segunda imagen; para crear un árbol de dominios nuevo que pertenezca a un bosque existente, la tercera y para crear un subdominio de otro que ya existe la cuarta.

El siguiente paso es dar un nombre FQDN (Full Quallified Domain Name) al bosque, que coincide con el nombre del dominio raíz. Debemos usar un nombre con puntos intermedios, ya que en caso contrario aparecen algunos problemas secundarios posteriormente, y procuraremos que el nombre sea representativo de nuestra organización.

Una vez hecho esto, tenemos que seleccionar el nombre NETBIOS del dominio. Nos ofrece por defecto la primera parte del nombre FQDN, pero podemos poner cualquier nombre que cumpla las reglas de nombres NETBIOS, y por supuesto, que no esté ya en uso.

Como vemos, y a pesar de que ya cuando se lanzó Windows 2000 con el Directorio Activo se pretendía eliminar progresivamente NETBIOS y basar todo en resolución de nombres DNS, la realidad es que todavía hay muchas aplicaciones que se basan en resolución de nombres NETBIOS. Es posible montar un entorno cien por cien DNS, pero a la hora de la verdad está limitado, ya que no tendremos certeza de que funcionen correctamente aplicaciones que requieran resolución NETBIOS (hay antivirus de red que se basan en esto para gestionar los clientes en que están instalados, por ejemplo), y algunas ni se instalarán (El propio Microsoft System Center Configuration Manager basa gran parte de su código en NETBIOS).

La siguiente decisión que tenemos que tomar es la elegir el nivel funcional, tanto del bosque como del primer dominio. Por explicarlo en pocas palabras, un dominio o un bosque proporciona unas determinadas funcionalidades en función de la versión de sistema operativo servidor en la que se basan. A más moderno el sistema operativo, más funcionalidades aporta su directorio activo. El total de funcionalidades correspondientes a un sistema operativo en un dominio se consigue cuando todos los DCs del dominio tienen al menos ese sistema operativo, y el de un bosque se consigue cuando todos sus dominios tienen el nivel funcional correspondiente o superior.

Si montamos un dominio nuevo con un servidor 2008, lo lógico es seleccionar el nivel funcional de Server 2008 tanto para el dominio como para el bosque, salvo que necesitemos instalar expresamente un DC con un sistema operativo anterior (recalco lo de que sea un DC, ya que los servidores miembro pueden tener cualquier versión anterior).

Si partimos de un bosque con dominios en nivel 2000, éstos sólo podrán tener DCs con Windows 2000 o superior, pero aunque tengamos en el dominio DCs con 2003 ó 2008, las funcionalidades del dominio seguirán siendo las correspondientes a Windows 2000. En el momento en que hayamos migrado o actualizado todos los DCs de un dominio del bosque al menos a Server 2003 podremos modificar el nivel funcional del dominio al de Server 2003, o al de Server 2008 si ya sólo tenemos DCs con este Sistema Operativo. La operación de cambiar el nivel funcional se denomina «elevar» el nivel funcional del dominio, y una vez hecha no tiene vuelta atrás.

Para elevar el nivel funcional del bosque a Server 2003 es preciso que todos los dominios del bosque tengan el nivel funcional 2003 o superior, y para nivel funcional 2008, todos los dominios del bosque tienen que tener nivel funcional 2008. Más tarde veremos cómo se realiza la operación de elevar el nivel de dominios y bosque.

Y para el dominio, seleccionamos el nivel que deseemos

La siguiente decisión es determinar si queremos que el controlador de dominio sea servidor DNS. Para el primer DC es lo más aconsejable, aunque no imprescindible, y para el resto de DCs lo mejor es hacer primero una planificación detallada de cómo queremos nuestra topología de servidores DNS en la red.

El primer DC del bosque tiene obligatoriamente el rol de Catálogo Global del bosque (GC), que es una funcionalidad adicional de los DCs que hacemos que sean GC por la que además de toda la información de todos los objetos correspondientes a su dominio, también albergan un subconjunto de los atributos de todos los objetos de todos los dominios del bosque.

Por fin, y sólo en los servidores 2008, aparece la posibilidad de que el DC sea de tipo RODC (Read Only Domain Controller), muy útil en situaciones como la de enviar un DC a una sede remota con conexión intermitente en la que no queremos que se pueda modificar nada del directorio, sino tan sólo usarlo. Como se ve en la figura, obviamente en primer DC de un dominio tiene que ser obligatoriamente de tipo lectura/escritura, de ahí que la opción esté desactivada.

Al pulsar «siguiente», el equipo ha detectado que tiene direcciones ip dinámicas, y nos avisa que deben ser estáticas. En Server 2000 y 2003 no suele aparecer el mensaje, ya que generalmente habremos puesto previamente una dirección ip fija (aunque si se nos ha olvidado, es el momento de solventarlo). Sin embargo, en Server 2008 nos aparece casi siempre, aunque le hayamos puesto una ipv4 fija, ya que éste también considera las ipv6, y salvo que lo sepamos y le hayamos configurado una ipv6 fija, normalmente no la tendrá configurada así y nos avisará, aunque sin especificar. Si no vamos a usar ipv6 en nuestra red, podemos ignorar el mensaje y decirle que sí, que siga aunque tenga una ip asignada dinámicamente. Eso sí, asegurarse primero de que la ipv4 sí se la hemos configurado fija.

Si detecta que nuestra configuración DNS está integrada en una topología DNS existente, intentará ubicarse en ella. Esto, que cuando creamos el bosque por primera vez no suele tener mayor importancia, es trascendental cuando estamos creando dominios secundarios o nuevos árboles en un bosque existente. Si no es capaz de detectarlo el propio asistente y crear las delegaciones adecuadas, tendremos que crearlas a mano en los servidores DNS que estén por encima en la cadena DNS.

En el caso del primer dominio del bosque, obviamos el mensaje y le decimos que continúe.

Lo siguiente es elegir la ubicación de los archivos del AD. Está recomendado usar discos distintos para cada una de las opciones con el objeto de mejorar el rendimiento (usar distintas particiones del mismo disco no mejora nada), pero la realidad es que salvo en ADs muy grandes y con muchas modificaciones y con gran frecuencia, lo normal es que se puedan poner todos en la misma partición sin que se note en el rendimiento.

La siguiente pregunta es la contraseña para cuando queramos reiniciar el servidor en el modo de restauración de los servicios de directorio. Esta contraseña no tiene nada que ver con la del usuario administrador, y sirve sólo para iniciar en el modo indicado. Este modo de arranque, sólo disponible en los DCs, sirve para realizar tareas de mantenimiento, como, por ejemplo, una restauración del AD en modo autoritativo.

El asistente nos muestra un resumen de lo indicado, tras lo cual comenzarán los trabajos de promoción del servidor a Controlador de Dominio, tal como indican las imágenes a continuación.

Una vez finaliza el proceso nos muestra el mensaje de haberlo hecho, tras lo cual reiniciaremos el servidor.

Tras el reinicio ya podremos iniciar sesión con un usuario administrador del dominio. En el caso del primer DC del bosque, su contraseña coincide con la del usuario «administrador» local que tuviéramos en el equipo antes de promocionarlo.

Es muy cómodo que al pinchar con el botón derecho del ratón sobre cualquier archivo nos aparezca una opción que lo edite automáticamente con el block de notas. Para ello no hay más que añadir un valor al registro, por ejemplo creando un archivo con extensión .reg con el siguiente contenido y combinándolo con el registro.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell]

[HKEY_CLASSES_ROOT\*\shell\Block_Notas]

[HKEY_CLASSES_ROOT\*\shell\Block_Notas\command] @=»notepad.exe %1″

Usar VBScript para hacer scripts de inicio de sesión es mucho más potente que ejecutar archivos .bat con comandos de DOS. Para asignar estos scripts a los usuarios lo podemos hacer de varias maneras, en función de si son W2000 o posteriores, o si tenemos equipos con NT4 y Windows 9x en nuestro dominio.

En Usuarios y Equipos de AD podemos editar las propiedades de cada usuario, y en su perfil le podemos especificar un archivo de inicio de sesión, que habremos colocado previamente en el recurso NETLOGON de un DC. Este archivo se le ejecutará siempre que inicie sesión. Sin embargo, hemos de tener en cuenta que los equipos previos a Windows 2000 no pueden ejecutar directamente archivos con extensión .vbs, por lo que si tenemos este tipo de equipos lo que hemos de hacer es poner como script de inicio de sesión un archivo .bat, que también colocaremos en el NETLOGON, y que contendrá una linea como la siguiente para lanzar el .vbs

WSCRIPT %0\..\miscript.vbs

También podemos aprovechar ese archivo bat para ejecutar comandos DOS, como para sincronizar de forma sencilla la hora con un DC. Esto en W2000 no es necesario, pero los Windows 98 no se sincronizan automáticamente con el dominio, por lo que nos vendrá bien. Podemos hacerlo con la siguiente linea, que en los W2000 en que no inicie sesión un administrador no se ejecutará, aunque tampoco parará el script.

NET TIME \\SERVIDOR /SET /YES

El archivo .vbs nos va a permitir hacer muchas cosas, y personalizar el script según nuestras necesidades, pero lo más básico que haremos con él es conectar unidades de red en nuestro equipo asignándoles letras de unidad. Un  ejemplo de código para empezar que pondríamos en el archivo miscript.vbs que lanza el .bat sería como sigue

‘********************************************** Option Explicit Dim oNet, sUser, startTime

On Error Resume Next

‘ Objeto Red Set oNet = CreateObject(«WScript.Network»)

‘ Obtenemos el login de usuario. En Windows 9x, el usuario puede no estar todavía autentificado ‘ cuando el script comienza a ejecutarse; En ese caso reitera cada 1/2 segundo sUser = oNet.UserName          ‘En minúsculas

startTime = Now

Do While sUser = «»

If DateDiff(«s», startTime, Now) > 600 Then

Wscript.Quit

Wscript.Sleep 500

sUser = oNet.UserName

Loop

‘ Mapeado de la unidad F particular de cada usuario

oNet.RemoveNetworkDrive «U:»

oNet.MapNetworkDrive «U:», «\\servidor\usuarios\» & sUser

oNet.RemoveNetworkDrive «X:»

oNet.MapNetworkDrive «X:», «\\servidor\comunes\»

‘**********************************************

Notar que en los equipos con Windows 2000 o superior es necesario eliminar el mapeo de la unidad antes de volver a asignarla, pues si no lo ignora y deja la asignación anterior que hubiese con esa letra.

Por fin, si no tenemos equipos con Windows 9x o NT4 podemos especificar directamente el archivo .vbs como script de inicio de sesión, y también podemos asignar este tipo de archivos mediante GPO (configuración de usuario – secuencia de comandos: inicio de sesión / cierre de sesión), procedimiento por el que podemos asignar más de un script.

Con el siguiente código conseguimos poner en una variable «dirip» la dirección IP actual que tenemos.

for /f «tokens=1,2* delims=:» %%i in (‘ ipconfig ^| find «IP» ‘) do set dirip=%%j

set dirip=%dirip:~1%

Si no queremos usar programas complejos como el Microsoft Operations Manager, podemos recurrir a la herramienta pslist, que se puede descargar gratuitamente de http://www.sysinternals.com/ProcessesAndThreadsUtilities.html , y crear un bat que tenga el siguiente código:
for /f «tokens=1,2* delims= » %%i in (‘ pslist wmplayer ^| find «wmplayer» ‘) do set prog=%%i if %prog% == wmplayer goto fin net send pc01 «WMP no está cargado en memoria» :fin
Primero hay que ejecutar pslist en una ventana de comando y ver entre todos los procesos cual es el nombre del que se quiere monitorizar. En el código del ejemplo he puesto el wmplayer, que es el reproductor de Windows Media. Sustituya wmplayer por el nombre del proceso, y pc01 por el nombre del equipo en que se quiera recibir la alerta (el servicio messenger tiene que estar habilitado y arrancado en los dos equipos). Ahora tan sólo hay que usar el programador de tareas para que el bat se ejecute periódicamente en el equipo que tiene el programa. También se puede aprovechar que pslist se puede ejecutar en remoto y cambiar el código al siguiente, en el que además si el proceso no está en memoria, lo carga:
for /f «tokens=1,2* delims= » %%i in (‘ pslist \\EQUIPOREMOTO wmplayer ^| find «wmplayer» ‘) do set prog=%%i if %prog% == wmplayer goto fin net send pc01 «WMP no está cargado en memoria» start wmplayer.exe :fin

En el Directorio Activo, todos los controladores de dominio son iguales (al menos lo eran hasta Server 2008), a diferencia de NT4 en que un servidor era el principal (PDC) y el resto eran copias de sólo lectura de la base de datos del dominio (los BDC). Sin embargo, hay una serie de roles que sólo pueden ser ejercidos por un único DC, al tratarse de funciones que requieren ser únicas en el bosque o dominio. Por así decirlo, el DC que ostenta en un momento dado un rol maestro realiza funciones de moderador o director de esa función. Un rol maestro puede transferirse de un DC a otro, incluso forzarse el cambio caso de desastre del DC que lo ostenta, pero en ningún momento puede haber más de un DC con el mismo rol. A estos roles se les conoce como FSMO (Flexible Single Master Operations). Los tipos de roles maestros de operaciones son cinco, dos a nivel bosque y tres en cada dominio del mismo.

1) Bosque: A este nivel, y localizados siempre en algún DC del dominio ra´´iz del bosque (el primero que montas cuando lo creas) hay dos, el maestro de esquema y el maestro de nombres de dominio.

– Maestro de Esquema: es el DC que dirige todas las operaciones de cambio en el esquema del AD (la definición de clases de objeto, con sus atributos). Cuando se hace una modificación al esquema, siempre se realiza sobre el maestro de esquema (aunque la consola la lancemos desde otro DC), y a continuación se replica a todos los DCs del bosque. Esto permite asegurar que el esquema sea único para todo el AD.

– Maestro de Nombres de Dominio: El DC que ostenta este rol es el que controla que los nombres propuestos para nuevos dominios en el bosque no estén en uso, y además que la topología de nombres sea la correcta (por ejemplo, si tenemos un árbol con un dominio de nombre «españa.es», no podremos crear otro árbol de nombre «sevilla.españa.es», sino que tendrá que ser un subdominio del anterior. 2) Dominio: En cada dominio del bosque hay tres roles maestros, que pueden ser ejercidos por el mismo o por distintos DCs del dominio. Son los siguientes:

– Emulador de PDC: Entre otras, realiza todas aquellas tareas que los equipos anteriores a Windows 2000 esperaban que se realizasen en un PDC de NT4. Entre otras cosas, cuando un DC recibe una modificación de la contraseña de un usuario, al primero que se lo replica es al PDC, quien además ejerce de árbitro cuando se produce una autenticación incorrecta de la contraseña de un usuario (antes de generar el mensaje de error, el DC en que se valida la contraseña errónea le pregunta al PDC por si éste ya hubiera recibido un cambio de la contraseña).   Por otro lado, el PDC de un dominio es la cabeza jerárquica en el mismo para la sincronización de tiempo (los clientes sincronizan con el DC con que se validan, y éstos con el PDC de su dominio). A su vez, el PDC del dominio raíz del bosque es la cabeza jerárquica de sincronización de tiempo para todos los PDCs de los dominios del bosque. Normalmente, éste PDC y no otro es el que configuraremos para sincronizar con una fuente externa de tiempo fiable (si es que lo necesitamos).   También, cuando editamos una GPO desde cualquier equipo, por defecto se hace contra la copia almacenada en el PDC del dominio y se guardan los cambios en el mismo, tras lo cual se replican al resto de DCs.

– RID Master (Relative Identifier Master): Como he comentado antes, al ser todos iguales, en cualquier DC del dominio se pueden crear objetos del AD.  Al crear un objeto de tipo usuario, grupo o equipo se le asigna un identificador único de seguridad en el dominio (SID). Este identificador consta de una parte única para todo el dominio y de otra variable dentro del mismo, que le asigna el DC en que se crea el objeto. Para evitar que dos DCs distintos generen el mismo SID para un objeto, el DC que hace de RID master asigna al resto de DCs del dominio un número de IDs (un RID Pool), de tal forma que son distintos en cada DC. Cuando a un DC se le está acabando el número de IDs disponibles, solicita al RID Master que le asigne un nuevo pool de RIDs. Si el RID Master cayese y no forzásemos que otro DC pasase a llevar este rol, llegaría un momento en que no se podrían crear más objetos en el dominio por falta de IDs.

– Maestro de Infraestructura: Es el DC responsable de actualizar en otros dominios de su mismo bosque aquellos objetos del dominio propio que son referenciados por objetos de otros dominios. Por poner un ejemplo claro que lo explique, podemos tener un grupo de usuarios en un dominio, al que pertenecen cuentas de usuario de otros dominios. Si en un momendo dado cambiamos el nombre al grupo, el Maestro de Infraestructura es el encargado de notificar a los de otros dominios de este cambio. En un dominio, el Maestro de Infraestructura no puede ser al mismo tiempo Catálogo Global, salvo en el caso de un bosque de dominio único, debido al modo como ese DC consulta a los de otros dominios sobre los cambios de este tipo.

Los cambios de servidor para cada rol maestro se pueden hacer de dos formas: con las distintas herramientas gráficas de administración del AD (Usuarios y Equipos de AD, Sitios y Servicios de AD, Dominios y Confianzas de AD y cargando en una consola mmc el complemento de esquema), o bien con la herramienta de linea de comandos «ntdsutil». Para que te aparezca esta última tienes que instalar las support tools del CD del servidor. Además, con las herramientas gráficas se puede cambiar un rol de servidor siempre que tanto el de origen como el de destino estén en linea. Si el original hubiese caído, el forzamiento del cambio (seize) sólo se puede hacer con ntdsutil, siguiendo los pasos que describe el siguiente artículo:  http://support.microsoft.com/kb/255504

Por fin, hay otro rol que no se define como tal como Maestro de Operaciones, que es el de Catálogo Global. En cada dominio tiene que haber al menos uno (el primero que promocionamos al crear un dominio lo será automáticamente, pero al resto se lo tendremos que especificar expresamente en las propiedades del DC en Sitios y Servicios de AD). Un Catálogo Global es un DC del dominio que además de tener toda la información de los atributos de todos los objetos de su propio dominio, tiene un subconjunto de los atributos de todos los objetos de todos los dominios del bosque. La réplica de estos datos se realiza de forma independiente entre los Catálogos Globales. Por defecto, el AD tiene marcado en su esquema cuales son los atributos de cada clase de objeto que se tienen que replicar entre Catálogos Globales, pero esto lo podemos modificar si fuera necesario editando las propiedades de cada atributo en el maestro de esquema del bosque. Existen unas reglas para determinar cuantos DCs deben ser Catálogos Globales. En un bosque de dominio único, todos los DCs se pueden configurar como GCs, incluso el Maestro de Infraestructura, ya que éste no tiene realmente nada que hacer como tal. En un bosque de múltiples dominios, en cada Sitio de AD (definido en Sitios y Servicios de AD) tendremos que configurar como GCs la mitad de los DCs de cada dominio en ese Sitio. Además, en este caso el Maestro de Infraestructura de cada dominio no debe ser Catálogo Global, salvo que un dominio no tuviese más que un único DC.