Windows Server 2012 R2Administración avanzada Este libro está dirigido a aquellos administradores e ingenieros de sistemas que deseen adquirir conocimientos avanzados sobre Windows Server 2012 R2 y dominarlo en profundidad. Responde a la necesidad de disponer de una mayor experiencia por parte del lector, tratando con profundidad, desde un punto de vista teórico y práctico, roles imprescindibles tales como Active Directory, DFS, Hyper-V, BitLocker, el reparto de carga o incluso la VPN. También se describen todas las especificidades de Windows Server 2012 R2 (como, por ejemplo, los avances en términos de virtualización, de seguridad, los Work Folders, IPAM, Workplace Joint, la Experiencia con Windows Server Essentials, etc.), para permitirle aprovechar al máximo el potencial de esta versión. Desde el despliegue, pasando por el clustering, y hasta la virtualización, este libro es el compañero ideal para aprender hasta el último detalle de esta versión de Windows Server. Aporta un alto nivel de experiencia y su vocación es convertirse en una obra de referencia. Los autores ponen a disposición del lector sus conocimientos en tecnologías Microsoft (MVP, MCSE y/o MCITP, MCSA) y su experiencia, muy significativa, en infraestructuras integrales y complejas, para proveer un nivel de calidad que respete las mejores prácticas del mundo profesional de la empresa.
Los capítulos del libro: Introducción – Dominio Active Directory – Arquitectura distribuida de acceso a los recursos – Alta disponibilidad – Implementar los servicios de Red de la empresa – La evolución de la red – Servicios de Escritorio remoto – Acceso remoto – Aplicaciones de Internet – Reducir la superficie de ataque – Consolidar sus servidores – Despliegue de servidores y puestos de trabajo – Securizar su arquitectura – El ciclo de vida de su infraestructura – Prepararse para el futuro Thierry DEMAN - Freddy ELMALEH - Sébastien NEILD Thierry DEMAN es Arquitecto de Sistemas y domina las tecnologías Microsoft tras numerosos años trabajando en el seno de Permis Informatique. Está reconocido como Microsoft MVP (Most Valuable Professional) en Exchange tras varios años. Está certificado, entre otros, en MCSE Messaging 2013 y MCSA Windows Server 2008 et 2012. Freddy ELMALEH es consultor freelance, experto en Seguridad y soluciones de Infraestructura de Microsoft. Fundador de la empresa Active IT, colabora con muchas grandes empresas en servicios de consultoría y auditoría de sistemas y seguridad. Está
reconocido como Microsoft MVP (Most Valuable Professional) en Directory Services desde 2007 gracias, en particular, a su activa participación en el seno de la comunidad Microsoft (Foro Technet y laboratorio Microsoft). También está certificado en MCITP Server Administrator para Windows Server 2012. Sébastien NEILD es Ingeniero de Sistemas y Redes en una empresa de servicios. Colabora como responsable de proyectos de Active Directory y Exchange y ha participado en numerosos proyectos de despliegue y migración de infraestructuras Windows Server. Está certificado en MCSE y MCITP Server Administrator para Windows Server 2008. Maxence VAN JONES es consultor freelance, Arquitecto de sistemas y redes, Jefe de proyecto, formador MCT y fundador de MVJ CONSULTING. Interviene como experto en proyectos de diseño de parques informáticos, de virtualización y de securización siempre en relación con tecnologías Microsoft. Está, entre otros, certificado en MCITP Enterprise Administrator para Windows Server 2008 y MCSA para Windows Server 2012.
Introducción Este libro trata sobre la última versión del sistema operativo de la gama Windows Server de Microsoft Se trata, evidentemente, de Windows Server 2012 R2. Microsoft, fiel a su estrategia, busca dinamizar la evolución de sus productos, prefiriendo, de este modo, definir un ciclo de vida más corto a sus productos para aportar, de manera regular, mejoras y evolutivos técnicos adaptados al mercado. Windows Server 2012 no se sale de esta norma, y algunos meses después de la aparición de la versión R1, ha hecho su aparición Windows Server 2012 R2 y se pone a disposición de todos los profesionales. Microsoft ha diseñado Windows Server 2012 para ofrecer una plataforma flexible y completa que responda a las necesidades, cada vez más exigentes, de las empresas. Esta versión evoluciona de acuerdo a su tiempo teniendo en cuenta la tendencia hacia la virtualización de servidores, al Cloud Computing y a la premisa "Bring Your Own Device". Podrá, de este modo, aprovechar las nuevas funcionalidades, útiles y prácticas, que le permitirán basar el conjunto de sus Sistemas de Información en una solución Microsoft.
Las distintas ediciones de Windows Server 2012/2012 R2
Como es habitual, Microsoft Windows Server 2012 R2, así como Windows Server 2012, está disponible en distintas versiones. La elección de una u otra edición dependerá, especialmente: • • •
Del rol del servidor que prevé instalar. De la estrategia de virtualización empleada. Del tipo de licencia utilizado.
Para realizar esta elección, hay disponibles cuatro ediciones de Windows Server 2012 R2: •
• •
•
Windows Server 2012 R2 Datacenter: se trata de la versión más completa, que soporta hasta 64 procesadores. Se trata de una versión destinada a servidores especialmente potentes que sólo está disponible bajo un programa de clave de licencia por volumen. Su modelo de licencia se calcula en función del número de procesadores y del número de CAL. Permite alojar un número ilimitado de máquinas virtuales. Windows Server 2012 R2 Standard: se trata de una versión idéntica a la edición Datacenter, salvo que sólo permite el uso de dos instancias virtuales. Windows Server 2012 R2 Essentials: esta versión remplaza a Small Business Server Essentials. Algunos roles no están disponibles en comparación con una versión Standard (Server Core, Hyper-V, etc.). Esta edición está limitada a una única instancia física o virtual, con un máximo de 25 usuarios. Las versiones Standard y Datacenter permiten utilizar ciertas funcionalidades que, habitualmente, son propias de la versión Essentials (tales como la copia de seguridad de los equipos cliente, los cuadros de mando, etc.). Windows Server 2012 R2 Foundation: esta edición no ofrece solución de virtualización (no es posible instalar Hyper-V), y está limitada a 15 usuarios. Es posible obtener más información sobre las especificaciones (idénticas entre las versiones 2012 y 2012 R2) de esta versión en la siguiente dirección: http://technet.microsoft.com/en-us/library/jj679892.aspx
Observe que existe, a su vez, una versión gratuita llamada Hyper-V Server 2012. Está preconfigurada para ejecutar una versión mínima (Core) de Windows Server 2012 y sólo puede alojar el rol Hyper-V. Es posible encontrar más información en la siguiente dirección: http://technet.microsoft.com/es-es/evalcenter/dn205299.aspx Windows Server 2012 R2 está disponible únicamente en versión 64 bits; las versiones de 32 bits e Itanium ya no están disponibles. Si desea información más precisa, encontrará una descripción detallada de las distintas versiones de Windows en la siguiente dirección (en inglés): http://www.microsoft.com/enus/server-cloud/windows-server/buy.aspx La gestión de las licencias se ha rediseñado por completo. Para Windows Server 2012 Standard y Datacenter, el cálculo de licencias "por servidor" cambia por licencias "por procesador". Preste atención, en adelante, al hardware de sus servidores. Por defecto, estas versiones parten de una licencia para dos procesadores. La única diferencia entre ambas
versiones reside en el derecho a la virtualización: ilimitado en la versión Datacenter y de dos máquinas virtuales en la versión Standard. Encontrará la FAQ oficial (en inglés) correspondiente a las licencias en la siguiente dirección: http://download.microsoft.com/download/4/D/B/4DB352D1-C610-466A-9AAFEEF4F4CFFF27/WS2012_Licensing-Pricing_FAQ.pdf Se aplica, a su vez, un licenciamiento particular a las máquinas virtuales. Todos estos detalles se encuentran en la siguiente documentación:http://download.microsoft.com/download/3/D/4/3D42BDC2-6725-4B29B75A-A5B04179958B/WindowsServer2012VirtualTech_VLBrief.pdf Dado que las versiones Foundation y Essentials están mucho menos extendidas en la empresa, este documento se centra en las ediciones Standard y Datacenter.
Los grandes ejes de Windows Server 2012 R2 Durante el estudio de los ejes principales de esta versión de Windows Server, Microsoft tiene en consideración la carga de trabajo, la presión creciente sobre el servicio IT de las empresas y la explosión del Cloud Computing. El sistema operativo deberá, por tanto, dar respuesta a estas tres exigencias esenciales.
1. Un mejor control de la información Windows Server 2012 R2 provee un mejor control de la información para garantizar una mayor eficacia en la administración y, en consecuencia, una mejora en la productividad. La nueva interfaz, de tipo mosaico, es coherente con el resto de la nueva gama de los OS Windows. Aunque le pueda resultar algo desconcertante, Microsoft ha rectificado su estrategia en la versión R2 reintegrando el botón Inicio. Es posible que la toma de control suponga, todavía, algún problema, por ello le invito a leer la siguiente página, a riesgo de que no sea capaz de volver a reiniciar su servidor salvo por línea de comando: http://technet.microsoft.com/es-es/library/hh831491.aspx#BKMK_run Para aumentar esta calidad en la administración, en Windows Server 2012 R2 se ha aumentado la capacidad de script y de automatización de tareas gracias al lenguaje de script Windows PowerShell. La automatización de tareas corrientes de administración se ve, de este modo, mejorada enormemente gracias a esta nueva funcionalidad. Prácticamente todas las acciones realizadas en el seno del sistema se pueden automatizar con PowerShell, y existen muchos asistentes que proponen, como último paso, recuperar la sintaxis PowerShell equivalente a las acciones realizadas. El servicio de directorio de Active Directory está dotado, desde Windows Server 2008 R2, de funcionalidades tales como la papelera de reciclaje de Active Directory, la
administración automática de cuentas de servicio o incluso la posibilidad de administrar de forma gráfica las directivas de contraseñas múltiples, que encantarán a todo administrador. El control de acceso dinámico permite controlar el acceso a los datos de forma dinámica. Identifica la criticidad del dato (según los atributos que se hayan definido) y guarda, a continuación, el control sobre el que se ubican en el seno del Sistema de Información. La instalación basada en roles y características, gracias a la consola única Administración del servidor, facilita la administración. Los asistentes disponibles permiten limitar al máximo los errores de configuración gracias a sus numerosas explicaciones, que guían al administrador en la etapa de instalación de un componente Windows. La consola permite, a su vez, instalar y administrar servidores físicos remotos o virtuales, tanto desde un servidor como desde un puesto de trabajo, mediante las herramientas de administración RSAT. Es, por tanto, fácil crear un grupo de servidores que tengan que gestionarse de manera conjunta. Microsoft ofrece, a su vez, la opción de instalar por defecto una versión mínima de Windows Server 2012 R2, conocida con el nombre de Windows Server Core. Esta versión funciona, de hecho, sin una interfaz gráfica y todo debe configurarse por línea de comandos. La ventaja principal de este tipo de administración reside en el hecho de que la superficie de ataque se reduce por el hecho de que solamente se instalan en el servidor aquellos componentes imprescindibles. Los administradores agregarán, a continuación, los roles que deseen. La interfaz gráfica se considera una característica más que es posible desinstalar. Consolas tales como el monitor de confiabilidad y rendimiento de Windows permite detectar problemas de configuración en sus sistemas operativos, e informar automáticamente al servicio informático. Ofrece, a su vez, mucha información precisa sobre el uso de componentes del sistema. En lo sucesivo, es posible realizar una mejor administración de la impresión. En efecto, es posible instalar impresoras automáticamente sobre equipos de usuario mediante directivas de grupo. La consola MMC le permite gestionar, controlar y resolver mejor los fallos de las impresoras de su dominio. Por último, y una buena noticia más para los administradores, las reglas Applocker permitirán realizar un mejor control de las aplicaciones cuyo uso se autorice con Windows Server 2008 R2/2012/2012 R2 y Windows 7/8/8.1.
2. Una mejor protección del Sistema de Información orientada a la movilidad y al Cloud Microsoft ha rehecho completamente el núcleo de su sistema operativo desde Windows Server 2008. Existe un núcleo NT 6.x desde Windows Vista/2008 (Windows 2000 y XP se basaban en el núcleo NT 5.x). Windows 8 y 2012 se basan en el núcleo 6.2.
Este núcleo posee la tecnología Patchguard, desarrollada por Microsoft para proteger al máximo el sistema operativo y, de este modo, mantener una barrera para los rootkits o cualquier otro ataque que trate de modificar el núcleo del sistema. Windows Server 2012/2012 R2, igual que Windows 8/8.1, aprovechan la funcionalidad ELAM (Early Launch Anti-Malware) que permite cargarse únicamente a aquellos drivers firmados, tras el arranque del sistema. La protección de acceso a redes (NAP) está, también, accesible y le permite implementar condiciones de uso de su sistema dentro de la empresa. ¡Se terminaron las personas externas que llegaban con un ordenador portátil que no cumpliera con las reglas de la organización y los usuarios sin el antivirus actualizado! El acceso a la red se les denegará mientras no cumplan con los criterios de conformidad que usted haya juzgado convenientes. El acceso a la red de la empresa cobra una nueva dimensión con la simplicidad en la implementación de DirectAccess, que permite a los administradores aprovechar un control mayor sobre los equipos, pudiendo, de este modo, administrarlos incluso antes de que se conecte un usuario (GPO disponibles, etc.). Se terminó la necesidad de tener una infraestructura IPv6 para aprovechar esta solución, como ocurría con Windows Server 2008 R2. Los controladores de dominio de solo lectura (RODC) refuerzan la seguridad de sus dominios Active Directory en la medida en que puede limitar la difusión de ciertas contraseñas en caso de que se vea comprometido algún controlador de dominio. Éstos encontrarán, por ejemplo, su lugar en las pequeñas redes de agencia donde la seguridad del controlador de dominio no puede garantizarse. El acceso VPN a través de protocolos tales como SSL facilitan el acceso al Sistema de Información y, también, intercambiar datos con otros equipos. La pasarela sitio-a-sitio multi-inquilino provee, de este modo, la opción de utilizar una misma pasarela Site To Site para conectar clientes que posean el mismo plan de direccionamiento IP. El firewall avanzado de Windows Server 2012 R2 permite limitar la superficie de ataque de sus servidores realizando un filtrado de los puertos sobre el tráfico de red entrante o saliente. El firewall analiza el flujo a nivel de aplicación, de modo que puede no autorizar el tráfico para un servicio específico. Además, la nueva consola de gestión MMC para el firewall avanzado permite configurar los flujos IPsec para asegurar la integridad o cifrar el flujo entre equipos. Esto resulta ideal para definir un cifrado entre controladores de dominio o entre equipos de administración y servidores de administración. El cifrado del lector de disco se realiza con BitLocker, que permite, a su vez, impedir el acceso a los datos de su disco duro desde una instalación paralela de otro sistema operativo. Los servicios asociados a Active Directory refuerzan, a su vez, la seguridad de su infraestructura informática. El rol AD CS (Active Directory Certificate Services) permite difundir certificados basados en el nuevo modelo de certificados versión 4. El rol AD RMS (Active Directory Rights Management Services) le da la posibilidad de controlar la difusión
de los documentos en su empresa. El rol AD FS permite favorecer enormemente los intercambios de información con equipos asociados externos, o incluso mejorar el uso de terminales personales para conectarse al Sistema de Información de la empresa (BYOD) con un control mínimo sobre estos equipos gracias a Workplace Join. Siempre desde un punto de vista de apetura hacia la movilidad, la funcionalidad de Carpetas de trabajo permiten sincronizar archivos profesionales entre varios PC o dispositivos que pertenezcan al mismo usuario, pertenezcan o no a la empresa. Las funcionalidades de seguridad presentes en Windows Server 2012 R2 permiten, por tanto, limitar el riesgo de ataque sobre el servidor garantizando una productividad y una flexibilidad importantes.
3. Una plataforma que evoluciona Windows Server 2012 R2 es una plataforma capaz de adaptarse y responde a las necesidades de evolución de una sociedad. La tecnología hypervisor (Hyper-V) responde a la necesidad, cada vez mayor, de las empresas que desean virtualizar algunos de sus servidores. Esta tecnología responde, de este modo, de forma ultra-reactiva a los cambios de trabajo dinámicos y al desarrollo de la cloud privada. Las réplicas de Hyper-V resultarán interesantes para más de una PYME que no disponga del presupuesto suficiente para la implementación de una solución de replicación para responder ante un desastre o siniestro. Una réplica de Hyper V permitirá replicar una máquina virtual hacia otra, ahorrando el máximo de ancho de banda, gracias a una compresión y un registro de los cambios en un disco de una máquina virtual. Un espacio de almacenamiento, novedad funcional desde Windows Server 2012, permite utilizar discos duros económicos para crear zonas de almacenamiento. Esta zona puede, por tanto, dividirse en espacios que se utilizarán como discos físicos. Un poco de manera similar a como ocurre con SAN, aunque de forma mucho menos onerosa, esta funcionalidad permite incluir discos auxiliares en caliente y utilizar métodos de redundancia (paridad, mirroring, etc.). El protocolo SMB (Server Message Block) pasa a la versión 3.0 y se ha visto mejorado considerablemente. Tiene en cuenta funcionalidades tales como la conmutación automática SMB, la consideración de SMB, el testigo de carpeta, etc. Tiene en cuenta, también, el almacenamiento en archivos VHD o un sistema de bases de datos SQL. Los servicios Terminal Server aportan una gran cantidad de innovaciones que mejorarán enormemente la experiencia de usuario. Es posible realizar un acceso centralizado a las aplicaciones de cara a desasociar, poco a poco, el puesto de trabajo de las aplicaciones que son necesarias para los usuarios.
También puede hacer disponibles aplicaciones (publicación de aplicaciones) sin que tengan que estar instaladas en el equipo del usuario. El acceso directo de la aplicación aparece, ahora, en el escritorio del usuario junto a las aplicaciones instaladas de manera local en su equipo. El usuario no es capaz de distinguir, a primera vista, las aplicaciones locales de aquellas remotas, lo que le permite ganar tiempo en término de formación de los usuarios. La funcionalidad RemoteFX, que había hecho su aparición con Windows Server 2008 R2, se ha visto mejorada y ya no requiere ninguna configuración particular para aprovechar una calidad gráfica excepcional mediante RDP (lectura de animaciones, webcam, etc.). Un servicio de pasarela Terminal Services (también llamado RD Gateway) le permite no tener que multiplicar los puertos a abrir en su red o a implementar una red privada virtual. Basta con tener un único punto de entrada, a través de un portal Web, que le permite acceder a su red privada virtual. El tráfico RDP se encapsula, en efecto, de manera transparente en un flujo SSL (HTTPS). El acceso Web a los servicios Terminal Server (RD Web Access) es una interfaz Web que le permite acceder a las aplicaciones RemoteApp que haya decidido publicar. Estas aplicaciones están, de este modo, accesibles desde su navegador de Internet. Esta solución se basa en IIS y puede, a su vez, integrarse en un portal SharePoint. Gracias a Windows Server 2012 puede gestionar la evolución de la empresa y, en particular, administrar aplicaciones que requieran una alta disponibilidad. El clúster de servidores tiene como cometido contener varios a servidores con un mismo rol. Si alguno de los servidores (llamados nodos del clúster) no está disponible, el sistema de clúster bascula, automáticamente, hacia otro nodo disponible. Esto se realiza sin ninguna intervención por parte de los administradores, lo que limita la duración de la indisponibilidad de una aplicación. El servicio de alta disponibilidad se caracteriza, a su vez, por la posibilidad de hacer un reparto de la carga de red (llamada, a su vez, NLB por Network Load Balancing). Este reparto o equilibrado de carga permite repartir la carga de red entre varios servidores que presenten la misma información. El reparto de carga de red puede, de este modo, responder a un desarrollo importante de la actividad de un sitio de Internet, por ejemplo, seleccionando dirigir las demandas de conexión al servidor Web en el servidor IIS menos ocupado. Por último, el ciclo de vida de su servidor resulta más sencillo de gestionar gracias a un conjunto de herramientas adaptadas y útiles. Entre todas ellas, podemos citar la característica de copia de seguridad que le permite administrar sus copias de seguridad y restauraciones gracias a asistentes muy intuitivos. La tecnología de las instantáneas permite realizar copias de seguridad de sus archivos en ejecución de forma casi inmediata.
El servidor de actualizaciones WSUS3 permite administrar el conjunto de actualizaciones (correctivos, parches de seguridad) de los sistemas operativos y de algunas aplicaciones Microsoft en el seno de su red empresarial. Este libro tiene también como objetivo presentarle las principales funcionalidades de Windows Server 2012/2012 R2, insistiendo especialmente en aquellas novedades aparecidas tras el salto tecnológico que separa a Windows Server 2003 de Windows Server 2008. Está salpicado de consejos y recomendaciones de expertos en herramientas Microsoft y se dirige, de este modo, a aquellas personas que ya posean cierta experiencia. No obstante, esta obra también pretende explicar los conceptos básicos de modo que resulte accesible a aquellas personas que no posean una experiencia notoria con la tecnología de servidor de Microsoft.
Las numerosas direcciones de Internet provistas en las páginas de este libro se recopilan en una webografía, disponible en la página Información.
Introducción Este capítulo está dedicado al directorio de Microsoft Active Directory. El servicio de directorio de Microsoft resulta indispensable en la gestión de la información en el seno de una empresa. En la primera parte, se presenta el servicio de directorio en Windows Server 2012 R2. A continuación, seguiremos con explicaciones sobre los principales componentes ligados al servicio de directorio, tales como las directivas de grupo y otros servicios relacionados al propio directorio.
Presentación del servicio de directorio de Microsoft: Active Directory Domain Services Usted ya conocerá, sin duda alguna, el principio de funcionamiento del directorio Active Directory. Esta obra no tiene como objetivo volver a explicar lo que ya conoce, de modo que los principios generales de un directorio Active Directory (también llamado Active Directory Domain Services o AD DS) se abordan de manera muy breve para, así, poder centrar su atención en las especificidades aportadas por Windows Server 2012 R2.
1. Definición de un dominio de Active Directory Active Directory es un servicio de directorio que permite referenciar y organizar objetos tales como cuentas de usuario, nombres de recursos compartidos, autorizaciones mediante grupos de dominio, etc. La información puede, así, centralizarse en un directorio de referencia con el objetivo de facilitar la administración del Sistema de Información. Desde un punto de vista tecnológico cabe tener en cuenta tres nociones: •
•
•
El dominio es la unidad básica encargada de agrupar los objetos que comparten un mismo espacio de nombres (un dominio debe, en efecto, basarse necesariamente sobre un sistema DNS que soporte actualizaciones dinámicas y registros de tipo SRV). Una arborescencia de dominios es la agrupación jerárquica de varios dominios que comparten un mismo espacio de nombres (por ejemplo, los dominios madrid.MiEmpresa.Priv y barcelona.MiEmpresa.Priv). Un bosque trata de reagrupar varias arborescencias de dominio que tienen en común un catálogo global y que no comparten, obligatoriamente, un espacio de nombres común.
Desde un punto de vista físico, cabe tener en cuenta tres elementos principales: •
•
Los controladores de dominio se encargan de almacenar el conjunto de los datos y de administrar las interacciones entre los usuarios y el dominio (apertura de sesión, búsquedas en el directorio, etc.). Al contrario que con los antiguos sistemas NT, en el dominio tiene lugar una replicación multimaestro, lo que permite a cualquier controlador poder iniciar una modificación (agregar una cuenta de usuario, cambiar una contraseña de usuario, etc.). Cada controlador de dominio contiene, a su vez, particiones. Microsoft ha decidido compartir la información en varias particiones para, así, limitar la extensión de los datos que hay que replicar. Cada partición tiene, por tanto, su ámbito de replicación. Todos los controladores de dominio de un mismo bosque tienen en común las particiones de esquema y de configuración. Todos los controladores de dominio de un mismo dominio comparten una partición de dominio común. La cuarta partición (presente de forma opcional) es la partición de aplicación. Ésta almacena los datos sobre las aplicaciones utilizadas en Active Directory y se replica sobre los controladores de dominio que usted elija que formen parte del mismo bosque.
•
Los sitios Active Directory ponen en evidencia la agrupación física de objetos de un mismo dominio. Debe, además, asociar uno (o varios) controlador(es) de dominio a un mismo sitio Active Directory si estos controladores de dominio se comunican con un enlace de red que tenga una buena velocidad de transferencia. En efecto, los
•
controladores de dominio de un mismo sitio dialogan de manera mucho más frecuente que los controladores de dominio definidos en dos sitios de Active Directory distintos. Esto le permite, también, reducir de manera importante el tráfico de red en un enlace que separe a dos sitios remotos. Los roles FSMO (Flexible Single Master Operation) son un total de cinco en el seno de una infraestructura Active Directory. Estos roles deben estar contenidos en controladores de dominio y son necesarios para el correcto funcionamiento de un dominio de Active Directory. Según los roles, son únicos por dominio o bien por bosque. La siguiente tabla muestra con detalle cada uno de estos cinco roles:
Nombre del rol FSMO
Ubicación
Rol
de Único en el de seno de un bosque
•
Maestro de esquema Único en el seno de un bosque
•
Gestiona la modificación esquema Active Directory.
Maestro RID
Único en el seno de un dominio
•
Distribuye rangos de RID para los SID.
de Único en el seno de un dominio
•
Gestiona los movimientos de objetos de un dominio a otro.
Único en el seno de un dominio
•
Garantiza una compatibilidad con los sistemas operativos anteriores (NT, en particular). Sirve como servidor de tiempo de referencia para el resto del dominio. Sirve como punto de referencia durante los procesos de cambio de contraseña y bloqueo de cuentas.
Maestro nomenclatura dominios
Maestro infraestructura Emulador PDC
•
• •
Se encarga de inscribir a los dominios en el bosque. Gestiona la nomenclatura del dominio. del
2. Funcionalidades de Active Directory en Windows Server 2012 R2 Windows Server 2012 R2 proporciona un gran número de funcionalidades, las cuales gustarán tanto a aquellas personas que no tengan un conocimiento previo como a aquellas que deseen poseer un conocimiento avanzado. Se le explica cómo instalar un controlador de dominio de Active Directory con Windows Server 2012 R2, cómo utilizar las directivas de contraseña específicas, etc. Estas funcionalidades se le presentarán mediante casos prácticos a lo largo de este capítulo para que pueda constatar, usted mismo, la utilidad de estas últimas. a. Instalación de un directorio de Active Directory
Desde un punto de vista general, los asistentes de configuración se han visto mejorados considerablemente a lo largo de las versiones de Windows. Descubrirá, rápidamente, que estos últimos son muy útiles e intuitivos. Por ejemplo, en lo sucesivo puede hacer referencia a la mayoría de las opciones avanzadas de instalación del directorio Active Directory desde el asistente creado a este efecto. Es necesario agregar un nuevo rol en su servidor Windows Server 2012 R2 para instalar su directorio Active Directory. Puede acceder desde el Administrador del servidor. Utilizará, por tanto, esta consola para agregar el rol Servicios de dominio de Active Directory (también conocido bajo el nombre AD DS por Active Directory Domain Services). Volveremos un poco más adelante sobre las etapas detalladas ligadas a esta instalación. En primer lugar, el conjunto de manipulaciones debe realizarse con una cuenta de usuario que posea los permisos de Administrador del servidor. Asegúrese, en primer lugar, que tiene bien definido el nombre NetBIOS de su futuro controlador de dominio, así como una dirección IP fija válida. Se recomienda, siempre, definir estos parámetros antes de realizar la promoción de un servidor a controlador de dominio.
Por defecto, el Administrador del servidor se ejecuta cada vez que inicia Windows, y le permite configurar su servidor una vez instalado. Haga clic en Configurar este servidor local (o Servidor local) para visualizar la configuración propia a este servidor y modificarla si fuera necesario.
Escoja configurar las opciones de red haciendo clic en los enlaces de hipertexto que se encuentran en la misma fila que Ethernet y Nombre de equipo. Podrá, de este modo, definir una dirección IPv4 fija, así como un nombre de equipo descriptivo para su servidor. En nuestro ejemplo, el nombre de equipo será DC2012 (DC por Domain Controller o controlador de dominio). A continuación deberá reiniciar el servidor. Vuelva sobre Panel, siempre desde la consola Administrador del servidor. Haga clic en Agregar roles y características.
A continuación se abre el Asistente para agregar roles y características. La primera página aparece, por defecto, con cada ejecución del asistente. Tiene como objetivo permitirle verificar un conjunto de buenas prácticas antes de continuar con la instalación de un rol en su servidor (contraseña fuerte, dirección IP estática, parches de seguridad al día). Haga clic en Siguiente. Escoja la opción Instalación basada en características o en roles y, a continuación, haga clic en Siguiente.
Como es posible instalar, desde este asistente, roles o características sobre un servidor definido en un grupo de servidores o desde un disco duro virtual, esta etapa le permite precisar el servidor o el disco duro virtual en cuestión. En nuestro ejemplo, se trata de un servidor físico. Seleccione la opción Seleccionar un servidor del grupo de servidores y, a continuación, haga clic en Siguiente. Observe que todos los comandos de instalación se basan en PowerShell y pueden ejecutarse de manera remota.
Seleccione, a continuación, el rol o la característica que desea instalar. Como se trata de la instalación de un controlador de dominio Active Directory, debe escoger la opción Servicios de dominio de Active Directory.
El asistente le invitará a agregar la instalación de varias características necesarias (o, al menos, útiles) para este rol (Herramientas administrativas, Administración de directivas de grupo, etc.). Las siguientes etapas del asistente se actualizan de manera dinámica en función del rol seleccionado. Haga clic en Siguiente.
A continuación se le pregunta si quiere aprovechar para instalar las características suplementarias de su servidor. No es necesaria ninguna para el buen funcionamiento de Active Directory, las características necesarias ya se le han presentado en la ventana anterior. Haga clic en Siguiente.
El asistente le explica, rápidamente, el rol de los servicios de dominio de Active Directory así como la principal información a tener en cuenta. Le invita, a su vez, a consultar los artículos disponibles en la ayuda de Windows para más información. Haga clic en Siguiente.
La última etapa consiste en confirmar la instalación del rol en cuestión. Los mensajes de información le avisan de que el servidor se reiniciará al finalizar la instalación. Reinicio que puede escoger que se realice automáticamente o no. Haga clic en Instalar. Comienza la instalación del rol.
Es posible exportar los parámetros de configuración. Esto será útil para poder reutilizarlos mediante comandos PowerShell si fuera necesario.
Es posible cerrar el asistente y continuar trabajando con el servidor sin que la instalación se detenga. Puede ver el grado de avance de la instalación en la consola Administración del servidor, dentro del área marcada con la bandera de notificación. Una vez terminada la instalación, se dará cuenta rápidamente de la potencia y de la utilidad de los asistentes de Windows Server 2012 R2. Estos últimos le guiarán de manera muy intuitiva en las siguientes etapas a realizar. En el área de notificaciones, puede apreciar, pasados algunos minutos, un signo de exclamación que se corresponde con la Configuración posterior a la instalación que debe realizar para continuar con la instalación de Active Directory. Si no apareciera, aunque la instalación haya terminado, cierre el Administrador del servidor y, a continuación, ábralo de nuevo (o haga clic en el botón Actualizar que se encuentra justo al lado (a la izquierda) del icono con forma de bandera de notificación). Haga clic en el enlace Promover este servidor a controlador de dominio. Si bien sigue existiendo, el comando dcpromo ya no se utiliza desde Windows Server 2012. Servirá únicamente para facilitar la transición de algunas empresas que hayan desarrollado scripts con este comando. La norma es, ahora, utilizar los scripts PowerShell, puesto que, ahora, todo se basa en ellos. Los cmdlets PowerShell que pueden resultar útiles son Install-ADDSForest, Install-ADDSDomain, Install-ADDSDomainController y Add-ADDSReadOnlyDomainControllerAccount. Puede encontrar más información en la siguiente dirección: http://technet.microsoft.com/enus/library/hh472162.aspx
Antes de poder instalar un controlador de dominio en Windows Server 2012 R2, el nivel funcional del bosque deberá ser, como mínimo, Windows Server 2008. A modo de recordatorio, para que el nivel funcional del bosque sea Windows Server 2008, es preciso que el nivel funcional de todos los dominios del bosque sean, como mínimo, Windows Server 2008. Esto implica que ya no será posible tener un controlador de dominio con Windows Server 2003 en un bosque que tenga un DC con Windows Server 2012 R2. Si no fuera el caso, deberá, obligatoriamente, extender el esquema a Windows Server 2012 y, a continuación, actualizar el dominio funcional del (o de los) dominio(s) y el bosque impactados. Estas etapas resultan, a menudo, temidas por los administradores puesto que la marcha atrás es compleja (habrá que restaurar, como mínimo, un dominio por bosque). Microsoft ha optado por simplificar esta etapa integrando directamente la actualización del esquema y del dominio en el asistente de promoción de un controlador de dominio desde el Administrador del servidor. El asistente ejecuta como tarea de fondo el comando adprep. Este comando es necesario para preparar un bosque y un dominio para la instalación de un controlador de dominio de una versión superior. Este comando sólo está disponible en versión 64 bits.
Si sus antiguos controladores de dominio ejecutan, todavía, una versión de 32 bits, es posible ejecutar adprep de manera remota desde un servidor Windows Server 2008 versión 64 bits, Windows Server 2008 R2, Windows Server 2012 o Windows Server 2012 R2 miembro del dominio, incluso aunque no se trate de un controlador de dominio. Adprep se ubica en la carpeta soporte\adprep del DVD de instalación de Windows Server 2012 R2. Encontrará mucha más información sobre la instalación manual de adprep en la siguiente dirección: http://technet.microsoft.com/en-us/library/hh472161.aspx Si, en el seno de su dominio, todos los controladores de dominio funcionan con Windows Server 2012 R2, puede aumentar el nivel de su dominio a Windows Server 2012 R2 mediante la consola Dominios y confianzas de Active Directory o mediante el centro de administración de Active Directory (encontrará más información en la dirección: http://technet.microsoft.com/es-es/library/cc753104.aspx). Si, en el seno de su bosque, todos los controladores de dominio funcionan con Windows Server 2012 R2 puede, también, aumentar el nivel funcional de su bosque, siempre mediante alguna de estas consolas (encontrará más información en la dirección: http://technet.microsoft.com/eses/library/cc730985.aspx) Existen varios motivos para aumentar el nivel funcional del dominio o del bosque. Aporta, la mayoría de veces, funcionalidades y características suplementarias. Estas funcionalidades se resumen en la siguiente dirección: http://technet.microsoft.com/enus/library/understanding-active-directory-functional-levels(v=ws.10).aspx Observe, no obstante, que algunos componentes no requieren más que la preparación del dominio para agregar nuevas funcionalidades (sin tener, obligatoriamente, que implementar el nivel funcional del dominio o del bosque). Es el caso, por ejemplo, del proxy web de aplicación (Web Application Proxy) que se basa únicamente en las clases del esquema creadas tras la implementación del esquema (mediante el comando adprep /forestprep) para poder funcionar. Observe, a su vez, que (siempre y cuando la papelera de reciclaje de Active Directory no esté activada) es posible disminuir el nivel funcional de un dominio o de un bosque de Windows Server 2012 o Windows Server 2008 R2 a Windows Server 2008 mediante los comandos PowerShell siguientes: Import-Module ActiveDirectory Set-AdDomainMode -identity MiEmpresa.Priv -server dc2012.MiEmpresa.Priv -domainmode Windows2008Domain Set-AdForestMode -identity MiEmpresa.Priv -server dc2012..MiEmpresa.Priv -forestmode Windows2008Forest
Haga clic, a continuación, en el vínculo Promover este servidor a controlador de dominio disponible en la lista de tareas o, tal y como se ha indicado antes, haga clic en Promover este servidor como controlador de dominio.
Se inicia el Asistente para instalación de Servicios de dominio de Active Directory. Seleccione una configuración de despliegue. En nuestro ejemplo, seleccione: Agregar un nuevo bosque. Observe que el asistente le indica un vínculo hacia el archivo de ayuda en línea de Windows que trata las distintas configuraciones de despliegue posibles.
Si ha seleccionado agregar un controlador de dominio a un dominio existente, tendrá la posibilidad, más adelante, de definir la instalación del controlador de dominio a partir de un medio externo (una copia de seguridad, por ejemplo). Esto resulta bastante útil para sitios remotos, por ejemplo, para evitar que se produzca un tráfico de red demasiado elevado y se sature el ancho de banda durante la primera sincronización entre los controladores de dominio. Puede, si no, definir un controlador de dominio particular para la primera sincronización del directorio de Active Directory para indicar un controlador de dominio del mismo sitio y, de este modo, evitar que la sincronización no se realice desde un sitio remoto que podría tener un ancho de banda limitado. Dé nombre a la raíz del bosque. En nuestro ejemplo, el nombre del dominio será miempresa.priv y, a continuación, haga clic en Siguiente.
Se recomienda, en cualquier caso, informar un nombre de dominio con dos niveles. No cree, por tanto, ningún dominio Active Directory que tenga, por ejemplo, el nombre Miempresa. Piense, también, en prohibir el uso de un guión bajo (underscore) en su nombre de dominio. Si se diera el caso, realice una migración a un nombre de dominio sin este carácter, que le generará una serie de inconvenientes en el futuro, especialmente con Exchange. Observe que desde Windows Server 2008 R2, el asistente no le permite crear un nombre de dominio de un solo nivel, bien sea para un bosque o para un nuevo dominio en un bosque ya existente. Sí le dejará, por el contrario, agregar un nuevo controlador que se ejecute bajo 2008 R2 o superior en un dominio con un único nivel ya existente. La KB de Microsoft KB300684 (http://support.microsoft.com/kb/300684) analiza este caso. De aquí a dos años, los fabricantes de certificados públicos no certificarán más dominios con extensiones privadas tales como: interna.MiEmpresa.es. Es conveniente disociar los nombres de dominio interno y externo para evitar, en particular, tener que realizar una gestión algo más compleja en su zona DNS interna. Tras hacer clic en Siguiente, el asistente trata de resolver el nombre de dominio para contactar con un eventual bosque ya existente.
Encontrará más información sobre los distintos tipos de zona DNS y sobre la replicación en el capítulo Implementar los servicios de red de la empresa - Implementar los sistemas de resolución de nombres. Es preciso definir el nivel funcional del bosque. Seleccione Windows Server 2012 R2 dado que, en este ejemplo, se trata de un servidor que es el único controlador de dominio y del bosque. Deje marcada la opción Servidor DNS para instalar este rol sobre el futuro controlador de dominio. La opción Catálogo global aparece marcada obligatoriamente puesto que todavía no existe ningún catálogo en el dominio, dado que hemos seleccionado la opción de crear un nuevo dominio en un nuevo bosque. Defina una contraseña de restauración de servicios de directorio. Se utilizará cuando se acceda en modo de restauración del directorio Active Directory pulsando la tecla [F8] durante el arranque del sistema operativo. Esta contraseña deberá responder a la complejidad requerida por la directiva de contraseña.
Si bien puede resultar tentador, no defina la misma contraseña que para la cuenta de Administrador actual por motivos de seguridad. A continuación, haga clic en Siguiente.
Aprovechará automáticamente, de este modo, las ventajas ligadas al nuevo funcionamiento del dominio de Windows Server 2012 R2, como las directivas de contraseña específica (disponibles desde el nivel funcional Windows Server 2012 y que verá, también, más adelante en la sección Directivas de contraseña específica y de bloqueo de cuenta granular de este capítulo). El sistema trata, a continuación, de contactar con el servidor DNS definido a nivel de los parámetros TCP/IP de la tarjeta de red del servidor. Si no responde al nombre de dominio Active Directory definido, y si no se ha instalado ningún servidor DNS, el asistente mostrará el siguiente mensaje (haciendo clic en Ver más en la barra de alerta de color amarillo ubicada en la parte superior del asistente).
Observe, también, que si se define un servidor DNS en las propiedades TCP/IP del servidor, éste se borrará automáticamente de estas propiedades de modo que el futuro controlador de dominio será cliente de su propio DNS. El anterior servidor DNS se informará en la pestaña Reenviadores en las propiedades del servicio DNS.
Haga clic en Siguiente. Deje el nombre NetBIOS por defecto y, a continuación, haga clic en Siguiente.
Como se encuentra trabajando en un entorno de pruebas, deje la ruta por defecto para la base de datos, los archivos de registro y SYSVOL. En un entorno de producción, se recomienda encarecidamente separar la base de datos y los archivos de registro para, así, evitar la saturación de I/O (entradas/salidas). Haga clic en Siguiente. Aparece un resumen que muestra las distintas opciones que ha definido a lo largo de las etapas del asistente. Es posible exportar estos parámetros para poder reutilizarlos en un archivo de respuestas. Podrá, de este modo, desplegar fácilmente otros controladores de dominio reduciendo el riesgo de error durante la configuración de este rol. El comando que debe utilizarse es, en este caso, dcpromo /answer:NombreDelArchivoCreado (si no se trata de promover un DC en Windows Server 2012 R2) o, directamente, mediante PowerShell mediante el script disponible haciendo clic en la opción Ver script.
Haga clic en Siguiente. El asistente realiza, a continuación, una verificación de requisitos previos necesarios para la instalación del rol de controlador de dominio sobre este servidor.
Aparece un mensaje de advertencia que indica los problemas que puede encontrar debido al enriquecimiento del algoritmo de cifrado utilizado para establecer un canal de seguridad con un cliente SMB. Por defecto, los anteriores sistemas operativos como, por ejemplo, Windows NT 4.0 no podrán acceder a los recursos compartidos que se encuentren en un servidor Windows Server 2008/2008 R2/2012 o 2012 R2. Recorra esta lista de advertencias y, si no existe ningún punto bloqueante, haga clic en Instalar. Observe que puede realizar las acciones correctivas necesarias y, a continuación, hacer clic en el vínculo que le permite volver a verificar si se cumplen los requisitos previos. Haga clic en Instalar para arrancar la instalación. El servidor reinicia, automáticamente, al finalizar la instalación. ¡Enhorabuena! Acaba de instalar con éxito un controlador de dominio en Windows Server 2012 R2. Le faltará verificar la instalación de Active Directory y realizar las primeras acciones esenciales. El siguiente enlace le ofrece todos los elementos necesarios: http://technet.microsoft.com/en-us/library/cc794717(WS.10).aspx
b. Presentación de la auditoría ligada al servicio de directorio
Auditar estos servidores es una actividad que consiste en censar los eventos que se consideren interesantes en el registro de eventos. Esto le permitirá evidenciar problemas de configuración o incluso verificar la seguridad de ciertos elementos críticos del sistema operativo. Preste atención, no obstante, a no definir demasiados objetos a auditar, puesto que el rendimiento del servidor se verá impactado inmediatamente. Antes de Windows Server 2008 R2, podía configurar los eventos de auditoría editando su directiva de grupo (desde el menú Inicio - Herramientas administrativas y Gestion des Directiva de grupo) a nivel, por ejemplo, de Directiva Default Domain Controllers Policy (Configuración de equipo - Directivas - Configuración de Windows Configuración de seguridad - Directivas locales - Directivas de auditoría).
La información que se muestra es, no obstante, confusa, ¡pues es posible ser mucho más preciso! Las directivas de auditoría pueden, en efecto, definirse de forma mucho más precisa y los parámetros visualizados a nivel de la directiva de grupo más arriba no representan más que de una forma muy vasta la configuración efectiva.
En Windows XP sólo existen nueve categorías de evento que pueden auditarse. Desde Windows Vista/Windows Server 2008, puede optar por auditar hasta 53 categorías de eventos distintos volviendo, de este modo, la creación de objetos mucho más granular. La visualización y la configuración de estos parámetros no son idénticos entre Windows Server 2008 R2 y Windows Server 2012 R2. En Windows Server 2008 (o Vista con las herramientas de administración RSAT), puede mostrar y aplicar de forma más precisa las directivas de auditoría realmente posibles únicamente por línea de comandos mediante el comando Auditpol.exe. El siguiente comando permite mostrar las distintas categorías posibles para la auditoría: Auditpol.exe /get /Category:*
En Windows Server 2008 R2 y Windows 2012/2012 R2 (o Windows 7 - Windows 8/8.1 con las herramientas de administración RSAT instaladas), es posible configurar, desplegar y administrar la auditoría detallada desde la consola GPMC. La configuración de la
auditoría detallada se realiza a nivel de Configuración del equipo - Directivas Configuración de Windows - Configuración de seguridad - Configuración de directiva de auditoría avanzada - Directivas de auditoría. Estas directivas pueden aplicarse, de este modo, sobre OU específicas para controlar la actividad de las cuentas de administrador, etc. Tenga en mente, no obstante, que esta configuración definida mediante GPO se ejecutará únicamente en equipos Windows Server 2008 R2/2012/2012 R2 o Windows 7/8/8.1.
Cabe destacar, también, que Microsoft desaconseja la configuración de la auditoría simultáneamente a nivel de Configuración del equipo - Configuración de Windows Configuración de seguridad - Directivas locales - Directivas de auditoría y de Configuración del equipo - Configuración de Windows - Configuración de seguridad Configuración de directiva de auditoría avanzada - Directivas de auditoría. Para ello, Microsoft recomienda configurar la opción Auditoría: forzar la configuración de subcategorías de la directiva de auditoría (Windows Vista o posterior) para invalidar la configuración de la categoría de directiva de auditoría que se define a nivel de Configuración del equipo - Configuración de Windows - Configuración de seguridad Opciones de seguridad. Si este parámetro no está habilitado, las opciones definidas a nivel de la auditoría básica (las siete categorías históricas) podrían entrar en conflicto con las definidas de manera más precisa en la directiva de auditoría avanzada. Para desplegar estos parámetros en Windows Server 2008 o Windows Vista, es preciso utilizar la opción auditpol.exe. Más adelante se ofrece un enlace a la KB que explica cómo poner en marcha este despliegue.
Con la llegada de Windows Server 2008 R2 y Windows 7, Microsoft introduce la posibilidad de auditar el acceso a objetos globales. Tiene, en efecto, la posibilidad de definir una directiva de auditoría para un usuario particular sobre una acción precisa y para un conjunto de servidores. Esto puede resultar muy práctico si tiene que justificar, en particular, la auditoría de la seguridad de un servidor de cara a afrontar una auditoría SOX. Los eventos generados por las auditorías de acceso a los archivos o al registro estarán mucho más detalladas si activa la opción Auditar la manipulación de identificadores puesto que se mostrará el "motivo del acceso", que le permitirá, en particular, poner de relieve errores de configuración (como, por ejemplo, un usuario que tiene acceso de escritura en lugar de tener un acceso de sólo lectura). Con Windows Server 2012/2012 R2 es posible crear directivas de auditoría basadas en expresiones con el objetivo de precisar mejor la información que se quiere mostrar en función de varios criterios (usuarios, equipos, recursos, etc.). Este aspecto se aborda en detalle en el capítulo Securizar su arquitectura. Encontrará la guía paso a paso para implementar una directiva de grupo avanzada en la siguiente dirección: http://technet.microsoft.com/es-es/library/dd408940(WS.10).aspx Observará, entonces, que las opciones de auditoría son mucho más ricas respecto a las versiones anteriores de Windows.
Se han conservado las principales categorías, y muchas subcategorías enriquecen y hacen que la recogida de eventos sea mucho más precisa. Su registro de eventos estará, por tanto, mucho más limpio de eventos inútiles. Sepa, no obstante, que si utiliza la directiva de grupo para definir las categorías principales de auditoría, no tendrá la posibilidad de definir de forma más precisa los parámetros de las subcategorías. Una directiva de auditoría configurada a nivel de las directivas de grupo activa, automáticamente, las subcategorías. Para configurar de forma más precisa la auditoría sobre los equipos tendrá que utilizar el comando auditpol en los equipos o servidores seleccionados a través de un script, por ejemplo.
Si desea, en cambio, poder administrar la configuración de las subcategorías de sus equipos Windows Vista/2008 de manera centralizada (y, en consecuencia, tener que utilizar el comando auditpol en cada equipo), consulte la solución provista en el siguiente artículo de la Kb de Microsoft: http://support.microsoft.com/kb/921469 Una de estas nuevas subcategorías de auditoría se ha creado especialmente desde Windows 2008 R2 para dar respuesta a una necesidad importante de los administradores de dominio Active Directory. Esta nueva subcategoría se denomina Directory Service Changes (categoría hija de DS Access). Le permitirá registrar los antiguos y los nuevos valores atribuidos a un objeto de Active Directory y a sus atributos. A título informativo, antes un controlador de dominio en Windows 2000 o 2003 indicaba simplemente el nombre del objeto o del atributo modificado, pero no los valores anterior y modificado del mismo. Una vez configurada la auditoría de esta subcategoría, los eventos se almacenan en el registro de Seguridad. La siguiente tabla recoge los cuatro tipos de eventos sobre los objetos de Active Directory: Número de evento
Tipo de evento
5136
Modificación con éxito de un atributo de Active Directory.
5137
Creación de un nuevo objeto de Active Directory.
5138
Restauración de un objeto de Active Directory.
5139
Desplazamiento de un objeto de Active Directory.
Si desea, por ejemplo, activar la auditoría para todas las subcategorías referentes al acceso al directorio Active Directory, siga el procedimiento siguiente:
Ejecute, desde una ventana de símbolo del sistema de un controlador de dominio, el siguiente comando: auditpol /set /category:"Acceso DS" /success:enable. Todas las subcategorías de auditoría del acceso DS se activarán. Es posible activar únicamente la subcategoría que nos interese, en nuestro caso, ejecutando auditpol /set /subcategory:"modificación del servicio de directorio" /success:enable y auditpol /set /subcategory:"Administración de cuentas de usuario" /success:enable. Existe un bug en la versión española de auditpol y todas las categorías o subcategorías que posean un apóstrofe no funcionarán si lo escribe. Existen dos soluciones para evitar este problema: o bien copia/pega la opción desde una página web codificada correctamente, o bien utiliza el código ASCII presionando [Alt] y 0146 para proveer la versión esperada del símbolo. Modifique, a continuación, la fecha de caducidad de una cuenta de usuario de Active Directory mediante la consola Centro de administración de Active Directory, también llamada ADAC (Active Directory Administrative Center) en el resto del libro (desde el menú Inicio - Ejecutar - dsac.exe).
Abra el registro de eventos de su controlador de dominio (desde el menú Inicio - Ejecutar - Eventvwr.msc). Puede comprobar que existe un evento 4738 y detalla el o los valores que acaban de modificarse, en nuestro ejemplo el valor Expiración de cuenta:.
Por otro lado, Windows Server 2012 ha introducido las directivas de auditoría de seguridad basadas en las expresiones que permiten acotar los eventos a informar utilizando expresiones basadas en reivindicaciones (claims) de usuario, de equipo y de recurso. Esta mejora está ligada a otra novedad: el control de acceso dinámico, del que hablaremos con detalle en el capítulo Securizar su arquitectura. Tenga en cuenta que, desde ahora, esta funcionalidad le permite auditar todos los usuarios que traten de acceder a recursos para los que no se ha definido ninguna habilitación o, por el contrario, administradores que utilicen sus permisos de manera abusiva. Para ello, a nivel de GPO en el servidor de archivos, siga estas etapas: Desde Configuración del equipo - Directivas - Configuración de Windows Configuración de seguridad - Configuración de directiva de auditoría avanzada Directivas de auditoría - Acceso a objetos, a nivel de parámetro Auditar sistema de archivos y del parámetro Auditar almacenamiento provisional de directiva de acceso central, active la auditoría Correcto y error. A nivel de la carpeta a auditar:
Desde las Propiedades de la carpeta a auditar (una carpeta sensible accesible únicamente por el servicio financiero de la empresa, por ejemplo), pestaña Seguridad - Opciones avanzadas - pestaña Auditoría - Agregar - Seleccionar una entidad de seguridad, escoja un grupo habilitado para acceder a esta carpeta, en nuestro ejemplo GSU-FinanzasRW. Agregue una condición que indique, por ejemplo: Usuario - Grupo - Miembro de cada Valor - [Administradores de dominio] y [Administradores].
Si un administrador accede a algún archivo de esta carpeta, se registrará un evento en el registro de eventos de seguridad.
Los eventos 4656 y 4663 pueden generarse durante la activación de la auditoría de la manipulación de identificadores o de la SAM. Estos eventos son propios de Windows 2012 R2 y Windows 8/8.1. Se podría, también, citar como ejemplo la posibilidad de poder auditar todos los proveedores que traten de acceder a documentos vinculados a proyectos sobre los que no
trabajen. La auditoría sería: Auditar - Todos - Todo - User.EmploymentStatus=Vendor AND User.Project Not_AnyOf Resource.Project. Si un usuario del servicio financiero trata de acceder, no se registrará ningún evento en el registro de seguridad, lo que evitará reportar accesos válidos. También es posible asociar la auditoría de acceso global a los objetos con directivas de auditoría basadas en expresiones, lo que permite fusionar las directivas de auditoría múltiples ubicadas en varios clientes. De este modo el administrador de un perímetro limitado podrá definir una directiva de auditoría de acceso global a los objetos correspondientes a su perímetro mientras que un administrador global podrá, por su parte, definir otra directiva de acceso global para un perímetro más amplio. Entre las mejoras aportadas por Windows Server 2012 y Windows 8 cabe destacar, también, que es posible configurar el parámetro Auditar los inicios de sesión (Configuración de directiva de auditoría avanzada - Inicio y cierre de sesión). Se genera el evento 4624 cada vez que un usuario inicia una sesión sobre un equipo local o remoto. Obtendrá más información sobre los nuevos eventos generados en la siguiente dirección: http://technet.microsoft.com/es-es/library/hh831382.aspx Estos parámetros pueden acoplarse con el control de acceso dinámico que se aborda en el capítulo Securizar su arquitectura. c. Controlador de dominio de solo lectura
Desde Windows Server 2008, es posible crear controladores de dominio de solo lectura (llamados, también, RODC por Read Only Domain Controller). Un controlador de dominio de solo lectura contiene toda la información de un controlador de dominio clásico salvo la contraseña de los usuarios. Esta información se almacena en solo lectura únicamente y no es posible iniciar ninguna modificación a nivel de dominio desde un RODC.
Sepa, por otra parte, que si no desea que se replique algún atributo sensible en su RODC es posible modificar las propiedades del mismo para limitar su replicación únicamente a aquellos controladores de dominio inscribibles. Para ello, tendrá que modificar el valor searchFlags del atributo que desee a nivel de partición de esquema. El rol maestro de esquema tendrá que encontrar, preferentemente, la información sobre algún controlador de dominio en Windows Server 2008 R2 como mínimo. Encontrará más información a este respecto en la siguiente dirección (en inglés): http://technet2.microsoft.com/windowsserver2008/en/library/f62c9720-a5c3-40c9-aa40440026f585e91033.mspx?mfr=true
Microsoft ha diseñado una solución adaptada a las necesidades de las empresas que posean sitios remotos con pocos usuarios para: • • •
mejorar la seguridad de los sitios; mejorar la autenticación de los usuarios de un sitio remoto sin tener que iniciar un tráfico WAN con el controlador de dominio del sitio principal; acceder a los recursos de la red con mayor rapidez.
Aumentar la seguridad de estos sitios Antes, en efecto era necesario instalar un controlador de dominio suplementario sobre un sitio remoto si no quería que ciertos usuarios se quejaran de mal rendimiento y una alta latencia en la autenticación o el acceso a recursos del dominio. El problema que se planteaba era que estos sitios no tenían los medios o la necesidad de tener un administrador a tiempo completo, ni podían invertir en un local protegido para dotar de seguridad a su servidor. En caso de robo o de corrupción del controlador de dominio del sitio, el atacante podía recuperar, potencialmente, todos los nombres de usuario de la empresa y sus contraseñas. En lo sucesivo, es posible limitar las consecuencias de una corrupción de un controlador de dominio sobre estos sitios puesto que puede definir, con precisión, qué cuentas tienen sus contraseñas almacenadas sobre este controlador de dominio de solo lectura. Esto se realiza mediante la pertenencia a uno de los dos grupos de seguridad llamados Grupo con permiso para replicar contraseñas en RODC (su contraseña se replica en el RODC) y Grupo sin permiso para replicar contraseñas en RODC (su contraseña no se replica en el RODC). Tan solo tiene que escoger aquellas cuentas de usuario y agregarlas al grupo que usted elija. En caso de conflicto (si un usuario perteneciera a ambos grupos, por ejemplo), el permiso "Sin permiso" es prioritario. Por defecto, se almacenan dos instancias de la contraseña sobre el RODC. La corres-pondiente a la cuenta krbtgt_xxxx y la correspondiente a la cuenta de equipo. La cuenta krbtgt_xxxx es propia de cada RODC. Permite entregar tickets Kerberos a los clientes que realicen la demanda. En caso de robo del controlador de dominio de un sitio, basta con reinicializar las contraseñas de estas cuentas, como verá más adelante. Mejorar la autentificación de los usuarios Un RODC trata de autentificar una cuenta respecto a las contraseñas que posee en caché. Si no se encuentra en su caché, contactará con un controlador de dominio inscribible para autentificar al usuario. Al mismo tiempo, consultará si la directiva de replicación de contraseñas autoriza que se aloje en la caché del RODC la contraseña de esta cuenta o no. De este modo, si la directiva lo permite, las consultas de autentificación se ejecutarán directamente en el RODC. Tenga en mente que jamás hay que abrir sesión en un RODC con una cuenta miembro del grupo Administradores de dominio (o equivalente), pues un ataque permitiría obtener estas credenciales.
Acceder a los recursos de red más rápidamente Entre las demás especificaciones de un controlador de dominio de solo lectura, sepa que este último sólo puede, por naturaleza, recibir el tráfico de replicación entrante (replicación unidireccional). No puede, por tanto, definirse como servidor inicial de una directiva de replicación de dominio en la medida en que simplemente sufre las modificaciones, sin poder iniciarlas. Es, también, posible instalar el servicio DNS sobre el RODC de un sitio. Esto evita tiempos de latencia repetitivos cuando un usuario trata de realizar una resolución de nombres sin tener un DNS próximo a él. Este servicio será, también, de solo lectura en un RODC y los equipos no tendrán la posibilidad de insertar sus propios registros de forma dinámica sobre este servidor DNS. Sus consultas de escritura se redirigirán a un servidor DNS sobre el que se permita realizar escrituras. Para limitar la primera replicación de un controlador de dominio suplementario, es posible instalarlo desde un medio extraíble y, de este modo, preservar el ancho de banda al máximo. En el caso de un RODC, es posible realizar esta acción utilizando el comando ntdsutil ifm, que tiene como efecto eliminar las contraseñas alojadas en caché presentes en el controlador de dominio. Puede obtener más información acerca de la instalación de un controlador de dominio desde un medio externo en la siguiente dirección: http://technet.microsoft.com/en-us/library/cc816722(v=ws.10).aspx Entre los requisitos previos de instalación de un RODC, sepa que: •
• •
El controlador de dominio debe ser capaz de transferir las consultas de autentificación hacia un controlador de dominio en Windows Server 2008 o superior. El nivel funcional del bosque y del dominio deben estar configurados en Windows Server 2003 o superior. Debe ejecutarse el comando adprep /rodcprep una única vez en el bosque. Permite actualizar el conjunto de dominios del bosque para modificar los permisos en la partición del directorio de la aplicación DNS. Será preciso, por tanto, que cada controlador de dominio con el rol "Maestro de infraestructura" esté disponible en el momento de ejecutar este comando.
Proceda como se indica a continuación si desea instalar un controlador de dominio de solo lectura: La instalación de un RODC es prácticamente idéntica al procedimiento que ha utilizado durante la instalación de un controlador de dominio clásico. Debe, por tanto, instalar el rol Servicios de dominio de Active Directory igual que para un controlador de dominio clásico y, a continuación, ejecutar la configuración post-despliegue seleccionando la opción Promover este servidor a controlador de dominio. En nuestro ejemplo, para instalar un RODC, seleccione Agregar un controlador de dominio a un dominio existente. Haga clic en Siguiente.
Indique el nombre del dominio existente sobre el que desee instalar un RODC y, a continuación, haga clic en Seleccionar para especificar la contraseña de un administrador de dominio o de la empresa. Haga clic en Siguiente (si apareciera algún error, compruebe su configuración DNS o autorice la apertura de puertos, pues su servidor RODC no llega a conectarse con el servidor de dominio). Seleccione el dominio y, a continuación, haga clic en Siguiente. En esta etapa, marque la opción Controlador de dominio de solo lectura (RODC). Si lo desea puede atribuir el rol de DNS y de catálogo global a este futuro controlador de dominio (teniendo, siempre, en mente las limitaciones descritas anteriormente). Haga clic en Siguiente.
Especifique a continuación la Directiva de replicación de contraseña agregando o suprimiendo los grupos y las cuentas de usuario que estarán autorizados a replicar su contraseña en este controlador de dominio de solo lectura. Seleccione, también, a quién delegar la administración del servidor RODC. En la práctica, los miembros de este grupo se encuentran en el sitio remoto que alberga al propio controlador de dominio de solo lectura. Haga clic en Seleccionar para agregar la cuenta o el grupo que desee. Una vez haya terminado, haga clic en Siguiente.
Seleccione Replicar desde para seleccionar un controlador de dominio específico si lo desea. Haga clic en Siguiente.
Seleccione una carpeta de destino para los archivos de Active Directory. Para mejorar el rendimiento, la base de datos de Active Directory y los archivos de registro no deberían ubicarse en el mismo disco duro. Una vez definidas las carpetas, haga clic en Siguiente. Aparece un resumen con las distintas opciones que ha seleccionado a lo largo del asistente. Puede, también, visualizar los comandos PowerShell que se ejecutarán para realizar estas acciones haciendo clic en Ver script. El archivo de respuestas creado permitirá realizar la instalación de un servidor RODC por línea de comandos sin intervención por parte del usuario (observe que la contraseña de restauración del servicio de directorio no se almacenará directamente en este archivo, y deberá indicarla antes de utilizar el archivo de instalación sin que el asistente le solicite introducir la contraseña en el momento necesario). Haga clic en Siguiente para ejecutar el asistente de verificación. Éste le avisará si existe alguna configuración incorrecta (dirección IP dinámica, etc.). Si bien no es obligatorio resolver estos errores para ejecutar la instalación del servidor RODC, es muy recomendable. Haga clic en Instalar. Es necesario reiniciar el servidor para que se tengan en cuenta las modificaciones. El servidor se agregará automáticamente al dominio como RODC. Sepa que es posible Crear previamente una cuenta de controlador de dominio de sólo lectura desde un controlador de dominio existente. Esta opción está disponible desde la consola ADAC, seleccionando su dominio en Domain Controllers.
El servidor RODC está instalado. Debe, a continuación, configurar la directiva de replicación de contraseña desde un controlador de dominio que permita la escritura. En efecto, cuando un servidor RODC recibe una solicitud de autentificación, consulta la
directiva de replicación de contraseña para determinar si debe o no almacenar en memoria la contraseña del usuario (o del equipo) que acaba de autentificarse. Por defecto, no se almacena en memoria ninguna contraseña. Según sus necesidades, puede escoger entre una directiva de replicación de contraseña más o menos severa. Para definir una directiva de replicación de contraseña, proceda de la siguiente manera desde un controlador de dominio (no RODC): Abra el Centro de administración de Active Directory y vaya al nivel correspondiente a la unidad organizativa Domain Controllers. Haga clic con el botón derecho del ratón sobre el controlador de dominio de solo lectura y, a continuación, en Propiedades. A nivel de Extensiones, haga clic en la pestaña Directiva de replicación de contraseña. Tal y como hemos visto anteriormente, un servidor RODC almacena únicamente aquellas contraseñas de cuenta de usuario o grupo que se definen con el valor Autorizar (para estar autorizados a tener su contraseña replicada en el servidor RODC). Por defecto, la replicación de la contraseña se rechaza para las cuentas de administración como Operadores de cuenta, Operadores de copia de seguridad, Administradores, etc. Agregar la cuenta que desee y seleccione si su contraseña se autoriza o no a replicarse en el servidor RODC y, a continuación, haga clic en Aceptar para seleccionar la cuenta de usuario o de grupo en su dominio. Valide haciendo clic en Aceptar. Haciendo clic en el botón Opciones avanzadas, puede mostrar el nombre de las Cuentas cuyas contraseñas están almacenadas en este controlador de dominio de sólo lectura.
Puede, también, seleccionar en la lista desplegable visualizar las Cuentas autenticadas en este controlador de dominio de sólo lectura. Resulta, en efecto, interesante conocer quién está autentificado mediante este RODC y, de este modo, modificar la directiva de replicación de contraseña para alojar en caché la contraseña de estos usuarios y así evitar consultas inútiles hacia un controlador de dominio de escritura. Puede, también, seleccionar la opción de Rellenar contraseñas previamente. Esto puede resultar muy útil si instala su RODC desde su sitio principal y rellena las contraseñas que quiere alojar en caché de los usuarios del sitio secundario (sobre el que se desplazará, a continuación, el servidor RODC). Habrá, también, que rellenar las cuentas de equipo utilizadas por los usuarios agregados. Esto evitará tener que utilizar la conexión WAN entre dos sitios durante la primera autentificación de los usuarios en el sitio secundario. Es decir, las cuentas seleccionadas deberá, previamente, agregarse a la directiva de replicación de contraseña, pues sin ello el rechazo implícito evitará que se almacene la contraseña en caché.
Sepa que es posible rellenar previamente las contraseñas utilizando el siguiente comando: repadmin /rodcpwdrepl [DSA_List]
[ ...] Exemplo: para rellenar la contraseña de la cuenta de usuario Fernando ROMERO (y de su equipo portítil LAP_FRO) sobre un servidor RODC llamada RODCSrv01 desde un controlador de dominio de escritura llamado DCSrv02, el comando sería: Repadmin
/rodcpwdrep1 RODCSrv01 DCSrv02 "CN=FernandoROMERO, OU=Usuarios_IT, DC=miempresa, DC=priv" "CN=LAP_FRO, OU=Equipos_IT, DC=miempresa, DC=priv" En caso de robo de un servidor RODC, podrá controlar de manera muy sencilla aquellas cuentas impactadas y, de este modo, limitar los potenciales riesgos de seguridad debidos al robo del servidor. Como administrador, aquí se muestra cómo debería reaccionar ante tal situación: Desde un controlador de dominio de escritura, abra la consola Usuarios y equipos de Active Directory (dsa.msc) y vaya al nivel de la unidad organizativa Domain Controllers. Haga clic con el botón derecho sobre la cuenta de equipo del controlador de dominio de solo lectura y, a continuación, seleccione Eliminar. Confirme el borrado haciendo clic en Sí. Se muestra una ventana que le permite forzar la reinicialización de la contraseña para las cuentas de usuario y/o equipo. También le permite exportar la lista de cuentas que estaban en caché. Una vez seleccionadas las opciones, haga clic en Eliminar.
Su controlador de dominio RODC se suprime, incluso si un atacante trata de explotar las contraseñas almacenadas en el mismo, no tendrán ninguna utilidad puesto que se habrían modificado rápidamente.
d. Directivas de contraseña específica y de bloqueo de cuenta granular
Una de las principales mejoras esperadas tras varios años por los profesionales de la informática que utilizan el directorio de Microsoft es, sin duda alguna, la posibilidad de poder definir directivas de contraseña múltiples sobre un dominio de Active Directoy. No ha sido, en efecto, posible realizar esta operación hasta Windows Server 2008. Desde Windows Server 2008, existe una nueva clase de objetos llamada msDSPasswordSettings. Hace posible la multiplicación de las directivas de contraseña en el seno de un mismo dominio. Sobre un dominio de Active Directory existente, anterior a Windows Server 2008, habrá que actualizar el nivel funcional del dominio al menos a Windows Server 2008 (todos sus controladores de dominio deberán, por tanto, ejecutar como mínimo Windows Server 2008). De este modo, es posible definir un objeto "parámetros de contraseña" (llamado también PSO por Password Settings Object) distinto entre los usuarios. En la práctica, puede tener una duración de vida máxima de contraseña de 30 días para las cuentas de administrador. Las cuentas de servicio tendrán una longitud mínima de contraseña de 36 caracteres que jamás expira. Por defecto, sólo los miembros del grupo Administradores de dominio tienen la posibilidad de definir directivas de contraseña múltiples. Tomemos el ejemplo de la definición de una directiva de contraseña específica para las cuentas de usuario utilizadas para la administración del sistema de información. Estas cuentas de usuario forman parte de grupos de seguridad con muchos permisos sobre el dominio y si se comprometiera la seguridad de su contraseña se permitiría a un potencial atacante tener acceso prácticamente a todos los servidores. Conviene, por tanto, dotar de una seguridad especial a este tipo de cuentas de usuario algo especiales. Los parámetros de contraseña serán los mismos que los definidos a nivel de la directiva Default Domain Policy, a diferencia de la duración de vida máxima de la contraseña que será de 30 días en lugar de 42 días. La longitud mínima de la contraseña pasará de 7 a 14 caracteres. La cuenta se bloqueará, a su vez, tras 10 intentos fallidos. Estos principios limitan los riesgos de compromiso de la contraseña de los administradores. Windows Server 2012 ha simplificado enormemente la configuración de una directiva de contraseña específica. Ya no es necesario utilizar la consola Editor ADSI como ocurría con las versiones anteriores de Windows. Ejecutando la consola ADAC (forzosamente desde un servidor Windows Server 2012/2012 R2, o Windows 8/8.1 con las herramientas RSAT instaladas), es posible gestionar las contraseñas existentes, visualizarlas y aplicarlas a un usuario concreto. Para configurar una directiva de contraseña específica:
Abra la consola ADAC (dsac.exe) desde una cuenta de usuario miembro del grupo "Administradores de dominio". Seleccione el modo Vista de árbol en la parte superior izquierda y, a continuación, despliegue su dominio y seleccione System - Password Settings Container.
En la lista de tareas del panel derecho, haga clic en Nuevo y Configuración de contraseña. Se abre una ventana en la que debe definir los distintos parámetros de su elección.
La información correspondiente se encuentra en el directorio Active Directory, y es posible visualizarla con la consola adsiedit.msc, a nivel de Nombre_FQDN_De_Dominio/CN=System/CN=Password Settings Container. • •
Nombre se corresponde con el atributo msDS-PasswordSettings. Prioridad se corresponde con el atributo msDS-PasswordSettingsPrecedence. Debe tener un valor superior a 0 y permite arbitrar en caso de conflicto cuando se aplican dos objetos PSO sobre el mismo usuario o grupo. Cabe recordar dos reglas en el caso de que se apliquen varios parámetros a un mismo objeto. Se aplicará el objeto PSO que disponga del valor de precedencia más débil, y una directiva aplicada a nivel Usuarios será prioritaria sobre una directiva aplicada a nivel Grupo.
Prevea espaciar la numeración del atributo msDS-PasswordSettingsPrecedence entre cada directiva PSO para poder jugar con las prioridades en un futuro. •
•
•
Longitud mínima de la contraseña: msDS-MinimumPasswordLength es una cifra entera. El valor por defecto es 7 en el dominio. En nuestro ejemplo, se trata de un PSO para las cuentas de administrador. El valor mínimo será, por tanto, de 14 caracteres. Exigir historial de contraseñas: msDS-PasswordHistoryLength define el número de contraseñas anteriores que no pueden utilizarse. Por defecto, su valor es de 24 en el dominio. Las contraseñas deben cumplir con determinados requisitos de complejidad: msDS-PasswordComplexityEnabled es un valor booleano que activa la complejidad siempre que su valor sea TRUE (valor aconsejado).
•
•
•
•
•
•
•
Almacenar contraseñas con cifrado reversible: msDSPasswordReversibleEncryptionEnabled. Se trata de un valor booleano. Es preferible indicar el valor FALSE salvo si se tienen necesidades particulares. Vigencia mínima de la contraseña: msDS-MinimumPasswordAge es una duración que indica la duración de vida mínima de la contraseña para impedir al usuario cambiar su contraseña de forma sucesiva hasta que supera el límite del histórico de contraseñas para poder volver a utilizar su contraseña. El valor por defecto es de 1 día. Su formato es 1:00:00:00. Vigencia C de la contraseña: msDS-MaximumPasswordAge es una duración que indica la duración de vida máxima de la contraseña. Por defecto, la contraseña debe cambiarse cada 42 días. En este ejemplo, seleccione una duración de vida máxima de 30 días, es decir 30:00:00:00. Umbral de bloqueo de cuenta: msDS-LockoutThreshold define el número de contraseñas erróneas que puede introducir el usuario antes de que se bloquee el objeto. Se corresponde con el parámetro Umbral de bloqueo de cuenta que es igual a 0 (lo que indica que la cuenta no se bloquea nunca). Es preferible informar un número de intentos restringido para evitar ataques sobre la contraseña. Indique el valor 10, por ejemplo Restablecer recuentos de bloqueo de cuenta tras (minutos): msDS-LockoutObservationWindows permite Restablecer el contador de bloqueos de cuenta tras la duración que usted elija. Indique un valor de 10 minutos, por ejemplo, escribiendo 10:00:00:00. La cuenta se bloqueará: Durante un periodo de (minutos): msDS-LockoutDuración indica la duración del bloqueo de la cuenta si el número de contraseñas erróneas supera el valor de msDS-LockoutThreshold. Indique un valor de 10 minutos, por ejemplo, escribiendo 10:00:00:00 (observe que existen controles de coherencia que le advierten siempre que trate de implementar una configuración irrealizable). Se aplica directamente a equivalente a configurar el atributo msDSPSOAppliesTo, capaz de contener varios valores (y, por tanto, varios usuarios y grupos). Es preciso seleccionar el o los grupos de seguridad para los que se quiere aplicar esta directiva haciendo clic en Agregar.
Aplique, preferentemente, una directiva de contraseña a un grupo en lugar de a un usuario para poder, de este modo, gestionarla más fácilmente. Si desea conocer la directiva que se aplica a un usuario, vaya a las propiedades de la cuenta en cuestión en la consola Centro de administración de Active Directory y, a continuación, seleccione la opción Ver configuración de contraseña resultante. Se lee el atributo msDS-ResultantPSO para identificar la directiva asociada al usuario.
Si, desde el Centro de administración de Active Directory, edita las propiedades de una cuenta de usuario, no podrá visualizar la PSO asociada al usuario si la PSO se ha definido para un grupo. En este lugar verá, únicamente, el o las PSO que se han definido directamente sobre el usuario. e. Active Directory como servicio de Windows
Desde Windows Server 2008, es posible detener e iniciar el directorio Active Directory desde cualquier controlador de dominio, pues se considera como un servicio de Windows. Puede, por tanto, realizar operaciones de mantenimiento tales como la desfragmentación offline de la base de datos del directorio Active Directory sin tener que reiniciar el servidor en modo de Restauración del servicio de directorio. Las actualizaciones de Windows que impactan al servicio de directorio ya no requieren sistemáticamente el reinicio completo del servidor. Bastará con un simple reinicio del servicio Active Directory. La principal ventaja ligada al funcionamiento de Active Directory como servicio es que los demás servicios instalados sobre el controlador de dominio ya no estarán inaccesibles cuando se quiera realizar alguna operación de mantenimiento. La desfragmentación de la base de datos del directorio Active Directory no volverá al servicio DHCP (instalador sobre el mismo servidor) inaccesible.
Puede configurar el estado del servicio a nivel de la consola MMC Servicios, disponible en las herramientas de administración o bien escribiendo services.msc en el menú Ejecutar.
El servicio aparece bajo el nombre completo Servicios de dominio de Active Directory. El nombre del servicio es NTDS. Cuando el estado del servicio se define como Detenido, los demás equipos ven al controlador de dominio como un servidor miembro del dominio sobre el que las directivas de grupo pueden aplicarse. El controlador de dominio se comporta igual que si estuviera en modo Restauración de servicio de directorio. Su archivo ntds.dit está libre y si no existe ningún controlador de dominio disponible para autentificar su apertura de sesión, tendrá que utilizar la contraseña de la cuenta de administrador de restauración de servicios de directorio cuando promocione el servidor como controlador de dominio. Es importante tener en cuenta que si bien el servicio NTDS puede detenerse, hay que tener en cuenta unas precauciones mínimas: •
El servicio NTDS no debe detenerse durante mucho tiempo. Por ejemplo, detener el servicio sobre un controlador de dominio diciendo que el directorio se restablecerá en caso de que falle algún controlador de dominio. En efecto, según la duración de
•
•
la parada del servicio NTDS, los registros podrían considerarse como demasiado viejos y no se replicarán. La parada del servicio NTDS no basta para realizar una restauración del Active Directory. Es preciso utilizar el modo de Restauración de Servicios de Directorio (Directory Services Restore Mode) DSRM para realizar una restauración (autoritaria o no). No es posible abrir una sesión con la cuenta Administrador DSRM (que se corresponde, en realidad, con la cuenta de Administrador local del controlador de dominio) cuando se detiene el servicio NTDS y no existen más controladores de dominio disponibles durante el intento de autentificación de cuenta. Es posible modificar este comportamiento editando la clave HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior en su controlador de dominio.
Los posibles valores son los siguientes: Clave DSRMAdminLogonBehavior Valor (por defecto)
0 No permite abrir una sesión con la cuenta de administrador DSRM. Para abrir una sesión con esta cuenta, será preciso que otro controlador dominio esté disponible en el momento de realizar la autentificación.
Valor 1
La cuenta de Administrador DSRM puede utilizarse cuando se detiene el servicio AD DS. Este valor es especialmente interesante si solo dispone de un controlador de dominio o si la resolución de nombres definida sobre el mismo apunta únicamente sobre sí mismo.
Valor 2
La cuenta de Administrador DSRM puede utilizarse para realizar la autentificación en cualquier situación. Hay que tener en mente que esta cuenta no se somete a ninguna directiva de contraseña.
Observe, también, que el reinicio en modo DSRM puede realizarse de varias formas: • •
Utilizando el comando shutdown con las opciones -o y -r. Utilizando la combinación de teclas [Windows] + C - Configuración Iniciar/Apagar - haciendo clic en la tecla [Mayús] haciendo clic en el botón Reiniciar y seleccionar un motivo del tipo Recuperación.
Durante el reinicio, el servidor le propondrá varias opciones, entre ellas la opción de Solucionar problemas, que permite recuperar el sistema operativo a partir de una imagen de sistema, la ejecución de una consola de comandos o bien la opción Configuración que le permitirá acceder al menú de inicio avanzado pudiendo, en particular, acceder al modo DSRM.
Hay otro servicio que existe desde la aparición de Windows Server 2012 R2. Se trata del servicio Servidor de la función de DS (DsRoleSvc), que está configurado, por defecto, en modo Manual Arrancará automáticamente siempre que se le solicite durante la configuración de un nuevo controlador de dominio, se agregue un nuevo bosque, un dominio o un controlador de dominio, se elimine el rol Active Directory en un servidor o cuando se clone un controlador de dominio. f. Clonado de un controlador de dominio Active Directory virtualizado
La virtualización se ha convertido, en el espacio de unos pocos años, en un elemento imprescindible en la mayoría de SI. El capítulo Consolidar sus servidores está dedicado al hipervisor Hyper-V y sus novedades. Windows Server 2012 incluye la posibilidad de virtualizar un controlador de dominio, operación que era técnicamente posible en las versiones anteriores de Windows Server, aunque estaba fuertemente desaconsejado puesto que Microsoft no daba soporte ni a los snapshots, ni al clonado de un controlador de dominio (puede obtener más información sobre estos riesgos en la siguiente dirección: http://support.microsoft.com/kb/888794). Asociado a la Réplica Hyper-V, permite incluir los controladores de dominio virtualizados en el plan de recuperación ante desastres (PRD) de las máquinas virtuales. Un controlador de dominio puede, de este modo: • •
Ser clonado sin riesgo alguno. Realizar una imagen instantánea (snapshot) de un controlador de dominio sin riesgo de corromper el conjunto de la base de Active Directory.
Las ventajas de la virtualización de un controlador de dominio son: • • • •
Poder desplegar rápidamente un controlador de dominio en un nuevo bosque o un nuevo dominio. Poder remplazar con varios clics un controlador de dominio. Una mejor capacidad de evolución de la infraestructura de Active Directory si fuera necesario. Implementación de manera sencilla de entornos de pruebas.
El controlador de dominio con el rol Emulador PDC debe utilizar Windows Server 2012 para poder implementar un controlador de dominio virtualizado (también llamado vDC). El controlador de dominio de origen (el que se clonará) y el controlador de dominio clonado deben tener el rol Hyper-V instalado y deben pertenecer al mismo dominio.
El controlador de dominio de origen debe ser un controlador de dominio virtualizado que se ejecute como mínimo en un entorno Hyper-V 3 (y, por tanto, bajo Windows Server 2012). El switch de la red virtual Hyper-V debe tener el mismo nombre en cada servidor Hyper-V. Si ambos controladores de dominio no tuvieran el mismo procesador, desde el controlador de dominio de origen, haga clic en su configuración en Hyper-V y, a continuación, en Procesadores - Compatibilidad y seleccione la opción Migrar a un equipo físico con una versión de procesador distinta. Debe existir un servidor Windows Server 2012 R2 con el rol Hyper-V para albergar el vDC. Si utilizara otro hipervisor, tendrá que ponerse en contacto con su proveedor para verificar si este hipervisor tiene en cuenta el ID de generación de máquina virtual (también llamado VM-Generation-ID). Este VM-Generation ID es un identificador único de 128 bits que gestiona el hipervisor. El controlador de dominio que quiere virtualizar debe disponer de los permisos suficientes para ello (formando parte del grupo "Controladores de dominio clonables"). Observe que ciertos roles no pueden estar presentes en un servidor clonado, como por ejemplo el servicio DHCP, AD CS y AD LDS. Para crear un clon del controlador de dominio, debe realizar las siguientes etapas: Desde un controlador de dominio que no se preste a clonarse, preferentemente, abra el Centro de administración de Active Directory y agregue el controlador de dominio que se virtualizará al grupo "Controladores de dominio clonables" (los grupos se encuentran en el contenedor "Usuarios"). Existe un bug en Windows Server 2012 y 2012 R2 que le obligará a renombrar el grupo "Controladores de dominio clonables" a "Clonable Domain Controllers", cambio sin el cual el comando PowerShell que se ejecuta más adelante (New-ADDCCloneConfigFile) fallará. Ejecute el comando Get-ADDCCloningExcludedApplicationList desde el controlador de dominio que quiere virtualizar para identificar los servicios y programas que no son clonables. Observe la lista devuelta y tome las medidas necesarias (elimine los elementos afectados o cree una lista de exclusión) y, a continuación, ejecute el comando GetADDCCloningExcludedApplicationList -Generate - Xml. Esto provoca que se agreguen los servicios y programas suplementarios que no están presentes por defecto en la lista provista en el archivo CustomDCCloneAllowList.xml (presente en %windir%\NTDS). Ejecute el comando New-ADDCCloneConfigFile sobre el controlador de dominio de origen. Esto provoca la creación del VM-Generation ID y crea un archivo DCCloneConfig.xml en %windir%\NTDS. Este comando PowerShell permite predefinir muchos elementos tales como la dirección IP, el nombre del servidor, etc. Todos los
parámetros posibles están disponibles en la siguiente dirección: http://technet.microsoft.com/en-us/library/jj158947.aspx Por ejemplo: New-ADDCCloneConfigFile -Static -IPv4Address "172.16.0.3" -IPv4DNSResolver "172.16.0.2" -IPv4SubnetMask "255.255.0.0" -CloneComputerName "VirtualDC2" -IPv4DefaultGateway "172.16.0.254" -SiteName "MADRID"
Por defecto, el controlador de dominio clonado pertenecerá al mismo sitio de Active Directory que el controlador de dominio inicial, a menos que lo defina en el archivo DCCloneConfig.xml. Copie este archivo en la carpeta donde se encuentra la base de datos de Active Directory sobre el controlador de dominio de origen (por defecto %windir%\NTDS). El archivo DCCloneConfig.xml es uno de los componentes que permite iniciar el clonado de un controlador de dominio. Un controlador de dominio clonado se basa en dos elementos para detectar que es el resultado de la copia de otro controlador de dominio: • •
El VM-Generation-ID de la máquina virtual es distinto al que hay almacenado en la base de datos Directory Information Tree (DIT) (%windir%\NTDS). Existe un archivo DCCloneConfig.xml presente en la ubicación de la DIT o en la raíz de algún lector extraíble (lector DVD, por ejemplo).
El controlador de dominio clonado contacta, entonces, con el controlador de dominio que alberga el rol emulador PDC (Windows Server 2012 como mínimo) utilizando el contexto de seguridad del controlador de dominio de origen. Éste crea, a continuación, los objetos necesarios en el Active Directory y, a continuación, el controlador de dominio clonado crea los archivos de su base de datos y limpia su estado con ayuda del comando sysprep. Para finalizar la implementación de un vDC: Deje el vDC inactivo y expórtelo o cópielo (cree un ID único). Cree una nueva máquina virtual importando la que acaba de exportar. Se configurará automáticamente como controlador de dominio completo y se integrará perfectamente en su infraestructura (a título informativo, sepa que en este momento se ejecuta el comando sysprep sobre el nuevo controlador de dominio y lo instala como lo haría tras una instalación a partir de un medio extraíble). Preste atención: realizar un snapshot del vDC no remplaza a la copia de seguridad regular del Active Directory.
He aquí una lista de los comandos PowerShell utilizados para realizar la gestión de snapshots: Checkpoint-VM, Export-VMSnapshot, Get-VMSnapshot, RemoveVMSnapshot, Rename-VMSnapshot y Restore-VMSnapshot. g. Instantánea de Active Directory
Dejando a un lado los snapshots (o instantáneas) de los vDC; es posible, desde Windows Server 2008, crear instantáneas de un Active Directory. La tecnología se basa en la API VSS (Volume Shadow Copy o instantánea de volumen). Para ayudarle con las búsquedas en inglés en Internet, sepa que esta funcionalidad también se denomina Database Mounting Tool. La principal ventaja es que es posible realizar una copia de seguridad de este tipo incluso sobre archivos bloqueados. No es necesario, por tanto, detener el servicio de Active Directory (para liberar los archivos asociados) para poder salvaguardar el archivo ntds.dit, por ejemplo. Puede acoplar el uso de instantáneas con el uso de la herramienta dsamain.exe para evidenciar cualquier cambio a realizar en el Active Directory. Por defecto, sólo los usuarios miembro del grupo Administradores de dominio y Administradores de empresas están autorizados a acceder a las instantáneas creadas. Para sacar el máximo provecho a las instantáneas para Active Directory, existen tres herramientas indispensables: • • •
El comando ntdsutil para crear, eliminar, enumerar, montar, desmontar una copia de seguridad (llamada, en esta ocasión, instantánea). El comando dsamain que se utiliza para mostrar las diferencias entre dos instantáneas, por ejemplo. La herramienta ldp.exe para visualizar los datos de una instantánea de forma gráfica.
El usuario solamente podrá acceder a aquellos datos salvaguardados sobre los que disponga de permisos. Los permisos sobre los objetos de la copia de seguridad no pueden modificarse, puesto que son de sólo lectura. Para crear una instantánea del directorio Active Directory, utilice el comando ntdsutil. Sepa, no obstante, que existen otros muchos programas comerciales que se basan en la tecnología de instantáneas. El comando que debe utilizar es: ntdsutil snapshot "activate instance ntds" create
Puede planificar la copia de seguridad de estas instantáneas mediante el Programador de tareas. El comando que debe definir será, en este caso, ligeramente diferente, pues debe salir del contexto ntdsutil. ntdsutil snapshot "activate instance ntds" create quit quit Una vez terminada la instantánea, puede seleccionar la opción de mostrar todas las instantáneas creadas. Si ya se encuentra en el nivel instantánea, escriba únicamente List All (en caso contrario el comando completo es ntdsutil snapshot "activate instance ntds" "List All"). Tendrá, a continuación, que montar la instantánea que desee para poder leer los datos salvaguardados: mount x (donde x se corresponde con el número de instantánea). Una vez montada la instantánea, escriba quit dos veces seguidas para volver a una línea de comandos clásica.
Creación de una instantánea del directorio Active Directory y montaje de una de sus copias de seguridad. A continuación es preciso asociar esta copia de seguridad con un servidor LDAP virtual mediante el comando dsamain.
Abra una ventana de comandos con una cuenta de usuario miembro del grupo Administradores de dominio o Administradores de empresas y escriba el siguiente comando: dsamain /dbpath /ldapport
La ruta de la base de datos se encuentra a nivel del comando ejecutado anteriormente y tiene el formato C:\$SNAP_XXXXXX_VOLUMEC$\ sobre el que deberá agregar la ruta completa hacia la base de datos de Active Directory, generalmente WINDOWS\NTDS\NTDS.dit
Si el firewall está activado, obtendrá, probablemente, un mensaje de advertencia para agregar una regla para el ejecutable dsamain, puesto que pone al puerto LDAP especificado en escucha. Si el dominio desde el que había creado la instantánea no existe, tendrá que agregar el argumento /allowNonAdminAccess. Su servidor LDAP virtual está, ahora accesible mientras tenga la ventana de comandos abierta. Conéctese a través de un cliente capaz de acceder a los datos de este servidor LDAP. En este ejemplo, utilizará la herramienta ldp.exe, disponible, por defecto, en Windows. Desde el menú Inicio - Ejecutar, escriba el comando ldp.exe. Haga clic, a continuación, en Conexión y Conectar. En la dirección del servidor, escriba la dirección IP del servidor e indique el puerto definido anteriormente en dsamain (51389 en nuestro caso). A continuación, haga clic en OK.
Verifique el tipo de enlace mediante el menú Conexión - Enlazar. Asegúrese de definir una cuenta de usuario con los permisos suficientes. Una vez configurado, haga clic en Aceptar para autentificarse sobre este archivo de directorio. Haga clic, a continuación, en Ver - Árbol, y defina el nombre único de la base de datos correspondiente con su nombre de dominio; en el ejemplo DC=miempresa, DC=priv. Puede, a continuación, navegar en la copia de seguridad de su directorio a través de esta herramienta.
Si le parece que el acceso a los datos no es muy amigable a través de la herramienta ldp.exe, sepa que puede, si sus necesidades son más limitadas, ver sus datos directamente desde la consola Usuarios y equipos de Active Directory. Para ello, haga clic con el botón derecho del ratón en la raíz de la consola y, a continuación, seleccione la opción Cambiar el controlador de dominio. Haga clic en el mensaje para informar el nombre de su controlador de dominio y el puerto definido anteriormente. Accederá, así, a su directorio de forma más sencilla que con la herramienta ldp.exe. Para complementar esta información, no hay que olvidar la fabulosa herramienta ADExplorer (http://technet.microsoft.com/enus/sysinternals/bb963907.aspx). Le permitirá comparar fácilmente dos instantáneas (creadas mediante esta herramienta), lo cual puede resultar extremadamente útil. Una vez haya finalizado, no olvide cerrar la herramienta dsamain ([Ctrl] C dos veces) y desmontar el directorio mediante el comando ntdsutil snapshot "activate instance ntds" "unmount x" donde x es el número de instantánea. Observe que la herramienta DSCT (Directory Service Comparison Tool) será muy útil si utiliza instantáneas. Le permite, entre otros, comparar un snapshot con la base de datos de Active Directory actual y visualizar todas las diferencias entre ambos estados (elementos agregados, eliminados, etc.). No se trata de una herramienta oficial de Microsoft. Está disponible en la siguiente dirección: http://blog.frli.se/p/dsct.html h. Las cuentas de servicio administradas
Habitualmente, durante la instalación por defecto de una aplicación, el administrador puede configurar la misma para ejecutar su servicio asociado como Local System, Local Service o Network Service. También es posible informar una cuenta de dominio para ejecutar este servicio, aunque esta cuenta de dominio debe, generalmente, tener una contraseña que jamás expire. Además, la seguridad de esta cuenta deja mucho que desear, puesto que la contraseña se encuentra en la caché LSA, que resulta fácilmente accesible.
Se han creado dos nuevas cuentas de servicio con la salida de Windows Server 2008 R2 (y Windows 7). Se trata de las "cuentas de servicio administradas autónomas" (también llamadas Standalone Managed Service Accounts o sMSA) y las cuentas virtuales (virtual accounts). Un tercer tipo de objeto ha aparecido con Windows Server 2012, las cuentas de servicio administradas de grupo (Group Managed Service Accounts, o incluso gMSA). Gracias a estos nuevos tipos de cuenta, puede extender la gestión de las contraseñas puesto que estos últimos objetos se renovarán automáticamente. Ya no es preciso tener que definir una cuenta de servicio con una contraseña que no expire jamás, puesto que el sistema la renovará automáticamente, de forma transparente, sin interrupción en el servicio. •
Las sMSA son dos tipos de cuenta de dominio que se utilizan para ejecutar servicios. Se utilizan para que su contraseña se cambie automáticamente, de cara a simplificar la gestión de los SPN (Service Principal Name). Recuerde que el SPN es necesario para la autenticación Kerberos. Esto permite, además, mejorar la seguridad de la contraseña de la cuenta de dominio utilizada para la ejecución de aplicaciones como SQL Server, IIS, Exchange, o cualquier otro servicio, con la condición de que las cuentas sMSA estén soportadas por el fabricante de su aplicación asociada.
•
Las cuentas de máquinas virtuales son cuentas de servicio locales que no requieren una gestión de su contraseña. Los identificadores de la cuenta de equipo se utilizan cuando el servicio debe acceder a los recursos presentes en el dominio. Estas cuentas se definen a nivel de las propiedades del servicio desde la consola Servicios (services.msc), pestaña Conexión y, a continuación, indicando el nombre de usuario NT Service\NombreDeCuenta, sin contraseña. Tras reiniciar el servicio, se ejecutará con un nombre de usuario que incluirá el nombre del servicio.
El inconveniente de los sMSA y de las cuentas virtuales es que no son capaces de compartir su cuenta en varios equipos. Observe que son compatibles únicamente con clientes Windows 7/8/8.1/2008 R2/2012/2012 R2. •
Las gMSA(group Managed Service Account o cuentas de servicio administradas de grupo) han aparecido con Windows Server 2012 y permiten, a diferencia de las xMSA, estar asociadas a un servicio (o una tarea programada, o incluso un pool de aplicaciones IIS, SQL Server, etc.) que se utilizará sobre varios servidores (una granja de servidores con el servicio de Equilibrio de carga de red, por ejemplo). El uso de un gMSA está condicionado por el hecho de que todas las instancias de los servicios utilizan el mismo principal. Para ello, esta nueva tecnología se basa en el nuevo servicio de distribución de claves de Microsoft, que se encarga de proveer una clave a una cuenta basada en un secreto compartido con este último. Windows Server 2012/2012 R2 calcula la contraseña sobre la clave provista y sólo los clientes Windows 8/8.1/2012/2012 R2 son capaces de obtener los valores de la contraseña de estas cuentas.
Vamos a centrarnos aquí, en particular, en el uso de las cuentas de servicio administradas de grupo, pues presentan ventajas importantes en grandes entornos informáticos. Principio general La cuenta de servicio administrada utiliza el mismo funcionamiento y la misma frecuencia de refresco de contraseña que la cuenta de equipo, es decir, cada 30 días, por defecto, aunque veremos más adelante que esta opción es configurable. No responde a ninguna regla de su política de contraseña de dominio ni a ningún PSO (directiva de contraseña única). No puede, tampoco, bloquearse ni es posible abrir una sesión con esta cuenta. La contraseña auto-generada utiliza un cifrado seguro que permite generar una contraseña de 240 caracteres aleatorios (120 para una gMSA). En términos de limitación del uso de esta cuenta, sepa que no puede utilizarse en todos los servicios de Windows (es posible que obtenga el error 1297 durante el arranque del servicio, por ejemplo). Una cuenta sMSA puede utilizarse, únicamente, sobre un equipo cada vez (aunque puede ejecutar varios servicios sobre este mismo equipo). No será, por tanto, posible utilizar una MSA para clústeres o servicios de equilibrio de carga de red. En estos casos será preciso utilizar una cuenta gMSA tal y como se ha visto anteriormente.
El Service Pack 1 de Windows Server 2008 R2 permite, a su vez, definir una MSA asociada a un servicio instalado sobre un servidor miembro del dominio y que se encuentra sobre una red delimitada (DMZ, extranet, etc.). Antes del SP1, esta operación fallaba si el único controlador de dominio presente en la misma red que el servidor que ejecutaba la MSA era un RODC (controlador de dominio de solo lectura). En lo sucesivo, las MSA funcionan, pues los RODC están preparados para redirigir la consulta de la MSA hacia un controlador de dominio de escritura. Requisitos previos Los requisitos previos que permiten utilizar las MSA son los siguientes: • •
Un dominio Active Directory con, al menos, un controlador de dominio en Windows Server 2012. Una actualización del esquema en versión 2008 R2 para las sMSA y las cuentas de equipo virtuales. No es preciso tener un nivel funcional de dominio o del bosque en 2008 R2 para que la renovación automática de la contraseña funcione. Por el contrario, si el nivel funcional es 2003 o 2008, el administrador deberá definir manualmente el SPN de estas cuentas MSA. Con un nivel funcional 2008 R2 o superior, el SPN se define automáticamente.
•
•
Un equipo con Windows Server 2008 (o superior) o Windows 7 (o superior) que contengan el servicio a configurar, si se trata de una sMSA, o Windows Server 2012/Windows 8 (o posterior) para configurar una gMSA. Disponer de las funcionalidades PowerShell, el módulo Active Directory para PowerShell (disponible en las herramientas de administración RSAT para Windows 7 en la siguiente dirección: http://www.microsoft.com/eses/download/details.aspx?id=7887 y para Windows 8 en: http://www.microsoft.com/es-es/download/details.aspx?id=28972) y, si fuera necesario, al menos el .NET Framework 4.5 instalado en los ordenadores encargados de configurar las cuentas MSA. Con Windows Server 2012/2012 R2, es posible agregar el módulo Active Directory para PowerShell desde el Administrador del servidor - Administrar - Agregar roles y características.
En la medida en que la gMSA debe configurarse desde un controlador Windows Server 2012 (o posterior), el hecho de agregar este módulo sólo es útil en el caso de que se quiera crear una sMSA desde una versión anterior. Observe, por último, que un vDC (controlador de dominio virtual) soporta únicamente las gMSA pero no las sMSA. •
Un servicio de Windows que soporte el uso de una cuenta MSA.
Instalación y configuración
Tras la extensión del esquema a 2008, se crea una nueva clase de objetos. Se trata de la clase llamada msDS-ManagedServiceAccount. Si quiere delegar la creación de esta cuenta, tendrá que verificar, previamente, que el usuario que crea la cuenta MSA posee los permisos Create/Delete msDS-ManagedServiceAccount. Tras la extensión del esquema en 2012, se crea otra clase de objetos. Se trata de la clase msDS-GroupManagedServiceAccount. Viendo los requisitos previos para instalar PowerShell, habrá comprendido que los pasos se desarrollarán, a continuación, por línea de comandos en lugar de mediante interfaz gráfica. Veremos, por tanto, las etapas detalladas que permiten crear una cuenta MSA y utilizarla para ejecutar una tarea programada. Esta tarea programada es un script que debe ejecutarse sobre todos los controladores de dominio que utilicen una cuenta con los permisos de Administrador. Antes, era obligatorio definir una cuenta con permisos muy amplios y cuya contraseña no cambiara jamás. Ahora, es posible utilizar una gMSA para ello. Las etapas principales son: • • • • •
La creación de la clave de raíz principal de los servicios de distribución de claves (Key Distribution Services KDS Root key). La creación de la cuenta MSA en el Active Directory. La asociación de la cuenta MSA con un equipo que sea miembro del Active Directory. La instalación de la cuenta MSA sobre el equipo asociado. La configuración del servicio para que este último utilice la cuenta MSA.
Para crear, en primer lugar, una cuenta gMSA, conéctese a su controlador de dominio Windows Server 2012/2012 R2 y cree sus claves de distribución raíz para estar seguro de poder crear una cuenta gMSA. En efecto, a diferencia de las sMSA, las gMSA las gestiona y mantiene el KDS (Key Distribution Service) desde un controlador de dominio Windows Server 2012/2012 R2. Ejecute la consola PowerShell. El módulo PowerShell Active Directory se cargará automáticamente. Ejecute el siguiente comando sobre su entorno de producción para generar una clave raíz, necesaria para la creación de una contraseña para una cuenta gMSA: Add-KdsRootKey -EffectiveImmediately Sólo podrá finalizar el resto del procedimiento tras esperar 10 horas, de cara a dejar tiempo a la clave generada para que se replique sobre todos los controladores de dominio (evitando, de este modo, que falle la autenticación en caso de que ésta no se replique). Si se encuentra en un entorno de pruebas, he aquí el comando que puede ejecutar para poder continuar de inmediato con el resto del procedimiento: Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
Cree un grupo de seguridad y agregue todas las cuentas de equipo que están autorizadas a utilizar la gMSA. Se trata de una buena práctica que permite una mejor gestión de estos accesos. Sepa que si elimina un equipo de este grupo, tendrán que reiniciarlo para que se tenga en cuenta la modificación. En nuestro ejemplo, crearemos un grupo "Domain Controllers" y haremos miembros del mismo a todos los controladores de dominio afectados. Cree, ahora, la cuenta gMSA desde la consola PowerShell. Tendrá que indicar, al menos, un nombre (SamAccountName) y un nombre de DNS. Opcionalmente, aunque muy útil, el parámetro PrincipalsAllowedToRetrieveManagedPassword que le permite especificar el grupo autorizado a utilizar la cuenta gMSA. Es posible utilizar el SPN, eventualmente. New-ADServiceAccount -Name -DNSHostName -PrincipalsAllowedToRetrieveManagedPassword -ServicePrincipalNames
Por ejemplo: New-ADServiceAccount MiMSA -DNSHostname MiCuenta.MiEmpresa.Priv -PrincipalsAllowed-PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"
Si quiere definir un intervalo particular para el cambio de la contraseña de la cuenta gMSA, tendrá que definirla obligatoriamente durante la creación de la cuenta; en caso contrario, se verá obligado a tener que volver a crear una cuenta con el parámetro conveniente. Por defecto, el valor es de 30 días, y puede modificarlo mediante el parámetro ManagedPasswordIntervalInDays.
Para evitar cualquier error a la hora de introducir los comandos en PowerShell, puede utilizar la opción de auto-completar presionando la tecla [Tab] tras escribir las primeras letras del comando. Sepa, también, que una vez creada la cuenta MSA, será visible desde la consola Usuarios y equipos de Active Directory o desde el Centro de administración de Active Directory a nivel del contenedor Managed Service Accounts. La cuenta está creada y es posible visualizarla desde la consola ADAC, en la OU Managed Service Accounts.
Puede agregar esta cuenta MSA a un grupo de seguridad Active Directory. Para ello, edite el grupo deseado y agregue un miembro. Especifique, a continuación, el nombre de la cuenta MSA recién creada. El cmdlet PowerShell Add-ADGroupMember o el cmdlet dsmod también permiten realizar esta acción. Una vez creada la cuenta MSA, la buena práctica consiste en instalar y probar la cuenta gMSA. Desde un comando PowerShell sobre el servidor que utilizará la cuenta gMSA: Install-ADServiceAccount Test-ADServiceAccount
Si obtuviera un mensaje de error, se debe a que hemos integrado nuestros controladores de dominio (en el marco de este ejemplo, únicamente) con un grupo de seguridad; mientras no reinicie el controlador de dominio desde el que está realizando la prueba, obtendrá un mensaje de error siempre que ejecute estos dos comandos. En nuestro ejemplo, se trata de un controlador de dominio, pero según sus necesidades podría ser cualquier servidor con Windows Server 2012/2012 R2 o Windows 8/8.1 (para la gMSA). Si desea delegar esta etapa sin tener que otorgar permisos de administrador de dominio a su usuario, puede delegar los permisos sobre la MSA específica mediante el siguiente script, que debe ejecutarse desde una ventana de línea de comandos: dsacls "CN=, CN=Managed Service Accounts,DC=miempresa,DC=local" /G "DOMINIO\:SDRCLCRPLOCA" "DOMINIO\:WP;Logon Information" "DOMINIO\:WP;Description"
"DOMINIO\
o o o o
grupo>:WP;DisplayName" grupo>:WP;Account Restrictions" grupo>:WS;Validated write to DNS host name" grupo>:WS;Validated write to service principal name"
La cuenta MSA puede, ahora, asociarse al servicio soportado mediante la interfaz gráfica abriendo la consola services.msc y, a continuación, especificando el nombre de usuario en la pestaña Iniciar sesión - Esta cuenta. La cuenta que debe indicar debe tener el siguiente formato: Dominio\NombreDeMSA$ (no olvide el dólar) sin informar ninguna contraseña.
Windows será capaz de asignar el permiso "Abrir una sesión como servicio" a la cuenta, si no dispone de él. También es posible asociar esta cuenta MSA mediante un script PowerShell del siguiente tipo: $MSA="dominio\NombreDeMSA$" $ServiceName="’Nombre_Del_Servicio’" $Password=$null $Service=Get-Wmiobject win32_service -filter "name=$ServiceName" $InParams = $Service.psbase.getMethodParameters("Change") $InParams["StartName"] = $MSA $InParams["StartPassword"] = $Password $Service.invokeMethod("Change",$InParams,$null)
Modifique y guarde a continuación este archivo con ayuda de un editor de texto en un archivo con extensión ps1. Para ejecutar un script en PowerShell, habrá que disminuir la política de seguridad por defecto mediante el comando Set-ExecutionPolicy, ejecutar el script y, a continuación, redefinir la política de seguridad por defecto. Set-ExecutionPolicy remotesigned Script.ps1 Set-ExecutionPolicy restricted
En nuestro caso, queremos definir una tarea programada que utilizará una cuenta gMSA para ejecutarse, proceda de la siguiente manera: Como la interfaz gráfica no permite definir una cuenta gMSA desde la interfaz gráfica del programador de tareas, va a ser preciso utilizar PowerShell: $action = New-ScheduledTaskAction "E:\Scripts\backup.cmd" $trigger = New-ScheduledTaskTrigger -At 8:00 -Daily $principal = New-ScheduledTaskPrincipal -UserID Dominio\ -LogonType Password
Action: se corresponde con la acción ejecutada (el script backup.cmd). Trigger: define la programación de la tarea. Principal: indica la cuenta utilizada. Aquí, cabe destacar que hay que especificar bien la contraseña "Password" en el argumento -LogonType. Se trata de la palabra clave que el sistema reconocerá para ir a buscar la contraseña actual de la gMSA. De este modo, para crear la tarea programada basándose en estas variables, es preciso ejecutar el comando: Register-ScheduledTask BackupViagMSA_Tarea -Action $action -Trigger $trigger -Principal $principal
No olvide, tampoco, asignar el permiso a la cuenta gMSA para iniciar sesión como proceso por lotes sobre los servidores (a través de la consola Administración de directivas de grupo a nivel de Configuración del equipo - Directivas - Configuración de Windows - Directiva de seguridad - Directiva local - Asignación de derechos de usuario). A continuación, se creará la tarea y será visible desde las Herramientas administrativas Programador de tareas. Para eliminar una cuenta MSA, tendrá que utilizar el siguiente comando PowerShell: Remove-ADServiceAccount -identity
Puede, también, eliminarla de Active Directory, mediante la consola Centro de administración de Active Directory. También es posible eliminar la cuenta MSA del servidor que la utiliza, mediante el siguiente comando: Remove-ADComputerServiceAccount -Identity -ServiceAccount
El comando Uninstall-AdServiceAccount desinstala la cuenta del servidor aunque no la elimina de Active Directory, a diferencia del comando anterior. Acaba de configurar su cuenta MSA para el equipo que lo necesita. De este modo, no tendrá que preocuparse de la gestión de la contraseña de este servidor. Puede consultar más información técnica sobre la implementación de las MSA en la siguiente dirección: http://technet.microsoft.com/es-es/library/dd548356(WS.10).aspx i. La papelera de reciclaje de Active Directory
Windows Server 2008 R2 introduce una funcionalidad que hará feliz a más un administrador. ¡Se trata de una papelera de reciclaje para objetos Active Directory! En efecto, en lo sucesivo, es posible restaurar un objeto de Active Directory que se haya eliminado sin tener que restaurar la última copia de seguridad, incluso sin tener que detener el servicio de uno de sus controladores de dominio (teniendo que reiniciarlo en modo DSRM y utilizando el comando NTDSUTIL). En lo sucesivo, es posible, gracias a esta funcionalidad, restaurar un objeto creado tras su última copia de seguridad disponible de Active Directory. Observe que desde Windows Server 2003 es posible utilizar la reanimación de objetos eliminados (durante 180 días, por defecto). El inconveniente principal de esta solución es que no restaura algunos atributos a un valor vinculado sino no vinculado. En concreto, esto significa que la restauración de una cuenta de usuario siguiendo este método no restaura su pertenencia a los grupos de seguridad y es preciso, por tanto, conocer esta información para agregarla a continuación. ¡La papelera de reciclaje de Active Directory le simplificará enormemente esta tarea! Antes de entrar en detalle a ver cómo puede implementarse, veamos, en primer lugar, su principio de funcionamiento. Principio general La funcionalidad de la papelera de reciclaje Active Directory se basa en cuatro atributos de Active Directory. isDeleted
Este atributo existe desde Windows 2000 Server. Está presente sobre todos los objetos del directorio. Indica si un objeto se ha eliminado pero puede ser restaurado. isRecycled Este atributo existe desde Windows Server 2008 R2. Está presente en todos los objetos eliminados una vez se activa la función de papelera de reciclaje de Active Directory. Indica que un objeto puede restaurarse utilizando la función de la papelera de reciclaje de Active Directory. msDS-DeletedObjectLifetime Este atributo existe desde Windows Server 2008 R2. Su valor determina el tiempo (en días) durante el que podrá restaurarse un objeto eliminado. Por defecto, su valor es igual al valor del atributo TombstoneLifetime. TombstoneLifetime Este atributo existe desde Windows 2000 Server. Desde Windows Server 2003 SP1, su valor por defecto es de 180 días. Este número de días sirve para propagar la información sobre un objeto eliminado a todos los controladores de dominio. Veamos, por tanto, qué ocurre cuando se elimina un objeto (una cuenta de usuario, por ejemplo) de Active Directory: •
•
Cuando se elimina un objeto, éste se desplaza al contenedor Deleted Objects que se encuentra en la raíz del dominio (en nuestro ejemplo: CN=Deleted Objects,DC=miempresa,DC=priv) y el atributo isDeleted toma el valor TRUE. El administrador dispone, entonces, del número de días definido en el atributo msDSdeletedOjectLifetime para restaurar el objeto mediante la funcionalidad de la papelera de reciclaje de Active Directory. Por defecto, su valor es igual al valor del atributo TombstoneLifetime, es decir, 180 días en la mayoría de situaciones. Dicho de otro modo, un objeto puede restaurarse mediante la papelera de reciclaje de Active Directory hasta 180 días después de su borrado, por defecto. Una vez superado el número de días definido por el atributo msDS-DeletedObjectLifetime, el atributo isRecycled recibe el valor TRUE. El objeto entra, entonces, en un nuevo estado disponible desde Windows Server 2008 R2 llamado "Recycled object" (disculpe el término anglosajón, pero no existe una traducción al castellano para este término en el momento de escribir estas líneas).
Llegado este momento, el objeto no puede restaurarse por completo (ni a través de la papelera de reciclaje de Active Directory, ni mediante una restauración completa) y pierde ciertos atributos cuyo valor estaba vinculado, a un estado no vinculado. El objeto queda, entonces, en este estado durante el tiempo definido por el valor del atributo TombstoneLifetime, de nuevo 180 días. El principal interés de este estado es avisar a los demás controladores de dominio que se ha eliminado un objeto.
•
Una vez superado el número de días definido por el atributo TombstoneLifetime (un total de 180 + 180 días, es decir, 360 días tras el borrado de la cuenta de usuario), el objeto se elimina "realmente" de Active Directory.
He aquí un esquema resumen:
Requisitos previos Los requisitos previos necesarios para utilizar la papelera de reciclaje de Active Directory no son despreciables. En efecto, es preciso que todos los controladores de dominio del bosque ejecuten, al menos, Windows Server 2008 R2. Será necesario, a continuación, extender el esquema a Windows Server 2008 R2 o superior (hemos explicado cómo hacerlo en la sección Instalación de un directorio de Active Directory). Cabe destacar, también, que activando la funcionalidad de papelera de reciclaje de Active Directory, no será posible disminuir el nivel funcional del dominio ni del bosque sin bajar del nivel Windows Server 2008 R2. Activación y uso La activación de la papelera de reciclaje se realiza mediante PowerShell o desde la consola Centro de administración de Active Directory. Mediante PowerShell: Abra una sesión sobre el controlador de dominio que alberga el rol de Maestro de nombres de dominio. Ejecute la consola PowerShell con una cuenta miembro del grupo de Administradores de empresas. Instale la funcionalidad PowerShell y el módulo PowerShell para Active Directory si no estuvieran presentes.
Ejecute, a continuación, los siguientes comandos e indique "S" (Sí) para validar los comandos. import-module ActiveDirectory (opcional) Enable-ADOptionalFeature ’Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target
Si no sabe si la papelera de reciclaje de Active Directory ya se encuentra activa, utilice el siguiente comando PowerShell: Get-ADOptionalFeature -filter * Si EnabledScopes posee algún valor, esto significa que la papelera de reciclaje de Active Directory está activa. Si estuviera vacío { }, significa que la papelera de reciclaje de Active Directory no se encuentra activa.
También es posible activarla desde el Centro de administración de Active Directory. Pulse las teclas [Windows] R y ejecute el comando dsac. Sitúese a nivel de su dominio y haga clic en Habilitar papelera de reciclaje.
Haga clic en Sí en el mensaje de alerta que indica que una vez activada la papelera de reciclaje no podrá desactivarse. Pulse la tecla [F5] en el teclado y compruebe que la opción Habilitar papelera de reciclaje queda sombreada en gris. Ahora que la papelera de reciclaje de Active Directory está activa, veamos cómo utilizarla reproduciendo distintos escenarios posibles en producción. Restauración de un objeto específico Tomemos como ejemplo un usuario de Active Directory eliminado por error. La replicación se realiza sobre todos los controladores de dominio y no ha tenido, en una situación de trabajo normal, otra opción que utilizar una copia de seguridad de su Active Directory. Gracias a la papelera de reciclaje de Active Directory, puede realizar esta operación en unos pocos minutos sin interrupción del servicio. En nuestro ejemplo, el usuario eliminado se llama "Fernando ROMERO" y su cuenta se ubica en la unidad organizativa "Central". Esta cuenta de usuario era, también, miembro de varios grupos de seguridad. Utilice PowerShell para visualizar los objetos eliminados que podrían restaurarse. Get-ADObject -filter ’isdeleted -eq $true -and name -ne "Deleted Objects"’ -includeDeletedObjects -property * | Format-List samAccountName,displayName,lastknownParent
La opción | Format-List permite interpretar el resultado del comando Get-Object y mostrar únicamente ciertos atributos que se devuelven en un formato fácilmente legible. Si suprime los argumentos del comando anterior tras la barra (carácter "|"), PowerShell le mostrará todos los atributos que se restaurarán para aquellos objetos que puedan restaurarse. Esto puede resultar interesante a título informativo, pero se revela, rápidamente, demasiado extenso para un entorno de producción en el que tenga varias decenas de objetos potencialmente restaurables.
Observe que un objeto solo puede restaurarse si se ha eliminado tras activar la papelera de reciclaje de Active Directory. Si un objeto se hubiera eliminado antes, no podría restaurarse con la papelera de Active Directory. Tendría, en tal caso, que restaurarlo utilizando una restauración estándar (mediante la herramienta ntdsutil.exe) partiendo de la última copia de seguridad que contenga el objeto a restaurar.
Una vez identificado el objeto, puede restaurarlo mediante el comando PowerShell Restore-ADObject: Get-ADObject -Filter ’samaccountname -eq "fromero"’ -IncludeDeletedObjects | Restore-ADObject
No aparece ninguna confirmación, aunque si vuelve a su consola Usuarios y equipos de Active Directory, verá que su cuenta de usuario se ha restaurado correctamente y sus atributos, tales como la pertenencia a los grupos de seguridad, están presentes. Windows Server 2012 incluye la posibilidad de restaurar un objeto de Active Directory mediante una interfaz gráfica. Para ello, es necesario tener instalado el cliente ADAC Windows 2012. Abra el Centro de administración de Active Directory (dsac.exe) y, a continuación, seleccione la visualización por arborescencia (en la parte superior izquierda) para visualizar y seleccionar el contenedor Deleted Objects.
Escoja la o las cuentas que desea restaurar y seleccione Restaurar o Restaurar en... si desea especificar un destino de restauración concreto. A continuación, se restaura la cuenta junto a su pertenencia a los grupos, su directiva de contraseña asociada si la tuviera, etc. Restauración de una unidad organizativa Tomemos, ahora, como ejemplo el borrado de una unidad organizativa, así como todos los objetos contenidos en ella (¡lo cual no habría ocurrido si hubiera estado activa la opción de protección contra la eliminación accidental estuviera activa sobre esta OU! Le invitamos no obstante, de manera excepcional, a desmarcar esta opción en las propiedades de la OU para realizar esta prueba). Podrá restaurar todos los objetos muy fácilmente. Sepa que, para poder restaurar el contenido, el contenedor debe estar disponible. Dicho de otro modo, si ha eliminado una OU y sus sub-OUs y quiere restaurar una cuenta concreta de una de las subOUs, tendrá que restaurar previamente la OU madre e hija. A menos, claro está, que escoja la opción de especificar un contenedor de restauración distinto al que estuviera definido inicialmente (mediante la opción Restaurar en...). La restauración se desarrolla en dos etapas. He aquí un primer método que utiliza PowerShell, para los puristas: En primer lugar, es necesario restaurar la unidad organizativa en su ubicación original. En nuestro ejemplo, restauraremos la OU "Central" que se encuentra en la raíz del dominio: Get-ADObject -filter ’msds-lastKnownRdn -eq "Central" -and lastKnownParent -eq "DC=miempresa,DC=priv"’ -includeDeletedObjects | Restore-ADObject
Una vez restaurada la unidad organizativa, puede ejecutar la restauración de todos los objetos que contenía a través de este comando: Get-ADObject -filter ’lastKnownParent -eq "OU=Central,DC=miempresa,DC=priv"’ -includeDeletedObjects | Restore-ADObject
Veamos ahora cómo realizar esta operación mediante el Centro de administración de Active Directory: Abra el Centro de administración de Active Directory y sitúese a nivel del contenedor Deleted Objects. La columna Principal último conocido será muy útil para poder clasificar y restaurar los objetos de una misma OU, por ejemplo. Seleccione la o las cuentas y OU que desee y haga clic en Restaurar.
Todos los objetos presentes en esta OU (usuarios, equipos, grupos, etc.) se restauran sin problema alguno. En lo sucesivo, será capaz de utilizar la papelera de reciclaje de Active Directory en caso de que se produzca alguna manipulación incorrecta de su directorio Active Directory. Tenga, no obstante, en mente que esta funcionalidad no debe eximirle de realizar copias de seguridad periódicas de sus controladores de dominio y habilitar la protección contra la eliminación accidental de sus objetos de Active Directory (al menos sobre sus OU). ¡Nunca se es demasiado prudente!.
j. Otras especificaciones desde Windows Server 2008 R2
Conforme aparecen nuevas versiones de Windows aparecen funcionalidades muy interesantes relacionadas con el directorio Active Directory. He aquí una lista, no exhaustiva, de las principales mejoras que han tenido lugar desde Windows Server 2008 R2: •
•
•
Unirse a un dominio en modo sin conexión (Offline domain join): el comando djoin permite pre-provisionar una cuenta de equipo sobre un controlador de dominio y crear el bloque asociado (Binary Large Object). Este bloque podrá, a continuación, desplegarse en el puesto cliente (mediante el registro o el archivo VHD) habilitando así una unión al dominio automática del puesto cliente al dominio (tras su reinicio). Será posible realizar esta unión incluso si el equipo no se encuentra conectado a la red de la empresa durante su reinicio. Windows Server 2012/2012 R2 y Windows 8/8.1 pueden utilizar djoin acoplándolo a una conexión DirectAccess (conexión VPN transparente que se aborda en el capítulo Acceso remoto). Encontrará más información sobre esta solución en el capítulo Despliegue de servidores y puestos de trabajo y, también, en la siguiente dirección: http://technet.microsoft.com/library/jj574150.aspx Centro de administración de Active Directory: con Windows Server 2008 R2 hace su aparición una nueva consola de gestión del directorio Active Directory, con el objetivo de remplazar a la consola Usuarios y equipos de Active Directory. Esta consola es una interfaz gráfica para PowerShell. También llamada Active Directory Administration Center o ADAC, puede ejecutarla a través las herramientas administrativas desde el administrador del servidor o ejecutando el comando dsac.exe. Las búsquedas globales permiten, en particular, ejecutar consultas LDAP predefinidas tales como el listado de usuarios cuya cuenta está desactivada o cuya contraseña ha expirado.
Esta consola se instala, por defecto, sobre un controlador de dominio igual o posterior a Windows Server 2008 R2. Requiere la presencia del módulo AD para PowerShell así como el servidor ADWS (Active Directory Web Service). •
Service Active Directory Web Service (ADWS) Este servicio está disponible desde Windows Server 2008 R2 y se instala por defecto tras la promoción de un servidor como controlador de dominio. Cuando un administrador ejecuta una consulta desde su consola de administración de Active Directory (dsac.exe), éste la traduce en un comando PowerShell mediante los cmdlets del módulo Active Directory PowerShell instalado. El comando PowerShell se transmite, a continuación, al servicio ADWS a través del puerto 9389/TCP mediante un protocolo WS-* (WS-Transfer, WS-Enumeration).
Observe que existe un servicio equivalente para las versiones anteriores de Windows Server, a partir de Windows Server 2003 SP2. Para ello, es necesario descargar e instalar el servicio Active Directory Management Gateway Service (ADMGS), con el que podrá, también, consultar a sus controladores de dominio utilizando comandos Power-Shell. Ambos servicios son equivalentes a diferencia de que ADMGS no podrá utilizar una instancia de instantánea de Active Directory. •
Active Directory Best Practices Analyzer Tool Tras la instalación del rol Active Directory, Windows Server 2012/2012 R2 instala, también, la herramienta Best Practice Analyzer Tool. Esta herramienta permite comprobar todo un conjunto de buenas prácticas a seguir y poner de manifiesto los errores de configuración de los controladores de dominio de su infraestructura, tanto para los controladores de dominio con Windows Server 2012 R2 como para los demás (2000/2003/2008/2008 R2/2012).
Las pruebas se ejecutan desde el Administrador del servidor o mediante comandos PowerShell.
Mediante PowerShell, ejecute los siguientes comandos para ver el estado de las distintas Best Practices para cada módulo: Import-Module ServerManager Import-Module BestPractices Get-BpaModel
Este comando permite recuperar el ID necesario para el comando siguiente. Seleccione el ID correspondiente al rol para el que desea realizar un scan. Invoke-BPAModel -BestPracticesModelId Microsoft/Windows/DirectoryServices
Este comando permite ejecutar la herramienta de buenas prácticas sobre el rol definido por su ID. Get-BpaResult -BestPracticesModelId Microsoft/Windows/DirectoryServices
Este comando permite visualizar los resultados del análisis anterior.
Desde el Administrador del servidor, vaya a AD DS y, a continuación, en la sección Analizador de procedimientos recomendados Tareas - Iniciar examen BPA.
Tenga en cuenta que esta herramienta también está disponible para los roles Active Directory Certificate Services (AD CS), DNS, Terminal Server y algunos otros que es posible visualizar mediante el cmdlet get-BPAModel. Ahora que se ha familiarizado con la administración del directorio Active Directory, descubramos una presentación en profundidad de las directivas de grupo.
Las directivas de grupo Las directivas de grupo se utilizan en el seno de un dominio de Active Directory para definir parámetros comunes a un conjunto de equipos. Microsoft provee mejoras muy útiles relativas a la gestión de las directivas de grupo desde Windows Server 2012. Se ponen a disposición del administrador varias opciones suplementarias, con esta nueva versión de Windows, cuyo objetivo es mejorar el buen trabajo que ya se había hecho con Windows Server 2008. A continuación se presentan las principales evoluciones de las directivas de grupo.
1. Detección de enlaces lentos La detección de enlaces lentos (también llamados, en ocasiones, "vínculos de baja velocidad", por Microsoft) permite limitar la aplicación de algunas directivas de grupo cuando el usuario se encuentra conectado mediante una red con baja tasa de transferencia. Antes, esta detección se realizaba gracias al protocolo ICMP, con todas las limitaciones que ello conllevaba. Por este motivo, Microsoft ha desarrollado el servicio de reconocimiento de ubicación de red (también llamado NLA por Network Location Awareness) para Windows Vista y Windows Server 2008. Gracias al servicio NLA, el refresco como tarea de fondo de su directiva de grupo será mucho más fiable, puesto que ya no se basa en el protocolo ICMP sino en RPC, conocido por su fiabilidad. Si su equipo intenta refrescar las directivas de grupo (por defecto, esto se produce cada 90 minutos), mientras el controlador de dominio no está accesible en ese preciso instante (si el usuario no está conectado a la red, por ejemplo), el refresco no se realizará en el próximo ciclo (90 minutos más tarde) sino cuando el controlador de dominio vuelva a estar disponible. El servicio NLA permite, en efecto, detectar muy rápidamente la disponibilidad del controlador de dominio en este caso concreto. Por otro lado, se ha optimizado el servicio Cliente de directiva de grupo, presente en un puesto Windows 8/2012 o versiones posteriores, y estará detenido la mayor parte del tiempo de cara a optimizar recursos de CPU. El servicio se inicia automáticamente durante 5 minutos y siempre respetando un retardo de 90 minutos, aproximadamente. Este inicio se controla, en lo sucesivo, mediante una tarea programada que se ejecuta con la cuenta SYSTEM (no puede, por tanto, visualizarla sino con la cuenta SYSTEM, utilizando el comando psexec, por ejemplo). Es posible volver al antiguo método de funcionamiento de este servicio habilitando la opción Desactivar la optimización de AOAC del servicio Cliente de la directiva de grupo en Configuración del equipo - Directivas - Plantillas administrativas - Sistema Directiva de grupo. Observe, también, que para los accesos mediante DirectAccess, se define un enlace por defecto si la velocidad de la conexión no se considera lo suficientemente rápida. De este modo, el inicio de sesión se ve mejorado, puesto que cuando se detecta un enlace lento, la aplicación de las GPO funciona de manera asíncrona. Esta configuración también es válida para conexiones 3G. Tenga en mente, también, que la opción Fast Startup de Windows 8 (opción que permite detener parcialmente el sistema operativo, haciéndole ganar tiempo de cara a la parada y el arranque del equipo) tiene consecuencias en los scripts de inicio y cierre de sesión, que no se ejecutarán. Será preciso habilitar la opción Fast Startup si desea seguir aprovechando este tipo de configuración de GPO.
2. Almacenamiento en caché de las directivas de grupo El almacenamiento en caché de las directivas de grupo está deshabilitado, por defecto, en Windows 8.1 y Windows Server 2012 R2. La opción no se aplica a las versiones anteriores de sistema operativo. La ventaja de esta funcionalidad es que acelera el proceso de inicio de sesión, pues el motor de directivas de grupo de Windows carga la información de las directivas desde una caché local, en lugar de descargarlas desde un controlador de dominio. El parámetro está disponible en Configuración del equipo - Directivas - Plantillas administrativas - Sistema - Directivas de grupo. Será necesario editar la opción Configurar almacenamiento en caché de directiva de grupo.
El almacenamiento en caché de las directivas de grupo permitirá, a los usuarios, obtener un mejor tiempo de inicio de sesión si las directivas se definen para ejecutarse en modo
Síncrono. El modo Síncrono, para una directiva de grupo, permite que su ejecución se realice en un orden bien definido antes de permitir al usuario iniciar la sesión en Windows. Esto resulta útil para la redirección de carpetas, la instalación de aplicaciones, la cuota sobre un disco, etc. Gracias a este parámetro, la información de las directivas se recuperará de manera local (a nivel de la carpeta C:\Windows\System32\GroupPolicy\Datastore) y un evento (5216) le confirmará el correcto funcionamiento de este almacenamiento en caché. Esta opción será particularmente útil para aquellos equipos conectados a redes con poco ancho de banda, o desde Internet mediante una conexión DirectAccess, por ejemplo.
3. El formato ADMX Con Windows Vista y Windows Server 2008 ha aparecido un nuevo formato de archivo, se trata de los archivos ADMX. Estos archivos se utilizan para mostrar las distintas opciones de las directivas de grupo. Poseen numerosas ventajas, en comparación a los formatos de archivos anteriores (los archivos ADM). Entre las principales ventajas de este nuevo formato, cabe destacar: •
•
•
El lenguaje utilizado en los archivos ADMX es el XML. Este formato está destinado a convertirse en un estándar en el intercambio de información entre aplicaciones, facilitando la interoperabilidad, etc. La creación de un almacén central que permita centralizar los archivos de plantillas ADMX en la carpeta SYSVOL, mientras que antes los archivos ADM se almacenaban con cada directiva de grupo de cada controlador de dominio (pudiendo provocar un gran volumen de datos a replicar, fenómeno que se conoce como Sysvol Bloat). Basta, entonces, con copiar/pegar los archivos ADMX de un puesto cliente con Windows Vista o Windows Server 2008 (disponible en la carpeta c:\Windows\PolicyDefinitions) a la carpeta PolicyDefinitions que habrá creado en el recurso compartido \\\SYSVOL\\Policies. Los administradores que quieran editar una directiva ya no tendrán que preocuparse por saber si disponen del archivo correcto de plantilla de directiva, dado que se recuperarán automáticamente desde el recurso compartido. Deberán, no obstante, acceder todos ellos a las directivas de grupo desde una misma versión de Windows y, si es posible, la más reciente para poder visualizar los parámetros del conjunto de puestos de trabajo. En efecto, si GPMC se ejecuta desde Windows Vista y se configura para recuperar información desde un almacén central, no le será posible visualizar los valores REG_MULTI_SZ o REG_QWORD, presentes únicamente desde Windows 7. La independencia del archivo de idioma que contiene el texto de cada una de las opciones de las directivas de grupo. Se asocia un archivo de idioma con la extensión. ADML a cada archivo ADMX. Es posible editarlo con ayuda de un simple editor de texto, puesto que tiene, también, formato XML. El detalle de las
modificaciones aportadas por el sistema al escoger una directiva no se almacena en el archivo ADML sino en el archivo ADMX asociado. Microsoft provee, por defecto, 146 archivos ADMX y otros tantos archivos ADML correspondientes al idioma del sistema operativo. Si había creado sus propios archivos de plantilla de directiva, con formato ADM, puede convertirlos al formato ADMX gracias a la herramienta ADMX Migrator que provee Microsoft en la siguiente dirección: http://www.microsoft.com/downloads/details.aspx?FamilyId=0F1EEC3D-10C44B5F-9625-97C2F731090C. Esta herramienta le permite, también, crear sus propios archivos ADMX. Observe que si el nivel funcional del dominio es, al menos, Windows Server 2008, será posible modificar la replicación de la carpeta SYSVOL para que utilice DFSR en lugar de FRS. Encontrará más información acerca de los inconvenientes y, sobre todo, las ventajas de la replicación mediante DFSR en la siguiente dirección: http://technet.microsoft.com/enus/library/cc794837(WS.10).aspx
4. Registro de eventos En las versiones anteriores a Windows 2008, los registros de eventos relativos a las directivas de grupo no eran sencillos de interpretar, puesto que el formato era poco comprensible para un administrador no iniciado. En adelante, es posible mostrar los eventos relativos a las directivas de grupo directamente desde el registro de eventos en un puesto con Windows Vista o Windows Server 2008 (o versiones posteriores). Windows Server 2012 R2 integra, a este respecto, eventos todavía más precisos, acerca de la duración de la descarga y la aplicación de una directiva, lo que le resultará muy útil para analizar la causa de una duración en la ejecución de las GPO anormalmente elevada. Para ello, haga clic en el menú Administrador del servidor y, a continuación, en Herramientas y Visor de eventos. Despliegue, a continuación, el menú Registros de aplicaciones y servicios - Microsoft Windows - GroupPolicy - Operativo.
Si utilizaba la herramienta Group Policy Log View para mostrar el archivo de registro de las directivas de grupo con un formato TXT o similar, sepa que ya no necesitará hacerlo con Windows Server 2012 R2 pues la opción de registro del sistema de archivos le permitirá guardarlo en varios formatos (¡en particular CSV o XML!). Escoja, para ello, la opción Guardar eventos seleccionados.... Puede, de este modo, recuperar mucho más fácilmente una gran cantidad de información relativa al funcionamiento de los distintos parámetros de las directivas de grupo aplicadas.
5. Parámetros de las directivas de grupo que debe conocer Con Windows Server 2008, se crearon nuevas categorías de directivas de grupo muy útiles, tales como, por ejemplo, las Preferencias de directivas de grupo (GPP). Las Preferencias de directivas de grupo ofrecen una alternativa a los scripts que se utilizan, muy a menudo, para personalizar el entorno del usuario. Es, en efecto, posible utilizar las directivas de grupo para configurar los lectores de red, los recursos compartidos, los usuarios y grupos locales, las opciones de alimentación, las impresoras que se quieren instalar, las tareas programadas, etc. Estos parámetros están disponibles en la consola Administración de directivas de grupo (gpmc.msc). Seleccione la opción de modificar una directiva existente, por ejemplo, en el
nivel Configuración del equipo (o usuario) - Preferencias - Configuración del Panel de control.
Es posible, para cada parámetro definido, agregar condiciones de aplicación del parámetro en cuestión. Puede, de este modo, decidir que se apliquen los lectores de red apuntando a un servidor en particular únicamente para aquellos usuarios con una dirección IP comprendida en un rango de direcciones que haya definido previamente. Desde Windows Server 2012 R2, este rango de direcciones puede definirse en formato IPv6.
Obtendrá más información acerca de las opciones de configuración en la siguiente dirección: http://technet.microsoft.com/es-es/library/cc733022.aspx Las preferencias de directivas de grupo se han visto mejoradas desde Windows Server 2012, en particular a la hora de considerar Internet Explorer 10 (disponible, únicamente, en una GPP "Usuario").
Internet Explorer 11 todavía no está integrado en las GPP, en el momento de escribir estas líneas, aunque no debería tardar dado que los demás parámetros de configuración de IE 11 ya están disponibles a nivel de Configuración del equipo (o Configuración de usuario) Directivas - Plantillas administrativas - Componentes de Windows - Internet Explorer. Estas GPO de preferencias pueden modificarse mediante el cmdlet de PowerShell GPPrefRegistryValue (o GPRegistryValue para los parámetros de GPO basados en modificaciones del registro). Para ello, será preciso importar el módulo mediante el comando Import-Module GroupPolicy. Desde Windows 2008 R2, los parámetros de la directiva de firewall e IPsec se han consolidado en una única consola MMC, accesible, también, desde cualquier directiva de grupo. Es, por lo tanto, posible definir reglas de tráfico entrante, tráfico saliente, y de seguridad de conexión (utilizando el protocolo IPsec) para los clientes con Windows Vista
y Windows Server 2008 o versiones posteriores. Estos parámetros están disponibles en Configuración del equipo - Directivas - Configuración de Windows - Configuración de seguridad - Firewall de Windows con seguridad avanzada.
Los parámetros de las directivas para IPsec y el firewall de las anteriores versiones de Windows están, todavía, disponibles en la antigua ruta Configuración del equipo Directivas - Plantillas administrativas - Red - Conexiones de red - Firewall de Windows.
6. La consola Administración de directivas de grupo La consola Administración de directivas de grupo (conocida, también, por el nombre GPMC por Group Policy Management Console) es una herramienta indispensable para administrar las directivas de grupo de su dominio Active Directory. Si el equipo desde el que desea editar las directivas de grupo no posee la consola GPMC, puede instalar dicha característica desde el Administrador del servidor - Agregar roles y características, haciendo clic en Siguiente hasta llegar a la etapa Características y marcando la opción Administración de las directivas de grupo.
La herramienta RSAT (por Remote Server Administration Tools) permite desplazar la configuración de las directivas de grupo (y, de manera general, la administración de roles y características de su servidor) desde un equipo cliente. Para Windows 8, es posible descargar esta herramienta en la siguiente dirección: http://www.microsoft.com/eses/download/details.aspx?id=28972
Para acceder a la consola GPMC, abra el Administrador del servidor y, a continuación, seleccione Herramientas y Administración de directivas de grupo. La consola le presentará, a continuación, la organización del o de los dominios del bosque que desee, sus OU y sub-OU, así como los objetos de directiva de grupo definidos.
Esta consola le permite: • •
• • • • •
Crear, modificar, eliminar o vincular sus directivas de grupo con los contenedores de los sitios, dominios o unidades organizativas del bosque que usted elija. Forzar la actualización de las directivas a nivel de toda una OU (creando una tarea programada en cada equipo). Es, también, posible realizar esta tarea mediante el cmdlet Invoke-GPUpdate. Configurar el filtrado de la aplicación de una directiva (mediante el filtro WMI o mediante la seguridad de la directiva). Gestionar la delegación. Definir los resultados de la directiva de grupo para simular la aplicación de una directiva antes de su puesta en producción. Realizar copias de seguridad y restauraciones de las directivas de grupo. etc.
Entre estas numerosas funcionalidades, no cabe olvidar dos opciones que han aparecido con Windows Server 2008. Se trata de la posibilidad de realizar búsquedas y definir plantillas de directivas. La función Buscar está disponible a dos niveles en la consola GPMC.
Para las grandes empresas que deban gestionar una gran cantidad de objetos de directiva de grupo, existe la función Buscar que está disponible haciendo clic con el botón derecho sobre el bosque o el dominio que desee. Es, a continuación, posible mostrar objetos de directiva de grupo que respondan a ciertos criterios que haya considerado y definido. Es, de este modo, posible mostrar las directivas para las que se ha definido alguna Configuración de seguridad.
La otra función Buscar disponible interesará a la mayoría de administradores. Esta función, accesible desde el editor de administración de directivas de grupo, le permite filtrar la visualización de las numerosas directivas ubicadas en el nodo Plantillas administrativas en función de criterios específicos. Puede, de este modo, encontrar los parámetros de directiva que respondan a sus necesidades, sin tener que navegar entre los miles de parámetros posibles. Para utilizar esta opción, realice los siguientes pasos:
Desde la consola GPMC, haga clic con el botón derecho en el objeto de directiva de grupo que desea modificar, seleccionando, a continuación, la opción Editar para acceder al editor. A continuación se abre el editor de administración de directivas de grupo. Vaya al nodo Plantillas administrativas: definiciones de directivas... en Configuración del equipo (o Configuración de usuario) - Directivas. Para iniciar una búsqueda entre todos estos parámetros, haga clic con el botón derecho en el nodo principal (o en una de las subcarpetas, aunque la búsqueda se realizará en todos los parámetros del nodo) y, a continuación, seleccione Opciones de filtro. Las opciones de filtrado se dividen en tres categorías que le permiten afinar su búsqueda. Puede, de este modo, seleccionar ver solamente los parámetros de la directiva que están configurados. También es posible realizar un filtrado por palabras clave. Por último, puede seleccionar ver los parámetros definiendo filtros de condiciones para mostrar, en unos pocos segundos, los parámetros aplicables a la familia Windows Vista, por ejemplo. El siguiente ejemplo define un filtro que muestra todos los parámetros que contienen la palabra clave activeX en el título del parámetro de la directiva, en el texto de la explicación o en el comentario (la pestaña comentario le permite, en efecto, agregar el texto que desee en la creación de una directiva de grupo o en la activación de algún parámetro). Haga clic, a continuación, en Aceptar para aplicar el filtro.
Una vez validado el filtro, la arborescencia del editor de directivas se actualiza automáticamente para mostrar únicamente aquellos parámetros que se corresponden con el filtro definido. Estos parámetros se agrupan, también, en el nodo Todos los valores.
Para deshabilitar el filtro y volver a una representación completa, haga clic con el botón derecho del ratón sobre una de las carpetas de Plantillas administrativas: definiciones de directivas y desmarque la opción Filtro activado (el icono Plantillas administrativas retomará su apariencia habitual). Windows 2012 aporta, además, dos funcionalidades importantes. Se trata de un resultado mejorado en el informe de Resultados de directivas de grupo y una interfaz que permite verificar el estado de las GPO en el conjunto del dominio. •
El resultado de la directiva de grupo se ha visto mejorado. Permite, como siempre, verificar las directivas que se aplican a un usuario y/o un equipo específico y aporta información suplementaria como, por ejemplo, eventuales errores detectados, el tipo de enlace (lento o rápido), si se ha definido el bucle invertido, el tiempo de aplicación de cada CSE (un CSE es un motor que se aplica a un conjunto de directivas). Esta información está disponible en los Resultados de directivas de grupo. Seleccione, a continuación, la cuenta y el equipo que quiere analizar y debería ver todos los parámetros definidos para el mismo.
•
La otra novedad interesante de la consola GPMC es la posibilidad de verificar el estado de un objeto GPO en el seno de todo un dominio Active Directory. En efecto, ya sabe que puede existir un pequeño retardo entre la modificación de una directiva en un controlador de dominio y su replicación en el conjunto de los demás controladores de dominio. En lugar de utilizar la herramienta GPOTool para
diagnosticar problemas vinculados con un usuario que ha actualizado sus directivas GPO sobre un controlador de dominio que no ha recibido la última versión, Microsoft ha mejorado la capacidad para identificar estos problemas integrando una herramienta de diagnóstico directamente en la consola de administración de directivas de grupo. Para ello, haga clic en Objetos de directiva de grupo y, a continuación, haga clic en el nombre de una de sus directivas. Se muestra una nueva pestaña, Estado. Puede hacer clic en Detectar ahora en la zona inferior derecha para iniciar una verificación del estado de esta GPO en el seno de todos los controladores de dominio del dominio.
El filtrado está, de momento, limitado a los parámetros definidos en las Plantillas administrativas. Si desea obtener una lista completa (aunque no exhaustiva) de los parámetros que agrupan la Configuración de seguridad, etc. descargue el archivo Group Policy Settings Reference for Windows and Windows Server (válido para Windows Server 2003 SP2/2008/2008 R2, 2012 y Windows Vista, Vista SP1, 7 y 8) con formato XLS o XLSX (sólo disponible en inglés): http://www.microsoft.com/downloads/details.aspx?familyid=18C90C80-8B0A-4906A4F5-FF24CC2030FB&displaylang=en
7. Los objetos GPO Starter Si es un poco observador, se habrá dado cuenta, sin duda, editando sus directivas de grupo mediante la consola GPMC desde un puesto de trabajo equipado con Windows Server 2008 o Windows Vista SP1 (o versiones superiores) que ha aparecido un nuevo parámetro. Se trata del contenedor Objetos GPO Starter. Esta opción consiste en crear plantillas de directivas de grupo que se refieren a parámetros disponibles en el nodo Plantillas administrativas únicamente (del lado Usuarios y Equipos). De este modo, es muy fácil crear varios objetos de directiva de grupo que se basarán en un conjunto de parámetros comunes, que deben definirse en sus directivas de grupo. De este modo, tras la creación de una nueva GPO, puede seleccionar un objeto GPO Starter Sourcer que haga referencia a un objeto GPO Starter existente. Microsoft ofrece, por defecto, una lista de GPO Starter relativa a los parámetros recomendados en su guía de securización de los distintos sistemas operativos. Provee, a su vez, desde Windows Server 2012, dos GPO Starter que permiten crear reglas de firewall adecuadas en los equipos cliente para permitir solicitar de manera remota un resultado o una actualización de directiva de grupo. Si edita un objeto GPO Starter desde un puesto con Windows Server 2008 R2 o Windows 7 (o versiones superiores) con las herramientas de administración RSAT instaladas obtendrá, directamente, los parámetros de la directiva de grupo recomendados para los escenarios descritos en las guías de seguridad de Windows Vista y XP. Si desea más información, en Windows 2008, puede obtener estos elementos después de descargarlos en la siguiente dirección: http://www.microsoft.com/Downloads/details.aspx?familyid=AE3DDBA7-AF7A-42749D34-1AD96576E823&displaylang=en También es posible exportar estas plantillas de GPO en un archivo CABinet (.CAB) para importarlas, a continuación, en un entorno totalmente diferente como, por ejemplo, su entorno de preproducción. Tras la primera activación de los objetos GPO Starter, se crea una carpeta llamada StarterGPOs en la carpeta SYSVOL del controlador de dominio. Se crea una nueva subcarpeta con un GUID asociado a cada nuevo objeto GPO Starter.
Para planificar una copia de seguridad del conjunto de sus directivas, no olvide marcar la opción Hacer copia de seguridad de todo disponible en el contenedor Objetos de directiva de grupo y, a continuación, Objetos GPO Starter.
Los demás componentes de Active Directory Existen otras cuatro funcionalidades principales nuevas, en lo que respecta a Active Directory, disponibles en Windows Server 2012 R2. Se trata de AD LDS, AD FS, AD RMS y AD CS.
1. Active Directory Lightweight Directory Services (o AD LDS) El rol AD LDS disponible desde Windows Server 2008 R2 con este nombre es el equivalente a ADAM (Active Directory Application Mode), que apareció con Windows Server 2003 R2. Se trata de una versión depurada del Active Directory Domain Services (AD DS, es decir, el Active Directory "clásico" mencionado a lo largo de todo este capítulo) que descansa sobre los mismos principios (a saber una replicación multipropósito, un directorio dividido en particiones, etc.) pero que no almacena ningún componente de seguridad de Windows (como las cuentas de usuario y ordenadores de dominio), las directivas de grupo, etc. El rol AD LDS permite, de este modo, distribuir la información necesaria a las aplicaciones en un directorio centralizado antes que individualmente en cada aplicación. Las ventajas de no tener que integrar las aplicaciones en AD DS son diversas. • •
Una aplicación podrá actualizar el esquema en AD LDS en lugar de en AD DS, lo que evitará riesgos inútiles de corrupción del esquema. Una aplicación accesible desde la extranet o mediante VPN ya no expondrá el conjunto del dominio AD DS si tiene como directorio de referencia a AD LDS.
Observe que es posible tener varias instancias de AD LDS en un mismo servidor, igual que es posible tener el rol AD LDS instalado en un Windows Server 2008 R2/2012 y 2012 R2 con el rol AD DS. El único requisito previo es que los puertos donde escuchan las distintas instancias sean diferentes. Encontrará más información acerca de este tema en la siguiente dirección: http://technet.microsoft.com/es-es/library/cc754361(v=ws.10).aspx
2. Active Directory Federation Services (o AD FS) El componente Active Directory Federation Services permite implantar una solución de acceso securizado entre distintas plataformas Windows o no Windows para el acceso de las aplicaciones Web (sobre una extranet, por ejemplo).
El uso típico de implantar un AD FS en su empresa consiste en permitir a un cliente que haya firmado recientemente un contrato para conectarse desde otra red (el caso de un contrato B2C), a una empresa asociada (el caso de un contrato B2B) o a una federación de empresas (bosques múltiples) acceder a los recursos de su red de una forma simple y sin tener que autenticarse en su base de datos de cuentas de usuario. Se crea en efecto una relación de aprobación entre la red asociada y la suya con el objetivo de proyectar la identidad de los usuarios y sus privilegios de acceso desde su red hacia los socios reconocidos. De este modo el usuario no tendrá que identificarse de nuevo (principio de autenticación único también llamado SSO por Single Sign On). Observe que, desde Windows Server 2012 R2, AD FS soporta el protocolo OAuth 2.0. Este protocolo lo utilizan cada vez con mayor frecuencia los distintos fabricantes y proveedores de servicios en Internet, pues permite publicar e interactuar con datos autenticando al usuario de forma segura. Es, también, el caso de Windows Azure Authentication Library (AAL), cuyo soporte se ha extendido a los directorios AD FS. También es conveniente saber que esta solución está limitada únicamente al acceso a través de aplicaciones Web (con HTTPS) aunque como estas últimas son cada vez más potentes, las posibilidades abiertas son también enormes. Es el caso por ejemplo con la integración de SharePoint Server 2007/2010/2013 o de AD RMS, que presentaremos más adelante. Para poder implantar un AD FS, existe un conjunto de funcionalidades y de servicios que deben haberse implantado de forma previa: • • • •
El rol AD DS o AD LDS debe estar instalado en, al menos, una de las redes implicadas. Servidor de federación de cuentas/recursos. Servidor Web ADFS. Cliente.
Encontrará más información acerca del concepto AD FS en la siguiente dirección: http://technet.microsoft.com/es-es/library/cc755828(v=ws.10).aspx a. Workplace Join
Workplace Join es una de las mejoras más destacadas de Windows Server 2012 R2. BYOD (Bring Your Own Device) está al llegar. Consiste, para una empresa, en autorizar a sus empleados a utilizar sus propios dispositivos personales (ordenadores, smartphones, etc.) para conectarse a la red de la empresa. Si bien esto representa un ahorro y una flexibilidad muy importantes para la empresa, también puede conllevar inconvenientes en la medida en que la empresa no tiene control sobre los equipos informáticos en cuestión.
Consciente del problema, Microsoft se ha implicado en la cuestión y propone, en adelante, el uso de los Workplace Join (término que todavía no se ha traducido de manera oficial por parte de Microsoft en el momento de escribir estas líneas). De este modo, el equipo en cuestión, si bien es propiedad del empleado, podrá declararse y administrarse en un directorio AD FS. De este modo, el certificado permitirá al terminal conectarse a su directorio y autenticarse. Será, entonces, posible solicitar a AD FS que gestione el acceso a los recursos a través de directivas globales de autenticación, y también gestionar la autenticación y el control de acceso multipropósito. Observe que, en lo relativo a smartphones, Microsoft soporta de momento los dispositivos que funcionan con Windows (2012 R2 y 8.1) e iOS (Android no está soportado en el momento de escribir estas líneas, aunque debería estarlo en breve). Los servicios proporcionados por el Workplace Join son los siguientes: •
•
•
Una mejor experiencia de usuario puesto que podrá aprovechar el SSO (Single Sign On) y, de este modo, no tener que volver a autenticarse con cada una de sus aplicaciones desde su dispositivo personal. Una mejor seguridad, puesto que la contraseña no se almacenará en el dispositivo local sino que circulará mediante un ticket de sesión que se pasará directamente a las aplicaciones cuando se solicite realizar una autenticación (siempre que se haya configurado de este modo para utilizar SSO). Un mejor manejo de los equipos que se conectan a recursos de la empresa puesto que, como se ha explicado antes, cada equipo se registrará en AD FS y recuperará un certificado que le permitirá identificarse de forma única en la red.
Workplace Join utiliza la funcionalidad Device Registration Service. Ligado al proxy web de aplicación (Web Application Proxy), será posible utilizar Workplace Join con equipos conectados desde Internet. Encontrará una presentación más completa del proxy web de aplicación en el capítulo dedicado al Acceso remoto. Por supuesto, esta funcionalidad no permite tener un control tan importante sobre los puestos como si fueran miembros de un dominio de Active Directory, pero se trata de un paso importante para controlar mejor los equipos en el marco de una iniciativa BYOD y mejorar la experiencia del usuario reforzando la seguridad de acceso a sus aplicaciones. Es, por otro lado, posible definir una política de bloqueo de las "cuentas utilizadas en la extranet" y que no se conectan a través del proxy web de aplicación. De este modo, si el número de intentos de autenticación erróneos supera un valor límite definido mediante el comando de PowerShell Set-ADFSProperties - ExtranetLockoutThreshold, entonces el valor BadPassword de AD ya no se incrementará a nivel de controlador de dominio (con el rol Emulador PDC) del AD vinculado a este AD FS. Esto evitará un gran número de ataques tales como la denegación de servicio, capaz de bloquear un gran número de cuentas tras intentos de conexión intencionadamente erróneos desde el exterior de la red de la empresa.
Por último, uno de los evolutivos más importantes de AD FS con la aparición de Windows Server 2012 R2 es la autenticación y el control multifactor. La autenticación multifactor consiste en forzar un método de autenticación suplementario además del que ya se utiliza por defecto con los terminales que utilizan el Workplace Join. Esto resulta particularmente útil para dotar de seguridad el acceso a una aplicación sensible que requiera, por ejemplo, la presencia de un certificado en el equipo de trabajo además de la contraseña, que seguirá siendo necesaria para acceder a la aplicación. Si posee únicamente una de estas dos credenciales de autenticación, no podrá acceder a la aplicación (puede obtener más información en la siguiente dirección: http://technet.microsoft.com/enus/library/dn280949.aspx). El acceso multifactor permite dar acceso a recursos si, y solamente si, se cumplen varias condiciones por parte del usuario (y no únicamente la tradicional pertenencia a un grupo de seguridad). Esto mejora, en parte, la gestión de pertenencia que se aborda en el capítulo Securizar su arquitectura (a nivel del control de acceso dinámico). Para obtener más información acerca del acceso multifactor: http://technet.microsoft.com/enus/library/dn280937.aspx#BKMK_2 Encontrará todos los elementos necesarios para implementar Workplace Join en las siguientes direcciones: http://technet.microsoft.com/en-us/library/dn280938.aspx y http://technet.microsoft.com/en-us/library/dn280939.aspx
3. Active Directory Rights Management Services (o AD RMS) AD RMS (Active Directory Rights Management Services) es un rol que permite limitar la difusión y proteger archivos, correos electrónicos o sitios Web de su empresa. AD RMS funciona con aplicaciones compatibles con RMS tales como Microsoft Office Profesional 2003/2007/2010/2013, Internet Explorer 7.0 o superior, etc. El principio de uso de las funcionalidades de AD RMS se basa en el principio de una licencia de publicación que se entrega con el archivo. El usuario indica el conjunto de privilegios y de condiciones específicas para este documento. Estas propiedades lo acompañarán protegiéndolo a lo largo de su ciclo de difusión. De este modo será capaz de controlar las posibles acciones sobre un archivo o su contenido, de definir una duración de validez (por ejemplo, para un presupuesto), etc. Así, cuando el archivo difundido se abra por primera vez en una aplicación compatible AD RMS, éste último contacta con el servidor AD RMS que haya emitido la licencia de publicación asociada al archivo para pedir autorización de acceso a su contenido. El servidor AD RMS verifica a continuación si el usuario solicitante está autorizado a visualizar el contenido del archivo, y en tal caso le envía una licencia de uso que le permita acceder al contenido del documento. El usuario puede entonces abrir el archivo mediante la aplicación compatible RMS.
En Windows 2012, la instalación de AD RMS se ha mejorado (es posible desplegarla en servidores remotos, con permisos de instalación más flexibles, y compatible con SQL 2005 SP3, SQL 2008 SP3, SQL 2008 R2 SP1 y SQL Server 2012). Es, también, posible en lo sucesivo delegar más fácilmente los permisos de acceso a los documentos compartidos (en el caso de una secretaria o asistente que deba acceder a los documentos de un responsable, por ejemplo). Observe que el rol puede, en lo sucesivo, instalarse en modo Server Core y es totalmente instalable y configurable mediante PowerShell.
4. Active Directory Certificate Services (o AD CS) Para completar este apartado, es importante mencionar el único rol que no hemos visto todavía. Se trata del servicio de certificados de Active Directory (también conocido bajo el nombre de Active Directory Certificate Server o AD CS). Este rol le permitirá instalar una entidad emisora de certificados en su red de empresa para poder emitir certificados de forma sencilla a sus usuarios y equipos. Estos últimos podrán a su vez acceder a los sitios Web mediante el protocolo SSL sin tener que comprar certificados (a menudo costosos) a una autoridad de certificación pública. La ventaja de tener una entidad emisora de certificados de empresa basada en Windows Server 2012 R2 consiste en el hecho de que el proceso de emisión y de renovación de los certificados se ve enormemente facilitado mediante la integración de esta autoridad en Active Directory. Existen dos tipos de entidades emisoras de certificados. •
•
Entidad emisora de certificados de empresa: requiere que el servidor que posee el rol AD CS estén integrado en Active Directory y permite, de este modo, aprovechar numerosas funcionalidades suplementarias (tales como la auto inscripción) y administrarse a través de las directivas de grupo. Entidad emisora de certificados independiente: que puede instalarse tanto en un servidor miembro del dominio como en un servidor que no lo sea, aunque no aprovechará las funcionalidades suplementarias.
La implementación de esta solución supera el alcance de este libro. He aquí, no obstante algunas de las principales funcionalidades disponibles desde Windows Server 2008 en lo que respecta a este rol. Desde Windows Server 2008: •
La emisión de certificados a través de su navegador se ha mejorado pues se basa en un nuevo control llamado CertEnroll.dll.
•
• •
•
Tiene en cuenta el protocolo NDES (Network Device Enrollment Service) que permite a los dispositivos periféricos (routers, conmutadores, etc.) obtener certificados X.509. Tiene en cuenta el protocolo OSCP (Online Certificate Status Protocol) que permite mejorar la gestión de la revocación de los certificados. En lo sucesivo, el modelo de certificado en la versión 3 disponible en las entidades emisoras de certificados de empresa tiene en cuenta la criptografía de nueva generación (CNG Suite-B). Una nueva consola MMC llamada PKIView está disponible para administrar de forma más eficaz los certificados a lo largo de su ciclo de vida.
Observe también que, desde Windows Server 2008 R2, se han incluido las siguientes funcionalidades: •
La auto inscripción (es decir, la inscripción automática de una máquina en la entidad emisora de certificados para obtener un certificado) es posible mediante una conexión HTTP (con la condición de tener el nivel funcional del esquema Active Directory en 2008 R2). Esta opción se ha mejorado con Windows Server 2012 (véase más adelante). Una de las ventajas principales es la posibilidad de solicitar un certificado desde un bosque diferente al de la entidad emisora de certificados. También es posible publicar el servicio Web correspondiente sobre un servidor en DMZ para entregar certificados a los usuarios de Internet. Este servicio Web será el único autorizado a dialogar con la entidad emisora de certificados que se encuentre en su LAN. Observe no obstante que tal configuración sólo está aconsejada para renovar los certificados ya emitidos y no para emitir certificados a los clientes conectados desde Internet. Encontrará el manual de uso (en inglés) acerca de esta nueva funcionalidad en la siguiente dirección: http://download.microsoft.com/download/C/2/2/C229E62436E4-4AD8-9D86F564ED539A16/Windows%20Server%202008%20R2%20Certificate%20Enrollme nt%20Web%20Services.doc y, también, https://social.technet.microsoft.com/wiki/contents/articles/7734.certificateenrollment-web-services-in-active-directory-certificate-services.aspx. Requisitos previos: para+ permitir la unión desde un bosque diferente, se requiere una entidad emisora de certificados de empresa en Windows Server 2003/2008/2008 R2/2012 y en versión Entreprise o Datacenter con cualquier versión de Windows Server 2012/2012 R2; el nivel funcional del bosque debe ser Windows Server 2008 R2 y los equipos cliente deben trabajar con Windows 7 o versiones superiores.
•
Consolidación de las entidades emisoras de certificados en el seno de la empresa que posean varios bosques con relación bidireccional. En efecto, la entidad emisora de certificados en 2008 R2 soporta el uso de los "LDAP Referals" lo que permite redirigir la consulta hacia el dominio correcto en el bosque adecuado. Requisitos previos: Entidad emisora de certificados de empresa en Windows Server 2008 R2 o superior Entreprise o Datacenter; nivel funcional del bosque 2003 y relaciones de aprobación inter-bosque bidireccionales.
•
Mejora de la entidad emisora de certificados que deba entregar una gran cantidad de certificados. Esto es especialmente válido para clientes NAP basados en IPSec. En efecto, los clientes deben solicitar varios certificados al día. Si lo desea, puede escoger que no se guarde una copia de seguridad de los certificados emitidos en la base de datos de la entidad emisora de certificados. La etapa de copia de seguridad entraña a menudo un crecimiento exponencial de la base de datos y por consiguiente un coste en su administración. Si elige no guardar una copia de seguridad de estos registros de certificados en la base de datos, no le será posible revocarlos. Este riesgo es no obstante aceptable en la medida en que los certificados afectados tengan un tiempo de vida corto. Requisitos previos: Entidad emisora de certificados de empresa en Windows Server 2008 R2 o superior.
Desde Windows Server 2012: •
• • •
Administración y despliegue mediante Windows PowerShell (véase http://go.microsoft.com/fwlink/p/?LinkID=242169 (cmdlets para el despliegue) y http://go.microsoft.com/fwlink/p/?LinkID=242165 (cmdlets para la administración)). AD CS y sus servicios asociados pueden ejecutarse sobre cualquier versión de Windows Server 2012. El modo Server Core permite instalar AD CS. Se tiene en cuenta la renovación automática de los certificados para los equipos que no son miembros de un dominio. Esta consideración se basa en el nuevo modelo de certificados (versión 4) y sólo puede utilizarse en Windows 8/2012 y permite, en particular, importar una renovación de los certificados con la misma clave. Puede encontrar más información acerca del nuevo modelo de certificado v4 en la siguiente dirección: http://go.microsoft.com/fwlink/p/?LinkId=242425
•
•
Se tienen en cuenta los nombres de dominios internacionales (es decir, que no contengan caracteres que puedan representarse con formato ASCII) en ciertos escenarios. Una mayor seguridad activa por defecto en el servicio de rol Entidad emisora de certificados; que impone, en particular, el cifrado de la consulta mediante RPC_C_AUTHN_LEVEL_PKT (parámetro que no está habilitado en las versiones anteriores de Windows; y que no es compatible con Windows XP).
Conclusión En este capítulo acaba de descubrir el conjunto de soluciones de gestión de la identidad y de acceso que proporciona Windows Server 2012 R2. De este modo, podrá abordar de la mejor forma posible las necesidades en términos de acceso a los recursos, tanto para implementar una solución de tipo SSO (Single Sign On o "identificación única") como para controlar la difusión de los archivos en su empresa.
Introducción En este capítulo se aborda la arquitectura distribuida (DFS) y se presenta la instalación, la configuración de nodos raíz, los enlaces, la replicación DFS-R y las herramientas.
Descripción de DFS El acrónimo DFS significa Distributed File Systems. Se trata de un sistema de archivos único, lógico, jerarquizado, que estructura los archivos compartidos entre varios equipos de la red bajo la forma de una arborescencia lógica de recursos de sistema. El principal objetivo de DFS consiste en referenciar a todos los recursos compartidos que queremos hacer accesibles de manera uniforme y centralizar los espacios disponibles sobre los distintos espacios. Esto permite obtener una vista uniforme y permanente de los datos que ya no estarán vinculados con los servidores físicos sobre los que se encuentran. Además del ahorro en unidades de red, puesto que una única letra permite alcanzar todos los espacios compartidos, las aplicaciones pueden configurarse, de una vez por todas, utilizando una ruta única y definida, que no cambiará, incluso aunque los datos se desplacen entre dos servidores, en particular en el caso de que evolucione la volumetría necesaria. Otra posibilidad, muy interesante, consiste en poder replicar los datos de una misma carpeta sobre varios enlaces de red, es decir, sobre varios espacios compartidos. Esta tolerancia a fallos aporta una funcionalidad muy próxima a la de un clúster de archivos. Aunque es preciso, no obstante, estudiar bien su modo de funcionamiento para evitar cualquier sorpresa.
He aquí cómo organiza DFS los recursos que residen en distintos componentes de la red:
La arborescencia DFS constituye un punto único de referencia. Sea cual sea su ubicación, los usuarios pueden acceder fácilmente a los recursos de la red. Sobre la red, las unidades DFS se ven como unidades compartidas de red clásicas y se gestionan, por tanto, mediante la función de redirección de archivos utilizando los clientes de red clásicos. Un usuario que navegue en una carpeta compartida DFS no tiene por qué conocer el nombre ni la localización del servidor sobre el que se encuentra un recurso concreto. El acceso a los recursos de red se ve, así, simplificado. Tras haberse conectado a una raíz DFS, puede recorrer la estructura y acceder a todos los recursos ubicados en esta raíz. Un recurso compartido DFS utiliza una estructura de arborescencia que contiene una raíz y enlaces DFS. Para iniciar el uso de DFS, es necesario crear una raíz DFS. Desde Windows Server 2003, es posible crear varias raíces. Cada raíz puede soportar varios enlaces, y cada una de ellas puede apuntar a una carpeta compartida en red. Los enlaces DFS de la raíz DFS representan carpetas compartidas que pueden estar físicamente ubicadas en distintos servidores de archivos. Las ventajas ligadas a DFS son las siguientes. Para resumir, he aquí todas las ventajas de esta solución:
•
• • • •
• •
•
La administración de la red se ve simplificada. En caso de que caiga algún servidor, el enlace DFS puede desplazarse hacia otro servidor, modificando así la carpeta DFS para indicar el nuevo servidor donde se ubican las carpetas compartidas. La ruta sigue siendo la misma de cara a los usuarios. El espacio de nombres permite acceder a todos los recursos utilizando un nombre único, sin tener que mapear una letra para cada recurso. DFS se integra con los clientes Windows y no requiere ningún agente o el uso suplementario de memoria. Los servidores de archivos pueden remplazarse sin verse afectado el espacio de nombres que utilizan los clientes. El reparto de carga y la tolerancia a fallos pueden mejorarse en las raíces y en los enlaces que se desee proteger indicando varios servidores y espacios compartidos sobre cada recurso. Existen varios marcos de utilización de estas soluciones. El espacio de nombres puede extenderse de manera dinámica para incluir un espacio de disco complementario y para tener en cuenta nuevos requisitos. DFS utiliza todas las autorizaciones existentes. No se necesita ninguna regla o autorización suplementaria por parte de los usuarios. Las listas de control de acceso (ACL) asociadas a las carpetas replicadas se replican de la misma manera que los datos. Para acelerar la búsqueda y recorrer más rápidamente la arborescencia DFS, ésta se aloja automáticamente en caché sobre los clientes tras su primer uso, hasta que se detiene el cliente o expira la contraseña.
Instalación A diferencia de las versiones anteriores, los módulos DFS ya no están integrados ni se inician automáticamente sobre los servidores Windows. La única excepción, aunque importante, es la referida a los controladores de dominio que utilizan la replicación DFS para las carpetas compartidas SYSVOL. Los componentes DFS forman, ahora, parte del rol Servicios de archivos y almacenamiento: • •
El módulo FS-DFS-namespace aparecerá bajo el nombre Espacios de nom-bres DFS. El módulo FS-DFS-Replication aparecerá bajo el nombre Replicación DFS.
¡El comando SERVERMANAGERCMD.EXE ya no existe! Es posible utilizar ambos módulos por separado de cara a responder a necesidades diferentes. También es posible replicar carpetas, o publicar espacios de nombres, aunque lo ideal es utilizar ambas funcionalidades al mismo tiempo.
1. El módulo de espacio de nombres Como con Windows 2003, es posible crear varios espacios de nombres. Estos espacios se publican en Active Directory (AD). La instalación del módulo de espacio de nombres puede realizarse a través de PowerShell mediante el comando: Install-WindowsFeature FS-DFS-namespace
2. El módulo de replicación El módulo de replicación permite crear grupos de replicación de datos. Una replicación debe contener, al menos, dos recursos compartidos que provengan de dos servidores diferentes. La instalación del módulo de replicación puede hacerse mediante el comando PowerShell: Install-WindowsFeature FS-DFS-Replication
Observe que la replicación mediante las herramientas Microsoft no es obligatoria. Es posible utilizar enlaces DFS para apuntar sobre varios recursos compartidos. Pero, si desea un contenedor idéntico, tendrá que replicarlo de manera explícita utilizando las herramientas o los scripts adecuados.
3. La consola de administración Si lo requiere, la consola de administración puede instalarse de manera separada a los demás módulos y funcionalidades. La consola de administración se encuentra en el Administrador del servidor, en el menú Herramientas, Administración de DFS. La instalación puede realizarse también mediante el comando PowerShell: Install-WindowsFeature RSAT-DFS-Mgmt-con
Tras ejecutar la consola, bastará con preguntar a Active Directory para obtener la lista de raíces DFS existentes.
4. El caso de los controladores de dominio Sobre un controlador de dominio, los servicios de espacio de nombres y de replicación se instalan automáticamente, pero Active Directory gestiona directamente sus propias carpetas compartidas. No es, por tanto, posible ver o modificar a este nivel la replicación utilizada por Active Directory para replicar el recurso compartido SYSVOL.
5. El procedimiento de instalación gráfica La instalación gráfica permite agregar todos los componentes necesarios de una sola vez. Esto se realiza a partir de la herramienta Administrador del servidor. En la visualización por defecto del Panel se encuentra el botón Administrar, que da acceso a la opción Agregar roles y características. He aquí las distintas etapas: Haga clic en Siguiente. Esta etapa puede ignorarse en futuras ocasiones marcando la opción adecuada.
Seleccione la instalación de un rol o una característica. Es posible instalar varios roles o características de una sola vez.
Una de las ventajas de Windows Server 2012 es que permite automatizar ciertas operaciones sobre varios servidores a la vez, tales como el reinicio o la configuración del reporte de los errores. En cambio, la instalación de un rol o una funcionalidad solo puede realizarse sobre un único servidor que debe seleccionar. Por defecto, se le propone realizar la instalación en el servidor local.
Sitúese en el rol Servicios de archivos y almacenamiento y, a continuación Servicios de iSCSI y archivo. Las opciones marcadas y sombreadas indican roles y componentes que ya están presentes en el servidor.
Basta, a continuación, con seleccionar entre los Servicios de rol los componentes deseados. Seleccionamos, en primer lugar, el módulo Espacios de nombres DFS.
El hecho de marcar el componente Espacios de nombres DFS hace que se proponga, automáticamente, instalar la característica de administración correspondiente. Haga clic en el botón Agregar características para aceptar y agregar el componente sugerido.
Marque el servicio de rol Replicación DFS y haga clic, a continuación, en Siguiente para pasar a la instalación de las características. En este ejemplo, ya está marcado debido a nuestra selección anterior.
No hay características suplementarias que agregar. Haga clic en Siguiente.
Haga clic en Instalar. Evitaremos, generalmente, marcar la opción Reiniciar automáticamente el servidor de destino en caso necesario.
Haga clic en Cerrar cuando le aparezca la opción.
Tras la instalación, los servicios arrancan automáticamente. Si hace clic sobre el icono Notificaciones en la barra de tareas, obtendrá el estado de la tarea solicitada.
Configuración del servicio DFS 1. Los distintos tipos de raíces distribuidas a. Las raíces autónomas
Las raíces autónomas permiten crear arborescencias que están vinculadas con un servidor determinado. Estas raíces no están securizadas, es decir, la raíz DFS no estará accesible, ni podrá utilizarse, si el servidor que la contiene no funciona correctamente. En cambio, los accesos directos a los recursos compartidos seguirán funcionando.
Observe que las carpetas (enlaces a recursos compartidos) pueden, no obstante, replicarse y sincronizarse mediante un grupo de replicación específico. Por otro lado, si la raíz autónoma se configura sobre un clúster de archivos, la raíz DFS aprovechará la misma tolerancia a fallos que la compartición de archivos. No obstante sólo será posible realizar esta operación en un clúster Windows Server 2008 o 2012. He aquí el procedimiento de creación de una raíz autónoma. La consola Administración de DFS puede abrirse desde el menú Herramientas del Administrador del servidor. Utilizando el asistente de creación de un espacio de nombres Nuevo espacio de nombres, esta operación puede llevarse a cabo muy rápidamente. Haga clic con el botón derecho en Espacios de nombres para desplegar el menú contextual. A continuación, haga clic en Nuevo espacio de nombres.
Los servidores de espacios de nombres no pretenden recibir directamente datos. Sólo contienen, por lo general, carpetas virtuales que apuntan sobre los datos reales. Se trata, a menudo, de servidores controladores de dominio que se utilizan para seguir este tipo de información.
Indique el nombre de servidor del espacio de nombres.
Indique el nombre de su espacio de nombres. Haga clic en Editar configuración... para indicar los permisos que se quiere asignar sobre la raíz RAÍZ AUTÓNOMA que se verá como un recurso compartido en el servidor correspondiente.
Hay que prestar atención a los permisos que se asignan a este nivel, pues los elementos creados en la raíz de este recurso compartido se encontrarán, efectivamente, en la carpeta local indicada.
La elección del tipo de espacio es relevante, entre una raíz que será específica a este servidor y una raíz llamada de nombres de dominio que podrá verse y utilizarse en todo el bosque. La raíz autónoma sólo podrá verse en el servidor donde se aloja. Seleccione el tipo de espacio de nombres que quiere crear, en este caso Espacio de nombres independiente.
Esta pantalla resume las decisiones anteriores. Haga clic en el botón Crear.
Esta pantalla confirma la creación de la raíz DFS. La pestaña Errores da acceso a los eventuales errores que se produzcan. El registro de eventos ofrecerá información complementaria.
b. Las raíces de nombres de dominio
Las raíces de nombres de dominio se basan en la resolución DNS del dominio. La principal ventaja de esta solución es la tolerancia a fallos, que puede asociarse a la raíz mediante el uso de, al menos, dos servidores vinculados a nivel de la misma raíz. Las raíces se inscriben en Active Directory, lo que permite a los administradores y a los usuarios de todo el bosque acceder fácilmente a las unidades DFS. He aquí el procedimiento de creación de una raíz de nombres de dominio. Los primeros pasos son idénticos a la creación de una raíz autónoma. Ejecute el asistente de creación de un Nuevo espacio de nombres.
Indique el servidor que gestionará esta raíz.
Indique el Nuevo espacio de nombres, teniendo en cuenta que el nombre debe escogerse de manera lógica puesto que podrán verlo y usarlo todos los usuarios del bosque, o incluso más.
Haga clic en Editar configuración para acceder a la configuración de las autorizaciones sobre la raíz.
El espacio de nombres de dominio permite basarse en la resolución del nombre de dominio Active Directory para acceder a un espacio compartido fácil de encontrar.
Se recomienda utilizar el modo Windows 2008, seleccionado por defecto (siempre que se lo permita el nivel funcional). El modo Windows 2008 activa el modo ABE (Access Based Enumeration) y un número mucho mayor de raíces y destinos. Haga clic en Crear si los parámetros de creación son correctos.
Observe que la creación de la raíz de dominio estará vinculada con el modo de funcionamiento del domino que lo alberga. El uso de una raíz de dominio supone que se quiere utilizar tolerancia a fallos y reparto de carga sobre la raíz DFS. Esto se consigue agregando un servidor de espacios de nombres suplementario. Haga clic en el espacio de nombres del tipo de dominio.
Haga clic en Agregar servidor de espacio de nombres. Puede, también, seleccionar o indicar directamente el nombre del nuevo servidor a utilizar.
De hecho, puede haber más de dos servidores que contengan información sobre los DFS.
2. Creación de enlaces DFS y destinos DFS El nombre de un enlace se corresponde con el nombre de la carpeta que aparece en el espacio de nombres distribuido. Un enlace DFS se corresponde con una ruta de red, es decir, un recurso compartido ubicado sobre no importa qué servidor (o estación del dominio) y que se asocia a un enlace DFS. Es posible asociar un enlace DFS con varios destinos y, por tanto, a varios recursos compartidos diferentes. Será, por tanto, necesario configurar la replicación de estas carpetas para obtener un contenido idéntico y sincronizado entre los distintos destinos. He aquí el procedimiento que permite definir un destino sobre los recursos compartidos CONTAB1 y CONTAB2 definidos sobre dos servidores distintos: Seleccione el espacio de nombres deseado (autónomo o de dominio) y, a continuación, haga clic con el botón derecho para desplegar el menú contextual. Seleccione la opción Nueva carpeta. Indique el nombre del enlace DFS CONTAB. Haga clic en Agregar para agregar los destinos asociados a este enlace. Puede escribir directamente el nombre UNC de acceso al recurso bajo la forma \\SERVIDOR\RECURSO_COMPARTIDO o hacer clic en Examinar. En el segundo caso, se recomienda indicar el nombre del servidor y, a continuación, hacer clic en el botón Ver las carpetas compartidas. Si se definen varios destinos, el asistente le propone crear un grupo de replicación. A continuación, se ejecuta automáticamente el asistente de creación de un grupo de replicación.
En la siguiente sección se describe el procedimiento de implantación de la replicación.
3. Replicación La replicación se basa en un motor multimaestro que permite tener en cuenta modificaciones de archivos simultáneas que provengan de varios puntos diferentes y sincronizar el conjunto. Esta replicación se adapta a los enlaces lentos utilizando una tecnología de compresión diferencial llamada RDC. Cada grupo de replicación (conjunto de servidores) es capaz de tener en cuenta varias carpetas replicadas. Cada carpeta replicada puede tener sus propios parámetros, en particular filtros de replicación que permiten limitar los tipos de archivo y las subcarpetas que deben incluirse en la replicación. a. Los filtros de replicación
Por defecto, los filtros de archivo excluyen los filtros temporales que comienzan por el carácter ~ así como las extensiones .BAK y .TMP. Por otro lado, los siguientes archivos también se excluyen: • • •
puntos de montaje NTFS; archivos cifrados mediante EFS; archivos definidos como temporales.
Es posible excluir tanto carpetas como archivos, en función de su nombre. Es posible utilizar el carácter genérico *. Las bases de datos, los archivos de vídeo y las imágenes de CD pueden, también, excluirse de esta replicación. b. La implementación gráfica de la replicación
He aquí el procedimiento gráfico de implementación de una replicación. Esta replicación se implementa de la misma manera sobre una raíz autónoma que sobre una de dominio. Seleccione el módulo Replicación y, a continuación, haga clic con el botón derecho para desplegar el menú contextual. Seleccione la opción Nuevo grupo de replicación. Esta opción permite, principalmente, definir una replicación ligada únicamente a dos servidores, donde uno de ellos contendrá los datos principales.
Asigne un nombre al grupo de replicación.
Indique los servidores miembros.
Seleccione la tipología que mejor se adapte a sus necesidades. La topología en malla completa está bien adaptada a las modificaciones autorizadas que provienen de todos los servidores miembros.
Según las características de su red, será posible modular los horarios y la tasa de uso de la red.
Más adelante podrá modificar fácilmente los parámetros de replicación. Es preferible iniciar la replicación con carpetas vacías. En caso contrario, esta opción permite definir el servidor que contiene los datos iniciales. Seleccione el servidor inicial que contiene los datos de referencia.
Indique el nombre concreto de la carpeta raíz que se quiere replicar.
Es posible agregar otras carpetas a este grupo de replicación de manera inmediata o más adelante.
Por cada servidor que contenga una réplica de los datos, active la replicación indicando una carpeta de destino. Seleccione el servidor y, a continuación, haga clic en Editar.
Cabe destacar la posibilidad de configurar esta réplica en modo de sólo lectura de manera inmediata. Esta opción permite indicar el nombre de la carpeta principal y crearla, si fuera necesario.
Seleccione los servidores de destino.
Esta pantalla resume los principales parámetros de la replicación.
He aquí el resultado de la implementación de la replicación.
La implementación efectiva dependerá del funcionamiento de Active Directory y de la planificación de la replicación que haya configurada entre los sitios.
c. La topología de replicación
Por defecto, se proponen dos tipos de topología. •
El modo Concentrador y radio, llamado en estrella, requiere, como mínimo, tres miembros. Este modo es particularmente útil cuando existe una fuente definida (el Concentrador) y la replicación se produce hacia múltiples destinos.
•
El modo malla completa autoriza a cada servidor replicarse hacia los demás. Se aconseja utilizar este modo en el caso de instalaciones compuestas por una decena de miembros como máximo.
La implementación de una nueva topología depende de la replicación Active Directory y puede, por tanto, tomar su tiempo antes de implementarse sobre cada miembro. En cambio, la replicación local de los archivos (de tamaño razonable) puede resultar muy rápida y, generalmente, instantánea.
Configuración avanzada 1. Los métodos de ordenación Los métodos de ordenación son muy importantes y deben tomarse en consideración de cara a optimizar el rendimiento y evitar futuros disgustos. En efecto, cuando una misma carpeta está accesible en ubicaciones diferentes, situadas en servidores distintos, ellos mismos alojados en sitios diferentes, la optimización lógica consistiría en utilizar el recurso compartido situado sobre el servidor del sitio local. Incluso en este caso, resulta vital utilizar de forma prioritaria un servidor determinado que sirva como referencia. En otros casos, será conveniente forzar un servidor remoto que sirva como referencia única para evitar modificaciones simultáneas sobre un documento. a. Configuración a nivel de las raíces DFS
La pestaña Referencias en las propiedades de las raíces DFS permite definir el valor por defecto que se utiliza sobre todos los enlaces que pertenecen a esta raíz. • • •
Orden aleatorio Coste más bajo Excluir destinos fuera del sitio cliente
El Orden aleatorio consiste en proveer, de manera aleatoria, todos los servidores situados en el sitio del cliente y, a continuación, y siempre de forma aleatoria, los demás servidores presentes en los demás sitios sin tener en cuenta las diferencias de coste. El Costo más bajo presentará, en primer lugar, aquellos servidores ubicados en el sitio del cliente de manera aleatoria. A continuación, los servidores remotos se mostrarán según su coste, del menos elevado al más elevado, aunque aquellos servidores que tengan un coste idéntico se presentarán aleatoriamente. El último modo, Excluir destinos fuera del sitio cliente mostrará, únicamente, aquellos servidores ubicados en el sitio del cliente. Más adelante veremos las posibles excepciones a esta regla. Si se fuerza, a este nivel, la restauración automática de clientes sobre los destinos preferidos, se activará sobre todos los enlaces y destinos que dependan de esta raíz. En la pestaña Opciones avanzadas es, ahora, posible activar el modo ABE (Access Based Enumeration) para ocultar aquellas carpetas sobre las que los usuarios no tienen permisos.
b. Configuración a nivel de los enlaces DFS
Sobre cada carpeta que represente un enlace hacia uno o varios destinos, es posible configurar una exclusión de los sitios remotos, en particular si no se ha indicado anteriormente. Es posible, también, activar la restauración automática de los clientes hacia un destino preferente (si no se hubiera configurado en un nivel superior). c. Configuración a nivel de los destinos DFS
Sobre cada destino, en la pestaña Opciones avanzadas, es posible configurar un comportamiento particular. Es posible dar preferencia al uso de un destino definiéndolo como Primero de todos los destinos o Primero de los destinos de igual costo. Puede, por el contrario, definir el destino como Último de todos los destinos incluidos en la selección, o Último de los destinos de igual costo.
Preste atención, estas reglas forzadas (Primero o Último) provocan la visualización sistemática de los destinos correspondientes.
2. Delegación de la administración Por defecto, sólo los administradores locales o de dominio pueden administrar los grupos de replicación. Sobre una raíz de dominio, sólo el grupo administradores de empresas hereda, automáticamente, permisos de administración. Sobre una raíz autónoma, el grupo administradores local y la cuenta especial SYSTEM tienen permisos heredados. Cuando un administrador crea una raíz, éste, y el grupo administradores de dominio, obtienen permisos explícitos. Esto quiere decir que es posible eliminar estos permisos.
Preste atención, los administradores que reciben una delegación siguen siendo propietarios de los objetos, incluso aunque se los retire, a continuación, un administrador. Por otro lado, cualquier administrador de una raíz DFS puede delegar la autorización de la gestión.
Administración de DFS con PowerShell Todos los comandos de administración DFSUTIL, DFSCMD, DFSRADMIN, DFSRDIAG, DFSRMIG siguen existiendo. Aunque está previsto que desaparezcan en la próxima versión, la administración de todos los componentes y servicios de Windows se están estandarizando gracias al lenguaje PowerShell, que sirve de referencia. La primera etapa consiste en importar el módulo que contiene todos los comandos DFS: Import-module DFSN
Observará que los comandos PowerShell se refieren, únicamente, a la gestión del espacio de nombres .La gestión de la replicación no se ve afectada. Las herramientas de programación WMI pueden ser útiles en este caso. Todos los recursos compartidos basados en nombres de servidores que se utilizan en los comandos siguientes deben crearse previamente. • •
Crear la carpeta Crear un recurso compartido
El conjunto de comandos permite definir, mediante un script PowerShell, una configuración equivalente a la que se ha creado anteriormente mediante la interfaz de administración.
1. Administración de los espacios de nombres con PowerShell a. Gestión de raíces
Este comando permite enumerar todas las raíces registradas en el directorio. Get-DfsnRoot | ft -auto -wrap
Resultado: Path type Properties TimeToLiveSec State on ---------------------------- -----\\MiEmpresa.Priv\RAIZ-DOMINIO Domain V2 Site Costing 300
Descripti --------Online
El comando FT utiliza detrás el carácter especial | que permite tabular el resultado y mejorar su lectura. Crear una raíz de árbol de dominio nueva llamada RAIZ2-DOM2. Cada recurso compartido utilizado debe existir previamente.
New-DfsnRoot -Path ’\\MiEmpresa.Priv\RAIZ2-DOM2’ -Targetpath ’\\SRVFIC01\RAIZ2’ -Type domainV2
Resultado: Path Type on -------\\MiEmpresa.Priv\...
Properties
TimeToLiveSec
State
Descripti
----------
-------------
-----
---------
Domain V2
300
Online
El parámetro PATH debe indicar el dominio y el nombre de la raíz que utilizarán, a continuación, los usuarios. El parámetro TARGETPATH debe apuntar hacia un servidor y un recurso compartido ya existente. El parámetro TYPE precisa que la raíz se gestionará en modo 2008. Los demás valores posibles son Standalone, para una raíz autónoma, y DomainV1 para el modo 2003. ¡Observe que es necesario agregar manualmente la nueva raíz en la herramienta de administración si queremos gestionarla gráficamente! Enumerar todos los servidores de nombres que soporten la raíz RAIZE2-DOM2: Get-DfsnRoot -Path \\MaSociete.Priv\RACINE2-DOM2|Get-DfsnRootTarget | ft -auto
Resultado: Path TargetPath ReferralPriorityRank -------------
State
ReferralPriorityClass
-----
--------------------- --------------------
\\MiEmpresa.Priv\RAIZ2-DOM2 \\SRVFIC01\RAIZ2 Online sitecost-normal 0
Agregar un nuevo servidor de espacios de nombres en una raíz existente. Get-DfsnRoot -Path \\MiEmpresa.Priv\RAIZ2-DOM2|New-DfsnRootTarget -Targetpath \\DC2012\RAIZ2 -ReferralPriorityClass "sitecostnormal"
Resultado: Path TargetPath State ReferralPriorityRank -----------------
ReferralPriorityClass ---------------------
\\MiEmpresa.Priv\RAIZ... \\DC2012\RAIZ2
Online
-------------------sitecost-normal
Preste atención, el parámetro ReferralPriorityClass es obligatorio.
0
Enumerar y verificar la agregación del servidor que administra una raíz determinada: Get-DfsnRoot -path \MiEmpresa.Priv\RAIZ2-DOM2|Get-DfsnRootTarget |ft -auto
Resultado: Path ----
TargetPath ----------
State ReferralPriorityClass ReferralPriorityRank ----- --------------------- --------------------
\\MiEmpresa.Priv\RAIZ2-DOM2 \\SRVFIC01\RAIZ2 Online sitecost-normal 0 \\MiEmpresa.Priv\RAIZ2-DOM2 \\DC2012\RAIZ2 Online sitecost-normal 0
Para eliminar un servidor que gestiona una de las raíces: Get-DfsnRoot -Path \\MiEmpresa.Priv\RAIZ2-DOM2 |Remove-DfsnRootTarget -TargetPath \\DC2012\RAIZ2 -Confirm:false
La opción -confirm con valor False permite evitar la pregunta, que puede resultar bloqueante en la ejecución de un script. Eliminar todos los servidores que gestionan una raíz: Get-DfsnRoot -Path \\MiEmpresa.Priv\RAIZ2-DOM2 | Get-DfsnRootTarget | Remove-DfsnRootTarget -Confirm:false
Preste atención, la eliminación de todos los servidores que gestionan una raíz equivale a suprimir la propia raíz. Por ello, las consolas de administración DFS que contengan esta raíz obtendrán un error de acceso sobre esta raíz. Si se trata de una raíz que no va a volver a utilizarse de forma permanente, basta, en tal caso, con eliminarla en la consola de administración DFS. b. Gestión de los destinos (de carpetas) y de los accesos
Nunca hay que utilizar directamente las raíces DFS para almacenar datos en ellas. Estas raíces se alojan, generalmente, en controladores de dominio que no tienen los mecanismos de copia de seguridad bien adaptados, ni espacio para alojar información. Crear un destino de carpeta en un espacio de nombres: New-DfsnFolder -Path \\MiEmpresa.Priv\RAIZ2-DOM2\INFO -TargetPath \\SRVFIC1\INFORMATICA -Description "Departamento Informático" -EnableTargetFailback true
Agregar un destino suplementario en una carpeta existente: New-DfsnFolderTarger -Path \\MiEmpresa.Priv\RAIZ2-DOM2\INFO targetPath \\DC2012\INFORMATICA Path TargetPath State ReferralPriorityClass ReferralPriorityRank
----
----------
----- ---------------------
\\MiEmpresa.Priv\RAIZ... \\DC2012\INFORMATICA
--------------------
Online sitecost-normal
0
Eliminar un destino: Remove-DfsnFolderTarget -Path \\MiEmpresa.Priv\RAIZ2-DOM2\INFO -TargetPath \\DC2012\INFORMATICA -Force
Eliminar la carpeta y los destinos correspondientes: Remove-DfsnFolder -Path \\MiEmpresa.Priv\RAIZ2-DOM2\INFO -Force
Ninguna de las instrucciones anteriores elimina los datos de los usuarios, que siguen estando en los recursos compartidos de los respectivos servidores.
2. Administración de la replicación con PowerShell Los 42 nuevos comandos están accesibles mediante la siguiente instrucción: Get-Command -Module DFSR
He aquí un comando que permite obtener detalles sobre cada uno de los comandos: Get-Command -Module DFSR | Get-Help | Select-Object Name, Synopsis | Format-Table -Auto
a. Ejemplo de creación de la infraestructura necesaria para un grupo de replicación de dos servidores
Crear el grupo de replicación: New-DfsReplicationGroup -GroupName "GrupoReplicacionContabilidad"
Observe que el grupo de replicación no se mostrará en la consola de administración, será preciso agregarlo para poder gestionarlo desde la consola. Crear una carpeta en el grupo de replicación: New-DfsReplicatedFolder -GroupName "GrupoReplicacionContabilidad" -FolderName "Contabilidad"
Agregar los servidores: Add-DfsrMember -GroupName "GrupoReplicacionContabilidad" -ComputerName SRVFIC01, DC2012
Verificar los miembros del grupo de replicación:
Get-DfsrMember -GroupName GrupoReplicacionContabilidad
Agregar las conexiones de replicación: Add-DfsrConnection -GroupName "GrupoReplicacionContabilidad" -SourceComputerName SRVFIC01 -DestinationComputerName DC2012
Se agrega una conexión en cada sentido. Agregar las carpetas a replicar entre los servidores: Set-DfsrMembership -GroupName "GrupoReplicacionContabilidad" -FolderName "Contabilidad" -ContentPath "C:\CarpetasContabilidad" -ComputerName SRVFIC01 -PrimaryMember /$True -force
Este comando agrega el contenido inicial que servirá de referencia. Set-DfsrMembership -GroupName "GrupoReplicacionContabilidad" -FolderName "Contabilidad" -ContentPath " C:\CarpetasContabilidad" -ComputerName DC2012 -force
Este comando agrega un miembro suplementario. Actualizar los servidores a partir del directorio Active Directory: Get-DfsrMember -GroupName "GrupoReplicacionContabilidad" | Update-DfsrConfigurationFromAD
La siguiente etapa consiste en verificar que la replicación está funcionando. El evento 4104 en el registro específico de la replicación DFS indica que ha finalizado la replicación inicial. b. El clonado de la base de DFSR
Se han agregado algunas instrucciones específicas para mejorar la replicación inicial cuando existe un conjunto importante de archivos iniciales: He aquí las cuatro instrucciones que se utilizan: Export-DfsrClone Import-DfsrClone Get-DfsrCloneState Reset-DfsrCloneState
El objetivo de este clonado es ahorrar tiempo en el análisis y la replicación de una arborescencia importante copiando la base de DFSR y los datos correspondientes en el sistema de destino. La primera etapa consiste en exportar la base de DFSR del volumen a una carpeta local. Cree la carpeta de destino: MD C:\ClonadoBaseDFSR
Exportar la base de DFSR del volumen E a la carpeta que acaba de crear: Export-DfsrClone -Volume E: -Path C:\ClonadoBaseDFSR -force | Format-List
Este comando acepta dos opciones: •
La opción -validation, que acepta tres valores:
•
None: no se realiza ninguna verificación de los archivos. Este valor no se aconseja, pues supone que no se realizará ninguna modificación. Basic: este valor, por defecto, es el recomendado. Existe una serie de permisos (ACL) que, junto al tamaño y la fecha, determinan si el archivo se ha modificado. Full: es el modo normal, utilizado por DFS, desaconsejado en una replicación con un volumen muy elevado (superior a 10 TB).
• •
•
Por defecto, la exportación funciona únicamente si la carpeta de destino de la base está vacía. La opción -AllowClober permite borrar los archivos presentes.
Supervisar la ejecución y esperar el estado Ready: Get-DfsrCloneState
En efecto, el grupo de replicación debe existir antes de realizar la exportación de su configuración. He aquí las instrucciones mínimas a realizar en el origen para obtener un grupo de replicación que contenga un único miembro: • •
New-DfsReplicationGroup -GroupName "GrupoReplicacionContabilidad"
• • •
New-DfsReplicatedFolder -GroupName "GrupoReplicacionDATA" -FolderName "DATA"
• • •
Add-DfsrMember -GroupName "GrupoReplicacionDATA" -ComputerName SRVFIC01
Crear el grupo de replicación:
Agregar la carpeta de datos:
Agregar el servidor origen que contiene los datos:
• • • •
Set-DfsrMembership -GroupName "GrupoReplicacionDATA" -ComputerName "SRVFIC01" -ContentPath E:\DATA -PrimaryMember $True -FolderName "DATA" -force
• •
Update-DfsrConfigurationFromAD
Agregar el recurso de datos a la carpeta de datos:
Actualizar la configuración a partir del directorio:
Una vez exportada la base, la siguiente operación consiste en replicar la base salvaguardada, y también los datos correspondientes. Robocopy.exe E:\Data \\DC2012\E$ \DATA /E /B /COPYALL /R:1 /W:1 /MT:64 /XD DfsrPrivate /TEE /LOG+:Precarga.log •
Replicación de la copia de seguridad de la base de DFSR correspondiente al volumen a replicar:
•
Robocopy.exe C:\ClonadoBaseDFSR \\DC2012\C$\ClonadoBaseDFSR
•
Como precaución, limpiar la base de DFSR que podría residir en el servidor de destino:
•
RD "E:\system volume information\dfsr" -Force -Recurse
/B
Es conveniente no realizar esta acción en el disco que contiene la replicación de las bases de DFSR de los controladores de dominio, u otras replicaciones de DFS. • •
Importar la base de DFSR en el nuevo volumen: Import-DfsrClone -Volume E: -Path "C:\ClonadoBaseDFSR" -force
La opción -force permite evitar que pida la confirmación. •
Verificar, a continuación, que la integración de la base está lista, mediante el estado Ready:
•
Get-DfsrCloneState
• • •
Add-DfsrMember -GroupName "GrupoReplicacionDATA" -ComputerName "DC2012"
Agregar el servidor de destino en el grupo de replicación:
•
Indicar que el servidor pertenece al grupo de datos DATA, así como la ruta de los datos en este servidor:
• • •
Set-DfsrMembership -GroupName "GrupoReplicacionDATA" -ComputerName "DC2012" -ContentPath E:\DATA -FolderName "DATA" -force
• • •
Add-DfsrConnection -GroupName "GrupoReplicacionDATA" -SourceComputerName "SRVFIC01" -DestinationComputerName "DC2012"
Por último, agregar la conexión de replicación entre los dos servidores:
• •
Actualizar el servidor de destino a partir de la información del directorio. Update-DfsrConfigurationFromAD
Utilizando este método de importación de la base, la verificación inicial puede pasar de 24 días a menos de 8 horas para un volumen de cerca de 10 TB, es decir, para obtener la convergencia de 14 millones de archivos a verificar, utilizando el nivel de validación "por defecto".
Uso de DFS y buenas prácticas El uso de DFS no requiere ninguna adaptación en los puestos cliente. En efecto, del lado del usuario (y de los clientes Windows), los recursos compartidos DFS y las raíces se ven como recursos compartidos clásicos. Es frecuente, en el script de conexión, realizar una conexión con la raíz, a menudo remplazando todas las conexiones anteriores. Por otro lado, es importante tener en cuenta que las raíces DFS de dominio están disponibles para todos los usuarios del bosque. No obstante, todos los permisos asociados a los recursos compartidos y a las carpetas NTFS siguen estando activos como si se tratase de un acceso directo. En cambio, el uso de DFS permite simplificar el número de unidades de disco y de recursos compartidos utilizados. Esto permite federar el conjunto de espacios disponibles. Las aplicaciones pueden configurarse sobre una ruta única, que será posible mantener a lo largo de todo el ciclo de vida del bosque. DFS, en su configuración Hub & Spoke, se diferencia por la replicación en varios sitios de información que cambia poco con el tiempo o que tiene un único punto de modificación. Documentos de referencia, noticias, actas de reunión o información general serán el tipo de documento entrante en este tipo de configuración. DFS puede, también, utilizarse para salvaguardar los datos de usuario o los perfiles itinerantes. Es preciso realizar una configuración particular a nivel de los destinos DFS para que se utilice siempre el mismo recurso compartido y el mismo servidor. Es decir, es preciso utilizar el destino principal en primer lugar, y no proponer la copia (salvaguarda) sino como último destino. Cuando se utiliza DFS para tareas ofimáticas, con numerosos documentos de tipo Word o Excel, actualizándose sobre distintos sitios, es importante gestionar bien el versionado de los documentos para evitar cualquier modificación simultánea del mismo documento. En efecto, sólo se conservará la última versión escrita. En ciertos casos, será preferible forzar el uso de un destino determinado que servirá como referencia para las modificaciones de este tipo, incluso si el sitio del usuario incluye una replicación local de este destino. La
solución ideal, cuando sea posible, consiste en utilizar el modo Solo lectura con todos los destinos, salvo con el destino de referencia. Con todo, aunque DFS no es la solución universal, puede proveer muchos servicios que merece la pena comparar con otras soluciones, por ejemplo, de gestión documental.
Interacción con otros componentes 1. Los espacios de nombres DFS: detección del sitio por parte de los clientes DirectAccess Windows Server 2012 ofrece, ahora, la posibilidad a los usuarios remotos conectados mediante DirectAccess de utilizar el mejor enlace DFS posible, según el sitio. Los usuarios remotos reciben referencias hacia los servidores de nombres y las carpetas más próximas a la ubicación de la conexión. Con las conexiones DFS realizadas por DirectAccess en Windows 7 o Windows Server 2008 R2, los equipos remotos cuya dirección IP no forma parte de un sitio específico en Active Directory reciben una sola referencia. Esta referencia contiene únicamente un nombre de servidor que proviene de cualquier sitio, local o remoto. Cuando las conexiones DFS se realizan mediante DirectAccess en Windows 8 o Windows Server 2012, el equipo provee un nombre de sitio en la solicitud de referencia (Request Referral) que apunta a un servidor de espacios de nombres que utiliza Windows Server 2012. El servidor de espacios de nombres utilizará el sitio transmitido para proveer la referencia hacia el sitio más próximo disponible. Para que esta detección funcione, el cliente debe ejecutar Windows 8 o Windows Server 2012, y el servidor trabajar con Windows Server 2012. Observe que la instalación de varios puntos de acceso basados en DirectAccess está, ahora, mucho mejor gestionada que con Windows Server 2008, de ahí el interés de apuntar al servidor DFS mejor adaptado.
2. La replicación DFS soporta los volúmenes sobre los que se ha activado la desduplicación De hecho, la desduplicación permite ganar espacio sin tener ningún impacto sobre la replicación DFS. Cuando se activa la desduplicación sobre un volumen, los archivos se segmentan en bloques de tamaño variable según el tamaño del archivo. La desduplicación gestiona un índice sobre estos segmentos para detectar los segmentos idénticos y ocupar una única vez el espacio correspondiente. Una marca de desduplicación
IO_REPARSE_TAG_DEDUP indicará cada archivo susceptible de incluir elementos deduplicados. La replicación seguirá a las marcas de desduplicación de tipo IO_REPARSE_TAG_DEDUP para reconstruir el archivo completo. Que un archivo esté desduplicado o no, no supone ninguna replicación puesto que el archivo, en sí mismo, no cambia. La replicación DFS se basa en el algoritmo RDC (Remote Differential Compression) y no sobre los fragmentos de los archivos desduplicados, que se ubican de forma separada. Que los volúmenes estén desduplicados en el origen y/o en el destino no cambia nada.
3. DFS dispone de un proveedor WMI completo (espacios de nombres y replicación) Windows Server 2012 proporciona, ahora, un proveedor WMI que permite acceder y realizar una configuración completa de la replicación DFS... gwmi -list | ft name | findstr /I "dfs" Win32_DfsNode Win32_DfsTarget Win32_DfsNodeTarget Win32_PerfFormattedData_DFSNServerService_DFSNamespace Win32_PerfRawData_DFSNServerService_DFSNamespace Win32_PerfFormattedData_DFSNServerService_DFSNamespaceServiceAPIRequests Win32_PerfRawData_DFSNServerService_DFSNamespaceServiceAPIRequests Win32_PerfFormattedData_DFSNServerService_DFSNamespaceServiceReferrals Win32_PerfRawData_DFSNServerService_DFSNamespaceServiceReferrals Win32_PerfFormattedData_dfsr_DFSReplicatedFolders Win32_PerfRawData_dfsr_DFSReplicatedFolders Win32_PerfFormattedData_dfsr_DFSReplicationConnections Win32_PerfRawData_dfsr_DFSReplicationConnections Win32_PerfFormattedData_dfsr_DFSReplicationServiceVolumes Win32_PerfRawData_dfsr_DFSReplicationServiceVolumes
A continuación, se muestra un ejemplo de acceso a la información de una de estas clases: gwmi -class win32_dfsnode __GENUS : 2 __CLASS : Win32_DfsNode __SUPERCLASS : CIM_LogicalElement __DYNASTY : CIM_ManagedSystemElement __RELPATH : Win32_DfsNode.Name="\\\\SRVFIC01\\RAIZ-AUTONOMA" __PROPERTY_COUNT : 8 __DERIVATION : {CIM_LogicalElement, CIM_ManagedSystemElement} __SERVER : SRVFIC01 __NAMESPACE : root\cimv2 __PATH : \\SRVFIC01\root\cimv2:Win32_DfsNode.Name="\\\\SRVFIC01\\ RAIZ-AUTONOMA"
Caption Description InstallDate Name Root State Status Timeout PSComputerName ...
: : : : : : : : :
\\SRVFIC01\RAIZ-AUTONOMA True 0 300 SRVFIC01
Hoy en día, como existen los comandos PowerShell para la parte Espacios de nombres, es, principalmente, la parte de replicación la que se configurará mediante WMI. Sepa que el acceso WMI puede invocarse, fácilmente, desde PowerShell, y será posible integrar el conjunto en un único script. WMI, a diferencia de PowerShell, permite administrar completamente la replicación mediante DFS: http://msdn.microsoft.com/enus/library/windows/desktop/bb540028(v=vs.85).aspx He aquí las clases que se utilizan para ello: • • • • • • • • • • • • • • • •
DfsrConfig DfsrConflictInfo DfsrConnectionConfig DfsrConnectionInfo DfsrIdRecordInfo DfsrIdUpdateInfo DfsrInfo DfsrLocalMemberConfig DfsrLocalMemberInfo DfsrMachineConfig DfsrReplicatedFolderConfig DfsrReplicatedFolderInfo DfsrReplicationGroupConfig DfsrSyncInfo DfsrVolumeConfig DfsrVolumeInfo
Una de las principales diferencias es que, ahora, el acceso WMI utiliza el protocolo WinRM (Windows Remote Management) como protocolo de transporte.
BranchCache Esta funcionalidad, aparecida con Windows Server 2008 R2, permite optimizar el acceso a los recursos compartidos alojados en los recursos compartidos de los archivos o en
servidores Web internos de tipo documentario, tales como SharePoint, para los sitios remotos. La lógica de funcionamiento se parece bastante a la de los Proxy de Internet. Es decir, durante la primera recuperación de un documento (archivo o ejecutable), éste pasa una única vez por el enlace lento. Para los demás clientes de este documento, sobre este sitio, tras realizar una verificación de los permisos y de la no modificación del documento, se transmite directamente desde el equipo presente en el sitio que dispone de una copia. El ahorro se realiza no únicamente en el ancho de banda del enlace, sino también en el tiempo de acceso a los documentos y aplicaciones remotos que puede resultar muy similar al de un acceso local. Esta opción también está disponible a partir de Windows 7 bajo la forma de una caché repartida entre las distintas máquinas. A partir de sistemas cliente Windows 7 y servidores 2008 R2, es posible utilizar la tecnología BranchCache. Para ello, basta con activar la directiva de Windows correspondiente.
Preste atención, en aquellos servidores de archivos donde quiera activar los recursos compartidos y utilizar BranchCache, debe agregar un servicio de rol en el rol Servicios de archivos y almacenamiento.
1. Instalación de BranchCache La primera etapa consiste en instalar la funcionalidad sobre cada servidor que comparte recursos. No obstante, todas las operaciones pueden realizarse a partir de una única máquina que posea el administrador del servidor 2012 instalado. El asistente que permite agregar roles y características puede ejecutarse desde distintos niveles del administrador del servidor. La opción más rápida es, a menudo, el botón Administrar del menú principal.
La instalación de todos los roles y funcionalidades se realiza con una única selección.
Seleccione el servidor que desea configurar. Preste atención, por defecto, sólo aparece el servidor local. Los demás servidores deben agregarse previamente. La administración remota debe estar autorizada a nivel de firewall.
Cada servidor accesible por los clientes que utiliza la función de BranchCache debe habilitar este modo. Esta opción permite habilitar la caché sobre los archivos compartidos de este servidor.
Seleccione la opción BranchCache para archivos de red. El servidor está, ahora, activo como cliente y servidor de BranchCache para los sitios Web y cliente, únicamente, para los servidores de recursos compartidos de archivos.
Seleccione BranchCache. El servidor está, ahora, activo como servidor de BranchCache para los archivos. El servicio BITS (Servicio de transferencia inteligente en segundo plano) debe estar iniciado si quiere utilizar BranchCache sobre los sitios Web de este servidor. Confirme la selección.
Tras la instalación, se inicia el servicio BranchCache, habitualmente sin necesidad de reiniciar el servidor.
A continuación, debe activar una directiva de grupo que permita, al servidor, utilizar las funcionalidades de decodificación de tipo "Hash coding". Esta funcionalidad permite identificar cada documento de forma única y detectar sus modificaciones basándose en el hash único para cada archivo. Esta opción autoriza la activación de BranchCache sobre todos los recursos compartidos. No olvide forzar la aplicación de la directiva. La gestión de las directivas de grupo se accede desde el menú Herramientas de un controlador de dominio.
La configuración del servicio BranchCache se aplica sobre la directiva Equipo, en Directivas - Plantillas administrativas - Red - BranchCache.
2. Configuración de los recursos compartidos Sobre cada recurso compartido, la opción de caché puede accederse mediante el botón Configuración sin conexión.
La configuración de los recursos compartidos puede realizarse desde la consola Administración de equipos - Carpetas compartidas - Administrar recursos compartidos y almacenamiento o, simplemente, desde la propia carpeta, mediante la pestaña Recursos compartidos - Uso compartido avanzado y, a continuación, el botón Caché. Seleccione la opción Habilitar BranchCache.
Preste atención, a diferencia del modo sin conexión clásico, los documentos o programas ejecutables sólo estarán disponibles si el recurso compartido y el documento remoto están, efectivamente, accesibles. En efecto, antes de enviar el documento al usuario desde la caché, es necesario verificar que el archivo no se ha modificado y que los permisos siguen autorizando al usuario acceder al mismo.
3. Configuración de los clientes El servicio BranchCache viene instalado, por defecto, en los clientes Windows 7 y 8, aunque deberá iniciarlo para que la directiva de grupo sea eficaz. Ejecute la herramienta de Administración de directivas de grupo desde el Administrador del servidor. Cree una nueva directiva específica en el contenedor Objetos de directiva de grupo. Puede asociar, más adelante, la directiva a la unidad organizativa que contiene los equipos seleccionados. He aquí la directiva de grupo que debe definir para configurar los clientes:
•
El parámetro Activar BranchCache permite habilitar el uso de la caché, aunque no se produce el arranque del servicio BranchCache, que se configura para arrancar automáticamente sobre los equipos. Su activación se realiza mediante la directiva, y se proponen dos modos:
•
El modo distribuido, que se utiliza cuando no hay ningún servidor disponible en el sitio. En este modo, todas las estaciones del sitio activadas por el BranchCache comparten la caché y verifican, de manera local, la presencia del documento buscado en una de las cachés antes de ir a buscar el archivo original en el sitio central.
•
El modo hospedado, a menudo recomendable cuando existe un servidor Windows 2008 R2 o superior en el sitio remoto. En este modo, todas las estaciones del sitio activadas por el BranchCache utilizan el servidor para verificar la presencia del documento y alojarlo en la caché si es necesario.
•
La activación del modo BranchCache para archivos de red permite indicar el retardo a partir del cual se decide, efectivamente, poner en caché el archivo afectado.
El valor 0 hace que se alojen en caché todos los archivos. •
El parámetro Establecer el porcentaje de espacio en disco usado por la memoria caché del equipo cliente define el porcentaje de espacio en disco autorizado para la caché sobre las estaciones o los servidores definidos para el almacenamiento de los archivos.
El valor por defecto es un 5 %. Esta lógica significa que se preparará una directiva específica para cada sitio remoto que contenga bien un servidor, o bien una caché repartida entre las distintas estaciones. Observe que el arranque automático del servicio puede incluirse en la misma directiva. A partir del cliente Windows 8, se incluyen algunas novedades: •
La activación de detección automática de la caché hospedada permite, al cliente, buscar directamente el servidor hospedado correspondiente con el sitio de conexión, lo que evita una configuración por sitio.
•
El parámetro Establecer el vencimiento de los segmentos de la memoria caché de datos define el periodo de tiempo durante el que se conservan los elementos considerados como válidos. La duración por defecto es de 28 días.
•
El parámetro Configurar compatibilidad con versiones de clientes de BranchCache permite, a los clientes Windows 8, ser compatibles con las versiones anteriores de BranchCache. Si esta opción no se utiliza, cada máquina utiliza su propia versión y su propio formato, lo cual puede provocar incompatibilidades con los datos hospedados en la caché por una versión diferente.
En definitiva, Microsoft refuerza la optimización de los sitios remotos, buscando, siempre, mejorar el acceso remoto. En efecto, este tipo de funcionalidad permite considerar una centralización mucho más importante de recursos y archivos compartidos, limitando el número de servidores necesarios para mantener el conjunto y facilitar la administración y la copia de seguridad del conjunto de información.
Las carpetas de trabajo 1. Presentación Se trata de un nuevo rol de servicio que depende del servicio de archivos y de almacenamiento. El objetivo es permitir la sincronización de archivos profesionales entre varios PC o dispositivos que pertenezcan al mismo usuario, pertenezcan o no a la empresa. Los archivos los gestiona la empresa, que mantiene el control de la información definiendo el marco de uso mediante directivas de encriptación y de contraseña.
De momento, sólo Windows 8.1 (versiones normal y RT) pueden utilizar esta funcionalidad (el módulo no existe en el servidor y, por tanto, no es compatible con Windows Server 2012 R2). Existe una aplicación, Work Folders client for Devices, pero no se ha proporcionado una fecha para su publicación en el momento de escribir estas líneas. Las carpetas de trabajo se ubican en una carpeta del servidor llamada Recurso compartido de sincronización. La carpeta seleccionada puede contener documentos del usuario que estarán disponibles, inmediatamente, para el usuario sin tener que realizar ninguna migración. La administración se lleva a cabo desde la interfaz del Administrador del servidor o mediante comandos PowerShell. He aquí la lista de comandos que puede es posible utilizar: Comando PowerShell
Descripción
Enable-SyncShare
Activar un recurso compartido de sincronización
Disable-SyncShare
Desactivar un recurso compartido de sincronización
GetSyncServerSetting
Obtener la configuración de un recurso compartido de sincronización.
Get-SyncShare
Obtener la lista de recursos compartidos
Get-SyncUserSetting Recuperar la configuración del usuario desde el servidor de sincronización. Get-SyncUserStatus Recuperar el estado del usuario desde el servidor de sincronización. New-SyncShare
Crear un recurso compartido de sincronización.
Remove-SyncShare
Eliminar un recurso compartido de sincronización.
Repair-SyncShare
Reinicializar los metadatos de un usuario de recurso compartido de sincronización.
SetSyncServerSetting
Modificar la configuración de un servidor de recursos compartidos de sincronización.
2. Requisitos previos En la red interna, he aquí los requisitos previos mínimos: • •
Un servidor Windows Server 2012 R2 Un volumen con formato NTFS
Para acceder desde Internet:
• •
Se recomienda utilizar un certificado en el servidor (el acceso mediante http es posible, aunque debe evitarse en producción). El servidor debe estar accesible mediante HTTPS (y/o http) desde Internet, a través de una publicación de tipo ReverseProxy o Gateway.
De manera opcional, si los controladores de dominio no funcionan con Windows Server 2012 R2: •
Una extensión del esquema para agregar un atributo que contenga el servidor de sincronización. Si esta extensión no se lleva a cabo, el usuario debe conocer e informar la URL de acceso cuando se configure la configuración del cliente.
•
Una infraestructura AD FS, si se utiliza autenticación AD FS (consulte el capítulo Acceso remoto - sección Rol Web Application Proxy).
En los equipos cliente: • •
Una versión de Windows adaptada (de momento Windows 8.1 o 8.1 RT). El espacio suficiente en el disco local NTFS.
Por defecto, la carpeta %USERPROFILE%\Work Folders contiene los datos sincronizados. Pero es posible seleccionar otra ubicación, en un dispositivo USB o MicroSD, por ejemplo. El tamaño máximo de los archivos es de 10 GB. Es posible definir cuotas mediante el FileServerResourceManager.
3. Instalación en el servidor La instalación mediante PowerShell es relativamente sencilla: Add-WindowsFeature FS-SyncShareService
Con una única instrucción es posible implementar este nuevo tipo de recurso compartido. New-SyncShare SyncDataUsuarios -path E:\ USERS -User MiEmpresa\MiUsuario -RequireEncryption $true -RequirePasswordAutoLock $true
Las distintas opciones de configuración se detallan en la configuración mediante el asistente gráfico. En concreto, encontraremos: • •
El uso de una subcarpeta determinada que podemos indicar, en caso contrario se incluirán todas las carpetas. El uso del nombre de login (NetBIOS) o el nombre único, llamado UPN.
Desde el asistente para agregar roles y características es preciso seleccionar el rol Servicios de archivos y almacenamiento y, a continuación, Servicios de iSCSI y archivo. Es probable que el servidor seleccionado ya tenga estos elementos instalados. Seleccione, a continuación, el rol de servicio Carpetas de trabajo entre los componentes propuestos.
Valide para agregar la funcionalidad Núcleo de web hospedable IIS.
Esta funcionalidad habilita y utiliza, automáticamente, los puertos 80 (HTTP) y 443 (HTTPS). Tras validar la funcionalidad:
Observe que los demás componentes de IIS no son indispensables para el buen funcionamiento. Las carpetas de trabajo están, ahora, instaladas.
La configuración se encuentra, naturalmente, en la sección Servicios de archivos y almacenamiento del servidor local.
Haga clic en el vínculo Para crear un recurso compartido de sincronización para Carpetas de trabajo….
Para simplificar seleccione, preferentemente, una carpeta nueva y específica para este uso. Cada usuario tendrá su carpeta personal en la carpeta indicada; la solución aquí diseñada es útil únicamente para carpetas personales y, en ningún caso, para carpetas comunes. La carpeta se crea si no existe.
Indique la nomenclatura utilizada para las carpetas, así como la carpeta que se desea sincronizar, si no queremos sincronizar el total de carpetas presentes en la ubicación indicada.
Por ejemplo, si utilizamos la carpeta E:\USERS, esta carpeta se comparte para recibir todas las carpetas personales bajo la forma \\servidor\USERS\%username%, mientras que puede ser preferible limitar la replicación de la carpeta de trabajo únicamente a una subcarpeta concreta, nueva o existente.
Indique el nombre del recurso compartido de sincronización y su descripción.
Agregue los usuarios o, mejor, los grupos autorizados que deben poder utilizar este recurso compartido de sincronización.
A menudo es preferible deshabilitar la herencia de las autorizaciones a este nivel para evitar cualquier riesgo de conflicto con permisos no deseados (la opción correspondiente está marcada por defecto). Esto es, sobre todo, importante si la carpeta seleccionada o una carpeta superior están compartidas y se han definido permisos sobre las carpetas superiores. Indique la seguridad seleccionada para los datos.
Esta directiva debe aceptarla el usuario antes del primer uso de los grupos de trabajo, incluidos ordenadores y dispositivos que no forman parte de la empresa (o del dominio) y sobre los que el usuario desea realizar la sincronización. Valide el conjunto de opciones configuradas.
La representación del resultado final:
El acceso a las carpetas se vuelve lo más seguro posible. Por defecto, sólo el acceso mediante el protocolo encriptado HTTPS está habilitado en el equipo cliente. Esto significa que es preciso disponer de un certificado en el servidor. Si el servidor recibe automáticamente un certificado emitido por una entidad emisora interna, las carpetas de trabajo pueden utilizarse automáticamente. A modo de prueba, es posible deshabilitar la obligación de usar HTTPS en el equipo cliente ejecutando el siguiente comando en el equipo cliente: Reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WorkFolders /v AllowUnsecureConnection /t REG_DWORD /d 1
Mejor que deshabilitar el uso de HTTPS, una solución más elegante consiste en generar un certificado que contenga los nombres internos y externos, para permitir a los clientes acceder a las carpetas de trabajo de forma segura tanto desde la red local (mediante la URL WorkFolders.MiEmpresa.Priv) como desde una red externa (WorkFolders.MiEmpresa.Es), que es el objetivo principal de esta funcionalidad. El siguiente comando permite generar un certificado autofirmado con este fin. Sepa que es, también, posible comprar un certificado emitido por un proveedor público si no dispone de
una PKI en su empresa o el despliegue de certificados autofirmados le resulta demasiado complejo. New-SelfSignedCertificate -DnsName "WorkFolders.MiEmpresa.Priv","SrvFic01.MiEmpresa.Priv", "WorkFolders.MiEmpresa.Es" -CertStoreLocation cert:Localmachine\My
Tras crear el certificado, debe agregarlo en las entidades raíz del servidor, y en los distintos clientes. El nombre DNS WorkFolders permite automatizar y facilitar la búsqueda, disponiendo de una forma para descubrir automáticamente la configuración, a partir de la dirección de mensajería indicada por el usuario una vez se establece la conexión. Se recomienda crear una entrada de tipo CNAME (alias) para este nombre en la zona DNS interna, y hacerla apuntar al registro A (Host) correspondiente al servidor de archivos. Para habilitar el uso del certificado que acaba de instalar, es preciso afectar al proceso IIS Core mediante el siguiente comando que puede ejecutar desde una ventana de comandos CMD. netsh http add sslcert ipport=0.0.0.0:443 certhash= appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=MY
El número de firma (thumbprint) que debe indicar en el comando puede obtenerse mediante el siguiente comando PowerShell: dir cert:\localmachine\my Thumbprint ---------EFEE6E02A04A2C1D18AF2B70B49103DF2E191ABC
Subject ------CN=WorkFolders.MiEmpresa.Priv
Para completar esta sección sobre la configuración, es posible modificar el esquema Active Directory para agregar un campo suplementario que permita administrar la URL de acceso a las carpetas de trabajo. Este campo puede resultar interesante si varias carpetas de trabajo se definen en distintos servidores para asociar al usuario a una carpeta de trabajo concreta. Esta extensión se agrega, por lo general, en el esquema tras su actualización, antes de promover el primer controlador de dominio 2012 R2. El siguiente enlace indica los elementos necesarios para administrar esta extensión sin tener que preparar el dominio para Windows Server 2012 R2: http://blogs.technet.com/b/filecab/archive/2013/10/09/a-new-user-attribute-for-workfolders-server-url.aspx Por otro lado, la gestión de la directiva de 2012 R2 permite modificar esta URL para el usuario.
El parámetro Especificar configuración de carpetas de trabajo se encuentra en Usuarios - Directivas - Plantillas administrativas - Componentes de Windows - Carpetas de trabajo. Permite habilitar las carpetas de trabajo, indicar la dirección URL que debe utilizar, y forzar la configuración automática.
4. Configuración en el puesto cliente El módulo Carpetas de trabajo está integrado en Windows 8.1. Basta con configurarlo desde el panel de control. Acceda al Panel de control y seleccione Carpetas de trabajo.
Haga clic en Configurar carpetas de trabajo.
Indique su sufijo UPN (tiene el formato de una cuenta de correo electrónico).
La URL se configura automáticamente si los equipos están integrados en el directorio o si la configuración automática está basada en el nombre WorkFolders. Si la configuración automática no funciona, o si desea utilizar un servidor de sincronización diferente, la opción Indicar una URL de Carpetas de trabajo sirve para definir una dirección de sitio web diferente. En el caso de una estación integrada en AD, se utiliza la autenticación integrada. Si todo funciona bien, la configuración continúa con la configuración de la ubicación de los datos.
Acepte la directiva de empresa.
Este concepto es importante en términos de permisos de datos, incluso para equipos integrados en el dominio. La configuración de las carpetas de trabajo finaliza.
Es posible, a continuación, administrar la configuración de las carpetas de trabajo desde el Panel de control.
Con el uso, es posible modificar ciertos parámetros de sincronización en el servidor y en el puesto cliente.
Por defecto, las modificaciones locales sobre los dispositivos tienen preferencia e inician la sincronización. Si las modificaciones provienen del servidor (o de la sincronización de otro dispositivo), tardarán más en tenerse en cuenta. Es, por tanto, posible configurar el intervalo entre dos verificaciones de sincronización. Por defecto, el intervalo de verificación es de 5 minutos. El valor mínimo es de 1 minuto, aunque si se disminuye este valor, no hay que olvidar tener en cuenta la potencia de CPU y el disco necesarios para realizar esta operación, que depende de la cantidad de archivos a examinar. He aquí la sentencia PowerShell que permite configurar este parámetro a tres minutos. set-SyncServerSetting -MinimumChangeDetectionMins 3
Conclusión ¡Se han aportado numerosas mejoras relativas a DFS! Por ejemplo, el hecho de disponer de comandos PowerShell para configurar la replicación DFS permite utilizar Remote PowerShell desde una máquina donde el componente no se encuentre instalado. La existencia de un proveedor WMI para la replicación mejora las nuevas herramientas de gestión destinadas a controlar la replicación. Una base de DFSR corrupta puede reconstruirse sin riesgo de pérdida de enlaces ligados a una sincronización inicial no autoritativa. Ya no se corre el riesgo de perder, arbitrariamente, los archivos en conflicto. Antes, en caso de producirse un error en la base tras una sincronización inicial, la replicación reiniciaba completamente desde el origen, sin tener en cuenta archivos más recientes que podrían encontrarse. El cross-file RDC se encuentra, ahora, deshabilitado. Por defecto, la replicación puede utilizar hasta cinco orígenes de un mismo archivo para generar un nuevo archivo sobre un nuevo destino. Se obtiene, también, un ahorro en tiempo y en ancho de banda en redes lentas o de tipo medio. En cambio, según la configuración de la red, si las redes son rápidas, es posible que afecte al rendimiento y al tiempo que se pasa de manera local a procesar la información cuando se tratan conjuntos importantes de archivos con muchas similitudes. ¡Los comandos SET-DFSRConnection y ADD-DFSRConnection soportan, ahora, la opción -DisableCrossFileRdc! El file staging tuning permite definir el tamaño mínimo a partir del cual se comprime un archivo y se replica por partes, pasando por la etapa llamada Staging. El resultado es que, por defecto, los archivos de menos de 64 KB no pasan por esta etapa de staging y no se comprimen. Windows Server 2012 R2 permite indicar el tamaño mínimo (entre 256 Kb y 512 TB) antes de que un archivo se procese y comprima. Los rendimientos se ven, de este modo, mejorados en detrimento de un ancho de banda algo más exigente.
Existen dos nuevos comandos PowerShell que facilitan la recuperación de los archivos en conflicto (ConflictAndDeleted) y carpetas preexistentes (PreExisting): GetDFSRPreservedFiles muestra los datos correspondientes y Restore-DFSRPreservedFiles los recupera bien en su carpeta de origen, o bien en un nuevo destino Tras un corte de corriente o un fallo inesperado, la base de datos de DFSR se repara y, a continuación, se reactivan automáticamente las replicaciones una vez preparada la base de datos. En caso de deshabilitar un miembro de la replicación DFSR, los datos presentes, incluidas las carpetas ConflictAndDeleted y PreExisting, no se eliminan. Esto representa muchas pequeñas mejoras que, de manera global, aportan una fiabilidad mucho mayor a los datos gestionados mediante DFS.
Introducción Este capítulo está dedicado a la alta disponibilidad. Su objetivo es describir las posibles ofertas en términos de alta disponibilidad con Windows Server 2012 R2. Aumentar la disponibilidad de los servicios que se ofrecen es un reto permanente en cualquier departamento informático. Existen una serie de factores que favorecen esto: • • • • • • •
Homogeneizar los servidores que se basan en una instalación y una configuración idénticas (véase el capítulo Despliegue de servidores y puestos de trabajo). Centralizar la configuración por GPO (consulte el capítulo Dominio Active Directory). Salvaguardar y mantener actualizados los servidores (consulte el capítulo El ciclo de vida de su infraestructura). Replicar los archivos ofimáticos (consulte el capítulo Arquitectura distribuida de acceso a los recursos). Duplicar los servicios de infraestructura de red (controladores de dominio, servidores DNS, DHCP...). Utilizar la versión Core de Windows Server 2012 R2 para limitar los tiempos de indisponibilidad debidos a instalaciones o actualizaciones de seguridad. Virtualizar el servicio y hospedar la máquina virtual en un clúster Hyper-V.
Una vez llevadas a cabo todas estas acciones, algunos servicios críticos siguen dependiendo de un servidor único que, tarde o temprano, fallará o será necesario reiniciar tras haber instalado algún parche o correctivo. Es aquí donde entra en juego la alta disponibilidad, que permite convertir un servicio necesariamente disponible en un servicio altamente disponible. Es un buen complemento de los factores anteriores.
Los servidores que participan de la alta disponibilidad se designan como nodos de un clúster, y éste define al conjunto de servidores. El clúster se prevé para dar respuesta a fuertes necesidades de disponibilidad y no debe considerarse a la ligera. Antes de decidir si una solución de tipo clúster responde a esta necesidad, es necesario plantearse ciertas preguntas: • • • • • •
¿Cuál es la tasa de disponibilidad de la solución actual? ¿Cuál es la tasa de disponibilidad deseada/solicitada? ¿Cuánto cuesta la pérdida de la disponibilidad actual? En caso de fallo, ¿cuánto tiempo hace falta para restaurar el servidor? ¿Está la solución que presta el servicio preparada para funcionar en modo clúster? ¿Un solo servidor es capaz de aportar todos los recursos de hardware necesarios o es necesario disponer de varios servidores activos al mismo tiempo?
Elecciones de arquitectura 1. Las distintas arquitecturas Tras los términos de alta disponibilidad se esconden dos tipos de soluciones distintas: • •
Soluciones de tipo activo/pasivo. Soluciones de tipo activo/activo.
La primera solución aumenta la disponibilidad del servicio haciendo bascular los recursos de un servidor a otro en caso de existir algún problema (solución altamente disponible). La segunda solución permite tener varios servidores que responden a las solicitudes al mismo tiempo (reparto de carga) y que pueden tolerar la pérdida de algún miembro (solución altamente disponible). Las soluciones de tipo activo/activo pueden parecer, a primera vista, más interesantes, aunque son, generalmente, mucho más complejas y deben considerarse para dar respuesta a un problema concreto de reparto de carga. En un entorno Microsoft, las soluciones son las siguientes: • •
Solución activo/pasivo: clúster de conmutación por error (MSCS - Microsoft Cluster Service). Solución activo/activo: clúster de reparto de carga de red (NLB, Network Load Balancing).
Una aplicación destinada a los usuarios debe ser compatible con una solución de alta disponibilidad. Dejando a parte los "grandes" desarrolladores de software, es habitual que un proveedor de aplicaciones no haya probado, jamás, su aplicación en un entorno de alta disponibilidad y que no pueda, por tanto, asegurar su funcionamiento. Como mínimo, cabe analizar los siguientes puntos :
• • •
• •
¿Puede residir el conjunto de datos en volúmenes compartidos y, por tanto, diferentes a las unidades locales C:, D...? ¿Deben replicarse algunas claves de registro entre ambos servidores? ¿La aplicación utiliza algún dispositivo de protección física (dongle instalado en un puerto USB o paralelo, por ejemplo) o se requiere una conexión física que no se puede duplicar ni conectarse sobre dos servidores? ¿Los clientes pueden utilizar un nombre NetBIOS/DNS y una dirección IP distintos del de la máquina física (nombre/IP virtuales)? ¿Cuáles son los mecanismos para detectar un fallo en la aplicación y decidir bascular al otro nodo?
Caso 1: solución activo/pasivo Un único servidor hospeda un mismo recurso en un momento determinado. No existe ninguna necesidad de sincronizar los datos de aplicación con los demás servidores (hasta 64, como máximo). Si se produce un fallo, otro servidor inicia la aplicación, que tendrá acceso a los mismos volúmenes de disco que el servidor anterior, debiendo gestionar la interrupción brusca del servicio (registros de transacciones, en el caso de una base de datos, por ejemplo). El almacenamiento puede suponer un punto de fallo único en ciertos casos. El almacenamiento corporativo (SAN, etc.) es caro, y generalmente se comparte entre varias aplicaciones y plataformas. En contrapartida, todos los elementos se duplican, especialmente los controladores. Si bien se tiene especial precaución en que nunca se produzca un fallo, sigue siendo posible. Otro problema es la corrupción de algún volumen (LUN) que hospede datos. Si fuera preciso realizar una verificación de la partición (chkdsk), cabría considerar la indisponibilidad durante la duración de la misma (que depende del número de archivos y no del tamaño del volumen). Caso 2: solución activo/activo N servidores (hasta 32, como máximo) responden a las solicitudes simultáneamente. Los servidores deben poder responder a todas las consultas y, por tanto, tener acceso al conjunto de datos que permiten elaborar las respuestas. Su uso más extendido son las granjas de servidores Web. Todos los servidores tienen una copia del sitio Web y los datos se almacenan en una base de datos que se hospeda fuera de la granja. La complejidad aparece en la gestión de la sesión del usuario. El usuario puede tener un carrito de la compra (en un sitio comercial) y/o estar autentificado en el sitio. Si el servidor que ha respondido a sus consultas dejara de funcionar, otro servidor debería ser capaz de poder tomar el relevo, preferentemente sin reenviar al usuario a su página de inicio. La sesión del usuario debe, por tanto, conservarse de forma externa al servidor, por ejemplo utilizando una base de datos. Esto implica que el sitio web tiene que haber previsto este tipo de arquitectura y almacenar la sesión de forma externa al servidor. Sobre un sitio comercial muy frecuentado, esta gestión de la sesión tiene un impacto enorme en el consumo de recursos. Es posible utilizar un clúster de tipo NLB en modo activo/pasivo, aunque este modo de funcionamiento supone un uso atípico respecto a la filosofía del producto.
He aquí una tabla que resume las principales diferencias entre ambas soluciones: Ventajas Clúster de conmutación por error
No se produce ninguna sincronización entre los servidores.
Inconvenientes Almacenamiento externo mutualizado.
Un único servidor debe ser capaz Es consciente del estado de de gestionar la carga (activo/pasivo la aplicación (funciona o por grupo de recursos). no) y de los recursos (saturados o no). Clúster NLB
Reparto de carga (activo/pasivo). Sin almacenamiento mutualizado.
Trabaja únicamente a nivel IP. No es consciente del estado de la aplicación.
Observe que estas dos tecnologías no pueden estar soportadas en el mismo servidor, véase el artículo 235305 (Interoperability between MSCS and NLB) de la base de conocimiento Microsoft.
2. Alta disponibilidad, ¿la panacea de su infraestructura? Las promesas de la alta disponibilidad sólo podrán materializarse si los equipos y los procedimientos son coherentes con la necesidad a la que responden estas promesas. Si bien el coste de la solución es elevado, sólo se verá amortizado si permite, efectivamente, evitar interrupciones en el servicio. El coste de la solución implica, como mínimo, los elementos siguientes: • • • • • • • •
Inversiones en material (dos servidores, en lugar de uno, por ejemplo). Volumen de espacio, consumo eléctrico y de climatización suplementario. El coste de "mantenimiento y gestión de infraestructura" (dos licencias de Windows Server, los agentes de copia de seguridad...). Licencias de las aplicaciones, algunos fabricantes obligan a pagar dos veces el precio de la licencia de la aplicación, incluso cuando se realiza un uso activo/pasivo. La supervisión y la copia de seguridad se vuelven tareas más complejas. Necesidad de tener un almacenamiento compartido cuando se podría haber trabajado con discos internos. Coste de personal para formarse en esta tecnología. Coste de personal para mantener operativa toda la solución.
Estos costes se producen por entorno y deben reportarse en cada entorno impactado (preproducción, certificación...). El coste de una indisponibilidad debe, por tanto, ser superior a todos estos costes.
El riesgo consiste en considerar un clúster como un servidor clásico "mejorado". Este enfoque es, a menudo, fatal en las versiones anteriores de Windows. Bastaba con que un administrador borrara un recurso compartido de archivos desde el explorador en lugar de hacerlo desde la consola de administración del clúster para hacer fallar este recurso de clúster y provocar, por defecto, una conmutación por error del mismo. Microsoft ha revisado a conciencia la integración de la capa de clúster en el sistema operativo. Este mismo error en Windows Server 2012 R2 se gestiona, y el sistema elimina de hecho el recurso de clúster directamente sin provocar una incidencia. Esto provoca una importante disminución de los incidentes provocados por errores humanos debidos a un mal conocimiento de las especificaciones de esta solución. La política de los fabricantes en lo relativo a las licencias evoluciona, aunque sigue existiendo cierto desfase. Por ejemplo, ya no es necesario adquirir la versión Enterprise de Microsoft SQL Server para implementar un clúster, desde la versión 2005. En cambio, el mismo producto sigue requiriendo una licencia Enterprise para formar un clúster NLB de servidores SSRS (SQL Server Reporting Services). Un clúster NLB presenta, también, problemas que no deben ignorarse. Se trata de un administrador de la carga de red de nivel 3 (IP), que no tiene, por tanto, consciencia del estado de las aplicaciones para las que reparte la carga. Si se trata de aplicaciones web, por ejemplo, la parada de un IIS en uno de los servidores no lo sacará del clúster. Tendrá una parte de los usuarios que no podrá acceder al sitio Web, en particular si está habilitada la afinidad. Esto le obliga a implementar un mecanismo de verificación de la aplicación, para sacar de la granja a un nodo con error. El único caso gestionado por un clúster NLB es un problema de nivel 3 o inferior. Por ejemplo, si el servidor pierde el acceso a la red, se sacará automáticamente de la granja y los usuarios se repartirán sobre los nodos restantes (convergencia). Una excepción la constituye, por ejemplo, Microsoft Forefront TMG, que controla el clúster NLB y sale del clúster si encuentra algún problema. La tecnología NLB proporciona varias soluciones para crear una dirección IP virtual, aunque todas presentan ventajas e inconvenientes. Algunos fabricantes de red (Cisco, Enterasys...) requieren una configuración especial para poder funcionar. Un clúster NLB está formado, a menudo, por dos servidores, con un máximo de 32 servidores. A diferencia del modo activo/pasivo, podemos encontrar una situación en la que uno de los nodos no pueda gestionar, por sí mismo, toda la carga. La alta disponibilidad no está, por tanto, asegurada, pues la pérdida de un nodo genera una interrupción del servicio o una degradación en el rendimiento. Es preciso, por tanto, prestar atención a la carga que debe absorber la granja para tolerar la pérdida de un nodo. Este fenómeno también puede darse en un clúster de conmutación por error, si los dos nodos trabajan en modo activo sobre recursos diferentes (activo/activo en modo cruzado). Microsoft no recomienda utilizar esta configuración, y propone, en su lugar, utilizar un clúster de tres nodos en este caso (activo/activo/pasivo). El nodo pasivo se encuentra mutualizado con los otros dos nodos activos.
Reparto de carga (clúster NLB)
El reparto de carga resulta indispensable cuando no basta con un único servidor para gestionar toda la carga de la aplicación o mantener unos tiempos de respuesta aceptables. Si no existen requisitos suplementarios de disponibilidad, se recomienda agregar, en primer lugar, recursos hardware al primer servidor antes de considerar una solución con varios servidores. El reparto de carga no supone una capacidad de carga lineal. Si un servidor es capaz de dar servicios a 200 usuarios, dos servidores no tienen por qué, necesariamente, ser capaces de dar servicio a 400 usuarios. Todo va a depender de la naturaleza de la carga y del comportamiento de las sesiones TCP generadas. La noción de afinidad permite conservar a un usuario sobre el mismo nodo mientras dure su interacción. De este modo, se disminuyen los cambios de sesión de usuario sobre los servidores. Para ello, la granja calcula un hash a partir de la dirección IP del cliente y su destino. Si todos los clientes se presentan con la misma dirección IP (por ejemplo, cuando se ubican tras un firewall con reglas NAT), serán redirigidos hacia el mismo servidor, anulando, de este modo, el reparto de carga. El reparto no se realiza en función de la carga de los servidores. Si algunos usuarios saturan uno de los nodos, seguirá recibiendo el mismo número de usuarios que los demás nodos. Si la carga entre los nodos no es del todo uniforme, deberá desarrollar una rutina encargada de drenar los nodos a partir de cierta carga.
1. Requisitos previos de una solución NLB Si bien la instalación de la funcionalidad de reparto de carga de red es sencilla, conviene respetar ciertos requisitos previos para obtener el mejor rendimiento posible. La primera etapa consiste en instalar las últimas actualizaciones del sistema operativo. En efecto, sería una pena hacerlo justo una vez puesto en producción el clúster... si bien no debería producirse ninguna parada del servicio en este caso. Los servidores que participan del clúster no deben ser controladores de dominio. No obstante, es necesario que sean miembros del mismo dominio Active Directory y que estén en la misma subred. Desde un punto de vista de hardware, el servidor, así como sus componentes, deben disponer del logotipo Certificado para Windows Server 2012 R2 o, como mínimo, Certificado para Windows Server 2012 para garantizar su estabilidad (y el soporte por parte de Microsoft en caso de producirse cualquier problema). Incluso si basta con una interfaz de red por nodo, se recomienda encarecidamente utilizar, como mínimo, dos interfaces de red: la primera para el host como máquina única, y la segunda para el tráfico del clúster. Si una de las interfaces de red se dedica al tráfico del clúster, ésta debe tener una dirección IP fija. Además, el registro automático DNS de esta interfaz debe estar deshabilitado, así como NetBIOS sobre TCP/IP. Todas las interfaces de red que forman parte del clúster, sea cual sea el nodo, deben tener una configuración idéntica desde un punto de vista de los parámetros (control de flujo, modo dúplex y tipo de medio). Para terminar, es posible utilizar tarjetas de red configuradas en teaming.
Para realizar la instalación, deben utilizar una cuenta que posea permisos de administrador local. Necesitará, también, el nombre completo del clúster así como su futura dirección IP.
2. Crear una granja NLB La creación de una granja NLB es, técnicamente, una tarea rápida. Es preciso, no obstante, verificar ciertos puntos previamente: •
El modo de operación del clúster:
• • •
Monodifusión (misma dirección MAC en todos los nodos). Multidifusión (dirección MAC única por nodo). Multidifusión IGMP (dirección MAC única por nodo e inscripción de la dirección IGMP).
•
El modo de filtrado:
• • •
Host múltiple (reparto de carga). Host único (activo/pasivo). Ninguno (bloquear el tráfico correspondiente a la regla).
•
El modo de afinidad (host múltiple únicamente):
• • •
Ninguno (envío sobre un nodo aleatorio). Único (mantenerse sobre el mismo nodo por dirección IP cliente). Red (mantenerse sobre el mismo nodo por subred completa).
Elección del modo de operación del clúster La elección del modo de operación debe realizarse de forma coordinada con los responsables de la red: •
El modo monodifusión asigna la misma dirección MAC sobre todos los nodos del clúster. Esto va en contra del funcionamiento de los switches, que memorizan las direcciones MAC por puerto, y para los que es imposible registrar dos veces la misma dirección MAC. NLB mitiga este punto activando la clave "MaskSourceMAC". El paquete llega con una dirección MAC de destino correspondiente a la del clúster, aunque el nodo responde con la suya propia. El switch no puede, en este caso, asignar la dirección MAC al nodo que responde y sigue enviando los paquetes a toda la red (inundación). Este comportamiento es "por diseño". Si el modo es obligatorio (lo era con Microsoft ISA Server, en un principio), existen varias alternativas. Es posible situar un hub entre los servidores del clúster y el switch. De esta forma, el switch ve la dirección MAC del clúster desde un solo puerto (sin "MaskSourceMac"), lo cual evita la inundación. Esto no forma parte, no obstante, de las "buenas prácticas". El uso de un conmutador de nivel 3 (router) no es posible, pues todos los nodos comparten la misma dirección IP
•
•
y el router envía los paquetes en función de la dirección IP. Los servidores no pueden comunicarse entre ellos, puesto que tienen la misma dirección MAC. Los paquetes se reenvían al servidor sin salir de la propia tarjeta de red. El modo multidifusión resuelve el problema de la dirección MAC agregando una dirección MAC de tipo multidifusión e impidiendo a los equipos de red memorizar la dirección MAC del clúster. El switch envía los paquetes al conjunto de puertos, entre los que se encuentran los nodos del clúster. Se produce, todavía, una inundación del tráfico sobre todos los puertos de la red. Algunos equipos (Cisco, en particular) requieren convertir parcialmente el switch en un hub por configuración, indicándole que transfiera sistemáticamente los paquetes para la dirección MAC del clúster a los puertos de todos los nodos. Es posible limitar este problema aislando los servidores tras un router, en una VLAN dedicada. El modo multidifusión IGMP se comporta como el anterior, aunque los nodos se registran, también, con una dirección IP IGMP de clase D (de 224.0.0.0 a 239.255.255.255). Esto obliga que los equipos de red soporten la multidifusión IGMP, aunque permite resolver lo más elegantemente posible los distintos problemas. Cada nodo tiene su propia dirección MAC, la dirección IP de multidifusión y sólo los nodos reciben el tráfico de red del clúster.
He aquí algunos artículos que tratan este asunto en función de los fabricantes: •
•
Cisco: http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_e xample09186a0080a07203.shtml Enterasys: http://www.enterasys.com/partners/microsoft/sa-nlb-tb.pdf
Elección del modo de filtrado El modo de filtrado permite definir el modo de funcionamiento del clúster, desde un punto de vista de los flujos de red. Permite definir qué paquete de red (puerto y tipo) debe enrutarse hacia qué nodo(s), o si se bloquea, simplemente. El modo de filtrado más interesante es host múltiple, que es de tipo activo/activo, lo que significa que varios nodos trabajan simultáneamente y, por tanto, se reparten la carga de trabajo y, por tanto, los flujos de red. El modo host único es de tipo activo/pasivo, con el nodo que tiene menor ID activo, donde sólo el nodo activo recibe el flujo de red. El modo de filtrado Ninguno permite bloquear el tráfico sobre ciertos puertos, en particular para proteger los nodos. Elección del modo de afinidad Utilizando un modo de filtrado de host múltiple, existen tres modos de afinidad posibles: •
Ninguno: con cada conexión TCP de un mismo cliente, se le redirigirá hacia el nodo que tenga menos clientes. Este modo asegura el mejor reparto posible, especialmente cuando no hay datos de cliente que deban mantenerse (carrito de la compra, sesión...).
•
•
Único: permite mantener a un cliente (según su dirección IP) sobre el mismo nodo mientras la topología de la granja no se vea modificada (se agregue/elimine un nodo). Cada cliente debe tener una dirección IP única para tener un reparto eficaz (sin NAT, proxy...). Red: se comporta como el filtrado anterior, aunque en vez de utilizar directamente la dirección IP del cliente, calcula la dirección de la red. Si, por ejemplo, un cliente se conecta con la dirección IP 192.168.1.1, NLB la transformará en 192.168.1.0. Todos los clientes que pertenezcan a esta red de clase C bascularán sobre el mismo nodo. Este tipo de filtrado permite mantener a un conjunto de clientes que provengan de una misma red sobre un mismo nodo.
De forma complementaria, en Windows Server 2012 R2 (desde Windows Server 2008 R2 para ser más exactos), la afinidad única puede sobrevivir a un cambio en la topología (convergencia), a diferencia que con las versiones anteriores, donde el cliente era redirigido hacia otro nodo. Si un cliente X se conecta sobre un nodo A y se agrega o elimina un nodo del clúster, el clúster mantendrá la afinidad durante X minutos. Este retardo de expiración, expresado en minutos, comienza desde que el cliente está inactivo. El valor por defecto es: no activo (0 sombreado). Esto significa que la afinidad expira desde que el cliente se desconecta. Si fuera necesario, el clúster puede disponer de varias direcciones IP virtuales. Esto es necesario, en particular, si hospeda varios sitios web con certificados SSL. A menos que tenga un certificado de tipo wildcard (*.MiEmpresa.Priv), cada sitio deberá tener una dirección IP dedicada para las conexiones SSL. A diferencia del protocolo HTTP, que autoriza los host virtuales, el protocolo SSL comienza negociando la seguridad, en primer lugar, y realizando una validación de la URL solicitada por el cliente.
3. Configurar la granja La implementación consiste en: • • •
Instalar la funcionalidad "reparto de carga de red". Crear la granja con un nombre y, al menos, una dirección IP sobre, al menos, un nodo. Configurar las reglas para determinar el tráfico a repartir.
La instalación puede hacerse mediante el Administrador del servidor aunque, también, a través de PowerShell. Windows Server 2012 R2 se instala con la versión 4 de PowerShell, que permite instalar esta funcionalidad sobre varios nodos mediante un único comando: Invoke-Command -ComputerName nodo1,nodo2 -Command {install-WindowsFeature NLB,RSAT-NLB}
La granja NLB puede crearse de dos formas: • •
Con la interfaz clásica NLB. Con PowerShell.
Configuración de la granja con la interfaz gráfica: Haga clic en Inicio - Herramientas de administración - Administrador de equilibrio de carga de red. A continuación, haga clic en Clúster y Nuevo. Seleccione un primer nodo para configurarlo, así como una interfaz (la que recibirá el flujo de red proveniente de los clientes y tenga como destino la dirección IP del clúster). Defina su prioridad, su interfaz de administración y su estado por defecto.. Agregue, a continuación, al menos una dirección IP utilizada por la granja. Determine la dirección IP principal del clúster así como el nombre del clúster. La siguiente etapa es crítica, y consiste en seleccionar el modo de operación del clúster (monodifusión, multidifusión con o sin IGMP). Por defecto, todos los puertos están configurados con reparto de carga, con una afinidad de tipo única. Llegados a este punto, se crea la granja con un único servidor como miembro. Es posible agregar un segundo nodo mediante el menú Clúster - Agregar host:
La interfaz de gestión de las reglas permite seleccionar la dirección IP del clúster donde se aplica, un puerto, o un rango de puertos, su naturaleza (TCP, UDP) y el modo de filtrado:
Configuración de la granja con PowerShell: #Creación del clúster sobre el primer nodo
New-NlbCluster -InterfaceName NLB -ClusterName cluster1.MiEmpresa.Priv -ClusterPrimaryIP 172.16.0.25 -SubnetMask 255.255.0.0 #Agregar un segundo nodo tras la creación del primer nodo Add-NlbClusterNode -Interface NLB -NewNodeName nodo2.MiEmpresa.Priv -NewNodeInterface NLB #O Agregar un segundo nodo tras el segundo nodo Get-NlbCluster -HomeName cluster1.MiEmpresa.Priv | Add-NlbClusterNode -NewNodeName nodo2.MiEmpresa.Priv -NewNodeInterface NLB
Para obtener la lista completa de comandos PowerShell que permiten administrar un clúster NLB (35 en total), ejecute uno de los siguientes comandos PowerShell: Get-Command *-NlbCluster* #O Get-Command -Module NetworkLoadBalancingClusters
4. Ejemplo: granja Web IIS Una granja de servidores Web supone el uso típico de una solución NLB. IIS 8.5 gestiona la noción de configuración compartida, que facilita la gestión de la granja centralizando la configuración IIS de todos los servidores Web sobre un almacén compartido de archivos UNC. El siguiente artículo de la TechNet describe su implementación: http://technet.microsoft.com/en-us/library/jj635853.aspx Las etapas son las siguientes: • • •
Instalar el rol Servidor Web (Web-Server). Crear, al menos, un clúster NLB con dos nodos. Modificar la regla por defecto, para equilibrar únicamente los puertos TCP 80 (HTTP) y 443 (HTTPS).
Llegados a este punto, tendrá una granja formada por dos servidores Web con una afinidad única. Ya sabe que NLB no es consciente del estado de la aplicación para la que realiza el reparto de carga. En cambio, puede modificar el comportamiento de IIS para que tenga en cuenta el clúster NLB y modifique su comportamiento en caso de ocurrir algún problema. Por defecto, IIS reenvía un código HTTP 503 en caso de fallo de algún pool de aplicaciones. En el caso de una granja de servidores, es muy probable que sólo este servidor tenga el problema. Indicando al pool de aplicaciones que realice una respuesta a nivel TCP, va a cerrar la conexión del cliente, que se verá redirigido hacia otro nodo de la granja. Par modificar este comportamiento, vaya a la configuración avanzada del pool de la aplicación:
5. Actualización de una granja NLB La actualización de una granja NLB existente es más sencilla que la creación de una granja. Los principales problemas son, generalmente, la compatibilidad de las aplicaciones y los drivers, como con cualquier actualización sobre cualquier servidor de una infraestructura. Una granja NLB bajo Windows Server 2012 R2 puede trabajar con nodos en alguna versión anterior de Windows Server (Windows Server 2003 R2, como mínimo), y la actualización necesaria es sencilla y no requiere crear ninguna granja nueva. He aquí los posibles métodos de actualización:
•
•
•
Parada total del clúster: la parada total del clúster permite realizar la actualización en todos los nodos al mismo tiempo. Esto supone una parada total de los servicios proporcionados por el clúster. Actualización por turnos (rolling update): se detiene uno de los nodos y se actualiza a Windows Server 2012 R2. A continuación, se realiza la misma operación con otro nodo del clúster. Agregar un nodo nuevo (nuevo hardware): se trata de una opción común puesto que, por lo general, se aprovecha para renovar el hardware. Se agrega, simplemente, un nodo nuevo que ya funciona con Windows Server 2012 R2. A continuación, se elimina el nodo de la generación anterior.
Una vez realizada la actualización, conviene probar el conjunto de nodos así como la tolerancia a fallos.
Clúster de conmutación por error La tecnología de clúster de conmutación por error tiene un enfoque distinto al de NLB. Su objetivo consiste en mantener los recursos en línea de forma permanente e ininterrumpida. Cada recurso se instancia sobre un único servidor a la vez, aunque varios servidores pueden estar activos al mismo tiempo sobre recursos diferentes. Para garantizar un buen funcionamiento, la capa de clúster verifica una serie de puntos: • • • •
¿Funcionan la dirección IP y el nombre virtual? ¿Funciona el acceso al almacenamiento? ¿El nodo es capaz de comunicarse con los demás nodos (no está aislado)? ¿Los servicios que hay que mantener activos son funcionales?
Si se detecta algún incidente sobre alguno de los puntos anteriores, el clúster bascula el conjunto de recursos necesarios para el funcionamiento del (de los) servicio(s) sobre otro nodo. Como mínimo, un clúster posee al menos un grupo (el ”grupo clúster”) que contiene: • • •
Una dirección IP virtual. Un nombre virtual. Potencialmente, un volumen que forma parte de un quórum, o un disco testigo.
En caso de producirse algún problema en la red, el clúster debe determinar qué nodos funcionan correctamente y qué nodos deben retirarse del clúster (y los recursos que los hospedan deben conmutar). Los nodos que sean mayoritarios quedarán en línea. Existen cuatro modos de funcionamiento para determinar este comportamiento: •
Mayoría de nodo: el nodo que se comunica con la mayor parte de nodos resulta ganador. Este modo funciona únicamente con un número impar de nodos.
•
•
•
Mayoría de disco y nodo: cada nodo tiene su propio voto, así como el quórum de disco. El nodo con más votos gana. Windows Server 2012 R2 aporta una modificación en el cálculo de votos (Dynamic withness) para obtener un resultado impar de votos en cualquier situación. Si el resultado del número de votantes (los nodos, por tanto), es impar, entonces el voto del quórum se toma en consideración. Puede conocer el estado del voto del quórum mediante el cmdlet PowerShell: (GetCluster). WithnessDynamicWeight. Si el valor es igual a "1", entonces el voto del quórum se considera, si vale "0", el voto del quórum no se tiene en cuenta. Esta configuración no se recomienda para una configuración multisitio (almacenamiento replicado) y requiere que todos los nodos del clúster estén instalados con Windows Server 2012 R2. Mayoría de recurso compartido de archivos y nodo: idéntico al anterior, aunque utiliza un recurso compartido de archivos externo al clúster en lugar del disco quórum. Esta es la configuración que utiliza Microsoft Exchange 2007 en su configuración en clúster CCR (Cluster Continuous Replication) y por Microsoft Exchange 2010 y 2013 para DAG (Database Availability Groups). Sin mayoría: sólo disco: solamente un nodo puede poseer el volumen en un momento determinado, y recupera el conjunto de los recursos. Esta solución se corresponde con el funcionamiento de un clúster Windows Server 2000/2003. Ya no es el modo recomendado, sobretodo en el caso de clúster multisitio (con almacenamiento replicado). No tolera la pérdida del quórum de disco (convirtiéndose en un punto de fallo único).
Cada recurso hospedado en un clúster (instancia SQL, compartición de archivos, Exchange...) dispone de uno o varios grupos que contienen un conjunto de recursos dedicados a su funcionamiento. Para poder definir un servicio o una aplicación, hay que escoger entre las siguientes opciones: • • • • • • • • • • • • • •
Aplicación genérica Servicio genérico DTC (Distributed Transaction Coordinator) Ordenador virtual (máquina virtual Hyper-V) Message Queuing Servidor de espacios de nombres DFS Servidor de archivos Servidor DHCP Servidor de destino iSCSI Servidor iSNS (Internet Server Name Service) Servidor WINS Otro tipo de servidor Servicio de agente de conexión para los servicios de Escritorio remoto Un script genérico. Éste le permite utilizar un script para realizar verificaciones específicas para determinar el estado del recurso y decidir o no conmutar el clúster.
Una vez creado el grupo, pueden agregarse los siguientes recursos virtuales:
• • • • • • • • •
Aplicación genérica Punto de acceso de cliente (con un nombre y una dirección IP virtual) Script genérico Servicio genérico Dirección de túnel de IPv6 Coordinador de transacciones distribuidas Recurso compartido de NFS Servidor DHCP, WINS Carpeta compartida
En función del tipo de recurso, algunos parámetros estarán, o no, disponibles. Los parámetros siguientes son comunes a todos los recursos: •
Dependencias: este parámetro determina qué otros recursos deben estar operativos para que este recurso funcione. Este parámetro puede, a su vez, determinar en qué orden deben iniciarse los recursos. Si alguna dependencia fallara, los recursos que dependan de ella se detendrán. Es posible utilizar los operadores lógicos "Y" y "O". El operador "O" permite flexibilizar las dependencias, en la medida en que dos recursos pueden cumplir un mismo rol. Es el caso, en particular, de un clúster que tenga nodos sobre dos subredes diferentes. Existen dos recursos de tipo ”dirección IP” (una por cada subred), aunque solamente habrá operativo uno de ellos, en un instante T. El operador lógico "O" permite satisfacer sólo una de ambas dependencias.
•
•
Afectar al grupo: este parámetro está activo por defecto. Determina, en caso de que falle algún recurso del grupo, si todo el grupo de recursos debe conmutar sobre otro nodo. Si este recurso no es imprescindible para el funcionamiento del grupo completo, puede considerarse el no conmutar y que el grupo no se vea afectado. Las soluciones de copia de seguridad crean, por lo general, un recurso en el clúster. Si se produce algún problema (crash o una acción incorrecta en la solución de seguridad), todo el grupo conmutará. Una solución de supervisión adecuada permite alertar sobre el fallo de este recurso y dejar el tiempo suficiente para reparar el problema antes de que empiece la copia de seguridad. Evitará, así, perturbar la disponibilidad del clúster de forma imprevista y no indispensable. Intervalo de comprobación: el intervalo entre dos verificaciones sobre la salud del recurso. Puede ser necesario aumentar el tiempo por defecto en el caso de servidores con mucha carga de trabajo.
En las versiones anteriores de Windows Server, era preciso tener una red privada, dedicada a la comunicación inter-nodo, llamada "heartbeat". Windows Server 2012 R2 ofrece una mayor flexibilidad y no impone esta restricción. El motivo es no tener ningún punto de fallo único y, por tanto, disponer de, al menos, dos caminos de red entre los nodos. Si utiliza iSCSI, las tarjetas de red deben estar dedicadas y la comunicación internodo bloqueada. Si utiliza una red dedicada a la copia de seguridad, es, también, una buena
idea prohibir su uso al clúster. El bloqueo se gestiona desde las propiedades de red, en la consola Administrador de clúster de conmutación por error. Es bastante común que una aplicación almacene ciertos parámetros en una base de registro. Si fuera necesario, el clúster puede replicar una arborescencia de la base de registro, situada en HKEY_LOCAL_MACHINE. Esta configuración puede estar ligada a un servicio de Windows o a una aplicación.
1. Validación de su clúster En las versiones anteriores de Windows Server, el hardware debía estar certificado para poder funcionar con el servicio de clúster de conmutación por error de Microsoft. En caso contrario, Microsoft no garantizaba el soporte. Desde Windows Server 2008, este proceso se ha simplificado. Para poder gozar de una configuración soportada por Microsoft, basta con que: • •
El hardware incluya el logotipo "certificado para Windows Server 2012 R2" (certificado para Windows Server 2012, como mínimo). La instalación se valide mediante el asistente Validación de una configuración.
El asistente realiza una serie de comprobaciones sobre los siguientes dominios: • • • • •
Configuración del clúster Configuración del sistema Inventario Red Almacenamiento
Existen dos excepciones relativas a este asistente de validación. Las configuraciones siguientes no pasan la prueba relativa al almacenamiento: •
•
Exchange en modo CCR (Cluster Continuous Replication). El clúster no dispone de un almacenamiento compartido, puesto que lo replica CCR. Esta comprobación no puede llevarse a cabo (http://technet.microsoft.com/en-us/library/bb676379.aspx). Los clústeres que utilizan un almacenamiento replicado. Ambos nodos tienen acceso al conjunto de volúmenes incluido el quórum (http://technet.microsoft.com/enus/library/cc732035(WS.10).aspx#BKMK_multi_site).
La prueba acerca del almacenamiento es la única que podría interrumpir la disponibilidad. Una vez tenga el clúster en producción, puede utilizar una LUN, de forma temporal, para superar las pruebas relativas al almacenamiento, en lugar del set de pruebas completo. Este asistente tiene como objetivo verificar un clúster que se pone en producción, aunque también cada cambio significativo realizado sobre el mismo, como:
• • •
La actualización del firmware o de los controladores. La agregación o eliminación de un nodo en el clúster. El cambio de hardware de almacenamiento.
Encontrará referencias a las pruebas a realizar en función de las modificaciones realizadas sobre el clúster en la siguiente dirección: http://technet.microsoft.com/enus/library/cc732035(WS.10).aspx#BKMK_validation_scenarios
2. Implementación del clúster La implementación del clúster incluye las siguientes etapas: • • • •
Configurar las interfaces de red sobre los futuros nodos del clúster. Configurar el almacenamiento para el clúster. Instalar la funcionalidad de clúster de conmutación por error. Configurar el clúster:
• •
Interfaz de red Determinar la mayoría (quórum, recurso compartido testigo...)
•
En función del objetivo del clúster, instale el rol de alta disponibilidad sobre todos los nodos (servidor de archivos, servidor WINS...). Cree la aplicación en el clúster. Bascule sobre cada uno de los nodos para validar el correcto funcionamiento de los mismos. Ejecute, de nuevo, el asistente de validación del clúster.
• • •
a. Configurar la red para el clúster
La primera etapa consiste en configurar las interfaces de red de los nodos de su futuro clúster. Recuerde que se recomienda encarecidamente utilizar varias tarjetas de red, cada una configurada sobre una subred o una VLAN diferentes, y dedicarles un rol bien definido. En nuestro ejemplo, utilizaremos cuatro tarjetas de red por nodo, he aquí su configuración: • • • •
LAN (172.16.0.x/16): dedicada a la comunicación entre los clientes y los nodos del clúster. Clúster (10.0.1.x/24): dedicado a las comunicaciones internas del clúster. Almacenamiento 1 (10.0.2.x/24): primera conexión al espacio SAN iSCSI. Almacenamiento 2 (10.0.3.x/24): segunda conexión al espacio SAN iSCSI.
Todas las interfaces deben estar direccionadas convenientemente. Esta conectividad con la red local (LAN), donde se encuentran los clientes, debe estar direccionada correctamente (dirección IP y DNS). Para las demás interfaces, y salvo por algún motivo en especial, debería dejar el mínimo imprescindible (dirección IP, deshabilitar el registro DNS y de NetBIOS).
b. Configurar el almacenamiento para el clúster
La segunda etapa consiste en conectar sus nodos a un espacio de direccionamiento, iSCSI en nuestro ejemplo, teniendo en cuenta la duplicidad de equipos de red para la tolerancia a fallos. Para poder gestionar varias rutas de red para alcanzar el almacenamiento, será preciso instalar la funcionalidad MPIO (MultiPath I/O). La configuración de los destinos iSCSI se realiza de la siguiente manera: Abra el iniciador iSCSI desde las herramientas administrativas. Vaya a la pestaña Detección, en la sección Portales de destino, haga clic en el botón Detectar portal..., escriba la dirección IP del espacio de almacenamiento y haga clic en Aceptar. Vaya a la pestaña Destinos, seleccione el destino correspondiente a la LUN para el quórum y, a continuación, haga clic en el botón Conectar. En la ventana Iniciar sesión en el destino, marque la opción Habilitar múltiples rutas y, a continuación, haga clic en Opciones avanzadas.... En la sección Conectarse utilizando de la pantalla que muestra la configuración avanzada, realice los siguientes cambios: • • •
Adaptador local: iniciador Microsoft iSCSI. IP del iniciador: dirección IP del nodo de la primera red de almacenamiento. IP del portal de destino: dirección IP del espacio de almacenamiento en la primera red de almacenamiento.
A continuación, haga clic en Aceptar dos veces. Para gestionar rutas múltiples, deberá repetir las etapas 3 a 5 utilizando las direcciones IP de la segunda red de almacenamiento en la etapa 5. Una vez configurado el iniciador iSCSI, debe instalarse la funcionalidad MPIO. Puede hacerlo a través del Administrador del servidor. A continuación, para configurar la funcionalidad MPIO: Abra la consola MPIO desde las herramientas administrativas. En la pestaña Detectar múltiples rutas, marque la opción Agregar compatibilidad con dispositivos iSCSI (si estuviera deshabilitada, significa que no ha conectado el destino iSCSI) y haga clic en el botón Agregar (vea la siguiente captura de pantalla). Para terminar, valide el reinicio haciendo clic en el botón Sí.
c. Configurar el quórum para el clúster
En este ejemplo, vamos a configurar el clúster en modo mayoría de disco y nodo, lo que implica que el quórum se define en un almacenamiento de red central, un espacio iSCSI, FCo FCoE. Todos los nodos de su futuro clúster deben tener acceso bien al quórum, o bien a la propia LUN. Ahora que ha realizado la conexión con el almacenamiento, vamos a preparar el volumen que queremos utilizar para el quórum del clúster. Para realizar esta preparación, utilizaremos la LUN que ha conectado en la sección anterior. Configure el almacenamiento para el clúster y realice esta tarea únicamente para el primer nodo. Esta preparación puede realizarse de varias formas: • • • •
Desde el Administrador del servidor. Desde la consola Administrador de discos (diskmgmt.msc). Mediante el comando DISKPART.EXE. Utilizando los cmdlets PowerShell.
Utilizaremos la consola Administrador de discos: Abra la consola Administrador de discos. Haga clic, con el botón derecho, sobre el disco destinado a ser el volumen del quórum, que normalmente aparecerá como disco desconocido, y seleccione En línea. Haga, de nuevo, clic con el botón derecho sobre el disco del quórum, y seleccione Inicializar el disco. En la ventana Inicializar el disco, deje las opciones por defecto y valide haciendo clic en el botón Aceptar. En la zona no particionada del disco de quórum, haga clic con el botón derecho y seleccione Nuevo volumen simple.... Mediante el asistente de Creación de un volumen simple, cree un volumen utilizando la totalidad del espacio disponible, asígnele la letra Q (se trata de una vieja convención de nomenclatura para el Quórum), asígnele el nombre quórum y realice un formato rápido en NTFS. d. Instalación del clúster
La instalación de la funcionalidad de clúster puede realizarse de varias formas: • •
Desde el Administrador del servidor. Desde PowerShell:
Invoke-Command -ComputerName nodo3,nodo4 -Command {Install-Windows Features -Name Failover-Clustering -IncludeManagementTools}
La configuración puede hacerse de distintas formas, aunque le conviene utilizar una cuenta con permisos de Administrador de dominio para realizar la creación de la cuenta de equipo que representa el clúster: • •
La interfaz gráfica: Administrador de clúster de conmutación por error. Desde PowerShell.
Observe que la herramienta por línea de comandos cluster.exe ya no se encuentra soportada en Windows Server 2012 R2. En este libro, vamos a explicar el primer y el último método para realizar la configuración de un clúster. Configuración mediante la interfaz gráfica: Abra el Administrador de clústeres de conmutación por error.
Haga clic en Validar configuración en el panel Acciones. El mensaje de bienvenida le recuerda tres aspectos muy importantes:
• • •
Incluso si su instalación pasa la validación, es preciso que todo el hardware incluya una mención "para Windows Server 2012 R2". Es necesario ser, al menos, administrador local de cada uno de los nodos. La validación no puede interrumpirse tanto si realiza todas las pruebas (que incluyen pruebas sobre el almacenamiento) como si realiza una prueba personalizada seleccionando el almacenamiento, lo que significa una interrupción del servicio para el almacenamiento del clúster de algunos segundos durante la validación.
Haga clic en Siguiente.
Agregue todos los nodos que van a formar parte del clúster.
Seleccione la opción Ejecutar todas las pruebas salvo si se trata de una excepción, de tipo clúster Exchange CCR o clúster multisitio. Haga clic en Siguiente.
El asistente muestra un resumen de las opciones anteriores. Haga clic en Siguiente.
Una vez realizadas las pruebas, se muestran los resultados. La primera frase del cuadro de diálogo permite conocer inmediatamente si el conjunto de pruebas es concluyente. Si se han detectado problemas, puede consultarlos mediante el informe. Su instalación se encuentra, ahora, certificada para funcionar en modo clúster de conmutación por error. La siguiente etapa consiste en crear el clúster. Haga clic en Crear el clúster desde el panel Acciones:
Haga clic en Siguiente.
Agregue los nodos que van a formar parte del clúster. Haga clic en Siguiente.
Indique un nombre (virtual) y una dirección IP para el clúster. Ambos recursos estarán dedicados al funcionamiento del clúster y no deberían utilizarse para ninguna otra tarea. Haga clic en Siguiente.
El asistente le muestra un resumen de la configuración que se aplicará antes de hacerlo realmente. Haga clic en Siguiente y, a continuación, haga clic en Finalizar. Habríamos podido llegar al mismo resultado con los siguientes comandos PowerShell: Test-Cluster -Node nodo3,nodo4 New-Cluster -Name cluster02 -Node nodo3,nodp4 -StaticAddress 172.16.0.28
Puede recuperar la lista de comandos de gestión del clúster con: get-command -module FailoverClusters. Por lo general, si se cumplen todos estos requisitos previos, su clúster debería estar, de manera automática, configurado completamente por parte del asistente de instalación del clúster. En nuestro ejemplo, el clúster está configurado en modo Mayoría de disco y nodo utilizando para el quórum la LUN conectada en la sección Configurar el almacenamiento para el clúster. Si lo requisitos previos no se cumplen, su clúster se configurará en modo Mayoría de nodo. Por defecto, la creación de un clúster de conmutación por error a partir de la interfaz gráfica, o mediante el cmdlet PowerShell anterior, implica la creación de la cuenta de equipo para el clúster en Active Directory. Windows Server 2012 R2 aporta una nueva funcionalidad, Directory-Detached Cluster, que permite crear un clúster de conmutación por error sin crear una cuenta de equipo en Active Directory, aunque los nodos formen parte del dominio de Active Directory. El despliegue de este tipo de clúster se realiza, exclusivamente, por línea de comandos PowerShell, agregando el parámetro AdministrativeAccessPoint : Test-Cluster -Node nodo5,nodo6 New-Cluster -Name cluster03 -Node nodo5,nodo6 -StaticAdress 172.16.0.29 -NoStorage -AdministrativeAccessPoint DNS
Conviene verificar la configuración de las redes del clúster para una mejor comunicación entre los nodos, pero también para el almacenamiento de red y el acceso por parte de los clientes. Como se precisaba antes en este mismo capítulo, nuestro ejemplo utiliza cuatro tarjetas de red. He aquí la configuración de las redes del clúster (observe que hemos renombrado las redes para una mejor comprensión):
Una vez haya verificado y corregido, si fuera necesario, los parámetros de su clúster, y antes de agregar los servicios, se recomienda validar el clúster. Para realizar esta tarea, haga clic en el enlace Validar el clúster... que se encuentra en el panel Acciones y siga las instrucciones del asistente de validación del clúster. Llegados a este punto, tenemos un clúster con mayoría de disco y nodo operacional, aunque todavía no hospeda ningún servicio. e. Implementar un clúster de archivos
En una configuración en clúster, el servidor de archivos requiere un almacenamiento compartido sobre un espacio de almacenamiento de red. Deberá, ahora, agregar una conexión a una nueva LUN sobre los nodos antes de agregar el servicio de Servidor de archivos a su clúster. Revise la sección Configurar el almacenamiento para el clúster en este capítulo. Una vez conectada la LUN y creado el volumen (letra E:\ en nuestro ejemplo), debemos agregar este volumen a los discos de nuestro clúster.
En el Administrador del clúster de conmutación por error, vaya a la sección Almacenamiento y, a continuación, Discos. En el panel Acciones haga clic en Agregar un disco. Seleccione el disco que desea agregar y haga clic en Aceptar.
Ahora que el almacenamiento está configurado, es posible agregar el rol Servidor de archivos al clúster. Un pequeño matiz: para configurar un rol en un clúster, debe estar instalado el rol Windows equivalente. Utilice la interfaz gráfica para agregar un grupo servidor de archivos al clúster:
Haga clic en Siguiente.
En la pantalla Tipo de servidor de archivos, puede escoger entre un servidor de archivos para uso general o con escalabilidad horizontal para datos de aplicación. Deje marcada la opción Servidor de archivos para uso general y haga clic en Siguiente.
Indique el nombre virtual del clúster para este grupo, así como una dirección IP virtual.
Seleccione el o los volúmenes que hospedan los datos.
El asistente muestra el resumen de la configuración que se va a aplicar. Haga clic en Siguiente.
El asistente muestra el informe de creación. El grupo que acaba de crear aparece en la arborescencia Roles:
Sólo queda probar el clúster reiniciando los nodos, cada uno en su turno y, a continuación, crear los recursos compartidos. Sepa que este procedimiento es idéntico para todos los roles de Windows que quiera configurar en clúster. f. Casos particulares
Caso de SQL Server En la instalación en clúster de una aplicación Microsoft SQL Server, debe tener en cuenta: • • • • • • •
Instalar el clúster. Instalar MSDTC como aplicación clúster (si fuera necesario). Instalar Microsoft Framework 3.5 SP1. Instalar Windows Installer 4.5. Crear un grupo de clúster vacío (uno por instancia a instalar). Asignar volúmenes de almacenamiento al grupo. Ejecutar el programa de instalación de SQL Server (como mínimo, SQL Server 2008 R2 SP1 o SQL Server 2012).
De preferencia a las versiones que ya incorporen los Service Packs mencionados, en particular los que permitan evitar los problemas que se describen en los artículos 955725 y 973993 de la base de conocimiento. Caso de Exchange Microsoft Exchange Server 2010 está, oficialmente, soportado a partir del Service Pack 3. Exchange Server 2013 también está soportado. Caso de Hyper-V Una de las principales novedades asociadas a Hyper-V y a los clústeres es la relativa al almacenamiento de máquinas virtuales. El CSV (Cluster Shared Volume), que se incluye con Windows Server 2008 R2, hace que no sea obligatorio disponer de un volumen por máquina virtual (VM). Es posible hospedar un conjunto de máquinas virtuales sobre el mismo volumen. Uno de los nodos realiza el rol de coordinador, siendo el único que puede crear archivos. Es él el encargado de gestionar el acceso de escritura a los archivos por parte de los servidores, para que no haya dos servidores que modifiquen el mismo archivo. Las ventajas son numerosas: •
• • •
El espacio libre es común a todas las VM. Este espacio pueden utilizarlo todas las VM cuyo almacenamiento sea de tipo extensible, y también es posible agregar nuevas VM. La eliminación de una VM hace que su espacio quede disponible, inmediatamente, para las demás VM. El número de volúmenes es considerablemente bajo. Habrá menos intervenciones sobre el almacenamiento central y, por tanto, menos riesgos derivados. El tamaño del volumen puede ser importante, y el tiempo de análisis para realizar un chkdsk está vinculado con el número de archivos y no con el tamaño. Con Windows Server 2012 R2, CSV soporta funcionalidades avanzadas de administración de archivos tales como la deduplicación de datos y ReFS (Resilient File System), de las que se habla en el capítulo El ciclo de vida de su infraestructura.
El modo CSV está soportado y se reserva, exclusivamente, para almacenar máquinas virtuales Hyper-V. Jamás debería utilizarse para almacenar otro tipo de objetos. Es posible agregar volúmenes CSV desde el Administrador de clúster de conmutación por error o mediante comandos PowerShell: $cluster = Get-Cluster cluster01 $cluster.EnableSharedVolume="Enabled"
Windows Server 2012 R2 aporta, a su vez, los discos virtuales VHDX compartidos (Shared VHDX) que permiten el acceso al mismo disco virtual, en formato *.vhdx, a varios equipos virtuales. Esto permite, por ejemplo, crear clústers compuestos por nodos formados por máquinas virtuales. Se aborda la implementación de un Shared VHDX en el capítulo Consolidar sus servidores.
3. Migración de Windows Server 2008 a 2012 R2 Si bien este libro está orientado a Windows Server 2012, existen ciertas consideraciones que debemos tener en cuenta si queremos migrar un clúster desde una edición anterior a Windows Server 2012 R2: •
•
•
•
Windows Server 2012 R2 existe, únicamente, en versión de 64 bits. Esto obliga a que tanto el hardware como todas las aplicaciones del mismo deban ejecutarse sobre 64 bits o, al menos, mediante la emulación de 32 bits WoW64 (Windows On Windows). La funcionalidad Compartir subdirectorios ya no está disponible desde Windows Server 2012. Será preciso crear cada recurso compartido. Esto se debe a una limitación técnica de 900 recursos compartidos. Como ya no existe este problema, esta funcionalidad se ha suprimido. DFS y FRS ya no están soportados en Windows Server 2012 R2 (salvo para controladores de dominio). Debería migrar a DFSR, preferentemente. Esto implica que los demás nodos DFS estén configurados, como mínimo, en Windows Server 2003 R2. ¿Utilice nombres virtuales y direcciones IP diferentes a las del grupo de clúster para sus recursos? Si no fuera el caso, la migración implicará una interrupción mayor del servicio, pues ambos clústeres (el viejo y el nuevo) deben cohabitar durante la migración.
Existen dos enfoques para abordar la migración: • •
Conservar el mismo hardware. Migrar el clúster a un nuevo clúster físico.
El primer enfoque consiste en: • • • • • •
Sacar un nodo del clúster (véase el artículo 935197 de la base de conocimiento de Microsoft). Actualizarlo a Windows Server 2012 R2 o instalar de nuevo todo el sistema operativo. Crear un nuevo clúster sobre este servidor. Utilizar el asistente para migrar un clúster. Poner en línea los recursos migrados. Sacar el nodo 2008 del anterior clúster y actualizarlo.
El segundo enfoque se utiliza muy a menudo, puesto que el cambio de sistema operativo supone, a menudo, un cambio de generación de hardware. El plan es muy similar, siempre que no se degrade (en número de nodos) durante la migración: • •
Instalar un clúster Windows Server 2012 R2 sobre, al menos, uno de los nodos (nuevo clúster). Utilizar el asistente para migrar un clúster.
• • •
Decidir si se utiliza el mismo almacenamiento o no. Poner en línea los recursos migrados. Eliminar el clúster anterior.
4. Configurar un clúster de conmutación por error en modo multisitio Si ocurre cualquier problema con el DRP (Plan de Recuperación ante Desastres) o, especialmente, del PSI (Plan de Seguridad Informática) llevados a un situación extrema, algunas empresas implementan un entorno informático idéntico al entorno de producción sobre un sitio auxiliar (locales separados geográficamente). El objetivo es que, si el sitio principal dejara de estar disponible (debido a un fuego, a una inundación...), los usuarios no tengan más que acudir al sitio secundario para poder seguir trabajando. Para ello, es preciso, evidentemente, que los usuarios sean capaces de encontrar los mismos datos y los mismos servicios que en el sitio principal, de la manera lo más transparente posible. En lo relativo a los propios datos, tiene varias posibilidades para replicarlos entre los sitios (DFS-R por ejemplo). Pero, ¿qué ocurre con un clúster? La implementación de un clúster de conmutación por error en un multisitio supone que los sitios estén conectados mediante una conexión fiable y rápida, e impone, a su vez, una replicación de datos del clúster. Esta replicación puede realizarse de distintas formas: •
•
•
A nivel de hardware: a día de hoy, la mayoría de espacios de almacenamiento profesionales permiten replicarse entre sí. Con algunos de ellos, es posible incluso encriptar y comprimir los datos replicados. Con este tipo de replicación, el espacio de almacenamiento replica los bloques de datos sea cual sea el tipo o el sistema de archivos. A nivel lógico o sistema de archivos: la replicación a nivel de aplicación se basa, a menudo, en el servicio DFS-R de Microsoft, si bien existen otras soluciones de replicación. Se trata de una replicación basada en el sistema de archivos. A nivel de aplicación: en este tipo de replicación, es la propia aplicación la encargada de replicar sus propios datos. Podemos citar a Microsoft Exchange 2007 como ejemplo, con una replicación de tipo CCR.
A esto le acompañan dos modos de funcionamiento: •
•
Una replicación síncrona: en este modo, cuando un dato se encuentra en el almacenamiento del sitio principal, la acción se considera como terminada cuando todos los sitios reconocen la escritura de dicho dato. Esto puede suponer una fuerte latencia de procesamiento si la replicación utiliza una conexión lenta. Una replicación asíncrona: aquí, el clúster del sitio principal puede leer y escribir sobre su almacenamiento sin tener por qué esperar a que los datos se repliquen sobre el segundo sitio. La replicación se efectúa, en este caso, bien de forma continua o bien de manera planificada. En caso de siniestro, puede haber cierta diferencia entre los datos de ambos sitios.
Desde un punto de vista del clúster, este comportamiento debe configurarse como Mayoría de nodo o Mayoría de recurso compartido de archivos y nodo. En este último modo, se recomienda que el recurso compartido de archivos para el quórum esté hospedado en un servidor externo al clúster. Esto permite aprovechar la conmutación por error automática entre los sitios, si bien la mayoría de administradores prefieren realizar esta conmutación de forma manual.
5. Actualización compatible con clústeres de conmutación por error Incluida con Windows Server 2012 R2, la funcionalidad Actualización compatible con clústeres (CAU, Cluster-Aware Updating) permite automatizar la aplicación de actualizaciones de Microsoft (Windows Update) sobre los nodos del clúster, conservando un alto nivel de servicio. El principio de funcionamiento es sencillo: se instalan las actualizaciones nodo a nodo. En primer lugar, el primer nodo se pone en pausa, sus sesiones activas se drenan hacia otro nodo y los roles basculan. A continuación, se aplican las actualizaciones y se reinicia el servidor, si fuera necesario. Para finalizar, el nodo se pone en funcionamiento dentro del clúster, recuperando los roles que tuviera antes de realizar las actualizaciones. La actualización compatible con clústeres funciona siguiendo los siguientes dos modos: •
•
Actualización remota: en este modo se utiliza un equipo Windows Server 2012 R2 o Windows 8.1 (Windows Server 2012 y Windows 8, como mínimo) con las herramientas de administración de Actualización compatible con clústeres instaladas que no forme parte del clúster. Este equipo permite verificar, aplicar y realizar un seguimiento de la aplicación de actualizaciones con una instalación mínima (Server Core) de Windows Server 2012 R2 o Windows Server 2012. Actualización automática: en este modo, es el clúster quien administra, directamente, las actualizaciones sobre los nodos. El primer nodo que se actualiza es el que posee el rol de Actualización compatible con clústeres y, a continuación, se actualizan los demás nodos.
De hecho, el proceso de actualización adaptado a los clústeres ejecuta el cliente Windows Update. De este modo, por defecto, es posible instalar todas las actualizaciones disponibles en el sitio Windows Update de Microsoft. Es posible gestionar las actualizaciones que quiere instalar sobre sus nodos con ayuda de un servidor WSUS interno y una GPO. Puede configurar la actualización compatible con clústeres en modo automático de dos formas: utilizando el Administrador de clúster de conmutación por error, seleccionando su clúster y, a continuación, haciendo clic en el enlace Actualización compatible con clústeres que se encuentra en la sección Configurar, o bien mediante comandos PowerShell.
En el primer caso, en la zona Conectar a un clúster de conmutación por error, tendrá que seleccionar el nombre de su clúster y, a continuación, hacer clic en Conectar para que aparezcan sus nodos.
Mediante la consola Actualización compatible con clústeres, podrá: • •
Aplicar actualizaciones a este clúster: con ayuda del asistente, puede instalar, de manera inmediata, las actualizaciones disponibles para los nodos de su clúster. Vista previa de actualizaciones para este clúster: le permite ver las actualizaciones disponibles para los nodos de su clúster.
•
•
Crear o editar perfil de ejecución de actualizaciones: permite crear o modificar un perfil de ejecución de actualizaciones y almacenarlo en formato XML para importarlo en otro servidor. Generar informe sobre ejecuciones de actualización anteriores: permite generar un informe acerca de la ejecución e instalación de las actualizaciones en su clúster.
•
Configurar opciones de auto-actualización de clúster: le permite habilitar, deshabilitar, configurar y planificar la aplicación de actualizaciones automáticas en su clúster de forma automática, mediante un simple asistente.
•
Analizar preparación de la actualización del clúster: permite verificar la correcta configuración del clúster para instalar actualizaciones remotas.
Ejemplo de configuración mediante PowerShell: #Agregar un rol al clúster Add-CauClusterRole -ClusterName cluster02 -CauPluginName Microsoft.WindowsUpdatePlugin -MaxRetriesPerNode 3 -CauPluginArguments @{’IncludeRecommentedUpdate’=’True’} -StartDate "14/10/2012 03:00:00" -DaysOfWeek 4 -WeeksOfMonth @(3) -EnableFirewallRules -Force #Activación del rol Enable-CauClusterRole -ClusterName cluster02 -Force
Conclusión Ahora, conoce las ventajas e inconvenientes de una solución de alta disponibilidad y/o de reparto de carga. Tiene las cartas en su mano para preparar su solución y gestionarla una vez puesta en producción. Como con muchas otras soluciones, no debe esperar a tener alguna necesidad tecnológica concreta (una caída de algún servidor, por ejemplo) para validar su buen funcionamiento. Debe planificar pruebas de forma regular, con el objetivo de asegurar su correcto funcionamiento del día D. A diferencia de la mayoría de proyectos,
es precisamente si ningún usuario se da cuenta de nada (comportamiento transparente), cuando podremos decir que el proyecto ha sido un éxito.
Introducción Este capítulo está dedicado a la definición y la configuración de los componentes necesarios para el correcto funcionamiento de la red de la empresa basada en Windows Server 2012. En él, se abordan los componentes IP, DNS, DHCP, WINS, así como la implementación de la cuarentena de red en DHCP, IPsec y 802.1x.
Seleccionar una infraestructura de red La implementación de toda la arquitectura de red supone realizar un análisis de las redes existentes. A menudo, es difícil modificar el conjunto de una sola vez. La migración se lleva a cabo, habitualmente, implementando un nuevo direccionamiento de red y haciéndolo cohabitar con las redes existentes. La modificación del direccionamiento IP se ve, a menudo, como una tarea costosa que aporta pocas ventajas suplementarias. Es, por lo general, durante el desplazamiento o la creación de un sitio cuando es fácil, o incluso necesario, repensar el direccionamiento IP y planificar un nuevo sistema. El cambio de un dominio DNS es, todavía, más complicado, sobre todo cuando dicho dominio sirve como soporte a un dominio Active Directory. En este caso, una migración representa un estudio particular que se sale del marco de nuestra presentación.
1. La elección de la arquitectura de red A este nivel, cabe estudiar bien dos puntos: • •
La elección de la zona DNS. La elección de la clase de red.
a. La zona DNS
Existen dos aspectos importantes a la hora de escoger la zona DNS. El nombre escogido para la zona DNS debe corresponderse con la integridad de la entidad (empresa, grupo, etc.) que se quiere gestionar. Este nombre debe poder ser aceptado por todas las entidades dependientes que tengan que alcanzar esta zona. ¡El problema es más de aspecto político que técnico!
Si alguna entidad no se encuentra en este marco, quiere decir que debe asociársele una zona DNS específica. Si la zona DNS debe utilizarse en Internet, el dominio DNS tendrá que ser, obligatoriamente, público y estar registrado, es decir, debe utilizar una extensión reconocida de tipo .es, .com, .info... En una red interna, el dominio puede ser público o privado. La elección más común es, por tanto, escoger un dominio DNS local con una extensión desconocida en Internet. La extensión .local se utiliza muy a menudo bajo la forma miempresa.local. El desacople entre la sección interna y la externa resulta mucho más fácil de llevar a cabo. Esta elección se desaconseja, pues los proveedores de certificados han decidido, de acuerdo con los grandes fabricantes, no distribuir más certificados a partir del 1 de Enero de 2014 que incluyan nombres de dominios DNS que no puedan verificarse. Esto tiene una consecuencia directa en la configuración de muchos servidores Exchange que trabajan con este tipo de certificados. No obstante, es probable que algunos servidores Web visibles al mismo tiempo en la Intranet y en Internet utilicen este tipo de funcionalidad. En cambio, el uso del mismo nombre de dominio sobre la red interna y sobre Internet obliga a tener servidores DNS diferentes para hacer visible sobre Internet únicamente la parte que se desea exponer. Esto supone una doble administración de las zonas DNS. Esta solución resulta muy compleja. En las nuevas instalaciones, las recomendaciones serán: • •
bien utilizar un dominio con una extensión conocida (y disponible en el registro) tal como .org, .net, .info. o bien definir un subdominio del dominio público que ya se esté utilizando, de la forma ad.miempresa.es.
En ambos casos, no supondrá ningún problema obtener un certificado público. b. La clase de red
Para todas las redes internas, la elección se realizará, evidentemente, sobre las clases de redes privadas. Si no se quiere modificar la integridad de las redes existentes por motivos a menudo históricos, es posible, al menos, crear todas las nuevas redes siguiendo esta regla. La clase de red se escoge en función del número de máquinas presentes en la red, del número de sitios, etc. Una red de clase C (192.168.0.X) representa, a menudo, una buena elección inicial. Siempre es posible cambiar la clase de la red o incluso utilizar varias redes en función de las necesidades. El uso de TCP/IP v6 no está, todavía, bien desarrollado, aunque será necesario en un plazo de dos a tres años, principalmente en Internet. En la red local, siguen existiendo muchas aplicaciones que no son compatibles, ¡aunque deberían evolucionar rápidamente! La red IPv6 se estudia en el capítulo La evolución de la red.
2. La instalación de un servidor DHCP El servidor DHCP permite implementar rápidamente la red seleccionada, y permite, también, modificar rápidamente y de forma global una serie de parámetros. Las empresas que, a día de hoy, no utilizan ningún servicio DHCP son más bien raras. Como muchos otros componentes de Windows Server 2012, el servicio DHCP es un rol. a. Definición
El protocolo DHCP (Dynamic Host Configuration Protocol) tiene como objetivo proveer una dirección IP y una máscara de subred a cualquier dispositivo de la red (estación, servidor u otro) que lo solicite. Según la configuración, es posible configurar también otros parámetros importantes, tales como: las direcciones IP de la ruta por defecto, los servidores DNS que debe utilizar, los servidores WINS y el sufijo del dominio, por citar algunos de los más importantes. DHCP se reserva, a menudo, para las estaciones, las impresoras, y no debería servir, salvo muy excepcionalmente, para los servidores. b. Instalación
Como con todos los demás componentes de Windows, la instalación puede llevarse a cabo de forma gráfica o mediante un comando PowerShell sin tener que insertar ningún medio extraíble. Instalación mediante PowerShell : Install-WindowsFeature DHCP
Preste atención, ¡el servicio se iniciará y configurará de manera inmediata con arranque automático! En cambio, la instalación del componente DHCP mediante PowerShell sólo instala el servicio DHCP. Es preciso ejecutar el comando indicado a continuación para instalar la herramienta de administración. Install-WindowsFeature RSAT-DHCP
El servicio debe iniciarse para poder acceder y configurar DHCP. Para que el servicio DHCP empiece a distribuir las direcciones, es imprescindible configurar y habilitar un ámbito. Preste atención, si el servidor que hospeda DHCP forma parte de un bosque Active Directory, debe estar, además, autorizado para los administradores miembros del grupo
Administradores de empresas y aquellos que hayan recibido los permisos de administración de DHCP. El servicio DHCP, como los demás servicios de red de referencia (DNS, WINS), debería instalarse siempre sobre servidores que utilicen una IP fija. c. Configuración
La consola de administración de DHCP se encuentra en cualquier servidor con el rol DHCP instalado mediante la interfaz gráfica y en cualquier servidor donde se haya agregado, específicamente, este componente de administración. Si el servidor local tiene el rol DHCP instalado, el servidor debería aparecer automáticamente en la consola.
Si el servidor no tiene el rol DHCP instalado, o no es el servidor que desea administrar, utilice el botón derecho para agregar un servidor específico o escogerlo entre los servidores autorizados.
Para autorizar un servidor DHCP, utilice la opción Administrar servidores autorizados.
Haga clic en el botón Autorizar, e indique el nombre o la dirección IP.
En un bosque Active Directory, sólo aquellos servidores DHCP que estén autorizados a los administradores de empresas tienen el permiso de asignar direcciones IP a partir de los ámbitos habilitados. Confirme la dirección y el nombre propuestos haciendo clic en el botón Aceptar.
Cierre la ventana de los servidores autorizados haciendo clic en Cerrar.
Los servidores autorizados aparecen marcados con una flecha de color verde.
Cada servidor DHCP puede servir varios ámbitos, aunque sólo uno por cada red IP. Utilice el asistente Ámbito nuevo que aparece haciendo clic con el botón derecho sobre IPv4 para preparar el uso de la red deseada.
Defina el nombre y la descripción del ámbito.
Indique el ámbito deseado.
He aquí un ámbito clásico para una red 172.16.X.X de clase B que utiliza una máscara estándar 255.255.0.0.
El rango utilizado no debe, obligatoriamente, utilizar la totalidad de la clase de red, de modo que puede dejar algunas direcciones libres para los servidores, o direcciones IP reservadas a impresoras u otros dispositivos. Informe las excepciones y el eventual retardo.
Las exclusiones permiten bloquear el uso de direcciones cuyo grupo de direcciones ya esté en uso en el ámbito seleccionado. Esta elección se utiliza, a menudo, cuando se quiere recuperar direcciones excluidas. El retardo permite tener en cuenta los distintos métodos de conmutación o escoger un servidor DHCP para que responda en primer lugar sobre un segmento determinado. Seleccione la duración del contrato.
La duración del contrato debe seleccionarse en función de la disponibilidad de direcciones. Idealmente, el contrato será lo más largo posible (30 días) siempre y cuando existan las suficientes direcciones disponibles. Si fuera necesario disminuir a menos de 3 días la duración del contrato, cabría considerar una ampliación de la subred seleccionada. Configure las opciones del ámbito.
Defina la dirección IP de la pasarela por defecto (pasarela de red).
La pasarela por defecto forma parte de los parámetros que habitualmente están ligados al ámbito. Salvo casos muy concretos, sólo hay que incluir una dirección IP. Las direcciones IP siguientes se utilizan únicamente si la primera no responde. Indique el sufijo DNS y las direcciones IP de los servidores DNS.
Idealmente, todo dominio Active Directory debería incluir, al menos, dos controladores de dominio y, por tanto, dos servidores DNS a este nivel. Escriba las direcciones IP de los eventuales servidores WINS.
Como buena práctica, se recomienda no utilizar servidores WINS, salvo en caso necesario. No hay que informar las direcciones IP de los servidores WINS salvo si el servicio tiene que estar, efectivamente, instalado. Active el ámbito al finalizar el asistente
He aquí la visualización de las opciones del ámbito tras su activación. Observará que las opciones a nivel de servidor se identifican mediante un icono especial que representa un servidor. Son aquellas que contienen parámetros que son variables globales sobre todos los ámbitos.
Las opciones del servidor (006, 015, 042 y 046) sirven como valores por defecto, aunque se reemplazan por las opciones del ámbito, que son prioritarias.
•
•
La opción Nombre de dominio DNS no permite especificar varios sufijos de búsqueda DNS. Si fuera necesario, las directivas de grupo permiten agregar sufijos de búsqueda. El Tipo de nodo con el valor 0x8 configura el modo de resolución híbrida. Es decir, se realizará una búsqueda de servidores WINS en primer lugar, y se pasará al modo Broadcast si falla.
Puede resultar muy interesante configurar ciertas propiedades avanzadas del servidor DHCP. Por ejemplo, cuando se configura la zona Intentos de detección de conflictos con un valor superior a cero (generalmente 2), DHCP utilizará una consulta ICMP para determinar la posible existencia de alguna máquina sobre esta dirección.
La actualización dinámica de los registros DNS es un elemento particularmente importante que hay que configurar.
En la versión R2, es posible deshabilitar la actualización dinámica de los registros PTR. El botón Configurar permite habilitar la protección de nombres durante la inscripción, las actualizaciones y las eliminaciones de registros de tipo A y PTR. Esta protección resulta efectiva únicamente si está habilitado el modo Actualizaciones dinámicas seguras. Cuando se crean y utilizan zonas de búsqueda inversa (Reverse DNS), es importante actualizar los registros PTD y no ignorarlos cuando se elimina el contrato.. La duración del contrato será más elevada conforme mayor sea el número de direcciones IP disponibles y menor sea el riesgo de producirse algún conflicto. La pestaña Filtros permite limitar la distribución de direcciones DHCP, bien autorizando ciertos tipos de hardware de red o bien excluyendo algunos otros. Estos tipos incluyen, habitualmente, Token Ring, X25, ATM, Ethernet, Localtalk, Frame Relay, Fibre channel, HDLC, LocalNet y Ethernet IEE 802.
d. Reservas
Incluso para aquellos administradores que quieran gestionar todas las máquinas con un direccionamiento IP fijo, DHCP puede resultar muy útil. En efecto, hay quien gestiona de este modo la práctica totalidad del parque mediante una reserva para cada dirección IP, incluso si esto supone una seguridad más o menos ficticia. Sin llegar al caso en que debamos gestionar así toda la red, las reservas resultan muy útiles para las impresoras de red, los dispositivos administrables (tales como switch...) y, en ocasiones, para ciertas máquinas cuya dirección IP se autorice y utilice en la configuración de alguna aplicación. Cada tarjeta de red dispone de una dirección física única llamada dirección MAC y, de este modo, es posible identificar una demanda proveniente de esta dirección y proveerle siempre la misma dirección IP y la misma configuración. He aquí un ejemplo de definición de una reserva:
Observe que las reservas deben formar parte de la red, aunque no tienen por qué formar parte del ámbito DHCP, lo cual puede resultar práctico en ciertas ocasiones. Si se utilizan varios servidores DHCP para una misma subred (con restricción de uso), las reservas deben configurarse sobre todos los servidores. Algunas herramientas proveen kits de recursos tales como DHCPCMD.EXE, o la librería DHCPOBJS.DLL, que permiten desarrollar scripts para automatizar la creación y configuración de los ámbitos. El comando NETSH permite, también, realizar operaciones de configuración, importación o exportación. Para exportar una configuración existente, puede utilizar el comando NETSH: NETSH DHCP SERVER DUMP
>DHCPCONFIG.CMD
Adapte, a continuación, el archivo DHCPCONFIG.CMD en función de las necesidades eliminando las líneas inútiles y modificando las demás. La programación de DHCP para PowerShell requiere que se cargue el módulo correspondiente mediante el siguiente comando: Import-Module DHCPSERVER
La instrucción Get-Command -Module DHCPSERVER enumera todos los componentes que incluye este módulo.
He aquí un enlace hacia un primer ejemplo de uso práctico de los comandos PowerShell para DHCP: http://blogs.technet.com/b/teamdhcp/archive/2012/07/15/bringing-powershellto-dhcp-server.aspx e. Registros DNS basados en directivas DHCP
Las directivas DHCP permiten configurar de manera particular los dispositivos, por ejemplo asignándoles una parte del rango IP, en base a los siguientes criterios: • • • • •
La clase Vendor La clase User La dirección MAC El identificador de cliente La información relativa al agente de retransmisión
Estas directivas resultan particularmente interesantes para gestionar, de distinta manera: • • •
Los tipos de dispositivos diferentes: impresoras, teléfonos IP… El rol y el distinto uso de estos dispositivos: portátiles, PC fijos… Dispositivos virtuales: máquinas virtuales
El criterio más sencillo que se puede utilizar es, a menudo, la dirección MAC cuyos 6 primeros caracteres hexadecimales identifican, generalmente de forma unívoca, al fabricante y el modelo. En el caso de máquinas virtuales, son los 6 últimos caracteres los que pueden resultar útiles, pues definen el direccionamiento definido a nivel de hypervisor. Destacaremos que las directivas se gestionan bien a nivel del servidor o bien a nivel de un ámbito. Cree una nueva directiva DHCP.
Asigne un nombre a la directiva.
Agregue una condición.
Seleccione las condiciones de aplicación de la directiva.
Haga clic en Agregar tras marcar la opción Anexar o Anteponer.
Indique si desea utilizar un ámbito concreto para esta directiva.
Preste atención, este rango de direcciones IP debe formar parte del ámbito DHCP correspondiente. Indique las propiedades DHCP que podrían ser diferentes (Router, Servidor DNS…).
Resumen de la configuración inicial:
La dirección MAC puede obtenerse desde una ventana de comandos DOS mediante el comando Ipconfig /ALL o mediante el comando PowerShell GET-NetAdapter. Tras configurar una directiva, es posible configurar la actualización de DNS específica asociada a la misma. A partir de las propiedades de la directiva, la pestaña DNS permite modificar el comportamiento del registro DNS, por ejemplo para modificar el sufijo del dominio.
Observe que la pestaña General da acceso a la configuración de una concesión personalizada, incluso ilimitada.
f. Configuración de la conmutación por error del ámbito DHCP
En las versiones anteriores, existían dos formas de garantizar la disponibilidad de la función DHCP: • •
Instalar el servicio en un clúster de Windows Repartir el ámbito DHCP entre varios servidores (habitualmente 70 %, 30 %)
Windows Server 2012 y 2012 R2 proporcionan la funcionalidad de DHCP Failover, es decir, la conmutación por error de DHCP evitando los problemas vinculados con las soluciones anteriores. Para simplificar, esta nueva configuración permite a dos servidores DHCP gestionar la misma red o el mismo ámbito. Existen dos modos de funcionamiento: bien un modo de tipo activo/pasivo, o bien un reparto de carga con un reparto de clientes. En ambos casos, la información y los ámbitos se replican entre los servidores, y los clientes conservan la misma configuración. Observe que, para IPv6, este tipo de configuración no resulta útil. Basta con que ambos servidores DHCP distribuyan las mismas opciones para obtener el mismo resultado.
Sólo es posible instalar dos servidores DHCP. La única restricción es disponer de dos servidores Windows Server 2012/2012 R2. Éstos no deben, obligatoriamente, formar parte del dominio, en cambio no se garantiza el correcto funcionamiento si los relojes están desfasados más de un minuto. He aquí el procedimiento de configuración: La primera etapa consiste en verificar que ambos servidores DHCP están instalados y autorizados, si forman parte de un dominio. Debe existir al menos un ámbito sobre uno de los servidores antes de comenzar con el procedimiento que permite configurar la conmutación por error. La opción Configurar conmutación por error se encuentra en el menú contextual del contenedor IPv4 o del ámbito que se desea proteger.
Seleccione el ámbito (o los ámbitos) que desea configurar en alta disponibilidad.
Agregue el servidor DHCP asociado. Este puede escogerse entre los servidores autorizados en el caso de un dominio, en caso contrario escriba su nombre.
Cree la relación de conmutación por error. ¡Es importante seleccionar el modo de protección!
Seleccionar el modo Equilibrio de carga o Espera activa. El modo Equilibrio de carga repartirá las peticiones en función del porcentaje indicado. El modo Espera activa utiliza únicamente el servidor principal, aunque los datos se replican en el segundo servidor, que toma el control en caso de caída del servidor principal. Escriba una cadena de encriptación en la zona Secreto compartido. Esta cadena se utiliza para dotar de seguridad a la comunicación entre ambos servidores, que comparten esta misma clave. Se muestran los detalles de la configuración antes de su validación.
Se muestra el resultado de la configuración. Haga clic en Finalizar.
La replicación de toda la configuración de la zona, incluidos los rangos activos, se realiza de manera inmediata. He aquí alguna información complementaria relativa a la administración: •
Tras la configuración, es posible forzar la replicación del ámbito o de la relación.
Estas opciones resultan prácticas para asegurar una configuración idéntica en ambos servidores DHCP, por ejemplo tras la parada de uno de los dos servidores. La replicación del ámbito replica únicamente el ámbito seleccionado. La replicación de la relación replica todos los ámbitos configurados con conmutación por error entre ambos servidores DHCP. •
En caso de que se anule la configuración, el servidor principal guarda la configuración, y el servidor Asociado se vacía de cualquier información relativa a este ámbito.
Implementar los sistemas de resolución de nombres 1. La resolución DNS DNS se ha convertido en la piedra angular del funcionamiento de una red Windows basada en Active Directory, aunque no sólo esto. Muchas de las actividades actuales (mensajería, Internet) se basan en un buen funcionamiento de la red y, en particular, del servicio DNS.
Ya no es, por tanto, posible obviar este sistema que hospeda cada vez más información vital para el buen funcionamiento del conjunto de la red. a. Definición
DNS (Domain Name Server) es un protocolo que permite a los clientes (de la red) consultar una base de datos que contiene información sobre las máquinas y los servicios que hospedan. DNS es un sistema que permite establecer una correspondencia entre una dirección IP y un nombre de dominio y, en términos generales, encontrar cierta información a partir de un nombre de dominio. b. Instalación
La instalación del servicio DNS sobre una red Windows se hace, a menudo, en el marco de instalación del primer controlador de dominio Active Directory. Su configuración inicial se tiene en cuenta de manera automática en el asistente DCPROMO. Por defecto, la zona DNS utilizada por Active Directory está, ahora, integrada y administrada por Active Directory. Para instalar el rol DNS mediante PowerShell: Install-WindowsFeature DNS Install WindowsFeature RSAT-DNS-Server
La segunda instrucción instala las herramientas de administración de DNS. Si el servicio DNS se agrega sobre un controlador de dominio, todas las zonas integradas con Active Directory se conocen automáticamente y se utilizan en el servicio DNS para llevar a cabo la resolución de nombres. En los demás casos, el servicio DNS deberá gestionarse como un servidor DNS clásico. Podrá, por tanto, hospedar zonas y servir de caché o de redirector hacia otros sistemas DNS. c. Los distintos tipos de zona
Zona de tipo principal Este tipo de zona se utiliza principalmente para administrar zonas que no estén vinculadas a Active Directory. Las zonas DNS públicas, que contienen los servidores Web de la empresa y los servidores de mensajería son los ejemplos de uso más corrientes. Cada zona se almacena en un archivo de texto específico con formato estándar y extensión .dns. Este tipo de archivo es compatible con los demás sistemas DNS tales como BIND. Esto permite importar o exportar zonas DNS entre los distintos servidores.
El servidor que hospeda la zona principal es el único que autoriza y valida las actualizaciones de su zona. Esta es la principal diferencia con las zonas integradas en Active Directory que autorizan, ellas, las modificaciones sobre cada controlador de dominio. Zona de tipo secundario Una zona secundaria puede establecerse a partir de un servidor de zona principal, una zona integrada en Active Directory o incluso otro servidor de zona secundaria. La zona secundaria no es sino una réplica exacta de la zona de la que depende. En cambio, la replicación debe estar autorizada sobre el servidor que sirve como referencia. En el mundo Windows, la zona de tipo secundario sirve, a menudo, para replicar la información de otro dominio Active Directory para realizar una aprobación entre dos dominios. Las zonas secundarias se configuran, a menudo, sobre servidores BIND (Unix o Linux) para obtener una resolución indirecta de los dominios DNS administrados por Active Directory. Como ocurre con la zona principal, la información se almacena en un archivo de texto con extensión .dns. En caso de pérdida del servidor principal, un servidor de zona secundario puede convertirse en un nuevo servidor principal. Las zonas secundarias presentan, a menudo, problemas de replicación, de retardos en las actualizaciones, de notificación o de seguridad que hay que configurar. Es, por tanto, preferible evitar el uso de zonas secundarias reemplazándolas por redirecciones condicionales o zonas de rutas internas. Zona integrada en Active Directory Una zona integrada en Active Directory consiste, como su propio nombre indica, en utilizar la base de datos de Active Directory como almacén principal de información. De entrada, aprovecha todas las opciones de seguridad de Active Directory, así como la replicación incremental entre todos los controladores de dominio. Todos los dominios DNS pueden integrarse con Active Directory, no sólo aquellos usados directamente por Active Directory. A menos que su servidor DNS no se encuentre en su controlador de dominio, todas las zonas DNS deberían estar integradas en Active Directory. d. Los distintos tipos de replicación
Sólo se aplican a las zonas integradas en Active Directory, accediendo a las propiedades del dominio seleccionado.
Seleccione la zona DNS y, a continuación, haga clic con el botón derecho y seleccione Propiedades en el menú. Haga clic en Modificar junto a Replicación. Aparecen los distintos tipos de replicación. Replicación en todos los servidores DNS del bosque De preferencia a este tipo de replicación para los dominios que deban ser conocidos (y se tengan que resolver) rápidamente en todos los dominios del bosque sin tener que transferir las consultas hacia los redirectores (Forwarders). Esta elección debe aplicarse, particularmente, al dominio raíz del bosque. Replicación sobre todos los controladores de dominio La replicación sobre todos los controladores de dominio es el modo compatible con el que existía en Windows 2000. Se trata de la elección lógica cuando los controladores de dominio se utilizan como servidores DNS de referencia. En efecto, como los controladores de dominio ya replican los datos de DNS al mismo tiempo que los demás datos del directorio, basta con instalar el servicio DNS para que se asegure esta funcionalidad. Replicación sobre todos los servidores DNS del dominio Esta elección se utiliza con poca frecuencia, y permite a los servidores DNS que no son controladores de dominio recibir, también, la replicación de una zona concreta. Replicación ligada a una partición de aplicación Por defecto, en un bosque Active Directory, existen dos particiones de aplicación particulares y que están disponibles para realizar la replicación: • •
la partición ForestDnsZones; la partición DomainDnsZones.
Si se crea alguna otra partición de aplicación, puede utilizarse para replicar la información DNS (u otro tipo de información) sobre grupos de máquinas personalizados. Observe que haciendo clic con el botón derecho sobre el servidor DNS, la opción Crear particiones de directorio de aplicaciones por defecto puede resultar muy útil para recrear una u otra partición.
e. Zonas de búsqueda inversa
Las zonas de búsqueda inversa DNS son capaces de resolver el nombre de una máquina a partir de su dirección IP. La clasificación se realiza, por lo tanto, en función del direccionamiento IP de la red. Este modo de búsqueda no es necesario, y no se utiliza en el funcionamiento normal de un bosque Active Directory. Por este motivo Microsoft no crea zonas de búsqueda inversa de manera automática. En cambio, el cliente DNS de Microsoft sabe cómo utilizarlas si se definen. Algunas herramientas, tales como la copia de seguridad TINA (Time Navigator de ATEMPO) necesitan este tipo de zonas para poder funcionar correctamente. Cuando se resuelve un problema de red y se utiliza la herramienta NsLookup, es imprescindible haber creado estas zonas de búsqueda inversa para que la herramienta funcione correctamente y poder interpretar los resultados. Cuando se crean estas zonas, es importante configurar DHCP para gestionar las actualizaciones de los registros PTR, es decir, el nombre del host asociado con cada dirección IP. La integración de estas zonas con Active Directory se aplica, principalmente, a las redes IP que contienen, en su mayor parte, equipos Windows. Tras la creación de una zona de búsqueda inversa, el nombre de la zona se basa en el direccionamiento IP, tomando cada valor de forma inversa. f. La zona GlobalNames o GNZ
Esta posibilidad no viene activada por defecto. Su objetivo consiste en obtener una resolución de nombres simples (llamados single-label name), sin dominio ni extensión, sobre el conjunto del dominio o del bosque. Para algunos controladores, esto puede servir para eliminar el servicio WINS sin tener que sufrir los inconvenientes de la replicación y las actualizaciones regulares propias del servicio WINS. En particular, se trata de crear una zona DNS especial llamada GlobalNames en la cual se incluyen todos los nombres para los que se quiere tener una resolución inmediata sin tener que buscar entre los distintos sufijos de dominio de búsqueda DNS. Es posible, por tanto, crear entradas tales como www, smtp, pop, proxy... que apunten a servidores bien conocidos o muy solicitados en el conjunto de la empresa. Estas entradas pueden ser registros de tipo A que indican, directamente, la dirección IP, o de tipo CNAME, es decir, un nombre completo que se resuelve de forma clásica. Para configurar la GNZ, los servidores DNS autoritarios deben ser, como mínimo, servidores Windows Server 2008. Sobre cada servidor DNS, active el modo GNZ utilizando el siguiente comando PowerShell:
Set-DnsServerGlobalNameZone -Enable:$true
Por defecto, la zona GlobalNames no debe aceptar las actualizaciones dinámicas. En cualquier caso, es algo que no se recomienda. Se aconseja crear una zona integrada con Active Directory con replicación a nivel del bosque o del dominio, según el ámbito deseado. add-dnsserverprimaryzone -name GlobalNames -ReplicationScope forest -DynamicUpdate None
Agregue los registros que desee por línea de comandos o a través de la interfaz gráfica. A continuación se muestra un ejemplo de cómo agregar un registro estático que apunta a un servidor Proxy. Add-DnsServerResourceRecordA -zone GlobalNames -name Proxy -IPv4address 172.16.1.5
Por defecto, la resolución local DNS se utiliza antes que la de la zona global, si fuera preciso utilice el siguiente comando para dar preferencia a la resolución de nombres a partir de la zona GlobalNames: set-DnsServerGlobalNameZone -GlobalOverLocal $true
Esta configuración sólo se aplica a nivel de los servidores DNS. El objetivo es centralizar la configuración. g. Pruebas y verificaciones
Existen diversas herramientas que permiten verificar el correcto funcionamiento de la resolución de nombres sobre los distintos dominios. La herramienta ping es la primera que se utiliza para realizar pruebas de resolución. Preste atención, el resultado de las pruebas puede verse alterado por el filtrado existente en los firewall intermedios o sobre los propios sistemas. Utilice ping con el nombre corto, el nombre completo (el nombre seguido del dominio DNS completo) y la dirección IP. Si se obtiene una respuesta con cada una de las pruebas, significa que todo funciona correctamente. En la prueba basada en la dirección IP, el argumento -a permite verificar también la resolución inversa. Si aparece el nombre completo SRVFIC01.MiEmpresa.Priv, significa que la resolución inversa funciona correctamente, incluso en el caso de que no responda a un ping. C:\Users\administrator.DOMINIOLOCAL>ping -a 172.16.1.184 Haciendo ping a con 32 bytes de Respuesta desde Respuesta desde Respuesta desde
SRVFIC01.MiEmpresa.Priv [172.16.1.184] datos: 172.16.1.184: bytes=32 tiempo<1ms TTL=128 172.16.1.184: bytes=32 tiempo<1ms TTL=128 172.16.1.184: bytes=32 tiempo<1ms TTL=128
Respuesta desde 172.16.1.184: bytes=32 tiempo<1ms TTL=128 Estadísticas de ping para 172.16.1.184: Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos), Tiempo aproximado de ida y vuelta en milisegundos: Mínimo = 0ms, Máximo = 0ms, Media = 0ms
La herramienta NsLookup permite consultar a los servidores DNS los distintos campos y registros de las zonas DNS accesibles. Los dos comandos, Tracert y PathPing, son equivalentes al ping, aunque muestran todas las etapas, las direcciones atravesadas y las duraciones de cada etapa. Existen, adicionalmente, otras herramientas como netsh, dnscmd y dcdiag que aumentan enormemente las posibilidades. Encontrará información complementaria acerca de la implementación de Active Directory en el capítulo Dominio Active Directory. h. Los distintos tipos de registro
SOA: el registro de tipo SOA se corresponde con una fuente de autoridad de la zona afectada. Todas las modificaciones en la zona incrementan el número de versión asociado a esta zona. NS: el registro NS contiene todos los servidores de nombres de servidores autorizados a responder en el dominio, A diferencia de los demás registros, los registros SOA y NS son únicos en cada zona. A: el registro A define la dirección IP asociada a un nombre de máquina concreto (llamado Host en inglés). CNAME: el registro CNAME crea un nombre (llamado Alias) en una zona, que podrá asociarse a un registro de tipo A en la misma zona o en otra zona DNS. MX: cada registro MX debe apuntar a un registro de tipo A en el que alguna máquina posea un servicio SMTP activo. Este registro resulta inútil para la mensajería interna basada en Exchange. Cuando existen varios registros de tipo MX, el peso (prioridad) más bajo asociado a cada uno de ellos indica el servidor de mensajería que debe utilizarse de forma prioritaria. SRV: el registro SRV sirve para indicar un servicio particular en un puerto específico. Los registros LDAP, Catálogo Global, Kerberos, SIP y otros utilizan este tipo de registros.
PTR: el registro PTR (Puntero) indica el nombre completo (FQDN) asociado a la dirección IP que se utiliza para la búsqueda. Sólo existe en las zonas de búsqueda inversa y no son indispensables en un entorno Microsoft. Existen otros tipos de registro, tales como el campo TXT, que se utilizan con menor frecuencia y son menos útiles para el funcionamiento de una red de equipos Windows. i. Buenas prácticas
En el marco de un bosque Active Directory, las buenas prácticas tratan de evitar la replicación inútil de la información y, por tanto, evitar el uso de zonas secundarias que son origen de muchos problemas. Las soluciones que se utilizan son las zonas de código auxiliar (stub zones) o las redirecciones condicionales. En los bosques y redes completas, la simplificación implica el uso de redirectores a nivel de cada subdominio hacia el dominio raíz de cada bosque. A nivel de cada dominio raíz de cada bosque, el uso de una redirección condicional hacia cada bosque bastará para resolver todo el bosque correspondiente. j. DNSSEC
A partir de Windows Server 2008 R2 y Windows Server 2012, es posible aumentar la fiabilidad de la información ofrecida y recibida por el servicio DNS. La condición principal para utilizad DNSSEC es disponer de, al menos, un servidor Windows Server 2008 R2 con el rol DNS instalado. El servidor no tiene por qué formar parte, necesariamente, de Active Directory. En cambio, si la zona DNS que se quiere firmar está integrada en Active Directory, entonces todos los servidores DNS del dominio o del bosque que gestionan esta zona DNS deben tener instalado, como mínimo, un sistema operativo Windows Server 2008 R2. DNSSEC permite autentificar la información DNS. Las zonas pueden firmarse digitalmente. Esta firma se envía a los clientes bajo la forma de registros de recursos desde los servidores que gestionan estas zonas. El cliente puede, a continuación, validar la información como auténtica desde los servidores DNS firmados. DNSSEC impide, así, ataques de tipo Man in the Middle que se basan, entre otros, en corromper los registros en caché de un servidor DNS para redirigir a los usuarios hacia direcciones IP controladas por el atacante. El número de DNSSEC de Windows 2008 estaba muy limitado y se basaba en tres tipos de registro: •
KEY: este registro contiene la clave pública indicada en la zona DNS del dominio.
Esta clave puede corresponderse con un servidor, la zona u otra entidad. Los registros KEY se autentifican mediante registros de tipo SIG. • •
NXT: este registro permite indicar el próximo registro firmado, si existe. SIG: este registro contiene la firma digital de una zona o parte de la zona para autentificar un recurso de un tipo concreto.
La implementación DNSSEC de Windows 2008 no permitía ni gestionar ni verificar la información transmitida. La norma utilizada actualmente por DNSSEC consiste en cuatro nuevos registros de recursos: • • • •
DNSKEY: registro de una clave DNSSEC. RRSIG: firma de los RR existentes con DNSSEC. NSEC: Next SEC, firma de los RR inexistentes con DNSSEC. DS: firma de las delegaciones de zona en DNSSEC.
Como con Windows Server 2008 R2, Windows Server 2012 puede no solo gestionar las zonas firmadas, sino también recibir información firmada, validarla y transmitirla a sus clientes. Sin embargo, DNSSEC puede configurarse de forma mucho más sencilla, directamente mediante la interfaz de administración gráfica. He aquí las distintas etapas a seguir para implementar DNSSEC: Verifique bien las condiciones de uso de DNSSEC en los puntos importantes que se indican al final del procedimiento. En este ejemplo, se dota de seguridad a una zona sencilla llamada MiEmpresa.es, estática y pública, que contiene dos registros MiSitioWeb (de tipo A) y www (de tipo CNAME). Preste atención, el procedimiento es el mismo tanto si la zona DNS se integra con Active Directory como si no. Sin embargo, la firma de la zona bloquea la zona, que ya no podremos transformar. La primera etapa consiste en autorizar DNSSEC sobre el servidor DNS. DNSSEC está autorizado por defecto en Windows Server 2012. He aquí el comando que permite verificar esto sobre el servidor DNS seleccionado: Get-DnsServer -Computername DC2012 | FindStr /I "Enablednssec" EnableDnsSec True
Si fuera necesario, utilice el siguiente comando de activación (por línea de comandos):
DnsCmd
/config /EnableDnsSec 1
Esta activación de DNSSEC se corresponde con la entrada Habilitar validación DNSSEC en las opciones avanzadas del servidor DNS.
Seleccione la zona que desea firmar y haga clic con el botón derecho para desplegar el menú que contiene la opción DNSSEC.
Seleccione la opción Firmar la zona y haga clic en Siguiente.
Configure y distribuya los puntos de validación de DNSSEC.
Configure la clave KSK.
Agregue una clave de tipo KSK haciendo clic en Agregar.
Modifique los parámetros del certificado.
Se recomienda seleccionar una encriptación de tipo NSEC3, que impide recorrer y descubrir toda la zona. La clave KSK se agrega a la lista, haga clic en Siguiente para continuar.
Haga clic en Agregar para crear una clave de zona.
Seleccione, de nuevo, el algoritmo NSEC3 y, a continuación, haga clic en Siguiente en la lista de claves de la zona.
Haga clic en Siguiente. Seleccione la distribución y la actualización de los anclajes de veracidad a nivel del dominio y, a continuación, haga clic en Siguiente.
Haga clic en Siguiente.
Haga clic en Siguiente para aprobar las modificaciones aportadas.
Haga clic en Finalizar.
Refresque la visualización haciendo pulsando la tecla [F5].
La zona MiEmpresa.es está, ahora, firmada. Si la zona no está integrada en Active Directory, o si los anclajes de veracidad no aparecen, es posible importar las claves DNSKEY desde el servidor DNS que ha servido para firmar la zona en todos los servidores DNS que pudieran necesitarlo. Seleccione el contenedor Puntos de confianza y, a continuación, Importar. Seleccione DNSKEY en la herramienta de administración DNS.
Indique el archivo Keyset correspondiente a la zona DNS deseada.
Verifique la integración de los certificados de tipo DNSKEY en la visualización de la herramienta de administración.
Preste atención, esta configuración no debe realizarse sobre el servidor primario, sino, únicamente, sobre los demás servidores DNS que reciban las consultas para esta zona. Si la zona está integrada y el servidor DNS es controlador de dominio, esta operación sólo debe realizarse una única vez para todo el bosque. Verifique que la resolución de la zona especial .trustanchors funciona para la zona que ha firmado mediante el siguiente comando PowerShell. resolve-dnsname -name MiEmpresa.Es.trustanchors -type dnskey -server dc2012
Name Type TTL Section Flags Key --------------- -----MiEmpresa.Es.trustanchors DNSKEY 3600 Answer 257 7 {3, 1, 0, 1...} MiEmpresa.Es.trustanchors DNSKEY 3600 Answer 257 7 {3, 1, 0, 1...}
Protocol Algorithm -------- ---------
-
DNSSEC
DNSSEC
Firmar una zona DNS integrada en Active Directory El procedimiento es muy similar al anterior. Durante la instalación, el asistente pregunta si el servidor DNS en curso debe convertirse en el maestro de claves. Seleccione el servidor que va a actualizar las claves de la zona.
La única diferencia es que los puntos de confianza aparecen de forma inmediata en el contenedor correspondiente.
Los nuevos registros creados en la zona están dotados, automáticamente, de una nueva clave. Configuración de servidores DNS integrados en Active Directory Idealmente, si los servidores DNS son controladores de dominio, las directivas se aplican directamente sobre la unidad organizativa de los controladores de dominio. Además, una unidad organizativa puede utilizarse para todos los servidores DNS miembros. Los certificados que utilizan los servidores DNS integrados en Active Directory pueden, también, entregarse de forma automática a través de una entidad emisora de certificados interna utilizando el modelo Directory Service Email Replication para crear una nueva plantilla que incluya el identificador del objeto 1.3.6.1.4.1.311.64.1.1. Se aplica una configuración particular para que el protocolo DNS pueda utilizarse de forma anónima y autentificada, con el objetivo de validar los certificados. Configuración de los clientes de DNSSEC Las estaciones o servidores miembros previstos para utilizar DNSSEC deben estar configurados para utilizar una NRPT (Name Resolution Policy Table), es decir, una tabla que incluye una directiva de resolución de nombres. Es posible crear una directiva de grupo para las máquinas miembros. Las demás se configuran directamente en las claves de registro. La directiva de grupo consiste en un conjunto de reglas que se aplican a la totalidad o a una parte de la zona correspondiente. Se puede configurar en Configuración del equipo Directivas - Configuración de Windows - Directiva de resolución de nombres.
Cada regla puede aplicarse a distintas partes (configuración de las distintas pestañas DNSSEC, Configuración DNS..., Servidor DNS genérico, Codificación) según los criterios de la siguiente tabla:
Con cada regla, haga clic en el botón Crear para agregarla a la tabla de la directiva.
He aquí las distintas reglas que pueden habilitarse mediante esta directiva: • • • • •
El prefijo se corresponde con el nombre de la máquina: MiSitioWeb. El sufijo se corresponde con el nombre del dominio: MiEmpresa.es. El nombre completo es la combinación del prefijo y del sufijo: MiSitioWeb.MiEmpresa.es. La subred (IPv4) con aspecto 172.16.1.1/16 permite securizar la búsqueda a partir de la dirección IP para la zona de búsqueda inversa: 16.172.in-addr.arpa. La subred (IPv6) realiza esta misma operación para IPv6.
Los botones Actualizar, Crear, Eliminar, y también Eliminar regla, Editar regla permiten agregar, modificar o eliminar el conjunto de reglas de la lista asociada a la directiva. El botón Configuración de directiva global avanzada permite acceder a las opciones complementarias que indican cómo debe funcionar la resolución de nombres DNS según la ubicación de red, los fallos que se produzcan en las consultas y la resolución de las mismas.
Para aquellas máquinas que no pertenezcan al dominio, es posible configurar la tabla NRPT en la directiva local. Si se desea, es posible elaborar un script manual para aplicar esta directiva. Basta, para ello, con exportar la clave HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicy-Config en un archivo NRPT.REG mediante la herramienta REGEDIT y, a continuación, aplicarlo mediante el comando REGEDIT /S NRPT.REG. Hay varios puntos importantes que cabe tener en cuenta a la hora de utilizar DNSSEC: •
Incluso si Windows Server 2012 incluye, ahora, una actualización (llamada RollOver) automática de los certificados para las zonas integradas en Active Directory, es posible, aunque no recomendable, habilitar las actualizaciones dinámicas sobre las zonas protegidas mediante DNSSEC.
Este tipo de zona la utilizarán, con mayor frecuencia, las raíces del bosque o las zonas que se accedan a través de Internet. • •
•
La renovación de claves: el uso de claves seguras mediante certificados supone configurar y verificar el mecanismo de renovación regular de claves. A diferencia de Windows Server 2008 R2, es posible agregar o eliminar registros en cualquier momento y ya no requiere firmar de nuevo la zona. No es necesario ningún certificado nuevo. La seguridad que provee DNSSEC sólo funciona con sistemas que tengan un cliente DNS compatible y con sistemas que ejecuten Windows 7, Windows Server 2008 R2 y versiones superiores.
k. Administración de DNS mediante PowerShell
PowerShell incluye numerosos comandos que permiten facilitar el conjunto de la administración del rol DNS. Utilice el siguiente comando para obtener la lista de todos los comandos posibles. Get-Command -Module DNSserver
Los comandos permiten crear, modificar y eliminar zonas, registros, así como configurar la práctica totalidad de los parámetros de un servidor DNS, incluido DNSSEC. He aquí la lista de comandos: DnsServer Add Set Get Remove X
X
Cache
X
X
Conditiona l X Forwarder Zone
X
Diagnostic s
X
Directory Partition
X
Expo Impo Clea Convert Enabl Disab Invoke rt rt r To e le X
X X
DnsSec PublicKey
X X
DnsSecZo ne Setting
X
X
DsSetting
X
X
EDns
X
X
X
X
Global NameZone
X
X
GlobalQueryBlockList
X
X
Forwarder
X
X
KeyStorageProvider Primary Zone
X
Recursion
X
ResourceRecord
X
ResourceRecordA
X
ResourceRecordAAAA
X
ResourceRecordAging
X X
X
X
ResourceRecordCName
X
ResourceRecordDnsKey
X
ResourceRecordDS
X
ResourceRecordM X
X
ResourceRecordPtr
X
RootHint
X
Scavengin g Secondary
X
X
X
X
X
X
X
X
X
X
X
Zone Setting SigningKe y
X
X
X
X
X
X
SigningKe y-Rollover
X
Statistics
X
StubZone
X
Trust Anchor
X
X X
Zone
X
Zone Delegation
X
X
X
X
TrustPoint ZoneAgin g
X
X
X
X
X
X
X
X
X
X
X
X
ZoneKeyMasterRol e ZoneSign
X
Zone Transfer Zone Unsign DnsServer
X Regist Res Restau Resu er et re me
Show Start
Suspen Syn Unregiste Updat Test d c r e X
Cache
X
Condition al Forwarder Zone Diagnosti cs Directory Partition
X
X
DnsSec PublicKey DnsSecZo
X
ne Setting DsSetting EDns Forwarder Global NameZon e GlobalQueryBlockList KeyStorageProvider Primary Zone Recursion ResourceRecord ResourceRecordA ResourceRecordAAAA ResourceRecordAging ResourceRecordCName ResourceRecordDnsKey ResourceRecordDS ResourceRecordM X ResourceRecordPtr RootHint
X X
Scavengin g
X
Secondary Zone
X
Setting SigningKe y SigningKe yRollover Statistics StubZone Trust Anchor TrustPoint
X
Zone
X
X
X
ZoneAgin g Zone Delegatio n ZoneKeyMasterRol e
X
ZoneSign Zone Transfer
X
Zone Unsign He aquí un enlace que le permite acceder a numerosos ejemplos de scripts PowerShell adaptados al rol DNS: http://gallery.technet.microsoft.com/scriptcenter/DNS-ServerPowerShell-afc2142b
l. Mejoras aportadas por la versión R2 de Windows 2012 Las estadísticas de DNS están mucho más detalladas: • •
El comando Get-DnsServerStatistics incluye una opción -ZoneName que permite obtener las estadísticas específicas de esta zona. A nivel del servidor, las estadísticas incluyen la siguiente lista de secciones:
CacheStatistics, DatabaseStatistics, DnssecStatistics, DsStatistics, ErrorStatistics, MasterStatistics, MemoryStatistics, NetBiosStatistics, PacketStatistics, PrivateStatistics, Query2Statistics, QueryStatistics, RecordStatistics, RecursionStatistics, SecondaryStatistics, SecurityStatistics, TimeoutStatistics, TimeStatistics, UpdateStatistics y WinsStatistics. El soporte de zonas protegidas mediante DNSSEC se ve mejorada: • •
El rol Key Master es, ahora, posible de configurar en las zonas multimaestro gestionadas en los archivos (no integradas en Active Directory). Por otro lado, todas las tareas de administración pueden realizarse en el servidor KeyMaster sin impactar a los demás DNS primarios que no son KeyMaster. Este aislamiento permite realizar todas las operaciones de generación de claves, almacenamiento, reemplazo y eliminación mientras que los demás servidores siguen firmados en la zona mediante estas claves.
Se han agregado o extendido algunos comandos PowerShell: • •
•
El comando Step-DnsServerSigningKeyRollover fuerza la renovación de KSK mientras se espera una actualización de una firma de delegación. Se ha agregado la opción -root al comando add-DnsServerTrustAnchor para recuperar los puntos de anclaje a partir de la URL indicada en la propiedad RootTrustAnchorsURL. Observe que el comando RetrieveDnsServerRootTrustAnchor es un alias. La propiedad RootTrustAnchorURL forma parte de los elementos devueltos por los comandos Get-DnsServerSetting y Set-DnsServerSetting.
2. La resolución WINS En teoría, esta resolución no debería utilizarse más, salvo para integrar dominios antiguos NT4. En la práctica, suele ser necesario (incluso muy práctico) para ciertas aplicaciones heredades (Microsoft o no), y también para aplicaciones recientes tales como Exchange 2007 (en casos muy particulares). Cuando se realiza una migración o cuando existe alguna duda sobre el funcionamiento de ciertas aplicaciones, es habitual mantener uno o dos servidores WINS en el sitio central. Las estaciones y servidores que utilizan este tipo de aplicación apuntarán, directamente, sobre este servidor WINS. De este modo, es inútil mantener y replicar los servidores WINS por toda la red.
a. Definición WINS (Windows Internet Name Service) es un servicio basado en una base de datos Jet que permite encontrar la dirección IP asociada a un nombre NetBIOS, y viceversa.
A diferencia de DNS, WINS mantiene información sobre los grupos de máquinas (llamados grupos de trabajo cuando los ordenadores no pertenecen a un dominio), y también sobre los usuarios conectados a dichas máquinas.
b. Instalación La instalación de WINS se realiza agregando la funcionalidad correspondiente desde PowerShell: Install-WindowsFeature WINS
En este caso, el componente de administración no se instala automáticamente y puede agregarse mediante el componente RSAT-WINS: Install-WindowsFeature RSAT-WINS
En cualquier caso, es posible, también, agregar todas estas funcionalidades mediante el Administrador del servidor.
c. Configuración Salvo en casos excepcionales en los que hay que informar manualmente un nombre (llamado estático) y una dirección IP, no es necesario configurar un servidor WINS, que recibe dinámicamente toda la información necesaria desde los servidores y clientes que se inscriben, de forma automática, en la base de datos. La única particularidad consiste en replicar la base de datos entre dos servidores WINS, o más, dependiendo del caso.
d. La replicación entre servidores WINS La replicación WINS se basa en dos operaciones: la emisión y la extracción. Para que una replicación WINS funcione en un sentido, es preciso que el servidor WINS esté configurado para emitir las modificaciones que recibe hacia otro servidor WINS, aunque también es necesario que el otro servidor WINS esté configurado para recuperar la información que proviene del servidor emisor en cuestión. Para que la replicación funcione bien en ambos sentidos entre dos servidores WINS, es preciso que cada servidor esté configurado como Emisión/Extracción con el servidor remoto.
e. ¿Cuándo y por qué utilizar WINS? Preste atención, ya no hay que ver a WINS como una solución de resolución completa. A día de hoy, DNS resulta imprescindible.
WINS es, simplemente, una solución que permite resolver problemas marginales de funcionamiento de las aplicaciones o de acceso que sería demasiado complejo resolver de otro modo. El caso más común es una aplicación que utilice, únicamente, nombres de servidores sencillos y relativamente cortos. Es el caso, por ejemplo, de algunas funcionalidades de Exchange. La instalación de un servicio WINS único, centralizado, que utilizarán únicamente algunas estaciones o servidores que tengan una verdadera necesidad del mismo responde perfectamente a este tipo de problemática.
Implementar la cuarentena de red La cuarentena de red no es una verdadera solución de seguridad, sino un elemento cuyo objetivo es mantener en un buen estado de mantenimiento los elementos presentes en la red. Este componente NAP (Network Access Protection) está, todavía, presente aunque debería considerarse como obsoleto a partir de Windows Server 2012 R2. Microsoft recomienda el uso de DirectAccess, que permite gestionar el equipo conectado "como" las demás máquinas de la red (AV, WSUS...). La solución aportada por DirectAccess es, por tanto, algo diferente al control de conformidad que proporciona el componente NAP.
1. Preparar el entorno común para los distintos tipos de cuarentena El uso del cliente NAP se basa en el uso de un servidor NPS (Network Policy Server), es decir, un servidor de directivas de red, que permite definir las restricciones deseadas. Es, por lo tanto, necesario instalar y configurar este rol a partir del comando PowerShell: Install-WindowsFeature NPAS-Policy-Server
La herramienta de administración Servidor NPS (Network Policy Server) no se instala automáticamente, y debemos agregarla. Install-WindowsFeature RSAT-NPAS
Una vez terminada la instalación, es necesario definir algunos puntos para las directivas funcionales: •
Un sistema de validación (SHV), es decir, pruebas que deben realizarse para verificar un sistema.
Windows Server 2008 R2 y Windows Server 2012 autorizan, ahora, varias configuraciones diferentes del sistema de validación. Una vez configurada la directiva de mantenimiento de la integridad del sistema, es posible seleccionar una de las configuraciones. Cada directiva de red puede configurarse para utilizar una o varias directivas de mantenimiento. •
• •
Un grupo de servidores de remedio: son los servidores que verán aquellas estaciones que no cumplan con la conformidad para poder actualizarse y cumplir con la política de seguridad configurada. Las directivas de mantenimiento, que se definen como SHVs, y serán interpretadas. Directivas de red.
Es posible descargar el kit de integración ForeFront for NAP (gratuito) para disponer de un sistema de validación complementario. Deben cargarse varios módulos en los equipos en función del tipo de procesador (32 o 64 bits), el módulo SHV sobre los servidores NPS, el módulo SHA sobre los clientes que se quiere validar (http://www.microsoft.com/enus/download/details.aspx?id=15887). La primera etapa consiste en definir las pruebas que se quieren realizar sobre los equipos que disponen de un cliente NAP, es decir, Windows XP SP3, Windows Vista o superior. En la consola de administración del servidor NPS, NAP, seleccione el contenedor SHV. Configure, a continuación, el sistema de validación provisto por defecto llamado Validador de mantenimiento de seguridad de Windows y, a continuación, haga clic en Configuración. El contenedor Configuración contiene una configuración llamada Configuración predeterminada que podemos utilizar. Es posible, también, definir nuevas configuraciones. En el contenedor Códigos de error, se asume que si los programas de validación de integridad no responden o no pueden responder, el cliente se clasificará como No compatible. Aunque, para cada situación, es posible adaptar su estado mediante el menú Propiedades de la carpeta Códigos de error. Seleccione la configuración que desea personalizar y haga doble clic para acceder a las distintas propiedades que se comprobarán. Observe que existe una pestaña para Windows XP y otra para Windows Vista y versiones superiores. En el marco de esta implementación de prueba, utilizaremos una configuración simplificada basada en la existencia de un firewall.
La segunda etapa consiste en definir un grupo que contenga los servidores autorizados para configurar la conformidad con las normas definidas en los grupos de servidores de actualizaciones.
Las máquinas no conformes pueden conectarse con los servidores indicados si están autorizadas las actualizaciones automáticas (que sirven como remedio) en la directiva de red. La tercera etapa consiste en crear al menos dos directivas de mantenimiento diferentes en las directivas de mantenimiento. Una para los equipos conformes: Sólo aquellos validadores habilitados, es decir, los programas de mantenimiento instalados y activos, forman parte de la regla de conformidad.
Si se crean varias configuraciones, seleccione aquella configuración que le interesa, entre las propuestas y configuradas anteriormente. Haga clic en Aceptar para terminar con esta primera directiva. Una para los equipos no conformes: Seleccione el mismo validador que para una máquina conforme, pero defina la regla como El cliente no supera ninguna de las comprobaciones de SHV.
La cuarta etapa consiste en la creación de directivas de red. Creación de la directiva de red para los equipos conformes: Haga clic con el botón derecho en Directivas de red y, a continuación, en Nuevo en el menú. Llame a la directiva Acceso completo para los equipos conformes, y deje el tipo de red como No especificada. No especificada significa que la directiva se aplicará sea cual sea el tipo de acceso de red utilizado. En la pantalla Especificar condiciones, es obligatorio precisar sobre qué elementos se aplicará la directiva, haga clic en Agregar. Es posible aplicar múltiples condiciones, seleccione Directivas de manteni-miento.
Seleccione, en la lista, la opción Equipo conforme, y pase a la siguiente pantalla. Indique Acceso concedido, ¡lo cual resulta evidente para las máquinas conformes! No se requiere ninguna autenticación para este tipo de cuarentena, seleccione la opción Realizar sólo comprobación de mantenimiento del equipo.
En la pantalla Configurar restricciones, no hay que modificar ningún valor. En la pantalla Configurar opciones, se trata de aplicar una configuración (modificación) del cliente de red. Aquí, en la sección NAP, se conserva el valor Permitir acceso completo a la red. Haga clic en Finalizar en la pantalla final que resume los valores de la directiva. Creación de la directiva de red para los equipos no conformes: Haga clic con el botón derecho en Directivas de red y, a continuación, seleccione Nueva en el menú.
Llame a la directiva Acceso completo para los equipos no conformes, deje el tipo de red en No especificada como hizo con las máquinas conformes. En la pantalla Especificar condiciones, debe precisar sobre qué equipos se aplica esta directiva, haga clic en Agregar. Es posible aplicar numerosas condiciones, seleccione Directivas de mantenimiento y, a continuación, seleccione la directiva Máquina no conforme de la lista. Pase a la siguiente pantalla. Indique Acceso concedido. En efecto, incluso para aquellas máquinas no conformes, se trata de una regla que va a autorizar un acceso a la red, ¡aunque sólo a aquellos elementos autorizados! No se requiere ninguna autenticación para este tipo de cuarentena, seleccione Realizar sólo comprobación de mantenimiento del equipo como con las máquinas conformes. En la pantalla Configurar restricciones, no modifique ningún valor. En la pantalla Configurar opciones, se trata de aplicar una configuración (modificación) del cliente de red. Aquí, en la sección NAP, seleccione Permitir acceso limitado.
La opción Permitir acceso limitado no debe aplicarse si no estamos seguros de los efectos de la directiva. Es, a menudo, preferible autorizar un acceso completo en primer lugar y utilizar el modo informe para hacerse una idea del conjunto de equipos que se verán impactados. Si queremos autorizar las actualizaciones automáticas (y, por tanto, habilitar los servidores de conformidad), debemos marcar la opción Habilitar corrección automática de equipos cliente.
Haga clic en Configurar para especificar un Grupo de servidores de actualizaciones así como la dirección de una página Web opcional que le dé instrucciones al usuario.
En los clientes restantes, cada servidor indicado en el grupo dispone de su propia ruta con una máscara 255.255.255.255. Lógicamente, los demás servidores no están accesibles. Haga clic en Finalizar en la pantalla final que resume el conjunto de parámetros de la directiva.
Observe que, según el reparto de roles en los distintos servidores autorizados, las actualizaciones automáticas pueden requerir un acceso completo. El cliente Agente de Protección de acceso a redes debe estar habilitado sobre los puestos cliente, es decir, el servicio debe estar configurado con arranque automático. El Centro de seguridad debe estar habilitado, algo que puede llevarse a cabo mediante una directiva. La consola del cliente NAP (NAPCLCFG.MSC) permite verificar las restricciones impuestas. El comando Napstat permite verificar la conformidad respecto a las reglas establecidas.
2. Implementar NAP mediante DHCP Una vez realizadas las preparaciones previas descritas anteriormente, quedan pocas etapas para que NAP funcione sobre DHCP. El ámbito DHCP debe, en primer lugar, estar habilitado para utilizar la seguridad basada en NAP. En las propiedades del ámbito, encontrará la pestaña Protección de acceso a redes.
Las máquinas que cumplen con los requisitos previos utilizan las opciones que ha configurado en las Opciones estándar de DHCP (Clase de proveedor), para la Clase de usuario predeterminada. El perfil predeterminado de protección de acceso a redes se corresponde con la clase de usuario Clase de protección de acceso a red predeterminada que está accesible en la configuración avanzada de las propiedades del ámbito. Las máquinas no conformes utilizarán las opciones definidas a nivel de esta clase. Sólo es necesario definir las opciones deseadas, por ejemplo:
• • •
Un servidor DNS específico o que no permita alcanzar o resolver ciertos nombres. Una zona DNS ficticia o no, pero específica para identificar rápidamente las máquinas no conformes. No informar ningún router, para impedir a la máquina acceder a secciones de la red que se desean proteger.
Aparecen las opciones concretas con una clase de red específica. Ahora, podemos habilitar la directiva de cuarentena de DHCP, bien utilizando una directiva, o bien directamente en la herramienta de administración del cliente NAP que podemos abrir mediante el comando NAPCLCFG.MSC.
En caso de que se detenga el servicio de Firewall de Windows, la estación de trabajo no estará conforme con las reglas definidas. Si están autorizadas las actualizaciones automáticas, y el servidor de resolución de problemas es accesible, las reparaciones se realizan de manera inmediata. En nuestro caso, el reinicio inmediato del servicio Firewall permite devolver a la máquina a la conformidad.
Utilice el comando napstat.exe para verificar el estado de conformidad de las estaciones respecto a las directivas en uso. Existe un icono situado en el área de notificación que permanece ahí hasta que cerremos la herramienta. La cuarentena de red basada en DHCP es la más débil de las protecciones posibles, y es fácilmente eludible por parte de cualquier usuario que tenga permisos de administrador local sobre su equipo.
3. Implementación de NAP mediante IPsec a. Instalación del servicio Autoridad HRA
Esta seguridad requiere la instalación del servicio Autoridad HRA (Health Registration Authority) a través del siguiente comando PowerShell: Install-WindowsFeature NPAS-Health
Es preciso instalar una entidad emisora de certificados de tipo Entreprise si no existe ningún otro sistema de distribución de claves (PKI). El uso del rol Microsoft correspondiente simplifica enormemente la tarea. Se recomienda encarecidamente utilizar la interfaz gráfica y, a continuación, utilizar el asistente de creación del certificado raíz. Para limitar la aplicación de la cuarentena de red basada en IPsec, es prudente crear grupos de equipos para cada categoría. • •
•
Equipos clientes de NAP IPsec: es decir, todas aquellas estaciones que deban cumplir con las normas de seguridad (CLIENTES-NAP). Aquellos servidores llamados "de frontera" (Boundary) que reciben, automáticamente, un certificado de salud y que sirven para autentificar a los clientes. Los controladores de dominio, los servidores DNS y los servidores de reparación deben formar parte de este grupo (SERVIDORES-FRONTERA). Los equipos protegidos por NAP IPsec: reciben, también, automáticamente un certificado y sólo autorizan la conexión desde las máquinas autentificadas (SERVIDORES-NAP).
Cada máquina (estación o servidor) debe poder recibir un certificado. Ahora bien, el certificado emitido por defecto a las estaciones no contiene la directiva de autenticación adecuada. Cree un nuevo certificado Autenticación de estación de trabajo duplicando el modelo existente a partir de la consola de Plantillas de certificado que podemos abrir directamente mediante el comando certtmpl.msc. Tras la duplicación, seleccione la compatibilidad Windows 2003 o Windows 2008. En cualquier caso, es necesario disponer de una entidad emisora de certificados de tipo Enterprise para que la distribución de certificados sea automática.
Aproveche para modificar algunos parámetros, tales como la duración de la validez de los certificados. Dé nombre al certificado, modifique el periodo de validez y publíquelo en Active Directory.
Los servidores implicados en la validación tienen, efectivamente, un certificado válido durante dos años. En cambio, los equipos que soliciten la validación obtendrán un certificado con un tiempo de vida de cuatro horas. En la pestaña Extensiones, seleccione Directivas de aplicación y agregue la directiva Autenticación del agente SHA (System Health).
En la pestaña Seguridad, agregue los grupos de servidores de tipo frontera y los servidores protegidos, y asigne los permisos Inscribirse e Inscripción automática.
En la consola Entidad emisora de certificados, en el contenedor de las plantillas de certificado, haga clic con el botón derecho y seleccione Plantilla de certificado que se va a emitir y, a continuación, la plantilla Autenticación de sistemas sanos. Como la validación de los clientes requiere, de manera regular, certificados de buena salud, es importante verificar que el módulo de directiva (sobre el certificado raíz) esté configurado a Emitir certificado automáticamente. Los clientes deben configurarse para solicitar automáticamente los certificados. En la herramienta GPMC (Administración de directivas de grupo), configure la petición de certificados automática en la Default Domain Policy. Este parámetro se encuentra en la sección Configuración de Windows - Configuración de seguridad - Directivas de clave pública. Haga clic con el botón derecho en Configuración del equipo - Configuración de Windows - Configuración de seguridad - Directivas de clave pública - Configuración
de la solicitud de certificados automática - en la directiva Cliente de servicios de servidor de certificados - Inscripción automática.
Los parámetros de inscripción y renovación automática están habilitados por defecto en las Propiedades. La cuenta SERVICIO DE RED (si la CA y la HRA se encuentran en la misma máquina) o el equipo sobre el que se encuentra instalado el sistema de validación (HRA) deben obtener los siguientes permisos:
El siguiente comando permite al sistema validador solicitar los certificados con una duración distinta a la validez de dos años definida e impuesta en el modelo. certutil -setreg policy\editflags +EditF_attributeEndDate
b. Configuración del sistema de validación (HRA)
En el menú Inicio, busque y ejecute la herramienta Autoridad HRA. Es posible, también, abrir una consola MMC y agregar el componente Autoridad HRA (Health Registration Authority). Agregue la entidad emisora de certificados a partir de Active Directory. Modifique las propiedades de la entidad emisora de certificados, en particular para validar la entidad emisora de certificados de la empresa, y las plantillas de certificado que se van a utilizar.
En la herramienta de administración NPS, debe estar deshabilitada la reparación automática. Esto puede configurarse en los parámetros del validador de mantenimiento del sistema dentro de la configuración por defecto. La opción Configuración de Actualizaciones automáticas debe estar desmarcada. En el puesto cliente, para habilitar IPsec, es necesario hacerlo desde la línea de comandos mediante la siguiente instrucción: netsh nap client set enforcement ID =79619
Cada cumplimiento (Enforcement) dispone de un identificador específico: • • • • •
DHCP = 79617 RAS = 79618 IPsec = 79619 TS Gateway = 79621 EAP = 79623
Observe que si el equipo no está conforme, el certificado que reciba se verá invalidado inmediatamente sin esperar las cuatro horas.
De momento, no se impone ningún cumplimiento salvo el hecho de disponer de un certificado. Estos cumplimientos los aportan tres directivas basadas en los grupos de seguridad creados al principio. c. Definición de las reglas de seguridad de conexión
Estas directivas pueden definirse en la raíz del dominio siempre que se implemente un filtrado sobre los grupos de seguridad. Los servidores frontera deben solicitar, pero no imponer, certificados válidos. Los servidores protegidos y los puestos cliente deben utilizar certificados, aunque es preferible utilizar directivas diferentes para asociar una configuración específica para los clientes (URL de configuración HRA). He aquí la directiva que debe implementar sobre los servidores frontera (Boundary): En Configuración del equipo - Directivas - Configuración de Windows Configuración de seguridad - Firewall de Windows con seguridad avanzada - Firewall de Windows con seguridad avanzada - LDAP... cree una nueva regla de seguridad en Reglas de seguridad de conexión, y seleccione Aislamiento.
Seleccione Solicitar autenticación para conexiones entrantes y salientes y, a continuación, el método de autenticación modo avanzado.
Haga clic en Personalizar. Haga clic en Agregar en la sección Primera autenticación.
Seleccione el modo Certificado de equipo y, a continuación, Examinar para indicar su entidad emisora de certificados. Haga clic en Aceptar solo certificados de mantenimiento.
Haga clic en Aceptar para terminar de personalizar los modos de autenticación y, a continuación, en Siguiente. Deje marcados todos los perfiles que se aplicarán: Dominio, Privado, Público. Dé nombre a la regla REGLA NAP IPSEC Frontera. En la pestaña Ámbito de la directiva, agregue un filtrado de seguridad para el grupo Servidores IPSEC de Frontera (SERVIDORES-FRONTERA) y elimine el grupo por defecto Usuarios autenticados. He aquí la nueva directiva que debe implementarse en los clientes y los servidores protegidos. Aunque la configuración sea idéntica, cree dos directivas independientes para poder habilitar y modificar la configuración según las necesidades. Utilice el mismo procedimiento que con los servidores frontera, seleccionando la opción Requerir autenticación para las conexiones entrantes y solicitar autenticación para las conexiones salientes, en lugar de Solicitar.
Indique su entidad emisora de certificados de dominio, y marque la opción Sólo aceptar certificados de mantenimiento. Deje marcados todos los perfiles que se aplicarán: Dominio, Privado, Público. Dé nombre a esta regla REGLA NAP IPSEC Client. En la pestaña Ámbito de la directiva, agregue un filtrado de seguridad para el grupo Clientes IPSEC (CLIENTES-NAP). Se creará una directiva idéntica para los servidores que se quieren proteger. Utilizando la instrucción ping -t sobre un servidor frontera o un servidor protegido, será posible verificar la autenticación por certificado mediante la herramienta Firewall de Windows con seguridad avanzada. Se utiliza una asociación de seguridad basada en los certificados para llevar a cabo la comunicación.
Efectivamente, esta es tan solo una posibilidad de implementación de seguridad basada en la cuarentena de IPsec. Sería prudente maquetar el conjunto de la red antes de implementar dichos cambios sobre una red en producción. Preste atención, el hecho de imponer una autenticación hace que no sea posible conectarse con máquinas que no tengan un certificado válido o que no cumplan la directiva de seguridad para los sistemas conformes.
4. Implementar NAP sobre 802.1x 802.1X estaba, hasta el momento, reservado principalmente a los puntos de acceso inalámbricos. Actualmente, NAP permite, también, utilizar fácilmente esta autenticación directamente sobre la red local. Esta implementación supone el uso de RADIUS para procesar la solicitud, y la creación de una VLAN específica mediante un switch que acepte VLAN.
Son necesarios, por tanto, tres elementos: • • •
un servidor de autenticación; un agente de autenticación (switch o punto de acceso inalámbrico) ; el solicitante.
El cliente solicitante utiliza el protocolo EAP (EAP over LAN) para enviar la solicitud al agente de autenticación (Pass-Through). El agente Pass-Through puede, a continuación, consultar al servidor RADIUS para validar o no la conexión. A partir de Windows Server 2008/2008 R2/2012, el servidor NPS remplaza la tecnología IAS, aunque sigue utilizando el protocolo RADIUS para comunicarse. Si los clientes cumplen con la conformidad relativa a la seguridad demandada, se les asigna una VLAN específica o un filtrado por IP. a) Configuración del switch (o punto de acceso): He aquí la configuración de las distintas VLAN que deben configurarse en el switch (o punto de acceso) para llevar a cabo nuestro ejemplo: • • •
VLAN ID 1 es la VLAN por defecto. VLAN ID 2 para las máquinas que no cumplen con la conformidad. VLAN ID 3 para las máquinas conformes.
Es necesario deshabilitar la comunicación inter-VLAN entre las VLAN 2 y 3. Los puertos del switch utilizados para conectar el servidor NPS y los controladores de dominio deben configurarse para no imponer la autenticación 802.1X. Todas las solicitudes de autenticación del switch deben redirigirse hacia el servidor NPS. b) En el bosque Active Directory, será preciso tener una entidad emisora de certificados raíz de tipo Enterprise. El servidor NPS debe haber recibido un certificado de equipo y el certificado raíz deberá agregarse a las principales entidades de confianza en todas las máquinas. Es posible crear un grupo de seguridad específico llamado Clientes NAP 802.1X para los clientes NAP 802.1X, con el objetivo de restringir la aplicación de las directivas en las máquinas que pertenezcan a este grupo. La mayoría de elementos (Controladores de dominio, Servidor NPS, Entidad emisora de certificados, Administración de directivas de grupo) pueden instalarse sobre el mismo servidor, lo cual nos simplificará en gran medida la configuración de las pruebas. Si los sistemas de cuarentena anteriores se han probado con éxito, todos los elementos necesarios se encuentran ya instalados. En cambio, será preferible, en primer lugar, eliminar o deshabilitar las directivas de grupo y las directivas de red que ya estén configuradas.
c) Configuración del servidor NPS como servidor de directivas de mantenimiento (Health Policy Server): Lo más sencillo es utilizar el asistente de configuración de NAP. A partir de la raíz (NPS Local): Haga clic en Configurar NAP en la sección Configuración estándar. En Método de conexión de red, seleccione IEE 802.1X (cableada). En los Clientes RADIUS, agregue la dirección IP o los switch RADIUS, así como el secreto compartido que utilizará el cliente RADIUS. En la pantalla Grupos de equipos y usuarios, no indique nada. En lo relativo al método de autenticación, haga clic en Seleccionar, seleccione el certificado (válido) emitido por el servidor que hospeda NPS y valide el modo PEAP-MSCHAP v2. A continuación, debe configurar las dos redes locales virtuales (VLAN) tal y como se indica a continuación, haciendo clic en Configurar. La VLAN de la red de organización que se obtiene modificando el atributo estándar:
Debe agregarse un atributo (tag) específico:
La VLAN de la red restringida:
El atributo indicado Tunnel-Tag debe tener el valor 1. En Definir directivas de mantenimiento de NAP, seleccione el sistema de validación deseado, es decir, Validador de mantenimiento de seguridad de Windows, en nuestro caso.
Por defecto, el acceso completo a la red no está permitido para aquellos clientes no conformes. Todas las directivas se crean en la pantalla final haciendo clic en Finalizar.
d) Una vez finalizada la configuración a través del asistente, es interesante verificar cada parámetro. • • • •
Para realizar pruebas, el validador de mantenimiento de seguridad de Windows está configurado para verificar únicamente el arranque del servicio de firewall. Las directivas de control de integridad (definir los validadores a utilizar). Las directivas de solicitud de conexión (verifique el orden de ejecución, observe que la directiva NAP 802.1X sólo se aplica a conexiones de tipo Ethernet). Las directivas de red y, en particular, la directiva NAP 802.1X (cableada) No compatible con NAP.
En efecto, tras la implementación de directivas de red, es primordial considerar la existencia de máquinas Unix, Linux, Mac u otros, que no serán compatibles con NAP. Estas máquinas deben seguir funcionando y comunicándose en la red, bien a partir de exclusiones, o bien a partir de reglas específicas.
e) Para aquellos clientes NAP declarados como conformes, es necesario que los clientes tengan la configuración adaptada. Para las máquinas integradas en el dominio, es lógico utilizar directivas de grupo para forzar su correcta configuración. He aquí los principales puntos de esta directiva: Inicie automáticamente el servicio Agente de protección de acceso a redes. Inicie automáticamente el servicio de Configuración automática de redes cableadas. Habilite el Cliente de aplicación de cuarentena de EAP en la sección Configuración de Windows- Configuración de seguridad - Protección de acceso a redes - Configuración del cliente NAP - Clientes de cumplimiento. Todos estos elementos pueden configurarse y automatizarse mediante una directiva. Habilite el Centro de seguridad (solo equipos de dominio). En Directivas de red cableada (IEEE 802.3), cree una directiva de red cableada con la siguiente configuración:
Haga clic en Propiedades y deje la opción Verificar la identidad del servidor validando el certificado marcada, así como el método de autenticación EAP-MSCHAP versión 2 por defecto.
Desmarque la opción Habilitar reconexión rápida. Marque la opción Aplicar Protección de acceso a redes. Si queremos restringir esta directiva a un grupo de equipos concreto, retire el grupo Usuarios autenticados en la sección Filtro de seguridad y agregue el grupo Clientes NAP 802.1X que se ha creado al principio del procedimiento. El botón Opciones avanzadas, en la pestaña Seguridad, permite acceder a una configuración avanzada de 802.1X.
Preste atención, ¡no olvide integrar los clientes en este grupo! Observe que estos parámetros pueden también configurarse de manera manual en el equipo de trabajo, a condición de iniciar manualmente todos los servicios indicados en la directiva.
5. Conclusión He aquí los resultados obtenidos con los distintos tipos de cuarentena. Reglas
Cliente correcto
Cliente incorrecto
DHCP Dirección IP completa y acceso Rutas restringidas. completo. 802.1X Acceso completo. IPsec
Acceso a la VLAN restringida o a los puertos autorizados.
Comunicación con cualquier Los elementos de confianza rechazan las elemento de confianza. conexiones de sistemas no seguros.
La mejor seguridad es la que aporta 802.1X, seguida de la que ofrece IPsec, siendo DHCP una barrera fácilmente franqueable. En cualquier caso, la cuarentena de red no supone una seguridad absoluta, aunque mejora enormemente la seguridad global favoreciendo la uniformidad a nivel del conjunto de la red. Existen otros tipos de cuarentena, aunque no se aplican a la totalidad de la red: se trata de la cuarentena VPN, Acceso Remoto o Escritorio remoto. Una de las principales restricciones ligadas al uso de la cuarentena consiste en utilizar Windows XP SP3, Windows Vista, o superior, e iniciar los servicios de protección de red necesarios. No obstante, es importante destacar que existen numerosos fabricantes que ofrecen productos compatibles con NAP y existen, en particular, clientes NAP para Linux y Mac.
La consola IPAM La instalación de la funcionalidad IPAM (IP Address Management) tiene como objetivo centralizar la administración del direccionamiento IP utilizando por el conjunto de elementos dependientes de la infraestructura de red de Microsoft. La herramienta está basada en una base de datos que permite administrar el descubrimiento, la supervisión y la auditoría del direccionamiento. Esta base de datos conserva y registra la información durante 3 años a partir de criterios tales como las direcciones IP, los nombres de las máquinas o de los usuarios. A partir de esta información centralizada y agregada, la consola permitirá modificar la configuración DNS, DHCP de manera remota teniendo en cuenta todos los elementos necesarios. Las funcionalidades que se tienen en cuenta son: • • •
DHCP DNS NPS
Esta consola no puede instalarse sobre un controlador de dominio. En cambio, sí es posible instalar la consola de administración remota de IPAM sobre un controlador de dominio.
1. Ventajas de esta solución Supervisar y administrar el direccionamiento IP sobre una red de empresa es un elemento crítico en la administración de la red, conforme ésta se va haciendo más grande y compleja. Muchos administradores utilizan, todavía, tablas o bases de datos personalizadas para realizar un seguimiento manual del lugar y el uso de las direcciones IP. Generalmente, esto
consume bastante tiempo y suele producir errores de tipo humano. El servidor IPAM es una herramienta que trata de dar solución, precisamente, a esta necesidad. •
•
• •
En términos de planificación, IPAM remplaza herramientas manuales y scripts. Permite evitar análisis costosos durante las expansiones o modificaciones del nivel de actividad, o durante cambios de configuración o de tecnología. IPAM provee una plataforma de gestión única para la administración de las direcciones IP de la red. Permite optimizar el uso y las capacidades de los servicios DHCP y DNS en un entorno multi-sitio. IPAM permite trazar y prever el uso del conjunto de direcciones IP utilizadas. El análisis de la tendencia general permitirá prever mejor ciertos incidentes. La auditoría realizada por IPAM ayuda a cubrir ciertas exigencias legales asociadas a leyes tales como HIPAA y Sarbanes-Oxley, y provee informes que permiten investigar y gestionar los cambios.
2. La arquitectura IPAM Según el tamaño de la empresa y sus necesidades, el despliegue puede ser distribuido (un servidor IPAM por sitio) o centralizado (un único servidor para toda la empresa), o incluso una combinación de ambos. El límite de cobertura de un servidor IPAM es el bosque del que forma parte. Cada servidor IPAM se configura para administrar un ámbito específico. El ámbito puede ser un dominio, un sitio y puede también limitarse a una lista filtrada de servidores administrados. Un servidor IPAM puede, también, definirse en la copia de seguridad. IPAM se comunica de manera regular con los controladores de dominio, los servidores DNS y DHCP de la red que están en su dominio de cobertura. ¡Cada servidor debería definirse como administrado o no administrado! Para que un servidor pueda ser administrado por IPAM, es necesario configurar la seguridad sobre dicho servidor, de modo que el servidor IPAM pueda realizar la supervisión y modificar la configuración si fuera necesario. Las directivas de grupo son, por tanto, la herramienta ideal para automatizar esta configuración según si el servidor está administrado o no. He aquí los protocolos que se utilizan según los servicios solicitados: Protocolos de acceso IPAM Server
Servicios
RPC WMI SMB
WS-Mgmt
DHCP
RPC WMI
WS-Mgmt
DNS
RPC WMI LDAP
Controladores de dominio
RPC
NPS
3. Instalación Como con los demás elementos, la instalación puede hacerse de forma gráfica o mediante comandos PowerShell. Seleccione la funcionalidad Servidor de administración de direcciones IP (IPAM).
Valide la lista de las demás funcionalidades necesarias haciendo clic en Agregar características.
Observe que se necesita la base de datos interna de Windows para la primera instalación. IPAM para Windows Server 2012 R2 soporta la migración de MS SQL, aunque no lo propone, por defecto, durante su instalación. La migración se describe al final del módulo. Haga clic en Siguiente.
Haga clic en Instalar.
Instale la consola sobre otro servidor 2012 reservado para la administración o sobre el controlador de dominio. Si el componente IPAM se instala sobre un servidor, el componente se muestra en el administrador del servidor, aunque sólo puede utilizarse si el cliente de gestión IPAM está instalado. He aquí el comando que debe utilizar en este caso: Install-WindowsFeature IPAM-Client-Feature
4. Configuración inicial Acceda a la consola de administración, desde el administrador del servidor, que contiene la herramienta IPAM/Información general.
La configuración se realiza en seis etapas. Haga clic en Conectar con servidor IPAM (etapa número 1 del asistente). Seleccione el servidor IPAM deseado y haga clic en Aceptar:
Haga clic en Aprovisionar el servidor IPAM (etapa número 2 del asistente) y, a continuación, en Siguiente.
Seleccione la configuración básica que desea.
Seleccione el modo Microsoft SQL Server y, a continuación, indique: • • • •
el nombre del servidor SQL el nombre de la base de datos SQL el puerto 1433 y si es necesario crear el esquema en la base de datos.
A continuación, valide haciendo clic en Siguiente. Observe que, utilizando la base de datos Interna, ahora es posible cambiar la ubicación de dicha base de datos. Configure la cuenta de acceso a SQL.
Para que el acceso y la creación de la base de datos se realicen correctamente, verifique bien los siguientes puntos: • •
El firewall debe autorizar la conexión sobre el puerto SQL (1433). El servidor IPAM debe tener permisos para conectarse.
La solución más sencilla consiste en crear un grupo de ACCESO_IPAM_SQL que contenga al servidor IPAM en Active Directory y, a continuación, crear un login en SQL para dicho grupo. Asigne, a continuación, el rol DbCreator a dicho login. Seleccione el método de aprovisionamiento por directiva de grupo e indique el prefijo seleccionado.
Observe el comando que tendrá que ejecutar mediante PowerShell: Invoke-IpamGpoProvisioning Si no utiliza las directivas de grupo propuestas, deberá configurar manualmente los recursos compartidos, las reglas de firewall y los grupos de seguridad necesarios. Haga clic en Aplicar para confirmar los parámetros.
Haga clic en Cerrar.
Cree las directivas mediante el comando Invoke-IpamGpoProvisioning. Invoke-IpamGpoProvisioning -Domain MiEmpresa.Priv -GpoPrefixName IPAM -force
¡Es importante especificar el mismo prefijo de dominio que el que ha indicado en el asistente! Las directivas se crean en la raíz del dominio correspondiente. Se aplican, por tanto, a todos los servidores DNS, DHCP y DC (para acceder a la configuración de NPS) del dominio. Idealmente, es posible desplazar la aplicación de dichas directivas sobre las unidades organizativas que contengan únicamente los servidores correspondientes. No hay que olvidar que los controladores de dominio pertenecen a un contenedor específico. Haga clic en la etapa siguiente en Configurar detección de servidores (etapa número 3 del asistente).
Haga clic en Agregar sobre cada dominio que quiera administrar y, a continuación, valide haciendo clic en Aceptar. Seleccione aquellos roles que desea descubrir. Por defecto, los tres roles (DNS, DHCP, Controladores de dominio) están seleccionados, lo cual resulta aconsejable. Haga clic en Aceptar.
Haga clic en Iniciar detección de servidores (etapa número 4 del asistente).
La ejecución de la tarea aparece hasta el final de la ejecución. El tráfico no será importante en un primer momento, puesto que se trata de consultas LDAP en el directorio.
Haga clic en Seleccionar o agregar servidores para administrar y comprobar el acceso de IPAM (etapa número 5 del asistente).
Es preciso definir el estado de gestión de cada servidor, es decir, si se desea administrarlo o no. Es importante considerar bien la acción recomendada especificada junto a cada servidor. Seleccione el servidor o los servidores que desea configurar y, a continuación, haga clic con el botón derecho para desplegar el siguiente menú contextual:
Haga clic en Editar servidor para obtener la siguiente pantalla:
Seleccione el modo Administrado y, a continuación, haga clic en Aceptar. El retardo en el estado de la comunicación entre cada servidor y el servidor IPAM aparece en la parte inferior de la página.
Existen varios elementos que podrían impedir una correcta comunicación sobre todos o parte de los modos de acceso necesarios. Las directivas anteriores tienen como objetivo autorizar IPAM a acceder a los servidores que posean los roles administrados. Fuerce la aplicación de las directivas IPAM en cada servidor DC, DHCP o DNS mediante el comando GPUPDATE /FORCE. Reinicie los servicios DHCP y DNS. A continuación, utilice la opción Actualizar el estado de acceso del servidor. Si todo va bien, el servidor pasa al estado desbloqueado (icono verde).
Cada uno de los componentes debería pasar al estado desbloqueado:
Puede ocurrir, generalmente en Windows Server 2008 R2, que el acceso al servicio DHCP se mantenga bloqueado. En este caso, verifique que el recurso compartido DHCPAUDIT está creado correctamente en la carpeta C:\Windows\system32\ dhcp. Haga clic en Recuperar datos de servidores administrados (etapa número 6 del asistente). Ahora, todas las funcionalidades IPAM se encuentran habilitadas.
5. Grupos utilizados por IPAM Los siguientes grupos de seguridad se crean en la base de datos local de cuentas del servidor IPAM:
•
•
•
•
•
Usuarios IPAM: los miembros de este grupo pueden ver toda la información disponible en el inventario de servidores, el espacio de direccionamiento IP y el análisis de la gestión de la consola IPAM así como los eventos operacionales IPAM y DHCP que forman parte del catálogo de eventos, aunque no consultar la información de seguimiento de las direcciones IP. Administradores IPAM MSM: los miembros del grupo Administradores MSM (Multi-Server Management, gestión multiservidor) tienen los mismos permisos que los usuarios IPAM y, además, pueden realizar tareas de gestión IPAM corrientes y tareas de análisis y de administración. Administradores IPAM ASM: los miembros del grupo de Administradores ASM (Address Space Management, gestión del espacio de direccionamiento) tienen los mismos permisos que los usuarios IPAM y, además, pueden realizar tareas de gestión IPAM corrientes así como tareas ligadas al espacio de direccionamiento IP. Administradores de auditoría IPAM IP: los miembros del grupo de administradores de auditoría IPAM tienen los mismos privilegios que los usuarios IPAM. Pueden realizar tareas de gestión IPAM corrientes y, además, ver la información de seguimiento de las direcciones IP. Administradores IPAM: los miembros de este grupo tienen permisos sobre todos los datos IPAM y pueden realizar cualquier tarea.
Existe un grupo de seguridad universal IPAMUG que se crea sobre el dominio tras la primera instalación: • •
Este grupo de equipos contiene el primer servidor IPAM instalado. Este grupo está incluido en los Event Log Readers y Usuarios DHCP del dominio.
6. Tareas de administración cotidianas Haga clic en el menú ACCIONES para obtener las operaciones habituales sobre las direcciones IP:
Este menú Acciones contiene, también, las distintas tareas planificadas:
7. Limitaciones a tener en cuenta •
IPAM sólo soporta controladores de dominio Microsoft, y servidores Windows 2008 o superior, integrados en un bosque mediante servicios DHCP, DNS y NPS. Esto quiere decir que la herramienta no gestiona la administración y la configuración de elementos no-Microsoft de la red. No obstante, es posible incluirlos en la base de datos.
•
• •
• • • •
La instalación puede ahora utilizar la base de datos interna de Windows o una base de datos ubicada en un servidor MS SQL 2008 o superior. Preste atención, la base de datos integrada en Windows está limitada a 4 GB. Un servidor IPAM es capaz de gestionar hasta 150 servidores DHCP, 500 servidores DNS, 6000 ámbitos DHCP y 150 zonas DNS. La base de datos almacena tres años de información histórica (contratos, direcciones MAC, conexiones y desconexiones de los usuarios) de hasta 100000 usuarios. No existe ninguna estrategia de purgado automático, de modo que tendrá que hacerse manualmente si fuera necesario. El análisis de tendencias sobre el uso de direcciones IP y de solicitudes sólo está disponible para IPv4. No existe ningún procesamiento especial para direcciones de tipo IPv6 autoconfiguradas sin estado, ni sobre la migración de máquinas virtuales. IPAM no permite auditar direcciones IPv6 autoconfiguradas sobre un equipo que no esté administrado para seguir un usuario. IPAM no verifica la coherencia de las direcciones IP con los routers y switchs de la red.
8. La migración de IPAM a IPAM 2012 R2 La actualización de Windows Server 2012 a 2012 R2 conserva la funcionalidad IPAM, así como la mayoría de componentes instalados y configurados. En cambio, la base de datos IPAM debe actualizarse para poder continuar siendo administrada y, principalmente, aprovechar las nuevas funcionalidades. Al arrancar la herramienta de la consola IPAM, tras la conexión, aparece la opción Actualizar el servidor IPAM. Haga clic en Actualizar el servidor IPAM.
Haga clic en Siguiente para iniciar el asistente.
El asistente realiza una verificación de la base de datos. Una vez terminada, haga clic en Siguiente.
Haga clic en Actualizar.
Haga clic, a continuación, en Cerrar en el resumen de tareas de actualización. Aparece la visualización clásica de todas las opciones de administración de la consola IPAM:
9. Los roles de IPAM 2012 R2 La gestión de los roles se ve mejorada con Windows Server 2012 R2, y es mucho más granular. La administración se divide, ahora, en: •
Roles: conjunto de acciones autorizadas para usuarios concretos.
•
Ámbitos de acceso: conjunto de objetos o de recursos autorizados a los usuarios. Por defecto, existe un único ámbito llamado Global, que incluye todos los recursos.
•
Directivas de acceso: combinación de roles y de ámbitos de acceso.
La delegación granular de la administración consiste en: • • •
Agregar roles suplementarios si es necesario. Crear y nombrar ámbitos y, a continuación, asociar estos ámbitos a los objetos correspondientes. Agregar usuarios o grupos autorizados, asociarles su rol y su ámbito de acceso.
a. La lista de roles integrados
He aquí la lista de roles que se ofrecen por defecto. Cabe destacar que los roles no se corresponden, exactamente, con los grupos creados por IPAM. Además, es posible crear nuestros propios roles: •
Rol Administrador ASM IPAM: Este rol integrado provee las autorizaciones requeridas para gestionar completamente los espacios de direccionamiento IP, los bloques de direcciones IP, las subredes de direcciones IP, los rangos de direcciones IP y las direcciones IP.
•
Rol Administrador de ámbitos DHCP IPAM: Este rol integrado provee los permisos requeridos para gestionar los ámbitos DHCP.
•
Rol Administrador de reservas DHCP IPAM: Este rol integrado provee los permisos requeridos para gestionar las reservas DHCP.
•
Rol Administrador de registros de direcciones IP: Este rol integrado provee los permisos requeridos para gestionar las direcciones IP, en particular la búsqueda de direcciones IP no asignadas, así como la creación y la eliminación de instancias de direcciones IP.
•
Rol Administrador de registros DNS: Este rol integrado provee los permisos requeridos para gestionar los registros de recursos DNS.
•
Rol Administrador DHCP IPAM:
Este rol integrado provee los permisos requeridos para gestionar completamente un servidor DHCP, así como sus ámbitos DHCP, sus filtros de direcciones MAC, sus directivas DHCP y sus reservas DHCP. •
Rol Administrador IPAM: Este rol integrado provee los permisos especificados por los roles Administrador ASM IPAM y Administrador MSM IPAM, además de los permisos necesarios para gestionar ámbitos de acceso, directivas de acceso y grupos lógicos.
•
Rol Administrador MSM IPAM: Este rol integrado provee los permisos requeridos para gestionar completamente los servidores DHCP, los ámbitos globales DHCP, los ámbitos DHCP, los filtros de direcciones MAC, las directivas DHCP, las zonas DNS y los registros de recursos DNS.
b. Creación de un rol personalizado
Si se quiere, por ejemplo, delegar la modificación de registros DNS en la zona DNS pública únicamente, he aquí las etapas que debe seguir. Para crear un rol personalizado, basta con ir a la carpeta IPAM/CONTROL DE ACCESO/Roles de la consola. El botón TAREAS (ubicado arriba a la derecha) permite abrir el asistente para Agregar un rol de usuario.
Escriba un Nombre y, opcionalmente, una Descripción del rol. Seleccione, a continuación, todas las operaciones autorizadas para este rol. c. Creación de un ámbito de acceso
Para crear un ámbito personalizado, basta con ir al a carpeta IPAM/CONTROL DE ACCESO/Ámbito de acceso en la consola. El botón TAREAS (ubicado arriba a la derecha) permite abrir el asistente Agregar ámbito de acceso.
El ámbito puede ubicarse directamente bajo el ámbito Global, o en otro nivel si se desea crear una arborescencia más compleja.
A continuación es posible asociar este ámbito a los recursos u objetos correspondientes. Por defecto, todos los recursos dependen del ámbito Global.
Si desea delegar la zona pública MiEmpresa.es, haga clic en el botón derecho en la zona miempresa.es y seleccione la opción definir ámbito de acceso. Seleccione el ámbito de acceso deseado.
d. Definición de las directivas de acceso
Hasta ahora, no ha tenido lugar, realmente, ninguna delegación. Agregando los usuarios o los grupos es como se otorgan los permisos reales de administración. Vaya a IPAM/CONTROL DE ACCESO/Directivas de acceso. Haga clic en el botón TAREAS y, a continuación, seleccione Agregar directiva de acceso. Seleccione el grupo o el usuario desde el directorio.
Haga clic, a continuación, en Configuración de acceso para poder agregar combinaciones de roles y ámbitos.
Haga clic en el botón Agregar configuración y, a continuación, en Aplicar. Como con Exchange, y con muchos otros productos, la tendencia es hacia la granularidad en la delegación de la administración mediante el uso de roles personalizados que gestionan un ámbito. El objetivo es no asignar más que aquellos permisos necesarios relativos a las acciones y ámbitos deseados.
El protocolo IPv6 Poco a poco, la tecnología IPv6 se va introduciendo en nuestro día a día. Esto es así debido a la inercia que adquiere todo en Internet, porque ya no existe otra opción en ciertas zonas de Internet (África, Asia...) y, también, para conseguir una mejora progresiva a la hora de adquirir nuevos dispositivos y componentes.
Microsoft está actualizando, de manera progresiva, todos sus productos para soportar los estándares de la industria. Esto incluye a IPv6, que será el nuevo protocolo obligatorio en el acceso a Internet, y que supone una evolución de IPv4, protocolo que se utiliza a día de hoy. IPv6 se concibe para dar respuesta a numerosos problemas vinculados a IPv4: la configuración automática, la movilidad y, sobre todo, la extensibilidad del espacio de direccionamiento, que se hace casi infinito en Internet. La funcionalidad principal de IPv6 es el uso de direcciones de 128 bits (en lugar de direcciones de 32 bits), lo cual permite explotar hasta 3.4 × 1038 direcciones, más que suficiente para gestionar las necesidades actuales y futuras. IPv6 no asegura la compatibilidad hacia atrás con IPv4. Un nodo configurado exclusivamente con IPv6 no puede comunicarse con un nodo que esté configurado, exclusivamente, en IPv4. Como consecuencia de ello, debe producirse una transición progresiva desde una red que funcione exclusivamente en IPv4 hacia una red que tenga en cuenta al mismo tiempo IPv4 e IPv6 de forma nativa. A medida que el número de nodos y de aplicaciones de la red que tengan en cuenta IPv6 aumente, el tráfico de su red basculará, con el tiempo, de un uso mayoritario de IPv4 a un uso mayoritario de IPv6. Se trata, por tanto, del objetivo de transición hacia IPv6. Dado que actualmente prevalecen los nodos, dispositivos, aplicaciones y sistemas de gestión de red que utilizan únicamente IPv4, salvo algunas excepciones, el objetivo de su estrategia de transición hacia IPv6 consistirá en migran una red que trabaja exclusivamente en IPv4 hacia una red que tenga en cuenta, al mismo tiempo, el tráfico IPv4 y el tráfico IPv6, y no migrar hacia una red que trabaje exclusivamente con IPv6. El objetivo de esta parte no es presentar la integridad de IPv6 (lo que podría llevarnos varios libros), sino disponer de los comandos básicos de referencia para comprender y adaptarse al nuevo entorno.
1. Tabla de equivalencia entre IPv4 e IPv6 A continuación se presentan algunos conceptos IPv4 y su equivalente en Ipv6: Direccionamiento IPv4 Clases de direcciones de Internet
5 Clases: A a E.
Direcciones MultiCast 224.0.0.0/4
Direccionamiento IPv6 No existe una equivalencia en IPv6 FF00::/8
Direcciones BroadCast
de Todos los bits a 1 No se aplica en IPv6 (255...)
Dirección especificada
no 0.0.0.0
::
Dirección local
de
bucle 127.0.0.1
::1
Direcciones IP públicas Clases A a C salvo las clases privadas.
Direcciones de tipo Global unicast.
Direcciones privadas
Direcciones de Site-local ULA=FC00::/7
IP 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Direcciones autoconfiguradas (APIPA) Representación modo Texto
169.254.0.0/16
en Notación decimal separada por puntos.
Direcciones de Link-local FE80::/64 Notación hexadecimal separada por los símbolos ":", se eliminan los ceros correspondientes a la compresión. Las direcciones compatibles IPv4 se representan en notación decimal con puntos (para los 4 últimos valores). Ejemplo ::ffff:172.16.1.1
Representación de las redes y subredes (Máscara de red)
Notación decimal o longitud del prefijo.
Resolución de nombres Registro de tipo (A) DNS que contiene una dirección IPv4. Resolución inversa
Únicamente la longitud del prefijo. Registro de tipo (AAAA) que contiene una dirección IPv6.
DNS Dominio de tipo IN- Dominio de tipo IP6.ARPA. ADDR.ARPA.
2. Comandos principales La mayoría de comandos son idénticos y funcionan a la vez sobre IPv4 e IPv6, por ejemplo los comandos ipconfig /flushdns y /registerdns. En algunos casos, se desea forzar el uso de un protocolo, por ejemplo, en la resolución de nombres DNS. Ping -4 DC2012
Envío de una consulta ’ping’ sobre DC2012.MiEmpresa.Priv [172.16.1.1] con 32 bytes de datos:
Respuesta de 172.16.1.1: bytes=32 tiempo<1ms TTL=128 Ping -6 DC2012
Envío de una consulta ’ping’ sobre DC2012.MiEmpresa.Priv[fe80::2d95:5a6:9b7d:f350%13] con 32 bytes de datos: Respuesta de fe80::2d95:5a6:9b7d:f350%13: tiempo<1ms Preste atención, en este resultado, la parte %13 no forma parte de la dirección IP, sino que se corresponde con el número del itinerario (interfaz) utilizado. Cuando una tarjeta de red soporta los dos protocolos IP, no es obligatorio configurar DHCP sobre ambos protocolos. Cuando se quiere utilizar el protocolo IPv6, o bien que el protocolo DHCP se base en IPv6, he aquí algunos comandos prácticos: Ipconfig /release6
Adaptador Ethernet LAN: Sufijo DNS específico para la conexión. . : MiEmpresa.Priv Vínculo: dirección IPv6 local. . . . . . . . . . . : fe80::c969:22b:c9fc:8eb0%12 Dirección IPv4. . . . . . . . . . . . . . . . . . . . . . : 172.16.1.185 Máscara de subred. . . . . . . . . . . . . . . . . . . : 255.255.0.0 Pasarela por defecto. . . . . . . . . .. . . . . . . . . : 172.16.1.5 Ipconfig /renew6
Adaptador Ethernet LAN : Sufijo DNS específico para la conexión. . . . . . : MiEmpresa.Priv Dirección IPv6. . . . . . . . . . . . . . . . . . . . . . : fd00::afbe:52a9:314e:e25c Vínculo: dirección IPv6 local. . . . . . . . . . . . . . . : fe80::c969:22b:c9fc:8eb0%12 Dirección IPv4. . . . . . . . . . . . . . . . . . . . . . . . . . : 172.16.1.185 Máscara de subred. . . . . . . . . . . . . . . . . . . . . . . : 255.255.0.0 Pasarela por defecto. . . . . . . . . . . . . . . . . . . . . . : 172.16.1.5 Observe que los comando /release y /renew sólo funcionan para IPv4.
3. La configuración de DHCP v6 Por defecto, la configuración de un servidor DHCP v6 no es obligatoria. Existen muchos mecanismos para evitar la mayoría de conflictos entre sitios, y sobre cada sitio. La asignación aleatoria de una parte del sitio entre millones de combinaciones posibles, y la asignación aleatoria de direcciones voluntarias repartidas también sobre varios millones de combinaciones hacen que los problemas sean meramente teóricos. En un sitio determinado, la primera máquina define el direccionamiento único que se utilizará y, a continuación, todas las demás máquinas se integran en el mismo direccionamiento. De hecho, la noción de sitio o, para ser más exactos, de sub-sitio puede extraerse de las subredes IPv6 y gestionarse, por defecto, mediante routers. Son ellos los encargados de configurar los equipos de acuerdo con el prefijo de la subred correspondiente. El inconveniente es que los servidores, en particular los servidores DNS y los controladores de dominio, tendrán, también, una dirección algo compleja y difícil de memorizar. En el marco de las directivas los scripts, o la configuración de ciertos componentes tales como firewalls, puede ser deseable configurar uno mismo esta parte de DHCP. Sabiendo que se puede escoger la dirección IP de su servidor DNS; de su proxy, será mucho más fácil utilizar información fija en los scripts de conexión o de personalización del entorno. Esta elección supone utilizar, voluntariamente, una configuración globalmente IPv6, sabiendo que muchos dispositivos y aplicaciones no están, todavía, plenamente operativos sobre este protocolo. Si bien el acceso de los clientes está, generalmente, bien administrado en IPv6, es necesario en términos de administración y de funcionamiento de varias aplicaciones importantes. Por ejemplo, en Exchange 2010, todos los protocolos de acceso IMAP, POP, SMTP y MAPI están preparados para funcionar en IPv6. En cambio, IPv4 sigue siendo indispensable para establecer la comunicación entre servidores Exchange. El funcionamiento de DHCPv6 está ligado a varios valores del entorno definidos sobre las tarjetas de red. Cuando se habilita IPv6 en una tarjeta de red, la configuración se realiza, por defecto, en modo StateLess (sin estado). Esto quiere decir que la configuración de la dirección (flag llamado M), tiene el valor Disabled, y no está administrado. La configuración de cada sitio la aportan los routers. Si se instala DHCPv6, puede utilizarse para distribuir otros elementos de configuración (por ejemplo, el servidor DNS, los sufijos de búsqueda...) a condición de que el atributo Otra configuración con estado (flag llamado O) tenga el valor Enabled. Si se habilitan ambos parámetros, la configuración llamada StateFull se basa completamente en DHCP. a. Configuración del cliente DHCPv6 sobre el servidor DHCP
He aquí la lista de comandos que debe utilizar para gestionar, de manera efectiva, un direccionamiento IPv6 basado en DHCPv6.
En los siguientes comandos, LAN se corresponde con el nombre de la tarjeta de red. netsh interface ipv6 set interface LAN routerdiscovery=dhcp netsh interface ipv6 set interface LAN managedaddress=enabled netsh interface ipv6 set interface LAN otherstateful=enabled
La opción routerdiscover puede valer Enabled si los routers están, efectivamente, configurados de forma que puedan aportar los elementos necesarios. Utilice el comando netsh interface ipv6 show interface LAN para confirmar las opciones en curso. b. Configuración del servicio DHCPv6
Abra la consola de administración de DHCP. Seleccione la opción Ámbito nuevo en el menú IPv6.
Haga clic en Siguiente para iniciar el asistente.
Asigne un nombre al ámbito y haga clic en Siguiente.
Indique el prefijo de la red así como la posible preferencia.
El número de prefijo se debe escoger en el ámbito previsto para las redes privadas. Como con las redes IPv4, ¡cada subred utiliza una parte fija que debe ser diferente! La noción de preferencia (valor de 0 a 255) permite repartir/optimizar el comportamiento de DHCP entre varios servidores. Un cliente DHCP preferirá un servidor que tenga la misma preferencia que el que haya obtenido la vez anterior. Agregue las zonas o direcciones IP que desea excluir.
En este caso, se escogen las 255 primeras direcciones, aunque podemos ser más generosos sin que ello suponga un problema. Todos los servidores para los que se quiere asignar una dirección IP fija, en particular servidores DNS y controladores de dominio, utilizarán, principalmente, este tipo de dirección, que podremos informar en las opciones. Indique la duración deseada para los contratos.
La duración preferida se corresponde con el retardo normal deseado de conservación de una dirección. La duración válida se corresponde con la duración máxima, si no existe una renovación del contrato. Habilite el ámbito y valide al final del asistente.
Configure, a continuación, las opciones del ámbito o la configuración a nivel de servidor.
Las opciones 23 (servidores DNS que se usarán para la resolución de nombres) y 24 (sufijos de búsqueda) son las opciones más interesantes que se pueden configurar. Preste atención, la activación del modo IPv6 completo no tiene sino ventajas. La estación recibe una dirección IPv6 aunque no funcionará plenamente en este modo sino tras haber deshabilitado IPv4. Es preciso probar bien el conjunto antes de utilizarlo en una red de producción.
4. Configuración DNS v6 de la zona de búsqueda inversa La zona de búsqueda DNS directa no necesita ninguna configuración particular.
Los registros siguen la misma lógica que los registros clásicos. He aquí las etapas que permiten crear una zona de búsqueda inversa de tipo IPv6: Seleccione Zonas de búsqueda inversa y, a continuación, haga clic con el botón derecho y seleccione Zona nueva... en el menú contextual.
Inicie el asistente Nueva zona y haga clic en Siguiente.
Seleccione el tipo de zona y haga clic en Siguiente.
Seleccione el tipo de replicación y haga clic en Siguiente.
Seleccione el tipo Zona de búsqueda inversa para IPv6.
Escriba el prefijo y el tamaño de la zona que se desea, en bits.
Teniendo en cuenta el número casi ilimitado de redes y de máquinas, nos limitaremos a una red en la que queremos recibir y actualizar la información. Seleccione el tipo de actualización y haga clic en Siguiente.
Finalice la creación de la zona haciendo clic en Finalizar.
Los registros DNS inversos aparecen una vez actualizada la zona, tarea que podemos forzar mediante el comando ipconfig /registerdns.
5. TEREDO Teredo es una tecnología que facilita la transición entre IPv6 e IPv4, permitiendo a las aplicaciones IPv6 comunicarse a través de una red IPv4, incluso a través de redes que utilizan NAT, es decir, traducción de direcciones. Esta capa es válida y está lista para utilizarse en Windows Server 2012. DirectAccess puede utilizar esta solución, aunque requiere dos direcciones IP públicas simultáneas consecutivas.
6. ISATAP ISATAP (Intra-site Automatic Tunnel Addressing Protocol) es una tecnología de transición definida en la RFC 4214. El interés de ISATAP consiste en utilizar la infraestructura IPv4 tal como es, sin ningún hardware suplementario ni modificación en la configuración de los routers. Las nuevas aplicaciones que utilizan IPv6 pueden instalarse sobre IPv4 gracias a esta capa suplementaria adaptándose al direccionamiento existente. Esta capa es, de hecho, válida y está lista para utilizarse en Windows Server 2012. El direccionamiento de ISATAP está compuesto por un prefijo, un valor fijo (0:5efe o 200:5efe) y termina con el direccionamiento IPv4. 64-bits_Unicast_Prefix:0:5efe:w.x.y.z
Este formato de dirección se utiliza cuando la dirección IPv4 es privada. 64-bits_Unicast_Prefix:200:5efe:w.x.y.z
Este formato de dirección se utiliza cuando la dirección IPv4 es pública. Esta combinación permite utilizar IPv6 manteniendo sus equivalentes en IPv4.
Asociación de tarjetas de red en equipo (Teaming) Windows Server 2012 soporta ahora, de forma nativa, la combinación de varias tarjetas de red. Las soluciones que daban antes los fabricantes suponían utilizar tarjetas de red idénticas, del mismo proveedor, y no estaban soportadas directamente por Microsoft en configuraciones de virtualización, soluciones que son exigentes, por lo general, en cuanto a la necesidad de tarjetas de red. La asociación (hasta 32 tarjetas de red) realiza, principalmente, la agregación del ancho de banda y la tolerancia a fallos. Es posible asociar tarjetas de distintas velocidades, y crear, por lo tanto, tantas asociaciones de tarjetas como sea necesario. El asistente propone integrar las tarjetas físicas, o incluso las tarjetas virtuales creadas por Hyper-V. Esto resulta, por otro lado, muy práctico cuando se desea desplazar tarjetas Hyper-V hacia nuevas tarjetas de forma asociada. Este tipo de configuración no requiere la configuración de un switch, y permite conectarse directamente a varios switchs diferentes, lo que mejora la tolerancia a fallos. Por supuesto, es mejor utilizar tarjetas que dispongan de las mismas propiedades. He aquí el procedimiento de instalación, que es relativamente sencillo. Abra el Administrador del servidor y sitúese en el Servidor local.
Puede, también, configurar asociaciones sobre un servidor remoto, aunque no se recomienda. Haga clic en Deshabilitado junto a la propiedad Formación de equipos de NIC.
Agregue una asociación seleccionando la opción TAREAS en EQUIPOS y, a continuación, Nuevo equipo.
Podemos, también, utilizar el menú TAREAS de una tarjeta disponible o en la sección ADAPTADORES E INTERFACES. Seleccione el nombre de la futura tarjeta, e indique las tarjetas que forman parte de la asociación.
Haga clic en Propiedades adicionales para adaptar la configuración.
El modo de formación de equipos y el modo de equilibrio de carga no se pueden modificar en una máquina virtual. En cambio, es posible definir una VLAN específica, o la tarjeta que se deja como reserva. El modo Independiente del conmutador funciona en cualquier caso, y no requiere ni un switch particular, ni disponer de una configuración particular. Permite, también, conectar cada tarjeta a switchs diferentes, con el objetivo de gestionar, de este modo, los fallos o el reinicio de un switch. Los otros dos modos de asociación requieren una configuración específica sobre los switchs. • •
El modo Formación de equipos estática obliga a identificar los enlaces que componen la asociación a nivel de switch. El modo LACP es un protocolo estándar que permite negociar con los demás equipos el funcionamiento óptimo agrupando los puertos configurados de la misma manera (velocidad, modo Duplex, VLAN, Trunk).
El modo de equilibrio de carga por defecto se basa en una tabla hash de las direcciones, es decir, un reparto basado en las direcciones IP recibidas. El otro modo propuesto se basa en los puertos Hyper-V. La asociación de tarjetas en una máquina virtual es útil solamente si no se ha creado ninguna asociación sobre la máquina host. O bien asociamos dos tarjetas sobre el servidor host, o bien asociamos dos tarjetas a la máquina virtual. Preste atención, es necesario modificar las opciones de las tarjetas de red en la configuración de la máquina virtual.
La asociación de la tarjeta ha concluido.
La administración de las tarjetas permite habilitar, deshabilitar, agregar o eliminar nuevas tarjetas. Preste atención, la nueva tarjeta creada no recupera la configuración TCP/IP de ninguna de las tarjetas anteriores, y se basa, por tanto, en DHCP. Las tarjetas que forman parte de la asociación pierden su configuración específica. En cambio, cabe destacar que esta configuración específica se recupera siempre que la tarjeta salga de la asociación. Configure la nueva tarjeta llamada Team1.
Las tarjetas utilizadas para la asociación se marcarán como Habilitado. La tarjeta Team1 incluye, ahora, la configuración del protocolo TCP/IP.
Presentación de SMBv3 SMB 3.0 es la nueva versión, incluida desde Windows Server 2012 y Windows 8. Observe que se llamaba SMB 2.2 durante su periodo Beta. La mayor parte de novedades funcionan únicamente con estas versiones de Windows. Este nuevo protocolo debería incluirse en la próxima versión de Samba 4.0, y ahora mismo se encuentra en desarrollo por parte de NetApp y EMC.
1. Características de SMBv3 SMB 3.0 aporta las siguientes mejoras respecto a versiones anteriores del protocolo: •
Conmutación transparente de SMB (Transparent Failover - Node Fault Tolerance) Un mismo recurso compartido puede proveerse por varios servidores o nodos diferentes de un clúster. La parada de un nodo ya no implica una desconexión y una reconexión.
•
SMB multicanal Todos los enlaces de red disponibles entre dos equipos serán evaluados y utilizados. El número de conexiones establecidas está vinculado entre dos sistemas. Depende del número de interfaces y del tipo de tarjeta. Una tarjeta que soporte RSS autorizaría cuatro conexiones, con un máximo de ocho de manera global. Incluso un sistema que posea una sola tarjeta puede utilizar esta funcionalidad y repartir su actividad entre varios procesadores.
•
Agrupaciones de servidores SMB (ScaleOut) Esta funcionalidad supone una ventaja respecto a las dos anteriores (Failover y Multicanal). Cuando un recurso compartido SMB 3.0 se instala en un clúster, todos los nodos y todas las tarjetas de red se utilizan para optimizar la transferencia de datos.
•
SMB directo Esta funcionalidad permite a los equipos que poseen tarjetas de red RDMA transferir datos de memoria a memoria entre ellos sin tener que pasar por el procesador.
•
Encriptación SMB Todos los datos enviados por SMB 3.0 entre los equipos se encriptan, automáticamente, por defecto.
•
VSS sobre los recursos compartidos de archivos SMB Los recursos compartidos pueden, en lo sucesivo, salvaguardarse gracias a una herramienta compatible con VSS. El servicio de instantáneas de Microsoft realizará, bajo demanda, los snapshots necesarios.
•
Concesión de directorio SMB (SMB directory leasing) SMB aloja en caché todos los metadatos de los documentos accesibles, en particular a través de BranchCache. Esto disminuye el número de consultas de ida y vuelta y el tiempo de latencia en el acceso inicial a las propiedades de un archivo.
•
PowerShell para SMB Todas las propiedades de SMB son, ahora, accesibles y configurables a partir de comandos PowerShell.
2. Caso práctico: implementar el modo Multicanal a. Requisitos previos
Para probar y utilizar SMB 3.0 es necesario disponer de, al menos, dos equipos con Windows Server 2012/2012 R2 o Windows 8/8.1. Para aprovecharlo plenamente, hace falta: • • •
Varias tarjetas de red. O, al menos, una tarjeta que soporte el modo RSS (Receive Side Scaling). O, al menos, una tarjeta que soporte el modo RDMA (Remote Direct Memory Access).
Observe que las máquinas virtuales (Windows 8/8.1 o Windows Server 2012/2012 R2) creadas por Hyper-V soportan, de forma nativa, RSS. Esto resulta muy práctico, y explica también, en parte, las transmisiones tan rápidas entre sistemas hospedados en un mismo servidor host. Cada tarjeta clásica autoriza una conexión TCP. Cada tarjeta RDMA autoriza dos conexiones RDMA. Cada tarjeta que soporta RSS autoriza un máximo de cuatro conexiones TCP. b. Comandos PowerShell
Verificar la configuración del servidor: Get-SmbServerConfiguration AnnounceServer
: False
AsynchronousCredits AutoShareServer AutoShareWorkstation CachedOpenLimit AnnounceComment EnableDownlevelTimewarp EnableLeasing EnableMultiChannel EnableStrictNameChecking AutoDisconnectTimeout DurableHandleV2TimeoutInSeconds EnableAuthenticateUserSharing EnableForcedLogoff EnableOplocks EnableSecuritySignature ServerHidden IrpStackSize KeepAliveTime MaxChannelPerSession MaxMpxCount MaxSessionPerConnection MaxThreadsPerQueue MaxWorkItems NullSessionPipes NullSessionShares OplockBreakWait PendingClientTimeoutInSeconds RequireSecuritySignature EnableSMB1Protocol EnableSMB2Protocol Smb2CreditsMax Smb2CreditsMin SmbServerNameHardeningLevel TreatHostAsStableStorage ValidateAliasNotCircular ValidateShareScope ValidateShareScopeNotAliased ValidateTargetName EncryptData RejectUnencryptedAccess
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
64 True True 5 False True True True 0 30 False True True False True 15 2 32 50 16384 20 1
35 120 False True True 2048 128 0 False True True True True False True
Verificar la configuración del cliente: Get-SmbClientConfiguration ConnectionCountPerRssNetworkInterface DirectoryCacheEntriesMax DirectoryCacheEntrySizeMax DirectoryCacheLifetime EnableBandwidthThrottling EnableByteRangeLockingOnReadOnlyFiles EnableLargeMtu EnableMultiChannel DormantFileLimit EnableSecuritySignature ExtendedSessionTimeout FileInfoCacheEntriesMax
: : : : : : : : : : : :
4 16 65536 10 True True True True 1023 True 1000 64
FileInfoCacheLifetime : 10 FileNotFoundCacheEntriesMax : 128 FileNotFoundCacheLifetime : 5 KeepConn : 600 MaxCmds : 50 MaximumConnectionCountPerServer : 32 OplocksDisabled : False RequireSecuritySignature : False SessionTimeout : 60 UseOpportunisticLocking : True WindowSizeThreshold : 8 Get-SmbServerNetworkInterfaceGet-SmbClientConfiguration Scope Name Interface Index RSS Capable RDMA Capable Speed IpAddress ---------- --------- ----- --- ------- ------------ ------------* 12 True False 10 Gbps 172.16.1.184 * 12 True False 10 Gbps fe80::4eb:1e38:4cf5... * 12 True False 10 Gbps fec0::12 Get-SmbClientNetworkInterface| ft -auto Interface Index RSS Capable RDMA Capable Speed IpAddresses Friendly Name --------------- ----------- ------------ ----- ---------------------12 True False 10 Gbps {fec0::12, fe80::4eb:1e38:4cf5:cfc0, 172.16.1.184} LAN 17 False False 0 bps {fe80::5efe:172.16.1.184} isatap.MiEmpresa.Priv 14 False False 0 bps {fe80::100:7f:fffe} do Tunneling Pseudo-Interface Get-SmbMultichannelConnection |ft -auto Server Name Selected Client IP Server IP Client Interface Index Server Interface Index Client RSS Capable Client RDMA Capable ----------- -------- ----------------- ---------------------- --------------------- ------------------ ------------------dc2012 True 172.16.1.184 172.16.1.1 12 13 True False Get-SmbMultichannelConnection |fl ServerName : dc2012 Selected : True Failed : False FailureCount : 0 ClientInterfaceIndex : 12 ClientRSSCapable : True ClientRdmaCapable : False ClientLinkSpeed : 10 Gbps ClientIpAddress : 172.16.1.184 ServerInterfaceIndex : 13 ServerRSSCapable : True ServerRdmaCapable : False ServerLinkSpeed : 10 Gbps ServerIpAddress : 172.16.1.1 MaxChannels : 4 CurrentChannels : 1
Para comprobar el uso del modo multicanal, basta con copiar una pequeña herramienta. PS C:\sources> copy .\admtsetup32.exe x:\ Get-SmbMultichannelConnection |fl ServerName : dc2012 Selected : True Failed : False FailureCount : 0 ClientInterfaceIndex : 12 ClientRSSCapable : True ClientRdmaCapable : False ClientLinkSpeed : 10 Gbps ClientIpAddress : 172.16.1.184 ServerInterfaceIndex : 13 ServerRSSCapable : True ServerRdmaCapable : False ServerLinkSpeed : 10 Gbps ServerIpAddress : 172.16.1.1 MaxChannels : 4 CurrentChannels : 4
Observe que existe un máximo de cuatro canales activos simultáneamente entre ambos equipos. Por último, destacaremos que, incluso habiendo probado las reglas por defecto del grupo para ser lo más favorables posibles en los casos más comunes, es posible parametrizar el número de conexiones utilizadas mediante los siguientes comandos: Set-SmbClientConfiguration -MaximumConnectionCountPerServer Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface
También es posible personalizar el comportamiento del multicanal entre varios servidores para forzar el uso de ciertas tarjetas y excluir algunas otras. Será preciso, entonces, utilizar los siguientes comandos: New-SmbMultichannelConstraint -ServerName -InterfaceAlias ,
En términos de optimización y de seguridad, deshabilitar el protocolo SMB 1.0 es más que aconsejable: Set-SmbServerConfiguration -EnableSMB1Protocol :$false
3. Observaciones Destacaremos que la práctica totalidad de las ventajas de SMB 3.0 no requieren, en realidad, ninguna configuración específica. Si los servidores poseen las tarjetas de red adecuadas y la negociación se lleva a cabo con éxito, se utilizará la mejor opción de entre las posibles. En un futuro próximo, serán los servidores Windows Server 2012 físicos o
virtuales los que aprovecharán un mejor rendimiento con una configuración que utilice los roles y características de Hyper-V, el clustering, y el almacenamiento compartido de tipo CSV basado en SMB 3.0. Los servidores de recursos compartidos tendrán que esperar, seguramente, algo más de tiempo antes de que un gran número de estaciones de trabajo con Windows 8 aprovechen estas nuevas mejoras de rendimiento.
4. Las modificaciones de SMB en Windows Server 2012 R2 La modificación más inmediata es SMB 1, que ya no es necesario en el funcionamiento normal. Sigue estando activo, por defecto, aunque puede deshabilitarse, lo cual elimina también el servicio llamado Explorador de red (Computer Browser) y el protocolo de administración a distancia (Remote Administration Protocol). El rendimiento se ve mejorado en el marco de los servidores de recursos compartidos utilizados bajo la forma de granja de servidores (Scale-Out File server) y, por extensión, aquellos que sirven para alojar a los servidores virtualizados. Cabe destacar: • •
• •
La conmutación automática de los clientes en función de los archivos compartidos y no en función del servidor para obtener el mejor acceso posible. El uso de archivos VHDX compartidos en recursos compartidos CSV o SMB ScaleOut para gestionar los clústers. La noción de Scale-out consiste en poder repartir la carga sobre varios servidores. La migración Over SMB de máquinas virtuales utilizando SMB Direct y SMB Multichannel, para una migración más rápida y con menor consumo de procesador. El soporte de varias instancias SMB diferentes sobre un servidor de archivos ScaleOut: por defecto, una instancia administra los accesos estándar a los archivos compartidos, y se crea una instancia suplementaria por cada nodo del clúster para gestionar el tráfico CSV inter-nodo.
Existen otras pequeñas mejoras: •
El rendimiento es mucho mejor para las tarjetas que soportan RDMA (SMB over RDMA), principalmente para las de tipo 40 Gbps Ethernet o 56 Gbps InfiniBand. Las tarjetas RDMA permiten la transferencia direct de memoria a memoria, entre dos equipos que disponen de este tipo de tarjeta.
• •
Los eventos SMB están mejor detallados. La gestión del ancho de banda permite definir límites sobre los distintos tipos de tráfico: Default, Live Migration y máquinas virtuales.
Windows Server Gateway
Esta funcionalidad es un elemento clave en las redes híbridas, que va a ayudar a las empresas a conectarse con los proveedores de servicios a través de una red privada de tipo punto a punto. Como tal, la máquina virtual realiza solamente el enrutamiento, es decir, la transferencia de los paquetes entre dos tarjetas de red. El resto del trabajo lo aseguran las capas de red incluidas con Hyper-V, que encapsulan, etiquetan y segmentan los paquetes. A día de hoy, éste no es el único uso para esta pasarela, que permite interconectar distintos tipos de redes físicas y virtuales, segmentando si fuera necesario la comunicación. Según la arquitectura, esta funcionalidad debe complementarse con otros productos para crear puentes, separar los flujos mediante tags (VLAN) y enrutar correctamente los flujos una vez que se ha eliminado la máquina virtual. En la empresa, esto puede aportar: • • •
La compartición de una Cloud privada entre varias entidades (Dev, PreProd, Prod). El acceso a infraestructuras externas (Cloud hybride). La intercomunicación entre distintas redes o arquitecturas que provengan de distintas entidades.
Para proveedores de Cloud pública, esto facilita: • • •
El aislamiento de las comunicaciones. La compartición de recursos de hardware de red (routers/switchs/…). La continuidad del direccionamiento de red del cliente que puede interconectar, sea cual sea su direccionamiento.
De manera esquemática, se trata de un router por software basado en una máquina virtual. Aun así, el uso de una máquina virtual permite gestionar el filtrado de las conexiones (aislamiento) a nivel del servidor físico, y etiquetar los paquetes a su paso.
1. Instalación Hablando con propiedad, no existe, como tal, una instalación sino simplemente una configuración. Dejando a un lado la configuración del entorno de red, esta configuración se realiza a dos niveles en Windows Server 2012 R2: • •
En el servidor Hyper-V En la máquina virtual
a. En el servidor Hyper-V
Algunos comandos indicados aquí son opcionales y dependen de la configuración de la red, otros optimizan el rendimiento, y muy pocos son indispensables. Otros es posible ejecutarlos solamente si se dispone de tarjetas de red que soportan la funcionalidad correspondiente. He aquí las instrucciones de optimización (todas las tarjetas no aceptan los mismos parámetros): •
Aumentar los buffers de recepción:
Set-NetAdapterAdvancedProperty "LAN" -DisplayName "Receive Buffers" -DisplayValue 3000 •
Aumentar los buffers de transmisión:
Set-NetAdapterAdvancedProperty "LAN" -DisplayName "Transmit Buffers" -DisplayValue 3000 •
Activación del modo RSS:
Enable-NetAdapterRss LAN •
Activación del Queuing:
Enable-NetAdapterVmq "Teaming1"
Si fuera necesario, indique la VLAN que desea utilizar en la tarjeta externa: Set-VMNetworkAdapterVlan -VMName "WSG" -Name "VIRTUAL" -Access -VlanId 5
Activar el aislamiento en la tarjeta de red LAN: Set-VmNetworkAdapterIsolation -VMName WSG -VMNetworkAdapterName "LAN" -IsolationMode NativeVirtualSubnet -MultiTenantStack Off
Es posible deshabilitar el modo de aislamiento mediante el comando: Set-VmNetworkAdapterIsolation -IsolationMode None
-VMName WSG -VMNetworkAdapterName "LAN"
b. Configuración de la pasarela WSG
He aquí los comandos de optimización de las tarjetas de red en la máquina virtual.
Definición del número máximo de procesos a utilizar en función de la configuración: Set-NetAdapterRss "LAN", "VIRTUAL" -MaxProcessorNumber 8
Tamaño máximo de los buffers que se utilizan en entrada y salida: Set-NetAdapterAdvancedProperty "LAN","VIRTUAL" -DisplayName "Send Buffer Size" -DisplayValue "32MB" Set-NetAdapterAdvancedProperty LAN, VIRTUAL -DisplayName "Receive Buffer Size" -DisplayValue "16MB"
La configuración de ambas tarjetas de red y la ruta por defecto puede definirse mediante la interfaz gráfica. En la tarjeta que permite acceder a la red virtual o remota, es preciso especificar esta red remota y la dirección IP concreta que se desea utilizar. Configuración de la ruta estática hacia la red virtual (es posible, también, utilizar el comando route add): New-NetRoute -InterfaceAlias VIRTUAL -DestinationPrefix 172.17.100.1.0/24 -NextHop 172.17.100.254
Ejemplo de configuración de la ruta por defecto: New-NetRoute -InterfaceAlias LAN -DestinationPrefix 0.0.0.0/0 -NextHop 172.16.254.254
La parte más importante consiste en activar el enrutamiento entre ambas redes: Set-NetIPInterface -InterfaceAlias LAN -Forwarding Enabled Set-NetIPInterface -InterfaceAlias VIRTUAL -Forwarding Enabled
¡Ahora el enrutamiento debería estar activo! La desactivación del enrutamiento se realiza mediante el comando: Set-NetIPInterface -InterfaceAlias VIRTUAL -Forwarding Disabled
c. La configuración del router interno
Para que los paquetes se encaminen desde la máquina virtual hacia la o las redes remotas, se agrega una ruta estática sobre el router por defecto para que los paquetes cuyo destino sea 172.17.100.0 se envíen a la dirección IP de la pasarela. La configuración dependerá del router utilizado.
2. Esquema de un ejemplo de uso
La red virtual indicada aquí estará, a menudo, vinculada con otra tarjeta de red física que permitirá acceder a otros recursos internos o externos según la configuración. Es posible, también, instalar una VPN para acceder a otras redes que no estarán accesibles más que por esta pasarela. Es posible realizar una configuración idéntica sobre el sitio remoto para recibir y repartir los flujos. Si tiene lugar, la conexión intersitio utilizará mecanismos de tipo Tunnel para encapsular los paquetes de red que, de otro modo, no podrían enrutarse directamente. Si el número de la red gestiona el nivel 3, estos mecanismos pueden ser GRE o IP-in-IP tunneling. A nivel 2, existen las VLAN de tipo Q-in-Q. Para saber más, el siguiente enlace presenta la mayoría de combinaciones posibles: http://technet.microsoft.com/es-es/library/jj618319.aspx
3. Conclusión He aquí algunos elementos de reflexión suplementarios que cabe tener en cuenta. La capa Hyper-V Network Virtualization (HNV) puede soportar en esta versión:
• • •
50 dominios de enrutamiento (red de máquinas virtuales) 500 subredes virtuales (subredes en las redes de máquinas virtuales) 200 conexiones VPN punto a punto
He aquí un procedimiento que indica las distintas etapas de la implementación: http://geekswithblogs.net/KeithMayer/archive/2012/10/08/step-by-step-implementinghyper-v-network-virtualization-with-windows-server-2012.aspx Desafortunadamente, no existe, a día de hoy, una herramienta de administración integrada en Windows Server 2012 R2 para administrar la pasarela. La gama System Center contiene la mayoría de elementos necesarios para controlar la construcción de soluciones basadas en la WSG. Con todas estas mejoras, Windows Server 2012 R2 incluye muchos usos que cambian muy rápido. La interconexión de nubes privadas, públicas, la virtualización en varios niveles, las facilidades de conexión y la velocidad permiten adoptar nuevas arquitecturas que facilitan la administración de un conjunto de componentes muy diverso.
Experiencia con Windows Server Essentials Se trata de un nuevo rol de Windows Server 2012 R2. Este rol ayuda a proteger los datos, ofreciendo un acceso a la información desde casi cualquier dispositivo. Este servicio le ayuda a conectarse rápidamente a las aplicaciones de gestión de su empresa y a los servicios asociados - accesibles desde este servidor. Este rol le aporta el mismo nivel de facilidad en la administración que el proporcionado por SBS, dejando a un lado la mensajería, que no está incluida en este rol. En cambio, se ha hecho lo posible para poder integrar fácilmente la mensajería correspondiente a Office 365, y la mensajería de tipo Exchange. Preste atención, como con SBS, este rol incluye sus restricciones, en particular a la hora de tener en cuenta bosques mono-dominios únicamente.
1. Instalación En la ventana del Asistente para agregar roles y características, seleccione el rol Experiencia con Windows Server Essentials de la lista.
Este rol integra toda una serie de componentes. Haga clic en Agregar características.
Podemos observar la instalación automática de numerosos componentes relacionados con el rol IIS así como la herramienta de copia de seguridad. No hay que agregar ninguna característica adicional.
Haga clic en Siguiente.
¡El rol IIS se instala automáticamente!
Valide la lista de componentes IIS instalados, y agréguelos si fuera necesario.
Confirme la instalación de los componentes haciendo clic en Instalar.
Valide el resultado de la instalación.
2. Configuración inicial Tras la instalación de la funcionalidad, la consola de gestión de servidores pide realizar la configuración. Haga clic en el enlace Más... junto al mensaje Requiere configuración para:....
Haga clic en la acción Configurar Windows Server Essentials en el detalle de las tareas.
Si la configuración es válida, haga clic en Configurar.
Haga clic en Cerrar.
Observe que el sistema puede reiniciar en cualquier momento. Si todo va bien, verá aparecer el siguiente mensaje:
Preste atención, Windows Server Essentials se configura por defecto en los puertos 80 y 443. Entrará, por tanto, en conflicto con cualquier otro servicio Web ya instalado, así como con la función Carpetas de trabajo, ¡que utiliza los mismos puertos! Por otro lado, el servicio entidad de certificados se instala automáticamente, y se solicita automáticamente un certificado a esta entidad.
3. Administración La herramienta de administración principal se llama Panel, para la que existe un acceso directo en el escritorio. Observe que no hay que confundirlo con el cuadro de mando de administración de servidores. He aquí el panel de Windows Server Essentials:
Aquí encontrará la lista esencial de tareas a manejar para obtener las funcionalidades deseadas: • • • •
Administrar las cuentas y las carpetas Administrar el acceso desde cualquier lugar Configurar la copia de seguridad Integrar equipos
La ventaja consiste en obtener, a continuación, rápidamente el estado de seguimiento, de los servidores, etc. Es posible, a continuación, integrar distintos servicios locales o remotos (Cloud):
En las aplicaciones, existe la posibilidad de conectarse a Microsoft Pinpoint. Se trata de una ubicación donde podemos encontrar herramientas complementarias que se integran con Windows Server Essentials.
4. Configuración del cliente en el equipo del usuario Para instalar el cliente que permite interactuar con esta funcionalidad, utilice la URL http://NombreDelServidor/CONNECT, que da acceso a un enlace de descarga de la herramienta llamada Conector, compatible con Windows 7 SP1, Windows 8, Windows 8.1 y Mac OS X 10.6 a 10.8. Tras la instalación, el equipo se integra al dominio, si no lo estuviera ya. Descargue la herramienta.
Ejecute el asistente de instalación.
Siga la instalación.
Indique su nombre de usuario y contraseña.
Se muestra una alerta de seguridad sobre la cuenta Administradores.
Seleccione la opción apropiada. Haga clic en No si configura el cliente para el conjunto de usuarios del equipo.
La primera opción está, principalmente, adaptada a equipos portátiles y equipos personales, la segunda opción a equipos de empresa. Configure el modo de copia de seguridad del equipo.
Valide la configuración.
Una vez terminada la instalación, se agrega un componente a la barra de tareas.
Preste atención, tras la primera conexión se realiza una copia de seguridad de la estación… Las copias de seguridad de los equipos cliente están ubicadas en archivos especiales con extensión de tipo DAT en el servidor, en la carpeta C:\ServerFolders\Copias de seguridad de equipos cliente.
5. Uso Si se ha configurado para todos los usuarios del puesto de trabajo, cualquier usuario que inicie sesión se conectará, automáticamente, al servidor.
El entorno del usuario incluye dos elementos para acceder a los datos: •
El acceso directo en el Escritorio.
Éste contiene dos accesos directos que apuntan a carpetas de trabajo a través del recurso compartido Carpetas compartidas sobre el servidor. •
El icono de la aplicación Launchpad, instalado por el conector, aparece en la barra de tareas.
Si se abre el LaunchPad, se obtiene la lista de aplicaciones disponibles. Por defecto, aparece la siguiente pantalla:
El usuario puede, de este modo, iniciar una copia de seguridad, acceder de manera remota si el módulo se ha configurado para obtener las carpetas compartidas, así como las aplicaciones agregadas tales como el correo electrónico, si se hubiera configurado. La aplicación Panel está accesible únicamente a aquellos usuarios declarados como administradores en la consola de administración de Windows Server Essentials.
6. Conclusión La administración aprovecha una herramienta que le permite implementar rápidamente toda una infraestructura comparable a la que se provee con SBS o en la versión específica de Windows Server 2012 Essentials, salvo en lo relativo al correo electrónico, que se propone como una integración con Office 365. Ahora es posible realizar una pequeña maqueta para afinar la configuración y adaptarla a las necesidades concretas del proyecto. Por ejemplo, las carpetas compartidas se crean por defecto en el disco C: del servidor.
Introducción Este capítulo está dedicado al rol Servicios de Escritorio remoto (Remote Desktop Services) de Windows Server 2012 R2. Probablemente ya utiliza este servicio para administrar su parque de servidores de forma cotidiana. Tras revisar este uso simple
aunque, ciertamente, crítico, veremos la potencia del rol RDS. Esto incluye, en particular, la publicación de aplicaciones, del escritorio en modo sesión o virtual, así como el acceso a estas aplicaciones a través de una pasarela Web. Antes de empezar, vamos a realizar algunas aclaraciones sobre la nomenclatura. El nombre de los servicios se ha visto modificado desde Windows Server 2008 R2, y encontramos nuevos nombres en Windows Server 2012 R2: Antes de Windows Server 2008
Windows Server 2012 R2
También llamado
Terminal Services
Servicios de Escritorio RDS remoto (Remote Desktop Services)
Terminal Server
Host de sesión de Escritorio RDSH remoto
no existía
Host de virtualización de RDVH o VDI Escritorio remoto
Administración licencias TS
de Administración de licencias de Escritorio remoto
Service Broker TS
Agente de conexión Escritorio remoto
a RDCB (Connection Broker) RDSB (Service Broker) o Broker
Acceso Web TS
Acceso Web para los RDWA o RDWEB servicios de Escritorio remoto
Puerta de enlace de Puerta de enlace de Escritorio TS remoto Como podrá observar, el cambio principal es que se ha remplazado "Terminal Services" por "servicios de Escritorio remoto". Esta obra, centrada en Windows Server 2012 R2, utiliza la nueva nomenclatura en lo sucesivo. Aquellas funcionalidades que sólo existan en una versión se destacarán. La denominación "Escritorio remoto" se remplazará, a menudo, por la voz inglesa RDS (Remote Desktop Services) con el objetivo de hacer más legible el texto. Windows Server 2012 R2 incluye su conjunto de mejoras en los servicios de Escritorio remoto respecto a las versiones anteriores. En particular, destacaremos: • •
Una consola de administración que le permitirá administrar sus servidores de Escritorio remoto o escritorios virtuales de forma sencilla y centralizada. Los discos de perfil de usuario que permiten ampliar la gestión de los perfiles móviles.
•
• • •
• • •
La gestión automatizada de los escritorios virtuales que permite recrear escritorios virtuales, una vez aplicadas las actualizaciones de seguridad instaladas en el modelo de escritorio virtual. La instalación simplificada de los servicios de Escritorio remoto en modo sesión o en modo de escritorios virtuales (VDI). Una mejora en la compresión de los flujos de audio y vídeo con una reducción del ancho de banda de casi el 50% en algunos casos. La posibilidad de visualizar las sesiones (Session Shadowing), que permite supervisar y controlar la sesión de otro usuario conectado a un servidor host de sesión de los servicios de Escritorio remoto o a un escritorio virtual que se ejecuta sobre un servidor host de virtualización de los servicios de Escritorio remoto. Una mejor tasa de compresión de los flujos RDP, que mejora el uso del ancho de banda. Una mejora en el tiempo de reconexión (Quick reconnect), tras la pérdida de la conexión mediante un escritorio virtual, una sesión o una aplicación RemoteApp. La posibilidad de instalar el rol Connection Broker en un servidor controlador de dominio.
Sería demasiado extenso enumerar la lista completa. Windows 8.1 y Windows Server 2012 R2 incluyen el cliente Remote Desktop Client (RDC) en su versión 8.0. El objetivo consiste en mejorar la experiencia de usuario proporcionando: • • • • • • • • • •
Soporte multi-touch. Redirección dinámica de USB mediante RemoteFX. Gestión de la reconexión automática para aplicaciones RemoteApp y conexiones de Escritorio remoto. Integración de una autenticación única (Single Sign-on). Integración de una API mediante RemoteFX para VoIP. Integración de sesiones anidadas. Un verdadero soporte multipantalla (en lugar de la extensión habitual). Soporte a pantallas con cambio de representación apaisada/vertical. Soporte a la hora de agregar o eliminar una pantalla en caliente (conexión a un proyector de vídeo, por ejemplo) en una sesión y las aplicaciones RemoteApp. Securización de las conexiones de administración mediante el modo RestrictedAdmin, que permite realizar una autenticación mediante un ticket Kerberos y un token de autenticación de la sesión interactiva sin necesidad de volver a introducir las credenciales tras la conexión. No se envía ninguna contraseña, encriptada o en claro, al servidor, y no existe, por tanto, la posibilidad de que un pirata nos robe la contraseña (ni siquiera el hash de la contraseña). Los sistemas operativos compatibles son únicamente Windows Server 2012 R2 y Windows 8.1 (tanto del lado cliente como servidor de conexión). Además, sólo aquellos usuarios miembros del grupo local Administradores (directa o indirectamente) podrán conectarse en modo RestrictedAdmin. Para abrir una conexión en modo RestrictedAdmin necesita escribir el comando mstsc.exe
/restrictedAdmin. Observe que el parámetro /admin viene implícito con el parámetro /restrictedAdmin. RemoteFX, incluido por primera vez con Windows Server 2008 R2 SP1, ha visto evolucionar sus funcionalidades gracias a Windows Server 2012 R2. He aquí las principales mejoras de RemoteFX: •
• •
•
Soporte de DirectX 11.1: en una sesión, RemoteFX gestiona, ahora, DirectX 11.1 sobre los procesadores gráficos virtuales (vGPU) con el objetivo de mejorar la calidad gráfica y dar soporte, también, a la visualización 3D, siempre basada en DirectX 11.1. Soporte de aplicaciones Metro RemoteFX gestiona las aplicaciones Metro introducidas con Windows 8. Soporte extendido de dispositivos USB: RemoteFX puede, ahora, redirigir varios tipos de dispositivos USB, tales como impresoras, teléfonos móviles, lectores/grabadoras de CD, lectores de smartcard, webcams u otros dispositivos USB. Además, los dispositivos USB pueden redirigirse en mitad de una sesión, de forma dinámica, y no sólo durante la apertura de la sesión. Mejora de las conexiones WAN y externas: gracias a las funcionalidades de RemoteFX Adaptative Graphics, RemoteFX Media Streaming y RemoteFX for WAN, se hace mucho más cómodo trabajar a distancia.
Para aprovechar todas las mejoras aportadas por RemoteFX, es preciso utilizar el cliente RDP 8.1. En una infraestructura de servicios de Escritorio remoto con Windows Server 2012 R2, los servicios de rol Agente de conexión a Escritorio remoto son el pilar fundamental. Este servicio de rol permite gestionar el conjunto de sesiones de usuario sobre varios servidores RDS. Esto mejora, a su vez, la experiencia de usuario, agregando las publicaciones RemoteApp, escritorio remoto y escritorio virtual en una vista única. Para ello, almacena el estado de todas las sesiones de todos los servidores, información que recibe mediante servidores RDS. Cuando un usuario se conecta por primera vez sobre un servidor, el Agente de sesiones memoriza esta conexión. Si el usuario pierde la conexión de red, su sesión TS permanece activa sobre el servidor, aunque en estado desconectado. Cuando vuelva a tener conexión de red, y vuelva a conectarse con el servidor, el Agente de sesiones detectará que ya existe una sesión existente y enviará al usuario sobre este servidor RDS. De este modo, el usuario volverá a su sesión anterior en lugar de creársele, potencialmente, una sesión nueva. También se utiliza, por defecto, el servidor de administración de la implementación como punto de unión con la nueva consola de gestión de los servicios de Escritorio remoto. No podrá tener una infraestructura de servicios de Escritorio remoto en Windows Server 2012 R2 sin tener este rol instalado. Es obligatorio, aunque casi transparente.
Implementar los Servicios de Escritorio remoto Desde un punto de vista técnico, los servicios de Escritorio remoto ya están instalados, por defecto, aunque detenidos, con Windows Server 2012 R2. A diferencia de las versiones anteriores a Windows Server 2008 R2, esto servicios se ejecutan, en lo sucesivo, con la cuenta "Servicio de red" en lugar de como local system. La seguridad del sistema se ha visto mejorada y, de este modo, un fallo en el servicio tiene un impacto menor que antes. Como se explica en la base de conocimientos de Microsoft (KB946399), la cuenta "Servicio de red" necesita tres privilegios para ejecutar los servicios de Escritorio remoto: • • •
Ajustar las cuotas de memoria para un proceso (SeIncreaseQuotaPrivilege). Generar auditorías de seguridad (SeAuditPrivilege). Remplazar un token a nivel de proceso (SeAssignPrimaryTokenPrivilege).
Estos tres privilegios no deben eliminarse de la cuenta (mediante una GPO...), o existe el riesgo de no poder ejecutar más estos servicios. Desde Windows Server 2008 es, no obstante, posible detener el servicio RDS, lo que no podía hacerse antes. Puede comprobar el estado actual del servicio así como los estados aceptados por el servicio utilizando el siguiente comando (el nombre corto del servicio no se ha modificado): sc query TermService
El servicio RDS utiliza, por defecto, el puerto TCP 3389. Mientras el acceso remoto no se haya autorizado de manera explícita, el servidor no escucha en el puerto TCP para no exponer los servicios sobre la red. El siguiente comando permite verificar que el puerto TCP 3389 no escucha nada sobre el servidor, por el momento: netstat -an | findstr 3389
Para aprovechar el conjunto de funcionalidades que ofrece Windows Server 2012 R2, se requiere el cliente RDP versión 8.1 (realmente, la versión 6.3.9600, aunque no se corresponde con el sistema operativo). Ya está incluido en Windows 8.1 y Windows Server 2012 R2. En el momento de escribir estas líneas, no existe un cliente RDP 8.1 para sistemas anteriores a Windows 8.1, aunque las versiones 8.0 y 7.0 del cliente RDP siguen siendo compatibles con los servicios de Escritorio remoto de Windows Server 2012 R2, sin las mejoras aportadas por la versión 8.1 del cliente RDP. Los servicios de rol que componen este rol de Servicios de Escritorio remoto son: •
•
• •
•
•
Host de sesión: permite, a un servidor, hospedar aplicaciones o el escritorio completo de Windows. Todos los usuarios pueden conectarse, no sólo los administradores. Se ha eliminado la limitación a dos sesiones concurrentes. Host de virtualización: los servicios de Escritorio remoto se integran con Hyper-V y permiten implementar escritorios o aplicaciones virtuales, en modo pool o personalizado, y presentarlas a los clientes mediante el cliente RDP, RemoteApp o mediante acceso Web. Administrador de licencias: gestiona la asignación de licencias CAL por dispositivo o usuario con el objetivo de conectarse a un servidor RDSH o RDVH. Agente de sesiones: permite repartir las sesiones TS en una infraestructura (o granja de servidores) RDS, así como la reconexión a una sesión existente en una granja. Gestiona, a su vez, el reparto de carga entre los servidores del mismo grupo siempre que no exista una sesión abierta para un usuario determinado. Puerta de enlace: permite a los usuarios habilitados consumir recursos desde Internet siempre que el periférico ejecute el cliente RDC. El flujo RDP (Remote Desktop Protocol), inicialmente sobre el puerto TCP 3389, se encapsula en un canal HTTPS (puerto TCP 443) entre el cliente y la puerta de enlace de los servicios de Escritorio remoto. Esto le va a permitir utilizar una conexión VPN para acceder a los recursos ofrecidos por los servicios de Escritorio remoto. Acceso Web: permite presentar las aplicaciones y los escritorios remotos a los usuarios mediante un simple sitio Web. Está acoplado a la Puerta de enlace de Escritorio remoto, lo que permite aumentar las posibilidades de acceso por parte de los usuarios, en particular desde hoteles, estaciones u otras empresas, donde el acceso a Internet está, a menudo, limitado a un flujo HTTP (TCP 80) y HTTPS (TCP 443).
1. Administración remota Si bien el servicio de Windows ya está instalado, éste no se inicia por defecto. En efecto, el servicio de Escritorio remoto (TermService) está configurado con un arranque Manual, y se configura automáticamente con arranque Automático cuando se habilita la Administración remota o se instalan los servicios de rol Host de sesión de Escritorio remoto o Host de virtualización de Escritorio remoto. De momento no puede utilizarlo para administrar sus servidores de forma remota, es preciso autorizar explícitamente el acceso remoto mediante el Administrador del servidor. Abra la consola Administrador del servidor y haga clic en Servidor local en la zona de navegación. En la parte principal de la consola, dentro de Propiedades para NombreDeServidor, haga clic en Deshabilitado donde indica Escritorio remoto.
Se abre una ventana de Propiedades del sistema, donde la pestaña Acceso remoto permite habilitar el escritorio remoto, con o sin NLA, así como autorizar a ciertos usuarios a conectarse. Escoja la opción Permitir las conexiones remotas a este equipo.
Esta interfaz modifica dos claves del registro: fDenyTSConnections y UserAuthentication, ubicadas en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server. La primera bloquea cualquier conexión TS, será necesario asignarle un valor 0 para autorizar las conexiones, y la segunda exige la autenticación NLA siempre que su valor sea 1. Aparece el siguiente mensaje informativo, haga clic en Aceptar.
La gestión del Firewall de Windows se describe en el capítulo Securizar su arquitectura. Deje la opción Permitir sólo las conexiones desde equipos que ejecuten Escritorio remoto con Autenticación a nivel de red (recomendado) marcada. A continuación, haga clic en Aplicar.
NLA significa Network Level Authentication. El objetivo consiste en luchar contra los ataques llamados hombre en el medio (man in the middle) autenticando al servidor RD antes de que se conecte el usuario. Es posible utilizar varios protocolos para realizar esta tarea: kerberos, TLS/SSL, NTLM. Técnicamente, se basa en el proveedor CredSSP, que utiliza SSPI (Security Service Provider Interface). Una vez superada la fase de autenticación mutua, el cliente provee las credenciales del usuario, que se encriptan dos veces con las claves de sesión SPNEGO y TLS. El Escritorio remoto, destinado especialmente a la administración remota, permite, por defecto, acceder únicamente a los miembros de los grupos Administrador local y Administrador de dominio. Puede agregar otras cuentas haciendo clic en el botón Seleccionar usuarios. Haga clic en el botón Aceptar para cerrar la ventana de las propiedades del sistema Ahora que el acceso remoto está abierto, el servicio RDS está iniciado y escuchando en el puerto TCP y UDP 3389 (una línea para IP versión 4 y otra para IP versión 6):
En efecto, Windows Server 2012 R2 gestiona, ahora, el protocolo UDP para los servicios de Escritorio remoto. La conexión inicial se realiza siempre sobre el puerto 3389 TCP. UDP entra en juego una vez establecida la conexión inicial, para acelera la tasa de transferencia. Sobre una red local, la tasa de transferencia es generalmente buena, entre los 100 Mb/s y 1000 Mb/s. El protocolo UDP no aporta, necesariamente, una mejora importante en el rendimiento, salvo para el uso de RemoteFX. Por el contrario, UDP adquiere sentido cuando hablamos de conexiones de tipo WAN o mediante una puerta de enlace de servicios de Escritorio remoto, donde la tasa de transferencia se ve limitada a la velocidad de su conexión a Internet. Para aprovechar el protocolo UDP, es preciso utilizar, como mínimo, el cliente RDP 8.0. Puede, ahora, utilizar el escritorio remoto para administrar su servidor. Esta funcionalidad no requiere la instalación del rol Escritorio remoto. La administración remota se considera algo indispensable en cualquier servidor, sea cual sea su uso, y no se caracteriza por un rol determinado. La administración remota es muy útil, aunque no supone un avance destacado. ¡Es momento de explotar todo el potencial del rol! Para ello, tras haber instalado los componentes del rol, se configurarán en el marco de ejemplos concretos.
2. Instalación de los servicios de Escritorio remoto Windows Server 2012 R2 utiliza una nueva forma (incluida con Windows Server 2012) de instalar los servicios de Escritorio remoto basada en escenarios que simplifican, así, la instalación de los distintos servicios de rol de Escritorio remoto sobre varios servidores. Este modo de instalación instala y configura también el protocolo de despliegue de
Escritorio remoto que permite administrar el servidor mediante la nueva interfaz de gestión de servicios de Escritorio remoto RDMS. Sigue siendo posible instalar los servicios de Escritorio remoto mediante la instalación basada en roles o características. No obstante, este modo de instalación requiere una administración por GPO o directamente en la base de registro. En efecto, las consolas de administración tsadmin.msc y tsconfig.msc ya no existen en Windows Server 2012 R2. Además, si prevé agregar su servidor RDS 2012 R2 a una granja RDS 2008 R2, tendrá que seleccionar este modo de instalación. Si bien todos los servicios de rol de Escritorio remoto pueden instalarse sobre el mismo servidor, se recomienda separarlos. En la mayoría de casos, los servicios de rol Host de sesión y Host de virtualización se instalan sólo sobre un servidor, el Administrador de licencias se instala, a menudo, sobre un controlador de dominio, y el Acceso Web y la Puerta de enlace se agrupan en otro servidor. ¿Por qué separar los servicios de rol de Escritorio remoto? Desde un punto de vista práctico, es obligatorio para poder configurar en clúster los servidores Host de sesión (RD Session Host) y el Acceso Web (RD Web Access). Otro ejemplo es que, si su infraestructura RDS soporta un gran número de usuarios que utilizan la misma puerta de enlace de los servicios de Escritorio remoto, esta última consumirá bastante tiempo de procesador para el cifrado de los flujos SSL y, por tanto, ralentizará a los usuarios que trabajan en la parte Host de sesión si estos servicios de rol están instalados en el mismo servidor. Observe que la instalación del rol Connection Broker sobre un controlador de dominio está, ahora, soportada, aunque no es una buena práctica. He aquí las principales posibilidades para instalar los servicios de Escritorio remoto: •
•
•
Mediante la instalación de Escritorio remoto: este modo de instalación, también llamado modo escenario, permite implementar sobre uno o varios servidores los servicios de rol de Escritorio remoto mediante un asistente de instalación gráfico. Permite instalar los servicios de rol RD Session Host, RD Web Access y RD Session Broker. Mediante la instalación basada en roles o características: este modo de instalación, idéntico a las versiones anteriores de Windows Server, permite instalar cada servicio de rol de Escritorio remoto de forma unitaria. Será preciso utilizar este modo de instalación para instalar los servicios de rol de Escritorio remoto siguientes: Administrador de licencias de Escritorio remoto y Puerta de enlace de Escritorio remoto. Mediante PowerShell: con PowerShell, veremos que es posible reproducir los dos tipos de instalación anteriores.
a. Requisitos previos
Antes de proceder con la instalación de los servicios de Escritorio remoto, debe asegurar que se respetan, como mínimo, los siguientes requisitos previos: • •
Los servidores afectados por la instalación deben ser miembros del dominio Active Directory. Los servidores afectados por la instalación deben tener una dirección IP fija.
Es también aconsejable crear una jerarquía de unidades organizativas dedicada a los servicios de Escritorio remoto en el seno de Active Directory. El objetivo consiste en poder aplicar las directivas de grupo únicamente a aquellos servidores y equipos virtuales que formen parte de los servicios de Escritorio remoto (principalmente servidores RD Session Host). Otra ventaja "oculta" es que esto le va a permitir organizar mejor su arborescencia de servidores en el seno de su Active Directory.
Para instalar los servicios de Escritorio remoto, debe utilizar una cuenta de usuario que posea, al menos, permisos de Administrador local sobre los servidores afectados por la instalación. b. Instalación Inicio rápido
Como ya hemos mencionado, la instalación de los servicios de Escritorio remoto es algo sencillo, sobre todo utilizando el asistente de instalación en modo Inicio rápido. Este tipo de
instalación implementará los servicios de rol necesarios (RDWEB, Agente de conexión y, o bien RDSH, o bien RDVH) sobre el mismo servidor. Instalación basada en sesiones A continuación, se muestra cómo instalar los servicios de Escritorio remoto basados en sesiones: Desde el futuro servidor de servicios de Escritorio remoto, abra el Administrador del servidor, haga clic en el menú Administrar y, a continuación, Agregar roles y características. Se abre el Asistente para agregar roles y características y le muestra la pantalla Antes de comenzar, haga clic en el botón Siguiente. En la pantalla Seleccionar el tipo de instalación, marque Instalación de Servicios de Escritorio remoto y, a continuación, haga clic en Siguiente. En la pantalla Seleccionar tipo de implementación, marque Inicio rápido y, a continuación, haga clic en Siguiente. En la pantalla Seleccionar escenario de implementación, marque Implementación de escritorio basada en sesión y, a continuación, haga clic en Siguiente. En la pantalla Seleccionar un servidor, seleccione el nombre del servidor afectado por la instalación de los servicios de Escritorio remoto en la columna Grupo de servidores, y haga clic en la flecha situada en el centro para desplazarlo a la columna Seleccionado. Si realiza la instalación desde otro servidor, puede que el nombre del servidor afectado por la instalación no aparezca en la lista Pool de servidores. Será preciso anular la instalación de los servicios de Escritorio remoto, volver al Administrador del servidor, abrir el menú Administrar y seleccionar Agregar servidores para incluir su servidor. Haga clic en el botón Siguiente para continuar con la instalación. En la pantalla Confirmar selecciones, marque la opción Reiniciar automáticamente el servidor de destino en caso necesario y haga clic en el botón Implementar. El Asistente para agregar roles y características le muestra, a continuación, la página Ver progreso que le permite implementar roles y servicios de rol. Una vez se haya reiniciado automáticamente el servidor, abra de nuevo una sesión con la cuenta de usuario que haya utilizado para realizar la instalación de los servicios de Escritorio remoto y, a continuación, abra el Administrador del servidor para terminar la instalación. Este último abrirá, automáticamente, la ventana del Asistente para agregar roles y características en la página Ver progreso. Una vez terminadas las etapas de la instalación con éxito, haga clic en el botón Cerrar.
Una vez finalizado el procedimiento de instalación, su servidor está listo para recibir sesiones de usuario. En efecto, el modo de instalación inicio rápido instala y configura los roles necesarios para los servicios de Escritorio remoto sobre un entorno Windows Server 2012 R2 (servicios de sesión de agente de conexión, acceso Web, servidores host de sesión), la consola de administración de los servicios de Escritorio remoto (RDMS, Remote Desktop Management Service), configura el punto de implementación de los servicios de Escritorio remoto, y crea una colección para el servicio de sesión de Escritorio remoto llamada QuickSessionCollection. Puede, también, observar que este modo de instalación publica de manera automática tres aplicaciones a través de RemoteApp: Calculadora, Paint, WordPad.
Vista del conjunto de una implementación en modo rápido.
Vista de la colección creada por defecto por una implementación en modo rápido. Aparece un icono en la barra de tareas que le advierte sobre la ausencia de licencias. Será preciso disponer de un servidor de licencias, con un periodo de prueba de 120 días. Tendrá que instalar el administrador de licencias de servicios de Escritorio remoto, habilitarlo e instalar las licencias de acceso cliente a los servicios de Escritorio remoto. También tendrá que obtener (o administrar) y asociar al servidor RD Session Broker y al servidor RD Session Host certificados digitales, y precisar, si fuera necesario, la configuración de los parámetros de la colección del servicio de implementación de Escritorio remoto, las conexiones, las aplicaciones publicadas mediante RemoteApp... Y, para finalizar, tendrá evidentemente que instalar las aplicaciones sobre las que podrán acceder los usuarios de los servicios de escritorio remoto. He aquí el equivalente en PowerShell: # Instalación en modo roles y características (opcional) Install-WindowsFeature RDS-RD-Server,RDS-Web-Access,RDS-ConnectionBroker -IncludeManagementTools # Instalación en modo escenario servicio de Escritorio remoto New-RDSessionDeployment -ConnectionBroker rds1.MiEmpresa.Priv -WebAccessServer rds1.MiEmpresa.Priv -SessionHost rds1.MiEmpresa.Priv
# Creación de la colección New-RDSessionCollection -CollectionName QuickSessionCollection -Session Host rds1.MiEmpresa.Priv -ConnectionBroker rds1.MiEmpresa.Priv # Publicación de la calculadora mediante RemoteApp New-RDRemoteApp -CollectionName QuickSessionCollection -Connection Broker rds1.MiEmpresa.Priv -DisplayName Calculadora -Alias Calculadora -FilePath "C:\Windows\system32\calc.exe" -ShowInWebAccess $true -RequiredCommandLine $false # Publicación de WordPad mediante RemoteApp New-RDRemoteApp -CollectionName QuickSessionCollection -Connection Broker rds1.MiEmpresa.Priv -DisplayName WordPad -Alias WordPad -FilePath "C:\Program Files\Windows NT\Accesorios\wordpad.exe" -ShowInWebAccess $true -RequiredCommandLine $false # Publicación de Paint mediante RemoteApp New-RDRemoteApp -CollectionName QuickSessionCollection -Connection Broker rds1.MiEmpresa.Priv -DisplayName Paint -Alias Paint -FilePath "C:\Windows\system32\mspaint.exe" -ShowInWebAccess $true -RequiredCommandLine $false
Observe que la instrucción Install-WindowsFeatures... no es obligatoria. En efecto, la instrucción New-RDSessionDeployment instalará todos los roles y servicios necesarios, como IIS, por ejemplo. Instalación basada en escritorios virtuales La instalación basada en escritorios virtuales no es complicada. No obstante, es preferible crear un disco virtual que contenga una instalación de un cliente Windows. En nuestro caso, utilizaremos un disco virtual que contenga una instalación de Windows 8, instalado y con el sistema preparado. Cabe indicar que la instalación en modo Inicio rápido crea, por defecto, una colección de escritorios virtuales en Pool. Recuerde que, a diferencia de las sesiones basadas en un servidor host de sesión donde todos los usuarios abren una sesión sobre la misma máquina, gestionados por el servidor host de sesión, las sesiones basadas sobre escritorios virtuales se abren sobre máquinas virtuales donde se conecta un único usuario. A continuación se muestra cómo instalar los servicios de Escritorio remoto basados en escritorios virtuales (VDI) en modo Pool: Abra el Administrador del servidor, haga clic en el menú Administrar y seleccione Agregar roles y características. Se abre el Asistente para agregar roles y características. En la pantalla Antes de comenzar, haga clic en Siguiente.
En la pantalla Seleccionar el tipo de instalación, marque Instalar los servicios de Escritorio remoto y, a continuación, haga clic en Siguiente. En la pantalla Seleccionar tipo de implementación, marque Inicio rápido y, a continuación, haga clic en Siguiente. En la pantalla Seleccionar escenario de implementación, marque Implemen-tación de escritorio basada en máquina virtual y, a continuación, haga clic en Siguiente. En la pantalla Seleccionar un servidor, seleccione el servidor sobre el que desea instalar los servicios de Escritorio remoto y haga clic en Siguiente. En la pantalla Seleccionar una plantilla de escritorio virtual, escriba la ruta completa del archivo de disco duro virtual que servirá como modelo y habrá creado previamente y, a continuación, haga clic en Siguiente. En la pantalla Confirmar selecciones, marque la opción Reiniciar automáticamente el servidor de destino en caso necesario y haga clic en el botón Implementar. El Asistente para agregar roles y características le muestra, a continuación, la página Ver progreso que le permite implementar roles y servicios de rol. Una vez se haya reiniciado automáticamente el servidor, abra de nuevo una sesión con la cuenta de usuario que haya utilizado para realizar la instalación de los servicios de Escritorio remoto y, a continuación, abra el Administrador del servidor para terminar la instalación. Este último abrirá, automáticamente, la ventana del Asistente para agregar roles y características en la página Ver progreso. Una vez terminadas las etapas de la instalación con éxito, haga clic en el botón Cerrar.
Si durante la instalación de los servicios de Escritorio remoto en modo Implementación de escritorio basada en máquina virtual observa que se detiene en la etapa Colección de escritorios virtuales - Creación de la colección de escritorios virtuales..., que abriendo el Administrador de Hyper-V, existe alguna máquina virtual además de la máquina virtual QuickMasterVM, en estado iniciado, y que su instalación dura más de 10 minutos, entonces probablemente no tenga ningún servidor DHCP configurado en su red, o bien no es accesible desde las máquinas virtuales que está tratando de implementar (máquina virtual ubicada sobre el switch incorrecto, por ejemplo). Conviene, evidentemente, resolver este problema, de modo que pueda finalizar su implementación. Como con una instalación de los servicios de Escritorio remoto basada en sesiones y en modo de inicio rápido, su servidor está listo para aceptar conexiones de usuario. No obstante, estará limitado en cuanto al número de usuarios que pueden conectarse simultáneamente, puesto que sólo se ha creado una VM durante la instalación. He aquí el equivalente en PowerShell:
# Instalación en modo roles y características (opcional) Install-WindowsFeature Hyper-V,RDS-Virtualization,RDS-Web-Access, RDS-Connection-Broker -IncludeManagementTools -Restart # Instalación en modo escenario servicio de Escritorio remoto, # debe realizarse desde otro equipo. New-RDVirtualDesktopDeployment -ConnectionBroker rdvh1.MiEmpresa.Priv -WebAccessServer rdvh1.MiEmpresa.Priv -VirtualizationHost rdvh1.MiEmpresa.Priv -CreateVirtualSwitch # Atribución de permisos de creación y eliminación de VM # sobre la OU Equipos Grant-RDOUAccess -Domain MiEmpresa.Priv -OU "Computers" -ConnectionBroker rdvh1.MiEmpresa.Priv # Creación de la colección New-RDVirtualDesktopCollection -CollectionName QuickVMCollection -PooledManaged -VirtualDesktopTemplateName "Win8.1 Ent" -VirtualDesktopTemplateHostServer rdvh1.MiEmpresa.Priv -VirtualDesktopAllocation @{"rdvh1.MiEmpresa.Priv" = 1} -StorageType LocalStorage -VirtualDesktopNamePrefix Win81ent -ConnectionBroker rdvh1.MiEmpresa.Priv
c. Implementación estándar
Primera instalación de los servicios de Escritorio remoto en modo sesión La instalación en modo Implementación estándar le permitirá instalar los servicios de rol Escritorio remoto sobre varios servidores, con el objetivo de separar o instalar varios servidores host simultáneamente, aprovechando una instalación más sencilla. A continuación se describe cómo proceder para realizar una instalación de los servicios de Escritorio remoto basada en sesiones, sobre varios servidores (para dos servidores RDSH, rds1.MiEmpresa.Priv y rds2.MiEmpresa.priv, y un servidor RDWA y RDCB, rdsgw.MiEmpresa.Priv en este ejemplo): Abra el Administrador del servidor, haga clic en el menú Administrar y, a continuación, en Agregar roles y características, y seleccione la opción Agregar servidores para agregar los servidores que van a contener, al menos, un servicio de rol de Escritorio remoto En el Administrador del servidor, haga clic en Administrar y, a continuación, en Agregar roles y características. Se abre el Asistente para agregar roles y características. En la pantalla Antes de comenzar, haga clic en Siguiente. En la pantalla Seleccionar el tipo de instalación, marque Instalar los servicios de Escritorio remoto y, a continuación, haga clic en Siguiente.
En la pantalla Seleccionar tipo de implementación, marque Implementación estándar y, a continuación, haga clic en Siguiente. En la pantalla Seleccionar escenario de implementación, marque Implementación de escritorio basada en sesión y, a continuación, haga clic en Siguiente. En la pantalla Revisar servicios de rol, haga clic en Siguiente. En la pantalla Especificar servidor de Agente de conexión a Escritorio remoto, seleccione el servidor que será el RD Connection Broker en la columna Pool de servidores y, a continuación, haga clic en la flecha situada en el centro para deslizarlo en la columna Seleccionado (el servidor rdsgw.MiEmpresa.Priv en nuestro ejemplo). A continuación, haga clic en Siguiente. En la pantalla Especificar servidor de acceso Web de conexión a Escritorio remoto, seleccione el servidor que será el RD Web Acces en la columna Pool de servidores y, a continuación, haga clic en la flecha situada en el centro para deslizarlo en la columna Seleccionado (el servidor rdsgw.MiEmpresa.Priv en nuestro ejemplo). A continuación, haga clic en Siguiente. En la pantalla Especificar servidores host de sesión de Escritorio remoto, seleccione el o los servidores que serán RD Session Host en la columna Pool de servidores y, a continuación, haga clic en la flecha situada en el centro para deslizarlo en la columna Seleccionado (los servidores rds1.MiEmpresa.Priv y rds2.MiEmpresa.Priv en nuestro ejemplo). A continuación, haga clic en Siguiente. En la pantalla Confirmar selecciones, marque la opción Reiniciar automáticamente el servidor de destino en caso necesario y haga clic en el botón Implementar. Tras finalizar la instalación, se reiniciará el servidor. Una vez reiniciado, abra de nuevo una sesión con la cuenta de usuario que haya utilizado para realizar la instalación y, a continuación, abra el Administrador del servidor para que finalice el asistente de instalación y configuración de los servicios de Escritorio remoto. Haga clic en Cerrar. Una vez terminada la instalación de los servicios de Escritorio remoto, sólo los usuarios miembros del grupo Administradores de dominio podrán abrir una sesión sobre los servidores RD Session Host. El motivo es bien simple, el asistente de instalación no ha creado ninguna colección, ni existen aplicaciones publicadas por RemoteApp. Además de seguir las mismas recomendaciones que con la post-instalación de la instalación de los servicios de Escritorio remoto - Inicio rápido, tendrá que crear una colección. A continuación se muestran los comandos equivalentes en PowerShell (basados en sesiones): # Instalación en modo escenario del servicio de Escritorio remoto
New-RDSessionDeployment -ConnectionBroker rdsgw.MiEmpresa.Priv -WebAccessServer rdsgw.MiEmpresa.Priv -SessionHost rds1.MiEmpresa.Priv,rds2.MiEmpresa.Priv
Primera instalación de los servicios de Escritorio remoto en modo escritorio virtual La instalación basada en escritorios virtuales con una implementación estándar es prácticamente idéntica, de modo que no vamos a describirla con detalle. He aquí los comandos equivalentes en PowerShell para un servidor RDVH, rdvh1.MiEmpresa.Priv y un servidor RDWA y RDCB, rdsgw.MiEmpresa.Priv en este ejemplo): # Instalación en modo roles y características (opcional) Install-WindowsFeature Hyper-V,RDS-Virtualization,RDS-Web-Access, RDS-Connection-Broker -IncludeManagementTools -Restart # Instalación en modo escenario del servicio de Escritorio remoto, # debe realizarse desde otro puesto. New-RDVirtualDesktopDeployment -ConnectionBroker rdsgw.MiEmpresa.Priv -WebAccessServer rdsgw.MiEmpresa.Priv -VirtualizationHost rdvh1.MiEmpresa.Priv -CreateVirtualSwitch
Agregar un tipo de implementación Una instalación basada en un despliegue de sesión puede, también, gestionar un despliegue de escritorios virtuales. Para ello, basta con proceder como si se tratara de una nueva instalación: Abra el Administrador del servidor, haga clic en el menú Administrar y seleccione Agregar roles y características. Se abre el Asistente para agregar roles y características. En la pantalla Antes de comenzar, haga clic en Siguiente. En la pantalla Seleccionar el tipo de instalación, marque Instalar los servicios de Escritorio remoto y, a continuación, haga clic en Siguiente. En la pantalla Seleccionar tipo de implementación, marque Implementación estándar y, a continuación, haga clic en Siguiente. En la pantalla Seleccionar escenario de implementación, marque Implemen-tación de escritorio basada en máquina virtual y, a continuación, haga clic en Siguiente. .En la pantalla Revisar servicios de rol, haga clic en Siguiente. En la pantalla Especificar servidor de Agente de conexión a Escritorio remoto, verifique que está seleccionado correctamente su servidor de agente de conexión y haga clic en Siguiente.
En la pantalla Especificar servidor de acceso Web de conexión a Escritorio remoto, verifique que está seleccionado correctamente su servidor de acceso web y haga clic en Siguiente. En la pantalla Especificar servidor host de virtualización de Escritorio remoto, seleccione el servidor que será host de virtualización para los servicios de Escritorio remoto y marque la opción Crear un nuevo conmutador virtual en los servidores seleccionados y, a continuación, haga clic en Siguiente. En la pantalla Confirmar selecciones, marque la opción Reiniciar automáticamente el servidor de destino en caso necesario y haga clic en el botón Implementar. El Asistente para agregar roles y características le muestra, ahora, la opción Ver progreso que le permite supervisar el despliegue de roles y servicios de rol. El servidor host de virtualización reiniciará dos veces durante la instalación, debido a la instalación del rol Hyper-V. Cuando finalicen todas las etapas de instalación con éxito, haga clic en Cerrar. Ejemplo con un servidor Host de sesión, rds1, que también es servidor de Acceso Web y Agente de conexión # Nuevo despliegue de sesiones. New-RDSessionDeployment -ConnectionBroker rds1.MiEmpresa.Priv -WebAccessServer rds1.MiEmpresa.Priv -SessionHost rds1.MiEmpresa.Priv
Ejemplo con un servidor Host de virtualización, rdvh1, y un servidor de Acceso Web y Agente de conexión, rds1. # Instalación en modo servicio de Escritorio remoto, # debe instalarse desde otro puesto. New-RDVirtualDesktopDeployment -ConnectionBroker rds1.MiEmpresa.Priv -WebAccessServer rds1.MiEmpresa.Priv -VirtualizationHost rdvh1.MiEmpresa.Priv -CreateVirtualSwitch # Atribución de permisos de creación y eliminación de VM # sobre la OU Computers Grant-RDOUAccess -Domain MiEmpresa.Priv -OU "Computers" -ConnectionBroker rdvh1.MiEmpresa.Priv
d. Instalación mediante PowerShell
Instalación de los servicios de Escritorio remoto mediante PowerShell # Instalación en modo roles y características Install-WindowsFeature -Name NombreDelRol -IncludeManagementTools Restart
Este cmdlet le permite instalar roles (y/o características) que siguen al atributo Name, así como su consola de administración asociada. Si se requiere el reinicio del servidor, se podrá automatizar gracias al atributo Restart. Es, también, importante destacar que cualquier rol o
servicio de rol necesario para el rol especificado por el atributo Name se instalarán de manera automática, tales como RPC over HTTP, IIS, .NET Framework 4.5... Es posible especificar varios roles al mismo tiempo separándolos por comas (por ejemplo: RDS-SessionHost, RDS-Web-Access, RDS-ConnectionBroker). Para obtener la lista de roles RDS posibles, instalados o no, puede ejecutar el siguiente cmdlet: Get-WindowsFeature *RDS*
Aparece un mensaje de advertencia que le indica que es necesario reiniciar para tener en cuenta la instalación del rol. Si realiza esta instalación desde el Administrador del servidor, y el servidor tiene, también, el rol de controlador de dominio, aparecerá una alerta que le indicará que no se recomienda realizar esta acción. En efecto, instalar el rol de Escritorio remoto sobre un controlador de dominio conlleva verdaderos riesgos que debe evaluar cuidadosamente. Una vez ejecutado el cmdlet, los roles y servicios de rol están instalados, aunque su servidor no podrá, de momento, responder a las consultas de los clientes puesto que falta, todavía, configurar los servicios de Escritorio remoto. Esta acción puede realizarse mediante RDM (Remote Desktop Manager), por directiva de grupo (GPO) o incluso mediante PowerShell. Además, para una instalación con varios servidores, con separación de roles, habrá que utilizar varios cmdlets PowerShell del tipo: # Instalación en modo roles y características (remoto) Invoke-Command -ComputerName NombreDeServidor -Command{InstallWindowsFeature -Name NombreDeRol -IncludeManagementTools -Restart }
El cmdlet PowerShell más eficaz para instalar los servicios de Escritorio remoto basado en sesiones es el siguiente: # Instalación del servicio de Escritorio remoto New-RDSessionDeployment -ConnectionBroker rds1.MiEmpresa.Priv
-WebAccessServer rds1.MiEmpresa.Priv -SessionHost rds1.MiEmpresa.Priv
Tiene la ventaja de instalar y pre-configurar los servicios de Escritorio remoto sobre uno o varios servidores de forma simultánea, con un único cmdlet. Para conocer más cmdlets relacionados con la instalación, consulte las secciones Instalación Inicio rápido e Implementación estándar en este mismo capítulo. Para tener una idea de todos los cmdlets posibles puede utilizar el siguiente comando PowerShell: Get-Command *-RD*
3. Presentación del Administrador de Servicios de Escritorio remoto En un entorno de Escritorio remoto Windows Server 2012 R2, lo esencial de la configuración y de la administración de los servicios de Escritorio remoto se realiza mediante la nueva consola de administración de servicios de Escritorio remoto (RDMS, Remote Desktop Management Services), o por línea de comando PowerShell. Como hemos visto durante la instalación, por defecto, una infraestructura de Escritorio remoto en Windows Server 2012 R2 requiere, como mínimo, tres servicios de rol de Escritorio remoto: • • •
RD Connection Broker, que gestiona la infraestructura RDS, las conexiones de los usuarios y el reparto de carga de red. RD Web Access, que se encarga de proveer a los usuarios un portal de acceso Web para la presentación de las aplicaciones y escritorios públicos. Y, o bien RD Session Host (servidor de sesión), o bien RD Virtualization Host (servidor de escritorio remoto virtual).
A todo esto se le debe agregar, obligatoriamente, un servidor de licencias de servicios de Escritorio remoto (RD Licensing). Con Windows Server 2012 R2, los servicios de Escritorio remoto se articulan en torno al servicio de rol Agente de conexión, incluso aunque sólo tenga un servidor host (de sesión o de virtualización), y aunque no utilice la gestión de los perfiles de usuario. El servidor que posee el servicio de rol Agente de conexión es, también, el servidor de implementación de los servicios de Escritorio remoto, servicio que permite, en particular, configurar el conjunto de servicios de Escritorio remoto. La consola de administración de servicios de Escritorio remoto RDMS, integrada con el Administrador del servidor, le obligará a abrir este último para acceder a la consola RDMS y configurar, así, su infraestructura RDS. La primera sección Información general le ofrece, como su propio nombre indica, una vista general de su infraestructura de servicios de Escritorio remoto. Esta pantalla le
permite agregar servidores a los servicios de Escritorio remoto y, también, administrar la configuración de alta disponibilidad del servicio de rol Connection Broker. Veremos esto un poco más adelante en este capítulo.
La segunda sección Servidores le permite ver la lista de servidores que forman parte de su infraestructura RDS, y le permite, también, agregar roles y características sobre estos servidores y recopilar eventos. Encontrará, también, la herramienta Best Practice Analyzer para los servicios de Escritorio remoto, que conviene ejecutar una vez terminadas la instalación y configuración.
La siguiente sección, Colecciones, le permite modificar, mediante el menú Tareas en la sección Colecciones, los parámetros de implementación comunes a toda la infraestructura RDS conectada a su servidor de Agente de conexión, tales como: el método de autentificación, el modo de licenciamiento, los certificados... También podrá agregar nuevas colecciones. La sección Conexiones le mostrará todas las conexiones activas sea cual sea su colección de origen, y desde aquí podrá enviar un mensaje, tomar el control sobre la sesión (Instantánea en el submenú), forzar la desconexión o cerrar la sesión del usuario conectado.
Para terminar con la lista de secciones, encontrará, a continuación, la lista de colecciones disponibles. Con una instalación en modo Inicio rápido, se crea una colección llamada QuickSessionCollection si su instalación se basa en hosts de sesión o QuickVMCollection si su instalación se basa en hosts de virtualización. Con cualquier otro modo de instalación, tendrá que crear una nueva colección para que los usuarios puedan conectarse. Desde la pantalla de una colección, es posible modificar las propiedades de dicha colección y gestionar las aplicaciones RemoteApp. Si se trata de una colección de sesión, podrá agregar servidores host de sesión suplementarios o administrar las conexiones de dicha colección. Si se trata de una colección de escritorios virtuales, podrá agregar un escritorio virtual o recrear todos los escritorios virtuales de la colección. La vista de una colección de sesión QuickSessionCollection:
Vista de una colección de virtualización QuickVMCollection:
Configuración
1. Propiedades de implementación Para acceder a las propiedades de implementación, abra el Administrador del servidor, vaya a la sección Servicios de escritorio remoto, Colecciones y, a continuación, en el menú Tareas seleccione la opción Editar propiedades de la implementación: •
•
• •
Pestaña Puerta de enlace de Escritorio remoto: permite definir el nombre de la puerta de enlace de los servicios de Escritorio remoto que debe utilizarse así como el método de autenticación. Pestaña Administración de licencias de Escritorio remoto: permite definir el modo de licenciamiento (por usuario o por dispositivo) y el servidor de licencias que se debe utilizar. Pestaña Acceso Web a Escritorio remoto: muestra, simplemente, la lista de servidores de Acceso Web. Pestaña Certificados: le permite importar certificados o generar certificados autofirmados para los servicios de Escritorio remoto.
•
Pestaña Active Directory (requiere, al menos, un despliegue virtual): permite indicar la unidad organizativa donde se crearán las cuentas de equipos correspondientes a los escritorios virtuales de los servicios de Escritorio remoto.
•
Pestaña Ubicación de exportación de escritorio virtual (requiere, al menos, un despliegue virtual): permite especificar la ubicación donde se almacenarán los modelos de escritorio virtual.
Los parámetros de despliegue afectan a todas las colecciones y todos los servidores asociados a esta implementación. Todos estos parámetros afectan, por tanto, a la implementación de los servicios de Escritorio remoto en su conjunto.
2. Configuración de una colección de sesiones En un entorno RDS en Windows Server 2012 R2, todos los servidores host de sesión de una misma colección comparten los mismos parámetros de sesión, de seguridad, de administración de dispositivos... Observe que un servidor host de sesión no puede pertenecer a más de una colección.
He aquí el procedimiento que debe seguir si ha realizado una instalación en Implementación estándar o si ha eliminado la colección por defecto o, simplemente, si desea crear una nueva colección: Abra el Administrador del servidor, vaya a la sección Servicios de Escritorio remoto, Colecciones y, a continuación, en el menú Tareas, seleccione Crear colección de sesiones. Se abre el asistente Crear colección y aparece la pantalla Antes de comenzar, haga clic en Siguiente. En la pantalla Nombre de colección, escriba el nombre de su colección y, eventualmente, una descripción. A continuación, haga clic en Siguiente. En la pantalla Especificar servidores host de sesión de Escritorio remoto, seleccione el o los servidores que formarán parte de dicha colección y, a continuación, haga clic en Siguiente. En la pantalla Especificar grupos de usuarios, agregue los grupos de usuarios que tendrán autorización de acceso sobre la colección y, a continuación, haga clic en Siguiente. En la pantalla Especificar discos de perfil de usuario, desmarque la opción Habilitar discos de perfil de usuario, y haga clic en Siguiente. En la pantalla Confirmar selecciones, haga clic en el botón Crear. Para finalizar, en la pantalla Ver progreso, haga clic en Cerrar. He aquí el equivalente en PowerShell: # Creación de la colección New-RDSessionCollection -CollectionName MiColeccionDeSesiones -CollectionDescription "" -SessionHost rds1.MiEmpresa.Priv -ConnectionBroker rds1.MiEmpresa.Priv
Tendrá, ahora, una colección de servidores de sesión configurada de forma sencilla, sin aplicaciones RemoteApp. Propiedades de una colección de Hosts de sesión He aquí una descripción de las propiedades de una colección de servidores host de sesión: •
Pestaña General: en esta pestaña puede modificar el nombre y la descripción de la colección. La opción Mostrar la colección de sesiones en Acceso Web de Escritorio remoto le permitirá mostrar o no la colección en el Acceso Web. Observe que esta opción no estará disponible si se han publicado aplicaciones RemoteApp en dicha colección.
#Ejemplo de modificación de la descripción en PowerShell Set-RDSessionCollectionConfiguration -CollectionName MiColeccionDeSesiones -CollectionDescription "Nueva descripción" •
Pestaña Grupos de usuarios: le permite administrar los grupos de usuarios que pueden conectarse a los servidores host de sesión y a las aplicaciones RemoteApp de la colección. Preste atención a los permisos suplementarios que deben aplicarse para RemoteApp, para saber más consulte la sección que aborda RemoteApp.
# Agregar autorizaciones de conexión para el grupo Usuarios de # dominio (para definir más grupos, sepárelos con comas). Set-RDSessionCollectionConfiguration -CollectionName MiColeccionDe Sesiones -UserGroup "MIEMPRESA\Usuarios de dominio" •
Pestaña Sesión: puede definir la duración de las sesiones inactivas, así como el comportamiento que desea cuando se alcanza el tiempo de inactividad. ¿Por qué gestionar estos elementos? Si algún usuario no se desconecta, su sesión, así como los programas en memoria, permanecen en el servidor. El consumo de recursos del sistema, mantenido, provoca que el servidor no pueda aceptar conexiones de otros usuarios.
He aquí una explicación y una recomendación para la configuración:
• •
•
•
Finalizar una sesión desconectada: cierra de forma arbitraria cualquier sesión desconectada. Valor propuesto: 2 horas. Límite de la sesión activa: obliga al usuario a cerrar su sesión incluso si está activo. Esto permite luchar contra fugas de memoria en las aplicaciones, y evitar que un usuario no cierre jamás su sesión. Valor propuesto: 12 horas. Límite de la sesión inactiva: cierra de forma arbitraria cualquier sesión mantenida por un cliente pero que no tiene actividad en el teclado/ratón. Valor propuesto: 4 horas. Cuando se alcanza el límite de una sesión o se pierde la conexión: acción que desea realizar cuando se produce una de ambas situaciones. Valor sugerido Desconectar de la sesión.
La situación es la siguiente:
El tiempo máximo, antes del cierre de una sesión, es igual a: Límite de sesión activa + Finalizar una sesión desconectada = 14 horas. Observará que el usuario dispone, todavía, de 2 horas potenciales para volver a conectarse sin perder su sesión.
Antes de salvaguardar un servidor de host de sesión por la noche, se recomienda cerrar todas las sesiones de Escritorio remoto del servidor de forma arbitraria. Esto evita que se produzcan errores sobre los archivos abiertos en modo exclusivo y permite salvaguardar perfiles RDS que se copian tras el cierre de sesión sobre su carpeta). He aquí los comandos equivalentes en PowerShell:
# Límite de sesión y carpeta temporal Set-RDSessionCollectionConfiguration -CollectionName MiColeccionDeSesiones -ActiveSessionLimiteMin 720 -IdleSessionLimitMin 240 -BrokenConnectionAction Disconnect -AutomaticReconnectionEnable $true -DisconnectedSessionLimitMin 120 -TemporaryFoldersDeletedOnExit $true -TemporaryFoldersPerSession $true # Valores admisibles # los valores numéricos se definen en minutos # -BrokenConnectionAction None/Disconnect/LogOff •
Pestaña Seguridad: esta pestaña le permite administrar la capa de seguridad y el nivel de cifrado del protocolo RDP.
He aquí los comandos equivalentes en PowerShell: # Security Set-RDSessionCollectionConfiguration -CollectionName MiColeccionDeSesiones -SecurityLayer Negociate -EncryptionLevel ClientCompatible -AuthenticateUsingNLA $true # Valores admisibles # -SecurityLayer RDP/Negociate/SSL (por defecto Negociate) # -EncryptionLevel Low/ClientCompatible/High/FipsCompliant (por defecto: ClientCompatible) •
Pestaña Equilibrio de carga: si dispone de varios servidores host de sesión en su colección y éstos no tienen el mejor rendimiento, esta pestaña le será útil para repartir la carga entre ellos, así como administrar el número máximo de sesiones por servidor host de sesión.
He aquí los comandos equivalentes en PowerShell: # Reparto de carga (ejemplo para 2 servidores host de sesión) $LoadBalanceObjectsArray = New-Object System.Collections. Generic.List[Microsoft.RemoteDesktopServices.Management. RDSessionHostCollectionLoadBalancingInstance] $LoadBalanceSessionHost1 = New-Object Microsoft.RemoteDesktopServices .Management.RDSessionHostCollectionLoadBalancingInstance ("MiColeccionDeSesiones",80,500,"rds1.MiEmpresa.Priv") $LoadBalanceObjectsArray.Add($LoadBalanceSessionHost1) $LoadBalanceSessionHost2 = New-Object Microsoft.RemoteDesktopServices .Management.RDSessionHostCollectionLoadBalancingInstance ("MiColeccionDeSesiones",100,700,"rds1.MiEmpresa.Priv")
$LoadBalanceObjectsArray.Add($LoadBalanceSessionHost2) Set-RDSessionCollectionConfiguration -CollectionName MiColeccionDeSesiones -LoadBalancing $LoadBalanceObjectsArray
# Valores admisibles # -LoadBalancing Array[CollectionName,Weight,NumberOfSessions, RDSessionHost] •
Pestaña Configuración de cliente: en esta pestaña puede administrar la redirección del lector de audio y vídeo, las tarjetas y dispositivos Plug-and-Play, etc. para las conexiones. A esto se le añade la administración de las redirecciones de las impresoras y el número máximo de pantallas redirigidas.
He aquí los comandos equivalentes en PowerShell: # Configuración de cliente Set-RDSessionCollectionConfiguration -CollectionName MiColeccionDeSesiones -ClientDeviceRedirectionOptions AudioVideoPlayBack, AudioRecording,SmartCard,PlugAndPlayDevice,Drive,ClipBoard -ClientPrinterRedirected $true -ClientPrinterAsDefault $true -RDEasyPrintDriverEnable $true -MaxRedirectedMonitors 16
# # # # #
Valores admisibles Varias opciones separadas por comas -ClientDeviceRedirectionOptions None/AudioVideoPlayBack/AudioRecording/ SmartCard/PlugAndPlayDevice/Drive/ClipBoard/COMPort/LPTProt/USBPort/ TimeZone-MaxRedirectedMonitors [1-16], 16 por defecto
Las CustomRDPProperty son opciones que permiten, en particular, agregar parámetros complementarios a la conexión RDS. Por ejemplo, un archivo RDP no es sino un conjunto de CustomRDPProperty, para darse cuenta de esto, edite un archivo RDP con ayuda de Notepad. Si desea más información acerca de CustomRdpProperty: http://go.microsoft.com/fwlink/?LinkId=139899 •
Pestaña Discos de perfil de usuario: Windows Server 2012 R2 implementa una nueva forma de administrar los perfiles de los usuarios de los servicios de Escritorio remoto: los discos de perfil de usuario. Un disco de perfil de usuario se presenta bajo la forma de un disco virtual con un formato *.vhdx y contiene, por defecto, los datos del perfil de un usuario, o el equivalente al perfil de usuario que se encuentra, habitualmente, en C:\Usuarios\%username%. A esto, puede incluirle carpetas externas al perfil o excluir carpetas propias del perfil. Los discos del perfil de usuario permiten, por ejemplo, resolver problemas de sincronización de ciertos tipos de archivos, tales como los archivos PST de Outlook y los archivos de base de datos como Access.
Estos discos de perfil de usuario deben almacenarse sobre un recurso compartido accesible por todos los servidores host de la colección y, preferentemente, por enlaces de red rápidos. Además, el conjunto de servidores de la colección deben tener autorización Control Total sobre el recurso compartido y la carpeta asociada. Cuando un usuario abre una sesión sobre uno de los servidores de la colección, el servidor monta el disco de perfil de usuario directamente en su carpeta de perfil (por defecto: C:\Usuarios) mediante un enlace simbólico. Esto resulta transparente al usuario, y a las aplicaciones. He aquí los comandos equivalentes en PowerShell: # Creación de la carpeta de almacenamiento de discos virtuales # de perfil de usuario (sobre DC2012, en este ejemplo) mkdir D:\UserProfileDisk # Aplicación de los permisos necesarios para usar los discos # virtuales de perfil usuario (para DC2012 en este ejemplo) # Permisos asignados en este ejemplo: # - Control total para RDS1, nuestro servidor RDSH, # - Control total para el grupo de Administradores de empresas, # - Control total para la cuenta Sistema, # - Control total para la cuenta Creador Propietario (sólo # para aquellas carpetas y archivos hijos). $RepUserDisk = "D:\UserProfileDisk" $acl = Get-Acl $RepUserDisk $acl.SetAccessRuleProtection($True, $False) $rule = new-object System.Security.AccessControl. FileSystemAccessRule("MIEMPRESA\RDS1$", "FullControl", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.AddAccessRule($rule) $rule = new-object System.Security.AccessControl.FileSystemAccessRule ("MIEMPRESA\Administradores de empresas", "FullControl", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.AddAccessRule($rule) $rule = new-object System.Security.AccessControl.FileSystemAccessRule ("Sistema", "FullControl", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.AddAccessRule($rule) $rule = new-object System.Security.AccessControl.FileSystemAccessRule ("CREADOR PROPIETARIO", "FullControl", "ContainerInherit, ObjectInherit", "InheritOnly", "Allow") $acl.AddAccessRule($rule) Set-acl $RepUserDisk $acl # Creación del recurso compartido Userdisk con autorización # de control total (para DC2012 en este ejemplo) New-SMBShare -Name UserProfileDisk -Path D:\UserProfileDisk -FullAccess "MIEMPRESA\RDS1$","MIEMPRESA\Administradores de empresas" # Configuración de los discos de perfil de usuario # para una colección de sesiones
Set-RDSessionCollectionConfiguration -CollectionName MiColeccionDeSesiones -EnableUserProfileDisk -DiskPath \\DC2012\UserProfileDisk -MaxProfileDiskSizeGB 5
# # # # #
Valores posibles : -IncludeFolderPath "RutaDeLaCarpeta" -ExcludeFolderPath "RutaDeLaCarpeta" -IncludeFilePath "RutaDelArchivo" -ExcludeFilePath "RutaDelArchivo"
a. Instalación de una aplicación sobre un servidor de sesiones
Cuando instala una aplicación sobre un servidor RDS, debe indicar que va a tener lugar una instalación. Para ello, puede utilizar el comando: change user /install
Una vez terminada la instalación, puede volver al modo estándar: change user /execute
Si el instalador utiliza la tecnología MSI, el comando change user no es necesario, puede ejecutarlo directamente. Esta manipulación no es obligatoria en Windows Server 2012 R2 con las aplicaciones certificadas para Windows Server 2012 o Windows Server 2012 R2, aunque supone una buena práctica si la aplicación que instala es anterior y no está certificada para Windows Server 2012/2012 R2. Windows Server 2012 existe, únicamente, en versión de 64 bits. Wow64 permite ejecutar aplicaciones de 32 bits mediante emulación. Esto supone, en cualquier caso, una carga complementaria y no permite aprovechar al máximo la capacidad de la plataforma técnica. Verifique sistemáticamente si existe una versión de 64 bits antes de instalar el componente o la aplicación en cuestión. b. Mantenimiento de un servidor de sesiones
A diferencia de un servidor Web, por ejemplo, pasar un servidor host de sesiones al modo de mantenimiento es más complicado de cara a los usuarios. Pueden tener documentos abiertos, no salvaguardados, correos electrónicos en curso, etc. Afortunadamente, existen herramientas adaptadas a estas situaciones disponibles para cortar el servicio de forma controlada. Para empezar, puede autorizar o no el inicio de sesión de un usuario mediante el comando change logon. Este comando acepta varios argumentos:
• • • • •
/QUERY: muestra el modo de inicio de sesión actual. /ENABLE: autoriza los inicios de sesión de usuario. /DISABLE: prohíbe los inicios de sesión de usuario. /DRAIN: prohíbe los nuevos inicios de sesión de usuario, aunque autoriza las reconexiones a las sesiones existentes. /DRAINUNTILRESTART: prohíbe los nuevos inicios de sesión de usuario hasta que el servidor haya reiniciado, aunque autoriza las reconexiones a las sesiones existentes.
Para cerrar todas las conexiones a la vez, puede utilizar el siguiente script: for /f "skip=2 tokens=2," %i in (’query session’) do logoff %i
El comando query session permite enumerar todas las sesiones de usuario del servidor. Una vez se obtiene la lista de sesiones, anote el número de sesión para el que desea realizar alguna acción. A continuación, podrá: • • • • •
Cerrar la sesión (cierra todas las aplicaciones abiertas, sin realizar una copia de seguridad): logoff XXX Desconectar al usuario (todas las aplicaciones siguen abiertas, aunque el usuario se desconecta): tsdiscon XXX Eliminar una sesión por la fuerza: session reset XXX Conectarse a esta sesión: tscon XXX Enviar un mensaje al usuario: msg XXX « Cierre, por favor, su sesión »
c. Mejora en la experiencia de usuario sobre un servidor de sesiones
Instalación de la experiencia del usuario La experiencia del usuario supone agregar la funcionalidad Experiencia de escritorio, presente por defecto en una edición cliente de Windows (como, por ejempo, Windows 8.1), sobre los servidores host de sesión. Esto incluye, en particular, al lector Windows Media, la reproducción de archivos AVI, el centro de sincronización, la grabadora de Windows, Herramientas de captura de pantalla, temas de Windows y la gestión multi-pulsación. Para aprovechar todo esto, instale las características Experiencia de escritorio y Servicios de Escritura con lápiz y Escritura a mano. Reinicie el servidor.
Para aprovechar plenamente las mejoras gráficas aportadas por la activación de la experiencia del usuario (del lado servidor), necesitará una conexión con alta tasa de trasferencia entre el cliente y el servidor (como mínimo 10 Mb/s) y configurar el cliente RDP.
Activación de la experiencia del usuario auditiva Para aprovechar completamente el uso del sonido en una sesión de Escritorio remoto, es necesario iniciar el servicio Audio de Windows y configurarlo en arranque automático. Gestión del entorno mediante directivas de grupo Es posible, incluso necesario, recurrir a una directiva de grupo para modificar el entorno de los usuarios que abran una sesión sobre el host de sesión. Será posible mostrar u ocultar iconos en el escritorio o prohibir el acceso a ciertos dispositivos, o configurar los parámetros de Internet Explorer, por ejemplo. Para ello, tendrá que crear una nueva directiva de grupo y asociarla a la unidad organizativa que contenga sus servidores de host de sesión. Defina los parámetros de usuario de la directiva tal y como desee, y habilite la opción Configurar el modo de procesamiento de bucle invertido de la directiva de grupo de usuario seleccionando el modo Combinar. Encontrará este parámetro en Configuración del equipo - Directivas - Plantillas administrativas - Sistema/Directiva de grupo.
Administración de la impresión La gestión de la impresión y, en particular, de los controladores de las impresoras sigue siendo un asunto importante en un entorno de Terminal Services. Windows Server 2012 R2 utiliza la funcionalidad Easyprint para superar los distintos problemas. Se implementa en tsprint.dll, tanto en 32 como en 64 bits, del lado cliente o del lado servidor. Los requisitos previos del lado cliente son los siguientes: • •
Cliente RDC 6.1 como mínimo. Framework .Net 3.0 Service Pack 1.
Observe que, si el cliente no cumple estos requisitos previos, será preciso instalar los controladores de impresión sobre el servidor. De otro modo, Easyprint permite ver, desde el servidor RDS, el conjunto de propiedades de la impresora, sin tener que instalar el controlador en el propio servidor. Para ello, se comporta como un proxy y redirige todas las llamadas a la interfaz sobre el controlador del lado cliente. Convierte la impresión de un formato GDI a un formato XPS (siempre que no se trate ya de un formato XPS) sobre el servidor, y lo envía al cliente en la sesión RDP, a través de un canal virtual (XPS over RDP). Una vez en el puesto cliente, si el controlador de impresión es compatible con XPS, el documento se imprime directamente. En caso contrario, se convierte de nuevo del formato XPS al formato GDI y se imprime.
Ahora, es posible restringir el número de impresoras que se conectan desde el puesto cliente mediante una GPO. El inicio de sesión se ve, así, acelerado, y la impresora por defecto del puesto cliente basta en la mayoría de casos. Para aplicar esta restricción mediante GPO, debe habilitar el parámetro: Configuración del equipo - Plantillas administrativas - Componentes de Windows - Servicios de Escritorio remoto - Host de sesión de Escritorio remoto - Redirección de impresora.
3. Configuración de una colección de escritorios virtuales El Escritorio remoto y VDI (Virtual Desktop Infrastructure) resultan una solución integrada. A diferencia de los servicios de Escritorio remoto clásicos donde varios usuarios abrían una sesión sobre un servidor host de sesión, una infraestructura de escritorios virtuales le permite dedicar una máquina virtual a cada usuario, y éstos se conectan a su máquina virtual a través de los servicios de Escritorio remoto. Hyper-V soporta los escritorios virtuales, en particular mediante el servicio de Agente de conexión de los servicios de Escritorio remoto y, eventualmente, SCVMM (el administrador de máquinas virtuales). El objetivo es complementario al de un servidor de Escritorio remoto clásico: se trata de proveer un escritorio remoto sobre un cliente Windows (Windows 8.1, por ejemplo) a un usuario. Esta asignación puede ser temporal (pool de VM) o permanente (escritorio personal). Esta flexibilidad permite cubrir necesidades muy específicas:
• •
•
Ciertas aplicaciones que no funcionan o no están soportadas salvo en un OS cliente, o donde el modelo de licenciamiento es más ventajoso con OS de tipo cliente. Ciertos usuarios deben tener privilegios de «administrador» sobre la máquina (desarrolladores remotos, etc.). De este modo, no son administradores de servidores de servidores RDS. Gracias a los escritorios virtuales personales, el usuario es administrador de la máquina virtual donde está conectado, y ya no sobre el todo servidor. En el caso de aplicaciones temporales, cuando finaliza la solución temporal, la máquina virtual vuelve, automáticamente, a su estado final (disco de rollback).
Este tipo de arquitectura está orientada a una solución multiservidor: • • •
Un servidor que juega el rol de agente de conexión y despacha las conexiones de los usuarios (RDS-Connection-Broker). Uno o varios servidores Hyper-V que albergan máquinas virtuales. Estas máquinas deben ser estrictamente idénticas (con los mismos programas instalados). Las máquinas virtuales deben ser de primera generación, pues las máquinas virtuales de segunda generación no están soportadas.
Como con las colecciones de sesiones, con un entorno RDS en Windows Server 2012, todos los servidores host de virtualización de una misma colección comparten los mismos parámetros de sesión, de seguridad, de gestión de dispositivos... He aquí cómo crear una nueva colección de escritorios virtuales en pool: Abra el Administrador del servidor, navegue a la sección Servicios de Escritorio remoto, Colecciones y, a continuación, en el menú Tareas seleccione la opción Crear una colección de escritorios virtuales. Se abre el asistente Crear una colección y aparece la pantalla Antes de empezar, haga clic en Siguiente. En la pantalla Asignar nombre a la colección, escriba el nombre de su colección y, eventualmente, una descripción. A continuación, haga clic en Siguiente. En la pantalla Especifique el tipo de colección, seleccione el tipo de colección que desea aplicar y haga clic en Siguiente. En la pantalla Especifique la plantilla de escritorio virtual, seleccione un modelo que haya creado previamente y, a continuación, haga clic en Siguiente. En la pantalla Especificar configuración de escritorio virtual, seleccione la opción Proporcionar configuración de instalación desatendida y haga clic en Siguiente.
En la pantalla Especificar la configuración de instalación desatendida, seleccione el huso horario, el dominio y, eventualmente, una unidad organizativa y, a continuación, haga clic en Siguiente. En la pantalla Especifique los usuarios y grupos de usuarios, si fuera necesario, agregue los grupos de usuario que tendrán permisos de acceso a la colección, modifique el número de escritorios virtuales que desea crear y el prefijo del nombre. A continuación, haga clic en Siguiente. En la pantalla Especificar asignación de escritorio virtual, haga clic en Siguiente. En la pantalla Especificar almacenamiento de escritorios virtuales, puede modificar el tipo y la ubicación del almacenamiento de los escritorios virtuales (archivos de las máquinas virtuales). En nuestro ejemplo, mantendremos los valores por defecto, haciendo clic en Siguiente. En la pantalla Especificar discos de perfil de usuario, desmarque la opción Habilitar discos de perfil de usuario, y haga clic en Siguiente. En la pantalla Confirmar selecciones, haga clic en el botón Crear, aparece la pantalla Ver progreso que le muestra el grado de avance. Para terminar, en la pantalla Ver resultados, haga clic en Cerrar.
He aquí los comandos equivalentes en PowerShell: # Creación de la colección New-RDVirtualDesktopCollection -CollectionName MiColeccionDeVMs -Description "" -PooledManaged -VirtualDesktopTemplateName "Windows 8.1 Ent - Sysprep" -VirtualDesktopTemplateHostServer rdvh1.MiEmpresa.Priv -VirtualDesktopAllocation @{"rdvh1.MiEmpresa.Priv" = 2} -Domain "MiEmpresa.Priv" -OU "OU=Escritorios virtuales,DC=miempresa,DC=priv" -UserGroup "MIEMPRESA\Usuarios de dominio" -StorageType LocalStorage -VirtualDesktopNamePrefix Win8ent -ConnectionBroker rds1.MiEmpresa.Priv -UserProfileDiskPath \\DC2012\UserProfilDisk -MaxUserProfileDiskSizeGB 5 # # # # # # # # #
El parámetro PooledManaged puede remplazarse por: -PooledManaged -PooledUnmanaged -PersonnalManaged -PersonnalUnmanaged El parámetro CustomSysprepUnattendFilePath permite indicar la ruta hacia un archivo de respuestas de sysprep de formato XML -CustomSysprepUnattendFilePath "RutaDelArchivoXML"
Una vez ejecutado este cmdlet, las cuentas de equipo para los escritorios virtuales se crean correctamente en la unidad organizativa Escritorios virtuales.
Propiedades de una colección de Host de virtualización •
Pestaña General: esta pestaña presenta la misma información que para una colección de sesiones con algunos datos suplementarios, tales como la posibilidad de habilitar el retraso de guardado.
He aquí los comandos equivalentes en PowerShell: # Configuración del cliente Set-RDVirtualDesktopCollectionConfiguration -CollectionName MiColeccionDeVMs -CollectionDescription "" # Valores posibles # -SaveDelayMinutes •
•
Pestaña Escritorios virtuales: todos los campos son de solo lectura. Algunos pueden configurarse durante la creación de la colección, y otros en la configuración de la implementación. Pestaña Grupos de usuarios: esta herramienta es idéntica a la pestaña Grupos de usuarios para una colección de sesiones.
He aquí los comandos equivalentes en PowerShell:
# Agregar autorizaciones de conexión para el grupo Usuarios de # dominio (para definir varios grupos, sepárelos por comas). Set-RDVirtualDesktopCollectionConfiguration -CollectionName MiColeccionDeVMs -UserGroup "MIEMPRESA\Usuarios de dominio" •
Pestaña Cliente: encontrará en esta pestaña la misma información que para una colección de sesiones.
He aquí los comandos equivalentes en PowerShell: # Configuración del cliente Set-RDVirtualDesktopCollectionConfiguration -CollectionName MiColeccionDeVMs -ClientDeviceRedirectionOptions AudioVideoPlayBack, AudioRecording,SmartCard,PlugAndPlayDevice,Drive,ClipBoard -RedirectClientPrinter $true -RedirectAllMonitors $true
# # # # #
Valores posibles Es posible seleccionar varios separados por comas -ClientDeviceRedirectionOptions None/AudioVideoPlayBack/AudioRecording /SmartCard/PlugAndPlayDevice/Drive/ClipBoard/COMPort/LPTProt/USBPort/ TimeZone •
Pestaña Discos de perfiles de usuario: esta pestaña es idéntica a la pestaña Discos de perfil de usuario de una colección de sesiones.
He aquí los comandos equivalentes en PowerShell: # Creación de la carpeta de almacenamiento de discos virtuales # de perfil de usuario mkdir UserProfileDisk on c:\ New-SMBShare -Path D:\UserProfileDisk -Name UserProfileDisk # Agregar autorizaciones de conexión para el grupo de Usuarios de # dominio (para definir varios grupos, sepárelos por comas). Set-RDVirtualDesktopCollectionConfiguration -CollectionName MiColeccionDeVMs -EnableUserProfileDisk -DiskPath \\DC2012\UserProfileDisk -MaxProfileDiskSizeGB 5
# # # # #
Valores posibles : -IncludeFolderPath "RutaDeLaCarpeta" -ExcludeFolderPath "RutaDeLaCarpeta" -IncludeFilePath "RutaDelArchivo" -ExcludeFilePath "RutaDelArchivo"
a. Agregar escritorios virtuales a una colección - Creación de un escritorio virtual
Puede resultar útil saber cómo agregar escritorios virtuales a una colección de escritorios virtuales. Para ello, simplemente hay que seguir el siguiente procedimiento sencillo: Abra el Administrador del servidor, vaya a la sección Servicios de Escritorio remoto, Colecciones, y el nombre de su colección (MiColeccionDeVMs, en nuestro ejemplo) y, a continuación, en la sección Escritorios virtuales, haga clic en el menú Tareas y seleccione Agregar un escritorio virtual. Se abre el asistente Agregar escritorios virtuales, indique el número de escritorios virtuales que desea agregar y haga clic en Siguiente. En la pantalla Especificar asignación de escritorio virtual, haga clic en Siguiente. En la pantalla Confirmar selecciones, haga clic en el botón Crear. Para finalizar, en la pantalla Ver resultados, haga clic en el botón Cerrar. He aquí los comandos equivalentes en PowerShell: # Agregar escritorios virtuales a una colección Add-RDVirtualDesktopToCollection -CollectionName MiColeccionDeVMs -VirtualDesktopAllocation @{"rdvh1.MiEmpresa.Priv"=1}
4. Desplegar aplicaciones con RemoteApp Este servicio de rol hace RDS muy atractivo. Permite publicar aplicaciones en lugar de un escritorio completo. Esta capacidad para publicar una aplicación permite una mejor integración de dicha aplicación en el entorno habitual del usuario, que tendrá la impresión de que la aplicación se ejecuta, directamente, en su puesto (como si fuera una ventana más). Con la configuración del cliente RemoteApp, la aplicación aparecerá en la pantalla de bienvenida (menú inicio) y la asociación de la extensión del archivo se realizará con el puesto cliente. Por ejemplo, si Microsoft Visio sólo está disponible mediante RemoteApp, el cliente RemoteApp puede asociar la extensión.vsd con esta aplicación publicada. De este modo, cuando un usuario hace doble clic sobre un archivo local.vsd, Microsoft Visio se abre automáticamente como RemoteApp y abre el archivo solicitado. La operación es, por tanto, transparente de cara al usuario. Ya no es posible crear el archivo.rdp o el paquete .msi con Windows Server 2012 R2, tendrá que crearlo a mano si no quiere utilizar la configuración del cliente RemoteApp en los puestos cliente. Con Windows Server 2012 R2, las aplicaciones RemoteApp se publican a nivel de la colección.
A continuación se muestra cómo configurar una aplicación RemoteApp que se publica en un escritorio virtual: Abra el Administrador del servidor y vaya a una colección de sesiones, o de escritorios virtuales. A continuación, en la zona principal de la ventana, haga clic en el menú Tareas y en la sección RemoteApp, seleccionando la opción Publicar programas RemoteApp. Si publica una aplicación en un escritorio virtual, debe escoger el escritorio virtual sobre el que se encuentra la aplicación que quiere publicar. Es lo que le permite hacer la siguiente pantalla Seleccionar escritorio virtual. Una vez lo haya seleccionado, haga clic en Siguiente. En el asistente Publicar programas RemoteApp, en la página Seleccionar programas RemoteApp, marque la opción correspondiente al programa que desea publicar (la calculadora, en este ejemplo) y, a continuación, haga clic en Siguiente. En la pantalla Confirmación, haga clic en el botón Publicar. Espere algunos segundos hasta que se publique la aplicación y, a continuación, en la página Última etapa haga clic en el botón Cerrar. He aquí los comandos equivalentes en PowerShell: # Publicación de la Calculadora mediante RemoteApp # por un servidor de sesiones New-RDRemoteApp -CollectionName MiColeccionDeSesiones -ConnectionBroker rds1.MiEmpresa.Priv -DisplayName Calculadora -Alias Calculadora -FilePath "C:\Windows\system32\calc.exe" -ShowInWebAccess $true -RequiredCommandLine $false # Publicación de la Calculadora mediante RemoteApp # por un servidor de escritorio virtual New-RDRemoteApp -CollectionName MiColeccionDeVMs -VirtualDesktopName Win8Ent-0 -ConnectionBroker rds1.MiEmpresa.Priv -DisplayName Calculadora -Alias Calculadora -FilePath "C:\Windows\system32\calc.exe" -ShowInWebAccess $true -RequiredCommandLine $false
Observe que la publicación de una aplicación oculta, automáticamente, el acceso web del escritorio, mientras que muestra la aplicación publicada mediante RemoteApp. Podrá gestionar las propiedades de la aplicación RemoteApp mediante la interfaz gráfica o mediante los siguientes cmdlets PowerShell: • • • •
Get-RemoteApp: muestra la lista de aplicaciones RemoteApp publicadas. New-RemoteApp: publica una nueva aplicación RemoteApp. Set-RemoteApp: modifica las propiedades de una aplicación RemoteApp. Remove-RemoteApp: elimina una aplicación RemoteApp.
Para finalizar, observe que es posible precisar los permisos de acceso de los usuarios a las aplicaciones RemoteApp mediante la pantalla Asignación de usuarios en las propiedades de la aplicación RemoteApp. Del lado del puesto cliente, la configuración del cliente RemoteApp es muy sencilla y puede hacerse mediante la interfaz gráfica o mediante GPO. No obstante, si el certificado de su servidor Broker es autorfirmado, tendrá que instalarlo en la Entidad de certificación raíz de confianza del equipo cliente. A continuación se muestra cómo realizar la configuración del cliente Remote App mediante la interfaz gráfica: Abra Conexiones remotas accesible en el Panel de control y haga clic en el enlace Acceso a los programas RemoteApp y servicios de Escritorio remoto. En el campo Dirección URL de conexión o dirección de correo electrónico escriba la URL https://NombreDeSuServidorRDS/rdweb/feed/webfeed.aspx (rds1.MiEmpresa.Priv en nuestro ejemplo) y haga clic en Siguiente.
En la pantalla Listo para configurar la conexión, haga clic en Siguiente. En la pantalla Configuró correctamente la siguiente conexión, haga clic en Finalizar.
Si quiere configurar los puestos de cliente mediante una directiva de grupo, cree una nueva directiva de grupo y vaya a Configuración de usuario - Directivas - Plantillas administrativas - Componentes de Windows - Servicios de Escritorio remoto Conexión de RemoteApp y Escritorio.
Habilite el parámetro Especificar la dirección URL de conexión predeterminada y escriba la URL correspondiente a su servidor que posea el servicio de rol Agente de conexión para los servicios de Escritorio remoto
Este parámetro de directiva de grupo sólo se aplica a aquellos sistemas operativos Windows Server 2012, Windows 8 y Windows RT. Con sistemas operativos anteriores, tendrá que realizar una configuración manual.
Configuración avanzada
1. Configuración del Acceso Web de los servicios de Escritorio remoto El uso de RDS se ha extendido mucho más allá de un simple escritorio remoto. Windows Server 2012 ofrece, ahora, un medio para centralizar los recursos publicados sobre un portal Web. Desde el punto de vista del cliente, siguen siendo necesarios dos criterios: • •
Poder acceder al sitio Web que ofrece el acceso Web desde un navegador de Internet, con o sin proxy. Tener instalado el cliente RDC 7.0 como mínimo.
Este servicio de rol puede instalarse sobre un servidor que tenga o no otros servicios de rol de Escritorio remoto. Requiere, no obstante, como mínimo IIS 8.5 para poder funcionar y una relación de confianza con los servidores host de sesión para poder enumerar las aplicaciones RemoteApp. Generalmente, ya viene instalado si ha realizado la instalación Inicio rápido o Implementación estándar. Es posible agregar el servicio de rol Acceso Web para Escritorio remoto mediante la interfaz gráfica o mediante PowerShell. # Agregar un servidor de Acceso Web Add-RDServer -Server MiServidorWebRDS -Role rds-web-access -ConnectionBroker rds1.MiEmpresa.Priv
Para acceder al servicio, abra un navegador Web en la siguiente dirección, remplazando MiServidorWebRDS por el nombre del servidor que tenga dicho servicio de rol: http://MiServidorWebRDS/RDWeb/ El nuevo portal de Acceso Web gestiona, ahora, navegadores como Mozilla Firefox o Google Chrome así como Microsoft Internet Explorer (si bien este último presenta ciertas ventajas tales como una mejor gestión de la autenticación, por ejemplo). Por defecto, la autenticación se realiza mediante un portal (formulario):
Una vez autentificado, se muestra la siguiente página:
Se presentan dos pestañas. La pestaña RemoteApp y escritorios se configura dinámicamente con las aplicaciones y escritorios a los que tiene permisos para acceder si la funcionalidad RemoteApp se ha configurado. La pestaña Conectarse a un equipo remoto permite abrir una sesión RDP completa sobre el servidor especificado en el sitio Web. La pestaña Conectarse a un escritorio remoto ofrece varias opciones, aunque no permite escoger el servidor sobre el que abrir una conexión. Para configurar el servicio, tiene dos opciones posibles: • • •
Dejar que el Administrador de servicios de Escritorio remoto se las apañe él solo (opción recomendada). Utilizar la MMC IIS 8.5. Editar el archivo de configuración XML, web.config, ubicado por defecto en la ruta C:\Windows\Web\RDWeb\Pages.
Configuración mediante IIS: Abra la consola Administrador de servicios de Internet (IIS) desde la pantalla de bienvenida, Herramientas administrativas y, a continuación, Administrador de servicios de Internet (IIS). En la pestaña Conexiones, despliegue el nombre de su servidor y, a continuación, Sitios Default Web Site - RDWeb y, por último, la carpeta virtual Pages. Haga clic dos veces en el icono Configuración de aplicaciones en la parte central de la pantalla:
El sitio de acceso RDWeb puede incorporarse en un sitio SharePoint, pues se trata de un Webpart. Esta opción no se aborda en este libro, puesto que SharePoint se sale de su perímetro. Los parámetros configurables son los siguientes:
DefaultTSGateway: permite especificar la puerta de enlace por defecto que utilizarán las conexiones. Por defecto, no existe ninguna puerta de enlace predeterminada. Una vez la seleccionada la aplicación RemoteApp o el escritorio remoto, se abre una conexión RDP clásica sobre el puerto 3389 TCP. GatewayCredentialsSource: puede tomar los valores 0, 1 o 4. El valor por defecto es 4, que se corresponde con "preguntarme más tarde". ShowDesktops: con el valor true por defecto. Esta variable controla el hecho de que se muestre o no la pestaña Escritorio remoto en el sitio Web. xClipboard: con el valor true por defecto. Bloquea el uso del portapapeles de Windows si su valor es false.
xDriveRedirection: con el valor false por defecto. Autoriza la redirección de los lectores locales si su valor es true. xPnPRedirection: con el valor false por defecto. Autoriza la redirección de dispositivos de tipo plug & play si su valor es true. Esto aplica únicamente a los dispositivos multimedia que trabajan con los protocolos Media Transfer Protocol, Picture Transfer Protocol o Microsoft Point of Service (POS) for .NET 1.11. xPortRedirection: con el valor false por defecto. Autoriza la redirección de los puertos COM y LPT si su valor es true. xPrinterRedirection: con el valor true por defecto. Bloquea la redirección de las impresoras si su valor es false. Utilizar el archivo XML web.config presenta la ventaja de que se tiene acceso a los comentarios que explican los distintos valores, por ejemplo, para GatewayCredentialsSource:
Las modificaciones se aplican en caliente y no se requiere ningún reinicio. Basta con refrescar la página Web para ver los cambios. Por defecto, las aplicaciones RemoteApp están habilitadas para el Acceso Web. Esta autorización puede gestionarse por aplicación, desde la consola Administrador de RemoteApp.
2. Configuración de la Puerta de enlace de Escritorio remoto El uso de RDS se ha extendido más allá de los límites de la empresa. Una vez fuera del lugar de trabajo, no controlamos la infraestructura implementada, así como sus restricciones. La apertura de una conexión sobre el puerto 3389 TCP desde otra empresa, desde un hotel o desde cualquier otro lugar público puede estar bloqueada por firewalls, lo cual limita la aplicación de los servicios de Escritorio remoto. Windows Server 2012 R2 ofrece un medio de transporte adaptado a este contexto para acceder a los recursos: HTTPS. El primer requisito previo consiste en disponer de un certificado SSL válido, bien emitido por un tercero de confianza, o bien desde su propia infraestructura de PKI. Windows Server 2012 R2 le permite generar un certificado auto-firmado, aunque esto implica poder agregar este certificado raíz en los equipos que se utilizan para conectarse. Esta solución puede resultar algo excesiva, aunque la experiencia del usuario no es óptima, y va a ser
problemática para la conexión desde un equipo sencillo desde un hotel, por ejemplo. Lo principal es que el puesto cliente considere su certificado como digno de confianza. A continuación se muestran los atributos del certificado y las reglas que deben respetar: • • • •
•
El certificado debe ser de tipo equipo. El objetivo del certificado es la autenticación del servidor. El atributo EKU es de tipo Server Authentication (1.3.6.1.5.5.7.3.1). El certificado no debe haber expirado. No se requiere un OID de 2.5.29.15, aunque si quiere utilizarlo, debe tener también uno de estos usos: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, y CERT_DATA_ENCIPHERMENT_KEY_USAGE; El nombre del certificado (CN) debe corresponderse con el nombre DNS utilizado por el cliente que se conecta a la puerta de enlace.
Instalación de la Puerta de enlace de Escritorio remoto: Abra el Administrador del servidor, vaya a la sección Servicios de Escritorio remoto e Información general y, a continuación, haga clic en el icono con el signo ”+” en la Puerta de enlace de Escritorio remoto sobre el esquema central (o haga clic en el menú Tareas de la sección Servidor de implementación, y seleccione la opción Agregar servidores de puerta de enlace de Escritorio remoto). En la pantalla Seleccionar servidor, seleccione el o los servidores que asegurarán el rol de puerta de enlace, y haga clic en Siguiente. En la pantalla Nombre del certificado SSL autofirmado, escriba el nombre de dominio completo (FQDN) que utilizarán los clientes para conectarse (generalmente el nombre de dominio público, webapp.MiEmpresa.es) y, a continuación, haga clic en Siguiente. En la pantalla Confirmar selecciones, haga clic en el botón Agregar. Una vez terminada la instalación, en la pantalla Ver progreso, haga clic en el botón Cerrar. He aquí los comandos equivalentes en PowerShell: # Instalación del servicio de rol RDS-Gateway Add-RDServer -Role RDS-Gateway -GatewayExternalFqdn webapp.MiEmpresa.es-Server rds1.MiEmpresa.Priv -ConnectionBroker rds1.MiEmpresa.Priv # Depuración... Set-RDDeploymentGatewayConfiguration -GatewayMode Custom -GatewayExternalFqdn webapp.MiEmpresa.es -LogonMethod GatewayAuthMode -UseCachedCredentials $true -BypassLocal $true -Force
Observe que el cmdlet Add-Server instala el servicio de rol Puerta de enlace de Escritorio remoto, así como todas las dependencias tales como RPC over HTTP e IIS, sobre el o los servidores afectados. Crea, también, un certificado autofirmado y lo asocia con el servicio Puerta de enlace de Escritorio remoto. No obstante, con Windows Server 2012, este cmdlet finaliza con dos errores ligados a dos comandos incorrectos en el archivo de script Despliegue del módulo PowerShell. Por este motivo, proporcionamos un segundo cmdlet que termina el trabajo... Este cmdlet no es inútil, por el contrario, en un servidor Windows Server 2012 R2 puesto que se ha corregido el error en esta versión. Por defecto, la instalación genera un certificado autofirmado que resulta útil para una fase de pruebas. Para un entorno de producción, se recomienda encarecidamente utilizar un certificado obtenido a través de una entidad emisora de certificados reconocida. Para configurar la Puerta de enlace de Escritorio remoto: Abra la consola Administrador de puerta de enlace de Escritorio remoto desde la pantalla de inicio, Herramientas administrativas - Servicios de Escritorio remoto y, a continuación, Administrador de puerta de enlace de Escritorio remoto.
En el panel izquierdo, haga clic con el botón derecho sobre el nombre de su servidor y, a continuación, haga clic en Propiedades. He aquí algunas pestañas interesantes: •
La pestaña General: permite limitar el número de conexiones simultáneas o prohibir nuevas conexiones.
•
•
La pestaña Certificado SSL: permite administrar el certificado que presenta la puerta de enlace al cliente. Puede generar un certificado autofirmado mediante una entidad emisora de certificados. La pestaña Configuración de transporte: permite modificar los puertos de red utilizados por los protocolos HTTP y HTTPS. Observe la presencia del transporte UDP sobre el puerto 3391, que permite optimizar los flujos de red
Cierre las propiedades del servidor. Despliegue la carpeta Directivas, seleccione Directivas de autorización de conexiones y, a continuación, edite las propiedades de la directiva RDG_CAP_AllUsers.
•
En la pestaña Requisitos, puede modificar los usuarios y grupos de usuarios que pueden conectarse mediante la puerta de enlace de Escritorio remoto.
•
La pestaña Redirección de dispositivos le permite limitar la redirección de dispositivos cuando se está conectado a través de la puerta de enlace.
•
La pestaña Tiempos de espera le permite limitar el tiempo de espera de inactividad de una sesión o el tiempo de espera de expiración de una sesión. Se recomienda configurar un valor pequeño para el tiempo de espera de inactividad, 15 minutos es incluso demasiado si una sesión se ha abierto desde un sitio público y no tiene supervisión alguna.
Despliegue la carpeta Directivas, seleccione Directivas de autorización de recursos y, a continuación, edite las propiedades de la directiva RDG_AllDomainComputers.
•
•
En la pestaña Grupos de usuarios, puede modificar los usuarios y grupos de usuarios que pueden conectarse a los equipos remotos mediante la puerta de enlace de Escritorio remoto. La pestaña Recurso de red le permite definir cuáles serán los equipos remotos a los que podrán conectarse los usuarios a través de la puerta de enlace. Es importante definir los equipos a los que los usuarios pueden acceder a través de la puerta de enlace. Es posible definir un grupo de Active Directory, un grupo gestionado por la puerta de enlace de Escritorio remoto, o bien todos los equipos. En producción, debería ser lo más restrictivo posible a la hora de abrir el acceso.
•
La pestaña Puertos permitidos permite definir los puertos de red autorizados. Por defecto, sólo está autorizado el puerto TCP 3389, que es el puerto RDP por defecto.
Para terminar, verifique que su despliegue está bien configurado para utilizar la puerta de enlace de Escritorio remoto: Abra el Administrador del servidor - Servicios de Escritorio remoto - Colecciones y, a continuación, haga clic en el menú Tareas y seleccione la opción Editar propiedades de la implementación. En la pestaña Puerta de enlace de Escritorio remoto, verifique que la opción Usar esta configuración del servidor de puerta de enlace de Escritorio remoto está marcada y el nombre completo de su servidor de puerta de enlace bien informado. Si no fuera el caso, hágalo así.
La pasarela RDS está, ahora, operativa. Posee un certificado SSL autogenerado y se han definido dos directivas. Todos los usuarios del dominio pueden utilizar la puerta de enlace para acceder a cualquier equipo de la red.
3. Configuración del Administrador de licencias de Escritorio remoto Las licencias RDS propuestas son de dos tipos: • •
Por dispositivo, sea cual sea el número de usuarios que utilicen este dispositivo para acceder a los recursos RDS. Por usuario, sea cual sea el dispositivo utilizado para acceder a recursos RDS.
En su arquitectura, puede ser adecuado instalar, por ejemplo, el Administrador de licencias sobre el servidor que ejecuta KMS (Key Management System). Si este servicio de rol está instalado sobre un controlador de dominio, todos los servidores RDS del dominio (independientemente de la versión) serán capaces de encontrarlo automáticamente. Si su infraestructura RDS sólo incluye servidores Windows Server 2012 o Windows Server 2012
R2, es preferible instalar el Administrador de licencias sobre el servidor Agente de conexión. Para instalar el servidor de licencias RDS: Abra el Administrador del servidor, vaya a la sección Servicios de Escritorio remoto e Información general y, a continuación, haga clic en el icono con el signo "+" a nivel de Administrador de licencias de Escritorio remoto sobre el esquema central (o haga clic en el menú Tareas en la sección Servidor de implementación, y seleccione la opción Agregar servidores de licencias de Escritorio remoto). En la pantalla Seleccionar servidor, seleccione el o los servidores que proveerán el rol de servidor de licencias para Escritorio remoto y, a continuación, haga clic en Siguiente. En la pantalla Confirmar selecciones, haga clic en el botón Agregar. Una vez terminada la instalación, en la pantalla Ver progreso haga clic en el botón Cerrar. He aquí los comandos equivalentes en PowerShell: # Instalación del servicio de rol RDS-Licensing Add-RDServer -Role RDS-Licencing -Server rds1.MiEmpresa.Priv -ConnectionBroker rds1.MiEmpresa.Priv
Activación del servidor de licencias de Escritorio remoto: Abra el Administrador del servidor, haga clic en el menú Herramientas - Terminal Services y Administrador de licencias de Escritorio remoto.
Haga clic con el botón derecho en el servidor que desea activar y, a continuación, seleccione la opción Activar servidor en el menú. Se abre el asistente de Activación del servidor, haga clic en Siguiente. En la pantalla Método de conexión, los posibles métodos de conexión son: • • •
Conexión automática: el servidor debe poder establecer una conexión con el servidor Microsoft mediante el protocolo HTTPS. Navegador Web: utiliza otro equipo que accede a Internet para realizar el procedimiento de activación. Por teléfono: intercambiará números de serie con Microsoft por teléfono.
Deje el método de conexión en Conexión automática (recomendado) y haga clic en Siguiente.
En la pantalla Información de la empresa, incluya aquella información asociada a su empresa (todos los campos son obligatorios) y haga clic en Siguiente. En la segunda pantalla Información de la empresa, escriba la información opcional, y haga clic en Siguiente. En la pantalla Finalización del Asistente para activar servidor, desmarque la opción Iniciar el Asistente para instalar licencias ahora y haga clic en el botón Cerrar. Esto no supone sino la primera etapa, registrar su servidor con Microsoft. Ahora es posible agregar licencias TS, seleccionando el programa de licencias. Una vez provistos los números necesarios, las licencias TS se muestran en el Administrador de licencias. Para ello, haga clic con el botón derecho en el servidor y seleccione la opción Instalar licencias en el menú contextual. Tenga en cuenta que Microsoft no ha modificado el contrato de licencia entre Windows Server 2012 y Windows Server 2012 R2, en lo relativo a la licencia de acceso cliente a los servicios de Escritorio remoto (RDS Cal). Esto significa que las licencias RDS Cal de
Windows Server 2012 son compatibles con los servidores RDS Windows Server 2012 R2 y, por tanto, no es necesario volver a comprar RDS Cals. Observaciones: •
• • •
•
Este servicio de rol consume muy pocos recursos, aunque debe instalarse sobre un servidor estable. Las licencias no podrán entregarse a otro servidor fácilmente, y la ausencia de este rol hace que el conjunto de hosts pasen al periodo de prueba de 120 días. Un servidor RDS Windows 2012 Server puede, únicamente, comunicarse con un servidor de licencias Windows 2012 Server. Por defecto, se crea una base de datos en el servidor en la siguiente ruta: %systemroot%\system32\lserver Un servidor de licencias Windows Server 2012 R2 puede proveer licencias RDS a servidores RDS Windows Server 2008/2008 R2, siempre que posea RDS Cal Windows Server 2008/2008 R2. El administrador de licencias permite seguir el consumo de licencias en modo usuario, y generar informes. Para utilizar esta funcionalidad, el objeto equipo del servidor debe ser miembro del grupo Active Directory Servidores de licencias de Terminal Server. Si el servidor es, también, controlador de dominio, entonces la cuenta Servicio de Red debe formar parte, también, de este grupo.
Para terminar la configuración, debe seleccionar el modo de licenciamiento a aplicar (por dispositivo o por usuario), que se utilizará en las propiedades de implementación de Escritorio remoto.
4. RemoteFX RemoteFX, que se incluye desde Windows Server 2008 R2 Service Pack 1, es una funcionalidad que permite mejorar de forma significativa la experiencia de usuario y permite mostrar gráficos en 3D de buena calidad, a través de una conexión de Escritorio remoto desde un puesto con un cliente RDP 8.1 u 8.0. El cliente RDP 7.1 también está soportado, aunque con menos funcionalidades. Además, la tecnología incluye el soporte de Aero, animaciones Flash o Silverlight con un rendimiento muy bueno (siempre que la tasa de transferencia de la red sea lo suficientemente buena, por supuesto). Con la aparición de HTML5 y la multiplicación de empresas que utilizan clientes ligeros para conectarse a su infraestructura, no cabe duda de que a RemoteFX le espera un buen porvenir.
Observe que RemoteFX permite, también, aumentar las posibilidades de redirección de los dispositivos USB. Es posible utilizar dos arquitecturas para aprovechar la tecnología RemoteFX: o bien mediante una infraestructura virtualizada VDI con Hyper-V, o bien a través de una
conexión a un servidor que posea el rol host de sesión disponible desde Windows Server 2008 R2 SP1. a. RemoteFX para un host de virtualización de Escritorio remoto
RemoteFX puede utilizarse a través de una infraestructura virtualizada hospedada en Hyper-V a través del rol de virtualización de Escritorio remoto. Los equipos cliente que acceden mediante esta infraestructura aprovechan la aceleración gráfica de la tarjeta física del servidor Hyper-V, permitiendo así aprovechar las ventajas que ofrece RemoteFX. La tarjeta gráfica está, en efecto, virtualizada y está accesible a todas las máquinas virtuales hospedadas. Los requisitos previos que permiten implementar dicha infraestructura son numerosos: •
•
El procesador debe ser compatible SLAT (Second Level Address Translation). Esta funcionalidad se denomina EPT (Extended Page Tables) en los procesadores Intel y NPT (Nested Page Tables) en los procesadores AMD. Los procesadores Intel Nehalem como los Xeon X5540, Xeon E5530, con núcleo Sandy Bridge e Ivy Bridge Intel i3, i5 o Intel i7 y los procesadores AMD con núcleo Barcelona, Shanghaï, Istanbul o Magny-Cours como Opteron 2356 forman parte de los modelos compatibles. Se necesita una tarjeta gráfica (CPU) sobre el servidor que hospeda RemoteFX. El controlador debe soportar DirectX 11.1 y disponer de, al menos, 1 GB de memoria dedicada al vídeo.
Observe que el número de máquinas virtuales que permitan aprovechar la funcionalidad RemoteFX dependerá directamente de la capacidad de memoria de la tarjeta gráfica. Cada máquina virtual requiere en torno a 200 MB de memoria (dependiendo de la resolución de pantalla y del número de monitores que se utilicen). •
• •
•
La tarjeta GPU instalada en el servidor debe poseer un único procesador gráfico. Si una tarjeta gráfica se instala en el servidor, habrá que deshabilitarla para que la tarjeta GPU sea la única que se utiliza. La funcionalidad Hyper-Threading debe estar habilitada sobre el servidor. La máquina virtual a la que se accede debe ejecutar Windows 8/8.1 Professional o Enterprise, Windows 7 Entreprise o Ultimate con el Service Pack 1 instalado. Si se trata de una versión x86, la cantidad de memoria alojada debe ser de 1024 MB como mínimo. Para un sistema operativo de 64 bits, será preciso alojar 2048 MB de memoria, como mínimo. Deben cumplirse los requisitos previos de hardware del rol Hyper-V en el servidor, tal y compo hemos visto anteriormente.
•
•
Los roles "Host de virtualización de Escritorio remoto" así como, evidentemente, el rol "Hyper-V" deben estar instalados en el servidor que hospeda las máquinas virtuales. El cliente RDP utilizado para acceder a la máquina virtual debe tener la versión 7.1 (disponible, de momento, en Windows 7 SP1 y 2008 R2 SP1 únicamente) para gestionar por aplicación la compresión/descompresión/codificación/decodificación de los flujos de audio y vídeo a nivel del protocolo RDP 7.1. Estas acciones pueden, además, realizarse mediante un componente de hardware dedicado (ASIC) que estará instalado del lado del cliente y del lado servidor. Se recomienda utilizar la versión 8.0 u 8.1, pues aportan una mejor compresión de los flujos de vídeo en el protocolo RDP.
Observe que las tarjetas de supervisión remota (tarjeta ILO, iDrac, IMM, KVM sobre IP, etc.), que sirven habitualmente para tomar el control sobre un servidor y configurar su BIOS o acceder a la consola, pueden presentar problemas de compatibilidad. RemoteFX utiliza, en efecto, los controladores WDDM cuando se instala una tarjeta GPU, mientras que las tarjetas de supervisión utilizan, en su mayoría, el controlador XPDM. Estos dos controladores no pueden funcionar de manera simultánea, si un controlador intenta conectarse a través de la tarjeta de supervisión mientras el controlador RemoteFX está cargado, la consola del servidor no será visible cuando se tome el control remoto de un sistema operativo con sesión iniciada.
La solución consiste, por tanto, en deshabilitar la tarjeta de supervisión desde la BIOS o en utilizar el controlador "cap" de RemoteFX. Encontrará más información acerca de la instalación del controlador "cap" en la siguiente dirección: http://technet.microsoft.com/eses/library/gg607270(WS.10).aspx Las principales etapas para implementar RemoteFX son: • •
•
Instalación de RemoteFX en el servidor Hyper-V (abrir el Administrador del servidor desde Agregar roles - Servicios de Escritorio remoto - RemoteFX). Configuración de la implementación de RemoteFX en la máquina virtual (en la configuración de la máquina virtual, agregue la tarjeta de vídeo 3D RemoteFX y, a continuación, reinicie la máquina virtual). Uso del cliente RDP 7.1 como mínimo, estando recomendado el cliente 8.0 o superior. El cliente RDP 7.1 debe estar configurado para utilizar una conexión de acceso remoto en modo LAN y con 32 bits de colores. Se genera, a continuación, un evento con ID 2 sobre la máquina virtual, en el registro de Microsoft-WindowsRemoteDesktopServices-RdpCoreTS/Admin, que confirma que se ha conectado correctamente sobre la máquina virtual utilizando RemoteFX. De este modo podrá aprovechar efectos 3D, Aero, etc.
Para disfrutar una mejor experiencia de usuario puede, también, seguir esta etapa opcional configurando el parámetro Optimizar la experiencia visual al usar RemoteFX con una tasa de captura de pantalla Máximo (calidad óptima) en la Configuración del equipo Plantillas administrativas - Componentes de Windows - Servicios de Escritorio remoto - Host de sesión de Escritorio remoto - Entorno de sesión remota. Tras reiniciar el equipo para confirmar los cambios en algún equipo (y siempre que la conexión de red tenga una buena tasa de transferencia), apreciará todavía un mejor rendimiento de las animaciones remotas. Encontrará una guía paso a paso del despliegue de RemoteFX para un host de virtualización de Escritorio remoto en la siguiente dirección: http://go.microsoft.com/fwlink/?LinkId=177903 b. RemoteFX para un host de sesión de Escritorio remoto
Los requisitos previos de instalación de RemoteFX sobre un servidor que hospeda el rol de host de sesión de Escritorio remoto son un poco menos exigentes que en el caso de una infraestructura VDI. Tendrá, en efecto, que respetar las condiciones siguientes: • • •
El procesador debe soportar SSE2 (Streaming SIMD Extensions 2). Debe estar instalado el rol "Host de sesión de Escritorio remoto" en un servidor Windows Server 2012 R2 o Windows Server 2012. El cliente RDP que se utiliza para acceder a la máquina virtual debe tener, como mínimo, la versión 7.1, estando recomendada la versión 8.0 u 8.1, para gestionar por aplicación la compresión/descompresión/codificación/decodificación de los flujos de audio y vídeo a nivel del protocolo RDP 7.1. Estas acciones pueden, además, realizarse mediante un componente de hardware dedicado (ASIC) que estará instalado del lado del cliente y del lado servidor.
Las principales etapas para implementar RemoteFX son: • •
•
Instalación del rol "Host de sesión de Escritorio remoto" en su servidor Windows Server 2012 R2 o Windows Server 2012. Configuración de la implementación de RemoteFX en el servidor al que accede. Es preciso, también, limitar el número máximo de colores a 32 bits por píxel, bien a nivel de las propiedades de conexión RDP, o bien mediante una directiva de grupo en Configuración del equipo - Plantillas administrativas - Componentes de Windows - Servicios de Escritorio remoto - Host de sesión de Escritorio remoto - Entorno de sesión remota. El otro parámetro a habilitar se encuentra en el mismo lugar y se llama Configurar RemoteFX. Uso del cliente RDP 7.1 como mínimo, estando recomendada la versión 8.0 u 8.1. El cliente RDP 7.1 debe estar configurado para utilizar una conexión de acceso remoto en modo LAN y con 32 bits de colores. Se genera, a continuación, un evento con ID 2 sobre la máquina virtual, en el registro de Microsoft-Windows-
RemoteDesktopServices-RdpCoreTS/Admin, que confirma que se ha conectado correctamente sobre la máquina virtual utilizando RemoteFX. De este modo podrá aprovechar efectos 3D, Aero, etc. Para disfrutar una mejor experiencia de usuario puede, también, seguir esta etapa opcional configurando el parámetro Optimizar la experiencia visual al usar RemoteFX con una tasa de captura de pantalla Máximo (calidad óptima) en la Configuración del equipo - Plantillas administrativas - Componentes de Windows Servicios de Escritorio remoto - Host de sesión de Escritorio remoto - Entorno de sesión remota. Tras reiniciar el equipo para confirmar los cambios en algún equipo (y siempre que la conexión de red tenga una buena tasa de transferencia), apreciará todavía un mejor rendimiento de las animaciones remotas. Encontrará una guía paso a paso del despliegue de RemoteFX para un host de sesión de Escritorio remoto en la siguiente dirección: http://go.microsoft.com/fwlink/?LinkId=192436 c. RemoteFX para la redirección de USB
Si lo desea, puede, también, aprovechar la redirección de dispositivos USB para redirigir cualquier dispositivo USB hacia su escritorio remoto, hospedado sobre una máquina virtual en Windows 7 SP1 como mínimo. Los dispositivos compatibles son numerosos (escáner, impresora multifunción, webcam, etc.). Si dispone, físicamente, de una webcam conectada a su equipo cliente, puede exportar su uso sobre la máquina virtual remota, que se accede mediante el escritorio remoto.
Observe que la redirección USB no funciona si RemoteFX está hospedado sobre un host de sesión de Escritorio remoto. La redirección sólo será efectiva si RemoteFX está instalado sobre un host de virtualización de Escritorio remoto. Puede utilizar esta funcionalidad en un equipo virtual con Windows 7 SP1, Windows 8 o Windows 8.1 mediante una conexión de escritorio remoto, mediante un acceso Web RDS, o incluso mediante una RemoteApp. Las principales etapas para implementar la redirección de puertos USB son: •
Habilitar la funcionalidad de redirección USB mediante RemoteFX en la sección Configuración del equipo - Plantillas administrativas - Componentes de Windows - Servicios de Escritorio remoto - Cliente de conexión de Escritorio remoto - Redirección de dispositivos USB RemoteFX. El parámetro Permitir la redirección RDP de otros dispositivos USB RemoteFX compatibles desde este equipo debe estar Habilitada con los Derechos de acceso a redirección de USB con RemoteFX definidos para Administradores y usuarios. Reinicie, a continuación, el puesto en cuestión.
•
Configurar el cliente RDP (7.1 como mínimo) para redirigir el dispositivo deseado. El dispositivo deberá estar conectado antes de que se inicie la conexión a escritorio remoto. En la conexión de acceso remoto (mstsc.exe) en las Opciones - Recursos locales - Otros, marque el dispositivo USB que desea redirigir. Una vez establecida la conexión mediante escritorio remoto, el dispositivo estará disponible sobre el equipo remoto.
Encontrará una guía paso a paso para configurar la redirección USB en la siguiente dirección: http://go.microsoft.com/fwlink/?LinkId=192432
Conclusión Ahora ya sabe cómo implementar el rol de Escritorio remoto y el conjunto de sus componentes. Puede implementar distintos métodos de acceso, adaptados a cada contexto (desde la red local, Internet, hacia un servidor o VDI) sin reducir la seguridad del sistema de información. Sería una pena privar a los usuarios, y por lo tanto clientes, de una tecnología así de rápida y eficaz.
Introducción Este capítulo está dedicado a las distintas formas que existen para acceder a los servicios de su empresa si se encuentra fuera de ella. La primera parte aborda los distintos medios que permiten este acceso remoto. A continuación, se describen los distintos servicios que ofrece Windows Server 2012 para responder a necesidades de movilidad cada vez más exigentes.
Principios básicos del acceso remoto A día de hoy, los usuarios itinerantes son cada vez más exigentes y requieren poder acceder a todos sus datos en cualquier momento (correo electrónico, archivos, etc.) de la misma forma que si se encontraran en los locales de su empresa. Para poder satisfacer estas necesidades, tendrá que configurar, seguramente, una solución de acceso remoto. Este acceso remoto puede realizarse a través de dos tipos de enlace. Bien mediante un enlace de tipo Conexiones de acceso telefónico (llamadas con frecuencia Dial-up), o viene estableciendo una red privada virtual (VPN: Virtual Private Network).
1. Acceso telefónico a. Generalidades sobre las conexiones telefónicas Dial-up
Utilizar una conexión de tipo Dial-up permite acceder a la red de la empresa mediante una simple línea telefónica, desde cualquier sitio. La contrapartida de esta facilidad de acceso es que se trata de una tecnología que ya es vieja y que ofrece un rendimiento muy limitado, con una tasa de transferencia de información muy baja. En la práctica, es necesario que tanto el cliente como el servidor estén dotados de un módem. El usuario configura una conexión de acceso telefónico bajo demanda, especificando un simple número telefónico. Cuando se inicia la conexión, se requiere un nombre de usuario y una contraseña. El servidor que gestiona el acceso remoto (también llamado RAS, Remote Access Server) será contactado a través de la línea telefónica, a la que se encuentra conectado a través del módem.
b. Ventajas e inconvenientes de las conexiones telefónicas Dial-up
Ventajas • •
No se necesita una conexión a Internet: basta con una simple línea telefónica clásica. Confidencialidad de los datos: la información no transita a través de Internet, de modo que los datos no son objetivo de todos los ataques propios de este medio de comunicación a través de la red mundial. La seguridad es, por lo tanto máxima, puesto que la red local no tiene por qué estar abierta al mundo exterior.
Inconvenientes
•
•
•
•
Muy poco ancho de banda. Basada en la tecnología telefónica, las tasas de transferencia de este tipo de conexión es bastante limitada. En efecto, la red telefónica se ha diseñado para poder reproducir la voz humana, y nada más. Las frecuencias que pueden transitar por este medio de transmisión son, de hecho, muy limitadas. Para aumentar la tasa de transferencia que encontramos (56K), existen líneas de transmisión digitales (128K). No obstante, siguen representando una inversión importante. Coste elevado. Las comunicaciones telefónicas tienen un coste que no es despreciable, recuperar un simple archivo de 10 MB supondrá una inversión considerable de tiempo necesario para descargarlo (cerca de cuarenta minutos si la tasa de transferencia media es de 4 kB/s). Además, para poder proveer conexiones remotas múltiples se requieren tantas líneas telefónicas como usuarios nómadas puedan conectarse simultáneamente.
Si bien el coste es bastante elevado de esta tecnología hace que su uso no parezca muy atractivo, puede resultar muy útil en ciertos casos concretos. Si no es, en efecto, extraño tener problemas de conexión a Internet, es mucho menos habitual tener cortes de la línea telefónica. Puede resultar, de este modo, bastante interesante aprovechar este tipo de acceso en ciertas empresas de administración de servidores. En efecto, un administrador podrá seguir gestionando, de manera remota, sus servidores a través de la línea telefónica, aunque no estén disponibles a través de Internet.
2. Acceso mediante Internet a. Generalidades sobre las VPN
La segunda tecnología que permite realizar un acceso remoto utiliza la red Internet y no la red telefónica. A diferencia de las conexiones bajo demanda que le permiten conectar directamente con la red de la empresa, en este caso es necesario pasar "a través" de Internet. La tecnología que se utiliza se denomina VPN (Virtual Private Network o Red Privada Virtual, en castellano). Aquí, la comunicación se establece directamente a nivel IP.
A continuación se dan algunas explicaciones relacionadas con la terminología Red Privada Virtual: La conexión es virtual en cuanto a que el equipo que establece una conexión VPN a través de Internet se va a comportar como si estuviera directamente conectado a la red de área local, como si se tratase de un cable de red directamente conectado a ella. El usuario va a poder, de este modo, acceder a los mismos recursos que si estuviera físicamente conectado a la red. Esta conexión se considera, no obstante, virtual, precisamente porque no existe tal enlace físico Ethernet con la red de destino. Es privada en cuanto a que se trata de una conexión punto a punto entre el origen y el destino. Los datos que se intercambian están cifrados. De este modo, si alguien interceptara los datos, no se podrían descifrar sin conocer la clave privada de la transacción.
Las VPN se utilizan, a menudo, para conectar sitios remotos completos. Hablamos, entonces, de VPN sitio a sitio. El objetivo de este tipo de conexiones es poder vincular lógicamente redes remotas sin tener que realizar un enlace de red directo (Ethernet, Wi-Fi, etc.).
b. Los distintos tipos de VPN que ofrece Windows Server 2012 R2
Windows Server 2012, como sus predecesores, soporta los siguientes tipos de VPN: •
PPTP (Point to Point Tunneling Protocol): PPTP es el método más sencillo para implementar y utilizar una VPN. El cifrado de los datos interviene después del proceso de autentificación mediante el protocolo PPP. Utilice, preferentemente, una autentificación MS-CHAPv2 con una autenticación basada en PAP (Password Authentication Protocol) o CHAP (Challenge Handshake Authentication Protocol) para no dejar que la contraseña transite sin cifrar por la red.
•
L2TP/IPsec (Layer 2 Tunneling Protocol): Más seguro que PPTP, L2TP/IPsec es el resultado de un desarrollo conjunto entre Microsoft y Cisco. A diferencia de PPTP, el cifrado incluye la fase de identificación puesto que la sesión IPsec se establece justo antes. Además, la autenticación mutua de las máquinas (también llamada handshake) impide a cualquier máquina desconocida conectarse. Esto evita, en particular, ataques del tipo Man-in-the-Middle, que sufren las VPN basadas en PPTP. Preste atención, no obstante, puesto que es necesario evitar, teóricamente el NAT antes de IPsec puesto que modifica el contenido de los paquetes. Esta modificación es incompatible con los mecanismos de protección integrados de los datos IPsec. Si se ve obligado a utilizar L2TP sobre una red "nateada", utilice la variante NAT-T (NAT Traversal).
Desde Windows Server 2008, el sistema también ofrece: •
SSTP (Secure Socket Tunneling Protocol):
SSTP es una nueva forma de túnel VPN que facilita el establecimiento de una conexión VPN mediante un firewall o un dispositivo que realiza la traducción de las direcciones de red (NAT). Esto es posible gracias a la encapsulación de paquetes PPP (Point to Point Protocol) en HTTPS. SSTP utiliza conexiones HTTP encriptadas con SSL para establecer conexiones con las pasarelas VPN. De este modo, es posible establecer conexiones VPN a través de un proxy HTTP. Del mismo modo que con L2TP/IPsec, sólo se transmite la información de identificación una vez establecida la sesión SSL con la pasarela VPN. También llamado PPP/SSL, este protocolo permite utilizar PPP y EAP para realizar la autenticación y hacer que la conexión sea todavía más segura.
Sólo disponible con la combinación de versiones Windows Server 2008 R2/Windows 7 o versiones superiores, la tecnología VPN Reconnect permite hacer una reconexión transparente mediante un enlace VPN. En caso de que se interrumpa la conexión a Internet, por ejemplo, el sistema se encarga de recuperar la conexión VPN sin ninguna intervención por parte del usuario, y en unos pocos segundos. c. Ventajas e inconvenientes de VPN
Ventajas •
•
•
Coste reducido: todas las empresas y todos los usuarios ya están equipados, por lo general, con una conexión a Internet. El coste de la implementación es por lo tanto mínimo, pues basta con aprovisionar un servidor que haga las veces de servidor VPN. Además, con una única conexión a Internet es posible dar servicio a varias conexiones remotas simultáneas sin tener que adquirir una línea suplementaria. Ancho de banda elevado: la tecnología VPN se apoya directamente en IP y, por tanto, sobre una infraestructura Internet. Con la extensión de ADSL y la explosión del ancho de banda asociado, esta tecnología es mucho más rápida que las conexiones de tipo Dial-Up. VPN Anywhere: supone una pequeña analogía con la tecnología empleada en Exchange (RPC over HTTPS) donde se encapsula el tráfico de Outlook a través de tráfico Web seguro (HTTPS). Como se ha explicado antes, aquí es el tráfico VPN el que está encapsulado en HTTPS. La seguridad de las redes es por lo general una prioridad, y es corriente bloquear el tráfico de salida que no se corresponda con las necesidades de la empresa. Por el contrario es raro ver el tráfico HTTPS saliente bloqueado. De este modo, gracias a SSTP, el usuario debe poder conectarse desde cualquier red de empresa o punto de acceso a Internet.
Inconvenientes
•
•
Dependiente de la red: a diferencia de las conexiones bajo demanda, el rendimiento de una conexión a Internet desde una de las dos partes (empresa o usuario nómada) tienen un impacto nada despreciable en la calidad de la transmisión. Cualquier problema en el proveedor de acceso de una u otra parte puede provocar una incapacidad total para comunicarse. Confidencialidad de los datos: aunque se utilizan sistemas de cifrado no queda más remedio que los datos transiten a través de Internet. Esto los vuelve potencialmente visibles para todo el mundo aunque estén cifrados.
d. DirectAccess, el "VPN-Killer"
La tecnología DirectAccess se denomina, a menudo, "VPN-Killer" por parte de muchos profesionales de la informática. Este sobrenombre proviene del hecho de que a diferencia de las VPN habituales (PPTP, L2TP, etc.), Direct Access permite establecer una conexión a la red de la empresa antes incluso de abrir una sesión sobre la máquina cliente. El objetivo del lado del cliente consiste en mejorar su experiencia como usuario nómada proporcionándole condiciones de trabajo totalmente idénticas a las que disfruta en los edificios de su empresa Los administradores de sistemas sacarán buen partido a esta tecnología. En adelante serán capaces de administrar íntegramente los equipos situados fuera de la empresa: despliegue de actualizaciones de software, actualización del antivirus, aplicación de las directivas de grupo, etc. Por defecto, y a diferencia de las tecnologías VPN habituales, sólo el tráfico de destino de la empresa pasará a través de Direct Access, de forma que no ralentice el tráfico de Internet. Siempre es posible hacer transitar la totalidad del tráfico por Direct Access, con el objetivo de controlar de principio a fin la seguridad del acceso. Su capacidad para gestionar la alta disponibilidad se ha visto mejorada con la llegada del Service Pack 1 de Windows Server 2008 R2 pues incluye el soporte del direccionamiento 6to4 e ISATAP cuando se utiliza DirectAccess mediante un clúster NLB (Network Load Balancing). Si desea más información acerca del clúster NLB, consulte el capítulo Alta disponibilidad. He aquí las etapas del proceso de conexión a la red gracias a DirectAccess con Windows Server 2008/2008 R2/2012/2012 R2: • • •
El cliente detecta si tiene conexión de red. Intenta establecer una sesión sobre un sitio Intranet SSL para determinar si se encuentra en el seno de la red de la empresa o en el exterior. El cliente se conecta al servidor Direct Access mediante IPSec e IPv6. Si no hay disponible una conexión IPv6 nativa (éste es generalmente el caso si el equipo cliente está conectado a Internet), el cliente establece un túnel IPv6 sobre IPv4
• • • •
mediante 6To4 o Teredo (para más información acerca de Teredo diríjase a la página: http://technet.microsoft.com/en-us/network/cc917486.aspx). Si el cliente no llega a establecer la conexión a causa de un cortafuegos o de un proxy, intentará conectarse automáticamente mediante el protocolo HTTPS. El equipo cliente y el servidor Direct Access van a autenticarse mutuamente gracias a los certificados de equipo. Este proceso forma parte de los mecanismos IPSec. El servidor Direct Access va a verificar en sus reglas si el equipo está autorizado (o forma parte de un grupo autorizado) para establecer una conexión Direct Access. El servidor Direct Access va a redirigir el tráfico del equipo cliente hacia los servidores de la Intranet sobre los que esté autorizado el acceso del usuario.
Este proceso es ligeramente diferente con Windows Server 2012 puesto que ya no se utiliza IPsec y, en lo sucesivo, la conexión externa se establece directamente mediante HTTPS. La etapa 3 de intento de conexión IPsec e IPv6 ha desaparecido, pasando directamente de la etapa 2 a la etapa 4. e. Rol Web Application Proxy
Web Application Proxy (o WAP) es un nuevo servicio de rol de Acceso remoto en Windows Server 2012 R2. El proxy de aplicación web provee una funcionalidad de proxy inverso para las aplicaciones web presentes en su red de empresa permitiendo, así, a los usuarios acceder desde el exterior de la empresa y desde cualquier dispositivo móvil (de momento se soporta IOS y Android debería llegar próximamente). WAP requiere poseer una granja de AD FS para poder funcionar. Sin AD FS, el asistente no puede completar las etapas de configuración. Es posible proveer funcionalidades simples de proxy inverso utilizando una autenticación de tipo Pass-Through, que tiene, también, la capacidad de pasar información de autenticación del cliente hacia el servidor de destino sin pre-autenticación. Puede, también, proveer una autenticación a AD FS (Active Directory Federation Service) agregando el rol de proxy AD FS. Observe que, incluso para el Pass-Through, el asistente exige una granja AD FS configurada. El objetivo de WAP es publicar aplicaciones web internas en la red de la empresa para hacer que estén disponibles desde el exterior, poco importa el cliente utilizado (equipo portátil, Smartphone, etc.), proveyendo una autenticación única (SSO) que juega, así, el rol de portal SSL. Se recomienda desplegar este rol en una red perimétrica (entre el firewall conectado a Internet y el conectado a la red de la empresa). A diferencia de una publicación web "clásica", WAP corta el tráfico entrante del cliente para iniciar una nueva sesión con la aplicación final. De este modo, el usuario no se comunicará, jamás, directamente con la aplicación, sino que accederá a través del componente WAP.
En resumen, WAP provee funcionalidades de publicación de aplicaciones similares a Microsoft Forefront Unified Access Gateway (UAG). No obstante, WAP interactúa con otros servidores y servicios (AD FS) para proveer un despliegue simplificado. No reemplaza totalmente a UAG, pues sólo las aplicaciones web con autenticación Kerberos o por notificación pueden aprovechar una publicación mediante WAP. WAP puede, por ejemplo, resultar útil para publicar el acceso remoto web de un servidor Exchange (OWA) o un servidor Lync (Lync Web app). Al gestionarse la autenticación en AD FS, el usuario recibirá un token único y podrá aprovechar el SSO (Single Sign On) para acceder a las dos aplicaciones gracias a una única autenticación. Encontrará, en el siguiente enlace, las etapas que permiten implementar una publicación mediante el componente WAP: http://technet.microsoft.com/en-us/library/dn383650.aspx f. ¿Cuáles son las novedades de Windows Server 2012 y Windows Server 2012 R2?
Windows Server 2012 combina la funcionalidad de Direct Access con el rol RRAS (Remote and Routing Access Service) en un nuevo rol que permite administrar de manera centralizada, configurar y supervisar a la vez Direct Access y los servicios de VPN. La mayor mejora reside en las numerosas actualizaciones y mejoras de Direct Access para prevenir bloqueos ligados al despliegue, y simplificar su gestión. Se han aportado las siguientes mejoras con Windows Server 2012: •
•
• •
• • •
• • • •
Coexistencia de Direct Access y RRAS: ambas herramientas pueden, en lo sucesivo, administrarse desde la misma interfaz, a saber: la consola de Administración de acceso remoto. Simplificación del despliegue de Direct Access para estructuras de tamaño pequeño o mediano: ya no es obligatorio disponer de dos direcciones IPv6 consecutivas. Basta con tener acceso al puerto TCP 443 desde el exterior, ya no es preciso utilizar reglas IPsec complicadas. Desaparecen los requisitos previos de clave pública (PKI): gracias a la delegación Kerberos. Integración nativa del soporte NAT64 y DNS64 para acceder a recursos mediante IPV4: antes, era preciso tener una intranet compatible con IPv6; en lo sucesivo basta con IPv4. Soporte de DirectAccess sobre un servidor a través de NAT. Simplificación de la administración de las directivas de seguridad. Soporte de Load Balancing: ya no es necesario un servidor UAG (Unified Access Gateway) como era el caso con la funcionalidad Direct Access en Windows 2008 R2. Integración de NAP (Network Access Protection): para asegurar la seguridad verificando el estado de la seguridad en los puestos. Soporte multidominio. Soporte de Windows Server en modo Core. Soporte OTP (One-Time Password).
• • • •
•
Supervisión de los usuarios. Herramientas de diagnóstico. Registro de eventos e Informes. VPN sitio a sitio en modo IKEv2 IPsec: Windows Server 2008 R2 incluye el soporte IKEv2 en las conexiones VPN cliente. El uso de IKEv2 y de IPsec ofrece una autenticación y métodos de cifrado robustos. Windows Server 2012 incluye esta funcionalidad reforzada para conexiones VPN de tipo sitio a sitio. En lo sucesivo, es posible virtualizar el servidor que hospeda el rol de Acceso remoto.
Windows Server 2012 R2 aporta, por su parte las siguientes mejoras: •
Pasarela VPN sitio a sitio multiteniente (Multi-Tenant Site-to-Site VPN Gateway): con Windows Server 2012 R2, es posible desplegar pasarelas sitio a sitio multilocalidad (multicliente) para proveer una conectividad a los sitios locales hacia las redes virtuales dedicadas en la red principal. Una pasarela (o Gateway: GW) es capaz de dar servicio a varios clientes que posean direcciones IP que se solapen (overlap). Para aclarar este punto, se muestra a continuación un esquema que muestra el caso de un anfitrión que aloja máquinas virtuales para clientes que utilizan la virtualización de redes Hyper-V. Vemos cómo una única pasarela S2S GW (Site To Site Gateway) es capaz de dar servicio a dos clientes distintos que posean la misma dirección IP (en este caso 10.10.10.0/24).
•
•
•
El servicio Enrutamiento y acceso remoto (RRAS) GW es una única solución software que puede desplegarse en la mayoría de instancias de servidores RRAS multicliente para equilibrar la carga. El siguiente enlace le indicará las etapas de la configuración necesaria para su implementación: http://blogs.technet.com/b/networking/archive/2013/10/15/multi-tenant-vpn-withwindows-server-2012-r2.aspx Pasarela del acceso remoto VPN multicliente: para las pequeñas y medianas estructuras, no existe la obligación de poseer dos direcciones IPv6 públicas consecutivas. El acceso al puerto TCP 443 desde el exterior es suficiente. El uso de reglas IPsec complicadas ya no es necesario. Border Gateway Protocol (BGP): Windows Server 2012 Border Gateway Protocol (BGP) permite un reparto dinámico y el aprendizaje de las rutas mediante interfaces de enrutamiento sitio-a-sitio (S2S) de RRAS. Esta funcionalidad permite, a los anfitriones (principalmente proveedores de servicios (IaaS)) desplegar BGP en las pasarelas S2S multi-cliente. De este modo, la pasarela puede saber qué paquetes están dirigidos a Internet, hacia las redes locales (clientes), hacia la red virtual del cliente en el anfitrión y, de este modo, determinar los itinerarios de manera consecuente. Las pasarelas RRAS con BGP habilitado puede, a su vez, desplegarse
en las empresas para distribuir rutas internas a otras pasarelas de la red de la empresa sobre túneles seguros.
Implementar un acceso seguro a través de Internet En esta sección veremos cómo configurar un servidor como servidor de acceso remoto. En primer lugar se describen los métodos para configurar los distintos tipos de VPN ofrecidos por Windows Server 2012 (PPTP, L2TP, SSTP). A continuación se abordan los aspectos relativos a la securización. No se mencionará la configuración de un servidor RAS mediante módem, pues se trata de una tecnología que apenas se utiliza.
1. Implementar un enlace VPN Requisitos previos de hardware: el servidor debe estar integrado en el dominio MiEmpresa.Priv y provisto de dos tarjetas de red. Una conectada a Internet y otra conectada a una red local (LAN). La primera se encarga de aceptar las conexiones VPN entrantes y necesita una IP fija (en nuestro caso configurada con la dirección IP 211.111.111.111/25, preste atención puesto que esta IP se utiliza como ejemplo, debería utilizar una IP pública en producción). La segunda interfaz de red transfiere el tráfico entre las conexiones VPN y los recursos de red de la LAN.
En el caso de una VPN PPTP o L2TP es técnicamente posible tener una única tarjeta de red. Esto se sale, no obstante, del marco de buenas prácticas recomendadas por Microsoft y el rendimiento puede verse afectado. a. Instalación del rol Acceso remoto
La instalación del rol se realiza desde la consola Administrador del servidor, en la subcarpeta Roles, haciendo clic en Agregar roles. He aquí las distintas etapas: Abra la consola Administrador del servidor. Haga clic en Administrar y, a continuación, en Agregar roles y características. Haga clic en Siguiente. En Tipo de instalación, seleccione Instalación basada en roles o caracte-rísticas. Haga clic en Siguiente.
En la pantalla Seleccionar servidor, haga clic en DC2012 en la lista y, a continuación, haga clic en Siguiente. En la sección Roles del servidor, marque la opción Acceso remoto tal y como indica la siguiente captura de pantalla:
Haga clic en Siguiente. Lea la descripción del rol y, a continuación, haga clic en Siguiente. Marque la opción DirectAccess y VPN (acceso remoto).
En el cuadro de diálogo Asistente para agregar roles y características, haga clic en Agregar características y, a continuación, haga clic en Siguiente.
En la pantalla Rol de servidor web (IIS), haga clic en Siguiente. Deje las opciones por defecto de los servicios de rol marcadas y, a continuación, haga clic en Siguiente. En la pantalla de confirmación, haga clic en Instalar.
En la pantalla de Resultados, verifique que la instalación se desarrolla correctamente y haga clic en Cerrar.
Si bien ya no resulta útil con Windows Server 2012, si lo desea puede crear un certificado autofirmado para L2TP/IPsec o SSTP con Windows Server 2008/2008 R2: abra la consola Administrador de Internet (IIS) y, en la parte central, haga doble clic en Certificados de Servidor. En la sección Acciones, haga clic en Crear un certificado autofirmado... y, a continuación, asígnele un nombre descriptivo. b. Configuración de las funcionalidades VPN
Ahora que ha instalado el rol de servidor de acceso remoto, puede configurar sus parámetros asociados.
El procedimiento de configuración para las tres tecnologías VPN es idéntico. En la consola Administrador del servidor, haga clic en Herramientas y, a continuación, seleccione Administración de acceso remoto.
En el panel de navegación, dentro de Configuración, haga clic en DirectAccess y VPN.
En la sección central, haga clic en Ejecutar el Asistente para introducción. Se abre el asistente de instalación, haga clic en Implementar solo VPN.
En la parte izquierda, haga clic con el botón derecho sobre su servidor y, a continuación, seleccione Configurar y habilitar Enrutamiento y acceso remoto como se indica a continuación:
Haga clic en Siguiente. Seleccione Acceso remoto (acceso telefónico o red privada virtual) y haga clic en Siguiente.
Marque la opción VPN y haga clic en Siguiente. Seleccione su interfaz pública (aquí, de cara a simplificar, se han renombrado las conexiones en función de su uso: se trata, por tanto, de la tarjeta WAN).
Haga clic en Siguiente. En la pantalla Asignación de direcciones IP, seleccione Automáticamente si dispone de un servidor DHCP. En caso contrario, seleccione De un intervalo de direcciones especificado. Haga clic en Siguiente. Si desea que el servidor VPN asigne las direcciones, le aparece la siguiente pantalla:
Haga clic en Nuevo y, a continuación, defina un rango que contenga suficientes direcciones de red. Valide haciendo clic en Siguiente. Preste atención y especifique un rango que se corresponda con su red local. Sin ello, la comunicación no funcionará.
En la pantalla Administrar servidores de acceso remoto múltiples, si dispone de un servidor RADIUS marque Sí, en caso contrario marque No. Aquí, marcaremos No puesto que la seguridad con RADIUS se aborda más adelante en este capítulo.
Haga clic en Siguiente. Aparece el siguiente cuadro de diálogo que le informa del uso de un agente de retransmisión DHCP. El componente Agente de retransmisión DHCP es un agente que transfiere los mensajes DHCP (Dynamic Host Configuration Protocol) entre los clientes y los servidores DHCP sobre distintas redes IP. Resulta, por lo tanto, útil cuando no existe ningún servidor DHCP en el segmento físico de una máquina.
Haga clic en Aceptar. En la pantalla Resumen, verifique que la información de la configuración es la deseada y, a continuación, haga clic en Finalizar. A continuación, haga clic en Aceptar. Una vez terminado este asistente, Windows Server 2012 crea automáticamente 128 puertos para cada una de las tres tecnologías de VPN que conoce .Cada conexión requiere un puerto único. Para obtener una mayor seguridad, conviene deshabilitar los puertos inútiles.
Una vez configurado para aceptar conexiones VPN entrantes, Windows Server 2012 bloquea automáticamente todo el tráfico entrante sobre la interfaz pública que no se corresponde con el tráfico VPN. Para modificar los paquetes autorizados (por ejemplo: para poder tomar el control sobre el servidor por escritorio remoto): Desde la consola Administrador del servidor, haga clic en Herramientas y, a continuación, en Enrutamiento y acceso remoto. Despliegue la arborescencia Nombre de su servidor - IPv4 (o IPv6 según su configuración) - General. Haga clic con el botón derecho sobre su interfaz pública y, a continuación, seleccione Propiedades.
Haga clic en Filtros entrantes....
Sólo falta autorizar el tráfico deseado (puerto 3389 TCP por ejemplo para el escritorio remoto).
2. Administración de la seguridad de los accesos Ahora que sabe cómo configurar Windows Server 2012 R2 como servidor de acceso remoto, sin duda querrá controlar la forma en la que se conectan los usuarios. Cuentas de usuario, franjas horarias, grupos y muchos otros parámetros son configurables. En las versiones anteriores a Windows Server 2008, estos parámetros se administraban a través de la consola Directivas del acceso remoto. Desde Windows Server 2008, debe utilizar la consola Servidor de directivas de redes (Network Policy Server). Esta consola le permite administrar la seguridad de los accesos a su red de forma centralizada. Con Windows Server 2012 y Windows Server 2012 R2, el rol de servidor NPS (Network Policy Server) se instala automáticamente cuando se agrega el rol de acceso remoto, a diferencia de lo que ocurría en las versiones anteriores de Windows Server. Para modificar una directiva existente: En la consola Administrador del servidor, haga clic en Herramientas y, a continuación, en Servidor de directivas de redes (Network Policy Server). Despliegue el nodo Directivas - Directivas de red.
Encontrará dos directivas por defecto con valores máximos para la columna Orden de procesamiento. Debe prestar atención a este orden. En efecto, las directivas de red se procesan en orden creciente. El servidor va a recorrer las directivas partiendo del menor valor de prioridad. Si encuentra una que corresponde con criterios de petición de conexión, autoriza o no el tráfico. De este modo, si una directiva está configurada para rechazar el acceso, tras la verificación de las directivas el acceso estará automáticamente bloqueado incluso si hay otra directiva más tarde que lo autoriza. Lo más práctico es que cree sus propias directivas de acceso a la red para controlar bien su contenido. He aquí el procedimiento a seguir para crear una directiva que autoriza al grupo Comerciales a conectarse a la red entre semana de 9h a 18h: En la consola Servidor de directivas de redes (Network Policy Server), vaya a Directivas de red. Haga clic con el botón derecho en la carpeta Directivas de red y, a continuación, haga clic en Nuevo. Especifique un nombre para su directiva. Preste atención a elegir nombres explícitos, de este modo si sus directivas se multiplican ganará en claridad.
La lista desplegable Tipo de servidor de acceso a la red se refiere a la tecnología NAP (Network Access Protection) que se ha abordado en el capítulo Implementar los servicios de red de la empresa. Aquí, sólo se administra la seguridad de acceso al servidor VPN, y dejaremos la opción como No especificado. Haga clic en Siguiente. Aparece, a continuación, una página que le permite definir las condiciones. Haga clic en Agregar.
A continuación tiene la posibilidad de elegir entre una gran variedad de criterios agrupados en siete categorías diferentes: • • • • • • •
Grupo (grupo de equipos, de usuarios, etc.). HCAP (grupos que se corresponden con servidores de acceso a la red de terceros). Restricciones horarias (días de la semana, intervalos horarios, etc.). Protección de acceso (sistema operativo, compatibilidad NAP, etc.). Propiedades de la conexión (dirección IP del cliente, tipo de autenticación, etc.). Propiedades del cliente (nombre del cliente RADIUS, IP del cliente RADIUS, etc.). Puerta de enlace (número de teléfono del servidor Dial-Up, nombre del dispositivo de red que transmite la solicitud).
En este libro no se abordan con detalle todas estas condiciones, teniendo en cuenta su elevado número. Podrá no obstante encontrar más detalle en la TechNet de Microsoft en la siguiente dirección: http://technet.microsoft.com/en-us/library/cc731220.aspx Las condiciones son acumulables, puede por ejemplo autorizar a un único grupo de usuarios y sobre una franja horaria muy precisa. Seleccione Grupos de usuarios y, a continuación, haga clic en Agregar. En el cuadro de diálogo que se abre, haga clic en Agregar grupos y, a continuación, escriba el nombre del grupo (Comerciales, en nuestro ejemplo) y valide haciendo clic en Aceptar.
Valide haciendo clic en Aceptar y, a continuación, haga clic en Siguiente. Una vez haya agregado las condiciones, tiene la posibilidad de Conceder acceso, de Denegar acceso o incluso hacer que sean las propiedades de marcado del usuario las que determinen el acceso (en este caso, son las propiedades definidas en la cuenta del usuario las que se tienen en cuenta). En este ejemplo, seleccione Acceso concedido y, a continuación, haga clic en Siguiente. A continuación puede elegir entre los distintos Métodos de autenticación. Debe seleccionar al menos uno. Preste atención, las opciones sin marcar en la siguiente imagen representan autenticaciones poco seguras y no deberían estar marcadas en la medida de lo posible.
Aquí, deje las opciones marcadas por defecto. Haga clic en Siguiente. La página de restricciones permite aplicar restricciones suplementarias como la franja horaria autorizada (en nuestro ejemplo). Haga clic en Restricciones de día y hora y, a continuación, marque la opción Permitir acceso solo en estos días y horas.
Haga clic en Editar y, a continuación, rellene la información tal y como se muestra a continuación para autorizar los días entre semana de 9h a 18h.
Valide haciendo clic en Aceptar y, a continuación, haga clic en Siguiente. En esta ventana puede configurar los parámetros suplementarios para securizar la conexión. En efecto, si la conexión responde a los criterios anteriores, a saber condiciones y restricciones, es preciso aplicar parámetros suplementarios, que van desde la Protección de acceso a redes (NAP), hasta el cifrado de la conexión, o incluso una restricción sobre los protocolos utilizados durante la conexión. En nuestro ejemplo, no especifique ningún parámetro y haga clic en Siguiente.
En la última página del asistente, verifique bien la información y haga clic en Finalizar. Su nueva directiva aparece con una cifra asignada automáticamente para el orden de procesamiento. A continuación puede modificar este orden haciendo clic con el botón derecho del ratón sobre la directiva y seleccionando una de las opciones, Aumentar o Disminuir. Esto le permite definir su prioridad y, por consiguiente, el orden en el que se va a verificar durante la petición de conexión.
3. Administración de la autenticación RADIUS En la sección anterior hemos visto cómo configurar una directiva de conexión para el acceso mediante VPN gracias a la consola NPS. Si bien es posible técnicamente, se vuelve rápidamente difícil de gestionar cuando tiene varios servidores de acceso a la red (servidores VPN, accesos Wi-Fi, etc.). Para centralizar la administración de las reglas de acceso de la autenticación necesita el componente de servicio NPS (Network Policy Server). Este rol se conocía en las versiones anteriores a Windows Server 2008 con el nombre de IAS (Internet Authentication Service). Para centralizar la autenticación, utilice la función RADIUS (Remote Authentication DialIn User Service) de su servidor NPS. El interés de la tecnología RADIUS consiste en centralizar la administración de la seguridad de los equipos informáticos que no son Microsoft. En efecto, puede por ejemplo configurar un punto de acceso Wi-Fi para utilizar el servidor NPS Windows Server 2012 para administrar la autenticación. He aquí las funciones que le ofrece el Servidor NPS en materia de seguridad: • •
• • • •
Network Policy Server (NPS): autenticación, autorización, servicios de acceso remoto, VPN, punto de acceso Wi-Fi, puerta de enlace TS. NPS Accounting (o registro): auditoría y registro de las autenticaciones y las peticiones de cuenta en una base de datos SQL o en un archivo local. Windows Server 2008 R2 integra un nuevo asistente que le permite configurar fácilmente este registro creando automáticamente las bases de datos asociadas. NPS RADIUS Proxy: permite encadenar mensajes entre los clientes RADIUS (los servidores de acceso y los servidores RADIUS que se ocupan de la autenticación). NPS NAP: diríjase al capítulo Implementar los servicios de red de la empresa Implementar la cuarentena de red. NPS RADIUS server: gestiona la autenticación, la autorización y el registro de las peticiones de los clientes RADIUS. NPS RADIUS client: servidor de acceso remoto que utiliza un servidor RADIUS para realizar la autenticación.
Los equipos cliente no son clientes RADIUS. Son los equipos a los que se conectan (servidor VPN, punto de acceso Wi-Fi) los que lo son. La configuración de las directivas de acceso (horarios, usuarios, etc.) se realiza del mismo modo que para un servidor VPN (visto anteriormente en este mismo capítulo). En lo sucesivo puede configurar su servidor NPS para que se comporte como un servidor RADIUS o incluso como Proxy RADIUS.
Un servidor RADIUS permite realizar la autentificación, la autenticación y la gestión de los clientes RADIUS. Un cliente RADIUS puede ser un servidor de acceso, tal como un servidor de acceso remoto o un punto de acceso inalámbrico, o un proxy RADIUS. Un proxy RADIUS asegura la distribución de los mensajes RADIUS entre los clientes RADIUS (servidores de acceso) y los servidores RADIUS que realizan la autenticación de los usuarios, su autorización y la gestión de cuentas durante los intentos de conexión. Puede ser interesante utilizar un servidor proxy RADIUS en los siguientes casos: • • • •
Si quiere ofrecer una autenticación para las cuentas que no sean miembro del dominio del que forma parte el servidor NPS. Si quiere ofrecer una autenticación basada en una base de datos diferente a la de Windows. Si desea poder gestionar una gran cantidad de consultas de conexión. El proxy RADIUS se comportará como un distribuidor de carga. Si desea dotar de seguridad al acceso a su base de datos de usuarios situando un proxy RADIUS en una DMZ.
Para que un dispositivo pueda acceder y utilizar su servidor como servidor RADIUS tendrá que haberlo autorizado previamente. Para ello, siga los siguientes pasos: En la consola NPS, vaya a Clientes y servidores RADIUS. Haga clic con el botón derecho del ratón en Clientes RADIUS y seleccione Nuevo.
Basta con declarar el dispositivo dándole un Nombre descriptivo y su Dirección IP. Si fuera necesario, haga clic en la pestaña Opciones avanzadas y especifique: • •
El Nombre del proveedor (la lista desplegable ofrece muchos actores importantes en el mundo informático tales como Cisco, etc.). Un secreto compartido que configurará también en el dispositivo de acceso.
También puede elegir los protocolos de autenticación y especificar si el cliente RADIUS es compatible NAP o no.
Una vez declarado el dispositivo, puede habilitarlo o deshabilitarlo haciendo clic con el botón derecho y marcando una opción. Para ello, basta, en la sección Clientes RADIUS, ir a las propiedades del dispositivo que acaba de crear. Sólo falta seleccionar entre Activado o Desactivado. A continuación se muestra un ejemplo de uso de un servidor RADIUS.
Declarar su servidor como Servidor proxy RADIUS es, también, muy sencillo. En su consola NPS basta con: • • • • • •
Navegar a Clientes y servidores RADIUS. Hacer clic con el botón derecho en Grupos de servidores remotos RADIUS y, a continuación, Nuevo. Indicar un nombre de grupo y, a continuación, hacer clic en Agregar. Informar el nombre o la dirección IP de un servidor RADIUS. Especificar si el proxy RADIUS debe autenticarse mediante un secreto compartido desde el servidor RADIUS, o incluso configurar el reparto de carga. Agregar varios servidores RADIUS en un mismo grupo para asegurar su tolerancia a fallos.
4. Implementación de DirectAccess tras un Firewall Con DirectAccess para Windows Server 2008 R2, era obligatorio poseer una dirección IP pública (y, por lo tanto, dos tarjetas de red: una pública y una privada) sobre el servidor de acceso remoto y DirectAccess no soportaba NAT. En lo sucesivo, es posible publicar un servidor de acceso DirectAccess que posea una única tarjeta de red y que se encuentre detrás de un firewall. •
• • • • •
Requisitos previos: ya ha instalado el rol Acceso remoto siguiendo el método descrito anteriormente en este capítulo (VPN no se ha configurado mediante el asistente para Administrar el acceso remoto, véase la sección Administración de la seguridad de los accesos). El dominio interno se llama MiEmpresa.Priv y el servidor DirectAccess (llamado DC2012) está integrado en el dominio. Dispone de un firewall cuya dirección IP interna es 172.16.0.254 y publica el puerto TCP 443 hacia la dirección 172.16.0.1. El servidor DirectAccess posee una interfaz privada con la dirección IP 172.16.0.1/24. Se ha instalado un certificado de tipo Web sobre el servidor DirectAccess con un nombre descriptivo: IP-HTTPS. Se ha creado un grupo DA_Clientes en el dominio y la máquina cliente DirectAccess en es miembro del mismo. Este grupo servirá para definir las máquinas autorizadas a conectarse mediante DirectAccess.
He aquí las etapas que debe seguir para instalar DirectAccess: En la consola Administrador del servidor, haga clic en Herramientas y, a continuación, seleccione Administración de acceso remoto. En el panel de navegación, en Configuración, haga clic en DirectAccess y VPN.
En la parte central, haga clic en Ejecutar el Asistente para introducción. Haga clic en Implementar solo DirectAccess. En la etapa Topología de red, seleccione la opción Tras un dispositivo perimetral (con un solo adaptador de red). Escriba el nombre público o la dirección IPv4 que utilizan los clientes para conectarse al servidor DirectAccess.
Haga clic en Siguiente. Haga clic en Finalizar para aplicar la configuración.
Dado que esta plataforma no dispone de una infraestructura de clave pública (PKI) el asistente generará automáticamente un certificado autofirmado para HTTPS y habilitará el proxy Kerberos. También habilitará los protocolos de traducción NAT64 y DNS64 en el entorno. Preste atención, este certificado se instalará sobre las máquinas cliente para que DirectAccess funcione. DirectAccess está, ahora, instalado. Basta con definir los equipos autorizados para conectarse a este servicio. Una vez aplicada la configuración, haga clic en Cerrar.
En la parte central, en la sección Paso 1 - Clientes remotos, haga clic en Editar.
Seleccione la opción Implementar DirectAccess completo para acceso de clientes y administración remota y, a continuación, haga clic en Siguiente. Elimine el grupo Equipos del dominio (MIEMPRESA\Equipos del dominio) y agregue el grupo DA_Clientes que ha creado en Active Directory como requisito previo a este ejemplo. Desmarque la opción Habilitar DirectAccess solo para equipos móviles (en un ámbito profesional, y fuera del perímetro de esta maqueta, es preferible dejar esta opción marcada). Haga clic en Siguiente.
Escriba la dirección de correo electrónico del equipo de soporte técnico y defina un nombre de conexión DirectAccess. Marque la opción Permitir que los clientes de DirectAccess usen la resolución local de nombres y, a continuación, haga clic en Finalizar. Esta opción permite al usuario utilizar los servidores DNS locales y, por tanto, que no todas las consultas DNS se envíen a los servidores DNS internos de la red de la empresa.
En la sección básica de la parte central, haga clic en Finalizar para aplicar la configuración.
Verifique los parámetros y haga clic en Aplicar. Una vez aplicada la configuración, haga clic en Cerrar. En el panel izquierdo de la consola de administración del acceso remoto, seleccione Estado de las operaciones y espere a que el estado cambie a: funciona correctamente.
Sólo queda probar desde un puesto cliente accediendo a un servidor Web interno o incluso a la carpeta SYSVOL del dominio (\\miempresa.priv\sysvol). Para verificar que se puede conectar mediante DirectAccess o, simplemente, que ha configurado correctamente DirectAccess desde la red local, siga las etapas siguientes desde un equipo con Windows 8: En el área de notificación de Windows, haga clic en el símbolo de red . Aparece la siguiente información:
Existe una guía de depuración (disponible únicamente en inglés en el momento de escribir estas líneas) en el sitio Web de Microsoft en la siguiente dirección: http://technet.microsoft.com/en-us/library/ee624056(WS.10).aspx
Preste atención, si desea trabajar con esta maqueta sobre un servidor Hyper-V, tendrá que configurar las tarjetas de red del servidor DirectAccess como tarjeta heredada (o Legacy) si encuentra problemas de flujo.
5. Supervisión de las conexiones Todas las soluciones de acceso remoto deben permitir saber qué usuario se conecta y qué acciones realiza mientras está conectado. Si bien las herramientas DirectAccess de Windows Server 2012 no permiten tener un nivel de información tan detallado como el que ofrece un servidor Forefront TMG, sí permiten supervisar mejor la actividad y el uso que las versiones anteriores de Windows Server. Windows Server 2012 incluye una nueva consola de supervisión que proporciona información útil acerca de los usuarios que se conectan de manera remota. La siguiente lista
presenta la información que puede obtenerse en esta consola (información que proviene, de hecho, de los contadores de rendimiento de Windows Server). Esta información está accesible desde la Consola de administración de acceso remoto. A continuación, en el panel izquierdo, haciendo clic en Panel accede al siguiente informe:
•
• • • • •
Total de clientes activos: incluye a los clientes de DirectAccess y VPN. Permite conocer cuántas conexiones simultáneas están en curso a través de VPN o DirectAccess. Total de clientes de DirectAccess activos: permite conocer cuántas conexiones simultáneas están en curso a través de DirectAccess. Total de clientes de VPN activos: permite conocer cuántas conexiones simultáneas están en curso a través de VPN. Total de conexiones acumuladas: permite conocer el número de conexiones remotas que se han realizado desde el último reinicio del servidor. Total de datos transferidos: permite conocer el volumen total de datos que han transitado por el servidor de acceso remoto desde su último reinicio. Máximo de conexiones de cliente: permite conocer el número máximo de conexiones simultáneas que han tenido lugar después del último reinicio del servidor de acceso remoto.
También puede encontrar información individual detallada acerca de los clientes en el menú Estado de cliente remoto, siempre en la Consola de administración de acceso remoto. Entre la información disponible, encontrará, por ejemplo: • • • • •
Nombre de usuario. Nombre de host. Dirección del ISP. Protocolo/Túnel. Duración de la conexión.
Conclusión Acaba de ver en este capítulo que, para proporcionar un acceso remoto a sus usuarios, tendrá que configurar un servidor de acceso remoto. Cuando sus usuarios se encuentren fuera de la empresa podrán acceder a los recursos internos utilizando bien una conexión de tipo Dial-up, una conexión VPN, o bien DirectAccess. Windows Server 2012 R2 sabe cómo gestionar las tres soluciones. Permite, además, agrupar los servidores de VPN y DirectAccess sobre el mismo servidor, lo cual presentaba problemas en ediciones anteriores de Windows Server. Incluye toda una serie de mejoras en el servicio de enrutamiento y en el acceso remoto que hace el despliegue de DirectAccess lo más sencillo posible y fácil de integrar con una solución VPN clásica. Windows Server 2012 R2 también le permite, gracias a las nuevas directivas de acceso, definir de forma muy precisa quién se conecta, cuándo y de qué manera. Si desea centralizar la seguridad de las conexiones de sus equipos, Windows Server 2012 le proporciona el rol de concentrador gracias a sus funciones RADIUS. Trabajando junto a la última versión del OS cliente de Microsoft (Windows 8.1), aprovechará también nuevas funcionalidades: • •
Auto-triggered (inicio automático): permite a las aplicaciones predefinidas conectarse automáticamente a redes de empresa iniciando una conexión VPN. Configuración avanzada de clientes VPN en PowerShell: permite utilizar un juego único de comandos PowerShell para configurar las conexinoes VPN (mediante el comando Add-VpnConnection).
Implementar un servidor Intranet/Internet
En este capítulo aprenderá a instalar y configurar un servidor Web gracias al rol de servidor IIS (Internet Information Services).
1. Presentación de IIS 8 a. Presentación general
IIS 8 (Internet Information Services) es la última versión del servidor Web de Microsoft. Se incluye de forma completa con Windows Server 2012, y proporciona una plataforma segura y fácil de administrar para albergar servicios Web y aplicaciones Web enriquecidas. Con Windows Server 2012 R2, se proporciona la versión 8.5 de la aplicación. IIS 8 es una plataforma Web unificada que integra IIS, ASP.NET, PHP, servicios FTP y Windows Communication Foundation (WCF: el modelo de programación de WCF es una capa de abstracción que unifica y simplifica el mecanismo de integración de los servicios Web, .NET Remoting, Microsoft Transaction Server y Microsoft Message Queuing). La compatibilidad hacia atrás de IIS 8.5 permite migrar con facilidad los sitios Web hospedados en versiones anteriores de IIS sin encontrar problema alguno. Como con IIS 6, IIS 7 e IIS 7.5, puede instalarse en el sistema operativo cliente (Windows 8) en su versión ligera. Windows 8 y Windows Server 2012 comparten el mismo núcleo, por lo que es sencillo desplegar aplicaciones desde su puesto de trabajo para, a continuación, hospedarlas en un servidor. Observe que Windows Server 2012 y Windows Server 2012 R2 no tienen una edición Web, puesto que la experiencia previa con los clientes de Microsoft indicaba que preferían utilizar una versión estándar antes que verse limitados en términos de funcionalidades. IIS 8.5 puede, también, instalarse en la versión mínima (Core) de Windows Server 2012 R2 (Windows Server 2012 ya permitía instalar IIS 8 en modo Core). Como con Windows Server 2008 R2 y a diferencia de Windows Server 2008, Windows Server 2012 y Windows Server 2012 R2 permiten instalar .NET Framework en modo core. b. Arquitectura heredada
La arquitectura de IIS se ha repensado en IIS 7 para facilitar la implementación de las funcionalidades y también la extensión de las posibilidades del servidor. En IIS 6, la estructura estaba compuesta por un único bloque que obligaba a instalar todo para utilizar el servidor Web. Con IIS 7 / 7.5, las funcionalidades se han desacoplado de forma que es posible cargar los módulos correspondientes a sus necesidades. Estos módulos están desacoplados en cinco categorías para la parte Servidor Web. • • •
Funcionalidades HTTP comunes (contenido estático, documentos por defecto, etc.). Desarrollo de aplicaciones (lenguajes incluidos: ASP.NET, ASP, CGI, etc.). Integridad y diagnósticos (registro, visor de peticiones, seguimiento, etc.).
• •
Seguridad (autenticación básica, autenticación Windows, autorización Digest, etc.). Rendimiento (compresión del contenido estático o dinámico).
Para la parte de Herramientas de administración, encontramos: • • • •
La consola de administración de IIS. Los scripts y herramientas de administración de IIS. El servicio de administración. La administración de la compatibilidad con IIS 6.
El servicio FTP (File Transfer Protocol) está separado de la parte servidor Web puesto que se trata, en lo sucesivo, de un servicio de rol aparte. Los módulos Servidor FTP y Consola de administración FTP están asociados a él. c. Administración
IIS 7 y 8 difieren de las versiones anteriores por la implementación de una nueva administración. La nueva consola de administración que centraliza la administración del conjunto de módulos del servidor ya no es un simple módulo. En efecto, se trata de una consola completa que se conecta sobre el servicio de administración La configuración también ha cambiado. En IIS 6, estaba almacenada en una metabase con formato XML. IIS 7 / 7.5 facilitan la implementación y sobretodo el mantenimiento de los servidores, desagregando esta configuración en varios archivos XML: • •
•
•
applicationhost.config: contiene la configuración global (lista de sitios, pools de aplicaciones, parámetros por defecto, etc.). redirection.config: contiene la información de redirección (utilizada por ejemplo cuando el contenido del sitio se encuentra en otro servidor o incluso cuando parte del sitio no debe estar disponible en caso de mantenimiento, etc.). web.config: contiene la configuración global ASP.NET del servidor (es posible crear un archivo individual por cada sitio que necesite una configuración específica; esto es útil cuando debe especificar parámetros diferentes a los de la configuración global del servidor). Esto permite realizar una administración más precisa de los parámetros de los sitios Web. machine.config: contiene las propiedades requeridas por las funcionalidades del Framework.
applicationHost.config y redirection.config se ubican en la ruta %windir%\system32\ inetsrv\config. Los archivos web.config y machine.config se encuentran en la carpeta %windir%\Microsoft.NET\Framework\version_framework\CONFIG. Existe una jerarquía entre los distintos archivos de configuración. Define una herencia de parámetros como pasaría con los permisos de seguridad NTFS. Esta jerarquía comienza por
el archivo machine.config y sigue el orden siguiente: web.config (de primer nivel), applicationHost.config y por último un archivo web.config opcional situado en la ruta del sitio o de la carpeta virtual. De este modo, se heredan las propiedades desde el archivo machine.config hasta el último archivo web.config del árbol. El almacenamiento de la configuración de sitios en archivos XML distintos (también llamada configuración distribuida) permite facilitar el despliegue o la copia de aplicaciones. Podrá copiar aplicaciones entre dos servidores frontales mediante un simple xcopy evitando cualquier error debido a una replicación o a cualquier sincronización. En lo sucesivo es posible automatizar las tareas administrativas gracias, principalmente, a PowerShell, a un nuevo proveedor WMI, a una nueva API.NET y sobre todo gracias a la herramienta AppCMD. AppCMD.exe permite realizar la mayoría de las tareas administrativas con ayuda de una sintaxis muy simple. La administración también puede delegarse. Puede especificar cuales son las funcionalidades que los usuarios no administradores deben gestionar. Esto permite por ejemplo configurar los parámetros ASP.NET de un sitio sin tener que usar privilegios de administrador. d. Novedades aportadas por IIS 8 en Windows Server 2012
Como hemos visto antes, Windows Server 2012 y Windows Server 2012 R2 proporcionan, respectivamente, las versiones 8 y 8.5 de IIS. Esta versión aporta un número de mejoras esperadas respecto a la versión anterior, pero también algunas novedades. •
•
• •
•
Evolución de la configuración: los archivos de configuración de IIS voluminosos pueden, en lo sucesivo, gestionarse fácilmente. Se han aportado un gran número de mejoras para optimizar el rendimiento de los servidores y las granjas de servidores que hospedan una gran cantidad de sitios. Evolución SSL: en las versiones anteriores de IIS, soportar un gran número de sitios web seguros mediante un certificado requería una dirección IP para cada sitio. Además, cuanto mayor era el número de sitios, más memoria se necesitaba. Antes, tras la primera visita, todos los certificados quedaban cargados. En lo sucesivo, los certificados se cargan únicamente cuando se accede al sitio y, a continuación, se eliminan de la memoria tras un periodo de inactividad. Centralización de certificados: provee un almacenamiento único para los certificados SSL de una granja y simplifica la gestión de enlaces SSL. Server Name Indication (SNI): el nombre de dominio virtual se incluye, en adelante, en la negociación SSL de forma que ya no es necesario disponer de una pareja dirección IP - puerto 443 para hospedar un sitio SSL y tener que dedicar una dirección IP para dotar de seguridad a un sitio. Restricción de direcciones IP dinámicas: esta funcionalidad que permite bloquear el acceso a los sitios desde ciertas direcciones IP ya existía en IIS 7 y las versiones anteriores, aunque obligaba a los administradores a introducirlas de forma manual. Con IIS 8, es posible bloquear estas direcciones IP en función de un número
• •
•
• •
máximo de consultas. En adelante, es posible configurar el servidor de modo que bloquee la conexión de un usuario en lugar de mostrarle una página de tipo 403.6: Acceso denegado: dirección IP rechazada. Restricciones de intentos de conexión FTP: permite configurar el número de intentos fallidos de realizar una conexión FTP antes de bloquear el acceso. Inicialización de aplicaciones: permite a los administradores configurar páginas temporales hasta que una aplicación haya terminado de iniciarse y se proporcione el acceso al "verdadero" sitio. Compatibilidad con dispositivos NUMA (Non Uniform Memory Access): esto permite evitar una degradación del rendimiento con la multiplicación de los núcleos del procesador y cuando no se ha optimizado la pareja núcleos/RAM del servidor. CPU Throttling: limita la CPU, la memoria y el ancho de banda que utiliza un pool de aplicaciones en un entorno. IIS 8 incluye ocho opciones adicionales. Soporte Mixto ASP.NET 3.5 y 4.5: IIS 8 para Windows Server 2012 permite ejecutar aplicaciones sobre todas las versiones del .NET Framework soportadas por Windows Server 2012.
La consola MMC IIS resulta obsoleta con Windows Server 2012. Se eliminará en las sucesivas versiones de Windows Server. e. Novedades aportadas por IIS 8.5 en Windows Server 2012 R2
Tras su aparición, Windows Server 2012 incluye numerosas mejoras en términos de seguridad, mientras que Windows Server 2012 R2 se centra en la evolución y la supervisión con las siguientes funcionalidades: •
•
•
•
Registro global avanzado: muchos campos pueden seleccionarse para registrarse gracias a los campos personalizados. Puede, de este modo, crear sus propios criterios de registro gracias a los orígenes de encabezado de la consulta, de encabezado de la respuesta o incluso de variables de servidor (por ejemplo: HTTP_ACCEPT ; LOGON_USER ; etc.). Registro en el registro de eventos Windows ETW (Event Tracing for Windows): enviar los eventos de registro hacia el registro ETW permite, al administrador, utilizar herramientas estándar de consulta o incluso distribuir vistas personalizadas para seguir, en tiempo real, el registro en ETW. Puede, a continuación, consultar los eventos en el registro Microsoft-Windows-IIS-Logging. Activación dinámica de sitios Web: con IIS 8.5, cuando el número de sitios configurados es importante (el valor por defecto es de 100), IIS no activa ningún sitio para no consumir recursos inútilmente. Cada sitio se inicia tras la primera consulta. Esto permite reducir, de manera significativa, la cantidad de recursos de sistema necesarios para su funcionamiento. Pausa de los procesos inactivos: con IIS 8.5, el administrador tiene la posibilidad de suspender un proceso de trabajo (worker process) inactivo en lugar de detenerlo. Un proceso de trabajo suspendido sigue vivo, paginado en disco, lo cual reduce los
recursos de sistema que consume. Cuando algún usuario acceda de nuevo al sitio, el proceso de trabajo volverá a memoria y estará, rápidamente, disponible de nuevo.
2. Instalación del rol Servidor Web (IIS) en modo Windows Server mínimo a. Instalación por defecto
Para realizar una instalación por defecto en un servidor Windows Server 2012 R2 en modo Core, utilice el comando PowerShell siguiente: Install-WindowsFeature Web-Server
b. Instalación completa
Para realizar una instalación completa de IIS 8.5 (con todas las funcionalidades) sobre un servidor Core Windows Server 2012 R2, utilice el siguiente comando PowerShell: Install-WindowsFeature -Name Web-Server -IncludeAllSubFeatures
Puede verificar que el rol está bien instalado utilizando el comando Get-WindowsFeature. Si lo ejecuta verá la lista de roles de servidor disponibles. Para cada uno de ellos verá una indicación Installed o Available. Para los servidores de rol instalados, se representa un subárbol con el estado de la instalación de cada servicio de rol.
3. Instalación del rol Servidor Web (IIS) en modo gráfico A continuación se muestran las distintas etapas a seguir para instalar el rol Servidor Web (IIS) en modo gráfico: En la consola Administrador del servidor, haga clic en Administrar - Agregar roles y características. Seleccione la opción Instalación basada en roles o características y, a continuación, haga clic en Siguiente. Seleccione su servidor en la lista (aquí DC2012) y, a continuación, haga clic en Siguiente. Marque la opción Servidor web (IIS) como se muestra y, a continuación, haga clic en Siguiente.
En el cuadro de diálogo Agregar características requeridas para Servidor Web (IIS), haga clic en Agregar características.
Haga clic en Siguiente. En la pantalla Características, haga clic en Siguiente. Lea la descripción del rol de Servidor Web y, a continuación, haga clic en Siguiente. En el ejemplo en curso, solamente utilizará las funciones básicas de IIS. Deje marcadas las opciones por defecto y, a continuación, haga clic en Siguiente.
Verifique las opciones marcadas y, a continuación, haga clic en Instalar.
Verifique que la instalación se ha desarrollado correctamente y, a continuación, haga clic en Cerrar. Para verificar que IIS 8.5 está operativo, abra Internet Explorer y, a continuación, en la barra de direcciones escriba la URL: http://localhost. Debería aparecer la ventana siguiente:
Crear un sitio Web Ahora que ha instalado su rol de Servidor Web (IIS), veremos cómo crear nuevos sitios y administrarlos fácilmente. En este capítulo configurará un sitio para su empresa (el contenido del sitio será mínimo, pues el objetivo de este libro no es formarle en los lenguajes de desarrollo Web).
1. Creación y configuración de un sitio En la consola Administrador del servidor, haga clic en Herramientas - Administrador de Internet Information Services (IIS). Por defecto la consola de administración de IIS se conecta al servidor local. Esto le permite cambiar la configuración y los parámetros del servidor. En el panel izquierdo, haga clic en el nombre de su servidor (aquí DC2012) para mostrar la lista de funcionalidades disponibles.
La primera vez que se conecte, se abre un asistente que le permite instalar Microsoft Web Platform. Microsoft Web Platform Installer es una herramienta gratuita que permite instalar componentes, aplicaciones web o gestores de contenidos de manera gratuita y con un solo clic. Puede hacer clic en Sí en la maqueta aunque no vayamos a utilizar esta funcionalidad en las siguientes etapas.
Por defecto, la página muestra las funcionalidades agrupadas por Área. Puede cambiar esta representación mediante la lista desplegable ubicada en la sección superior del panel central. De este modo, es posible agrupar por Área (por defecto), por Categoría o incluso sin agrupar. He aquí las distintas etapas para crear un nuevo sitio: Requisitos previos: debe haber creado una carpeta Empresa en la carpeta C:\inetpub\wwwroot. Desde la consola Administrador de Internet Information Services (IIS), haga clic con el botón derecho del ratón sobre el nombre de su servidor y, a continuación, seleccione la opción Agregar sitio Web (es posible realizar esta misma operación desde otros lugares. Por ejemplo, directamente desde el árbol de Sitios). Indique los datos como se muestra a continuación:
El nombre del sitio es meramente informativo, los espacios en blanco no suponen ningún problema. En este ejemplo, no informe el nombre del host y deje los parámetros del enlace por defecto. Estos parámetros de enlace sirven para definir sobre qué puerto y/o con qué nombre va a acceder al sitio (encontrará más detalles en la sección Uso de los encabezados host de este capítulo).
Una vez haya completado los campos, haga clic en Aceptar. Aparece el siguiente mensaje:
La razón por la que aparece este mensaje es porque IIS ya hospeda un sitio que utiliza el puerto 80 en la misma dirección IP. Se trata del sitio Web por defecto. No es posible, para una única dirección IP y un mismo puerto, tener varios sitios Web (salvo que utilicemos encabezados HTTP; este punto se aborda en la sección Uso de los encabezados host de este capítulo). Si trata de levantar el sitio Web obtendrá un mensaje de error. Para confirmarlo, siga los siguientes pasos: Haga clic en Sí en la ventana que presenta la advertencia del enlace duplicado. En el panel central, seleccione su sitio Web y, a continuación, en el panel derecho, haga clic en Iniciar. Aparecerá el siguiente mensaje.
En este ejemplo, cambiará el puerto sobre el que escucha el sitio Web. En el panel izquierdo, extienda el árbol Sitios para mostrar el sitio que acaba de crear y, a continuación, selecciónelo. En el panel derecho, en la sección Acciones, haga clic en Enlaces.
Seleccione el enlace HTTP y, a continuación, haga clic en Modificar. Escriba 8080 en el campo Puerto y, a continuación, haga clic en Aceptar para validar. A continuación, haga clic en Cerrar. Este puerto se define de forma arbitraria puesto que no está siendo utilizado por los servidores que sirven como ejemplo. Generalmente se utiliza para servidores de tipo proxy como puerto estándar.
En el panel de acciones, haga clic en Iniciar. Tendrá que mostrar algún documento en su sitio web. Para crearlo, abra el Bloc de notas y, a continuación, escriba el código siguiente:
Sitio web de mi Empresa He aquí mi primer sitio Web en IIS 8.5
Guárdelo como archivo en la ubicación: C:\inetpub\wwwroot\Empresa\default.htm Para comprobar su funcionamiento, abra Internet Explorer y, a continuación, escriba la dirección: http://localhost:8080
2. Uso de los encabezados host Si bien es posible utilizar puertos de escucha distintos para cada sitio Web, en la práctica esto no resulta una solución viable cuando varios sitios Web están hospedados sobre el mismo servidor. Este problema se presenta, en particular, para los sitios Web públicos. Los internautas no saben en qué puerto está configurado el servicio de su sitio Web y, por lo tanto, no es factible demandarles que indiquen el puerto concreto al que quieren conectarse para acceder a un sitio Web en Internet. Una de las soluciones que permiten resolver este problema de puertos consiste en configurar varias direcciones IP sobre su servidor Web. Cada IP se asocia, a continuación, con un sitio único. Si bien esta solución puede sacarnos del apuro en un uso interno, se convierte en una solución muy costosa para un uso público (las direcciones IP fijas en Internet representan una inversión y se proporcionan de forma limitada). Para poder administrar de forma óptima la ubicación de varios sitios Web, tendrá que utilizar los encabezados host. Estos encabezados permiten utilizar varios nombres de host para una única dirección IP. IIS escuchará las solicitudes entrantes y revisará la información enviada por el navegador. En función del nombre de host recibido, redirigirá la consulta del navegador hacia el sitio Web correspondiente.
En el siguiente ejemplo va a configurar el sitio creado en la etapa anterior para que escuche en la dirección www.miempresa.es. Requisitos previos: disponer de un servidor DNS funcional que hospede la zona MiEmpresa.es. En esta zona debe existir un registro de tipo A llamado www que apunte a la dirección IP 172.16.0.1 (dirección IP de su servidor Web). Consulte el capítulo Implementar los servicios de red de la empresa - Implementar los sistemas de resolución de nombres para obtener más información acerca de la configuración DNS. En la consola Administrador del servidor, haga clic en Herramientas - Administrador de Internet Information Services (IIS). Despliegue el árbol Sitios para mostrar el sitio creado en la etapa anterior de este capítulo (sitio Web de mi empresa). Seleccione su sitio y, a continuación, en el panel derecho, haga clic en Enlaces. En la ventana Enlaces de sitios, haga clic en Agregar. Complete la información de los campos tal y como se muestra a continuación:
Valide haciendo clic en Aceptar y, a continuación, en Cerrar.
También puede modificar el enlace existente para especificar estos parámetros. No obstante, gracias a este ejemplo, comprobará que es posible asociar puertos distintos a un mismo sitio incluso con nombres de host distintos. Pruebe, a continuación, la modificación abriendo Internet Explorer y escribiendo la dirección http://www.miempresa.es en la barra de direcciones.
Cada nombre de host que quiera utilizar en IIS debe existir. En un sitio Intranet, basta con agregar registros en su zona DNS de dominio. Para un uso público, tendrá que gestionar la zona DNS pública. O bien tiene acceso a una interfaz de administración que se lo permite, o bien solicita al administrador de su zona DNS crear los registros de acuerdo a las reglas.
3. Implementar una DMZ Una DMZ (Demilitarized Zone) o Zona desmilitarizada es una zona de la red en la que los usuarios de Internet pueden acceder a los servidores sin poner en peligro la seguridad de su red local. El objetivo de esta zona es limitar la superficie de exposición de sus redes. Organizando los servidores de modo que aquellos que albergan aplicaciones públicas estén en la red perimétrica, no permitirá el acceso a su red local desde Internet. De este modo, reforzará la seguridad de su red local impidiendo la comunicación con la misma. Existen dos implementaciones típicas de DMZ. La primera utiliza un firewall con tres interfaces de red o más (firewall multidominio).
La segunda utiliza dos firewalls. En el caso ideal, y para dotar de una máxima seguridad a la infraestructura, es recomendable utilizar dos modelos de firewall distintos. En efecto, si una persona malintencionada encuentra un fallo en el primero, ya tiene el trabajo prácticamente hecho para llegar a abrir el segundo, si son idénticos.
A continuación, sólo le queda gestionar los flujos entre Internet y la DMZ, y entre la DMZ y la LAN. En efecto, si sus servidores Web llaman a recursos de red, necesitarán un acceso a la misma. Basta con autorizar a los servidores de la DMZ para comunicarse con la LAN con los protocolos requeridos. A continuación, podrá restringir el acceso para mejorar la seguridad tanto en la DMZ como en su red local.
Del lado del servidor, Windows Server 2012 configura automáticamente las excepciones de su firewall. Habiendo agregado el rol de servidor IIS, ya ha autorizado automáticamente los flujos http y HTTPS. Sólo le falta gestionar los puertos abiertos en los equipos del firewall.
4. Implementación del CPU Throttling En un entorno multi-tenant (multicliente) es importante crear una maqueta ("sandbox" que podríamos considerar como un espacio dedicado) para cada cliente. Sin esta maqueta, un cliente podría, de forma intencionada o no, impactar en los demás clientes de forma negativa accediendo al contenido de los demás clientes o monopolizando recursos del servidor como, por ejemplo, la memoria, la CPU o incluso el ancho de banda. Desde IIS 8 para Windows Server 2012, esta maqueta se crea por pool de aplicaciones. Ofrece, al mismo tiempo, un límite a nivel de procesos Windows haciendo que cada cliente se ejecute en entidades distintas y estableciendo un límite en el uso de recursos para cada proceso. La funcionalidad de CPU Throttling no consiste en una reserva de recursos de CPU sino en un límite de uso máximo. Para configurarlo en su sitio Web, creado en las etapas anteriores, siga los siguientes pasos: En la consola Administrador del servidor, haga clic en Herramientas - Administrador de Internet Information Services (IIS). En la sección Conexiones, despliegue su servidor (DC2012) y, a continuación, seleccione Grupos de aplicaciones. En el panel central, seleccione su pool de aplicaciones (Sitio Web de mi Empresa).
En el panel Acciones, haga clic en Configuración avanzada.... Vaya a los parámetros de CPU:
•
•
• • • • •
Afinidad del procesador habilitada: permite especificar si los procesos de trabajo que utiliza este pool de aplicaciones deben ejecutarse sobre procesos específicos. Esta opción permite utilizar eficazmente las cachés de los procesadores en servidores multiprocesadores. Límite (1/1000 de %): indica que el uso máximo de CPU (este valor se define como 1/1000 de un %: en resumen, para definir un uso máximo del 10 %, habrá que escribir 10000 para que tenga en cuenta el 1/1000 de 10000, o bien el valor 10) para este pool de aplicaciones. SI hay varios procesos asociados a este pool, el límite se aplica a la suma total de los procesos. Acción de límite: indica la acción que se quiere realizar si se supera este límite: NoAction: no realiza ninguna acción. KillW3wp: IIS se detendrá. Throttle: esta opción reduce el uso de CPU al valor definido como límite. ThrottleUnderLoad: esta opción reduce el uso de CPU al valor definido como límite aunque únicamente cuando se alcanza la carga de CPU máxima. El pool de aplicaciones podrá utilizar más recursos siempre que el procesador esté inactivo.
Ejemplo de configuración de CPU Throttling Escriba 30000 en el campo Límite (1/1000 de %) para obtener un 30 % como umbral. Seleccione el valor Throttle para la opción Acción de límite. Simule una carga o utilice una herramienta como WCAT (http://www.iis.net/downloads/community/2007/05/wcat-63-%28x64%29) para hacerlo.
Instalar un sitio FTP con aislamiento de usuarios Para proporcionar un espacio de almacenamiento en Internet a sus usuarios, o incluso a los clientes para los que hospeda sitios Web, seguramente necesitará proporcionarles un acceso FTP. Para restringir su campo de acción y asegurar que no ven las carpetas de otras personas, tendrá que configurar el aislamiento de usuarios.
Requisitos previos: disponer de una instalación básica de IIS; haber creado las cuentas usuario1 y usuario2 en Active Directory.
1. Instalación del rol Servidor FTP En la consola Administrador del servidor, haga clic en Administrar - Agregar roles y características. Haga clic en Siguiente. Seleccione la opción Instalación basada en un rol o una funcionalidad y, a continuación, haga clic en Siguiente. Seleccione su servidor y, a continuación, haga clic en Siguiente. Despliegue el árbol Servidor Web (IIS). Marque la opción Servidor FTP y, a continuación, haga clic en Siguiente.
Haga clic en Siguiente. En la página que permite seleccionar las funcionalidades, haga clic en Siguiente. Verifique las opciones de selección y, a continuación, haga clic en Instalar. Una vez terminada la instalación, haga clic en Cerrar.
2. Configuración del aislamiento de usuarios Antes de pasar a la configuración del servicio FTP, va a crear datos que permitirán visualizar la correcta implementación del aislamiento de usuarios. Abra una ventana de comandos y escriba el siguiente comando: CACLS "C:\inetpub\ftproot" /G IUSR:R /T /E
Este comando permite dar permisos de lectura a la cuenta anónima IIS sobre la carpeta ftproot.
Cree una carpeta LocalUser en la carpeta ftproot y, en esta nueva carpeta, cree la carpeta Public. Esta carpeta servirá para almacenar el contenido que se provee a los usuarios anónimos. Cree un archivo de texto llamado archivopublico.txt en la carpeta Public. Cree una carpeta MIEMPRESA (nombre NetBIOS de su dominio) en la carpeta ftproot.
Preste atención, es importante que nombre esta carpeta con el nombre de su dominio. Si no respeta esta condición, el aislamiento de usuarios no funcionará correctamente y serán incapaces de encontrar su carpeta raíz. Cree las carpetas usuario1 y usuario2 en la carpeta MIEMPRESA. Cree un archivo de texto llamado archivousuario1.txt en la carpeta usuario1 y haga lo mismo con un archivo llamado archivousuario2.txt en la carpeta usuario2. En la consola Administrador del servidor, haga clic en Herramientas - Administrador de Internet Information Services (IIS). En el panel Conexiones, haga clic con el botón derecho sobre el nombre de su servidor y, a continuación, seleccione Agregar sitio FTP.... Rellene la información tal y como se describe más abajo y, a continuación, haga clic en Siguiente.
Seleccione Sin SSL en la sección SSL y, a continuación, haga clic en Siguiente. En este ejemplo, configurará el servidor FTP para que no exija el protocolo SSL. En la práctica, como utiliza una cuenta de dominio, convendrá dotar de seguridad a la autenticación. De este modo, tendrá que adquirir un certificado SSL (o entregarlo mediante una entidad emisora de certificados) y exigir SSL de forma que la información esté cifrada y evitar, de este modo, cualquier intercepción de las credenciales.
Marque la opción Anónima, en la lista Autorización seleccione Usuarios anónimos y marque la opción Leer. Haga clic en Finalizar. En la consola Administrador de Internet Information Services (IIS), en el panel Conexiones, despliegue el árbol DC2012 - Sitios - Mi Sitio FTP. En el panel central, haga doble clic en Autenticación FTP. En el panel central, haga clic con el botón derecho en Autenticación básica y, a continuación, seleccione Habilitar. Vuelva a su sitio FTP y, a continuación, haga doble clic en Reglas de autorización de FTP en el panel central. En la sección Acciones, haga clic en Agregar regla de permiso.... Las reglas de autorización permiten autorizar o denegar el acceso a los usuarios. Es posible precisar si un usuario tiene permisos de escritura o, simplemente, de lectura.
Seleccione Todos los usuarios y marque las opciones Leer y Escribir y, a continuación, valide haciendo clic en Aceptar.
Vuelva a su sitio FTP y, a continuación, haga doble clic en Aislamiento de usuarios FTP. Seleccione Directorio de nombres de usuario (deshabilitar los directorios virtuales globales).
Esta opción permite restringir el acceso de los usuarios a la carpeta física o virtual del FTP que tiene el mismo nombre que su cuenta FTP. No podrán subir en la arborescencia FTP. Las carpetas virtuales globales raíz se ignoran (una carpeta virtual global sirve como acceso directo hacia una carpeta física definida; esto permite dar acceso a una carpeta con un nombre diferente o simplificando la ruta de acceso; esto permite también definir autorizaciones de acceso distintas), los usuarios sólo podrán acceder a las que estén definidas explícitamente en su arborescencia. Las otras posibilidades son: Directorio físico de nombres de usuario (habilitar los directorios virtuales globales): esta opción aísla a los usuarios en la carpeta física que lleva el mismo nombre que su cuenta FTP. Las carpetas virtuales globales están accesibles en la medida en que el usuario tenga las autorizaciones asociadas. Directorio particular de FTP configurado en Active Directory: los usuarios están aislados en una carpeta base definida en las propiedades de su cuenta Active Directory. En el panel de acciones haga clic en Aplicar. Es momento de verificar el aislamiento de usuarios. Abra el navegador Internet Explorer. Escriba, en la barra de direcciones: ftp://dc2012. Debería obtener el siguiente resultado:
Se trata del resultado esperado puesto que está habilitado el acceso anónimo y no ha especificado credenciales algunas. Abra el explorador de Windows y escriba la dirección ftp://usuario1@dc2012 en la barra de direcciones. A continuación, valide. Obtiene una ventana de identificación, escriba el nombre de usuario usuario1 y su contraseña asociada. A continuación, haga clic en Iniciar sesión. Comprobará que solamente ve el contenido de la carpeta individual de usuario1.
En este ejemplo, ha utilizado un dominio y, por tanto, creado una carpeta correspondiente al nombre de dominio en ftproot. En el caso de que se utilice un servidor ftp autónomo, utilice el nombre de la carpeta LocalUser para crear carpetas de usuario.
3. Configuración de la restricción de intentos de conexión Una posible vulnerabilidad en un servidor consiste en un ataque del tipo "fuerza bruta" (un ataque por fuerza bruta consiste en un método utilizado para encontrar una contraseña o una clave. Se trata de probar, una a una, todas las combinaciones posibles. Este método de búsqueda exhaustiva tiene éxito en aquellas ocasiones en que la contraseña que se busca está formada por pocos caracteres) mediante los servicios FTP. Partiendo del principio de que las cuentas que utiliza FTP son, a menudo, cuentas de usuario físicas del sistema operativo resulta, teóricamente, posible adivinar la cuenta de administrador una vez conoce la versión del servidor FTP (por ejemplo: Administrador para un servidor Windows y root para un servidor Linux). Con IIS 8 y Windows Server 2012, Microsoft incluye la funcionalidad de dotar de seguridad integrada con el objetivo de prevenir ataques de tipo "fuerza bruta" sobre el servidor FTP. Observe que esta funcionalidad no se activa en el sitio FTP sino a nivel de servidor. Para implementarla, siga los pasos siguientes: En la consola Administrador del servidor, haga clic en Herramientas - Administrador de Internet Information Services (IIS). En el panel izquierdo, seleccione su servidor (DC2012). En el panel de funcionalidades, sección FTP, haga doble clic en Restricciones de intento de inicio de sesión de FTP. Marque la opción Habilitar restricciones de intento de (opción que no ha sido del todo bien traducida al castellano). Defina el número máximo de intentos de conexión fallidos así como el periodo de tiempo entre cada intento. Deje marcada la opción Denegar direcciones IP basándose en el número de intentos fallidos de inicio de sesión.
Haga clic en Aplicar en el panel Acciones.
Conclusión Acaba de ver en este capítulo que para administrar sitios Internet y/o Intranet debe utilizar el rol Servidor Web (IIS). IIS 8 e IIS 8.5 conservan la arquitectura de su predecesor, así como las mejoras que se han aportado en términos de seguridad y de modularidad. Aportan, no obstante, varias mejoras dedicadas a hospedar sitios Web y a la gestión multicliente. La seguridad sigue siendo el núcleo principal de mejora. En particular, las restricciones dinámicas de direcciones IP así como las restricciones de intentos de conexión FTP. Se ha evolucionado también la gestión de SSL y, en particular, el hecho de que el dominio virtual forme parte, en adelante, de la negociación SSL. La gestión centralizada de certificados permite, en sí misma, simplificar la renovación de los certificados; el nombre DNS de los certificados se lee y asocia directamente al sitio correspondiente gracias a su encabezado de host. Es, también, posible almacenar los archivos de certificados en un recurso compartido de archivos en la red, en lugar de hacerlo de manera local sobre cada servidor web para simplificar la administración de certificados.
La diferencia entre IIS 8 e IIS 8.5 se pone de manifiesto principalmente en la optimización del funcionamiento, aportando importantes mejoras, principalmente en lo relativo a proveedores de soluciones Cloud.
Introducción Este capítulo está dedicado a la securización de Windows Server 2012 R2. La seguridad se encuentra en el núcleo de este sistema operativo, cuya implantación más evidente es la instalación llamada "mínima", de ahí el nombre inglés "Core" para nombrarla. En este capítulo descubrirá cómo administrar esta versión tan particular y tan útil en un entorno hostil.
Principios del servidor Core Esta sección presenta las principales características del servidor Core, los dominios para los que ha sido previsto su uso, así como aquellos para los que no es posible utilizarlo.
1. Restricciones ligadas a una instalación mínima Con la opción de instalación mínima, la interfaz estándar de usuario (a saber, el intérprete de comandos gráfico de servidor) no está instalado. Por ello, las tareas de gestión del servidor se realizan mediante herramientas de interfaz de usuario remotas (RSAT), Windows PowerShell o, si tiene lugar, de forma local por línea de comandos (o Windows PowerShell). Por analogía, esta instalación mínima sigue llamándose Core, como en Windows 2008 Server y 2008 R2 Server, por parte de los usuarios. El interés de una instalación Core consiste en reducir la superficie de ataque, lo cual tiene un impacto en los roles que pueden instalarse en el servidor. La aplicación de las actualizaciones también se ha visto reducida, lo que facilita el ciclo de vida del servidor. Desde Windows Server 2008 R2, se incluye el Framework .NET en la edición Core, lo cual abre nuevos usos (PowerShell, sitios IIS...). Es posible instalar los siguientes roles en un servidor Windows Server 2012 R2: • • • • • • • •
Controlador de dominio (típicamente un RODC). Servicios de Certificados de Active Directory. Servicios AD LDS (Active Directory Lightweight Directory Services). Servidor DHCP y DNS. Servidor de archivos (y Administrador de recursos del servidor de archivos). Hyper-V (una de sus especialidades). Acceso remoto. Servicios de impresión y de digitalización de documentos.
•
Servidor Web IIS (parte de ASP.NET):
• • •
BranchCache (retransmisión). Servidor multimedia. Servicios WSUS (Windows Server Update Services).
2. Instalación mínima La instalación Core es sucinta, ¡lo cual se pone de manifiesto desde la instalación! Sólo se necesitan 5 minutos, aproximadamente, desde que se inserta el DVD de instalación hasta que aparece el prompt de autenticación, incluso sin haber automatizado la instalación En esta etapa, nada indica que se trata de una instalación mínima. Es una vez autenticados cuando la diferencia se hace patente.
No se trata de una captura de pantalla parcial, sino de la pantalla completa. No hemos ocultado Explorer en ningún sitio, ¡su archivo ejecutable está completamente ausente en el disco duro! El objetivo consiste en reducir al máximo los componentes y recursos, para adecuarlos en términos de seguridad y para las máquinas virtuales.
Desde el punto de vista de la seguridad, cuantos menos elementos instalados, ejecutándose o accesibles haya, mayor será el nivel de seguridad. Por ejemplo, y puesto que no es posible disponer de Explorer.exe, cualquier fallo de seguridad que afecte a este componente no tendrá el más mínimo efecto en un servidor Core. Más allá del hecho de que el fallo no sea explotable, no es necesario instalar cualquier hotfix que lo corrija más adelante. Si bien ya existía una versión Core de Windows Server 2000, se ha reducido en torno al 60% el número de actualizaciones a instalar, y en torno al 40% respecto a Windows Server 2003. El impacto del sistema operativo se ha reducido considerablemente: • •
Tras el arranque, con una única sesión abierta, se utilizan 300 MB de memoria frente a los más de 500 MB en una instalación completa. Se necesitan 6,3 GB de espacio en disco, frente a los casi 11 GB para una instalación completa. Windows Server 2012 R2 incluye, sistemáticamente, una partición de unos 350 MB.
Observe también que, con Windows Server 2012 R2, Windows Defender se instala automáticamente con la versión Core.
Configurar de manera local un servidor Core La ausencia de consolas de administración no incita a administrar de forma local un servidor Core, lo cual forma parte del objetivo. Una vez se ha realizado la configuración mínima, basta con conectarse desde un host de remoto que posea consolas de administración que permitan superar estas restricciones. Esta sección cubre la configuración inicial para autorizar una administración descentralizada. Con Windows Server 2012 R2, también es posible utilizar la consola Administrador del servidor para administrar un servidor Core (habilitando winrm en el servidor Core previamente).
En el modo Core, cuando se abre una sesión, se utiliza la línea de comandos como interfaz, y ésta se abre de forma automática. Para que PowerShell sea la línea de comandos por defecto en Windows Server 2012 R2, ejecute el siguiente comando en una ventana PowerShell: $RegPath = "Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon" Set-ItemProperty -Confirm -Path $RegPath -Name Shell -Value ’PowerShell.exe -noExit -Command "$psversiontable’ Restart-Computer
1. Sconfig Para simplificar la configuración inicial de un Servidor Core, a partir de Windows Server 2008 R2 se incluye una nueva herramienta: sconfig. Esta consola permite configurar los siguientes elementos desde su menú interactivo: • • • • • • •
Unirse a un dominio o grupo de trabajo. Cambiar el nombre del equipo. Agregar un administrador local. Configurar la administración remota. Conectarse a Windows Update. Definir la configuración de red. Configurar la fecha y hora.
Abrir esta herramienta es tan sencillo como escribir su nombre en una ventana de comandos: sconfig.
Habrá comprendido, si tiene la suerte de poseer Windows Server 2012 R2, que no será necesario realizar la mayor parte de las configuraciones que siguen. No obstante, siempre es interesante conocer los distintos métodos que se ofrecen.
2. Configurar la fecha y la hora Ciertas acciones, evidentes sobre un servidor clásico, pueden resultar desconcertantes en esta versión depurada. Una de las primeras a realizar sobre un servidor consiste en configurar la fecha y la hora. Incluso si se va a unir a un dominio, debe tener, por defecto, un desfase menor a 5 minutos respecto a la fecha y hora del dominio para que Kerberos funcione correctamente y permita su unión al dominio.
Existen varias soluciones (los comandos time y date siguen existiendo), aunque a continuación se presenta cómo abrir la interfaz gráfica en un servidor Core: Desde una línea de comandos, ejecute controltimedate.cpl:
3. Parámetros regionales Si desea modificar los parámetros regionales, puede utilizar el comando control intl.cpl.
4. Resolución de pantalla Para cambiar la resolución de la pantalla ya no es preciso, como en la versión anterior, utilizar la base de registro. Microsoft ha incorporado el comando Set-DisplayResolution. Utilice, por tanto, el siguiente comando: Set-DisplayResolution [-Width] [-Height]
5. Salvapantallas También es posible modificar el salvapantallas por línea de comandos. Para ello, abra el editor regedit desde la línea de comandos abierta en pantalla. Navegue, en la arborescencia, hasta la ruta: HKEY_CURRENT_USER\Control Panel\Desktop Existen cuatro claves que le permiten administrar el nombre del salvapantallas, el bloqueo automático de la sesión tras el inicio del salvapantallas y el tiempo de espera antes de su ejecución: • •
• •
ScreenSaveActive: permite habilitar o deshabilitar el salvapantallas de forma global. Puede tomar los valores 1 (activo) o 0 (deshabilitado). SCRNSAVE.EXE: indica la ruta del salvapantallas que se quiere utilizar. El parámetro por defecto es C:\Windows\system32\logon.scr. El salvapantallas scrnsave.scr está disponible en el servidor y evita un consumo del procesador inútil, especialmente en un entorno virtual. ScreenSaverIsSecure: permite habilitar o no el bloqueo de la sesión tras la ejecución del salvapantallas. Su valor por defecto es 1, que habilita esta protección. ScreenSaveTimeOut: número de segundos antes de que se ejecute el salvapantallas. Por defecto, el valor está fijado a 600 segundos.
Con la instalación sólo está disponible la clave ScreenSaveActive. Las otras tres se crean manualmente como "valores cadena" (REG_SZ).
En el marco de un dominio Active Directory, estos parámetros se administran mediante las directivas de grupo de forma centralizada.
6. Nombre del servidor Por defecto, al servidor se le asigna un nombre de máquina aleatorio, siempre con el prefijo WIN-. • •
Para conocer el nombre actual, ejecute el siguiente comando desde la línea de comandos: hostname Para cambiar el nombre del servidor, ejecute el comando siguiente desde la línea de comandos:
netdom renamecomputer /NewName:DC2012 •
Es preciso reiniciarlo para que se tenga en cuenta el cambio: Por línea de comandos:
shutdown /r /t 0 /C "renombrado del servidor"
Mediante PowerShell: Restart-Computer
7. Administración de controladores Es posible administrar los controladores por línea de comandos gracias a la herramienta pnputil. Puede enumerar los controladores instalados y que se están ejecutando mediante el comando: Pnputil -e
Para agregar e instalar controladores suplementarios, hay que utilizar los parámetros -a y -i y precisar la carpeta donde se encuentran: Pnputil -a -i c:\miscontroladores\*.inf
Para obtener la lista de controladores habilitados, utilice el siguiente comando (no olvide el espacio tras el signo =): -sc query type= driver
8. Configuración de red El servidor utiliza, por defecto, un direccionamiento DHCP sobre todas las interfaces. Para cambiar a un direccionamiento por IP estática, tiene que utilizar el comando PowerShell Set-NetIPAddress. Cada tarjeta de red posee un número atribuido que se utiliza en el
comando Get-NetIPInterface para determinar la tarjeta de red a la que se desea aplicar los cambios. Para enumerar las tarjetas de red y ver los identificadores atribuidos por Windows, ejecute el siguiente comando desde la línea de comandos PowerShell: Get-NetIPInterface
Por ejemplo, si desea configurar la tarjeta de red con un identificador 12 con un direccionamiento por IP estática, ejecute: Set-NetIPAddress -InterfaceIndex 12 -IPAddress 172.16.0.1 -PrefixLength 16
Donde: • • •
InterfaceIndex es el valor de la columna IfIndex detallada en la etapa 2 (en este ejemplo, 12). IPAddress es la dirección IP estática que se quiere definir (en este ejemplo, 172.16.0.1). PrefixLength es la longitud del prefijo (otra forma de máscara de subred) de la dirección IP que ha definido (en este ejemplo, 16).
Para configurar la dirección 172.16.0.2 como servidor DNS primario, ejecute el siguiente comando: Set-DNSClientServerAddress -InterfaceIndex 12 -ServerAdresses 172.16.0.2
Debería obtener un resultado equivalente al siguiente:
Para configurar el sufijo DNS por defecto, hay que modificar la base de registro. Para ello, ejecute desde la línea de comandos: reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v "NV Domain" /d "MiEmpresa.Priv" /f
9. Activación de Windows La activación de la licencia de Windows puede administrarse por línea de comandos. El script slmgr.vbs se instala con Windows en la ruta %systemroot%\System32 para ello. Recuerde que, a diferencia de las versiones anteriores de Windows, la activación es obligatoria, incluso con una licencia por volumen. Este script funciona, también, con KMS (Key Management Service). Para verificar el estado de activación actual, ejecute el comando: cscript %systemroot%\System32\slmgr.vbs /dlv
En este ejemplo, la licencia expira en 180 días. Se trata de una versión de evaluación de Windows no registrada. Si simplemente quiere conocer la fecha en la que expira la licencia, ejecute el script con el parámetro /xpr. cscript %systemroot%\System32\slmgr.vbs/xpr
Por defecto, el servicio KMS se encuentra automáticamente en su dominio Active Directory con la consulta DNS siguiente: _vlmcs._tcp.miempresa.local. Si existe esta entrada DNS, el servidor intentará conectase al puerto TCP 1688. Puede, de este modo, indicar manualmente el nombre del servidor KMS con el parámetro -skms. Para iniciar manualmente la activación de Windows, ejecute el comando: cscript %systemroot%\System32\slmgr.vbs /ato
10. Gestión del informe de errores El servicio de informe de errores puede configurarse por línea de comandos. Para verificar la configuración actual, ejecute el comando: serverWerOptin /query Para activar el informe de errores simple: serverWerOptin /summary Para activar el informe de errores detallado: serverWerOptin /detailed Para desactivar el informe de errores: serverWerOptin /disable
11. Configurar el archivo de paginación El archivo de paginación (PageFile) se gestiona, automáticamente, por defecto. Para conocer la configuración actual, puede utilizar el comando: wmic pagefile list /format:list
Antes de configurar manualmente el PageFile, es preciso deshabilitar la administración automática: wmic computersystem where name="%computername%" set AutomaticManagedPagefile=False
Para forzar un tamaño de PageFile de 2 GB: wmic pagefileset where name="C:\\pagefile.sys" set InitialSize=2048, MaximumSize=2048
Es necesario reiniciar el servidor para que el cambio tenga efecto.
12. Unirse a un dominio El comando netdom permite unirse a un dominio Active Directory existente. Ejecute, desde la línea de comandos: netdom join /domain: /userd: /password:*
El símbolo * indica que debe solicitarse la contraseña, evitando tener que escribirla en claro en la consola. El mismo comando permite sacar un equipo de un dominio Active Directory: netdom remove Igual que con Windows Server 2008 R2 y Windows Server 2012, es posible unirse a un dominio sin estar conectado a la red del dominio en ese preciso momento. El capítulo Despliegue de servidores y puestos de trabajo cubre con detalle esta operativa (sección Unirse al dominio sin red).
13. Administrar el registro de eventos Si bien la consola Visor de eventos permite visualizar los registros de un servidor remoto, puede gestionarlos de forma local desde el servidor Core. Es posible mostrar la lista de los registros de eventos en la consola mediante el comando: wevtutil el La ventana Línea de comando, sin ser ideal para una visualización masiva, ni muy rápida, puede filtrar los resultados de salida especificando el número de eventos que se quiere mostrar. Por ejemplo, para mostrar únicamente los cinco últimos eventos: wevtutil qe System /c:5 /f:Text También es posible visualizar solamente los cinco últimos errores agregando el parámetro "/q:*[System[(Level=1 or Level=2)]]".
• • • •
El nivel 1 se corresponde con los eventos "críticos". El nivel 2 se corresponde con los eventos de "error". El nivel 3 se corresponde con los eventos de "advertencia". El nivel 4 se corresponde con los eventos de "información".
El siguiente comando permite guardar el registro abierto en un archivo y comenzar así un nuevo registro: wevtutil cl system /bu:c:\MisDocumentos\syslog.evtx
Administración remota 1. Activación del Escritorio remoto Como con la versión completa de Windows Server 2012, el acceso remoto no está activado por defecto. Puede verificar el estado de su activación con el siguiente comando: cscript.exe c:\windows\system32\scregedit.wsf /AR /v
Como se explica en el capítulo Servicios de Escritorio remoto, la clave fDenyTSConnections deshabilita el control remoto cuando su valor es 1, como es el caso por defecto. El mismo script permite cambiar la clave a cero y autorizar las conexiones: cscript.exe c:\windows\system32\scregedit.wsf /AR 0
En este estado, sólo los clientes que ejecuten al menos Windows Vista o Windows Server 2008 podrán conectarse. Para autorizar la conexión de clientes de versiones anteriores: cscript.exe c:\windows\system32\scregedit.wsf /cs 0
La siguiente captura de pantalla muestra los comandos descritos anteriormente y permite, mediante el comando netstat y su filtro sobre el valor 3389 (puerto TCP de los servicios de Escritorio remoto) darse cuenta de que el servicio Escritorio remoto no estaba habilitado antes de ejecutar estos comandos.
2. Activación de WinRM WinRM es la implementación de Microsoft del protocolo WS-Management. El objetivo consiste en poder comunicar dos sistemas del sistema de información, pudiendo atravesar correctamente los firewalls. Para instalar WinRM, ejecute el siguiente comando desde la línea de comandos: WinRM quickconfig. Para verificar que WinRM está activo y escuchando ejecute el comando: winrm enumerate winrm/config/listener
Quickconfig se encarga de agregar la excepción sobre el firewall para que el servicio esté accesible a través de la red.
Por defecto, WinRM utiliza el protocolo HTTP. Es posible utilizar HTTPS, con la condición de tener instalado un certificado válido (que no haya expirado, y que no sea autofirmado). Para ello, basta con especificar el transporte HTTPS: WinRM quickconfig transport:https Si desea utilizar WinRM para acceder a un servidor que no esté en su dominio Active Directory, debe utilizar un certificado SSL, o bien utilizar la lista de equipos aprobados. Esta lista está situada del lado del cliente, y puede administrarla potencialmente mediante una directiva de grupo, facilitando así las altas y las bajas de servidores en esta lista. Si desea administrar localmente esta lista, puede utilizar el comando siguiente para agregar servidores: winrm set winrm/config/client @{TrustedHosts=""}
Será preciso reemplazar miLista por uno o varios elementos separados por comas. Es posible utilizar direcciones IP y nombres DNS. Para obtener la lista actual de hosts aprobados: winrm get winrm/config/client
Si sus servidores pertenecen a un dominio Active Directory, puede administrar WinRM desde las directivas de grupo:
Sería una pena mostrar este protocolo sin hablar, por ejemplo, de sus capacidades. He aquí algunas posibilidades que ofrece WinRM. •
Mostrar el resultado del comando ipconfig /all de un servidor remoto:
winrs -r:NombreDelServidor ipconfig /all •
Especificar una cuenta de usuario y una contraseña (la contraseña se solicita a continuación):
winrs -r:NombreDelServidor -u miotracuenta ipconfig /all •
Ejecutar una consulta WMI:
winrm get wmicimv2/win32_service?name=W32Time -r :NombreDelServidor
WinRM está, también, disponible en las versiones anteriores de Windows (XP, 2003) como componente suplementario. Puede acceder a él descargándolo de la siguiente dirección: http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=8 45289ca-16cc-4c73-8934-dd46b5ed1d33
Dotar de seguridad al servidor Core 1. Administración del firewall Como en la versión completa, el firewall de Windows está habilitado por defecto en la edición mínima. Esto resulta bien visible pues el servidor no responde al comando ping,
mientras que la dirección MAC correspondiente a la IP está visible con el comando arp -a. La gestión de las reglas de firewall puede volverse compleja, por lo que resulta útil poder administrarlas a distancia. Esto puede realizarse mediante las directivas de grupo, pero también utilizando la consola adecuada de forma remota. Antes de ello, es necesario haber autorizado la administración de las reglas de firewall a distancia sobre el servidor, ejecutando el siguiente comando: netsh advfirewall set currentprofile settings remotemanagement enable
La consola Firewall de Windows con seguridad avanzada no permite seleccionar directamente un equipo remoto. Para ello, es necesario ejecutar el administrador de consola mmc y, a continuación, agregar la consola Firewall de Windows con seguridad avanzada y, a continuación, tendrá la posibilidad de seleccionar el equipo concreto. Encontrará más información acerca de la configuración del firewall en modo gráfico en el capítulo Securizar su arquitectura. Las demás consolas mmc pueden estar autorizadas sobre el firewall para poder utilizarse de forma remota. He aquí una lista de los elementos que se pueden visualizar con los nombres correspondientes en las reglas: • • • • •
Servicios: Administración remota de los servicios. Programador de tareas: Administración remota de las tareas programadas. Visor de eventos: Administración remota de los visores de eventos. Monitor de confiabilidad y rendimiento: Registro de alertas de rendimiento. Administración de almacenamiento y recursos compartidos: Compartición de archivos e impresoras.
Netsh advfirewall firewall set rule group="nombre_de_las_reglas" new enable=yes
Para administrar IPsec de manera remota, es necesario habilitar, en primer lugar, su administración remota: cscript \windows\System32\scregedit.wsf /im 1
Para que la administración remota de volúmenes funcione, es necesario iniciar, previamente, el servicio de disco virtual: net start vds
2. Administración automática de las actualizaciones La activación o desactivación de actualizaciones automáticas puede administrarse de forma local. Si el servidor forma parte de un dominio Active Directory, debería administrar preferentemente esta configuración mediante las directivas de grupo. •
Para saber si están habilitadas las actualizaciones:
cscript C:\Windows\System32\Scregedit.wsf /au /v •
Para habilitar las actualizaciones:
cscript C:\Windows\System32\Scregedit.wsf /au 4
Si obtiene el siguiente mensaje de error: Scregedit.wsf(777, 3) (null): 0x80240037, elimine la siguiente clave de registro: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate •
Para deshabilitar las actualizaciones :
cscript C:\Windows\System32\Scregedit.wsf /au 1
Puede forzar la verificación inmediata de las actualizaciones ejecutando el comando: wuauclt /detectnow Puede forzar la instalación inmediata de las actualizaciones ejecutando el comando: wuauclt /install A pesar de estos comandos, el servicio de actualizaciones almacena la fecha y hora de la última verificación. También, después de la petición inicial, se impone un tiempo de espera. Para acelerar el proceso puede suprimir la clave del registro que contiene la fecha y hora de la última y de la próxima verificación: net stop wuauserv
reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ WindowsUpdate\ Auto Update" /f net start wuauserv wuauclt /detectnow
Sigue existiendo un retardo de varios minutos. Para consultar la lista de actualizaciones instaladas, utilice el comando siguiente: wmic qfe list
3. Hacer una copia de seguridad del servidor La instalación Core se utiliza a menudo en un entorno hostil, de modo que es útil poder realizar al menos copias de seguridad locales del sistema. La administración de las copias de seguridad se realiza instalando la funcionalidad Windows Server Backup mediante PowerShell: Add-WindowsFeature Windows-Server-Backup
Para iniciar manualmente una copia de seguridad, es preciso utilizar el comando wbadmin. En nuestro ejemplo, vamos a realizar una copia de seguridad del lector C:\ en la carpeta compartida \\otroservidor\carpetascompartidas\copiasdeseguridad: wbadmin start backup -backuptarget :\\otroservidor\carpetascompartidas\copiasdeseguridad -include:c: -allcritical -vssfull -quiet
Las rutas UNC pueden utilizarse directamente como destinos de la copia de seguridad. Se creará una carpeta llamada "WindowsImageBackup". A continuación se creará automáticamente una carpeta con el nombre del servidor. Cualquier copia de seguridad anterior se borrará de forma automática. La restauración completa puede hacerse utilizando el DVD de instalación (opción restauración). Para obtener más información acerca del uso de Windows Server Backup, consulte el capítulo El ciclo de vida de su infraestructura.
Implementar un servidor Core y sus aplicaciones asociadas
1. Instalación de roles y características Los comandos oclist y ocsetup presentes en Windows Server 2008/2008 R2 han dado paso, en lo sucesivo, a los comandos PowerShell Get-WindowsFeature y Add-WindowsFeature desde Windows Server 2012. El primero enumera los roles instalados o no, y el segundo permite instalarlos. Para eliminar un rol o una característica, será preciso utilizar el cmdlet PowerShell Remove-WindowsFeature. Un ejemplo de salida por pantalla del comando Get-WindowsFeature es:
a. Roles de red
La instalación de roles de red se limita a un simple comando. He aquí los comandos que permiten realizar la instalación de los distintos roles de red disponibles. Estos roles consumen pocos recursos de sistema pero son necesarios permanentemente. Utilizar una instalación mínima permite dotarlos de seguridad y limitar los cortes de servicio gracias a la reducción del número de actualizaciones de seguridad a instalar. Instalar el rol DHCP Server Para instalar el rol DHCP Server, utilice los siguientes comandos: Add-WindowsFeature DHCP
Para autorizar el servidor DHCP, ejecute:
Add-DhcpServerInDC -DnsName dc2012.MiEmpresa.Priv
Si el servidor se convierte, a continuación, en controlador de dominio habrá que autorizarlo de nuevo. Para crear un ámbito sobre el servidor DHCP que incluye el rango de direcciones 172.16.0.100 a 172.16.0.250: Add-DhcpServerv4Scope -Name "Ámbito de mi empresa" -StartRange 172.16.0.100 -EndRange 172.16.0.250 -SubnetMask 255.255.255.0
Para definir un rango de exclusión: Add-DHCPServerV4ExclusionRange -ScopeId 172.16.0.0 -StartRange 172.16.0.100 -EndRange 172.16.0.120
Para proveer una dirección IP de la puerta de enlace por defecto y los servidores DNS en los contratos DHCP: Set-DhcpServerv4OptionDefinition -OptionId 3 -DefaultValue 172.16.0.254 Set-DhcpServerv4OptionDefinition -OptionId 6 -DefaultValue 172.16.0.1
Para proveer el sufijo DNS en el contrato DHCP: Set-DhcpServerv4OptionDefinition -OptionId 15 -DefaultValue MiEmpresa.Priv
Para habilitar el ámbito: Set-DhcpServerv4Scope -ScopeId 172.16.0 -Name "Ámbito de mi empresa" -State Active
El comando netsh sigue existiendo, si no quiere utilizar PowerShell. Puede consultar la lista de argumentos utilizando el comando netsh dhcp /?. A continuación, puede obtener la misma sintaxis para obtener ayuda sobre un argumento. Por ejemplo: para obtener ayuda sobre la forma de agregar un ámbito: netsh dhcp server add /? Instalar el rol DNS server Para instalar el rol DNS Server, utilice el comando siguiente: Add-WindowsFeature DNS
Para agregar una zona DNS primaria local sobre el servidor: Add-DnsPrimaryZone -Name MiEmpresa.Priv -Filezone MiEmpresa.Priv.dns
Es muy sencillo agregar entradas de forma manual. Por ejemplo, para declarar un segundo servidor DNS para la zona: Add-DnsServerResourceRecord -ZoneName MiEmpresa.Priv -Name NombreDelServidor -A -IPV4Address 172.16.0.2 Add-DnsServerResourceRecord -ZoneName MiEmpresa.Priv -NS -Name MiEmpresa.Priv -NameServer NombreDelServidor.MiEmpresa.Priv
La zona no acepta, por defecto, actualizaciones dinámicas. Para autorizarlas, es necesario utilizar el comando: Set-DnsServerPrimaryZone -Name MiEmpresa.Priv -DynamicUpdate NonSecureAndSecure
Puede ver todas las entradas de una zona por línea de comandos: Get-DnsServerResourceRecord -Name MiEmpresa.Priv
Para enumerar todas las zonas declaradas en el servidor: Get-DnsServerZone
Windows Server 2008 R2 incluye la securización del DNS (DNSSEC), lo que permite verificar que la fuente es digna de confianza para la resolución y la transferencia de zonas. Una infraestructura de tipo PKI permitirá proteger las entradas DNS. b. El rol servidor de archivos
A diferencia de los roles de red, se proporcionan varios roles en función de sus necesidades. Puede seleccionar instalar o no FRS, RFRS, DFS, SIS e incluso NFS. El capítulo Arquitectura distribuida de acceso a los recursos de este libro cubre con detalle la administración distribuida de recursos mediante DFS, por lo que aquí nos interesaremos por las especificidades ligadas a la instalación Core. Este tipo de instalación es adecuado para este rol, pues la disponibilidad es vital para la mayoría de usuarios. Podrá utilizarse una mayor cantidad de memoria gracias al bajo perfil de consumo del sistema operativo, y la reducción del número de actualizaciones reduce los cortes del servicio. •
Instalación del servicio de compartición de archivos con PowerShell:
Add-WindowsFeature FS-FileServer •
Instalación del servicio DFS:
Add-WindowsFeature FS-DFS-Namespace •
Instalación del servicio Replicación DFS:
Add-WindowsFeature FS-DFS-Replication •
Instalación del servicio NFS:
Add-WindowsFeature FS-NFS-Service
Windows Server 2012 incluye el servicio FSRM (File Server Resource Manager) en su edición Core. Esto permite administrar el almacenamiento burocrático (gestión de cuota, bloqueo de archivos por extensión e informes sobre el consumo de espacio en disco) así como tener en cuenta el control de acceso dinámico, que se aborda en el capítulo Securizar su arquitectura. Para instalar FSRM: Add-WindowsFeature FS-Resource-Manager
La consola Administrador de recursos del servidor de archivos debe estar instalada en el equipo utilizado para administrar FSRM: Import-module servermanager Add-WindowsFeature RSAT-FSRM-Mgmt
Basta, a continuación, con agregar las excepciones sobre el firewall para administrar de manera remota los recursos compartidos (sobre el servidor Core en entrada y sobre el equipo que ejecuta el administrador del servidor): netsh advfirewall firewall set rule group="Administración remota de recursos del servidor de archivos" new enable="yes" netsh advfirewall firewall set rule group="Administración remota de volúmenes" new enable="yes"
c. El rol servidor de impresión
El rol de servidor de impresión se instala por línea de comandos PowerShell: Add-WindowsFeature Print-Services
Agregar una impresora al servidor: Desde un equipo Windows 8 u otro Windows Server 2012 R2 que no sea la edición Core, abra la consola administración de impresión. Si no se encuentra en un servidor Windows Server 2012 R2, puede agregarla independientemente utilizando el comando: Add-WindowsFeature RSAT-Print-Services
A continuación, basta con administrar el rol igual que en la edición completa.
2. Servicio de directorio (AD) El despliegue y la configuración de los servicios de directorio se han simplificado con Windows Server 2012, y esta simplificación también se encuentra en la edición mínima. En efecto, si antes era necesario proporcionar los archivos de respuesta para el despliegue, en lo sucesivo tiene a su disposición un conjunto de comandos PowerShell para realizar el despliegue. Para empezar, hay que instalar el servicio de rol Active Directory (AD DS): Add-WindowsFeature AD-Domain-Services
A continuación, es necesario desplegar un nuevo bosque: Install-ADDSForest -DomainName "MiEmpresa.Priv" -DomainNetBIOSName MIEMPRESA
El rol servidor DNS se instala de manera automática y, una vez finalizada la instalación y la creación del bosque, el servidor reinicia. La instalación de un nuevo dominio hijo o dominio en la arborescencia se realiza mediante Windows PowerShell:
Install-ADDSDomain -NewDomainName hijo -ParentDomainName MiEmpresa.Priv
La instalación de un controlador de dominio suplementario (réplica) mediante Windows PowerShell se realiza mediante el siguiente comando: Install-ADDSDomainController -DomainName miempresa.priv
3. Ejecutar aplicaciones de 32 bits Windows Server 2012 es un sistema operativo que existe, únicamente, en 64 bits. No obstante, las aplicaciones de 32 bits pueden ejecutarse gracias a una emulación (Wow64 por Windows On Windows). Siendo el objetivo principal de un servidor Core reducir la superficie de ataque y, en particular, evitar que los virus de 32 bits puedan funcionar, se le aconseja desactivar la emulación WoW64 si no tiene aplicaciones que la necesiten. Para ello, basta con eliminar el paquete ServerCore-WOW64 mediante PowerShell: Remove-WindowsFeature Wow64-Support
Flexibilidad de la administración con el modo Core La instalación mínima es la opción por defecto desde Windows Server 2012. Windows Server 2012 R2 ofrece la posibilidad de modificar ambas opciones en cualquier momento una vez realizada la instalación. En consecuencia, puede seleccionar, inicialmente, una opción de instalación completa para poder configurar el servidor mediante las herramientas gráficas y, más adelante, pasar a una opción de instalación mínima. La interfaz gráfica ya no está vinculada al modo de instalación, aunque se considera una funcionalidad completa del sistema operativo. Es, también, interesante saber que existe un modo intermedio llamado Servidor con Interfaz básica. Este modo se sitúa entre los dos anteriores por el motivo siguiente: el intérprete gráfico de comandos es, en lo sucesivo, una característica. Si bien la interfaz de administración gráfica habitual (explorador de Windows, barra de herramientas, etc.) se elimina y nos deriva a un modo Core, sí tiene, en cualquier momento, la posibilidad de abrir herramientas de gestión gráfica tales como una consola MMC.
Para cambiar a este modo intermedio puede utilizar el siguiente comando PowerShell: Uninstall-WindowsFeature Server-Gui-Shell -Restart, o bien utilizar la consola Administrador del servidor y eliminar la característica ”Interfaz gráfica del servidor”.
1. Paso del modo GUI al modo Core Si la idea de utilizar una línea de comandos para instalar las funcionalidades de Windows no le agrada, o simplemente por sus aspectos prácticos prefiere instalar inicialmente su servidor en modo gráfico, configurar los distintos servicios de rol y, a continuación, pasar a un modo de servidor mínimo para dotarlo de seguridad, puede pasar del modo GUI al modo Core ejecutando el siguiente comando desde una línea de comandos Windows PowerShell con privilegios de administrador: Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -Restart
Esta misma operación puede realizarse desde la consola Administrador del servidor: Haga clic en Administrar - Eliminar roles o características. Haga clic en Siguiente. Seleccione su servidor y, a continuación, haga clic en Siguiente. En la etapa Roles del servidor haga clic en Siguiente. En la lista de características, desmarque Infraestructura e interfaces de usuario.
En el cuadro de diálogo, haga clic en Quitar características. Haga clic en Siguiente. Haga clic en Eliminar para confirmar su elección. Una vez realizada la modificación, haga clic en Cerrar. Reinicie su servidor para que se tengan en cuenta los cambios.
2. Paso del modo Core al modo GUI En ciertas situaciones, puede necesitar utilizar las interfaces de usuario gráficas que están disponibles en los servidores en modo gráfico. Puede pasar de un servidor en instalación mínima a un servidor en modo gráfico realizando las siguientes etapas (debe reiniciar el equipo). Para pasar de un servidor en modo de instalación mínima al modo gráfico cuando el servidor se ha instalado, originalmente, en modo de instalación mínima, los archivos binarios correspondientes a la funcionalidad de consola gráfica no están presentes. Puede utilizar los archivos fuentes de instalación para realizar este cambio. Es necesario, para esta operación, crear un punto de montaje siguiendo los pasos que se describen a continuación: Cree una carpeta de montaje mediante el comando: mkdir MountDir
Introduzca el DVD de instalación de Windows Server 2012 (x: se corresponde con su lector de DVD). Las opciones de instalación (mínima, gráfica, Datacenter, Standard) poseen un índice asociado. Determine el índice asociado a una imagen de servidor en modo gráfico (por ejemplo, SERVERDATACENTER, y no SERVERDATACENTERCORE) gracias al comando. Get-WindowsImage -ImagePath x:\sources\install.wim
Anote el número de índice correspondiente a esta versión (4 en este ejemplo). Ejecute: Dism /mount-wim /WimFile:X:\sources\install.wim /Index:4 /MountDir: c:\mountdir /readonly
Ejecute: Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell
-Restart -Source
c:\mountdir\windows\winsxs
O, si prefiere utilizar Windows Update como origen, en lugar del archivo WIM, ejecute el siguiente comando Windows PowerShell: Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Restart
Una vez terminadas las tareas de administración, puede volver al modo de instalación mínima si lo necesita (debe reiniciar el equipo) utilizando el siguiente comando Windows PowerShell: Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -restart
3. Uso de funcionalidades bajo demanda En las versiones anteriores de Windows, cuando un rol o una característica del servidor no estaba habilitado, los archivos binarios correspondientes se conservaban en disco, lo cual consumía un espacio de disco innecesario. En Windows Server 2012 R2, cuando deshabilita un rol o una característica, tiene la posibilidad de eliminar completamente los archivos correspondientes, lo que se corresponde con el estado "eliminado" (removed) en el Administrador del servidor o "deshabilitado con eliminación de la carga" en Dism.exe.
•
Para eliminar completamente un rol o una característica, ejecute, en Windows PowerShell, el cmdlet Uninstall-WindowsFeature con el parámetro -Remove. Por ejemplo, para eliminar completamente el Explorador de Windows, Internet Explorer y los componentes relacionados, ejecute el siguiente comando Windows PowerShell:
Uninstall-WindowsFeature Server-Gui-Shell -remove
Para reinstalar un rol o una característica que haya sido completamente eliminado, debe utilizar los archivos fuente de instalación. •
• •
Para instalar un rol o una característica habiéndolo eliminado completamente, utilice el comando Install-WindowsFeature con el parámetro -Source. La opción Source define una ruta de acceso a una imagen WIM y el número de índice de la imagen. Si no indica la opción-Source, Windows utiliza Windows Update por defecto. Para instalar un rol o una característica que se ha eliminado mediante una imagen WIM, utilice el procedimiento y los comandos Windows PowerShell siguientes: Get-WindowsImage -imagepath \install.wim
y, a continuación, indique el índice de la imagen de instalación en modo gráfico de Windows Server 2012. Install-WindowsFeature -Source wim::<índice>
donde: o o o
nombre_característica se corresponde con el nombre del rol o de la característica objeto de Get-WindowsFeature. ruta es la ruta de acceso al punto de montaje WIM. índice es el índice de la imagen de servidor que figura en la etapa en que ha utilizado el comando Get-WindowsImage.
Por ejemplo, si la imagen de instalación en modo gráfico se encuentra en D:\sources: Install-WindowsFeature -Source wim:d:\sources\ install.wim:4 •
Puede, a su vez, especificar una fuente para los servidores que son miembros del dominio mediante una directiva de grupo. Acceda a Configuración del equipo Plantillas administrativas - Sistema - Especificar parámetros para desinstalar componentes opcionales y reparar componentes.
4. Novedades aportadas a PowerShell Ya lo conoce, a menos que no utilice las herramientas de gestión remota del servidor (RSAT: Remote Server Administration Tools), pero puede utilizar PowerShell para administrar su servidor de manera local. Windows PowerShell 4.0 se incluye con Windows Server 2012 R2 y aporta un gran número de funcionalidades que extienden su uso, mejorando su experiencia y permitiendo gestionar de forma mucho más sencilla y eficaz los entornos Windows. Entre las novedades, encontrará: •
•
Windows PowerShell Desired State Configuration (DSC): se trata de un nuevo sistema de gestión que permite desplegar y gestionar las configuraciones que se aplican a los entornos. Por ejemplo, DSC permite instalar o eliminar roles y características en los servidores, gestionar bases de registro, archivos y carpetas e incluso grupos y usuarios locales. Encontrará más detalles acerca de sus características y cómo crear una configuración en el blog technet siguiente: http://blogs.technet.com/b/privatecloud/archive/2013/08/30/introducing-powershelldesired-state-configuration-dsc.aspx La directiva por defecto para ejecutar scripts está, ahora, fijada como RemoteSigned (antes el valor por defecto era Restricted, impidiendo así la ejecución de scripts no firmados).
•
Se han aportado mejoras, también, a PowerShell Web Access, PowerShell Web Services, PowerShell Workflow y PowerShell ISE. Encontrará la descripción del conjunto de actualizaciones en la siguiente dirección: http://technet.microsoft.com/en-us/library/hh857339.aspx
Conclusión Gracias a todas las etapas de configuración seguidas anteriormente, usted dispone, ahora, de un servidor Core completamente funcional en su entorno. Se han presentado algunos de sus uso principales, y otros, como Hyper-V, se han descrito en el capítulo Consolidar sus servidores. La opción de instalación mínima requiere menos espacio en disco, disminuye la superficie expuesta a los atacantes y facilita considerablemente las operaciones de mantenimiento y de reinicio del servidor. Por todos estos motivos, se recomienda escoger una instalación mínima siempre que no necesite utilizar los elementos de la interfaz de usuarios y las herramientas de administración gráfica suplementarias en la opción Servidor con una GUI y si los roles y/o características que faltan en esta versión no le son imprescindibles. Esta edición se ha visto reforzada con, por ejemplo, la posibilidad de instalar SQL 2012 sobre un servidor Core: http://msdn.microsoft.com/en-us/library/hh231669.aspx Las ventajas de esta instalación mínima son reales, y la principal dificultad consiste en acostumbrarse a su administración cotidiana. ¿Supone el Server Core el final de la división entre la interfaz Windows y el shell de Unix?
Introducción Este capítulo está dedicado a la solución de virtualización de Microsoft, Hyper-V. A diferencia de los productos anteriores de Microsoft sobre la materia, como Virtual Server, la virtualización se ha pensado desde el diseño de un sistema operativo. Este verdadero hipervisor está disponible de forma gratuita (sin compra de licencia Windows Server 2012 R2) con el nombre Microsoft Hyper-V Server 2012 R2 y puede descargarse del sitio de Microsoft (http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx). En este capítulo, descubrirá cómo rentabilizar la infraestructura existente y volverla más flexible de cara a los cambios.
¿Por qué consolidar? La virtualización está cada vez más extendida en las empresas. Aun así, no debería implementarse como algo sistemático. Antes de iniciar un proyecto de virtualización, debería medir bien todas las consecuencias, así como las potenciales ventajas. Como ocurre
con muchas otras cosas, se recomienda pensar a lo grande pero comenzar dando pequeños pasos.
1. Virtual frente a Físico En un primer enfoque, virtualizar permite superar ciertas restricciones relativas al hardware, permitiendo obtener un mejor rendimiento. El enfoque de uso de servidores físicos es más sencillo para comenzar, aunque se complica con el número de servidores. Además del mantenimiento de los sistemas operativos y sus aplicaciones es necesario gestionar el ciclo de vida del material: • • •
Fallos de hardware. Actualizaciones de la BIOS, firmwares, controladores. Ciclos de amortización.
En efecto, las soluciones a estos problemas son conocidas y pueden gestionarse sin problemas en base a la metodología de trabajo actual. No obstante, siempre existe el riesgo de que aparezca un nuevo modelo de servidor que reemplace al anterior para el que su imagen de instalación de Windows no contenga el controlador adecuado. La virtualización le proporciona los medios para enmascarar esta administración y así poder dedicarse plenamente a tareas de mayor valor añadido. a. Optimización de los costes
Uno de los objetivos de la virtualización es la reducción de costes en infraestructura. Para ello, uno de los grandes ejes es la optimización de los recursos disponibles. La capacidad de los servidores sigue creciendo de forma exponencial, aunque las necesidades de las aplicaciones no siempre siguen la misma progresión. Incluso el servidor más barato disponible en los fabricantes de hardware tiene como mínimo un procesador con dos o cuatro núcleos, algunos gigabytes de memoria RAM y almacenamiento SAS acorde. Si algún servidor alberga una o incluso varias aplicaciones, seguramente no utilizará más que un modesto porcentaje de los recursos. La mayoría de fabricantes de software siguen, por otro lado, solicitando un servidor dedicado para asegurar el soporte para sus programas. Como resultado se tienen salas de servidores con muchos equipos, aunque ninguno de ellos esté utilizado por encima del 10% de su capacidad. La virtualización permite mantener una división lógica, en un sistema operativo dedicado, consolidando la infraestructura de hardware. Esta consolidación física ya tiene un impacto importante sobre los costes: • •
Reducción del conjunto de los costes vinculados con la sala de servidores: eléctrico, climatización, cableado, alquiler del suelo... Reducción de costes de mantenimiento, proporcional al número de servidores físicos que se ahorren.
La virtualización también reduce los costes ligados a la inclusión de un nodo en la infraestructura. La generación de una máquina virtual no supone ningún coste de cableado informático, de puesta en rack... Este ahorro cobra todo el sentido en un entorno donde el
número de peticiones sea importante, como por ejemplo en entornos de desarrollo o de pruebas. La solución SCVMM (System Center Virtual Machine Manager) permite incluso implementar un portal de autoservicio para la creación de máquinas virtuales a la carta. Un uso menos convencional consiste en utilizar la virtualización para mantener en funcionamiento los sistemas obsoletos, donde el material ya no esté en mantenimiento o pueda mantenerse. La mayoría de Sistemas de Información poseen algunos equipos obsoletos, con aplicaciones para las que ya no existe documentación ni fuentes. Migrarlas a máquinas virtuales permite mantenerlas en el Sistema de Información evitando problemas de hardware. b. Límites de la virtualización
No todos los equipos son buenos candidatos para la virtualización. La solución Hyper-V no soporta, por ejemplo, el conjunto de sistemas operativos Microsoft. En el momento de escribir este libro, se soportan las versiones siguientes: Tipo servidor: • • • • • • • • • • • •
Windows Server 2012 R2, Windows Server 2012. Windows Server 2008 (en 32 y 64 bits) SP2, 2008 R2 SP1. Windows 2003 SP2, 2003 R2 SP2 en 32 y 64 bits. Windows Home Server 2011, Windows Small Business 2011. CentOS 5.7 a 6.4. Red Hat Enterprise Linux 5.7 a 6.4. SUSE Linux Enterprise Server 11 SP 2 y SP3, en 32 y 64 bits. OpenSUSE 12.1. Ubuntu Server 12.04 LTS, 12.10, 13.04 y 13.10. Debian 7.0 FreeBSD 8.2, 8.3 et 9.0. Oracle Linux 6.4 (solo un kernel compatible con Red Hat).
Tipo cliente: • • • • • • •
Windows 7, Windows 8 y Windows 8.1 en 32 y 64 bits. Windows XP SP3, XP x64 SP2, Vista SP2. CentOS 5.7 a 6.4. Red Hat Enterprise Linux 5.7 a 6.4. OpenSUSE 12.1. Ubuntu 12.04, 12.10, 13.04 y 13.10. Oracle Linux 6.4 (solo con un kernel compatible con Red Hat).
Como cualquier sistema operativo instalado sobre un servidor físico, donde es necesario instalar controladores para reconocer el hardware, los sistemas operativos instalados en las máquinas virtuales necesitan, a su vez, controladores que les permitan reconocer el
hardware. Todo hipervisor posee controladores virtuales. Con Microsoft Hyper-V se llaman Servicios de integración. En VMware ESX, son las VMware Tools. Salvo para Windows Server 2012 R2 y Windows 8.1, todos los demás sistemas operativos necesitan que se instalen (o actualicen) los servicios de integración. Para sistemas operativos como SUSE Linux, OpenSUSE, Ubuntu y Oracle Linux, no se requieren estos servicios puesto que ya están integrados en estos sistemas, como con Windows Server 2012 R2 y Windows 8.1. Para CentOS (distinto a 5.9 y 6.4) y Red Hat (distinto a 5.9 y 6.4), tendrá que descargar e instalar los servicios de integración 3.4: http://www.microsoft.com/en-us/download/details.aspx?id=34603 Encontrará en el sitio Web Windows Server Catalog la lista de dispositivos y aplicaciones homologados para Hyper-V, en la siguiente dirección: http://www.windowsservercatalog.com/svvp.aspx Incluso aunque no estén oficialmente soportados, algunos otros sistemas operativos funcionan sin problema sobre Hyper-V, tales como MS-DOS, Windows NT4, Windows 2000 Server, algunas distribuciones de Linux o incluso Sun Solaris 10, por ejemplo. Ciertos elementos de la arquitectura no deben coexistir en la misma infraestructura, a efectos de disponibilidad. Por ejemplo, no deberían existir dos servidores DNS o DHCP en el mismo servidor Hyper-V. En caso contrario, si se produce un fallo en el servidor, ambos servicios quedarán indisponibles al mismo tiempo aunque estén disponibles dos veces en la misma red para prestar alta disponibilidad. Servicios diferentes que tengan una fuerte actividad al mismo tiempo deberían estar situados sobre servidores Hyper-V distintos, con el objetivo de no cargar negativamente la infraestructura virtual. Debería, por tanto, definir reglas de afinidad y anti-afinidad. Por último, las soluciones que necesiten tarjetas hardware especiales (tarjetas digitales, acceso primario…) o las soluciones que utilizan dispositivos físicos son difíciles de migrar a un entorno virtual. Los puertos COM del servidor físico no están accesibles desde las máquinas virtuales, así como el lector de disquetes.
2. Nuevas problemáticas Sería ilusorio pensar que la virtualización sólo aporta ventajas y ningún inconveniente. Como cualquier solución técnica, lo importante es dominarla para sacarle partido. Existen dos cuestiones que precisan una atención particular: los impactos de la consolidación y la copia de seguridad. a. Entorno consolidado
La consolidación es un eje clásico de rentabilización, aunque se vuelve mucho más sensible con la virtualización, pues la lleva al extremo. Parte de la base de que la mayoría de sistemas sólo consumen una parte de los recursos de hardware que están disponibles y los consolidan para rentabilizarlos. Aun así raramente podemos predecir la carga que van a
generar los usuarios sobre el conjunto de sistemas virtuales en un momento dado. Puede ocurrir que varias VM quieran consumir repentinamente lo máximo disponible, perturbando así a las demás VM. El rendimiento puede convertirse rápidamente en un freno a la virtualización si no está administrada correctamente. Lo más típico es que los usuarios experimenten un mal rendimiento, que asocian inmediatamente al hecho de que se trata de una máquina virtual. Se vuelven así reacios a su uso, pensando que es la única causa de este mal rendimiento. Este tipo de problema puede aparecer incluso de forma insidiosa con el tiempo. Esta lentitud en el uso también aparece cuando, al contrario, el resultado es bueno y el éxito de la solución incita a instalar todavía más máquinas virtuales de las que el dimensionamiento de la infraestructura prevé. Todo proyecto de virtualización debería tener un plan de capacidad, actualizado permanentemente. Si el sistema que se quiere virtualizar ya está en uso, obtenga un registro previo del uso de los recursos. Esto permitirá predecir su impacto en la infraestructura Hyper-V así como los recursos necesarios. Hyper-V permite limitar el consumo de cada máquina virtual, con el objetivo de garantizar una cantidad de recursos en cada instante. La reserva de recursos tiene el inconveniente de bloquearlos, incluso si la máquina virtual no se utiliza. El límite permite restringir una máquina virtual que no sea crítica, como una máquina de pruebas, o una máquina que consuma todos los recursos disponibles, como un servidor de procesamientos masivos. También puede asignar un peso a cada máquina virtual, permitiendo así priorizar el acceso a los recursos disponibles que no están reservados. Si por ejemplo dos máquinas virtuales piden más recursos de procesador al mismo tiempo, la que tiene un peso mayor será prioritaria. Puede asignar de 1 a 64 procesadores virtuales a cada máquina virtual (dependiendo del sistema operativo hospedado), siempre que disponga de los núcleos físicos correspondientes. En un servidor físico de cuatro núcleos, cada VM puede tener como máximo cuatro procesadores lógicos. Los servidores actuales tienen por lo general al menos dos o cuatro núcleos, lo cual resulta muy rentable en términos de virtualización. Si asigna a cada VM dos procesadores lógicos, esto permite mantener un tiempo de respuesta correcto en una VM, incluso si un procesador lógico está consumido por completo por un programa o un proceso. Si sólo asigna un procesador lógico y un thread consume todos los ciclos en bucle, le será complicado incluso acceder al sistema para parar este proceso. Este fenómeno también es cierto sobre una máquina física con un único núcleo, pero la virtualización acentúa este efecto que no está presente en la mente de los usuarios que tienen por lo general dos núcleos en sus equipos (Hyper Threading o dual core). La pérdida de un servidor físico Hyper-V tiene consecuencias mucho más graves que si se trata de un servidor sin virtualización. En efecto, este tipo de servidores alberga potencialmente varias VM (¿una decena, quizás?), y quedarán todas ellas indisponibles al mismo tiempo. Es preciso prepararse para este escenario, para poder tomar las decisiones correctas, como el orden en el que se va a volver a poner en servicio estas VM. Se recomienda desplegar al menos dos servidores Hyper-V, con el objetivo de tener un plan de recuperación rápido en caso de que ocurra un fallo grave en uno de los dos servidores.
b. Copia de seguridad
La copia de seguridad de una infraestructura virtual es una cuestión que merece una atención particular. Existen varias implementaciones posibles, y debería encontrar la que le aporte mayor flexibilidad, limitando las restricciones y los costes asociados. Su objetivo debería ser poder responder a sus necesidades de una forma lo más adaptada posible al contexto, respetando los compromisos de servicio con sus clientes. Existen tres grandes ejes de copia de seguridad: • • •
Considerar las máquinas virtuales como si se tratara de servidores estándar, instalando el agente de copia de seguridad tradicional en cada máquina virtual.. Implementar una copia de seguridad utilizando las posibilidades ofrecidas por la infraestructura virtual. Realizar una copia de seguridad de los discos virtuales de las VM en frío, es decir con las VM paradas.
La primera solución tiene la ventaja de ser muy clásica, aunque también es seguramente la más costosa, pues no aporta ningún ahorro ligado a la virtualización. Ciertos fabricantes de software de copia de seguridad proporcionan no obstante un precio por agente inferior cuando se trata de máquinas virtuales. Nos ceñiremos a las soluciones de copia de seguridad que tengan en cuenta las funcionalidades ofrecidas por la virtualización. Una máquina virtual puede tener varios estados: • • •
Encendida o Apagada. En pausa. Con uno o varios puntos de control (antes llamados "instantáneas").
Los puntos de control (antes llamados "instantáneas") permiten tomar una "foto" de la VM en un momento dado. Para ello, Hyper-V crea un nuevo disco virtual (*.avhd) que contendrá todas las diferencias generadas tras este punto de control. Esto no constituye en sí mismo un mecanismo de copia de seguridad. El archivo maestro es indispensable para su funcionamiento, y no puede estar fuera de la VM. Esta funcionalidad no está disponible para los discos físicos ligados directamente a la VM (pass-through). Para ciertos roles, como el controlador de dominio, esta funcionalidad no está soportada por Microsoft. En cambio, esta funcionalidad es un verdadero "must" para realizar el mantenimiento, pues permite instalar una nueva aplicación o las actualizaciones del sistema y poder hacer la marcha atrás si algo no funciona. Si todo funciona correctamente, sólo tendrá que eliminar el punto de control, que se fusionará automáticamente con el archivo .VHD o .VHDX de su máquina virtual. El número máximo de puntos de control es de 50 por máquina virtual. Las copias de seguridad en frío son la solución más sencilla, aunque implican un periodo de parada que no siempre es posible. Un reinicio del sistema operativo puede generar pérdidas de rendimiento si se utiliza una caché en memoria (SQL Server...).
Es posible que su solución de copia de seguridad proporcione un agente para Hyper-V. Este mecanismo utiliza la tecnología VSS (Volume Shadowcopy Service). De este modo obtendrá copias autónomas de las máquinas virtuales, que podrá copiar y conservar en una cinta magnética. La solución de copia de seguridad Microsoft SCDPM (System Center Data Protection Manager) así como la solución de copia de seguridad nativa de Windows Server 20012 R2 son compatibles con este tipo de copia de seguridad. Para que este tipo de solución funcione, es necesario cumplir ciertos requisitos previos: • • •
Las herramientas Servicios de sistemas invitados virtuales deben estar instaladas, y el servicio Backup integration debe estar activo. Todos los volúmenes utilizados por la VM deben estar en modo básico y con formato NTFS. El servicio Windows VSS debe estar habilitado en todos los volúmenes y cada volumen debe disponer de su propio almacenamiento VSS.
Si no puede realizarse una copia de seguridad en línea, entonces se realizará una copia de seguridad en frío del equipo. Para ello, su estado será en copia y, una vez terminada la copia de seguridad, la VM se situará en el estado inmediatamente anterior a la copia de seguridad. Este tipo de copia de seguridad permite restaurar por completo una máquina virtual, aunque no parte de la misma (como por ejemplo un archivo del disco C:\ en este equipo). No es apropiado ejecutar una copia de seguridad o su restauración a la vez sobre una máquina virtual y sobre la partición raíz. Puede generar conflictos si cada instancia intenta bloquear el registro VSS. He aquí un comando útil para realizar la copia de seguridad integral de un servidor HyperV así como el conjunto de sus máquinas virtuales en caliente: wbadmin start backup -backuptarget:\\ otroservidor\compartidos\copiasdeseguridad -include:c:,d: -allcritical -vssfull -quiet
3. Preparar el despliegue a. Requisitos previos
Para poder tener el rol Hyper-V, un servidor físico debe tener las funcionalidades de virtualización (Intel-VT o AMD-V), funcionalidades de prevención de ejecución de datos (DEP) y de seguridad (Intel XD o AMD NX), todas ellas habilitadas. Esto como complemento a las instrucciones de 64 bits, imprescindibles en Windows Server 2012 R2 y para Hyper-V en términos generales. Hyper-V soporta hasta 320 procesadores sobre el servidor físico (y no 16 como era el caso con Windows Server 2008), que provengan de núcleos físicos o lógicos gracias a la tecnología Hyper Threading. Windows Server 2012 R2 también es capaz de sacar partido de las funcionalidades de parada de núcleo (Core Parking) y de un segundo nivel de traducción, Extended Page Tables (EPT) para Intel, Nested Page Tables (NPT) para AMD. El primero permite reducir
el consumo eléctrico parando los núcleos que no estén utilizándose. El segundo permite ahorrar en torno al 2% del tiempo de procesador y 1 MB por máquina virtual. Se recomienda realizar una instalación mínima (Core). El capítulo Reducir la superficie de ataque de este libro cubre este tipo de instalación. Windows Server 2012 R2, edición Estándar y Datacenter, así como Hyper-V Server 2012 R2 permiten utilizar como máximo 4 TB de memoria en el servidor host, es decir el servidor físico (también llamada partición raíz) y hasta 1 TB de memoria en cada máquina virtual. El tamaño máximo para un disco duro virtual depende de su tipo, y será de 2040 GB para un disco .VHD (antes esta limitación era de 127 GB para Windows Server 2012) y de 64 TB para un disco .VHDX, formato de disco duro virtual aparecido con Windows Server 2012. Se recomienda disponer de al menos dos tarjetas de red físicas en el host físico (véase más adelante la sección Respetar las buenas prácticas). Cada máquina virtual de primera generación puede tener hasta 12 tarjetas de red virtuales (8 reales (tarjetas de red virtuales que requieren la instalación de servicios de integración) + 4 emuladas), hasta 8 tarjetas de red virtuales para máquinas de segunda generación (pues las tarjetas de red heredadas no están soportadas), cada una con una dirección MAC estática o dinámica. Para las máquinas de primera generación, las tarjetas de red reales están disponibles una vez instalados los servicios de invitado virtual y los controladores adecuados. Esto significa que no pueden hacer boot en la red. Las tarjetas de red emuladas tienen peores rendimientos, 100 Mb/s frente a 10 Gb/s para las tarjetas reales. Utilizan un controlador estándar que no necesita controladores Hyper-V, aunque permiten el boot PXE. Esto acentúa la importancia de instalar únicamente sistemas operativos soportados por Hyper-V para tener una red virtual con un buen rendimiento. La tecnología VLAN está soportada por las tarjetas de red virtuales. Un lector de DVD virtual puede utilizar imágenes ISO o el lector físico del servidor en el caso de una máquina virtual de primera generación. Sin embargo, sólo una máquina virtual puede acceder al lector físico al mismo tiempo. Se recomienda convertir los CD y DVD necesarios en imágenes ISO. Además, el uso de imágenes ISO mejora el rendimiento de uso; en efecto, las imágenes ISO, que se almacenan en el disco duro, aprovechan una tasa de transferencia de lectura superior. Una máquina virtual de segunda generación utiliza, exclusivamente, imágenes ISO. b. Metodología de trabajo
La metodología es un aspecto fundamental en un proyecto de virtualización. Ciertas cuestiones, tales como la copia de seguridad, deben tratarse cuidadosamente antes del paso a producción. Es posible aplicar las fases clásicas de un proyecto de infraestructura con algunas especificidades:
• • • • • • • • • •
• •
• • • •
Determinar el alcance (entornos, sistemas operativos...). Comenzar la búsqueda de los mejores candidatos para la virtualización implementando herramientas de medida (véase la sección siguiente). Determinar el nivel de servicio que se desea proporcionar en el perímetro (SLA). Montar una maqueta/POC (Proof Of Concept). Utilizar la infraestructura de almacenamiento presente (interna, SAN, iSCSI, compartición de archivos...). Medir la integración en la arquitectura de red existente (VLAN, filtrado por dirección MAC, protección en los conmutadores). Implementar, al menos, un ejemplo de cada tipo de VM en el alcance (una VM de cada OS y cada aplicación). Asegurar la capacidad para realizar la copia de seguridad y restaurar cada una de las VM. Generar la misma carga que en producción con las mismas restricciones (procesamientos, ventanas de copia de seguridad...). Implementar una solución de supervisión teniendo en cuenta la virtualización (medir el uso de los procesadores disponibles en Hyper-V así como el consumo por VM...). Evaluar el interés de SCVMM en su contexto de trabajo. Medir el impacto en la gestión de las actualizaciones de Windows (uso de Offline Virtual Machine Servicing Tool como se explica en la sección Configurar el almacenamiento). Medir el impacto en los procedimientos de explotación (procedimientos de parada/arranque...). Evaluar el impacto en el coste. Implementar un piloto, que supondrá la puesta en producción de una muestra del perímetro, para verificar las hipótesis. Extender el piloto al conjunto de manera progresiva.
La prueba de concepto es decisiva, pues permite evaluar las nuevas funcionalidades, en ocasiones importantes, de esta versión y verificar que la arquitectura actual soportará la carga. Menospreciar esta fase conlleva el riesgo de fracasar una vez en producción. La duración de esta fase debería permitir evaluar los impactos de la virtualización, así como las optimizaciones que es necesario realizar, bien en Hyper-V, en las máquinas virtuales o en los demás bloques del sistema de información. Con la prueba de concepto, todos los participantes podrán tener una visión clara de las ventajas y los inconvenientes de la virtualización para poder hacer una evaluación completa. El piloto debe confirmar sin reservas esta evaluación antes de generalizar el despliegue.
c. Determinar los servidores y las aplicaciones adecuados para la virtualización
Microsoft proporciona de forma gratuita una herramienta que le permite preparar y acelerar su proyecto de virtualización: Microsoft Assessment and Planning Toolkit. Está disponible para su descarga en la siguiente dirección: http://www.microsoft.com/enus/download/details.aspx?id=7826 De este modo podrá, fácilmente: • • •
Realizar un inventario de los servidores. Recoger datos sobre el consumo de recursos sobre estos servidores. Generar informes Office con recomendaciones basadas en los datos recogidos.
Debe instalarse preferentemente en un puesto de trabajo, pues necesita Microsoft Office (2003 o 2007), y una instancia de SQL Server o SQL Express (2008, 2008 R2 o 2012). La instalación de esta última puede evitarse si ya está presente, creando preferentemente una instancia llamada "MAPS".
Una vez instalada la aplicación, deberá: • •
Crear una base de datos para el proyecto haciendo clic en Select a database. Crear manualmente un archivo de texto que contenga la lista de los servidores que quiera examinar para su proyecto de virtualización (candidatos potenciales). Por ejemplo, el siguiente script PowerShell exporta el nombre DNS de todos los servidores de Active Directory en el archivo miextraccion.txt:
$buscar = New-Object DirectoryServices.DirectorySearcher("[ADSI]") $buscar.SizeLimit = 10000 $buscar.PropertiesToLoad.Add("dNSHostName") $buscar.Filter = "(&(objectClass=Computer)(operatingSystem=*Serve*r*))" $buscar.FindAll() | foreach-object {$objet=$_.GetDirectoryEntry();$objet.dNSHostName;} >> miextraccion.txt
En el panel de navegación, haga clic en Server Virtualization y, a continuación, haga clic en Collect performance data. Indique el archivo de texto creado anteriormente. Especifique una o varias cuentas con permisos de administrador local sobre los servidores de destino. Indique una fecha de fin para la recogida de datos. La estación que realiza la recogida de datos debe permanecer encendida todo el tiempo de la colecta.
A continuación, puede generar los informes. d. Respetar las buenas prácticas
He aquí algunas reglas consideradas como buenas prácticas que deberían respetarse por defecto, salvo en casos muy concretos. De forma general, en Hyper-V: •
Prevea al menos dos tarjetas de red físicas sobre el servidor, aunque lo conveniente es:
• • • •
una para la administración del hipervisor, una o varias dedicadas a las máquinas virtuales, una o varias para el iSCSI, si lo implementa, una para las migraciones rápidas (live migration), si las implementa.
•
Conecte la tarjeta de red dedicada a la gestión del hipervisor a su red de administración. Exponga únicamente las máquinas virtuales a la red Internet. Incluya una excepción en el antivirus para los archivos *.vhdx, *.avhdx, *.vhd y *.avhd. El lector de DVD no puede estar compartido por varias máquinas virtuales. Dé prioridad a las imágenes ISO en su lugar.
• • •
De manera general, sobre las máquinas virtuales: • • • •
• • •
•
Instale, siempre que sea posible, las herramientas de administración Servicios de sistemas invitados virtuales. Deshabilite el salvapantallas. Defragmente siempre el disco físico antes de crear un disco duro virtual. Si migra las máquinas virtuales utilizando otras soluciones de virtualización, como Virtual PC, Virtual Server, VMware, desinstale las VMadditions o las VMware Tools. Elimine los puntos de control y comprima el disco duro virtual antes de desplazarlo al Hyper-V. Asegúrese de que la visualización está optimizada para un buen rendimiento, y así aprovechar la aceleración de hardware. Utilice, preferentemente, el nuevo formato de disco virtual de tipo *.vhdx de tamaño dinámico. El rendimiento es superior al de los discos *.vhd de tamaño fijo. Si utiliza discos dinámicos *.vhd, conviértalos en discos virtuales de tamaño fijo, el sistema estará menos fragmentado, la gestión del espacio será mucho más sencilla y el rendimiento mejor respecto a los discos de tamaño dinámico. Cree discos virtuales de tamaño fijo. El rendimiento es superior, el sistema de archivos estará menos fragmentado, y la administración del espacio será más sencilla.
• •
Si crea una VM Windows Server 2003, asígnele dos procesadores virtuales para tener un HAL multiprocesador. Utilice, en la medida de lo posible, controladores reales una vez instalados los servicios de sistemas invitados virtuales, para mejorar el rendimiento.
Puede instalar un controlador de dominio Active Directory en el interior de una máquina virtual Hyper-V. No obstante, se recomienda observar las siguientes reglas: •
•
•
Las buenas prácticas de Active Directory indican que es necesario disponer, como mínimo, de dos controladores de dominio. Ambos controladores deberían residir en hosts distintos. Seleccione cómo sincronizar el tiempo. Es crucial que el conjunto del dominio utilice la misma hora. Por defecto, Kerberos no soporta un desfase superior a los 5 minutos. Puede o bien sincronizarlos en base al reloj del hardware del servidor a través de los servicios de sistemas invitados virtuales, o bien sincronizarlos a través de la red del dominio. Si su único controlador de dominio es una máquina virtual en Hyper-V, la partición raíz (hipervisor) no debe unirse a este dominio. Cuando reinicie el servidor, la partición raíz buscará un controlador de dominio que no podrá encontrar pues la máquina no estará todavía levantada.
Windows Server 2012 R2 conserva la funcionalidad que permite clonar controladores de dominio virtualizados, introducida con Hyper-V 3 para Windows Server 2012. Esta funcionalidad se explica con detalle en el capítulo Dominio Active Directory. Puede implementar SQL Server en una máquina virtual. El almacenamiento es un elemento crítico en una base de datos, y la virtualización no cambia nada. El almacenamiento sobre el que residirán los datos y los registros debe proporcionar un rendimiento adecuado. Para no disminuir este rendimiento con la virtualización, debería utilizar únicamente discos virtuales de tamaño fijo, utilizando un controlador SCSI virtual. La otra alternativa es utilizar volúmenes directamente en modo pass-through. Puede implementar Exchange Server 2010 o Exchange Server 2013 en una máquina virtual. En este caso, debe observar las siguientes recomendaciones: • • •
Para que la configuración esté soportada por Microsoft, instale el Service Pack 1 para Exchange 2010, Exchange 2013 RTM o superior. El uso de discos virtuales de tamaño dinámico está soportado únicamente con VHDX, aunque se recomienda utilizar discos virtuales de tamaño fijo. El uso de funciones de puntos de control y diferenciales sobre los discos virtuales no está soportado.
En lo relativo a la seguridad, jamás debería proporcionar permisos sobre la partición raíz a los administradores de las máquinas virtuales. Para respetar el célebre principio de otorgar siempre el menor nivel de privilegios posible, debería darles acceso a lo estrictamente necesario. Administrar esta seguridad puede convertirse en una tarea compleja, para la que también puede utilizar la noción de roles para clasificar los accesos.
Desplegar Hyper-V 1. Instalación a. Instalación del rol Hyper-V
La instalación es tan sencilla como agregar el rol en el servidor mediante el Administrador del servidor, a partir de su interfaz gráfica. Si está trabajando con una instalación Core, ejecute el siguiente comando PowerShell: Install-WindowsFeature Hyper-V
Será necesario reiniciar para que se apliquen los cambios y poder utilizar este rol. b. Configuración del rol
La configuración del rol cubre diferentes aspectos: • •
creación y configuración de las redes virtuales; preparación de las imágenes ISO para las distintas instalaciones.
La consola permite administrar los servidores Hyper-V así como las máquinas virtuales que las albergan. Abra la consola Administrador de Hyper-V disponible en la pantalla de inicio de Windows, Herramientas administrativas y, a continuación, Administrador de Hyper-V.
c. Configuración de las redes virtuales
En Hyper-V, la administración de las redes se realiza mediante el Administrador de HyperV o mediante PowerShell. Existen tres tipos de redes, también llamadas switchs virtuales: •
•
•
El switch virtual externo: vinculado con una tarjeta de red real sobre el host, este tipo de switch virtual permite a las VM conectadas a él acceder a la red externa y, por lo tanto, dialogar con el exterior. Es posible crear y asociar una tarjeta de red virtual con un host vinculado a este tipo de switch virtual. El switch virtual interno: este tipo de switch virtual permite realizar una comunicación entre las VM vinculadas a este switch, así como al host que posee, automáticamente, una tarjeta de red virtual sobre este mismo switch. El switch virtual privado: las VM conectadas a este switch sólo pueden comunicarse entre ellas.
Windows Server 2012 R2 soporta las tecnologías de red siguientes: •
La tecnología PVLAN (Private Virtual Local Area Network), que permite aislar las máquinas virtuales sobre una misma red local privada virtual aunque se hospeden en hosts diferentes. Resulta muy práctica para servidores hospedados en Datacenters.
•
•
•
•
•
•
•
La tecnología SR-IOV, que permite a la tarjeta de red enviar directamente los paquetes de red en el espacio de memoria de la VM, sin pasar por la partición raíz. Es necesario que la tarjeta de red del servidor físico gestione esta funcionalidad y es posible que haga falta instalar controladores suplementarios en la máquina virtual. Observe que el soporte de SR-IOV para el switch virtual se define durante la creación de dicho switch virtual, no será posible modificar este parámetro tras una ruptura (salvo creando otro switch virtual). El NIC Teaming, o agregación de varias tarjetas de red, que se gestiona de forma nativa en los sistemas operativos. Un switch virtual puede vincularse a un equipo para aumentar las tasa de transferencia y la tolerancia a fallos. Los switchs virtuales extensibles (Extensible vSwitch), que permiten agregar extensiones al switch virtual. Algunos fabricantes de switch ya han anunciado extensiones que permitirán soportar su tecnología en los switchs virtuales. Las tarjetas de red inalámbricas están soportadas, y es posible vincularlas con un switch virtual externo. Resultan muy útiles en la versión de Hyper-V para Windows 8/8.1. La tecnología Jumbo Frames para las máquinas virtuales. Esta tecnología permite aumentar la MTU (Maximum Transmission Unit) de 1500 (Ethernet) a 9014. La misma cantidad de datos puede, de este modo, transmitirse con seis veces menos intercambios de paquetes. Esto implica que todos los equipos de red soporten las Jumbo Frames. La tecnología VMQ (Virtual Machine Queue), que permite a la tarjeta de red alojar, en su propia memoria interna, un espacio dedicado a cada VM. Los datos se envían, a continuación, directamente sobre el puerto conectado al VMBus del switch virtual que permiten alcanzar la VM. Una especie de pre-enrutamiento interno en la tarjeta de red. Esto evita, también, tener que verificar el enrutamiento en los switch virtuales mediante los VMQ Queue ID. El objetivo es una mejora en el rendimiento reduciendo el número de operaciones en las comunicaciones de red. Es necesario, no obstante, que la tarjeta de red del host gestione esta funcionalidad. El TCP Offload permite descargar la gestión del tráfico TCP/IP de las máquinas virtuales sobre una tarjeta física del servidor. Esta descarga aumenta el rendimiento y reduce el consumo de procesador del servidor físico. La migración en caliente de VM puede aprovechar esta funcionalidad.
d. Configuración del almacenamiento
Con la virtualización, el almacenamiento es el centro de la cuestión. Esto es todavía más cierto si los servicios ofrecidos por las máquinas virtuales consumen muchos recursos de entrada/salida de disco. Para poder reducir costes, es interesante utilizar almacenamiento "low cost", aunque existe el riesgo de sufrir un mal rendimiento en las máquinas virtuales. Será preciso encontrar el justo equilibrio entre una solución SAN y una carpeta compartida de red. Hyper-V soporta una gran variedad de soluciones para el almacenamiento de las máquinas virtuales:
• • • • •
Almacenamiento local del servidor (IDE/SATA/ESATA/USB/Firewire/SAS/SCSI). Almacenamiento en una SAN (con almacenamiento en clúster en modo Cluster Shared Volumes). Almacenamiento mediante iSCSI o FCoE. Almacenamiento sobre una carpeta compartida de archivos. Almacenamiento en modo pass-through.
Puede incluso almacenar las VM en una llave USB, a condición de que tenga formato en NTFS. Por defecto, debería utilizar discos virtuales. Existen no obstante ciertos casos donde debería utilizar un almacenamiento en modo pass-through. Este método proporciona a la VM acceso directo a una zona de almacenamiento, como si fuera una máquina física. Una de las ventajas es que se obtiene un mejor rendimiento, ligado a la ausencia de la capa de virtualización. He aquí algunas consideraciones a propósito del modo pass-through: •
•
Los volúmenes en modo pass-through no se incluyen en la copia de seguridad por los mecanismos de Hyper-V. Necesitará realizar estas copias de seguridad utilizando algún otro medio. El mecanismo de puntos de control no está disponible en este tipo de volumen
Si elige almacenar las VM en una carpeta compartida de archivos o un almacenamiento compartido con formato SMB 3.0, se recomienda configurar este recurso compartido con alta disponibilidad. El almacenamiento mediante ISCSI puede realizarse de dos maneras, desde la partición raíz, o desde la máquina virtual. Esta elección tiene varias consecuencias: •
•
Si al almacenamiento ISCSI se accede desde la partición raíz, el rendimiento es mejor que desde la VM, y la copia de seguridad a través del registro VSS está soportado. Las máquinas virtuales no pueden iniciarse desde un almacenamiento ISCSI (administrado desde las VM en lugar de la partición raíz). El almacenamiento ISCSI que se accede desde las VM no puede incluirse en las copias de seguridad a través de VSS Hyper-V.
Otra decisión que hay que tomar atañe a la naturaleza de los controladores virtuales para las máquinas virtuales. Pueden ser IDE o SCSI. El rendimiento no juega, de momento, un papel importante cuando se instalan los servicios de sistemas invitados virtuales. Las diferencias se centran en la volumetría, el número de discos virtuales asociados a la VM y las funcionalidades propuestas (como el Shared VHDX). El controlador SCSI permite tener hasta 256 dispositivos de almacenamiento (4 controladores * 64 dispositivos). No obstante, permite arrancar únicamente en una máquina virtual de segunda generación. Los volúmenes ligados al controlador IDE pueden ser 4 como máximo (contando el lector CD/DVD virtual), tienen un tamaño máximo de 2040 gigabytes, aunque están disponibles únicamente en una máquina virtual de primera generación.
El almacenamiento sobre una infraestructura SAN es generalmente la solución competente, y también la más costosa. La tecnología NPIV está disponible en las tarjetas HBA, lo que permite respetar las buenas prácticas en lo que respecta al almacenamiento SAN (zoning...). Para ello debería activar las WWN (World Wide Names) virtuales para las máquinas virtuales. He aquí algunas consideraciones para el almacenamiento sobre una SAN: • • • • •
Es necesario tener un controlador MPIO (multipuerto), incluso con una única HBA. Deshabilite el montaje automático de volúmenes. Deje los discos en modo básico y no dinámico. Todos los archivos de VM deben estar en un único volumen. Agregue las LUN como recursos de disco al clúster antes de crear las VM. Windows Server 2012 R2 incluye los Cluster Shared Volumes, que permiten tener varias VM por LUN, teniendo estas VM en hosts diferentes.
Si las VM están almacenadas en modo pass-through sobre la SAN, se necesitan dos LUN, una para el disco de inicio y otra para la configuración.
2. Máquinas virtuales de nueva generación Windows Server 2012 R2 incluye un nuevo formato de máquina virtual, hablamos de máquina virtual de generación 2. Las máquinas virtuales de primera generación siguen estando soportadas, y ambas generaciones de máquina virtual pueden convivir en el mismo servidor host. La generación de la máquina virtual determina el tipo de componentes de hardware y algunas funcionalidades de la máquina virtual. Las máquinas virtuales de generación 2 incluyen un modelo de hardware simplificado, pues cierto número de componentes se han suprimido, como los controladores IDE y los periféricos emulados (disquetera, tarjeta de red heredada). Además, esta nueva generación de máquinas virtuales soporta, también, UEFI (Unified Extensible Firmware Interface) en comparación con el anterior tipo de BIOS. En el momento de escribir estas líneas, sólo Windows Server 2012 / 2012 R2 así como las versiones de 64 bits de Windows 8/8.1 están soportadas como sistema operativo invitado. He aquí una tabla con las diferencias de hardware entre ambas generaciones de máquina virtual. Generación 1
Generación 2
BIOS Tipo
Hyper-V BIOS-Based
Hyper-V UEFI
Arranque sobre
IDE CD, IDE HD, tarjeta de Tarjeta de red, SCSI HD, red heredada y disquetera SCSI CD
Memoria RAM Máximo
1 TB
1 TB
Memoria dinámica
Windows Server 2012/ 2012 Windows Server 2012/ R2, Windows 8/8.1, y algunas 2012 R2, Windows 8/8.1 distribuciones de Linux
Procesador Número máximo Controlador IDE Bootable
64
64
Sí
No
Sí
Número máximo de 2 controladores IDE Número máximo de 2 periféricos por controlador Tipo de soportado
disco VHD, VHDX, Pass-Through
Número máximo de 4 (si no tiene CD) discos Tamaño máximo por 2040 GB disco Tipo de CD
ISO, Lector host
Número máximo de 4 (aunque 3, pues hace falta 1 CD HD para poder arrancar…) Controlador SCSI Bootable
Sí
Sí
No
Sí
Número máximo de 4 controladores SCSI
4
Número máximo de 64 dispositivos por controlador
64
Tipo de soportado
VHDX, Pass-Through
disco VHD, VHDX, Pass-Through
Número máximo de 256 discos
256 (si no tiene CD)
Tamaño máximo por 2040 GB en VHD o 64 TB en 64 TB disco VHDX Tipo de CD
No soportado
Número máximo de CD Tarjeta de red sintética Sí
ISO 256 (aunque 255, pues hace falta 1 HD para poder arrancar…) Sí
Número máximo
8
8
Bootable
No
Sí
Tarjeta de red heredada Sí Número máximo
4
Bootable
Sí
Adaptador Channel
No 0
Fibre
Número máximo
4
4
1
0
2
0 (1 mediante cmdlets PowerShell)
Sí
No
1
0
Tarjeta de vídeo 3D RemoteFX Número máximo Puerto Com Número máximo Disquetera Número máximo
Observe que Remote FX no está soportado en las máquinas virtuales de generación 2, mientras que sí lo está con las de generación 1. Puede vincular discos virtuales VHDX de generación 1 a una máquina virtual de generación 2, y a la inversa. Si el disco virtual de generación 1 es un VHD, tendrá que convertirlo al formato VHDX; en efecto, las máquinas virtuales de generación 2 soportan únicamente discos con formato VHDX. Es posible realizar esta acción mediante la consola de Hyper-V, con el asistente Editar disco… que se encuentra en el panel de Acciones, o mediante el cmdlet PowerShell Convert-VHD. Observe que el cmdlet PowerShell Convert-VHD permite convertir un VHD en VHDX, y a la inversa. No es posible convertir el disco virtual bootable de una máquina virtual de generación 1 a uno de generación 2, es obligatorio partir de una nueva instalación. Igual que un disco bootable con formato VHDX instalado desde una generación 2 no permitirá arrancar una máquina virtual de generación 1. En una infraestructura virtual de alta disponibilidad (clúster de servidores Hyper-V, Live Migration…), las máquinas virtuales de generación 2 están soportadas únicamente en Windows Server 2012 R2 y Microsoft Hyper-V 2012 R2, y no podrán migrarse a hosts Windows Server 2012 R2 o Microsoft Hyper-V 2012 R2. Puede conocer la generación de una máquina virtual de varias maneras. La primera consiste en utilizar, sencillamente, el Administrador de Hyper-V y consultar el valor del campo Generación presente en el panel de información de una máquina virtual.
Una segunda forma de verificar la generación de una máquina virtual consiste en editar sus propiedades. En efecto, si observa la presencia de controladores IDE, se trata de una máquina virtual de generación 1. La ausencia de controladores IDE pone de manifiesto una máquina virtual de generación 2 .Otra forma de conocer la generación de una máquina virtual consiste en utilizar el cmdlet de PowerShell Get-VM con una visualización de tipo lista: Get-VM -Name VM-Gen2 | fl
3. Creación y configuración de una máquina virtual La creación de una máquina virtual se realiza mediante el Administrador de Hyper-V, en el panel acción, mediante el menú Nueva y seleccionando Máquina virtual.... Le bastará con seguir el asistente Nueva máquina virtual que le solicitará la generación de la máquina virtual que desea crear, así como alguna información básica (el nombre, la cantidad de memoria, la conexión de red de la primera tarjeta de red y el disco duro virtual). También puede utilizar PowerShell: New-VM -Name MaquinaVirtual01
Este comando creará, simplemente, una máquina virtual de primera generación con el mínimo imprescindible: 1 procesador y 512 MB de memoria RAM, sin ningún disco duro y con una tarjeta de red real no conectada. New-VM -Name MaquinaVirtual02 -Generation 2
Este comando creará una máquina virtual de generación 2 con el mínimo vital, 1 procesador, 512 MB de memoria, aunque sin disco y una tarjeta de red sintética no conectada. Observe que no podrá cambiar la generación de la máquina virtual una vez creada.
Para acceder a la configuración de la máquina virtual, en el Administrador de Hyper-V, basta con hacer clic con el botón derecho sobre la máquina virtual y seleccionar Configuración en el menú contextual.
En esta ventana, puede administrar la configuración del hardware de la máquina virtual, y también las interacciones de los servicios de integración con la máquina virtual, así como las acciones que quiere llevar a cabo si debe detener el host. Todos estos parámetros están accesibles, también, mediante PowerShell, aunque la lista de comandos es muy extensa. a. Dynamic Memory
Incluida con Windows Server 2008 R2 SP1, la administración de la memoria dinámica (Dynamic Memory) sigue estando presente. Esta tecnología permite, al servidor Hyper-V, alojar dinámicamente la memoria RAM de las máquinas virtuales según las necesidades de éstas en función de los parámetros que defina.
Con Hyper-V para Windows Server 2012 R2 y Microsoft Hyper-V Server 2012 R2, es posible definir la cantidad de memoria de arranque, además de la memoria mínima y máxima. Esta memoria de arranque se utilizará en la máquina virtual durante sus arranques, reinicios, o vuelta a la actividad tras una suspensión. Si una máquina virtual ejecuta un procesamiento específico que utiliza más memoria de la que se le había asignado en un principio, Hyper-V podrá aumentar, momentáneamente, la cantidad de memoria RAM asignada a esta máquina virtual bien directamente a partir de la memoria libre del servidor Hyper-V o bien a partir de la memoria inutilizada en las demás máquinas virtuales presentes en el mismo servidor. Una vez finalice el proceso intensivo en memoria, ésta se libera si alguna otra máquina virtual la solicita o tiene necesidad de ella.
La memoria se considera, de este modo, como un recurso compartido entre las máquinas virtuales. Su asignación ya no requiere una parada de la máquina virtual para que se tenga en cuenta la nueva capacidad de memoria. Los sistemas operativos de Microsoft que soportan la memoria dinámica son: • • • • • • •
Windows Server 2012/2012 R2. Windows Server 2008 SP2 (32 y 64 bits) / 2008 R2 SP1. Windows Server 2003 SP2 (32 y 64 bits) / 2003 R2 SP2 (32 y 64 bits). Windows 8/8.1 (32 y 64 bits). Windows 7 SP1 (32 y 64 bits). Windows Vista SP2 (32 y 64 bits). Distribuciones de Linux recientes, con los últimos servicios de integración.
b. Resource Metering
Windows Server 2012 incluye la posibilidad de recuperar distintas estadísticas de cada máquina virtual iniciada sobre un host con el rol Hyper-V instalado. Estas estadísticas podrán utilizarse para gestionar una solución de alta disponibilidad mediante SCOM 2012 o SCVMM 2012, o simplemente para realizar una refacturación de servicios en el caso de un proveedor de infraestructura. Las estadísticas que pueden recuperarse son: • • • • • •
Media de uso del procesador: en mega hertzios, durante un periodo de tiempo determinado. Media de uso de la memoria física: en megabytes. Picos mínimo / máximo de memoria física utilizada: en megabytes. Espacio de disco asignado a la máquina virtual. Tráfico total de red entrante: en megabytes. Tráfico total de red saliente: en megabytes.
La configuración y la recuperación de las estadísticas se realizan mediante PowerShell. He aquí algunos ejemplos de cmdlets PowerShell útiles: •
Para habilitar el Resource Metering en una máquina virtual:
Enable-VMResourceMetering -VMName NombreDeLaMaquinaVirtual •
Para habilitar el Resource Metering en todas las máquinas virtuales de un host:
Get-VM -ComputerName NombreDelServidorHost | Enable-VMResourceMetering •
Para configurar la frecuencia de muestreo, los valores admisibles están comprendidos entre 1 hora y 24 horas. El valor por defecto es de 1 hora. Por ejemplo, para una muestra cada 2 horas:
Set-VMHost -ComputerName NombreDelServidorHost -ResourceMeteringSaveInterval 02:00:00 •
Para ver las estadísticas de una máquina virtual en particular:
Measure-VM -Name NombreDeLaMaquinaVirtual # O para obtener información más detallada Measure-VM -Name NombreDeLaMaquinaVirtual | fl
•
Para ver las estadísticas de todas las máquinas virtuales:
Get-VM -ComputerName NombreDelServidorHost | Measure-VM
•
Para reiniciar las estadísticas de una máquina en concreto:
Reset-VMResourceMetering -VMName NombreDeLaMaquinaVirtual
•
Para deshabilitar Resource Metering en una máquina virtual:
Disable-VMResourceMetering -VMName NombreDeLaMaquinaVirtual
c. Redimensionamiento del disco duro virtual en caliente
Windows Server 2012 R2 le permite, ahora, redimensionar sus discos duros virtuales en caliente, lo que permite evitar tener que reiniciar la máquina virtual para realizar este tipo de mantenimiento en el servidor. El único requisito previo es que sus discos duros virtuales tengan el formato VHDX, que estén conectados a un controlador SCSI, y que el sistema operativo alojado lo soporte. Le bastará con utilizar el Asistente para editar discos duros virtuales, mediante el Administrador de Hyper-V, para extender el disco duro virtual. Es, también, posible realizar esta acción mediante el cmdlet PowerShell Resize-VHD. Para terminar, bastará con utilizar el espacio que acaba de configurar, mediante el Administrador de discos en su máquina virtual, siempre que la manipulación haya consistido en extender el disco y no en reducirlo. Puede llegar a ocurrir, en algunos sistemas operativos, que no se analicen bien los discos disponibles y se muestren las modificaciones, como ocurre con algunas distribuciones de Linux, por ejemplo. d. Gestión de la QoS en el almacenamiento de una máquina virtual
Windows Server 2012 R2 incluye la posibilidad de gestionar la calidad de servicio acerca del uso de discos duros virtuales (Storage QoS). Esta funcionalidad permite limitar, o contener, las entradas y salidas por segundo (E/S) en los discos duros de las máquinas virtuales. Por ejemplo, en el caso de una mutualización de los recursos, como con un servidor host, puede resultar práctico limitar los recursos de uso de disco. Otro ejemplo, si tiene una aplicación que requiere una gran tasa de lectura/escritura en disco (como una base de datos SQL), puede querer asignar un mínimo de E/S sobre el disco donde se almacenan los datos. De este modo, la aplicación tendrá, en cualquier caso, una tasa de acceso a disco garantizada. Para configurar la calidad de servicio para un disco virtual, acceda a las Propieades de la máquina virtual y, a continuación, en el disco duro afectado, haga clic en el sigo "+" y en Características avanzadas. Marque la opción Habilitar la administración de calidad de servicio, e indique el valor deseado, que debe estar comprendido entre 0 y 1000000000 (mil millones). Sólo queda aplicar las modificaciones.
También puede modificar estos parámetros mediante PowerShell: # Para configurar el Storage QoS en el disco IDE 0 del controlador # IDE 0 de una máquina virtual. Set-VMHardDiskDrive -VMName VM-Gen1 -ControllerType IDE -ControllerNumber 0 -ControllerLocation 0 -MinimumIOPS 8 -MaximumIOPS 1000
Observe que no es posible utilizar la calidad de servicio sobre el almacenamiento con discos virtuales compartidos. e. Activación automática de máquinas virtuales
Windows Server 2012 R2 edición Datacenter incluye una funcionalidad de activación automática de máquina virtual (AVMA, Automatic Virtual Machine Activation), que resulta muy útil en una infraestructura virtual, con la condición de que esté compuesta por
varios servidors host Hyper-V, instalados con esta edición. En efecto, no debe olvidar que la edición Windows Server 2012 R2 Datacenter le permite ejecutar un número ilimitado de máquinas virtuales Windows, que están cubiertas con la licencia de esta edición Datacenter. La única limitación verdadera es la que imponga el hardware, en términos de rendimiento. Hasta Windows Server 2012, en este tipo de casos, tenía que activar sus máquinas virtuales mediante la clave de licencia del host "Datacenter", dentro de sus máquinas virtuales, para activarlas. ¿Qué ocurría con Live Migration? ¿Cómo era posible gestionar varias máquinas virtuales alojadas en otro host? Además, la activación del sistema operativo invitado tenía que realizarse bien manualmente (por Internet o por teléfono), o bien gracias a un servidor KMS, o incluso, desde Windows Server 2012, mediante la funcionalidad de activación basada en Active Directory (ADBA, Active Directory-Based Activation). Con Windows Server 2012 R2 Datacenter, si el servidor host está activado, las máquinas virtuales que contiene se activarán automáticamente gracias al hipervisor, mediante el VMBus, incluso aunque no formen parte del dominio o no tengan ninguna conexión a Internet. Para implementar esta funcionalidad, basta con que el host sea un servidor Windows Server 2012 R2 "activado" (mediante una clave KMS o ADBA, Open Licence u OEM), y que el sistema operativo de la máquina virtual sea Windows Server 2012 R2 (Datacenter, Standard o incluso Essentials) con una clave AVMA. Las claves AVMA son públicas y están disponibles en la dirección: http://technet.microsoft.com/en-us/library/dn303421.aspx Una vez posea la clave correspondiente a su edición, conviene inscribirla en la máquina virtual. Para ello, en la máquina virtual, abra una línea de comandos (con elevación de privilegios de Administrador) e introduzca el siguiente comando: slmgr /ipk slmgr /ato
La máquina virtual se activará automáticamente por una duración de 7 días, tras los que la máquina virtual validará automáticamente su activación por otros 7 días. Ocurrirá de este modo mientras la máquina virtual resida sobre un host Windows Server 2012 R2 DataCenter. Observe que es posible utilizar una clave AVMA en un archivo de respuesta de instalación de Windows o en las plantillas de máquinas virtuales con SCVMM o SCCM. f. Exportación de máquinas virtuales en caliente
Windows Server 2012 R2 incluye la posibilidad de exportar una máquina virtual, o uno de sus puntos de control, en caliente sin tener que detener la máquina virtual. Esto permite duplicar la máquina virtual para realizar pruebas, sin tener que detener el servidor de producción, o incluso probar la migración de máquinas virtuales entre la Cloud privada y la Cloud interna, siempre sin detener los servidores de máquinas virtuales de producción.
Además, cualquier exportación de una máquina virtual que esté en funcionamiento exportará su estado de memoria. Puede realizar una exportación de la máquina virtual mediante la consola de Administración de Hyper-V o mediante PowerShell con el siguiente comando: # Para exportar una máquina virtual llamada VM-Gen1 a la carpeta # D:\ExportVM. Export-VM -Name VM-Gen1 -Path D:\ExportVM # Para exportar todas las máquinas virtuales a la carpeta # D:\ExportVM. Get-VM | Export-VM -Path D:\ExportVM # Para exportar un punto de control, llamado VM-Gen1-chk1 de una máquina # virtual llamada VM-Gen1, bajo la forma de una nueva máquina # virtual, a la carpeta D:\ExportVM. Export-VMSnapshot -Name VM-Gen1-chk -VMName VM-Gen1 -Path D:\ExportVM
g. Mejora de VM Connect (RDP over VMbus)
Con las versiones anteriores de Windows Server e Hyper-V Server (versiones 2008 a 2012), VM Connect utilizaba una redirección básica de pantalla, teclado y ratón cuando se conectaba a una máquina virtual. Para disponer de funcionalidades avanzadas (tales como la compartición de datos entre el cliente y la máquina virtual), es preciso disponer una conectividad de red entre la máquina virtual y el cliente, además de utilizar el cliente de Escritorio remoto estándar (cliente RDP). Esto permite disponer de todas las ventajas del protocolo RDP (redirección de lectores, impresoras…), pero obliga a la máquina virtual a tener conectividad de red. Otra posibilidad consiste en compartir una carpeta entre el host y la máquina virtual mediante un vswitch de tipo externo (el host y la máquina virtual pueden comunicarse mediante un vswitch externo, pues el host posee una tarjeta de red virtual). Con Windows Server 2012 R2 y Windows 8.1, Microsoft incluye una funcionalidad avanzada al cliente de conexión a un equipo virtual Hyper-V (vmconnect.exe) para que soporte, de forma nativa, el protocolo RDP sobre el VMbus de Hyper-V. Como resultado, cuando se habilita esta funcionalidad (lo cual se aborda más adelante), se tiene una conexión de tipo RDP con la máquina virtual. Esta conexión permite obtener las mismas ventajas que una conexión RDP: • • • • •
Configuración avanzada de la visualización (soporte multi-pantlalla y pantalla multi-touch). Soporte del cortapapeles entre el cliente y la máquina virtual. Redirección del lector de tarjetas smartcard (con posibilidad de autenticación). Redirección del audio. Redirección de impresoras.
• • •
Redirección de lectores. Redirección de dispositivos USB. Soporte de dispositivos Plug-and-Play.
Resulta muy sencillo compartir datos entre el cliente y la máquina virtual, incluso sin una conexión de red. Observe, no obstante, que sólo los hosts Windows Server 2012 R2, Hyper-V Server 2012 R2 y Windows 8.1 soportan esta mejora. En el momento de escribir estas líneas, los únicos sistemas operativos invitados que soportan esta funcionalidad son Windows Server 2012 R2 (todas las versiones) y Windows 8.1 (también todas las versiones). Además, deben disponer del servicio Servicios de Escritorio remoto iniciado y la cuenta de usuario que se utiliza para conectarse a la máquina virtual debe formar parte del grupo Usuarios de Escritorio remoto o Administradores locales en la máquina virtual. Para terminar, sepa que no necesita comprar una licencia de acceso a los Servicios de Escritorio remoto (RDS CAL, Remote Desktop Services Client Access License). En efecto, Microsoft incluye este tipo de conexiones directamente en el contrato de licencia de Windows Server 2012 R2 y Windows 8.1, con una única conexión por máquina virtual. He aquí los pasos a seguir para activar esta funcionalidad en el servidor host: En el host Windows Server 2012 R2, abra el Administrador de Hyper-V y, a continuación, en el panel Acciones, haga clic en Configuración de Hyper-V…. En la ventana de Configuración de Hyper-V, vaya a la sección Directiva de modo de sesión mejorada, y habilite la opción Permitir modo de sesión mejorada.
Aplique los parámetros y cierre la ventana de configuración de Hyper-V. Es todo. Simple, ¿no? Mediante PowerShell: Set-VMHost -Name rdvh1.miempresa.priv -EnableEnhancedSessionMode $true
Sólo queda conectarse a una máquina virtual, con un sistema operativo Windows Server 2012 R2 o Windows 8.1, mediante el Administrador de Hyper-V de Windows Server 2012 R2 o el cliente Hyper-V de Windows 8.1 (o mediante el comando vmconnect.exe de estas mismas versiones de sistemas operativos). Se abrirá una nueva ventana de conexión que le proporcionará la opción de ajustar la resolución de pantalla, así como la posibilidad de utilizar todas las pantallas disponibles.
Haciendo clic en Mostrar (opciones avanzadas) en la esquina inferior izquierda, accede a las opciones de redirección de recursos, similares a las del protocolo RDP.
En la sección Recursos locales, observará que la impresora principal del equipo cliente se ha redirigido hacia la máquina virtual, así como el recurso compartido del portapapeles. Haciendo clic en el botón Más…. tendrá la posibilidad de redirigir las unidades locales así como los dispositivos USB y Plug-and-Play. En este ejemplo, hemos optado por hacer disponible el lector E:\ de nuestro equipo cliente en la máquina virtual.
Una vez conectado a la máquina virtual, encontrará el lector presente en el explorador de Windows.
Para terminar, volviendo a la primera pestaña Mostrar de la conexión, verá una opción para Guardar mi configuración para conexiones futuras en esta máquina virtual.
Esta opción guardará los parámetros de la conexión (desde el equipo cliente hacia esta máquina virtual únicamente) en la carpeta %AppData%\Roaming\Windows\HyperV\Client\1.0\ de su perfil de usuario en el equipo cliente.
4. Gestión de la alta disponibilidad con Hyper-V a. Live Migration
La migración en caliente (Live Migration) permite desplazar una máquina virtual de un servidor a otro sin pérdida en el servicio (pérdida de la conexión de red). Es posible utilizar la migración en caliente de tres formas: •
•
•
Sin un almacenamiento común, los archivos de la VM se almacenan en discos internos del servidor host. En este caso, la migración en caliente será mucho más lenta debido al tiempo de copia de los archivos de disco duro virtuales (archivos VHD y VHDX). Con un recurso compartido SMB 3.0, en este caso, sólo se migrarán los archivos de memoria virtual a través de la red. Los archivos con los discos duros siguen almacenados en el recurso compartido SMB. Con un almacenamiento basado en un array de discos, generalmente conectada en forma de LUN. Sólo se migran los archivos correspondientes a la memoria virtual, los archivos de disco duro virtual siguen en la LUN del array de almacenamiento. Es la solución de migración en caliente más segura y la única que no entraña ninguna interrupción en el servicio.
Windows Server 2012 R2 soporta Live Migration entre hosts Windows Server 2012/2012 R2 así como Microsoft Hyper-V 2012/2012 R2. Windows Server 2008/2008 R2 o Microsoft Hyper-V Server 2008/2008 R2 no están soportados para Live Migration con Windows Server 2012 R2. Windows Server 2012 R2 incluye una optimización de rendimiento tras la migración de una máquina virtual optimizando el desplazamiento de la memoria de la máquina virtual. La primera posibilidad, TCP/IP, copiará los archivos de memoria virtual directamente sobre la red a través de una conexión TCP/IP. La segunda posibilidad difiere de la primera en el sentido de que los archivos de la memoria virtual se comprimen antes de enviarse sobre la red en la que se transitan gracias a una conexión TCP/IP. La última posibilidad permite copiar archivos de memoria virtual sobre la red mediante una conexión SMB 3.0. Se utiliza SMB Direct si las funcionalidades de acceso directo a la memoria remota (RDMA, Remote Direct Access Memory) están habilitadas en las tarjetas de red de origen y de destino. Esto permite obtener cieta mejora en la rapidez de hasta x10, frente al x2 que se alcanza con una compresión sencilla mediante la opción SMB Multichannel incluido en SMB 3.0.
El principio de funcionamiento de una migración requiere varias etapas: • •
• • •
Creación de la VM en el destino. Copia de las páginas de memoria desde el origen hasta el destino. Las páginas modificadas durante la transferencia se envían de nuevo (se marcan como "dirty"), hasta 10 veces. La máquina virtual se pone en pausa en el origen. El acceso al almacenamiento (el disco virtual de la VM) se asigna al servidor de destino. La máquina virtual se pone en funcionamiento de nuevo.
El Clustered Shared Volume (que se aborda en el capítulo dedicado a la Alta disponibilidad) permite a varios servidores acceder a los archivos en el interior de una LUN. Un nodo es propietario del espacio de nombres y sigue siendo el maestro a la hora de crear/eliminar los metadatos (carpetas...). No obstante, distintos nodos pueden acceder a
distintos archivos sobre la misma LUN de manera simultánea, en particular a los archivos VHD y VHDX. Esto permite, por lo tanto, almacenar todos los archivos VHD y VHDX en una única LUN. Todos los nodos pueden acceder al conjunto de archivos, de modo que ya no es necesario modificar el propietario de la LUN. Las LUN pueden, también, cambiar su propietario sin interrupción, puesto que los descriptores son persistentes. Los servidores de origen y de destino deben utilizar procesadores del mismo fabricante. Si los modelos de procesador no son estrictamente idénticos, Hyper-V puede enmascarar las funciones que no sean comunes al conjunto de la plataforma. La opción Migrar a un equipo físico con una versión de procesador distinta lo permite. Esta opción debe configurarse en la configuración del procesador de la máquina virtual que se desea migrar. b. Réplicas Hyper-V
Las Réplicas Hyper-V, incluidas con Windows Server 2012 e Hyper-V Server 2012, permiten realizar una replicación síncrona de las máquinas virtuales entre dos servidores host Hyper-V en el marco de un plan de recuperación de actividad. Esto permite, si ocurriera algún incidente importante en el sitio principal, y gracias a la infraestructura virtual replicada en el sitio secundario, retomar la carga de trabajo con una interrupción mínima del servicio. Las Réplicas Hyper-V son independientes del hardware. La infraestructura del servidor físico no tiene por qué ser idéntico en el sitio secundario, aunque el espacio de almacenamiento del sitio secundario debe ser, al menos, equivalente al del sitio principal, y tener un ancho de banda de red adecuado para soportar el tráfico ligado a la replicación. Un servidor host que se comporte como servidor de réplica puede sincronizar las VM que provengan de varios sitios primarios, y puede replicar una máquina virtual recibida en un servidor primario hacia un servidor secundario de réplica una vez terminada la replicación inicial (Tiers Replica). Debe realizarse una sincronización inicial. Ésta puede realizarse mediante: • • •
La red de replicación de réplicas Hyper-V. EL uso de una copia de seguridad del servidor primario. La exportación y la importación de la VM y su transporte mediante un disco USB externo, por ejemplo.
La configuración de las Réplicas Hyper-V se realiza en dos etapas, aunque es muy sencilla. La primera etapa consiste en configurar los servidores para que acepten la replicación. Para ello, mediante el Administrador de Hyper-V, acceda a las propiedades del servidor y vaya a la sección Configuración de la replicación. Observe que es preciso configurar todos los servidores Hyper-V que participan en la réplica
Es posible utilizar el protocolo HTTP con autenticación Kerberos o HTTPS con autenticación basada en certificados. El primer método, la combinación de HTTP/Kerberos, puede utilizarse entre servidores Hyper-V del mismo dominio o de dominios relacionados. Observe que esta combinación HTTP/Kerberos no encripta los datos, de modo que sólo debe utilizarse en una red de área local, una red extendida dedicada y dotada de seguridad o bien será preciso encriptarla mediante IPsec. El segundo método, la combinación de HTTPS/Certificado para una replicación entre el servidor Hyper-V de dominio no aprobado o en workgroup.
Si quiere utilizar HTTPS, tendrá que utilizar un certificado válido que debe tener el atributo de uso mejorado de la clave (EKU) de autenticación de cliente y servidor con clave privada, el nombre FQDN del servidor debe estar presente como nombre principal o nombre
alternativo. Además, el certificado de la entidad emisora de certificados debe ser conocido y válido. Puede autorizar la replicación a partir de todos los servidores autenticados o especificar el o los servidores de origen. En el último caso, será posible definir carpetas de almacenamiento diferentes para las máquinas virtuales.
Si el firewall de Windows está habilitado, tendrá que activas las reglas ”Escucha HTTP de réplica de Hyper-V (TCP de entrada)” y/o ”Escucha HTTP de réplica de Hyper-V (TCP de entrada)” en el firewall con opciones de seguridad avanzadas. Además, si replica las máquinas virtuales hacia o desde el exterior de su red piense en abrir, y redirigir, el puerto HTTPS (TCP 443) de su firewall.
La segunda etapa consiste en habilitar la replicación en las máquinas virtuales afectadas. Desde el Administrador de Hyper-V, haga clic con el botón derecho en la máquina virtual y seleccione la opción Habilitar replicación… en el menú contextual.
He aquí la información solicitada en el asistente Habilitar replicación: • • • • •
El nombre del servidor de destino. El tipo de autenticación HTTP/Kerberos o HTTPS/Certificado. Los discos virtuales que desea replicar. El número del punto de recuperación. El método para la replicación inicial, con posibilidad de planificación.
Una vez realizada la sincronización inicial, se realiza una replicación continua asíncrona para replicar las modificaciones de la VM. Esta replicación tiene lugar, por defecto, cada 5 minutos y este valor puede modificarse entre tres valores: 30 segundos, 5 minutos o 15 minutos. c. Compartición de discos virtuales (Shared VHDX)
Windows Server 2012 R2 presenta la funcionalidad de compartición de discos virtuales con formato VHDX (Shared VHDX), que permite compartir un disco duro virtual entre varias máquinas virtuales. Esto permite crear un clúster de disco único para el quórum con máquinas virtuales, o incluso un clúster s SQL Server basado en máquinas virtuales, por ejemplo.
Los requisitos previos son los siguientes: • • • •
•
Disponer, al menos, de dos servidores con Windows Server 2012 R2 (o Microsoft Hyper-V Server 2012 R2). Los servidores host deben estar en el mismo dominio de Active Directory. Los servidores host deben tener los roles Hyper-V y Failover Clustering instalados. Los servidores host deben poder acceder a un sistema de almacenamiento a nivel de bloque, de tipo CSV o SoFS. Este almacenamiento puede estar alojado en zonas ISCSI, Fibre Channel, Direct Attached (SAS) o en espacios de almacenamiento en clúster (Clustered Storage Space). Las máquinas virtuales deben estar instaladas con Windows Server 2012 R2.
La funcionalidad de compartición de disco duro virtual soporta únicamente discos virtuales en formato VHDX de tamaño fijo o dinámico. Los archivos VHDX a compartir deben estar, obligatoriamente, almacenados en un CSV (Cluster Shared Volume) o en una partición SoFS (Scale-Out File Server con SMB 3.0). Los discos duros virtuales están disponibles para las máquinas virtuales de generación 1 y de generación 2, siempre que se cumplan los requisitos previos y el disco duro virtual compartido esté asociado a un controlador SCSI en el seno de las máquinas virtuales. Para poder utilizar un disco virtual compartido, conviene, en primer lugar, crear un clúster de servidores Hyper-V, con Windows Server 2012 R2 o Hyper-V Server 2012 R2, con un almacenamiento CSV o SoFS. Para ello, consulte el capítulo que trata sobre la Alta disponibilidad. Una vez instalado el clúster, tendrá que crear un disco duro virtual, con formato VHDX y almacenado en CSV o SoFS, y asociar las máquinas virtuales correspondientes. La creación del disco duro virtual es sencilla: Abra la consola Administrador de Hyper-V y, en el panel Acciones, haga clic en Nuevo y Disco duro… y, a continuación, haga clic en Siguiente para pasar la primera pantalla del asistente de creación de un disco virtual.
Los discos virtuales compartidos se soportan únicamente con formato VHDX, seleccione VHDX y haga clic en Siguiente.
Los discos virtuales compartidos no soportan los discos de diferenciación. Un disco duro virtual de diferenciación requiere la presencia de un disco duro virtual padre que sirva como base, y contiene todas las diferencias que posea con su padre. Del mismo modo que un disco AVHDX necesita un punto de control. Seleccione el tipo de disco duro entre Tamaño fijo o Tamaño dinámico y, a continuación, haga clic en Siguiente.
Indique el nombre del archivo así como su ubicación. Esta puede tener el formato "D:\SharedVD\" si se trata de un CSV, o formato UNC (en nuestro ejemplo \\rdvh1\SharedVD\) con un SoFS. Haga clic en Siguiente para definir el tamaño del disco virtual y, a continuación, haga clic de nuevo en Siguiente y en Finalizar. He aquí la misma operación con PowerShell mediante el comando New-VHD: # Para un disco virtual de 40 GB de tipo dinámico almacenado en el # recurso compartido\\rdvh1\SharedVD\. New-VHD -Dynamic -Path \\rdvh1\SharedVD\SharedVolume.vhdx -SizeBytes 40GB
Tan sólo queda asociar este disco virtual a las máquinas virtuales a las que está destinado, y habilitar el recurso compartido. Para ello, mediante el Administrador de Hyper-V, edite los parámetros de una de las máquinas virtuales y agregue el disco creado al controlador SCSI.
Haga clic en el pequeño icono "+" correspondiente al disco agregado y seleccione Características avanzadas.
Marque la opción Activar uso compartido de discos duros virtuales y, a continuación, haga clic en Aplicar y Aceptar. Puede, también, crear un disco compartido con PowerShell mediante el cmdlet ADDVMHardDiskDrive: # Para vincular un disco virtual en posición (SCSI 0, Disk 1) con el # parámetro "Compartir disco duro virtual", que se encuentra en el # recurso compartido de tipo SoFS, a una máquina virtual # llamada VM-Gen1. Add-VMHardDiskDrive -VMName VM-Gen1 -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 1 -Path \\rdvh1\SharedVD\SharedVolume.vhdx -SupportPersistentReservations # Observe que puede, también, utilizar el parámetro # « -ShareVirtualDisk » que es un alias de
# « -SupportPersistentReservations ».
Sólo queda asociar, del mismo modo, su disco duro compartido a otras máquinas virtuales, y crear un clúster compuesto de sus máquinas virtuales, por ejemplo.
5. SCVMM 2012 R2 SCVMM 2012 R2 (System Center Virtual Machine Manager) es necesario para administrar los servidores Hyper-V con Windows Server 2012 R2. La instalación del módulo complementario SCVMM 2012 R2 es muy sencilla y rápida de realizar. No cabe, por lo tanto, sobrevalorar su aporte funcional en la administración de la infraestructura. No obstante, tendrá que instalar previamente Windows ADK 8.1 (Windows Assessment and Deployment Kit), puesto que es un requisito previo indispensable. Las principales funcionalidades son: •
• • • •
• • • •
•
• • •
Soporte de las características de Windows Server 2012 (máquina virtual de generación 2, redimensionamiento de disco en caliente, exportación y clonado de máquinas virtuales en caliente, etc.). Centralización del despliegue y de la gestión de las máquinas virtuales para HyperV, Virtual Server y VMware ESX. Conversión P2P y P2V rápida y fiable, sin ninguna herramienta suplementaria. Integración con SCOM para la supervisión. Optimización de los recursos y del rendimiento proporcionando desplazamientos y una ubicación de las máquinas virtuales teniendo en cuenta las funciones de red TCP Chimney Offload y VMQ en las propuestas de ubicación. Administración centralizada de una librería de componentes para las máquinas virtuales. Delegación de ciertas tareas de administración. Integración con los clústeres. Automatización e industrialización mediante scripts de PowerShell. SCBMM 2012 es completamente scriptable con PowerShell 4.0 (incluido en Windows Server 2012 R2). Los scripts PowerShell 3.0 están soportados con más del 90% de los cmdlets de PowerShell en común con PowerShell 4.0. En lo relativo a los scripts PowerShell 2.0, tendrá que instalar la funcionalidad complementaria "Motor de Windows PowerShell 2.0". Además, sepa que dado que algunos cmdlets están restringidos en PowerShell 2.0, es preferible utilizar scripts PowerShell 3.0 o 4.0. Administración de varias soluciones de virtualización Microsoft (Virtual Server, Hyper-V 1.0/2.0/3.0) y no Microsoft (Vmware ESX 3.5/4/5 a través de Virtual Center). Generación de informes acerca del estado de la infraestructura virtual. Soporte de las migraciones de las VM ubicadas fuera de un clúster hacia un clúster, y viceversa. Soporte de la migración en caliente (live migration). Soporte del almacenamiento dinámico en las VM en caliente (Windows Server 2008 R2 como mínimo).
• •
Soporte de las redes virtuales VMware ESX y de los grupos de puertos virtuales (Windows Server 2008 R2 como mínimo). Soporte del modo de mantenimiento (Windows Server 2008 R2 como mínimo). La implementación del mantenimiento de un host hace que las VM que hospeda se pongan en pausa, impide la creación de VM sobre el propio host, o el desplazamiento de VM hacia el mismo.
No obstante, no es posible instalarlo sobre una edición Core. Las únicas opciones reales que tiene durante la instalación son las relativas a la base de datos de SCVMM 2012 R2 y las cuentas sobre las que se ejecutará el servicio SCVMM. Ya no es posible utilizar un motor SQL Express 2008/2008 R2/2012, sino que tendrá que utilizar, obligatoriamente, un servidor SQL 2008 R2 SP2 o 2012:
Tiene dos posibilidades para administrar su entorno virtual con SCVMM 2012 R2: • •
Mediante su interfaz gráfica, la Consola Virtual Machine Manager. Mediante la extensión de PowerShell.
Antes de aprovisionar las máquinas virtuales, debería: •
Declarar los servidores Hyper-V que quiere administrar (al menos uno).
• • • •
Declarar las redes virtuales. Crear las plantillas de los perfiles para las máquinas virtuales. Agregar las imágenes ISO a la biblioteca. Crear plantillas de discos duros virtuales.
La declaración de redes virtuales se realiza desde las propiedades del servidor virtual:
De cara a simplificar y automatizar el despliegue de nuevas máquinas virtuales, es posible definir distintos tipos de perfil: perfil de aplicación, perfil de sistema operativo invitado o incluso perfil SQL Server. Los perfiles de hardware permiten utilizar las plantillas de configuración en lugar de configurar manualmente los recursos para cada VM. Más allá de la ganancia en eficacia a la hora de crear una VM, esto permite mantener una consistencia en la configuración entre dos máquinas virtuales, ganando, así, en calidad. Para gestionar los perfiles de hardware, vaya a Biblioteca y, a continuación, Perfiles. Un perfil incluye los siguientes parámetros:
Agregar imágenes ISO consiste simplemente en copiar archivos ISO en la carpeta compartida de la biblioteca SCVMM. Tras una actualización de la biblioteca, Virtual Machine Manager indexa los archivos registrados en las carpetas compartidas de la biblioteca, y a continuación actualiza la vista Biblioteca y la lista de recursos. No todos los archivos están indexados y no todos los archivos aparecen en la vista Biblioteca. El contenido de la biblioteca se refresca automáticamente por defecto cada hora. El tipo de contenido que se indexa es el siguiente: • • • • •
discos duros virtuales: .vhdx y .vhd (Hyper-V, Virtual Server), .vmdk (VMware). disquetes virtuales: .vfd (Virtual Server), .flp (VMware). Imágenes ISO: .ISO. archivos de respuesta: .ps1 (Windows PowerShell); .inf o .xml. plantillas VMware: .vmtx.
Los siguientes tipos de archivos de configuración también se indexan, aunque no se agregan a la biblioteca como recursos: • • •
Hyper-V: .exp (formato para exportar), .vsv (estado almacenado), .bin. Virtual Server: .vmc (configuración de la máquina virtual), .vsv (estado almacenado). VMware: .vmtx (configuración de la máquina virtual), .vmx (formato de exportación).
•
Los discos duros virtuales, imágenes ISO y disquetes virtuales asociados a un equipo virtual.
La administración de las máquinas virtuales puede realizarse mediante PowerShell, lo que abre las puertas necesarias a las planificaciones, automatizaciones y procesamientos masivos. He aquí algunos ejemplos de comandos PowerShell: Recuperar una cuenta de acceso: $Credential = get-credential
Recuperar el identificador del grupo "Todos los equipos host": $VMHostGroup = Get-VMHostGroup -VMMServer localhost | where {$_.Path -eq "Todos los equipos host"}
Agregar el recurso Hyper-V: Add-VMHost -VMMServer localhost -ComputerName "hyperv.miempresa.priv" -Description "" -Credential $Credential -RemoteConnectEnabled $true -VmPaths "E:\VMDATA" -Reassociate $false -RunAsynchronously -RemoteConnectPort 2179 -VMHostGroup $VMHostGroup
Declarar un nuevo adaptador de red virtual: New-VirtualNetworkAdapter -VMMServer localhost -JobGroup e4c2dfd1-0091-4a2a-992f-3406cfe833eb -PhysicalAddressType Dynamic -VirtualNetwork "Net_LAN" -VLanEnabled $false
Declarar un nuevo lector de DVD virtual: New-VirtualDVDDrive -VMMServer localhost -JobGroup e4c2dfd10091-4a2a-992f-3406cfe833eb -Bus 1 -LUN 0
Utilizar un tipo de procesador ya existente: $CPUType = Get-CPUType -VMMServer localhost | where {$_.Name -eq "3.07 GHz Xeon"}
Declarar un nuevo perfil de hardware para las VM: New-HardwareProfile -VMMServer localhost -Owner "MIEMPRESA\administrador" -CPUType $CPUType -Name "Profil11d45f28-11b9-414b-aca0-ce8fbf6b9081" -Description "Configuración de hardware para crear una máquina virtual/plantilla" -CPUCount 2 -MemoryMB 512 -RelativeWeight 100 -HighlyAvailable $false
-NumLock $false -BootOrder "CD", "IdeHardDrive", "PxeBoot", "Floppy" -LimitCPUFunctionality $false -JobGroup e4c2dfd1-0091-4a2a-992f-3406cfe833eb
Recuperar un perfil de hardware existente: $HardwareProfile = Get-HardwareProfile -VMMServer localhost | where {$_.Name -eq "Profil11d45f28-11b9414b-aca0-ce8fbf6b9081"}
Declarar un nuevo disco virtual: New-VirtualDiskDrive -VMMServer localhost -IDE -Bus 0 -LUN 0 -JobGroup e4c2dfd1-0091-4a2a-992f-3406cfe833eb -Size 40960 -Dynamic -Filename "PRD-DOM-WEB01_disco_1"
Recuperar un sistema operativo existente: $OperatingSystem = Get-OperatingSystem -VMMServer localhost | where {$_.Name -eq "64-bit edition of Windows Server 2008 Standard"}
Recuperar un servidor Hyper-V: $VMHost = Get-VMHost -VMMServer localhost | where {$_.Name -eq "hyperv.miempresa.priv"
Declarar una nueva máquina virtual: New-VM -VMMServer localhost -Name "PRD-DOM-WEB01" -Description "Servidor WEB IIS en el dominio" -Owner "MIEMPRESA\administrador" -VMHost $VMHost -Path "E:\VMDATA" -HardwareProfile $HardwareProfile -JobGroup e4c2dfd10091-4a2a-992f-3406cfe833eb -RunAsynchronously -OperatingSystem $OperatingSystem -RunAsSystem -StartAction TurnOnVMIfRunningWhenVSStopped -DelayStart 0 -StopAction ShutdownGuestOS
Los comandos New-HardwareProfile y New-VM ejecutan el grupo de comandos que poseen el mismo JobGroup. Si desea más información acerca de los JobGroups consulte la siguiente página: http://technet.microsoft.com/es-es/library/hh875035.aspx Si desea administrar clústeres Hyper-V con SCVMM, he aquí algunas consideraciones: •
•
Si agrega almacenamiento sobre un clúster e inmediatamente desea agregar máquinas virtuales sobre este almacenamiento, asegúrese previamente de que el clúster se ha refrescado en SCVMM para tener en cuenta este nuevo almacenamiento. La creación/supresión de los clústeres no puede hacerse en SCVMM.
•
Los clústeres que no están en un dominio de confianza no pueden administrarse con SCVMM.
La optimización de los recursos puede administrarse en función de los siguientes parámetros:
Este conjunto de criterios se utiliza a continuación para sugerir el lugar donde almacenar y desplazar las máquinas virtuales a través de una configuración en estrella. SCVMM permite a su vez administrar la asignación de direcciones MAC a las máquinas virtuales. Por defecto, se define un rango, aunque puede modificarse en caso de problema:
Esto no es sino una pequeña introducción de las posibilidades de System Center - Virtual Machine Manager 2012, este producto necesitaría un libro entero para poder dominarlo con destreza.
6. Actualizaciones de Windows Con el objetivo de facilitar la instalación de las actualizaciones de Windows, Microsoft proporciona una herramienta complementaria a SCVMM, el Offline Virtual Machine Servicing 2012. El objetivo de esta herramienta es iniciar las máquinas virtuales sobre una red aislada (preferentemente), iniciar las actualizaciones de Windows, y apagar la máquina virtual, incluyéndola de nuevo en la biblioteca. Necesita por un lado SCVMM, y por otro un servidor WSUS local (gratuito) o SCCM 2012 R2. Puede descargarse en la siguiente dirección: http://www.microsoft.com/en-us/download/details.aspx?id=30470
Esta herramienta se proporciona para 32 y 64 bits. Se recomienda su uso en infraestructuras virtuales consecuentes con un número importante de máquinas virtuales detenidas, o para entornos donde la seguridad es un factor importante. Antes de decidir utilizar o no esta herramienta, he aquí algunos puntos que debería considerar:
•
• • •
• •
Las VM deben estar configuradas para utilizar el servidor WSUS mediante GPO u otro (no considerado en esta herramienta), o tener el cliente SCCM instalado y configurado. WSUS o SCCM deben estar configurados previamente para que las actualizaciones estén aprobadas en el despliegue de estas VM. Las VM deben estar en DHCP, o tener una configuración de red funcional en la red de actualizaciones. Si se van a actualizar más de 20 máquinas virtuales con esta herramienta, se recomienda que la infraestructura en torno a la misma sea física y no virtual (servidor WSUS, SCVMM...). Funciona a la vez sobre una infraestructura Hyper-V y Virtual Server 2005. Todos los servidores físicos y las máquinas virtuales deben formar parte del dominio Active Directory, con el servicio DNS instalado y configurado.
He aquí un ejemplo de arquitectura:
Conclusión Para concluir, ahora conoce qué puede aportarle la virtualización, con la condición de tener en cuenta sus especificidades. Si, como ocurre cada vez con más administradores, observa una ventaja clara al virtualizar, debe realizar una prueba de concepto para validar sus hipótesis. Según su contexto, la complejidad de este tipo de proyecto puede variar de forma importante y debe estar preparado en consecuencia. Como se indica en la introducción, piense a lo grande pero comience dando pequeños pasos para poder tener un aumento de carga controlado.
Introducción Este capítulo está dedicado al despliegue de servidores y puestos de trabajo. Contar con una plantilla de instalación automatizada supone una ganancia importante en la productividad y en la calidad. La instalación de servidores tiene poco valor añadido aunque debe hacerse siempre de la misma forma, con las mismas versiones de componentes, para tener coherencia entre todos los sistemas. Un despliegue comprende como mínimo el sistema operativo, pero también generalmente el conjunto de controladores, herramientas del sistema, o incluso el conjunto de aplicaciones necesarias. La automatización de este proceso cobra mayor sentido con la virtualización, y los entornos "a la carta". La preparación de este despliegue es un aspecto muy importante para el éxito de su proyecto. La tecnología no supone ningún inconveniente, ¡no hay ningún motivo para no usarla!
Preparar bien el despliegue planteando una buena estrategia La preparación es la fase crítica del proyecto. Para no olvidar nada y acelerar su despliegue, Microsoft proporciona diferentes herramientas adaptadas a su contexto. Al finalizar esta etapa, usted habrá determinado el perímetro, el tipo de licencias y ediciones de Windows, el plan de despliegue así como la infraestructura necesaria para conseguirlo.
1. Definir el perímetro Como en todo proyecto, el perímetro es aquí un elemento clave. Debería definir lo que es "obligatorio" y lo que es "opcional". Para llevar a cabo esta reflexión, he aquí una lista de elementos que pueden integrarse en su proyecto: •
¿Sólo servidores o también puestos cliente?
• • • • • • •
• • • •
¿Qué versiones y ediciones de Windows se desea incluir? ¿Hace falta gestionar varios idiomas? ¿Qué nomenclatura desea adoptar para los sistemas desplegados? ¿Quién va a desplegar estas imágenes? ¿La implementación debería estar completamente automatizada? ¿Qué hardware (y controladores) desea incluir? ¿Qué actualizaciones deben/pueden estar presentes tras el despliegue? ¿Qué herramientas o aplicaciones forman parte del núcleo común y pueden estar presentes tras el despliegue? ¿Puede hacer una instalación genérica y automatizada de estas aplicaciones? ¿Es necesario crear varias imágenes de despliegue con distintas opciones o basta con una sola? ¿Hace falta una imagen específica para los entornos virtuales? ¿Todos los equipos a desplegar están sobre la red local y en el dominio? ¿Hace falta poder instalar una imagen desde un DVD? ¿Ya utiliza SCCM 2012 SP1 CU3 o SCCM 2012 R2 (System Center Configuration Manager)? ¿Cómo piensa administrar las licencias asociadas a los sistemas operativos? ¿Utiliza licencias por volumen?
La respuesta a esta lista de preguntas cubre gran parte del perímetro. Las decisiones que más impactarán al proyecto de despliegue son: • • •
el uso de SCCM 2012 SP1 o SCCM 2012 R2, que permiten realizar un despliegue "zero touch"; la integración de aplicaciones en la imagen; la elección del modo de transporte para el despliegue (red u otro).
El hecho de incluir más o menos tipos de hardware sólo tiene impacto en el tiempo necesario para incluir los controladores adecuados. Se habrá dado cuenta de que se ha empleado el término "imagen" para designar al método de despliegue. Se trata, en efecto, de construir un modelo de servidor que se va a capturar en forma de imagen y a volver genérico. Esto hace que la integración de las aplicaciones en el despliegue sea una tarea muy sencilla, siempre y cuando su instalación sea genérica. Esta imagen puede desplegarse a continuación mediante diversos medios, a través de la red o mediante un DVD.
2. Administración de las licencias Presentado con Windows Vista y Windows Server 2008, Windows 8.1 y Windows Server 2012 R2 pueden utilizar el servicio de administración de licencias por volumen: KMS (Key Management Service) para la activación de Windows. Se trata de un servicio de infraestructura que debe implantar en su red para administrar las licencias de sus servidores y puestos de trabajo. Si no implementa este servicio, cada equipo tendrá que conectarse de forma individual a Microsoft a través de Internet para activarse. La activación mediante del servicio KMS permite no tener que conectarse a Microsoft para activar Windows, y esta activación es válida por 6 meses. Pasado este periodo, el sistema tiene que activarse de nuevo por un periodo de 180 meses más conectándose a su red. KMS puede implementarse
a partir de 25 licencias Windows 8.1 o 5 licencias Windows Server 2012 R2. El servicio KMS puede, también, activar Microsoft Office 2010 y 2013. La instalación de KMS es tan sencilla como introducir la clave KMS, pues el servicio de Windows asociado ya está instalado y activo por defecto (se trata del Servicio de licencias de software): cscript C:\windows\system32\slmgr.vbs /ipk claveKMS
A continuación, el servidor debe validar esta clave con Microsoft. Este proceso tiene lugar una sola vez cada vez que se agrega una clave. Si el servidor tiene acceso a Internet: cscript C:\windows\system32\slmgr.vbs /ato
En caso contrario, podrá realizar la activación telefónicamente ejecutando el comando slui.exe 4. Para detectar el servidor KMS, Windows utiliza el DNS, un recurso SRV en particular. Si las actualizaciones dinámicas de DNS están autorizadas, el servicio crea automáticamente los registros DNS adecuados. Si su entorno no las autoriza, podrá configurar KMS para que deje de intentar crear el registro SRV ejecutando el comando: cscript %systemroot%\system32\slmgr.vbs /cdns
El recurso SRV puede crearse de forma manual con los siguientes parámetros: • • • •
Servicio: _VLMCS Protocolo: _TCP Puerto: 1688 Host que ofrece el servicio: FQDN del host
Si el servicio DNS no está disponible desde el cliente, podrá especificar de forma manual la dirección IP del servidor KMS que desee utilizar mediante el comando: cscript %systemroot%\system32\slmgr.vbs /skms X.X.X.X:1688
Si existe un firewall entre los equipos a activar y el servidor KMS, el puerto TCP 1688 (por defecto) tiene que estar abierto (del lado cliente únicamente). Si desea cambiar el puerto TCP es preciso modificar la siguiente clave tanto en el servidor KMS como en los clientes: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL
Nombre: KeyManagementServicePort Tipo: REG_SZ
Valor: XXXX (valor que representa el nuevo puerto de escucha TCP). Para conocer el número de licencias que actualmente se están utilizando en su KMS, puede ejecutar el siguiente comando: cscript %systemroot%\system32\slmgr.vbs /dli
Si no desea utilizar KMS sino que prefiere activar de forma masiva sus sistemas Windows, puede utilizar VAMT (Volume Activation Management Tool). Puede descargar esta herramienta desde MDT 2012, en el nodo Componentes.
3. Seleccionar la edición y el tipo de instalación A diferencia de Windows Server 2008/2008 R2, donde cada pareja edición/tipo de instalación (completa o mínima) requería una nueva imagen de despliegue, Windows Server 2012 R2 sólo necesita dos. Una para la edición Estándar y otra para la edición Datacenter. Los servidores virtuales se instalarán, generalmente, con ediciones Estándar de Windows Server. El primer motivo es que la interfaz gráfica puede, ahora, instalarse o desinstalarse con total sencillez. Se ha convertido en una característica más. Ya no hay, por lo tanto, necesidad de tener una imagen particular para una instalación mínima. El segundo motivo reside en el hecho de que ya no existe ninguna diferencia entre la edición Estándar y Datacenter con Windows Server 2012 R2. Ya no es preciso tener que recurrir a la edición Enterprise (que no existe con Windows Server 2012) o a la edición Datacenter para aprovechar la funcionalidad de Failover Clustering, por ejemplo, como era el caso con Windows Server 2008/2008 R2. Existe, en resumen, una menor cantidad de imágenes que gestionar, lo cual supone una buena noticia.
Crear y ejecutar el despliegue Esta sección cubre la creación y el despliegue de los sistemas operativos, tanto de clientes como de servidores. Microsoft Deployment Toolkit es la herramienta central, que enriquece las herramientas nativas mediante una interfaz amigable y un emplazamiento único donde alojar todos los datos necesarios para los despliegues. Proporciona dos métodos: Lite Touch y Zero Touch
1. Microsoft Deployment Toolkit (MDT 2013) Microsoft pone a su disposición de forma gratuita una herramienta que le permitirá acelerar su proyecto de despliegue, MDT 2013. Éste soporta Windows 7 y Windows Server 2012 R2, gracias a WADK para Windows 8.1. MDT 2013 soporta, también, Office 2010, Office
365 y Zero-Touch Integratio (ZTI) con System Center 2012 R2. Observe que MDT 2013 no permite instalar Windows XP, Windows Vista, Windows Server 2003/2003 R2 o incluso Windows Server 2008, para trabajar con estos sistemas operativos tendrá que utilizar MDT 2012 SP1 CU2 con WADK para Windows 8 o WAIK para Windows 7. MDT utiliza varios componentes, como WADK para Windows 8.1 (Windows Assessment and Deployment Kit), que soporta desde Windows 7 SP1 y Windows Server 2008 R2 hasta Windows 8.1 y Windows Server 2012 R2. WADK para Windows 8.1 necesita, obligatoriamente, MDT 2013 para funcionar. Está disponible en la siguiente dirección: http://www.microsoft.com/es-es/download/details.aspx?id=39982 WADK y WAIK son dos componentes bastante similares. Contienen un conjunto de herramientas que permiten personalizar y desplegar Windows a gran escala. Sus verdaderas diferencias son: • •
las versiones de Windows soportadas, de Windows XP SP3 a Windows 7 para WAIK, y de Windows 7 a Windows 8.1 para WADK. la versión de MDT soportada, MDT 2012 sp1 para WAIK, y MDT 2013 para WADK.
He aquí una lista no exhaustiva de las herramientas que contienen WAIK y WADK: • •
• • •
User State Migration Tool (USMT): esta herramienta permite migrar datos de un perfil de usuario a otro. Application Compatibility Toolkit (ACT): aplicación que permite detectar eventuales problemas de compatibilidad de sus aplicaciones y drivers antes de realizar una actualización de Windows. Volume Activation Management Tool (VAMT): herramienta que permite gestionar y centralizar la activación de Windows en la red. Herramientas de modificación de imagen: ImageX, que permite capturar y aplicar las imágenes WIM, DISM, que permite modificar una imagen WIM... Windows Preinstallation Environment (Windows PE): ofrece un entorno personalizable de instalación de Windows.
Una vez instalados MDT 2013 y WADK, la interfaz de administración se encuentra en la pantalla de inicio de Windows, Deployment Workbench. Los componentes complementarios pueden descargarse desde la misma consola en la pestaña Components:
Es preciso descargar, al menos, el componente Windows Assessment and Deployment Kit para Windows 8.1 (también llamado WADK), en 32 o 64 bits dependiendo de su entorno de trabajo. MDT está disponible únicamente en inglés, y descargará dicho componente en inglés. Para descargar la edición española, basta con ir a la siguiente dirección: http://www.microsoft.com/es-es/download/details.aspx?id=39982
Cuando alguno de los componentes no esté presente, no funcionará ninguna de las funcionalidades del árbol Deployment Share. MDT controla WADK para asistirle en la implementación y no puede funcionar sin él. Descargándolo, obtiene también Windows PE. Una vez instalado WADK, el árbol Deployment Shares permite crear un espacio de trabajo. Para ello, basta con hacer clic con el botón derecho, seleccionar la opción New Deployment Share. La ubicación seleccionada debe tener suficiente espacio para contener las fuentes y las imágenes generadas.
A continuación, podemos alimentar cada módulo de este espacio de trabajo: • • • • • •
Applications: contendrá las aplicaciones incluidas en el despliegue. Operating Systems: contendrá los archivos fuentes de los sistemas operativos. Out-of-Box Drivers: contendrá los controladores suplementarios necesarios. Packages: contendrá las actualizaciones de Windows que desee integrar. Task Sequences: permite crear un escenario a partil de elementos de los módulos. Advanced Configuration: permite crear un medio (DVD...), guardar una traza de los despliegues en una base de datos SQL o administrar las réplicas del punto de distribución.
Las siguientes etapas son: • • • • • •
Agregar los sistemas operativos (desde su DVD...). Agregar las aplicaciones (instalación silenciosa...). Agregar las actualizaciones de Windows. Agregar los controladores. Crear una secuencia de acciones a realizar. Crear una base de datos para inventariar las máquinas desplegadas.
Es muy sencillo agregar sistemas operativos. Una vez importado el CD o DVD, aparecerá de la siguiente manera:
Observe que la lista comprende a la vez Windows Server 2012 R2 y Windows 8.1. MDT 2013 también permite desplegar Windows Server 2008 R2, Windows Server 2012 R2, Windows 8 y Windows 7. Agregar una aplicación mediante el nodo Applications le permitirá instalar aplicaciones post-despliegue. Se trata de instalaciones silenciosas, de archivos MSI, etc. A continuación podrá integrarlas en las secuencias de instalación. Están disponibles las siguientes propiedades:
La selección Application bundle permite agrupar las aplicaciones. La agregación de actualizaciones de Windows se realiza mediante el nodo Packages. Es tan sencillo como indicar la carpeta que las contiene (archivos .cab y .msu). Por defecto, pertenecen al grupo All Packages. Puede agregar grupos personalizados para filtrar las actualizaciones en las secuencias de instalación. El apartado Out-of-Box Drivers contendrá todos sus controladores. Basta con indicar la carpeta que los contiene (archivos .inf). Puede clasificar los elementos de cada apartado en carpetas y subcarpetas.
El nodo Task Sequences es la pieza clave de la aplicación. Permite articular todos los elementos para crear los escenarios de instalación. Durante la instalación de una secuencia sólo es posible indicar las opciones básicas: • • • • • •
Un identificador único, un título y una descripción. Una máscara de secuencia. Un sistema operativo de entre la lista del apartado Operating Systems. Indicar o no el número de serie (periodo de prueba que expira). El nombre y la página por defecto de Internet Explorer. La contraseña del Administrador local (o que se solicitará tras el primer inicio de sesión).
Una vez creada, hay que abrir las propiedades de la secuencia, en la pestaña Task Sequence, para descubrir toda la capacidad real de las secuencias:
Las opciones están agrupadas por temática: •
General
• • • • • • • • • •
Ejecutar una línea de comando. Ejecutar un script PowerShell. Asignar un valor a una variable. Reiniciar. Recoger información. Instalar actualizaciones tras el primer arranque. Validar. Instalar una o varias aplicaciones presentes en el nodo Applications. Instalar controladores. Ejecutar un Runbook System Center Orchestrator.
•
Discos
• • •
Particionar y formatear un disco. Activar BitLocker. Crear discos virtuales VHD.
•
Imágenes
•
Instalar un sistema operativo.
•
Configuración
• •
Aplicar una configuración de red (IP, DNS, WINS). Capturar la configuración de red existente.
•
Roles
•
Instalar y configurar roles y características. Las posibilidades varían según el sistema operativo a instalar. Configurar el servidor DHCP, DNS, Active Directory, y por último autorizar a DHCP.
•
Los posibles escenarios son muy amplios durante el despliegue: •
• •
Copia de seguridad o no de los perfiles de usuarios locales sobre una partición en red (con restauración). Capturar la configuración de red antes de la reinstalación, y a continuación restaurarla. Instalación y configuración de roles. Administración de BitLocker con su configuración:
• • •
Medio de almacenamiento (TPM, USB, ambos). Creación de una clave de recuperación en Active Directory. Esperar a que termine la encriptación antes de continuar.
•
Instalación de las actualizaciones de Windows.
•
A continuación queda por definir un punto de despliegue en el apartado Deploy Deployment Points. Las posibilidades son: • • • •
La partición local a la máquina donde se ejecuta MDT 2013. Una partición local o remota que contenga un único juego de configuración. Un medio de almacenamiento extraíble (DVD, USB). Una integración con SCCM 2012 R2 o versiones anteriores.
Las secuencias se almacenan en la subcarpeta Control del recurso compartido creada anteriormente, con la siguiente arborescencia:
•
En la raíz:
• •
Bootstrap.ini: archivo de configuración cuando la máquina que se despliega no puede conectarse a un punto de despliegue. CustomSettings.ini: archivo de configuración común a todas las secuencias.
•
{Número de secuencia}
• •
TS.xml: contiene metadatos relacionados con la secuencia. Unattend.xml: contiene los valores para el sysprep.
El despliegue desde un medio portátil es el más básico, aunque es muy eficaz cuando la conectividad de la red está limitada. En la carpeta de destino encontrará una imagen ISO de arranque, LiteTouchPE_x86.iso o LiteTouchPE_x64.iso según su entorno. Windows PE es el entorno de preinstalación de Windows. Se trata de un sistema Windows muy ligero que permite ejecutar un conjunto de herramientas para desplegar un sistema operativo Windows. La imagen WIM generada con MDT utiliza Windows PE. En este tipo de entornos el motor vbscript está disponible. Las pantallas gráficas MDT son vbscript y HTA (HTML Applications). Al tener los archivos en memoria, Windows PE puede particionar y formatear todo el espacio de almacenamiento disponible, en especial la partición de sistema. Ciertas herramientas, como USMT e ImageX, funcionan en este tipo de entorno, lo que permite realizar una copia de seguridad de los datos del equipo antes de su reinstalación, por ejemplo. La versión actual es la 4.1 que se corresponde con Windows 8 y Windows Server 2012 R2. He aquí un ejemplo del entorno que proporciona MDT:
2. Lite Touch La solución Lite Touch le permite industrializar el despliegue sin tener que disponer de la infraestructura de gestión de Microsoft, System Center Configuration Manager 2012 R2. La solución es sencilla de implantar pero mantiene su eficacia, pues utiliza el motor de secuencia de esta última en versión autónoma. El despliegue debe iniciarse de forma manual, pero se le guiará mediante pantallas gráficas para llevarlo a cabo. Más allá del uso de una imagen ISO como se ha visto anteriormente, es posible realizar el despliegue a través de la red utilizando WDS (cuya instalación se cubre más adelante). A continuación, debe especificar en CustomSettings.ini la variable DeployRoot=\\%WDSServer%\DeploymentShare$, en la sección [Default]. Tiene que reemplazar DeploymentShare$ por el nombre de su recurso compartido si no ha dejado el nombre por defecto. A continuación tiene que actualizar el punto de distribución haciendo clic con el botón derecho encima de él y a continuación seleccionar Update Deployment Share. Basta con: • •
Importar ambas imágenes WIM en WDS; arrancar una máquina mediante PXE.
También es posible utilizar el modo multicast para el despliegue:
Antes de desplegar una imagen se plantean varias preguntas a través de la interfaz gráfica. Es posible aumentar la automatización, evitándolas. Para ello tendrá que proporcionar la respuesta a estas preguntas en el archivo CustomSettings.ini. He aquí las etapas que pueden evitarse si las siguientes variables se informan a YES (en mayúsculas) en el archivo CustomSettings.ini, sección [Default]. A cada pantalla le corresponde una variable para omitirla y una o varias variables para informar los datos solicitados por pantalla: SkipAdminPassword: no solicitar la contraseña del administrador local. •
Automatizar mediante AdminPassword=micontraseñadeadministrador. La contraseña se almacenará sin encriptar en el archivo, debería, por tanto, cambiar de contraseña posteriormente. Del mismo modo se recomienda cambiarla regularmente en el conjunto de sus equipos.
SkipApplications: omitir la etapa que propone instalar aplicaciones. •
Automatizar mediante Applications001={GUID de la aplicación que se encuentra en control\Applications.xml}
SkipAppsOnUpgrade: omitir la etapa de instalar aplicaciones si se trata de una actualización. SkipBDDWelcome: omitir la pantalla de bienvenida. SkipBitLocker: omitir BitLocker. SkipBitLockerDetails: omitir la configuración de BitLocker. SkipTaskSequence: omitir la selección de la secuencia. •
Automatizar mediante TaskSequenceID={Identificador de la secuencia}
SkipCapture: omitir el uso de captura. •
Automatizar mediante DoCapture=NO|YES|PREPARE
SkipComputerBackup: omitir la copia de seguridad del equipo. •
Automatizar mediante ComputerBackupLocation=NETWORK|AUTO|NONE
• •
NETWORK hace una copia de seguridad en la red. AUTO hace una copia de seguridad local si hay suficiente espacio en disco, en caso contrario la realiza en la red. NONE no hace ninguna copia de seguridad.
•
Si desea realizar una copia de seguridad sobre la red, es preciso utilizar estas dos variables: • •
BackupShare=\\DC2012\Backup$ BackupDir=%ComputerName%
Para que funcione la copia de seguridad, es preciso asignar los siguientes permisos en el recurso compartido utilizado: • •
Objeto equipos y usuarios de dominio con permisos de creación de carpetas y agregación de datos. Propietario con permisos de control total
SkipComputerName: no solicitar el nombre de equipo. •
Automatizar mediante ComputerName=%SerialNumber% , por ejemplo.
SkipDeploymentType: no solicitar el tipo de despliegue. •
Automatizar mediante DeploymentType=NEWCOMPUTER. Puede tomar los valores NEWCOMPUTER, REFRESH, REPLACE, UPGRADE
SkipDomainMembership: omitir la opción de unir el equipo a un dominio. •
Automatizar mediante JoinDomain=MIEMPRESA. Las variables adicionales son:
• • • •
MachineObjectOU=OU=Mis_Servidores,DC=miempresa,DC=priv DomainAdmin=Administrador DomainAdminDomain=MIEMPRESA DomainAdminPassword=contraseñacompleja
Dado que la contraseña se almacena sin encriptar, debería utilizar una cuenta que sólo tenga permisos para incluir equipos en el dominio. SkipFinalSummary: omitir la ventana final de resumen de la secuencia. SkipLocaleSelection: omitir la elección de parámetros regionales. •
Automatizar mediante:
KeyboardLocale=es-ES (incluir también esta variable en bootstrap.ini para tener el teclado configurado en español durante la instalación). UserLocale=es-ES y UILanguage=es-ES SkipPackageDisplay: omitir la opción de realizar un paquete complementario. SkipProductKey: no solicitar el número de serie. SkipSummary: omitir el resumen. SkipTimeZone: no solicitar la zona horaria. •
Automatizar mediante TimeZoneName=’’TimeZoneName=Romance StandardTime’’.
SkipUserData: omitir la opción de realizar una copia de seguridad de los perfiles de usuario. •
Automatizar mediante UserDataLocation=NETWORK|AUTO|NONE.
• •
NETWORK hace una copia de seguridad en la red. AUTO hace una copia de seguridad local si hay suficiente espacio en disco, en caso contrario la realiza en la red. NONE no hace ninguna copia de seguridad.
•
Si desea realizar una copia de seguridad sobre la red, es preciso utilizar estas dos variables: • •
UDShare=\\DC2012\Profiles$ UDDir=%ComputerName%
Por último, para informa la cuenta que se utilizará para acceder al recurso compartido que contiene los recursos MDT: USERID=Administrador UserPassword=contraseñacompleja UserDomain=MIEMPRESA
Su archivo CustomSettings.ini podría tener el siguiente aspecto: [Settings] Priority=Default Properties=MyCustomProperty [Default] OSInstall=Y SkipBDDWelcome= YES SkipCapture=YES SkipAppsOnUpgrade=YES SkipFinalSummary=YES SkipPackageDisplay= YES SkipProductKey=YES SkipSummary=YES USERID=Administrador UserPassword=contraseñacompleja UserDomain=MIEMPRESA SkipComputerBackup=YES ComputerBackupLocation= NONE SkipAdminPassword=YES AdminPassword=micontraseñadeadministradorlocal SkipApplications=YES Applications001={73823faf-bb78-4491-a053-b47afb5553c4} SkipTaskSequence=YES TaskSequenceID= 001 SkipComputerName=YES ComputerName=%SerialNumber% SkipDeploymentType=YES DeploymentType=NEWCOMPUTER SkipDomainMembership=YES JoinDomain=MIEMPRESA MachineObjectOU=OU=Mis_Servidores,DC=miempresa,DC=priv DomainAdmin=Administrador DomainAdminDomain=MIEMPRESA
DomainAdminPassword=contraseñacompleja SkipLocaleSelection=YES KeyboardLocale=es-ES UserLocale=es-ES UILanguage=es-ES SkipTimeZone=YES TimeZoneName=Romance Standard Time" SkipUserData=YES UserDataLocation=NONE DeployRoot=\\DC2012\DeploymentShare$
La integración con WSUS está prevista en MDT. Por defecto, la máquina intentará conectarse a los servidores Microsoft Windows Update en Internet. Si tiene un servidor WSUS, puede indicárselo a MDT agregando la variable WSUSServer=http://miservidor en el archivo Custom- Settings.ini. Si especifica un servidor WSUS pero el cliente no está actualizado, MDT intentará descargarlo desde Internet. Sólo queda activar las dos etapas de Windows Update en la secuencia (Pre y Post), pues están desactivadas por defecto:
Otro enfoque consiste en desplegar totalmente un equipo, configurarlo completamente instalando por ejemplo las aplicaciones y las actualizaciones, y a continuación capturarlo con Lite Touch. Ésta será su imagen de referencia, que le bastará para desplegar haciendo un sysprep. Sysprep permite hacer único un equipo, en lo que respecta a su nombre y su SID (Security IDentifier). Por este motivo no puede asociarlo a un dominio Active Directory durante la fase de captura. La fase de sysprep se incluye automáticamente en MDT (fase Copy sysprep files). Un aspecto que requiere especial atención durante una captura con Lite Touch es el uso del antivirus, que puede presentar problemas. La migración de perfiles de usuario se realiza mediante el componente USMT (User State Migration Tool). No es necesario instalarlo en el servidor de despliegue. USMT 5.0 incluye WADK 1.0. MDT ofrece la posibilidad de inventariar todas las máquinas desplegadas en una base de datos SQL Server. Si lo desea, puede utilizar una base de datos SQL Express 2012. Esta versión de SQL Server es gratuita y basta para cubrir esta necesidad. Puede descargarla desde la página Web de Microsoft: http://www.microsoft.com/eses/download/details.aspx?id=29062
3. WDS La instalación del rol WDS es muy sencilla. Como requisito previo debe disponer de los servicios DNS y DHCP sobre la red, así como una partición NTFS para el almacenamiento. Para instalar el rol puede utilizar el Administrador del servidor o hacerlo directamente mediante el cmdlet PowerShell siguiente: Install-WindowsFeature -Name WDS -IncludeAllSubFeature -IncludeManagementTools
Se instalan tres componentes: • •
•
Servidor de despliegue: se trata del componente principal. Servidor de transporte: este componente puede instalarse solo en un entorno restringido (sin Active Directory, DHCP, DNS...). También lo utiliza el componente principal. Herramientas de los servicios de despliegue de Windows: componentes de administración.
Una vez instalado el rol, puede gestionar WDS mediante PowerShell o mediante la interfaz de gestión que se encuentra en el menú de inicio de Windows, Servicios de implementación de Windows. Despliegue el árbol hasta llegar a su servidor y seleccione Configurar el servidor. Seleccione, a continuación, una carpeta para almacenar las imágenes (%systemdrive%\RemoteInstall, por defecto). El volumen de esta carpeta puede llegar a ser importante, y aparece una alerta si se está utilizando la partición de sistema. Si es necesario, es posible reducir en caliente el volumen desde el administrador de discos, para disponer de un lector dedicado a este almacenamiento. WDS puede restringirse para responder únicamente a clientes conocidos. Para que un cliente sea conocido, es preciso que esté incluido en el Active Directory previamente, o que se haya creado un objeto equipo manualmente en Active Directory con el identificador correcto. El identificador utilizado se visualiza durante el arranque del equipo cliente, en el momento de la búsqueda de PXE (GUID). También es posible tener un modo de aprobación, donde el administrador visualiza las peticiones de los clientes desconocidos en espera.
El modo multicast es el mejor adaptado para realizar un despliegue masivo. Evita el tener que inundar la red enviando todos los bytes de forma individual a cada equipo. En su lugar, los equipos se inscriben en la dirección multicast, y WDS envía los datos una sola vez a esta dirección para todos los equipos. Tratándose de multicast IGMP, es necesario que sus equipos de red soporten esta característica. Si no es el caso, el switch las procesará como difusiones, e inundará toda la red. Si llegan nuevos equipos durante el despliegue, comenzarán a recuperar los datos enviados hasta el final y, a continuación, WDS enviará los datos restantes a estos equipos, que serán capaces de recibir los datos de forma desordenada. Además del ahorro en ancho de banda, el servidor será capaz de desplegar más máquinas a la vez puesto que sólo lee una vez los datos de despliegue. Esto reduce de forma importante los accesos al almacenamiento en disco. Es posible visualizar la lista de máquinas en curso de despliegue así como su consumo de red en la consola WDS:
En Windows 2008 (y no 2008 R2), la velocidad de despliegue del conjunto de máquinas es igual a la velocidad de despliegue de la máquina más lenta. Si, por ejemplo, todas las máquinas son rápidas salvo una, esto impedirá a las demás desplegarse más deprisa. El servidor transmite los paquetes de red una única vez, y por ello debe esperar a que estén todas listas para recibir el próximo paquete. En la ventana que se muestra a continuación, la columna Velocidad de transferencia permite determinar la velocidad de cada máquina durante el despliegue. Si una máquina es claramente más lenta que las demás, puede cambiar su modo de despliegue por compartición de archivo, para que no ralentice a las demás. Para ello, basta con hacer clic con el botón derecho en la máquina y seleccionar la opción Ignorar multidifusión:
En cambio, Windows Server 2012 R2 permite clasificar automáticamente en dos o tres categorías los equipos (rápido, medio, lento). El servidor tendrá, al final, que enviar 2 ó 3 veces los datos, pero esto permitirá realizar un despliegue de equipos más rápido. La transmisión por multidifusión, creada por defecto por MDT 2013, es de tipo automático. Es decir el despliegue comienza cuando un cliente solicita una multidifusión. WDS permite no obstante también realizar una multidifusión planificada. Esta planificación puede realizarse en base a dos criterios: • •
el número de clientes en espera de un despliegue; una fecha y una hora para lanzar el despliegue.
Es posible utilizar ambos criterios al mismo tiempo. Si no está seleccionado ninguno de los dos, será preciso iniciar la multidifusión de forma manual. Incluso si se trata de un despliegue planificado, también es posible realizar un arranque manual. A diferencia de la versión anterior de WDS, que necesitaba la copia completa de la imagen WIN o VHD en el puesto cliente antes de instalarla realmente durante un despliegue, la versión WDS de Windows Server 2012 R2 permite instalarla directamente durante la difusión de la imagen. Esto permite, en particular, acelerar el despliegue y la instalación limitando el espacio en disco necesario en el puesto cliente. WDS es compatible con la multidifusión IPv4, y también con IPv6; para ello tendrá, obligatoriamente, que configurar el servicio DHCPv6. Con la versión WDS de Windows Server 2012 R2, las BIOS de tipo UEFI (Unified Extensible Firmware Interface) de los puestos clientes de 32 bits se gestionan para su arranque en red (Boot on LAN) y para el despliegue. Además de con las arquitecturas x86 y x64, WDS es compatible, también, con las arquitecturas ARM para Windows RT (versión de Windows 8 para tabletas con procesadores ARM).
Con Windows Server 2012, WDS es compatible con imágenes con los formatos .WIM, .VHD y .VHDX para el despliegue. Fuera del marco de uso de MDT, WDS para Windows Server 2012 permite: • •
Administrar controladores para imágenes Windows 7, Windows 8, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 y Windows Server 2012 R2. Arrancar directamente sobre imágenes VHD o VHDX.
Puede, también, gestionar WDS mediante cmdlets PowerShell. La lista de cmdlets PowerShell para WDS está disponible en el sitio Technet en la siguiente dirección: http://technet.microsoft.com/library/dn283416.aspx
Para ir más allá... El despliegue de sus servidores constituye el primer bloque técnico. A continuación queda por automatizar la instalación de sus aplicaciones, tarea que puede revelarse larga y complicada. La virtualización crea una nueva necesidad: el despliegue a la carta de entornos. Ya no se trata de realizar una configuración manual en este contexto.
1. Microsoft Application Compatibility Toolkit Esta herramienta le va a permitir resolver incompatibilidades no sólo con Windows Server 2012 R2 y Windows 8.1, sino también con Windows Vista, Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2 y Windows Server 2012. Las incompatibilidades se clasifican, generalmente, en: • •
Elevación de privilegios (UAC). Intentos de escribir en %ProgramFiles%.
Para descargarla gratuitamente, visite la página: http://www.microsoft.com/enus/download/details.aspx?id=7352 Si no puede modificar la aplicación, siempre podrá implementar shims para modificar al vuelo las llamadas que causen problemas durante la ejecución. La palabra shim designa una biblioteca que convierte la llamada de una API en otra. El programa Compatibility Administrator permite visualizar los shims utilizados por Microsoft para hacer compatibles hasta 348 aplicaciones. Para conseguirlo, hay disponibles 118 shims. Agregando el argumento -x al siguiente programa, existen 242 shims disponibles. Por defecto, están ocultas, pues raramente son necesarias. También es posible "hacer creer" a la aplicación que el sistema operativo es Windows XP, o que Internet Explorer 6 está presente. Los desarrolladores tienen tendencia a realizar verificaciones bloqueantes para estar seguros de que no habrá ningún problema, mientras que la mayoría de veces no existe ninguna incompatibilidad probada. Una vez la aplicación es compatible con Windows 8.1 o
Windows Server 2012 R2, habrá que instalar la base de datos sobre las máquinas que la utilicen. Para facilitar el diagnóstico, el programa Standard User Analyzer Wizard le guía paso a paso en: • • •
La preparación antes de la ejecución. La ejecución de la aplicación, realizando todas las acciones que presenten problemas. El análisis y la propuesta de shims.
2. Entorno a la carta El despliegue de máquinas virtuales puede consumir mucho tiempo, especialmente si se trata de entornos a la carta para proyectos de desarrollo. Podrá crear una secuencia para sus entornos virtuales con el objetivo de instalar automáticamente las herramientas adicionales. Hyper-V, que es compatible con el arranque PXE, le permite instalar máquinas virtuales directamente a través de la red con WDS. De este modo tendrá un único punto central que contendrá todas las imágenes y aplicaciones durante el despliegue, en vez de tener una imagen a parte para la generación de máquinas virtuales.
3. ImageX ImageX es una herramienta que funciona por línea de comandos y le permite administrar y modificar las imágenes WIM. El formato WIM tiene en particular una propiedad interesante: se basa en archivos y no en clústeres, como para los formatos ISO. Esto permite en especial almacenar en la imagen un único ejemplar de cada archivo, incluso si está presente varias veces desde el punto de vista lógico (Single Instance Storage). Esta herramienta acepta los siguientes argumentos: • • • • • • • • • • •
APPEND: combina dos imágenes. APPLY: aplica una imagen a una carpeta. CAPTURE: captura una partición en una imagen wim. DELETE: borra un volumen en un archivo wim. DIR: enumera los archivos contenidos en un archivo wim. EXPORT: copia un volumen desde un archivo wim a otro. INFO: muestra la descripción XML de un archivo wim. SPLIT: separa un archivo wim en dos archivos wim separados. MOUNT: monta un archivo wim en una carpeta, en modo sólo lectura. MOUNTRW: monta un archivo wim en una carpeta, en modo lectura/escritura. UNMOUNT: desmonta un archivo wim de una carpeta.
Esta herramienta es útil si desea modificar la imagen generada por MDT.
Por ejemplo, para montar la imagen WIM Lite Touch en una carpeta, es necesario ejecutar el comando: imagex /mount D:\images\LiteTouchPE_x64.wim 1 c:\wim_temp
El ejecutable ImageX se encuentra en distintos lugares: • • •
En la carpeta Deployment Tools\amd64\DISM del directorio de instalación de Windows ADK. En la carpeta Tools\PeTools del directorio de instalación de Windows AIK. En X:\Deploy\Tools\x86 o X:\Deploy\Tools\x64 desde el entorno de inicio de Windows PE construido con MDT.
4. DISM (Deployment Image Servicing and Management) Esta herramienta, que se ofrece de forma estándar con Windows 8.1 y Windows 2012 R2, aunque también con Windows PE 4.1, combina las funciones antes mencionadas: • • • • •
Montaje de archivos WIM. Personalización de imágenes de inicio de Windows PE. Inyección/supresión de controladores. Activación/desactivación de componentes de Windows. Administración de la configuración regional.
Es una herramienta complementaria a ImageX que permite configurar la imagen. Su único punto en común es poder montar imágenes WIM.
5. Zero touch con SCCM 2012 R2 El uso de System Center Configuration Manager R2 permite automatizar por completo el despliegue de equipos. Desde la consola SCCM, usted podrá programar directamente y efectuar despliegues sobre equipos existentes, sin tener que desplazarse hasta la máquina para arrancar en PXE y seleccionar la secuencia.
6. Unirse al dominio sin red Desde Windows 7 y Windows Server 2008 R2, es posible unir una máquina a un dominio AD sin que tenga que unirse a un controlador de dominio durante todo el procedimiento. Esto abre nuevas perspectivas, como hemos visto en el capítulo dedicado al Dominio Active Directory: • • • •
Desplegar máquinas virtuales o no en gran cantidad, evitando el reinicio. Unir una máquina al dominio aunque no tenga red en ese momento. Simplificar el procedimiento cuando el controlador de dominio es de tipo RODC. Limitar los contratiempos y mejorar el diagnóstico cuando se produce un error o incidente de red durante un despliegue.
El procedimiento se desarrolla en dos tiempos: • •
Preparar el Active Directory inicializando el objeto equipo con el comando djoin. El resultado es un archivo de texto que hay que conservar (testigo). Inyectar el archivo anterior en el equipo de destino con djoin. Es posible copiar el archivo mientras la máquina está detenida. Durante el arranque, será miembro del dominio sin necesidad de un reinicio posterior.
El comando que debe utilizar es djoin. Necesita, como mínimo, Windows 7 o Windows Server 2008 R2 instalado en el equipo que prepara el Active Directory y sobre la máquina que se va a unir al dominio sin red. El controlador de dominio puede estar configurado con alguna versión anterior a Windows Server 2008 R2 (utilizando el argumento /downlevel de djoin). He aquí el comando que permite preparar el equipo SRV01:
He aquí el comando que permite unir la máquina al dominio:
7. ¿Qué hacer si ocurre algún problema? La informática está llena de sorpresas que condimentan nuestro trabajo cotidiano. Cuando un despliegue no se realiza según lo previsto, he aquí algunas trazas que pueden proporcionarle ayuda: • • • •
Si ocurre un problema uniendo el equipo al dominio: %WINDIR%\Debug\netsetup.log Si ocurre un problema con algún controlador: %WINDIR%\inf\Setupapi.dev.log Si ocurre un problema durante la instalación: %WINDIR%\panther\Setupact.log y Setuperr.log Mensaje de error "Multiple connections to a server or shared resource by the same user": Este mensaje aparece cuando una secuencia utiliza una cuenta para conectarse a un recurso compartido MDT diferente del definido en customsettings.ini. El equipo de producto de MDT provee, en su blog, las modificaciones que es necesario realizar (ztiutility.vbs): http://blogs.technet.com/msdeployment/archive/2009/09/18/fix-formultiple-connections-to-a-server-or-shared-resource-by-the-same-user-using-morethan-one-user-name-are-not-allowed-problem-with-mdt-2010.aspx
Conclusión Ya está preparado para desplegar sus servidores y puestos de trabajo. Desde un punto de vista técnico, nunca había sido tan sencillo y flexible, en especial con MDT 2013. ¡Seguir haciendo instalaciones a mano sería una verdadera pérdida de tiempo y de calidad!
Introducción Este capítulo tiene como objetivo permitir abordar la seguridad de su arquitectura de la mejor forma. En efecto, no es raro escuchar a los profesionales de la informática expresarse en términos algo arcaicos acerca de la seguridad. Se trata de un área que evoluciona muy regularmente y muy rápido, y no sería razonable pensar que la arquitectura informática y las soluciones en términos de seguridad están actualizadas. Conviene estar informado regularmente y respetar un conjunto de buenas prácticas. Este capítulo está dedicado a describir las buenas prácticas al respecto y le presenta las novedades funcionales que le permitirán ponerlas en marcha.
Principio de privilegio mínimo El principio de privilegio mínimo es, como su propio nombre indica, un principio que consiste en ejecutar cada tarea con una cuenta de usuario que tenga exactamente los permisos necesarios para completar dicha tarea. En la práctica, esto no siempre es factible, aunque conviene hacer siempre todo lo posible para estar lo más cerca posible de la necesidad reduciendo al máximo la superficie de ataque expuesta. Si un usuario no necesita permisos específicos, ¿por qué asignárselos? Y, ¿cómo asegurarse que el usuario no tiene más derechos de los que le hacen falta? La superficie de ataque será mucho más reducida si actualiza, de manera regular, su parque informático tanto a nivel de sistema operativo como de aplicaciones instaladas, sin olvidar a los equipos de red. El capítulo El ciclo de vida de su infraestructura aborda, en particular, el uso de WSUS (Windows Server Update Services) para desplegar actualizaciones en sus sistemas Windows. Un parque informático actualizado regularmente, con permisos de usuario bien definidos, le protegerá de numerosos ataques. Es preciso dominar algunas nociones técnicas para poder realizar la mejor elección en cada caso.
1. Los distintos tipos de cuenta En Windows existen distintos tipos de cuentas de usuario. Cada uno de ellos define un conjunto de permisos tales como el acceso a los archivos, las modificaciones que está autorizado a realizar en el sistema operativo, etc. Desde un punto de vista genérico, según el tipo de cuenta seleccionado, el usuario tendrá un nivel de acceso más o menos importante en el sistema operativo. Existen tres categorías principales de cuenta de usuario: • • •
Invitado Estándar Administrador
Cuenta de usuario invitado Una cuenta de usuario con permisos de tipo Invitado autoriza el acceso a los recursos del equipo sin autenticación en este último. Este tipo de cuenta se utiliza de manera muy esporádica en la empresa, pues presenta riesgos no despreciables en términos de seguridad. Por defecto, este tipo de cuenta está deshabilitado. Cuenta de usuario estándar Una cuenta de usuario estándar permite utilizar la mayor parte de las funcionalidades del sistema operativo mientras no afecten a la seguridad del equipo o a la configuración común a todos los usuarios. La principal diferencia entre una cuenta de usuario estándar y una cuenta de administrador es el nivel de acceso del usuario a los lugares definidos como protegidos en el sistema operativo. Cuenta de administrador Una cuenta de usuario con permisos de Administrador (y que por lo tanto forme parte, de forma directa o no, del grupo Builtin\Administradores del equipo) está autorizado a administrar la totalidad del sistema operativo y, por tanto, a definir configuración común a todos los usuarios (instalación de programas, definición de la seguridad del equipo, etc.). En la medida en que los permisos de esta cuenta son muy extensos, se desaconseja encarecidamente utilizarla para sus tareas corrientes. Verá más adelante, en este mismo capítulo, cómo Microsoft responde a la necesidad de dotar de seguridad este acceso de Administrador gracias al UAC (User Account Control). Por ejemplo, un usuario estándar no puede, por defecto, escribir en la carpeta de sistema (C:\windows) o en la mayor parte del registro, mientras que un administrador sí puede
hacerlo. Un administrador puede también activar/desactivar el firewall, configurar las políticas de seguridad, instalar un servicio o un controlador para todos los usuarios, etc. Desde Windows Vista y Windows 2008, Microsoft ha mejorado bastante las cuentas de usuario estándar, y ahora pueden realizar tareas que necesitan permisos de administrador tales como: • • • • • •
Ver el reloj de sistema, el calendario y modificar el huso horario. Modificar los parámetros de visualización y las fuentes instaladas. Modificar las opciones de alimentación. Agregar impresoras y otros dispositivos. Agregar y configurar conexiones VPN. Definir una clave WEP/WPA para una red inalámbrica.
Existen tareas programadas suplementarias que permiten, en lo sucesivo, definir una tarea de defragmentación o de copia de seguridad automática. Antes, estas funcionalidades no podían realizarse fácilmente y necesitaban, en su mayoría, privilegios de usuario administrador. He aquí una lista no exhaustiva de los distintos permisos para un usuario estándar y un administrador, que le permitirá situar un poco mejor las autorizaciones de cada tipo de cuenta. Usuarios estándar
Administradores
Establecer una conexión de red.
Instalar/desinstalar aplicaciones.
Establecer una inalámbrica.
conexión
de
red Instalar el controlador de un dispositivo.
Cambiar la configuración de pantalla.
Instalar actualizaciones de Windows.
Defragmentar el disco duro (mediante Configurar el control parental. un servicio). Leer un CD/DVD.
Instalar un control ActiveX (incluso si ha evolucionado poco con la presencia del servicio de Control ActiveX desde Windows 7).
Grabar un CD/DVD.
Configurar el firewall.
Modificar el fondo de pantalla.
Modificar el tipo de cuenta de un usuario.
Acceder a la fecha y hora del sistema y Modificar los parámetros UAC. modificar el huso horario. Utilizar el escritorio remoto para Configurar el acceso al escritorio remoto. conectarse a equipos remotos. Configurar las opciones alimentación de la batería.
de Crear o eliminar una cuenta de usuario.
Configurar las accesibilidad.
opciones
de Copiar o mover archivos en las carpetas Program Files o Windows.
Restaurar los archivos de copia de Definir tareas programadas. seguridad de usuario. Definir una sincronización entre un Restaurar la copia de seguridad de dispositivo portátil y el equipo archivos de sistema. (smartphone, ordenador portátil, PDA (Personal Digital Assistant). Conectar y configurar un dispositivo Configurar el servicio de actualizaciones Bluetooth. automáticas. Existe un cuarto tipo de cuenta que se utiliza a menudo en entornos como Windows 2000/XP. Se trata de cuentas que pertenecen al grupo de Usuarios avanzados. Este grupo está a medio camino entre Usuarios y Administradores. Permite, en efecto, realizar algunas tareas como, por ejemplo, escribir en ciertos lugares del registro y del sistema de archivos, sin necesidad de tener permisos de administrador. Este tipo de grupo no responde a todas las necesidades de las aplicaciones y ya no tiene ningún permiso particular por defecto desde Windows Vista y Windows 7. Conviene saber, no obstante, que este grupo sigue estando disponible con el objetivo de asegurar la compatibilidad de las aplicaciones que lo necesitan. Para ello, es necesario cargar un modelo de seguridad particular (compatws.inf) en Windows Vista y Windows 7 para modificar los permisos sobre ciertos archivos y ciertas claves del registro para permitir al grupo Usuarios avanzados tener acceso. Windows Server 2012 R2 propone utilizar un nuevo grupo de dominio que permite habilitar una protección suplementaria en aquellos equipos que utilizan Windows Server 2012 R2 o Windows 8.1. Este grupo se encuentra en los controladores de dominio de Windows Server 2012 R2 y se llama Protected Users. Los miembros de este grupo sólo pueden utilizar métodos de autenticación considerados como seguros para poder autenticarse. De este modo, los miembros de este grupo están sometidos a las siguientes condiciones: •
•
• •
No pueden autenticarse utilizando NTLM, Digest o incluso CredSSP. Por otro lado, las contraseñas de las cuentas miembros de este grupo no están almacenadas en caché si se utilizan en un equipo Windows 8.1 miembro del dominio. El protocolo Kerberos es el único protocolo autorizado y no puede basarse en un cifrado DES o RC4 (débiles) para el proceso de pre-autenticación. Sólo es posible utilizar el protocolo AES. La delegación Kerberos no está permitida. El tiempo de vida del ticket Kerberos (TGT) se puede modificar (por defecto, 4 horas) e implica una reautenticación por parte del usuario, pasado este tiempo.
Para poder aprovechar las ventajas de este grupo, debe actualizar su esquema de Active Directory (mediante el comando adprep /forestprep), de cara a poder soportar las nuevas clases incluidas en Windows Server 2012 R2 y el controlador de dominio que
alberga el rol de emulador PDC debe funcionar, como mínimo, con Windows Server 2012 R2. Existe una novedad, llamada Directiva de silos de autenticación que le permite controlar los equipos en los que un usuario puede iniciar sesión en el dominio. Si se acopla esta funcionalidad con el grupo de tipo Protected Users, es posible aplicar condiciones de control del acceso para la autenticación de cuentas. Las directivas de autenticación se fuerzan en la etapa de intercambio de información de AS y TGT de los tickets Kerberos. Los requisitos previos son los mismos que para los Protected Users, es preciso agregar un nivel funcional del dominio Windows Server 2012 R2. Esta directiva puede aplicarse a las cuentas de Equipos, Usuarios y a las cuentas de servicio administradas.
2. El control de cuentas de usuario El control de cuentas de usuario o User Account Control (UAC) es uno de los principales avances de la nueva gama de sistemas operativos Microsoft Windows Vista y Windows Server 2008. Esta funcionalidad (activada, por defecto) permite informarle de cualquier acción que requiera permisos del sistema. Se crea un token de acceso completo, con los permisos más importantes del usuario, y se le pasa a la aplicación. Esto se llama una elevación de privilegios. El UAC se caracteriza por una elevación de privilegios automática, apareciendo un mensaje de advertencia cuando se produce esta elevación, y un escritorio securizado dedicado a este mensaje de advertencia. De este modo, será mucho más complicado para un programa espía instalarse en el sistema o acoplarse a un proceso sin informarle antes. En adelante, es sencillo identificar aquellas tareas que precisarán permisos más importantes. El icono con forma de escudo asociado a ciertas aplicaciones y asistentes de configuración indica que estas tareas se ejecutarán con permisos de administrador del equipo.
Para las demás aplicaciones, aparecerá un mensaje de elevación de privilegios si fuera necesario.
Observe que la visualización de la ventana de elevación de privilegios aparece con menos frecuencia desde Windows 7/2008 R2, en particular tareas "seguras" tales como la
instalación de actualizaciones o de controladores descargados desde Windows Update, la visualización de la configuración de Windows o incluso las herramientas de diagnóstico de la tarjeta de red. Antes de que realizar la elevación de privilegios, Windows Server 2012 R2 muestra, por defecto, la ventana de confirmación solicitando esta elevación de privilegios a un escritorio virtual aislado (llamado también "Escritorio difuminado" desde Windows 7/2008 R2) y securizado, de forma que el resto de aplicaciones continúe ejecutándose a nivel del escritorio interactivo del usuario. Esto permite poder impedir a un proceso de usuario (como, por ejemplo, una aplicación espía) interactuar con la solicitud de elevación de privilegios y aceptar automáticamente la elevación. La ventana de petición de elevación para el proceso en cuestión se encuentra por tanto en un entorno hermético. De este modo, si un atacante elige crear un ejecutable que permite reproducir con exactitud la ventana de elevación de privilegios, no la ejecutará porque su visualización no se realizará en un escritorio virtual. Del mismo modo, el escritorio securizado impide los ataques que consisten en trucar la posición del puntero del ratón. El atacante puede en efecto modificar la visualización del ratón de modo que cuando el usuario piensa que está haciendo clic en Cancelar, la acción del clic del ratón se realiza sobre el botón Continuar permitiendo así ejecutar la aplicación peligrosa. El escritorio virtual permite bloquear este tipo de ataque. Por otro lado, existe un modo particular llamado Modo de aprobación de administrador que está activo para todos los miembros del grupo de Administradores (salvo la cuenta Administrador integrado). Este modo muestra la elevación de privilegios cuando se ejecuta una aplicación que necesita privilegios de administración. Desde Windows Server 2008 R2, es posible tener una granularidad más precisa del UAC para limitar las peticiones de la contraseña. Esto se detalla más adelante. Es posible configurar los distintos parámetros en el Panel de control o mediante una directiva de grupo (también local o de dominio). Para ello, abra su editor de directivas, y diríjase al nivel Configuración del equipo - Directivas - Configuración de Windows Configuración de seguridad - Directivas locales - Opciones de seguridad. Las directivas relativas a la gestión del UAC son las siguientes: Control de cuentas de usuario: modo de aprobación de administrador para la cuenta predefinida Administrador Descripción: permite definir si la cuenta de Administrador integrada se somete al Modo de aprobación de administrador o no. Valor por defecto: Deshabilitado.
Control de cuentas de usuario: cambiar al escritorio seguro cuando se pida confirmación de elevación Descripción: indica si la petición de elevación de privilegios debe realizarse en el escritorio de los usuarios interactivos o en un escritorio virtual securizado. Valor por defecto: Habilitado. Control de cuentas de usuario: permitir que las aplicaciones UIAccess soliciten la elevación sin usar el escritorio seguro Descripción: los programas UIAccess como el asistente remoto pueden solicitar utilizar esta opción. Valor por defecto: Deshabilitado. Control de cuentas de usuario: comportamiento de la petición de elevación para los administradores en Modo de aprobación de administrador Descripción: define a si un usuario conectado con una cuenta de administrador se le muestra una ventana de elevación de privilegios durante la ejecución de aplicaciones que requieran permisos de administrador. Existen seis opciones posibles: • • •
Elevar sin preguntar: la elevación se produce automáticamente y de forma silenciosa (sería inútil indicarle que esta opción no está recomendada). Pedir consentimiento: requiere una intervención del usuario para Continuar o Anular la operación de elevación de privilegios. Pedir credenciales: se solicita un nombre de usuario y una contraseña durante la petición de elevación de privilegios.
Valor por defecto: Pedir consentimiento. •
• •
Pedir consentimiento en el escritorio seguro: requiere una intervención del usuario en el escritorio securizado para Continuar o Anular la operación de elevación de privilegios. Pedir credenciales en el escritorio seguro: se solicita un nombre de usuario y una contraseña en el escritorio securizado durante la elevación de privilegios. Pedir consentimiento para ejecutables que no son de Windows: requiere una intervención del usuario para Continuar o Anular la operación de elevación de privilegios para una aplicación no firmada por un certificado de Microsoft.
Valor por defecto: Pedir consentimiento para ejecutables que no son de Windows.
Control de cuentas de usuario: comportamiento de la petición de elevación para los usuarios estándar Descripción: define si un usuario conectado con una cuenta estándar obtiene una ventana de elevación de privilegios de ejecución de aplicaciones que requieren permisos de administrador. Por defecto, un usuario estándar tendrá la posibilidad de indicar la contraseña de una cuenta de administrador. También es posible deshabilitar esta opción, aunque no impide al usuario hacer clic con el botón derecho del ratón sobre el ejecutable y seleccionar la opción Ejecutar como administrador. Valor por defecto: Pedir credenciales. Control de cuentas de usuario: detectar instalaciones de aplicaciones y pedir confirmación de elevación Descripción: cuando está habilitado, el usuario debe dar su consentimiento cuando Windows detecta un programa de instalación. No se aconseja aplicar este parámetro en entornos de empresa si el usuario no tiene permisos de administrador o si ya existe una aplicación para la distribución remota. Valor por defecto: Habilitado. Control de cuentas de usuario: elevar sólo aplicaciones UIAccess instaladas en ubicaciones seguras Descripción: indica que sólo las aplicaciones que requieran un nivel de integridad UIAccess (es decir especificando UIAccess=true en su manifiesto de aplicación) deben encontrarse en un emplazamiento seguro en el sistema de archivos. Los emplazamientos seguros son: • • •
\Program Files\ (y subcarpetas) \Program Files (x86)\ (y subcarpetas) \Windows\System32
Valor por defecto: Habilitado. Control de cuentas de usuario: elevar sólo los archivos ejecutables firmados y validados Descripción: sólo los ejecutables firmados y validados mediante un certificado tendrán la autorización para elevar sus privilegios. La lista de aplicaciones de administración puede controlarse por este medio. Valor por defecto: Deshabilitado.
Control de cuentas de usuario: ejecutar todos los administradores en Modo de aprobación de administrador Descripción: permite activar o desactivar el control de usuario para los usuarios que son Administradores. Valor por defecto: Habilitado. Control de cuentas de usuario: virtualizar los errores de archivo y escritura de Registro por ubicaciones de usuario Descripción: esta opción asegura la compatibilidad con las antiguas aplicaciones que se ejecutaban como administrador y escribían sus datos de ejecución de la aplicación en %Program Files%, %Windir%, %Windir%\System32 o HKLM\Software. Valor por defecto: Habilitado.
Si utiliza una autenticación biométrica, sepa que Windows Server 2008 R2/2012 R2 permite simplificar la elevación de privilegios solicitada por el UAC mejorando la experiencia de usuario. Su dispositivo biométrico estará mejor gestionado en Windows Server 2008 R2/2012 que en las versiones anteriores y podrá utilizar este medio de autenticación sin tener que disponer necesariamente de una aplicación dedicada instalada a partir del momento en que el driver descargado mediante Windows Update haya sido instalado. Aunque es una fuente frecuente de controversia, pues modifica nuestros (¿malos?) hábitos, UAC permite asegurar un nivel de seguridad muy superior comparado con las versiones anteriores de Windows. Sus mejoras, evidentes deberían, en lo sucesivo, animarle a adoptarlo rápidamente, si no lo ha hecho aún.
3. Administrar grupos con ayuda de grupos restringidos Los grupos restringidos le permiten administrar los miembros de grupos de seguridad con el objetivo de asegurar el contenido de estos grupos. Esta configuración es muy interesante y permite controlar mejor las personas y permisos asignados a un conjunto de equipos y servidores miembros. Los grupos restringidos se configuran únicamente a nivel de directivas de dominio. No encontrará esta configuración en el nivel de una directiva local. Se encuentra en Configuración del Equipo - Directivas - Configuración de Windows - Configuración de seguridad - Grupos restringidos.
La principal ventaja, como habrá comprendido, consiste en bloquear los miembros definidos a nivel de Miembro y Miembros de... del grupo definido como grupo restringido. De este modo, si por ejemplo se retira manualmente a un usuario de un grupo definido como grupo restringido, se agregará automáticamente a éste tras la aplicación de la directiva de grupo (cada 90 minutos aproximadamente). Antes de configurar un grupo restringido, conviene comprender bien la diferencia entre el parámetro Miembro de este grupo y Este grupo es miembro de. Configurando, por ejemplo desde la directiva de grupo, un grupo restringido como el grupo local de los equipos llamado BUILTIN Administradores (haciendo clic con el botón derecho del ratón en la directiva de los grupos restringidos y, a continuación, en Agregar un grupo - Builtin\Administradores) e indicando un grupo de dominio como, por ejemplo, MiEmpresa\AdminLocal en Miembros de este grupo, entonces todos los usuarios del grupo MiEmpresa AdminLocal serán Administradores de los equipos que se encuentran en el contenedor asociado a la directiva de grupo definida. ¡Perfecto! ¿Está seguro? No tanto... Imagine que este grupo restringido se define a nivel de los equipos de su Active Directory y que un usuario necesita ser miembro del grupo Administradores de su equipo (no es raro que los usuarios de equipos portátiles tengan este tipo de necesidad). Asociándolo al grupo MiEmpresa\AdminLocal el usuario será, en efecto, miembro del grupo BUILTIN\Administradores de su equipo, ¡pero también de todos los demás equipos!
Del mismo modo, si trata de agregar este mismo usuario de forma local al grupo BUILTIN\Administradores de su equipo, la aplicación de la directiva de grupo tendrá como efecto la limpieza de los miembros de los grupos locales y en consecuencia el usuario perderá los permisos de administrador. Como habrá comprendido, este tipo de configuración está poco adaptado a la definición de los miembros de los grupos a nivel de puestos de trabajo, aunque puede ser muy interesante para controlar los miembros de los grupos de servidores y controladores de dominio para bloquear estos últimos. Volviendo a nuestro usuario que quiere ser administrador de su equipo haciendo uso de los grupos restringidos, y sin que impacte a la seguridad de los demás equipos, conviene definir los grupos restringidos de forma ligeramente diferente. En efecto hace falta definir un grupo restringido a partir del grupo de dominio seleccionado (en nuestro ejemplo el grupo MiEmpresa\AdminLocal) y definir la configuración Este grupo es miembro de: para agregar el grupo BUILTIN\Adminis- tradores (o BUILTIN\Administrators dependiendo de si esta directiva de grupo se define en un equipo en castellano o en inglés).
De este modo, el grupo MiEmpresa\AdminLocal tiene su atributo IsMemberOf bloqueado y los usuarios que forman parte de este grupo son efectivamente miembros del
grupo Administradores de todos los equipos aunque esto impida que un usuario equis pueda ser administrador de su equipo. La administración de grupos representa, a día de hoy, un verdadero desafío para nuestros Sistemas de Información y la seguridad, ambos en pleno despegue, los grupos restringidos responden en gran medida a esta necesidad de dotar de seguridad al puesto de trabajo.
4. AppLocker o el control de las aplicaciones Applocker es una funcionalidad que ha hecho aparición en Windows 7 (en su edición Enterprise e Ultimate) y Windows Server 2008 R2 con el objetivo de reemplazar a las directivas de restricción de aplicaciones de las versiones anteriores de Windows. Como con las directivas de restricción de software, Applocker permite definir las aplicaciones autorizadas a ejecutarse por parte de sus usuarios estándar en el seno de su dominio desplegando sus parámetros mediante directivas de grupo. El interés principal es limitar la instalación de malwares en los puestos de trabajo pero también impedir la instalación de programas no conformes o que requieren una licencia que no posee, etc. Esta funcionalidad se aplica, principalmente, en puestos cliente con Windows 7/8/8.1 Enterprise, aunque también puede ser interesante auditar y limitar los ejecutables lanzados en Windows Server 2008 R2 y Windows Server 2012/2012 R2. Applocker presenta varias ventajas en comparación con las directivas de restricción de software: •
• • •
La definición de reglas más precisas basadas en el fabricante (mediante firma electrónica del archivo y de sus atributos extendidos tales como el fabricante, el nombre, el nombre del producto y/o el nombre del archivo). De este modo es posible por ejemplo autorizar únicamente un programa que provenga de un fabricante concreto y a partir de una versión específica (como, por ejemplo, autorizar únicamente el uso de Office 2003 (versión 11.0.0.0) o superior). La posibilidad de definir reglas para usuarios o grupos específicos. La posibilidad de importar y exportar reglas. La posibilidad de identificar los efectos laterales de una regla activando el modo de auditoría.
Sepa, también, que si una directiva de grupo posee a la vez una directiva de restricción de software y una directiva de control de aplicación (Applocker), sólo se aplicará la directiva Applocker en el puesto. Por lo tanto, si posee un parque informático heterogéneo compuesto de equipos clientes Windows 7/8/8.1 y equipos clientes Windows XP, tendrá que crear dos directivas de grupo
distintas. Una directiva de restricción de aplicación para los clientes Windows XP, y una directiva de control de aplicación (AppLocker), para los clientes con Windows 7/8/8.1. Si todos los equipos clientes están en la misma OU, es posible utilizar filtros WMI sobre ambas GPO para filtrar sobre qué tipo de sistema operativo se deben ejecutar. Las buenas prácticas de seguridad recomiendan prohibir, explícitamente, la ejecución de archivos ejecutables en carpetas conocidas y habitualmente utilizadas por virus y demás malwares. Si aplica las restricciones en las siguientes carpetas, disminuirá sensiblemente el riesgo de que un virus se ejecute con éxito en sus equipos. El método, sin ser infalible, sí cubre un espectro bastante importante de procedimientos utilizados por estos programas malintencionados. Seleccione las siguientes reglas de bloqueo: Para Windows XP Bloqueo de ejecución de archivos peligrosos en %AppData% y sub-carpetas: • • • • • • • • •
%Appdata%\*.exe %Appdata%\*.sys %Appdata%\*.dll %Appdata%\*\*.exe %Appdata%\*\*.sys %Appdata%\*\*.dll C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.exe C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.sys C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.dll
Bloqueo de la ejecución de archivos peligrosos en %LocalAppData% y sub-carpetas: • • • • • •
%UserProfile%\Local Settings\*.exe %UserProfile%\Local Settings\*.sys %UserProfile%\Local Settings\*.dll %UserProfile%\Local Settings\*\*.exe %UserProfile%\Local Settings\*\*.sys %UserProfile%\Local Settings\*\*.dll
Bloqueo de la ejecución de archivos desde archivos WinRar, 7Zip, WinZip y el soporte Zip integrado en Windows: • • •
%UserProfile%\Local Settings\Temp\Rar*\*.exe %UserProfile%\Local Settings\Temp\7z*\*.exe %UserProfile%\Local Settings\Temp\wz*\*.exe
•
%UserProfile%\Local Settings\Temp\*.zip\*.exe
Para Windows Vista y versiones superiores Bloqueo de la ejecución de archivos peligrosos en %AppData% y sub-carpetas: • • • • • • • • •
%Appdata%\*.exe %Appdata%\*.sys %Appdata%\*.dll %Appdata%\*\*.exe %Appdata%\*\*.sys %Appdata%\*\*.dll C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.exe C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.sys C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.dll
Bloqueo de la ejecución de archivos peligrosos en %LocalAppData% y sub-carpetas: • • • • • •
%LocalAppData%\*.exe %LocalAppData%\*.sys %LocalAppData%\*.dll %LocalAppData%\*\*.exe %LocalAppData%\*\*.sys %LocalAppData%\*\*.dll
Bloqueo de la ejecución de archivos desde archivos WinRar, 7Zip, WinZip y el soporte Zip integrado en Windows: • • • •
%LocalAppData%\Temp\Rar*\*.exe %LocalAppData%\Temp\7z*\*.exe %LocalAppData%\Temp\wz*\*.exe %LocalAppData%\Temp\*.zip\*.exe
Veamos cómo configurar Applocker. Antes de comenzar es preciso saber que existen tres tipos de reglas posibles para evaluar si una aplicación tiene autorización para ejecutarse o no. •
Ruta de acceso: esta regla permite identificar un ejecutable basándose en una ruta. Puede, por ejemplo, definir una regla para autorizar el ejecutable C:\Windows\ calc.exe. Aunque esta solución no es la más eficaz, puesto que si un usuario renombra un ejecutable prohibido como calc.exe en la carpeta C:\Windows será capaz de ejecutar la aplicación. Es, por el contrario, un método interesante para impedir la ejecución de un tipo de extensión de archivo en una carpeta conocida por su riesgo (como, por ejemplo, la carpeta Temporal). La lista de estas carpetas peligrosas se muestra más arriba e indica también, por ejemplo, que todos los
•
•
ejecutables que se encuentren en la carpeta %LocalAppData%\*.exe no puedan ejeutarse. Hash de archivo: esta regla permite identificar un ejecutable basándose en un valor de hash calculado. Cada archivo posee un valor de hash único, Windows calcula el valor de hash de un archivo y lo compara con los valores definidos en las reglas de Applocker para saber si la regla debe o no aplicarse. El inconveniente de esta solución es que la regla debe implantarse con cada nueva versión del archivo que quiere autorizar. Publisher: esta regla permite identificar un ejecutable en función del fabricante (como era el caso con las reglas de certificado de las antiguas restricciones de software) aunque agregando condiciones más precisas como la versión del producto, etc.
Antes de crear sus propias reglas personalizadas, será necesario comenzar creando las reglas por defecto. En efecto, Applocker funciona un poco como un firewall, de modo que todo lo que no esté expresamente autorizado se rechaza. He aquí las principales etapas a seguir para implantar Applocker en su empresa. •
•
•
Generar las reglas por defecto: para evitar efectos laterales indeseados, es preciso administrar las reglas por defecto autorizando a todo el mundo a ejecutar los programas que se encuentran en las carpetas Program Files y Windows. Generar reglas automáticas: a continuación sólo tendrá que definir reglas para bloquear lo que desee. Esta forma de proceder le evitará "auto-bloquearse" en ciertas situaciones a causa de reglas mal definidas. Auditar siempre las reglas Applocker antes de su despliegue masivo en producción.
Generar las reglas por defecto Para definir sus reglas por primera vez, utilice un puesto piloto (con Windows 7/8/8.1 o 2008 R2/2012/2012 R2) que sea el único puesto presente en la unidad organizativa ligada a la directiva de grupo que va a configurar. Instale las aplicaciones homologadas o aquellas que desee autorizar. Instale a su vez las herramientas RSAT para crear la directiva y las reglas Applocker directamente desde este puesto (enseguida verá por qué razón). Siempre desde este puesto piloto, diríjase al nivel Configuración del equipo - Directivas - Configuración de Windows - Configuración de seguridad - Directivas de control de aplicaciones - Applocker. Observe que hay tres subcategorías: Reglas ejecutables, Reglas de Windows Installer y Reglas de scripts. Haga clic con el botón derecho del ratón sobre cada una de estas subcategorías para crear la regla por defecto seleccionando la opción Crear reglas predeterminadas. Esto tiene el efecto de crear reglas por defecto autorizando a "Todos los usuarios" a ejecutar los programas que se encuentran en la carpeta %PROGRAMFILES% y %WINDIR%. Habrá que tenerlo en cuenta a la hora de realizar las primeras pruebas en
producción. La prohibición prevalece sobre la autorización, y podrá Rechazar el acceso a un programa específico que se encuentre en alguna de estas carpetas.
Generar las reglas automáticas La forma más sencilla de definir las reglas para las aplicaciones existentes consiste en utilizar el asistente. Permite generar reglas según las especificidades de cada ejecutable que se encuentra en la carpeta indicada. Para ello, haga clic con el botón derecho del ratón en la categoría Reglas ejecutables y elija Generar reglas automáticamente....
Se abre un asistente que le permite indicar la carpeta a escanear, los usuarios afectados por esta regla, así como el nombre de la regla.
La siguiente etapa le permite definir las Preferencias de reglas. Es preferible seleccionar reglas de publicador antes que reglas de hash para una primera implantación. A continuación puede pasar a la etapa siguiente. Comienza, a continuación, el escaneo y se muestra el número de reglas identificadas así como el tipo de regla asociada. Tendrá la posibilidad de examinar los archivos analizados para suprimir todas o una parte de las reglas propuestas.
Haga clic en Crear para crear las reglas seleccionadas. Estas se agregarán de inmediato a la regla del ejecutable.
Auditar las reglas Applocker en los puestos de producción
El objetivo de esta etapa consiste en hacer "como si" las reglas que ha creado estuvieran implantadas en los puestos de producción, con la diferencia de que las reglas establecidas no bloquearán las aplicaciones. Se trata de una fase de aprendizaje esencial que permite identificar los principales efectos colaterales. AppLocker, para Windows Server 2012 R2 y Windows 8.1, permite escribir en el registro Seguridad información detallada acerca de los atributos solicitados por una aplicación que intenta ejecutarse. Para poder simular el despliegue de las reglas Applocker sin que estas últimas sean realmente efectivas, haga clic con el botón derecho del ratón en Applocker (en Configuración del equipo - Directivas - Configuración de Windows - Configuración de seguridad - Directivas de control de aplicaciones - Applocker) y a continuación en Propiedades. Marque, a continuación, la opción Configurado en la categoría de reglas que desee (en nuestro ejemplo Reglas de ejecutables) y seleccione Solo auditoría en la lista desplegable correspondiente.
Valide haciendo clic en Aceptar. Para que esta configuración pueda aplicarse en los puestos correspondientes, es preciso modificar el tipo de inicio del servicio Identidad de aplicación. Éste se define, por defecto, con arranque Manual y no Automático. Puede configurarlo directamente desde el puesto cliente o incluso mediante una directiva de grupo en Configuración del equipo Directivas - Configuración de Windows - Configuración de seguridad - Servicios del sistema. Seleccione, a continuación, el servicio Identidad de aplicación y modifíquelo para un arranque automático. Reinicie su puesto cliente o fuerce la actualización de la directiva mediante el comando gpupdate /force para poder probar inmediatamente esta funcionalidad. A continuación, puede identificar si las reglas Applocker definidas bloquean aplicaciones normalmente autorizadas. En esta etapa, la aplicación no estará bloqueada. Para verificar la lista de
aplicaciones que tendrían que haber estado bloqueadas, ejecute el visor de eventos y diríjase al registro que se encuentra en Registro de aplicaciones y servicios - Microsoft Windows - Applocker. Busque, a continuación, los eventos con Id 8002 (indicando una ejecución autorizada de una DLL o de un ejecutable) o 8003 (indicando que el archivo habría sido bloqueado si no hubiera estado activado el modo de auditoría).
Aplicar las reglas Applocker en los puestos de producción Una vez haya definido correctamente sus reglas, puede aplicarlas editando su directiva de grupo creado precedentemente dirigiéndose al nivel Configuración del equipo Directivas - Configuración de Windows - Configuración de seguridad - Directivas de control de aplicaciones - Applocker y, a continuación, Propiedades. En la lista desplegable correspondiente a la categoría de reglas que quiere aplicar realmente, seleccione Aplicar reglas. Valide haciendo clic en Aceptar. Si lo desea, puede agregar opcionalmente la dirección de un sitio Web propio cuando se le bloquee una aplicación a algún usuario. De este modo, podrá dirigirles a una página específica de su Intranet para proporcionar información acerca de este bloqueo. Para ello, modifique la directiva Configuración del equipo - Directivas - Plantillas administrativas - Componentes de Windows - Explorador de Windows - Establecer un vínculo de página web de soporte.
Es posible administrar la solución Applocker mediante PowerShell. Encontrará los comandos PowerShell de referencia en la siguiente dirección: http://technet.microsoft.com/en-us/library/ee424349(WS.10).aspx Acaba de descubrir cómo implantar una directiva Applocker. La solución técnica no es particularmente complicada aunque habrá que prestar atención a los distintos procesos para implantar esta solución que evoluciona al mismo tiempo que las aplicaciones de su empresa, de modo que no penalice a los usuarios.
5. Cifrado de datos mediante BitLocker La mayor parte del tiempo, los servidores están ubicados en un datacenter a menudo llamado "búnker", de cara a implementar la seguridad física (cámaras, control de acceso…). No siempre es posible alcanzar este nivel de seguridad, especialmente en sitios remotos, que cuentan únicamente con unos pocos usuarios. Si bien el número de usuarios es, con frecuencia, poco elevado, resulta indispensable desplegar un servidor para ofrecer ciertos servicios de manera local, en especial un controlador de dominio o un servicio DHCP. En el primer caso, el servidor dispone por defecto de una copia del dominio y, por tanto, de las contraseñas de todos los usuarios. Como ha visto en el segundo capítulo del libro, la implementación de un RODC (controlador de dominio de sólo lectura) permite superar este problema. Pero, ¿cómo puede hacerse si se trata de un servidor de archivos o de una base de datos? En tal caso, será interesante cifrar los datos para impedir que el atacante pueda recuperar los datos y las contraseñas contenidos en el equipo. El cifrado es un método que permite reforzar la seguridad de un mensaje o un archivo codificando su contenido de manera que sólo las personas que dispongan de la clave de cifrado apropiada para descifrarlos puedan leerlo. Por ejemplo, si compra un producto en un sitio web, la información necesaria para realizar la transacción (como, por ejemplo, su dirección, su número de teléfono y de tarjeta bancaria) se cifra, por lo general, en el servidor con el objetivo de dotarlos de seguridad. Por otro lado, el cifrado de los discos duros de los equipos portátiles resulta, también, extremadamente interesante para las empresas, sobre todo dado que los usuarios son, cada día, más móviles y, en consecuencia, los datos de la empresa se ven cada vez más expuestos en caso de hurto. Microsoft proporciona, desde Windows 2000, el uso • •
•
BitLocker Provisioning: permite desplegar un cifrado de los discos antes, incluso, de la instalación del sistema operativo. Cifrado únicamente del espacio en disco utilizado: es posible seleccionar cifrar el disco entero o, únicamente, el espacio en disco utilizado. La idea permite cifrar de manera más rápida el disco cifrando únicamente los bloques utilizados. Cambio de contraseña y del código PIN por el usuario estándar: esta funcionalidad ofrece la posibilidad a un usuario estándar de modificar la contraseña o el código confidencial de BitLocker en los volúmenes que albergan el sistema
•
•
operativo y la contraseña de BitLocker en los volúmenes de datos, lo que contribuye a reducir el número de llamadas a soporte técnico. Desbloqueo de red: esta funcionalidad permite a un sistema BitLocker instalado en red desbloquear automáticamente el volumen de sistema durante el arranque (en redes compatibles con Windows Server 2012). Esto puede resultar primordial tras la intervención remota por parte del equipo de soporte informático. Compatible con discos duros cifrados de Windows: Windows 8 es compatible con discos duros cifrados con BitLocker.
Antes de que un disco cifrado con BitLocker se desbloquee, BitLocker autentica el disco basándose en los datos de identificación que el usuario, o el sistema operativo, proveen y que autorizan a BitLocker a desbloquear el acceso al lector. BitLocker tiene en cuenta los distintos métodos de bloqueo en base al conocimiento por el usuario de una contraseña, la presencia de un componente de hardware o claves de aplicación, o una combinación de estos tres elementos. Puede seleccionar el método de bloqueo cuando configura BitLocker. Los métodos de bloqueo disponibles difieren entre los discos del sistema operativo y los discos de datos fijos o extraíbles. Por ejemplo, sólo es posible proteger mediante TPM un disco que contenga un sistema operativo. Sobre un disco que contenga un OS, puede seleccionar utilizar uno de los métodos de bloqueo siguientes: • • • • •
Sólo TPM. Sólo clave de arranque. TPM + código PIN. TPM + clave de arranque. TPM + código PIN + clave de arranque.
En un disco de datos fijos o extraíble, puede seleccionar los tres métodos de bloqueo siguientes: • • •
contraseña. tarjeta + código PIN. automático.
Para los lectores de datos, el método de bloqueo por tarjeta + código PIN ofrece la mejor protección. Cuando quiere bloquear los datos protegidos mediante BitLocker con una tarjeta, debe asegurarse de que sus usuarios tienen certificados compatibles con BitLocker cargados en una tarjeta. Para generar estos certificados, puede utilizar una entidad de certificación (CA), crear certificados autofirmados, o configurar un certificado EFS existente para un uso con BitLocker. Cuando utiliza tarjeta, también se recomienda disponer de una aplicación de gestión de tarjetas. Puede, por ejemplo, utilizar la funcionalidad de gestión de tarjetas que ofrece Microsoft Forefront Identity Manager (FIM). El siguiente vínculo ofrece información detallada acerca del uso de certificados con BitLocker: http://technet.microsoft.com/en-us/library/dd875548%28WS.10%29.aspx
He aquí las principales etapas a realizar para poder utilizar BitLocker en el seno de su empresa. En este ejemplo, se trata de desplegar esta funcionalidad en los equipos portátiles de su AD. a. Activación de la tarjeta TPM en los equipos
La primera etapa consiste en activar la tarjeta TPM en los equipos pues, como hemos visto, no es práctico almacenar la información en una llave USB o tener que escribirla con cada arranque del equipo… Esta etapa se desarrolla a nivel de BIOS del equipo y puede necesitar, según los fabricantes, dos reinicios sucesivos del ordenador. El primero permite activar la funcionalidad de Seguridad TPM y el segundo realiza la activación de la opción de la tarjeta TPM en la placa base. Defina, también, el disco duro como primer dispositivo a utilizar en el orden de arranque del equipo, en caso contrario correrá el riesgo de encontrar problemas si selecciona un arranque puntual desde otro dispositivo (lector de CD, llave USB, etc.). El despliegue de esta opción puede realizarse en cada equipo modificando el proceso de entrega del equipo, con el objetivo de agregar esta configuración, o mediante la herramienta que permite distribuir la información BIOS a los equipos. Estas herramientas son propias de cada fabricante y será conveniente leer su documentación para identificar la existencia de tal solución. b. Activación de BitLocker en los equipos
Si desea desplegar BitLocker en su infraestructura, el elemento más importante a tener en cuenta es disponer de claves de recuperación BitLocker. De este modo, si extrae el disco duro cifrado para conectarlo a otro equipo o si, por algún motivo, el usuario ha perdido su clave BitLocker, la clave de recuperación permitirá recuperar los datos. Es, también, posible configurar los equipos para que la clave de cifrado de BitLocker se almacene como propiedad del equipo directamente en Active Directory. Para ello, si tiene un controlador de dominio con Windows Server 2008 o superior, es posible almacenar esta información en Active Directory. En caso contrario, instale, al menos, un controlador de dominio con esta versión y actualice el esquema de Active Directory para que la información BitLocker pueda tenerse en cuenta. c. Despliegue de BitLocker en equipos del Active Directory
Cree, a continuación, una nueva directiva de grupo y edite los parámetros que se encuentran en Configuración del equipo - Directivas - Plantillas administrativas Componentes de Windows - Cifrado de unidad BitLocker.
Verá varios parámetros de configuración así como tres carpetas suplementarias que configuran la forma en que Windows procesa la información de BitLocker según se trate de un lector de datos extraíble, de un disco fijo o de un sistema operativo. Seleccione las siguientes opciones y repita esta operación según el tipo de información que desea proteger:
Por ejemplo, para el sistema operativo, las opciones son: Elegir cómo se pueden recuperar unidades del sistema operativo protegidas por BitLocker Habilite la opción y seleccione registrar las contraseñas de recuperación y los paquetes de claves. Indique, a su vez, "No habilitar BitLocker hasta que la recuperación de información esté almacenada en Active Directory", lo que le asegura que BitLocker no cifrará los datos mientras no esté seguro de poder recuperarlos a través de Active Directory.
Puede, a continuación, repetir la configuración para los demás tipos de lector. Vaya a Configuración del equipo - Directivas - Plantillas administrativas Componentes de Windows - Sistema - Servicios de Módulo de plataforma segura. Habilite la opción Activar copia de seguridad del TPM en los Servicios de dominio de Active Directory.
Observe que, si BitLocker ya está activo en los equipos, las claves de recuperación así como la información TPM no se almacenará en Active Directory, puesto que se realiza en el momento en que se activa la tarjeta TPM y, por tanto, se activa BitLocker. Para forzar manualmente el almacenamiento de esta información en Active Directory para estos equipos, será preciso utilizar el siguiente comando (para la recuperación de la información para el lector C:, por ejemplo): manage-bde-protectors -get c: Puede obtener la contraseña digital del lector y "empujarla" a Active Directory mediante el comando manage-bde-protectors -adbackup c: -id {contraseña digital}. Puede, a continuación, forzar la aplicación de esta directiva en sus equipos mediante el comando gpupdate /force. d. Visualizar las claves de recuperación de BitLocker
Para visualizar las claves de recuperación de BitLocker, tendrá que utilizar las herramientas RSAT, o bien agregar la funcionalidad Cifrado de unidad BitLocker. Puede, a continuación, ir a la pestaña Recuperación BitLocker, en las propiedades del equipo. La pestaña presenta la contraseña de recuperación que debe utilizar si fuera necesario.
Se planteará, sin duda, la cuestión… ¿Cómo es posible recuperar un disco duro cifrado sin no se sabe el nombre del equipo que ha cifrado los datos? En este caso, tras intentar acceder a los datos, un mensaje le indicará el Password ID. Haciendo una búsqueda en Active Directory puede encontrar este Password ID y, de este modo, la clave de recuperación asociada. Desde la consola ADUC (dsa.msc), aparecerá una nueva opción siempre que estén instaladas las herramientas BitLocker; se trata de la opción Buscar contraseña de recuperación de BitLocker.
Sepa, también, que BitLocker puede utilizarse para cifrar los periféricos extraíbles (llave USB, disco duro externo, etc.) utilizando la funcionalidad BitLocker To Go. El lector puede leerse automáticamente en un equipo Windows 7/8 una vez que se haya informado la contraseña de cifrado. Las versiones anteriores de Windows, como por ejemplo Vista y XP, pueden leer los datos cifrados en los periféricos, con la condición de que los datos estén almacenados en FAT (y no NTFS); gracias a la herramienta BitLocker To Go Reader almacenada sobre el dispositivo. La herramienta no permitirá, sin embargo, leer el contenido de la clave ni escribir datos en el dispositivo. Puede descargar la herramienta de la siguiente dirección: http://www.microsoft.com/enus/download/details.aspx?id=24303 En un contexto algo diferente, he aquí un ejemplo de implementación de BitLocker sobre un servidor core que se encuentra configurado en workgroup: En primer lugar es necesario instalar la funcionalidad mediante el siguiente comando PowerShell: Add-WindowsFeature BitLocker
Al finalizar la instalación, es necesario reiniciar.
Para obtener el estado del cifrado BitLocker sobre el servidor y para todos sus volúmenes, utilice el comando PowerShell: Get-BitLockerVolume |FL
Obtendrá un resultado similar al que se muestra a continuación:
A continuación, debe habilitar BitLocker: %systemroot%\System32\manage-bde.exe -on C: -rp -sk E:
Esta línea de comando configura el cifrado del lector C que contiene al sistema operativo en una máquina que no disponga de un módulo TPM. La opción -rp se corresponde con una contraseña de recuperación; la opción -sk con la ubicación E: (llave USB) se corresponde con la ubicación de almacenamiento de una clave, necesaria con cada reinicio. El resultado se muestra en la siguiente captura de pantalla:
Observe que, por defecto en Workgroup, el sistema no permite cifrar el lector que contiene el sistema operativo en un servidor que no posea módulo TPM. Es preciso, no obstante, configurar la directiva local para autorizar esta operación (en el editor de directivas: Plantillas administrativas - Componentes de Windows - Cifrado de unidad BitLocker - Unidades del sistema operativo - Requerir autenticación adicional al iniciar y marque la opción Permitir BitLocker sin un TPM compatible. Encontrará más información acerca de la configuración de BitLocker en la siguiente dirección: http://technet.microsoft.com/en-us/library/jj612864.aspx Por último, sepa que Windows 8.1 y Windows Server 2012 R2 aprovechan la aparición del soporte del cifrado de los dispositivos. Como ejemplo, cuando un equipo se instala con Windows 8.1, la fase de preparación para el primer uso se encarga de inicializar, también, el cifrado del disco duro externo mediante una clave sin cifrar (equivalente al estado suspendido de BitLocker). A diferencia de las implementaciones anteriores de BitLocker, el cifrado está habilitado automáticamente de manera que el dispositivo siempre está protegido por defecto.
6. Herramientas de seguridad indispensables a. Asistente para configuración de seguridad
Siempre partiendo del principio del menor privilegio, Windows Server, desde el Service Pack 1 de Windows Server 2003, proporciona un asistente de configuración de la seguridad (llamado SCW por Security Configuration Wizard). Su objetivo es crear una directiva que habilite los servicios, las reglas de firewall y los parámetros necesarios para cubrir los roles específicos (controlador de dominio, servidor de impresión, etc.). No se trata, por tanto, de aplicar un modelo de seguridad (archivo INF) sino más bien de configurar el sistema operativo de manera más cercana a las verdaderas necesidades del servidor. Esto supone deshabilitar todos aquellos servicios inútiles, agregar reglas necesarias en el firewall de Windows, etc. Para acceder al asistente, en Windows Server 2012 R2, vaya al Administrador del servidor - Herramientas - Asistente para configuración de seguridad.
La primera etapa consiste en definir la acción que se desea realizar. Puede bien crear una directiva, modificarla, aplicarla o bien hacer una marcha atrás en alguna directiva aplicada con anterioridad. En este ejemplo, vamos a crear una nueva directiva. Hacemos clic en Siguiente.
Seleccione, a continuación, el servidor sobre el que desea auditar la configuración y aplicar esta seguridad. A continuación, haga clic en Siguiente.
Se compara la información con la información de seguridad que ofrece Microsoft y que es visible haciendo clic en Ver la base de datos de configuración. Haga clic en Siguiente.
El resto del asistente le permite realizar la selección de roles necesarios en el servidor para configurar, así, los servicios de manera adecuada. Si no marca un servicio que esté instalado, entonces el asistente lo deshabilitará y ya no se volverá a arrancar. Tome su tiempo para analizar los resultados. Por defecto, el asistente le presenta aquellos roles que ha identificado como instalados en su etapa de verificación anterior. Una vez realizada la selección, haga clic en Siguiente.
La siguiente etapa hace referencia a las Características instaladas. Aquí se enumeran los principales servicios "cliente" utilizados en el servidor (DNS, WINS, Miembro de dominio, etc.). Realice el mismo análisis que en la etapa anterior y, a continuación, haga clic en Siguiente.
La siguiente etapa indica otras opciones diversas que tendrán su impacto en ciertos servicios, o sobre la configuración automática del firewall de Windows con seguridad avanzada. Haga clic en Siguiente una vez realizada la selección.
Los servicios adicionales, al no formar parte de la base de datos de configuración que se ofrece por defecto, se enumeran aquí. Haga la selección adecuada y, a continuación, haga clic en Siguiente.
Pasamos a una etapa que se refiere al tratamiento de servicios sin especificar durante las etapas anteriores. Puede seleccionar el comportamiento por defecto entre no modificar el modo de arranque del servicio o deshabilitarlo automáticamente. La elección dependerá de la criticidad del servidor. Haga clic en Siguiente. La siguiente ventana resume las modificaciones que se realizarán en los servicios del servidor en cuestión. Valide la configuración haciendo clic en Siguiente.
La siguiente etapa se refiere a la configuración automática de las reglas para el Firewall de Windows. Es posible ignorar esta etapa marcando la opción adecuada. Haga clic en Siguiente para iniciar este asistente. Puede seleccionar y enumerar las reglas modificadas por el asistente de configuración, o incluso, por ejemplo, agregar una regla específica que no se había identificado previamente. Una vez finalizada esta etapa, haga clic en Siguiente.
A continuación puede editar la configuración del registro. En esta aplicación, se trata, en realidad, de configurar los protocolos autorizados para comunicar con los demás equipos (exigir la firma SMB, exigir la firma LDAP y los métodos de autenticación entrante y saliente). Aparece una página que le resume todas las modificaciones que se efectuarán en el servidor. Esta configuración resulta muy interesante y permite aumentar, significativamente, la seguridad de los intercambios entre el servidor y sus clientes. Las modificaciones propuestas requieren, no obstante, disponer de un parque informático relativamente moderno. La última etapa se refiere a la configuración de la directiva de auditoría que se aplicará. Piense en prever una volumetría suficiente para que la auditoría sea manejable. El archivo SCWAudit.inf define una auditoría sobre el acceso de cualquier usuario al archivo de configuración, de sistema, etc. Tenga en mente que la marcha atrás propuesta por el asistente de configuración de la seguridad no le permitirá restaurar estos parámetros de auditoría a su estado original. Si tiene alguna duda, desmarque la opción en cuestión. Haga clic en Siguiente.
Seleccione un nombre para guardar el archivo. Puede visualizar la configuración creada e incluso integrarla en un modelo de seguridad (archivo .INF) que se aplicará durante la selección de la configuración específica. En nuestro ejemplo, se trata de Plantilla_ControladorDeDominio_2014.xml.
A continuación, puede seleccionar aplicar más adelante, o inmediatamente, la directiva en cuestión. Lo que resulta interesante con este asistente es que puede crear un archivo de plantilla, tal y como hemos hecho, y a continuación convertirlo en un objeto de directiva de grupo, que será más fácil de desplegar en los equipos que elija. Es posible convertir el archivo de directiva de seguridad en un objeto de directiva de grupo de la siguiente manera: Scwcmd transform /p:%windir%\security\msscw\Policies\Plantilla_ ControladorDeDominio_2013.xml /g:SecureDC
Se crea automáticamente una GPO llamada SecureDC donde se definirán los parámetros de la plantilla. Deberá, a continuación, vincular esta GPO con la OU que desee. Si fuera necesario, los archivos de log se encuentran en la ruta: %windir%\security\msscw\Logs
Esto permitirá mantener una seguridad homogénea de los servidores utilizados para un mismo rol, sin un sobrecoste en la administración. b. La herramienta Security Compliance Manager
Microsoft pone, también, a disposición del usuario y de manera gratuita una lista de referencias de los parámetros de seguridad para sus productos, especialmente para Windows Server 2012. Estos parámetros se proveen a través de una herramienta llamada Security Compliance Manager, accesible en la siguiente dirección: http://technet.microsoft.com/en-us/library/jj898542.aspx SCM permite evaluar y corregir la conformidad de sus políticas de seguridad mediante las siguientes operaciones: • • • •
Importar los parámetros de seguridad (desde el sitio Microsoft Solution Accelerators o desde una copia de seguridad de sus GPO). Comparación y personalización de los parámetros respecto a las recomendaciones de Microsoft. Exportación de los parámetros de seguridad (hacia una GPO, un pack de configuración DCM para SCCM, un archivo SCAP…). Consulta de las últimas versiones de las guías de seguridad de Microsoft provistas con las baselines oficiales.
c. La herramienta Microsoft Security Assessment Tool
Existe otra herramienta, muy popular entre los equipos encargados de la seguridad. Se trata de Microsoft Security Assessment Tool (MSAT), disponible en la siguiente dirección: http://www.microsoft.com/enus/download/details.aspx?displaylang=en&id=12273. Se analizan una serie de cuestiones (más de un centenar), que le permiten evaluar la seguridad de su infraestructura según las respuestas indicadas. Tras el formulario, se generan 3 informes, más un informe completo que incluye una guía de procedimientos y un listado de las acciones principales. Permite ofrecer información y recomendaciones sobre las buenas prácticas de seguridad en el seno de una infraestructura. Se basa en una serie de preguntas globales relativas a su parque informático (número de equipos, número de servidores, etc.) más cuestiones un poco más técnicas (¿existe una DMZ?, etc.).
7. El control de acceso dinámico a. Principio del control de acceso dinámico
Estos últimos años hemos organizado toda nuestra seguridad de datos (nuestros recursos) en base a la asignación de permisos (ACL) y a usuarios según su pertenencia a tal o cual grupo.
Si bien este método ha resultado útil, posee sus límites pues, de hecho, se trata de un acceso que se resume en autorizado o no según la pertenencia del usuario a los grupos definidos o a la aplicación de ciertas ACL sobre una carpeta o archivo concretos. La seguridad se centraba, principalmente, en los usuarios que podían acceder a ciertos recursos, más que a la criticidad de los propios recursos accedidos. Con Windows Server 2012 R2, es posible mejorar considerablemente esta gestión de los datos a través de una nueva noción llamada Control de acceso dinámico (o Dynamic Access Control - DAC). El control de acceso dinámico permite establecer autorizaciones de acceso en función de reglas precisas. Permite complementar los permisos existentes sobre una carpeta o un archivo, no tiene vocación de remplazar las ACL, aunque se agrega a los permisos NTFS implementados. Estas reglas pueden estar vinculadas a numerosos parámetros, tales como: • • • •
El nivel de confidencialidad asociado a un archivo o carpeta. El cargo ocupado por un usuario, su ubicación geográfica o cualquier otro atributo diferenciador. La configuración del dispositivo que se utiliza para acceder a los recursos. Etc.
Será, de este modo, posible permitir el acceso a un recurso en función de su clasificación. Es posible agregar alguna condición de acceso suplementario como, por ejemplo, la conformidad del equipo desde el que el usuario intenta acceder al recurso. Este mismo usuario desde un equipo que no esté actualizado no podrá acceder al mismo archivo. El cambio se realiza sobre la marcha, pues los criterios se verifican en el momento de realizar el acceso al recurso. La información relativa al DAC se almacena en el Active Directory dentro de CN=Claims Configuration,CN=Services,CN=Configuration,DC=miempresa, DC=priv y se replica en el seno del Active Directory. b. Terminología
Antes de poder abordar el DAC, veamos los distintos términos que conviene conocer: •
Notificación (Claim): le permite implementar DAC en su infraestructura, será preciso realizar un trabajo previo para categorizar sus datos, su criticidad, el perímetro de seguridad autorizado (puesto conforme o no) para acceder a los archivos, etc. Estos elementos se asocian a distintos atributos. Una notificación es uno de estos atributos, hará referencia a un usuario (sus atributos Active Directory), un dispositivo (atributos Active Directory del equipo) o un recurso (propiedad de recursos definidos por los administradores).
Esto permite definir de forma precisa los usuarios, dispositivos y recursos que se desea integrar en DAC a nivel de toda la empresa. Cuando una notificación se basa en una cuenta de equipo, deberá habilitarse la opción FAST (Kerberos Armoring) por GPO sobre los controladores de dominio del dominio afectado. Es posible agrupar una notificación de usuario y de equipo para formar una autenticación compuesta (Compound ID), disponible únicamente en Windows 8/2012 o superior. Las notificaciones, o propiedades, se agregan a una lista de propiedades de recursos. •
Reglas de acceso central (Central Access Rules): se trata de una expresión de reglas de autorización que incluye una o varias condiciones. Estas condiciones afectan a los grupos de usuarios, a las propiedades de los recursos, a las notificaciones del usuario o del dispositivo.
•
Directiva de acceso central (Central Access Policy): se trata de una directiva de autorización que incluye expresiones condicionales, es decir, condiciones que deben cumplirse para poder acceder al recurso (o al archivo). La directiva de acceso central debe agregarse a una regla de acceso central. La regla de acceso central debe, por tanto, aplicarse a todos los archivos afectados. La directiva de acceso central se despliega, a continuación, en todos los servidores de archivos.
•
Expresión (Expression): hablamos de una expresión condicional. El acceso a los recursos puede afinarse gracias a la definición de varias condiciones (tales como la pertenencia de una cuenta a un grupo, el nivel de seguridad del puesto de usuario, etc.). Las expresiones se definen a nivel de los parámetros de seguridad avanzados del archivo/carpeta o del editor de reglas de acceso central.
c. Formas de implementación y requisitos previos
Para utilizar DAC, existen dos enfoques posibles: • •
Es posible definir reglas y directivas de acceso central a nivel de Active Directory, y éstas se utilizarán para autorizar o no el acceso a un recurso. El segundo método consiste en crear e integrar las notificaciones en las listas de control de acceso existentes (ACL). Este caso resulta particularmente útil para archivos almacenados en un sistema de archivos ReFS puesto que no soporta, de momento, ninguna directiva de acceso. Para obtener más información acerca ReFS, consulte el capítulo El ciclo de vida de su infraestructura.
Los requisitos previos son:
• • •
•
• •
El nivel funcional del bosque debe, al menos, ser Windows Server 2003. DAC requiere, al menos, un controlador de dominio con Windows Server 2012. Los servidores de archivos para los que desea una autenticación basada en notificaciones deben, a su vez, utilizar Windows Server 2012/2012 R2. El rol File Server Resource Manager (FSRM) debe estar instalado en estos servidores de archivos. Un cliente Windows RT/8/8.1/201/2012 R2 si el acceso se basa en notificaciones y quiere utilizar los atributos en el objeto Equipo. En los demás casos, basta con un cliente Windows 7/2008 R2. Un cliente Windows RT/8/8.1/2012/2012 R2 con acceso a un controlador de dominio en Windows Server 2012/2012 R2 para los sitios remotos. Si el usuario no se encuentra en el mismo bosque que el servidor de archivos, todos los controladores de dominio del dominio raíz del servidor de archivos deben utilizar Windows Server 2012/2012 R2.
Como podrá ver, existen varias nociones nuevas que debe aprehender, aunque la ganancia en términos de seguridad resulta muy interesante. d. Caso práctico y análisis de necesidades
Tomemos como ejemplo el departamento Recursos Humanos (RRHH) de una gran empresa con varios países agrupados en el mismo dominio Active Directory. Los archivos de RRHH de cada país no deberían poder consultarse, salvo en modo de sólo lectura, por parte del departamento de RRHH local de cada país, respectivamente. El departamento de RRHH central podrá, además, acceder a los archivos de RRHH de todos los países. Etapa 1: Comprender las necesidades y traducirlas en atributos de referencia interpretables en DAC Como en todo proyecto, es necesario realizar un estudio previo. Se trata de identificar los datos sensibles y las reglas que autorizarán el acceso a los mismos. Las reglas son, por tanto: • • • • •
Los documentos no pueden accederse salvo en modo de solo lectura desde el departamento de RRHH. El departamento de RRHH sólo puede acceder a los recursos de RRHH de su país. Sólo los miembros del grupo Admins RRHH tienen un acceso de lectura/escritura. Los miembros del grupo RRHH_Excepcion tendrán acceso de sólo lectura. Los administradores y propietarios del documento tendrán un acceso de Control total.
Etapa 2: Crear el tipo de notificación
Es necesario crear notificaciones sobre los atributos que se utilizarán para definir el acceso al recurso. En nuestro caso, nos basaremos en los atributos Department (Departamento) y Country (País) del usuario. La definición de la notificación se configura en la consola del Centro de administración de Active Directory, pues se trata de información que se almacena en Active Directory. Desde la consola Centro de administración de Active Directory (dsac.exe), vaya al menú Control de acceso dinámico - Claim Types - Nuevo - Tipo de notificación y haga clic en el atributo department. Agregue, a continuación, el atributo País. Desde la consola Centro de administración de Active Directory, Control de acceso dinámico - Claim Types - Nuevo - Tipo de notificación y haga clic en el atributo c. En Nombre completo, indique country. En los valores sugeridos, haga clic en Se sugieren los valores siguientes y agregue ES (en valor y nombre completo), JP, US, GB.
Etapa 3: Definir las propiedades de los recursos Hay que empezar definiendo las propiedades de los recursos (Resource Properties). Aquí se configuran las propiedades que se descargarán los servidores de archivos para clasificar los archivos. Observe que estas propiedades de recursos se agregarán a la lista de Propiedades de recursos. Los futuros accesos de control dinámico tendrán como objetivo comparar los atributos del usuario con las propiedades de los recursos. Se establece una lista previa de propiedades de los recursos por Microsoft, aunque es posible crear las propias si fuera necesario. Esto es lo que hemos hecho con el atributo Country, que no existe por defecto. En primer lugar, habilitaremos el atributo Department... Abra la consola Centro de administración de Active Directory y, a continuación, seleccione Control de acceso dinámico - Resource Properties. Seleccione Department y marque la opción Habilitar en la lista de tareas disponibles.
Para el atributo Country, al no estar definido por defecto, es necesario crear una propiedad de recursos de referencia del siguiente modo: Desde la consola Centro de administración de Active Directory, Control de acceso dinámico - Resource Properties - Nuevo - Propiedades de recurso de referencia. Seleccione el atributo country e indique el mismo nombre en Nombre completo y, a continuación, haga clic en Aceptar.
Seleccione country en la lista de Resource Properties y haga clic en Habilitar.
Si no utiliza las notificaciones sino directamente las propiedades de los recursos, se recomienda agregarlas a una lista de propiedades de recursos. Etapa 4: Definir una regla de acceso central (Central Access Rule o CAR) Es, de algún modo, el equivalente a las ACL, incluso aunque no las remplaza por completo. Una CAR describe las condiciones que deben cumplirse para permitir el acceso a un recurso (un archivo, por ejemplo). Desde la consola Centro de administración de Active Directory (dsac.exe), vaya al nodo Control de acceso dinámico, haga clic en Central Access Rules - Nuevo - Regla de acceso central.
Defina, a continuación, las reglas que desee aplicar. En nuestro ejemplo, para asociar una verificación al atributo "Departamento", haga lo siguiente: Nombre: RRHH - Reglas para los documentos RRHH. Descripción: (opcional). Recursos afectados: haga clic en Editar y, a continuación, en Agregar una condición y seleccione la o las condiciones que deben cumplirse para permitir el acceso a los recursos, del siguiente modo: Recurso - Department - Es igual a - Valor - Human Resources y haga clic en Aceptar (Human Resources se corresponde con el valor preconfigurado por defecto en Windows y que puede modificarse si fuera necesario a nivel de Resource Properties). En las autorizaciones, seleccione el valor Usar los siguientes permisos como permisos actuales.
En las Permisos actuales, haga clic en Editar y, a continuación, agregue los Usuarios autentificados como Principal. Es preciso crear, a continuación, las condiciones que se refieren a las necesidades expresadas en el estudio para "Todos" los usuarios. En nuestro ejemplo, los Usuarios autentificados responden a ciertos criterios que pueden acceder a los archivos en modo lectura, por lo que debemos definir la siguiente regla: Usuario - country - Cualquiera de - Recurso - country y Usuario - department - Cualquiera de - Recurso - Department Haga clic en Aceptar.
Agregue una autorización específica para los Administradores de RRHH (miembros del grupo RRHH_Admin) que tendrán, en sí mismo, la posibilidad de modificar el contenido en cuestión. Haga clic en Editar dentro de Permisos actuales y, a continuación, Agregar Seleccionar una entidad de seguridad. Indique el grupo RRHH_Admin en Modificar. Haga clic en Aceptar.
Agregue una autorización específica para los usuarios que solo tengan permisos de lectura (miembros del grupo RRHH_Excepcion). Haga clic en Editar dentro de Permisos actuales y, a continuación, Agregar - Seleccionar una entidad de seguridad. Indique el grupo RRHH_Excepcion que tendrá acceso de Lectura/lectura y ejecución. Haga clic en Aceptar. Ahora, tiene una regla de acceso central que limita el acceso a los archivos de RRHH a un mismo país y un mismo departamento. El grupo RRHH_Admin puede editar los archivos y el grupo RRHH_Excepcion puede leerlos. Observe que sólo los archivos clasificados como Human Resources estarán afectados por esta regla. Etapa 5: Agregar reglas de acceso central a una directiva de acceso central A continuación, es preciso asociar las reglas creadas a una directiva de acceso central que desplegaremos mediante una GPO. Para ello, desde el Centro de administración de Active Directory abra Central Access Policies - Nuevo - Directiva de acceso central y asocie la regla de acceso central que acaba de crear.
Etapa 6: Desplegar la directiva de acceso central en los servidores de archivos mediante una GPO La CAP puede desplegarse mediante una GPO en los servidores de archivos Windows Server 2012 que posean el rol FSRM (este rol se agrega al servidor en Seleccionar roles de servidor - Servidor de archivos y almacenamiento - Servicios de iSCSI y archivo y marcando Servidor de archivos y Administrador de recursos del servidor de archivos). Es preciso crear una nueva GPO para desplegar la directiva de acceso central (CAP) en los servidores de archivos. Esta directiva de grupo deja disponible la política de acceso central, aunque no forzará su aplicación. Desde la consola Administración de directivas de grupo (gpmc.msc), cree una GPO en la OU que hospeda sus servidores de archivos. Navegue a Configuración del equipo Directivas - Configuración de Windows - Configuration de seguridad - Sistema de archivos - Directiva de acceso central.
Haga clic con el botón derecho en Directiva de acceso central y, a continuación, en Administrar directivas de acceso central. Seleccione la directiva que acaba de crear CAP_RRHH y haga clic en Agregar.
Haga clic con el botón derecho en la OU correspondiente a su directiva y seleccione Actualización de directiva de grupo. Esto tiene como efecto forzar la aplicación de la directiva de grupo en todos los servidores de la OU (funcionalidad incluida con Windows Server 2012 que funciona con equipos cliente con Windows Vista/2008 o versiones superiores). Etapa 7: Configurar los controladores de dominio y los clientes para que tengan en cuenta las notificaciones Para que un controlador de dominio sea apto para gestionar las notificaciones, hay que configurarlo definiendo una GPO que se aplica a nivel de la OU ”Domain Controllers”.
La opción FAST por Flexible Authentication Secure Tunneling, también conocida con el nombre de ”Kerberos Armoring"” (o blindaje Kerberos), debe estar habilitada en los controladores de dominio para ser compatible con DAC. FAST provee, en particular, un canal seguro entre el cliente y el KDC. El blindaje Kerberos se aplica mediante GPO sobre la OU ”Domain Controllers”. Se aplica sobre controladores de dominio con Windows Server 2008 y superiores. Para configurarlo, siga los siguientes pasos: Cree una GPO, en lugar de utilizar la GPO por defecto ”Default Domain Controllers Policy”. Vaya a Configuración del equipo - Directivas - Plantillas administrativas - Sistema KDC y habilite el parámetro KDC admite notificaciones, autenticación compuesta y protección de Kerberos. Fuerce las GPO en los controladores de dominio a través del comando gpupdate /force. A nivel de su dominio (o de sus equipos cliente, únicamente), defina una GPO que permita utilizar notificaciones. Esto tiene como efecto extender el ticket Kerberos gestionado por el cliente. Vaya a Configuración del equipo - Directivas - Plantillas administrativas - Sistema Kerberos y habilite el parámetro KDC admite notificaciones, autenticación compuesta y protección de Kerberos. Etapa 8: Clasificar los datos en el servidor de archivos y aplicar la directiva de acceso central Esta etapa debe realizarse desde el explorador de archivos en el servidor de archivos con el rol FSRM. En primer lugar, deberá clasificar los archivos del recurso compartido especificando las propiedades de los recursos definidas anteriormente. En las propiedades de aquellos recursos compartidos que deban protegerse, haga clic con el botón derecho sobre él y, a continuación, en Propiedades. Vaya a la pestaña Clasificación. Verá aparecer todas las propiedades de los recursos definidas anteriormente. Si no fuera el caso, desde el servidor de archivos, abra una ventana de PowerShell y escriba el comando Update-FSRMClassificationPropertyDefinition. Este comando forzará el refresco de las propiedades de los recursos definidas. Seleccione, a continuación, las propiedades del recurso country y Department y defina los valores esperados. A continuación, haga clic en Aceptar.
Ahora que ha clasificado la carpeta, puede asociar la directiva de acceso central que desea aplicarle. En las propiedades de la carpeta, seleccione la pestaña Seguridad, haga clic en Opciones avanzadas y seleccione la pestaña Directiva central. Haga clic en Cambiar y seleccione, a continuación, la directiva centralizada llamada CAP_RRHH.
A continuación, haga clic en Aceptar para validar la configuración y, de este modo, hacer la DAC efectiva sobre esta carpeta. Etapa 9: Verificar los accesos efectivos Ahora que todo está implementado, la última etapa consiste en verificar que los accesos están bien definidos. Para ello, no tendrá que conectarse con la cuenta de tal o cual usuario para hacer esta verificación. La pestaña Acceso efectivo se ha actualizado en Windows Server 2012 y tiene en cuenta las notificaciones. En las Propiedades de la carpeta, seleccione la pestaña Seguridad, haga clic en Opciones avanzadas y seleccione la pestaña Acceso efectivo. Seleccione la cuenta de usuario que desee y haga clic en Ver acceso efectivo.
Aquí, si bien todos los usuarios autenticados están definidos a nivel NTFS, sólo aquellos que respondan a los criterios definidos en la DAC están autorizados a acceder a los recursos. Puede, a continuación, constatar la eficacia de esta directiva visualizando las autorizaciones efectivas sobre esta carpeta seleccionando una cuenta de usuario que tenga los atributos informados correctamente. Puede, a su vez, indicar una notificación específica y ver los permisos aplicados. Puede definir atributos de usuario directamente desde la consola Centro de administración de Active Directory. En las propiedades del usuario existe una sección Extensión, que contiene varias pestañas, entre ellas una llamada Editores de atributos.
e. Para ir más allá...
Existen varias opciones muy interesantes que complementan la funcionalidad de control de acceso dinámico. Entre ellas, cabe tener en mente: •
En caso de acceso denegado, es posible definir una directiva de remedio que permita al administrador definir un mensaje específico al usuario, e incluso avisar al propietario del recurso mediante correo electrónico, lo que mejora considerablemente la reactividad en caso de existir alguna configuración incorrecta durante la etapa de implementación de la DAC. Observe que esta funcionalidad sólo está disponible si utiliza SMB 3.0 (y, por consiguiente, para accesos a archivos que se hayan realizado desde clientes Windows 8/8.1/2012/2012 R2 hacia un servidor de archivos Windows Server 2012/2012 R2). Esto se configura en los servidores de archivos, en la consola Administrador de recursos del servidor de archivos - Administración de clasificaciones. Haga clic con el botón derecho en Propiedades de la clasificación y Establecer propiedades de administración de carpetas.
•
Las directivas de auditoría son mucho más eficaces cuando están basadas en expresiones que se apoyan en notificaciones (claims) de usuario, de equipo y de recurso, permitiendo así precisar los eventos que deben notificarse.
De este modo puede, por ejemplo, auditar todos los usuarios que intentan acceder a recursos para los que no tienen habilitado el acceso o, al revés, administradores que usen sus permisos de forma abusiva. Vaya a las Propiedades de la carpeta que desee auditar, en la pestaña Seguridad Opciones avanzadas - pestaña Auditoría - Agregar - Seleccionar una entidad de seguridad. Seleccione, a continuación, el grupo que desea auditar, por ejemplo el grupo habilitado para acceder a esta carpeta. Puede, a continuación, agregar una condición que indique, por ejemplo: Usuario - Grupo Miembro de cada - Valor - [Admins de Dominio] y [Administradores]. Debe haber habilitado, previamente, la auditoría del sistema de archivos en Configuración del equipo - Directivas - Configuración de Windows - Configuración de seguridad Configuración de directiva de auditoría avanzada - Directivas de auditoría - Acceso a objetos. A continuación, en el parámetro Auditar sistema de archivos y en el parámetro Auditar almacenamiento provisional de directiva de acceso central, habilite las opciones Correcto y Error. •
Para la clasificación de los archivos, una de las etapas más complejas, es posible definir reglas de clasificación automática de los datos. Puede, a continuación, buscar los archivos que contienen la cadena de caracteres "Confidencial restringido" y, de este modo, categorizar automáticamente el archivo como ”High”. Para ello, es preciso crear una regla de clasificación desde la consola Administrador de recursos del servidor de archivos, habiendo habilitado previamente la propiedad de recursos "Impacto".
De este modo, se ejecutará esta regla escaneando todos los archivos buscando la cadena de caracteres en cuestión y, a continuación, atribuirá automáticamente el valor High al atributo Impact del archivo. Microsoft proporciona, a su vez, la herramienta Data Classification Toolkit que le ayuda en la clasificación de los archivos en sus servidores Windows 2008 R2/2012 y 2012 R2. Está disponible en la siguiente dirección: http://www.microsoft.com/enus/download/details.aspx?id=27123 •
Si desea acoplar DAC a RMS, esto le permitirá cifrar sus documentos sensibles En base, por ejemplo, a su clasificación podrá mantener el control sobre los documentos clasificados en cualquier momento.
El control de acceso dinámico supone una mejora importante en Windows Server 2012. Si bien es necesario realizar un gran trabajo inicial, la seguridad de los datos de la empresa se verá mejorada considerablemente. Podrá acoplarle una directiva de auditoría basada en expresiones, tal y como se describe en el capítulo Dominio Active Directory.
Delegación de la administración en Active Directory Una de las principales ventajas de un dominio Active Directory es poder tener un directorio común para varias entidades en el seno de la misma empresa. Este directorio compartido permite reducir costes de administración asociados al mantenimiento de la infraestructura.
1. Enfoque de la delegación de la administración Dado que las políticas de seguridad están bien diferenciadas en las distintas divisiones de la empresa y que los equipos IT no son los mismos, conviene encontrar una solución que permita delegar las tareas necesarias para el trabajo de cada uno sin comprometer la seguridad de la totalidad del dominio Active Directory. Existen distintas maneras de delegar los permisos a los usuarios. Algunas autorizaciones pueden asignarse, fácilmente, a través de grupos de seguridad ya existentes. Es el caso, por ejemplo, de la delegación de la administración de un servicio como DHCP (mediante el grupo DHCPAdmins) o DNS (mediante el grupo DNSAdmins), o incluso la posibilidad de consultar los registros de eventos (mediante el grupo Event Log readers), etc. Es posible realizar, también, una delegación en el seno de Active Directory mucho más granular, directamente a nivel de los objetos. La estructura de un dominio Active Directory está organizada por defecto de forma jerárquica. Es posible, en efecto, delegar tareas a nivel de un bosque, de un sitio, de un dominio o incluso de una unidad organizativa. Además, cada objeto posee atributos con DACL (Discretionary Access Control List) asociados, de modo que también es posible delegar las opciones de manera muy precisa (reinicializar la contraseña del usuario, autorizar la desactivación de una cuenta de usuario, etc.). Pasaremos a la práctica un poco más adelante en este mismo capítulo. Antes de comenzar con la configuración de la delegación de su Active Directory, conviene estudiar bien las necesidades actuales a las que debe responder. La siguiente lectura (en inglés) le permitirá ver un poco más clara la delegación de la administración de un Active DirectoryDirectory y las buenas prácticas que debe aplicar. Está disponible en la siguiente dirección: http://www.microsoft.com/enus/download/details.aspx?id=21678
2. Delegación de cuentas de usuario Pasemos, ahora, a la práctica delegando dos acciones especialmente útiles para una hotline y equipo de soporte informático de la empresa. Estos equipos no tienen la vocación de
realizar tareas administrativas ligadas al Active Directory, sería excesivo agregarlos al grupo "Administradores del dominio" por ejemplo. Entre las necesidades que expresan más a menudo estos equipos para responder a las peticiones de los usuarios, encontrará en especial la solicitud de permiso para agregar un usuario a un dominio Active Directory y el permiso para reinicializar las contraseñas de los usuarios. Las delegaciones se realizan, por lo general, sobre el total o sobre una parte de los objetos de una unidad organizativa (u OU por Organizational Unit) o de un dominio. Esto tiene como objetivo simplificar la administración y la gestión de los permisos de su Active Directory. Está de más recordarle que es obligatorio guardar una traza de las delegaciones realizadas para facilitar la administración cotidiana y las operaciones de recuperación en caso de problemas. Tomemos como ejemplo el departamento de hotline que quiere poder reinicializar las contraseñas de los usuarios y desbloquear sus cuentas. Todos los usuarios de la hotline forman parte del mismo grupo llamado HotlineUsers. Para delegar estos permisos, Microsoft pone a su disposición el asistente de delegación. Para ello, desde la consola Centro de administración de Active Directory (dsa.msc), sitúese en el objeto del contenedor padre desde el nivel en que quiera realizar la delegación de permisos. En la mayoría de casos, esta delegación se realiza a nivel de una unidad organizativa. Haga clic con el botón derecho del ratón en el objeto y seleccione Delegar control.
Haga clic en Siguiente en la pantalla de bienvenida. El asistente le pide a continuación seleccionar los usuarios o grupos para los que quiere asignar los permisos delegados. Haga clic en Agregar y, a continuación, escriba el nombre de su grupo y haga clic en Comprobar nombres. A continuación, haga clic en Aceptar.
Una vez agregado el o los grupos, haga clic en Siguiente. Puede seleccionar, ahora, el nivel de permisos que quiere aplicar al objeto delegado. Puede seleccionar entre las delegaciones predefinidas para tareas corrientes o bien Crear una tarea personalizada para delegar. En nuestro ejemplo, podríamos escoger las tareas predefinidas aunque éstas ofrecen demasiados permisos en comparación con lo que queremos autorizar. Elija la opción Crear una tarea personalizada para delegar para poder realizar una delegación más granular, y haga clic en Siguiente.
Seleccione delegar Sólo los siguientes objetos en la carpeta, marque Objetos Usuario y, a continuación, haga clic en Siguiente.
Seleccione, a continuación, el o los tipos de autorización que quiere delegar a los usuarios. En nuestro ejemplo, el atributo Restablecer contraseña (o Reset Password, en inglés) se utiliza para reiniciar la contraseña y los atributos Leer lockoutTime (o Read lockout Time) y Escribir lockoutTime (o Write lockout Time) se utilizan para desbloquear una cuenta de usuario. Los dos últimos sólo están visibles marcando la opción Específico de la propiedad pues, como su propio nombre indica, son específicos del objeto usuario.
Una vez marcadas las tres opciones, haga clic en Siguiente. Aparece una ventana que resume las opciones seleccionadas durante el asistente de delegación. Haciendo clic en Finalizar se modifican las ACL en el contenedor seleccionado.
Puede enumerar y definir una autorización directamente desde la consola de Usuarios y Equipos Active Directory. Para ello debe activar las Características avanzadas en el menú Ver de la consola. A continuación, visualizando las Propiedades del controlador o del objeto delegado, aparece una pestaña Seguridad que le permite visualizar y modificar la seguridad directamente desde este lugar.
Observe, también, que desde el Centro de administración de Active Directory (DSAC.exe), no existe ningún asistente de delegación disponible, aunque puede visualizar la seguridad implementada en una OU específica seleccionando la opción Ver de las propiedades de la OU en cuestión.
Una vez realizada la delegación, es habitual que se distribuya una consola MMC personalizada a los usuarios afectados. Para ello es necesario tener instaladas las herramientas RSAT en los puestos de administración. La ventaja de tener una consola MMC personalizada es que estos usuarios sólo tienen acceso a una visión limitada del Active Directory. También es posible definir de forma exhaustiva las acciones disponibles (en nuestro ejemplo, serían las opciones de reinicializar las contraseñas de los usuarios y desbloquear su cuenta). Encontrará más información acerca de la forma de crear una consola MMC personalizada en la siguiente dirección (en inglés): http://technet.microsoft.com/enus/library/bb742441.aspx#XSLTsection126121120120 o también http://social.technet.microsoft.com/wiki/contents/articles/2816.how-to-create-custom-mmcand-add-taskpad.aspx Aun habiendo configurado todas sus delegaciones, se dará cuenta rápidamente de que no siempre es sencillo encontrar el documento correcto para saber "quién tiene el permiso para hacer qué". Microsoft incluye para ello una pestaña que le permite listar las autorizaciones efectivas de una cuenta o de un grupo de usuarios sobre el objeto que elija (opción disponible tanto a nivel de los permisos NTFS como a nivel de directorio). Esta opción puede resultar muy práctica para ver con mayor claridad la delegación implementada, pero también para paliar problemas de permisos a menudo heredados desde objetos padre difícilmente identificables. Gracias a esta herramienta, podrá identificar fácilmente los problemas.
Abra las Propiedades de una cuenta de usuario presente en el contenedor que desee (por ejemplo la unidad organizativa sobre la que haya definido su delegación en el ejercicio anterior) y a continuación haga clic en la pestaña Seguridad - Opciones avanzadas Permisos efectivos. Recuerde que si utiliza la consola Usuarios y equipos de Active Directory (dsa.msc), y la pestaña Seguridad no está presente, es necesario seleccionar las Características avanzadas dentro de las opciones de visualización). Desde la consola Centro de administración de Active Directory (dsac.exe), tendrá que ir a la opción Extensiones en las Propiedades de la cuenta. Haga clic en Seleccionar e indique la cuenta de un usuario (en nuestro ejemplo se trata de una cuenta de usuario miembro del grupo HotlineUsers). Se muestran, a continuación, todos los permisos que posee la cuenta de usuario sobre el objeto seleccionado. En la captura de pantalla siguiente, vemos cómo el permiso Cambiar contraseña está habilitado.
La delegación de tareas administrativas es, como hemos visto, un elemento importante que puede integrar en sus procesos administrativos para delimitar de la mejor forma posible el rol de cada uno.
Securización de la red La securización de la red de empresa es, también, una etapa primordial de la securización general de su infraestructura. Esta sección tiene como objetivo presentar las funcionalidades más interesantes de Windows Server 2012 que le permitirán implementarlo de la mejor forma posible en su infraestructura de red existente.
1. Network Access Protection Con Windows Server 2008 R2 apareció una capa suplementaria de red llamada NAP (por Network Access Protection). Se realiza un control de conformidad sobre todos los servidores y puestos de trabajo (que soporten esta funcionalidad) antes de realizar cualquier conexión a la red de producción. Debería, de este modo, definir previamente un conjunto de requisitos previos de seguridad (antivirus actualizado, firewall activo, etc.). Será, también, capaz de garantizar que los equipos que se conectan a su red de empresa tienen un nivel de seguridad mínimo. Si éste no fuera el caso, estos equipos se ponen en cuarentena en una red dedicada y no enrutada mientras no cumplan con los requisitos previos exigidos. Encontrará más información acerca de NAP en el capítulo Implantar los servicios de red de la empresa. Observe que tras la aparición de Windows Server 2012 R2, la funcionalidad se ha marcado como "potencialmente a abandonar" en las próximas versiones de Windows. Este tema se aborda con un poco más de detalle en el capítulo Implementar los servicios de red de la empresa.
2. El Firewall de Windows Windows Server 2012 R2 ponen a su disposición un firewall capaz de analizar a la vez el tráfico entrante y saliente gracias a su nuevo módulo de firewall con seguridad avanzada accesible a través de la consola MMC con el mismo nombre. Este módulo de firewall no debe confundirse con el firewall "básico", conocido en entornos XP y accesible mediante el comando firewall.cpl. El firewall básico no permite definir reglas para el tráfico saliente, sino únicamente excepciones para el tráfico entrante. Desde Windows Server 2008 R2, la consola del firewall básico ha evolucionado y permite habilitar la protección dependiendo del tipo de red a la que está conectada la tarjeta de red, a saber: "Dominio", "Privada" o "Pública". Cada interfaz de red tendrá asignado un perfil de-pendiendo de las características definidas por el servicio Reconocimiento de ubicación de red.
A continuación, seleccione las aplicaciones para las que desea autorizar el tráfico entrante. Esto presenta una ventaja en comparación a la apertura de un puerto, pues una aplicación autorizada abre una "brecha" únicamente durante el tiempo de ejecución de la aplicación mientras que una regla aplicada sobre un puerto deja este puerto abierto durante todo el tiempo y nada garantiza que la aplicación que escucha en el puerto no es, en realidad, un malware. También es posible configurar reglas de firewall desde una consola MMC que permita configurar, de forma muy precisa y granular, los flujos, tanto entrantes como salientes. Esto permite adaptarse mejor a la realidad de los requisitos en producción. Se trata de la consola MMC Firewall con seguridad avanzada (accesible en las Herramientas administrativas, mediante el acceso directo wf.msc o bien a través de la opción Configuración avanzada en la consola básica del firewall). El firewall también puede configurarse por línea de comandos mediante el argumento advfirewall del comando netsh. Es posible definir una configuración de firewall distinta para cada uno de los tres perfiles de red existentes en Windows Server. La elección del tipo de perfil se realiza tras la primera conexión de la tarjeta de red y puede encontrarse en la consola Centro de redes y recursos compartidos. Puede cambiar esta definición más tarde, desde el Administrador del servidor - Herramientas - Directiva de seguridad local - Directivas de gestión de
listas de red (será necesario ejecutar un "gpupdate /force" para que se tengan en cuenta, de manera inmediata, las modificaciones realizadas en el entorno). También puede conocer el perfil activo (y para el que se aplicarán las reglas de firewall asociadas) directamente desde la consola MMC de configuración del firewall avanzado.
Recuerde que existen tres perfiles de firewall, son los siguientes: • • •
Un Perfil de dominio: se activa automáticamente cuando su equipo está conectado a un dominio Active Directory. Un Perfil privado: activo cuando su equipo está conectado a una red sin dominio Active Directory (no hay ningún controlador de dominio disponible). Un Perfil público: activo cuando está conectado a redes que ha considerado poco seguras como por ejemplo cibercafés, aeropuertos, y demás lugares donde la seguridad de red no está o está poco garantizada.
Para centralizar la configuración de las reglas de firewall en sus servidores de dominio, le será posible (¡incluso recomendable!) utilizar directivas de grupo. Existen dos conjuntos de directivas para ello:
Configuración del equipo - Directivas - Plantillas administrativas - Red - Conexiones de red - Firewall de Windows: permite configurar las opciones del firewall básico, aplicándose, de este modo, al equipo Windows XP también. Es posible precisar mucho menos que con la siguiente directiva: Configuración del equipo - Directivas - Configuración de Windows - Firewall de Windows con seguridad avanzada: permite configurar reglas de firewall avanzadas como las que vamos a ver más adelante. A continuación, configuraremos una regla de firewall para comprobar toda la extensión de las posibilidades propuestas. Autorice, por ejemplo, la conexión desde Internet hacia el puerto 80/TCP de su servidor que alberga, de momento, un servidor Web Apache. Hemos escogido expresamente un servidor Web de un fabricante externo para facilitar la comprensión de las excepciones del firewall sobre un ejecutable, comprobando que basta con utilizar una regla predefinida creada automáticamente. Va a configurar, aquí, las opciones de manera local en un equipo, pero sepa que podrá realizar la misma operación editando una directiva de grupo en el almacén descrito más arriba. Conéctese de forma local a un servidor o desde puesto cliente con Windows 7/8 con las RSAT y, a continuación: Abra la consola Firewall de Windows con seguridad avanzada (wf.msc desde el menú Inicio - Ejecutar), y haga clic con el botón derecho del ratón en Reglas de entrada y, a continuación, Nueva regla. Se abre un asistente que le permite elegir el tipo de regla de firewall que desea crear. Se ofrecen cuatro opciones: • • •
•
Programa: esta opción le permite definir el ejecutable para el que la acción definida en la etapa siguiente se va a aplicar. Puerto: permite especificar un puerto o una lista de puertos TCP o UDP locales de su equipo. Predefinida: regla correspondiente a un servicio de Windows (útil para puertos abiertos de manera dinámica y aleatoria, no nos obligará a abrir todo el rango de puertos). Personalizada: permite personalizar la regla para, por ejemplo, limitar la autorización únicamente a un programa concreto por un puerto definido.
En este ejemplo, seleccione crear una regla personalizada y, a continuación, haga clic en Siguiente. Defina, ahora, si lo desea, el ejecutable o el servicio que desea autorizar y, a continuación, haga clic en Siguiente. En este ejemplo, indique la ruta completa del ejecutable del servidor Web Apache (%Program-Files%(x86)\Apache Software Foundation\Apache2.2\bin\httpd.exe). También podrá definir el servicio Apache en esta mista etapa del asistente haciendo clic en Personalizar y seleccionando el servicio en cuestión
A continuación, tiene que definir el o los puertos que quiere autorizar (o bloquear) que respondan a sus necesidades. El puerto local se corresponde con el puerto del equipo sobre el que se aplica el perfil de firewall. El puerto remoto es el puerto situado en el equipo que trata de comunicarse con el equipo que tendrá aplicado el perfil de firewall. En este ejemplo, debe autorizar el puerto 80/TCP local de su servidor para autorizar una conexión HTTP clásica.
Observe que también es posible definir una franja de puertos para abrir.
Es posible configurar el ámbito de la regla indicando las direcciones IP origen y destino para las que se le quieren aplicar. En este ejemplo, puede abrir un acceso completo para Cualquier dirección IP. Haga clic en Siguiente. A continuación, se ofrecen tres acciones. Lo que elija se aplicará al tráfico definido en la etapa anterior: • •
•
Permitir la conexión: dicho de otro modo esto permite, en nuestro ejemplo, circular al tráfico entrante hacia el servidor Web Apache. Permitir la conexión si es segura: permite controlar la integridad y la autenticación de cada paquete enviado desde su equipo basándose en el protocolo IPSec. Veremos este punto un poco más adelante en este capítulo en la sección Cifrado IPSec. La opción Exigir el cifrado de las conexiones permite activar IPSec para cifrar los paquetes durante su transmisión. El destinatario de estos paquetes debe a su vez estar configurado para poder enviar y recibir este tipo de tráfico, sin que el diálogo entre los dos equipos sea imposible. Bloquear la conexión: bloquea la condición definida anteriormente en el asistente. En nuestro ejemplo, seleccione Permitir la conexión y, a continuación, haga clic en Siguiente.
Indique, a continuación, los perfiles de conexión para los que quiere aplicar esta regla y haga clic en Siguiente para dar un Nombre a esta regla de firewall.
¡Su regla de firewall se ha creado y ya es efectiva! Aparece en la parte superior de la lista de su consola MMC. En Windows Server 2008 R2/2012, si elige Permitir la conexión si es segura para una regla específica, entonces es posible editar esta regla para definir los usuarios y equipos para los que no se aplicará esta regla.
Observe que si está habilitada la auditoría de las modificaciones de las directivas (mediante la directiva de grupo Configuración del equipo - Directivas - Configuración de Windows - Configuración de seguridad - Directivas locales - Directivas de auditoría), se genera un evento con el número 2004, visible desde la consola Eventvwr.msc en el registro Firewall que se encuentra en Registros de aplicaciones y servicios - Microsoft Windows - Windows Firewall With Advanced Security. Si ha definido una directiva de auditoría avanzada (detallada en el capítulo Dominio Active Directory y disponible, si recuerda, en Configuración del equipo - Directivas Configuración de Windows - Configuración de seguridad - Configuración de directiva de auditoría avanzada), los elementos interesantes relativos al firewall son los siguientes: •
Inicio/cierre de sesión (utilícela únicamente si tiene una directiva IPsec implementada):
• •
Auditar modo extendido de IPsec. Auditar modo principal de IPsec.
•
Auditar modo extendido de IPsec.
•
Acceso a objetos:
• •
Auditar conexión de plataforma de filtrado. Auditar colocación de paquetes de plataforma de filtrado.
•
Cambio en directivas:
• •
Auditar cambio de directiva de plataforma de filtrado. Auditar cambio de directiva del nivel de reglas de MPSSVC.
•
Sistema:
• •
Auditar controlador IPsec. Auditar otros eventos del sistema.
Con esta directiva (en particular, Auditar conexión de plataforma de filtrado y Auditar colocación de paquetes de plataforma de filtrado habilitadas), se produce un evento 4946 presente en el registro de Seguridad cuando se cree alguna regla de firewall.
Verá que muchos de estos elementos afectan, también, a IPsec, puesto que ambos módulos están integrados en la misma aplicación. Este tema se aborda un poco más adelante en este capítulo. También es interesante saber que no se crea ningún archivo de registro por defecto. Puede resultar útil configurarlo para facilitar la detección de cualquier ataque en su servidor (escaneo de puertos abiertos), o la depuración que permita encontrar los puertos que es necesario autorizar para una aplicación concreta (bastará con tener una conexión y supervisar en el archivo de registro los paquetes que no han sido autorizados). Para configurar el archivo de registro, haga clic con el botón derecho del ratón en Firewall de Windows con seguridad avanzada en Equipo local - Propiedades. Haga clic en Personalizar dentro de Registro. A continuación, puede definir una ruta y un nombre para el archivo de registro, un tamaño máximo y el tipo de eventos que desea registrar (paquetes ignorados y/o conexiones de red).
Observe que esta manipulación puede realizarse, también, desde la directiva de grupo y, de este modo, desplegarla al mismo tiempo que las demás reglas configuradas.
3. Securización de las transacciones de red mediante IPsec IPSec es un estándar de seguridad que ofrece autenticación y cifrado de las conexiones. Ambas nociones de seguridad no son indisociables e IPSec puede ofrecer la autenticación sin el cifrado y a la inversa. IPSec funciona sobre la capa de red del modelo OSI, y es capaz de proteger cualquier aplicación de red. El cifrado de las conexiones mediante IPSec hace mucho más complicado atacar un sistema orientado a la red. Si un atacante quisiera, por ejemplo, escuchar (mediante un sniffer) la
red durante la transferencia de un archivo entre dos equipos configurados para utilizar el cifrado IPSec, ¡le será imposible descifrar los archivos intercambiados! La segunda ventaja del protocolo IPSec consiste en proveer una autenticación de los participantes y garantizar la integridad de los datos durante el cifrado de red. IPSec puede, así, autenticar a un cliente de red (mediante una autenticación Kerberos o un certificado, por ejemplo) antes de permitir inicializar la conexión de red. El ataque de tipo "Man in the middle" consiste en que un atacante se hace pasar por el servidor a los ojos del cliente y a la inversa para el cliente a los ojos del servidor. De este modo puede escuchar todo el tráfico entre ambos participantes (remitiéndolo inmediatamente al verdadero destinatario) y a continuación recuperar la contraseña del usuario en una fase de autenticación en el dominio Active Directory por ejemplo. La autenticación IPSec permite impedir este tipo de ataque autenticando los participantes y asegurando que los datos no han sido modificados durante su transporte. Esta autenticación también puede ser muy útil para definir una replicación entre los controladores de dominio que se encuentran en sitios diferentes y así garantizar la integridad de la transacción. Es preciso, también, saber que el protocolo IPSec funciona según dos modos posibles. El modo transporte o el modo túnel. El modo transporte de IPSec permite proteger las comunicaciones entre dos hosts de una misma red privada o entre dos hosts que no están separados por ninguna traducción de direcciones de red (NAT). En este último caso, puede implantar IPSec Nat Traversal (NATT) con la condición de que el servidor NAT y los hosts soportan NAT-T (consulte la RFC 3947). El modo túnel de IPSec protege las comunicaciones entre un host y una red, o de red a red. Este modo es más flexible que el modo transporte. Windows Server 2012 R2 permiten definir reglas de aislamiento (precisando una autenticación) o de cifrado mediante el protocolo IPSec. Esta configuración puede realizarse de forma muy precisa en el mismo lugar que se hacía en las versiones anteriores de Windows Server, es decir en la directiva de grupo Configuración del equipo - Directivas - Configuración de Windows - Configuración de seguridad - Directivas de seguridad IP. La ventaja de esta consola es que puede definir el tipo de tráfico IP que desea autorizar. Si, por el contrario, tiene necesidades mucho más precisas que definir (como, por ejemplo, implementar un filtrado IPsec en su red interna entre dos puestos de distintos departamentos, entre controladores de dominio, etc.), las reglas de seguridad de conexión están mucho mejor adaptadas, pues son mucho más fáciles de implementar y permiten, en particular, filtrar el flujo autorizado a través de esta conexión IPsec.
Puede configurar sus propias reglas de seguridad de conexión desde la misma consola MMC que el firewall de Windows avanzado.
Antes de lanzarse a realizar la configuración de las directivas IPSec, asegúrese de haber comprendido bien y configurado sus directivas IPsec pues, sin ello, corre el peligro de bloquear completamente el acceso a la red de este servidor. Conviene, por tanto, probar las reglas antes de aplicarlas. A continuación, trataremos de aplicar lo que se ha explicado más arriba con un ejemplo. En este ejemplo, va a cifrar el tráfico entre dos equipos. Para ello, siga los pasos siguientes: Abra la consola Firewall de Windows con seguridad avanzada (wf.msc) y, a continuación, vaya al nivel Reglas de seguridad de conexión - Acciones - Nueva regla. Se le ofrecen varios tipos de regla. Para tener una visión completa de las posibilidades seleccione Personalizada y, a continuación, Siguiente. Defina, a continuación, un punto de extremo 1 y un punto de extremo 2 correspondientes a las direcciones IP de cada uno de los equipos. En nuestro ejemplo, el extremo 1 es la dirección IP de nuestro servidor local (192.168.0.1) y el extremo 2 es el servidor remoto (192.168.0.2). A continuación, haga clic en Siguiente. Desde Windows Server 2008 R2 y Windows 7, es posible realizar una administración dinámica de los extremos. Esta funcionalidad la utiliza en particular DirectAccess para los usuarios móviles que poseen una dirección IP dinámica. Obtendrá más información sobre DirectAccess en el capítulo Acceso remoto.
Seleccione, a continuación, las condiciones de autenticación requeridas. En nuestro ejemplo, seleccione Requerir autenticación para las conexiones entrantes y salientes (de este modo, si los dos puestos no están configurados correctamente para dialogar mediante IPsec, no será posible realizar ningún intercambio de información, sea cual sea el emisor de la solicitud) y haga clic en Siguiente. El método de autenticación utilizado se basa en el método definido en los parámetros por defecto de IPSec. Es posible realizar esta configuración en Propiedades de Firewall de Windows con seguridad avanzada - pestaña Configuración IPSec - Personalizar. Puede hacer esto sin tener que cerrar el asistente en curso. Cuando esté en este apartado, aproveche para definir la obligatoriedad del cifrado de los datos haciendo clic en Personalizar en Protección de datos (modo rápido) y marcando la opción Requerir cifrado para todas las reglas de seguridad de conexión que usan esta configuración. Haga clic en Aceptar tres veces para volver a su asistente. En este ejemplo, en la etapa Método de autenticación, haga clic en Personalizar dentro de Opciones avanzadas. Haga clic, a continuación, en Agregar en la primera autenticación y seleccione Clave previamente compartida (este parámetro no está recomendado en una red de producción pero es aceptable en el marco de las pruebas de implementación).
Indique, a continuación, el valor de TestAuthentification relativo a esta clave previamente compartida. Haga clic en Aceptar dos veces y en Siguiente. En un entorno de producción, si los equipos están en un mismo dominio Active Directory, se recomienda usar la autenticación Kerberos puesto que no necesita ninguna configuración particular de los ordenadores afectados. Para equipos que no formen parte del mismo dominio, es preciso establecer una autenticación basada en un certificado. También es posible definir desde la consola los Protocolos y puertos sobre los que se aplicará esta regla, lo que permite definir, de una manera todavía más precisa, el túnel IPsec creado. Esta operación puede realizarse también mediante el comando netsh. Defina los perfiles para los que quiere aplicar esta regla. Es posible marcar los tres perfiles. Indique un nombre para esta regla y haga clic Finalizar. Como hemos impuesto una autenticación en las conexiones entrantes y salientes, a partir del momento en que haga clic en Finalizar, ya no es posible mantener la conexión entre ambos servidores. Conviene, por tanto, crear esta misma regla en el segundo servidor. Para comprobarlo, trate de hacer ping al equipo que posee, de momento, la directiva IPsec desde el segundo equipo, y comprobará que no hay respuesta al ping. Debe configurar el extremo 2 de forma similar a la directiva configurada en el extremo 1. A continuación, comprobará que el ping sí obtiene respuesta, aunque transportado en un flujo completamente cifrado. Puede convencerse abriendo la consola wf.msc y, a continuación, Supervisión Asociaciones de seguridad.
Conclusión Como ha podido ver, Windows Server 2012 R2 posee numerosas funcionalidades de seguridad avanzada. Éstas no tienen por qué suponer una pérdida de productividad. En efecto, muchos de estos parámetros de seguridad son fácilmente accesibles y pueden administrarse de forma centralizada.
Introducción En este capítulo aprenderá a implementar soluciones para garantizar el estado de salud de su red una vez configurada y en producción.
Administración de la copia de seguridad
Pensar que un sistema recién implantado o que ya lo lleve un tiempo no necesita ninguna atención es incorrecto. En efecto, es imposible evitar eventos inesperados en el conjunto del sistema de información. Caídas de servidores, pérdidas de archivos, errores en la manipulación humana, un incendio, etc. Todos estos elementos pueden volver inestable su sistema informático o incluso dejarlo completamente indisponible. Existen varias soluciones proactivas a su disposición, que le permitirán plantar cara al "incidente". Una de ellas es la copia de seguridad. Escoger una estrategia de copia de seguridad adaptada a las necesidades de la empresa es la mejor forma de asegurarse contra una pérdida de los datos. Existen distintos mecanismos de copia de seguridad: •
• •
Completa: este método transfiere al soporte de copia de seguridad una copia de todos los datos asociados a una copia de seguridad, independientemente de la modificación de los datos tras la ejecución de la copia de seguridad anterior. Diferencial: copia todos los datos que han sido modificados desde la última copia de seguridad completa. Incremental: copia todos los datos que han sido modificados desde la última copia de seguridad, bien sea completa o incremental.
Si bien a primera vista puede parecer que las copias de seguridad incremental y diferencial son muy parecidas, en la práctica cada una tiene sus ventajas y sus inconvenientes. Una copia de seguridad diferencial necesita menos medios para realizar una restauración. En efecto, basta con usar la última copia de seguridad completa y la última copia de seguridad diferencial. Ventajas: la restauración de datos es más rápida. Inconvenientes: el volumen de datos de copia de seguridad es mayor y las copias de seguridad tardan más en realizarse. La copia de seguridad incremental toma menos tiempo. Sólo almacena aquellos elementos que se hayan visto modificados desde la última copia de seguridad (completa o incremental). El volumen de la copia de seguridad será menor. Ventajas: las copias de seguridad son más rápidas y necesitan menos capacidad en los medios de almacenamiento. Inconvenientes: la restauración es más lenta pues será necesario utilizar más medios. La restauración requiere la última copia de seguridad completa, más todas las copias de seguridad incrementales que le siguen hasta el punto en que sea necesario restaurar.
En cualquier caso, es necesario que preste mucha atención a sus copias de seguridad completas. Son las que van a determinar el comportamiento de las siguientes copias de seguridad.
1. Windows Server Backup Windows integra, desde la versión 3.1, una herramienta de copia de seguridad llamada NTBACKUP. Con la llegada de Windows Server 2008, se ha visto remplazada. El nombre de su sucesor es: WSB (Windows Server Backup). Ya no vuelva a escribir más ntbackup en el menú Ejecutar, pues en caso contrario recibirá un mensaje de error indicando que la herramienta ya no existe Windows Server Backup proporciona una solución que permite responder a las necesidades de copia de seguridad y de restauración. Puede utilizarla para realizar una copia de seguridad completa de un servidor, también para realizar una copia de seguridad de ciertos volúmenes, ciertas aplicaciones o incluso para guardar solamente el estado del sistema. En caso de producirse algún problema grave, podrá realizar una recuperación bare metal (restauración partiendo de 0). Puede utilizar Windows Server Backup para crear y administrar copias de seguridad de un equipo local o un equipo remoto. Es posible planificar copias de seguridad para que se ejecuten de manera automática. También es posible realizar copias de seguridad puntuales. Windows Server Backup presenta algunos inconvenientes, entre ellos: •
• • •
Es imposible realizar una copia de seguridad de un servidor Exchange Server (salvo para la versión Exchange Server 2007 SP2 que incluye un plug-in que habilita la realización de copias de seguridad). Es imposible realizar copias de seguridad sobre lectores de banda magnética. Es imposible realizar copias de seguridad en memorias flash USB o llaves USB. Sólo puede realizarse copia de seguridad de volúmenes locales en NTFS.
La versión de Windows Server 2012 aporta varios cambios importantes y algunos beneficios a la herramienta Windows Server Backup: •
•
•
Realizar una copia de seguridad o restaurar máquinas virtuales individuales en un host Hyper-V. La versión de Windows Server 2012 R2 permite realizar la copia de seguridad de máquinas virtuales en Linux desde el host. Mejora de la gestión de las versiones de copia de seguridad y de la retención: realizando una copia de seguridad sobre un disco o volumen, ahora tiene la posibilidad de especificar una política de borrado para determinar cuáles son las copias de seguridad que quiere mantener, de cara a gestionar su espacio en disco. Soporte a copias de seguridad de volúmenes de almacenamiento compartidos (CSV: Cluster Shared Volumes).
•
Externalización de la copia de seguridad sobre la plataforma Online Windows Azure (si dispone de un abono. Puede consultar el siguiente enlace si desea más detalles: http://www.windowsazure.com/es-es/services/backup/).
WSB no permite restaurar copias de seguridad realizadas con NTBackup. Existe no obstante una versión disponible para su descarga de la herramienta compatible con Windows Server 2008 R2 y dedicada a las restauraciones: http://support.microsoft.com/kb/974674 a. Instalación de Windows Server Backup
He aquí las etapas para realizar la instalación de Windows Server Backup : En la consola Administrador del servidor, haga clic en Administrar - Agregar roles y características. Haga clic en Siguiente. Seleccione la opción Instalación basada en roles o características y, a continuación, haga clic en Siguiente. Seleccione su servidor y, a continuación, haga clic en Siguiente. En la lista Roles del servidor, haga clic en Siguiente. En la etapa Características marque la opción Copias de seguridad de Windows Server y, a continuación, haga clic en Siguiente.
En la pantalla de confirmación, verifique que se han seleccionado las características deseadas y, a continuación, haga clic en Instalar. Una vez finalizada la instalación, haga clic en Cerrar.
Para instalar la herramienta de copia de seguridad también puede utilizar el comando siguiente: Install-WindowsFeature Windows-Server-Backup b. Creación de una copia de seguridad completa planificada
A continuación, configurará su primera copia de seguridad utilizando el asistente. El objetivo consiste en realizar una copia de seguridad completa de la máquina. Esta copia de seguridad se realizará de forma automática todas las noches a las 23h. Requisitos previos: disponer de un segundo disco duro sobre el que realizar la copia de seguridad. He aquí las etapas que debe seguir:
En la consola Administrador del servidor, haga clic en Herramientas - Copia de seguridad de Windows Server. En el panel izquierdo, seleccione Copia de seguridad local. En la pantalla Copia de seguridad de Windows Server (Local), en el panel derecho, haga clic en Programar copia de seguridad. Haga clic en Siguiente. En la pantalla de selección, seleccione la opción Servidor completo (recomen-dado).
Haga clic en Siguiente. En la lista desplegable Seleccionar hora del día, seleccione 23:00 y, a continuación, haga clic en Siguiente.
En la pantalla que permite seleccionar un tipo de destino, haga clic en realizar copia de seguridad En un volumen y, a continuación, haga clic en Siguiente.
Existen tres opciones: •
•
•
En un disco duro dedicado para copias de seguridad (recomendado): se trata de un disco local que estará dedicado a la copia de seguridad y no se utilizará para almacenar archivos de otro tipo. En un volumen: ofrece la posibilidad de realizar la copia de seguridad de un servidor en uno de los volúmenes de datos. El volumen de destino se excluirá automáticamente de la copia de seguridad, donde puede seguir almacenando datos. En una carpeta de red compartida: permite realizar una copia de seguridad en un espacio de almacenamiento compartido (lo cual supone una buena opción puesto que separa la copia de seguridad de los datos salvaguardados), aunque presenta el inconveniente de que conserva una única copia de seguridad que se eliminará cada vez. Puede almacenar copias de seguridad únicas o copias de seguridad planificadas.
Haga clic en Agregar. Seleccione su segundo volumen de datos y, a continuación, haga clic en Aceptar.
Aparece un mensaje de advertencia que le indica que el volumen de destino se excluirá de la copia de seguridad. Haga clic en Aceptar.
Haga clic en Siguiente. Verifique las opciones seleccionadas y, a continuación, haga clic en Finalizar. Una vez creada la programación de la copia de seguridad, haga clic en Cerrar. Su copia de seguridad queda, así, operativa. c. Creación de la copia de seguridad planificada de una (o varias) carpeta(s)
El objetivo es, aquí, realizar una copia de seguridad sólo de ciertas carpetas de la máquina servidor. Esta copia de seguridad se realizará de forma completa todos los días a las 21h. En la consola Administrador del servidor, haga clic en Herramientas - Copia de seguridad de Windows Server. En el panel izquierdo, seleccione Copia de seguridad total. En la consola Copia de seguridad de Windows Server (Local), en el panel derecho, haga clic en Planificación de la copia de seguridad. Haga clic en Siguiente. Seleccione la opción Personalizada y, a continuación, haga clic en Siguiente.
Haga clic en Agregar elementos para seleccionar los archivos/carpetas que desea incluir en la copia de seguridad. En la ventana de selección, marque la carpeta Users y, a continuación, haga clic en Aceptar.
A continuación, haga clic en Siguiente. Deje la planificación por defecto (Una vez al día a las 21h) y, a continuación, haga clic en Siguiente. Seleccione la opción de hacer la copia de seguridad En un volumen y, a continuación, haga clic en Siguiente. Haga clic en Agregar. Seleccione su segundo volumen y, a continuación, haga clic en Aceptar. Haga clic en Siguiente. Verifique las opciones marcadas y, a continuación, haga clic en Finalizar. Una vez creada la programación de la copia de seguridad, haga clic en Cerrar. d. Herramientas asociadas a WSB y copias de seguridad únicas
WSB ofrece, también, la posibilidad de realizar copias de seguridad no planificadas. Esto puede ser interesante antes de cualquier operación que pueda necesitar de una vuelta atrás (instalar un nuevo producto, eliminar un rol, etc.). Estas copias de seguridad únicas permiten a su vez no incluir obligatoriamente el estado del sistema en la copia de seguridad.
Siguiendo el asistente Hacer copia de seguridad una vez que se encuentra en Copia de seguridad de Windows Server, puede: • •
seleccionar una ubicación de red para realizar la copia de seguridad; escoger entre una copia de seguridad realizada mediante VSS (Volume Shadow Copy) o una copia de seguridad completa VSS.
La copia VSS es útil si utiliza otro sistema de copia de seguridad. En efecto, esto deja los atributos de los archivos intactos. De este modo las copias de seguridad que se realicen con su programa dedicado no se verán afectadas en su rotación. VSS permite a su vez salvaguardar archivos abiertos. La copia de seguridad completa VSS es útil cuando sólo utiliza Windows Server Backup para realizar sus copias de seguridad. Éste, una vez terminada la ejecución, actualiza el histórico de copia de seguridad de los archivos. La herramienta por línea de comandos wbadmin está disponible con las versiones Core y Completa de Windows Server 2012. Permite realizar las mismas tareas que con la interfaz gráfica (observará que el título de la ventana de copia de seguridad Windows Server se llama: wbadmin - Copia de seguridad de Windows Server) del asistente de copia de seguridad o incluso más. Algunos comandos útiles con wbadmin.exe: • • • • •
wbadmin enable backup: permite crear y administrar las copias de seguridad programadas. wbadmin start systemstatebackup: permite realizar una copia de seguridad del estado del sistema. wbadmin start backup: permite ejecutar una copia de seguridad una vez. wbadmin get versions: permite obtener los detalles de una copia de seguridad que ya se ha realizado. wbadmin get items: permite ver cuáles son los elementos que contiene un archivo de copia de seguridad.
Wbadmin tiene la ventaja de permitir incluir los comandos en procesos batch. Estos batch pueden ejecutarse como tareas programadas. A su vez, existe la posibilidad de ejecutar rápidamente una copia de seguridad sobre un almacenamiento en red. Por ejemplo, la siguiente línea de comando permite realizar la copia de seguridad del volumen E en una carpeta compartida de otro equipo: Wbadmin start backup -backuptarget:\\OTROSERVIDOR\CarpetaCompartida include:E: -User:[email protected] -Password:P@ssw0rd
Si desea obtener más información acerca de la sintaxis de wbadmin, vaya a la siguiente dirección: http://technet.microsoft.com/en-us/library/cc754015.aspx
Desde Windows Server 2008, Microsoft ha restringido significativamente las capacidades de su herramienta de copia de seguridad integrada en beneficio de su producto System Center Data Protection Manager (DPM). Este producto, independiente y de pago, ofrece muchas más funcionalidades que WSB. Para obtener más información sobre DPM: http://technet.microsoft.com/en-us/library/hh758173.aspx e. Las instantáneas
Como complemento a las copias de seguridad, puede utilizar las instantáneas (llamadas comúnmente Volume Shadow Copy). Las instantáneas permiten restaurar los archivos que se encuentran en las carpetas compartidas de red. Esta restauración se realiza de forma muy simple y rápida. El principio de funcionamiento es el siguiente: el servidor inicia una captura del estado de los archivos en un momento dado y otra captura más tarde en el tiempo. El sistema va a comparar, a continuación, las diferencias entre ambos estados. Si un archivo se ha suprimido, modificado u otro, entonces el sistema guardará una copia. Es posible realizar varias planificaciones para un mismo volumen en el mismo día. La restricción es que el sistema sólo conserva 64 versiones de un archivo. Las instantáneas están activas a nivel de los volúmenes. Para implementarlas: En la consola Administrador del servidor, haga clic en Herramientas - Administración de equipos. En el panel de Navegación, despliegue Almacenamiento - Administración de discos. Haga clic con el botón derecho en el volumen para el que quiere activar las instantáneas y, a continuación, seleccione Propiedades. Haga clic en la pestaña Instantáneas.
Desde esta ventana puede activar o desactivar las instantáneas. También puede crear una instantánea de forma manual simplemente haciendo clic en el botón Crear ahora. La configuración avanzada se puede administrar haciendo clic en Configuración... y tras haber seleccionado un volumen. Una vez dentro puede especificar la programación de la instantánea, su área de almacenamiento así como su tamaño máximo. Haga clic en Configuración.
Seleccione un tamaño límite (o ilimitado) para realizar las instantáneas. Seleccione la ubicación del almacenamiento (puede ser interesante seleccionar otro medio de almacenamiento distinto al volumen desde el que se hacen las instantáneas para utilizar un medio de almacenamiento de bajo coste como, por ejemplo, un disco duro USB). Haga clic en Programación.
Por defecto, las instantáneas se realizan todos los días laborables 2 veces al día (a las 7h y a las 12h). Ajuste estos valores en función de sus necesidades y teniendo en mente que sólo se conservarán 64 versiones de la instantánea. Haga clic en Aceptar para validar la programación. Haga clic en Aceptar para validar la configuración de la instantánea. Puede hacer clic en el botón Crear para crear una instantánea de manera inmediata. Si intenta ver el contenido de esta instantánea, verá que está vacía. En efecto, las instantáneas utilizan una imagen en un instante T para realizar la copia de seguridad de los datos que se han modificado desde la última instantánea. Un archivo que ya existiera en la instantánea antes de implementar la copia de seguridad y que jamás se haya modificado, nunca podrá verse en las versiones anteriores.
Para restaurar una instantánea, vaya a la pestaña Versiones anteriores en las propiedades de una carpeta padre o, directamente, sobre el archivo deseado si todavía está presente (a continuación se muestra una captura de pantalla que ilustra esta posibilidad).
2. Restaurar los datos Ahora que sabe cómo realizar una copia de seguridad de sus datos, vamos a ver cómo restaurarlos. Para restaurar información utilizando WSB, debe ser miembro del grupo Operadores de copia de seguridad o del grupo Administradores del equipo. a. Restaurar archivos y/o carpetas
Para restaurar una carpeta:
En la consola Administrador del servidor, haga clic en Herramientas - Copia de seguridad de Windows Server. En el panel derecho, haga clic en Recuperar. Especifique el servidor sobre el que se encuentra la copia de seguridad que se utilizará para recuperar los datos y, a continuación, haga clic en Siguiente. Seleccione, utilizando el calendario, la copia de seguridad que desea restaurar y, a continuación, haga clic en Siguiente. Seleccione el tipo de dato que desea recuperar y, a continuación, haga clic en Siguiente. Seleccione el elemento (archivos o carpetas) que desea restaurar y, a continuación, haga clic en Siguiente. Seleccione los elementos que desea recuperar y, a continuación, haga clic en Siguiente. Especifique, a continuación, el lugar donde desea restaurar la información, si desea borrar los archivos de destino, o bien realizar una copia, o no recuperar archivos que ya existan en el espacio de destino. Especifique, a su vez, si deben restaurarse los permisos NTFS.
Haga clic en Siguiente.
En la pantalla de confirmación, verifique los elementos seleccionados y, a continuación, haga clic en Recuperar. Una vez recuperados los elementos, haga clic en Cerrar. b. Restaurar el estado del sistema
Si ocurriera un fallo importante en el sistema, debería restaurarlo. Esta operación es similar a una restauración completa, aunque la diferencia es que no restaura los volúmenes que contienen datos. Sólo se restauran los volúmenes críticos. Esta operación puede realizarse sobre la misma máquina o, en el caso de un reemplazo o renovación de hardware, sobre una máquina diferente. Preste atención, la máquina de reemplazo debe poseer características de hardware similares. La restauración del sistema es la forma más práctica de reparar los roles de servidores corruptos o incluso de restaurar Active Directory. Preste atención, no es posible realizar una restauración parcial del estado del sistema.
La restauración del estado del sistema sobre un controlador de dominio realiza una restauración no autoritaria de Active Directory. He aquí las etapas que debe seguir para restaurar el estado de su sistema: Inicie su servidor desde una imagen de instalación (DVD, llave USB, red) de Windows Server 2012. Seleccione los parámetros regionales y, a continuación, haga clic en Siguiente. Haga clic en Reparar el equipo. Haga clic en Solucionar problemas. Haga clic en Recuperación de imagen del sistema. Seleccione su sistema operativo. Si no existe ninguna copia de seguridad disponible en local, aparecerá el siguiente mensaje:
Haga clic en Cancelar. Haga clic en Siguiente para seleccionar una imagen de sistema. Haga clic en Opciones avanzadas. Haga clic en Buscar una imagen de sistema en la red. Aparece la siguiente advertencia, haga clic en Sí.
Al utilizarse una imagen almacenada en la red para restaurar el sistema, es preciso disponer de un servidor DHCP que permita obtener una dirección IP válida en la red de trabajo. Indique la ubicación de la copia de seguridad y, a continuación, haga clic en Aceptar. Indique la información de identificación para conectarse al recurso compartido (en este ejemplo, el recurso compartido se encuentra en un servidor llamado DC1) y, a continuación, haga clic en Aceptar.
Seleccione la copia de seguridad que desea restaurar y, a continuación, haga clic en Siguiente.
Seleccione, a continuación, las opciones facultativas (para dar formato y reparticionar los discos, instalar controladores, etc.) y, a continuación, haga clic en Siguiente. Haga clic en Finalizar, y, a continuación, haga clic en Sí para iniciar la restauración. Espere a que el sistema reinicie automáticamente para que la restauración termine por completo.
3. Almacenamiento a. Conjunto RAID
Existe un método alternativo de asegurar los datos. Muy extendida en los entornos de servidores y en expansión en entornos particulares, esta tecnología se llama RAID (Redundant Array of Independent Disks). Desde un punto de vista simplificado, esta tecnología permite almacenar la información sobre discos duros múltiples con el objetivo de mejorar, en función del tipo de RAID seleccionado, la tolerancia a fallos y/o el rendimiento del conjunto. En este capítulo sólo vamos a describir los tres niveles de RAID estándar propuestos por Windows Server 2012 R2, a saber: RAID 0, RAID1 y RAID5. En función del nivel de RAID elegido, obtendrá:
• • •
Bien un sistema de reparto de carga que mejora su rendimiento (RAID 0). Bien un sistema de redundancia que dota al almacenamiento de datos de cierta tolerancia a fallos de hardware (RAID 1). O bien ambas características a la vez (RAID 5).
El sistema RAID es capaz por tanto de gestionar el reparto de carga y la coherencia de los datos. Este sistema de control puede ser puramente lógico, o utilizar un hardware dedicado. En RAID lógico, el control del RAID se realiza íntegramente en la capa lógica del sistema operativo. Esta capa se intercala entre la capa de abastecimiento de hardware (controlador) y la capa del sistema de archivos. En el caso de RAID por hardware, existe una tarjeta o un componente dedicado a la gestión de las operaciones. Desde el punto de vista del sistema operativo, el controlador RAID por hardware ofrece una virtualización completa del sistema de almacenamiento. El sistema operativo considera cada volumen RAID como un disco que no conoce sus constituyentes físicos. Características de los niveles de RAID: •
•
•
El RAID0, o conjunto dividido, es el que tiene mejor rendimiento; por el contrario es el menos fiable. Ofrece un conjunto de discos. Por ejemplo tres discos de 500 GB en RAID0 le ofrecen un volumen de 1,5 TB. El inconveniente principal de esta tecnología, si uno de los discos falla, es que los datos situados en los demás también se pierden. El RAID1, o espejo, proporciona buenos rendimientos en la escritura asegurando tolerancia a fallos. En el caso de dos discos en RAID1, la información se escribe de forma idéntica en ambos. Dos discos de 500 GB en RAID1 le ofrecen un volumen de 500 GB. El segundo disco sirve como «réplica» del primero. El rendimiento global es algo inferior a un RAID0. El RAID5, o agregado de conjuntos con paridad es el que presenta mejor rendimiento en términos de lectura. La información se reparte en los distintos discos de modo que no se pierdan datos en caso de fallo de uno de los discos. Este nivel RAID requiere un mínimo de tres discos. Tres discos de 500 GB configurados en RAID5 le ofrecen un espacio de almacenamiento de 1 TB.
En Windows Server 2012, las operaciones de configuración de los volúmenes en RAID se hacen desde la consola Administración de equipos. A continuación, hay que navegar en la arborescencia de almacenamiento. Las opciones propuestas le permiten agregar fácilmente un volumen en espejo o crear un conjunto agregado.
Para poder configurar volúmenes en RAID en Windows Server 2012, es preciso haber convertido los discos como dinámicos previamente.
Windows Server 2012 y Windows Server 2012 R2, igual que sus versiones anteriores, no permite configurar el volumen de sistema en RAID 5. b. Espacios de almacenamiento
Los espacios de almacenamiento, aparecidos con Windows Server 2012, proveen soluciones de almacenamiento rentables, altamente disponibles, con capacidad de evolución y flexibles para despliegues de soluciones de almacenamiento críticas (virtuales o físicas) en la empresa. Esta tecnología permite agrupar discos físicos y crear discos virtuales sobre ellos. Para las pequeñas empresas, los espacios de almacenamiento ofrecen la posibilidad de crear un almacenamiento compartido de bajo coste. Si bien las funcionalidades son parecidas a las de una SAN (Storage Area Network), los espacios de almacenamiento son, no obstante, mucho más flexibles de utilizar. Otra ventaja del uso de espacios de almacenamiento se presenta cuando necesita reconstruir un disco físico defectuoso. En los sistemas RAID tradicionales, esto puede llevar un tiempo considerable. Con Windows Server 2012 R2, verá estos tiempos considerablemente reducidos gracias a una técnica de reconstrucción en paralelo. Este proceso utiliza los discos sanos restantes para reponer los datos que estaban almacenados sobre el disco defectuoso. Resulta extremadamente práctico, en lugar de utilizar discos hot spare, utilizar en su lugar discos de reserva en el espacio de almacenamiento, los cuales pueden explotarse, de este modo, mediante procesos de reconstrucción en paralelo. Esto permite no sólo ofrecer un mejor rendimiento de entrada/salida para la actividad de almacenamiento de la producción (a diferencia de un RAID que suele degradar sobre un sistema SAN clásico) sino también hacer que su empresa sea menos vulnerable mientras se ejecuta un proceso de reconstrucción (por ejemplo, durante la reconstrucción de un RAID5 degradado debido a que un segundo disco se ha vuelto irreparable). Como demostración, Microsoft muestra, en una sesión TechEd, la reconstrucción de un RAID compuesto por ocho discos de 3 TB en 50 minutos con una tasa de transferencia superior a 800 MB/s. Windows Server 2012 R2 incluye otras mejoras con los espacios de almacenamiento, en particular: •
•
Storage Tiers: en un entorno con un almacenamiento mixto de discos rápidos (de tipo SSD) y discos menos rápidos (de tipo SATA), el sistema será capaz de medir, automáticamente, la velocidad de los discos y su actividad con el fin de redirigir los flujos de almacenamiento hacia aquellos discos que poseen un mejor rendimiento, todo de forma transparente. Si la información almacenada resulta poco utilizada, se desplazará hacia el almacenamiento menos rápido, y a la inversa, si se trata de información accedida con frecuencia. Write-back cache: basado en el mismo principio que el Storage Tiers, cuando se detectan picos de actividad, el sistema podrá utilizar el almacenamiento rápido
•
(SSD) antes de escribir en los discos clásicos para actuar como buffer e impedir una pérdida de información. Storage QoS (Storage Quality of Service): esta funcionalidad se habilita en la capa vhdx para permitir limitar las IOPS (Input/Output Operations Per Second) máximas en un disco duro virtual. Es, también, posible definir contadores para enviar notificaciones cuando las IOPS mínimas para un disco no se están respetando.
4. Nuevo sistema de archivos a. Resilient File System (ReFS)
A pesar de las numerosas ventajas que ofrece NTFS respecto a los primeros sistemas de archivos FAT, existe desde 1993. Muchos usuarios de productos Windows Server esperan, desde hace ya bastante tiempo, una evolución del sistema de archivos del sistema operativo de Microsoft. Windows Server 2012 aporta este nuevo sistema de archivos: ReFS, o sistema de archivos resiliente, que tiene en cuenta muchas funcionalidades de NTFS aunque abandona algunas de ellas como, por ejemplo, la compresión de archivos, el sistema EFS (Encrypting File System) y las cuotas de disco. A cambio, ReFS ofrece la verificación de datos y la corrección automática. Este nuevo sistema de archivos se ha elaborado, especialmente para gestionar cantidades enormes de datos. Se ha diseñado para funcionar con espacios de almacenamiento lógico reducibles/extensibles. El nuevo sistema de archivos favorece su capacidad de evolución, teniendo en cuenta hasta 264 clústeres o lo que es lo mismo, en teoría, ¡volúmenes de hasta 1 YB (Yottabyte)! Este nuevo sistema de archivos ReFS puede detectar automáticamente la corrupción de datos y realizar reparaciones necesarias sin tener que desconectar el volumen. CHKDSK se convierte, por lo tanto, en una herramienta obsoleta con este sistema de archivos, ¡se terminaron los checkdisk interminables! Los objetivos principales de ReFS son: •
•
• •
Mantener un grado elevado de compatibilidad con un subconjunto de funcionalidades NTFS. Las funcionalidades que se han adoptado se conservan, eliminando aquellas que aportan un valor mínimo a cambio de una complejidad importante en el sistema de archivos. Verificar y corregir automáticamente errores en los datos. Los datos pueden corromperse debido a una serie de causas y deben poder verificarse y, si es posible, repararse automáticamente. Optimizar la capacidad de evolución del almacenamiento. No perder, jamás, la disponibilidad del sistema de archivos. Por ejemplo, en el caso de que ocurra algún problema de corrupción de datos, supone una ventaja aislar el
•
defecto permitiendo el acceso al resto del volumen. Debe ser posible recuperar la máxima cantidad de datos posible en cualquier momento y siempre en línea. Ofrecer una arquitectura de resiliencia completa, extremo a extremo, cuando se utiliza de forma conjunta con espacios de almacenamiento.
Las funcionalidades claves de ReFS son las siguientes (observe que algunas de estas funcionalidades se ofrecen junto con los espacios de almacenamiento): • • •
• • • • •
Integridad de los metadatos con sumas de control (checksums). Aportar un modelo robusto de escritura transaccional para las actualizaciones de los discos (también conocido como copy-on-write). Soporte para grandes volúmenes, archivos y carpetas. ReFS está diseñado para funcionar con juegos de datos extremadamente grandes (principalmente en cantidad, observe que la longitud de las rutas también se ha alargado). Puesta en común del almacenamiento y la virtualización de espacios de almacenamiento para facilitar la gestión del sistema de archivos. Entrelazado de datos para un buen rendimiento (es posible administrar el ancho de banda) y una redundancia para la tolerancia a fallos. Limpieza de los discos para la protección contra los errores de discos latentes. Resiliencia frente a la corrupción para obtener la disponibilidad de volumen máxima. Pools de almacenamiento compartidos entre las máquinas para obtener la tolerancia a fallos y un reparto de carga suplementario.
Es posible seleccionar este formato de sistema de archivos en el momento en que formatee un volumen.
Windows Server 2012 no permite convertir un volumen NTFS al formato ReFS.
b. Desduplicación de datos
Presentación de la desduplicación de datos En la empresa, el volumen de datos basados en archivos aumenta relativamente rápido. Si bien el coste del almacenamiento en disco duro ha bajado considerablemente, éstos no evolucionan lo suficientemente rápido como para compensar dicho crecimiento. El objetivo de la desduplicación de datos es almacenar más datos en un espacio limitado cortando los archivos en fragmentos de tamaño variable (de 32 a 128 KB), identificando aquellos segmentos duplicados y conservando una copia única de cada segmento. Las copias redundantes del segmento se remplazan por una referencia de la copia única, y los segmentos se organizan en archivos de contenedor y los contenedores se comprimen para ofrecer una optimización del espacio ocupado. Para aclarar el funcionamiento, tomemos el ejemplo de dos archivos de texto (Archivo 1 y Archivo 2) en los que existe una porción idéntica. Simplificando su contenido, veamos a qué podría corresponderse:
Cada archivo posee su propia información: nombre, atributos, permisos, etc. Pero también su propio contenido. Si bien los archivos son, en parte, idénticos (secciones A y B), las porciones similares se almacenan dos veces. Con la desduplicación de datos, el sistema separa la parte de Metadatos de la parte de Datos. Se modifican completamente los archivos y se reescriben para crear un puntero, en cada archivo, hacia su contenido (véase la ilustración que aparece a continuación).
El sistema detectará, en primer lugar, que el contenido ya existe y está almacenado y clasificado. No almacenará, de hecho, para el segundo archivo más que la parte que no estuviera registrada previamente en el espacio de almacenamiento, en este caso el segmento Z. Funcionalidades clave de la desduplicación de datos Windows Server 2012 R2 provee una desduplicación de datos mejorada gracias a las siguientes funcionalidades: •
•
•
Optimización de la capacidad: la desduplicación de datos, en Windows Server 2012, permite almacenar más datos en un espacio físico inferior. La desduplicación de datos se basa en una segmentación de tamaño variable en subarchivos y en la compresión de los datos. Utilizadas de manera conjunta, ambas tecnologías permiten dividir el almacenamiento entre dos en servidores de archivos genéricos y entre 20 (como máximo) en datos de virtualización. Capacidad de evolución y rendimiento: la desduplicación de datos de Windows Server 2012 permite una gran capacidad de evolución, siendo eficaz en términos de uso de los recursos, y es no intrusiva. Esta funcionalidad puede ejecutarse de manera simultánea en decenas de grandes volúmenes de datos clave sin afectar a las demás cargas de trabajo en el servidor, aplicando límites a los recursos de la unidad central y controlando la memoria consumida. Además, los usuarios con poder tendrán total flexibilidad para fijar las horas de ejecución de la desduplicación de datos, especificar los recursos disponibles a tal efecto y establecer directivas de selección de archivos. Fiabilidad e integridad de los datos: cuando se aplica la desduplicación de los datos, es vital mantener su integridad. Windows Server 2012 explota la suma de control, la coherencia y la validación de identidad para garantizar la integridad de los datos. En el caso de datos o metadatos que posean un gran número de referencias, la desduplicación de datos de Windows Server 2012 asegura la redundancia de la información conservando varias copias del archivo con el objetivo de permitir recuperarlo en caso de que se corrompa.
•
•
Eficacia del ancho de banda compatible con BranchCache: cuando asocia BrachCache a la desduplicación de datos, se aplican las mismas técnicas de optimización a los datos que se transfieren por la red extendida a una filial. Esto permite disfrutar de unas descargas de archivos más rápidas y una reducción de consumo en el ancho de banda. Optimización de la gestión con herramientas familiares: Windows Server 2012 dispone de una funcionalidad de optimización integrada con el Administrador del servidor y con Windows PowerShell. Los parámetros por defecto pueden traducirse en ahorros inmediatos. Su configuración puede, incluso, mejorar estas ganancias. Utilice fácilmente los comandos de Windows PowerShell para iniciar o programar una tarea de optimización posterior.
Windows Server 2012 y 2012 R2 no permiten configurar la desduplicación de datos en un volumen ReFS. Mejoras aportadas por Windows Server 2012 R2 • • • •
•
Optimización de archivos abiertos (a diferencia de Windows Server 2012, que no soporta el procesamiento de archivos abiertos y, por tanto, bloqueados). Mejora del rendimiento de lectura/escritura: los archivos desduplicados se abren, en lo sucesivo, de forma más rápida. Mejora de los resultados obtenidos: la ganancia obtenida mediante la desduplicación es más importante. Soporte de archivos VHD para VDI (Virtual Desktop Infrastructure): con Windows Server 2012, las recomendaciones eran no habilitar la desduplicación en un servidor Hyper-V. La filosofía es, en lo sucesivo, separar el almacenamiento de los nodos miembros del clúster en un servidor dedicado. Es, en adelante, posible habilitar la desduplicación de archivos de máquinas virtuales sobre este servidor de almacenamiento. Soporte de volúmenes compartidos de clúster (CSV : Cluster Shared Volumes): Windows Server 2012 no soporta la activación de la desduplicación en volúmenes CSV. Con Windows 2012 R2 es posible, aunque conservando el principio del almacenamiento en un servidor de archivos (como con VDI) y no asociado directamente (fibra, iSCSI).
Limitaciones de la desduplicación de datos Las pruebas muestran buenos resultados en lo que afecta a la desduplicación de datos (no sólo en tecnologías Microsoft), aunque se basan, sin duda, en casos particularmente optimistas. Antes de su implementación, conviene tener en cuenta los siguientes elementos:
•
•
•
•
El rendimiento de las copias de seguridad/restauraciones de datos en volúmenes muy grandes son, prácticamente, incalculables: los rendimientos vinculados a estas operaciones se encuentran, no obstante, mejorados, sin contar el tiempo de indisponibilidad propio de una restauración en caso de ocurrir algún error importante. La eficacia de la desduplicación de datos en volúmenes muy grandes está muy limitada en casos, por ejemplo, de datos estructurados como Exchange o SQL y está mejor dirigida a estructuras de tamaño pequeño o mediano. Despilfarro de recursos: en el caso de que pocos datos puedan desduplicarse, el ciclo de trabajo del proceso causará una carga de trabajo en la máquina inútil, con pocos o ningún resultados. Poco o ningún control sobre el proceso: no existe, a día de hoy, la posibilidad de afinar el comportamiento del proceso o incluso de intervenir manualmente sobre él.
Implementación de la desduplicación de datos En un servidor de archivos Windows Server 2012, la funcionalidad de desduplicación de datos no está disponible por defecto. Va a ser necesario, por lo tanto, instalarla siguiendo los siguientes pasos: En la consola Administrador del servidor haga clic en Administrar - Agregar roles y características. En la pantalla Antes de empezar, haga clic en Siguiente. Seleccione Instalación basada en roles o características y, a continuación, haga clic en Siguiente. Seleccione su servidor en la lista y, a continuación, haga clic en Siguiente. Despliegue el árbol Servicios de archivos y almacenamiento - Servicios de iSCSI y archivo y, a continuación, marque la opción Desduplicación de datos. Haga clic en Siguiente. En la etapa de selección de características, haga clic en Siguiente. Haga clic en Instalar. Una vez instalada la funcionalidad, haga clic en Cerrar. Es momento de configurar la desduplicación de datos en los volúmenes deseados. Para ello:
Se recomienda encarecidamente realizar copias de seguridad regulares de los datos importantes durante la implementación de la desduplicación. En la consola Administrador del servidor, en el panel de navegación, haga clic en Servicios de archivos y almacenamiento. Haga clic en Volúmenes. Haga clic con el botón derecho sobre el volumen en el que desea activar la desduplicación de datos y, a continuación, seleccione Configurar desduplicación de datos.
Cuando habilite la desduplicación de datos con Windows Server 2012, el retardo por defecto para realizar la operación de desduplicación de los archivos era de 5 días. Los archivos se procesan, desde su escritura en el servidor, pasado cierto tiempo, que podrá adaptar en función de sus necesidades, recursos, y demás condiciones de trabajo. Con Windows Server 2012 R2, el valor está fijado por defecto a 5 días, y no es posible modificarlo. En efecto, con Windows Server 2012, los usuarios rebajaban este valor a 3
días, lo que impedía un funcionamiento correcto del proceso de desduplicación, siendo el valor demasiado bajo (véase la conclusión de los ingenieros de Microsoft al respecto como resultado del feedback de sus clientes). También tiene la posibilidad de excluir archivos de este proceso. Por ejemplo, los archivos mp3 y mp4, sobre los que ya se ha ejecutado un procesamiento previo similar mediante las herramientas que los gestionan. No resulta, por tanto, útil configurar la desduplicación para estas extensiones, y el proceso no permite liberar una cantidad de espacio significativa. Del mismo modo, puede excluir carpetas completas. Con Windows Server 2012 R2, existe una opción en la configuración de la desduplicación. Puede, en lo sucesivo, especificar si se trata de un servidor de archivos "clásico" o un servidor VDI (Virtual Desktop Infrastructure). En función de la opción elegida, las extensiones de los archivos excluidas por defecto para adaptarse al tipo de servidor (de archivos edb y jrs para un servidor de archivos; archivos bin, vsv, slp, xml, tmp, hrl y hru para un servidor VDI). Preste atención, la desduplicación de datos es una funcionalidad que procesará, potencialmente, todos los datos de un volumen seleccionado. Una planificación cuidadosa debe permitir determinar si su servidor y sus volúmenes son candidatos aptos para la desduplicación, antes de utilizar esta funcionalidad. Para definir la planificación, haga clic en Establecer programación de desduplicación....
Por defecto, cuando se habilita la desduplicación de datos se produce un procesamiento de optimización como tarea de fondo. Esta optimización utiliza un perfil de trabajo reducido con el objetivo de no perturbar a los sistemas en producción. Puede, por el contrario, resultar útil afinar estos procesamientos asignando más recursos al proceso de desduplicación en días y franjas horarias definidos. Estas franjas se configuran mediante las opciones Habilitar optimización de rendimiento y Crear una segunda programación para la optimización del rendimiento visibles en la captura de pantalla anterior. Haga clic en Aceptar y, de nuevo, en Aceptar para validar las opciones seleccionadas y, de este modo, habilitar la desduplicación de datos en el volumen seleccionado.
Recurrir a la desduplicación de datos sobre archivos replicados mediante replicación DFS no supone ningún problema. Sólo se actualizarán aquellas particiones de archivos que se hayan modificado desde la última replicación.
Administrar las actualizaciones 1. Presentación de WSUS Se trata de otro medio de protegerse contra eventuales problemas (en particular de seguridad) y asegurarse de que sus equipos cliente y servidores están bien actualizados. En pequeños parques de servidores, configurar en cada puesto las actualizaciones en modo automático es suficiente. En grandes parques informáticos, en los que la configuración de las máquinas es estricta, es en ocasiones necesario probar un parche antes de desplegarlo de forma centralizada en todos los puestos. Microsoft pone a su disposición, de manera gratuita, la herramienta WSUS (Windows Server Update Services) en versión 3.0 con SP2 (WSUS es un rol independiente en Windows Server 2012 y puede, por lo tanto, instalarse desde la consola Administrador del servidor sin tener que descargarlo por separado). Esta herramienta permite desplegar las últimas actualizaciones para los productos Microsoft. Utilizándola, podrá administrar de forma integral la distribución de las actualizaciones (hora de despliegue, qué parches se desplegarán, etc.). Dispone, gracias a WSUS, de una herramienta de centralización y de seguimiento de la gestión de las actualizaciones de Windows. Le será posible de un golpe de vista saber qué equipo no ha recibido las últimas actualizaciones necesarias y enviárselas. Siempre puede utilizar una herramienta de terceros para gestionar las actualizaciones de aplicaciones externas. Tenga en mente que el navegador de Internet y los plugins asociados (Adobe Flash Player, Adobe Reader, Java, etc.) son la principal puerta de entrada para un virus. Es, por tanto, importante actualizar de manera regular estos componentes mediante las directivas de grupo o herramientas externas. Según su infraestructura, WSUS puede actualizarse a través del sitio Microsoft Update o incluso con otro servidor WSUS. Los clientes compatibles con WSUS aparecen a partir de Windows 2000 SP4. Además de los sistemas operativos, WSUS permite gestionar las actualizaciones de las aplicaciones de Microsoft más corrientes (SQL Server, Exchange Server, Office, etc.). Observe que, del lado cliente, Windows 8.1 aporta una mejora. En efecto, cuando los usuarios de dispositivos reportan o ignoran las actualizaciones del sistema, los dispositivos pueden no estar en conformidad con las políticas de seguridad de la empresa. En Windows 8.1, Windows Update realiza automáticamente las actualizaciones del sistema. Si es necesario reiniciar, el usuario que está conectado al equipo se conecta, automáticamente, de
nuevo, y las aplicaciones en curso antes de realizar la actualización se reinician, con la sesión desbloqueada (utilizando Secure Desktop). Este reinicio automático requiere que las credenciales del usuario conectado puedan almacenarse en caché, y que BitLocker esté habilitado y soporte este tipo de reinicio sin intervención.
2. Instalación de WSUS A continuación se muestran las etapas que debe realizar para instalar WSUS. Observe que esta etapa tiene, como requisito previo, una conexión a Internet. En la consola Administrador del servidor, haga clic en Administrar - Agregar roles y características. En la pantalla Antes de empezar, haga clic en Siguiente. Seleccione Instalación basada en roles o características y, a continuación, haga clic en Siguiente. Seleccione su servidor en la lista y, a continuación, haga clic en Siguiente. Marque la opción Windows Server Update Services. En el cuadro de diálogo, haga clic en Agregar características.
Haga clic en Siguiente cinco veces hasta llegar a la pantalla Servicios de rol. Deje marcadas las opciones WID Database y WSUS Services y, a continuación, haga clic en Siguiente.
Aquí, WID Database significa que se va a instalar la base de datos de configuración WSUS en la base de datos interna de Windows (WID por Windows Internal Database). Para instalar la base de datos en un servidor SQL basta con marcar la opción Base de datos. Obviamente, no es posible marcar al mismo tiempo las opciones WID Database y Base de datos. Los administradores que quieran tener un mayor control sobre la base de datos preferirán utilizar SQL Server. Indique la ubicación del almacenamiento para las actualizaciones y, a continuación, haga clic en Siguiente.
Verifique las opciones marcadas y, a continuación, haga clic en Instalar. Una vez terminada la instalación, haga clic en Cerrar. En la consola Administrador del servidor, haga clic en Herramientas - Windows Server Update Services. Se abre el asistente de instalación de WSUS.
Haga clic en Ejecutar. Una vez terminadas las tareas de post-instalación, haga clic en Cerrar. Se abre el asistente de configuración, haga clic en Siguiente. Seleccione participar en el programa de mejora o no y, a continuación, haga clic en Siguiente. Seleccione la opción Sincronizar desde Microsoft Update (salvo si ya dispone de un servidor WSUS y desea utilizarlo como referencia para el que está instalando). Haga clic en Siguiente. Si no utiliza un proxy, no indique nada en la opción de proxy. A continuación, haga clic en Siguiente. Si utiliza un proxy, esta página le permite detallar su configuración. Haga clic en Iniciar conexión para que WSUS recupere la información disponible para la descarga (esta etapa resulta algo larga). Una vez realizada la conexión, haga clic en Siguiente. Seleccione los idiomas utilizados por los distintos sistemas operativos (en nuestro ejemplo el español) si no está hecho automáticamente y, a continuación, haga clic en Siguiente. WSUS descargará, en lo sucesivo, las actualizaciones en todos los idiomas seleccionado. Prevea, por lo tanto, un espacio en disco acorde al número de idiomas diferentes seleccionados. En la lista de selección de productos, seleccione los productos que desea actualizar y, a continuación, haga clic en Siguiente. Seleccione la clasificación de las actualizaciones deseadas, y, a continuación, haga clic en Siguiente. Seleccione su modo de sincronización (manual o automático), y, a continuación, haga clic en Siguiente. Marque la opción Iniciar la sincronización inicial si desea iniciar la sincronización de inmediato y, a continuación, haga clic en Siguiente.
3. Uso de WSUS Una vez instalado WSUS, se abre automáticamente la consola MMC de administración. Puede controlar rápidamente el estado de las actualizaciones de su parque así como las actualizaciones en espera de aprobación.
Puede acceder a esta consola desde la consola Administrador del servidor haciendo clic en Herramientas - WSUS (Windows Server Update Services). Antes que nada, es preciso configurar los clientes para utilizar el servidor WSUS recién instalado. Si dispone de un dominio Active Directory, cree una nueva directiva de grupo GPO a nivel de dominio o de una OU. Si su PC no está en un dominio, utilice el comando gpedit.msc. En el Editor de objetos de directivas de grupo, despliegue el nodo Configuración del equipo - Directivas - Plantillas administrativas - Componentes de Windows - Windows Update. En el panel derecho, edite el parámetro Especificar la ubicación del servicio Windows Update en la Intranet. Marque la opción Habilitada y, a continuación, indique la URL de acceso a su servidor WSUS en ambos campos. Por ejemplo: http://dc2012.MiEmpresa.Priv:8530 Preste atención, piense en especificar el puerto que utiliza el sitio Web de actualizaciones. Haga clic en Aplicar, y, a continuación, en Aceptar. A continuación, edite el parámetro Configuración actualizaciones automáticas.
Marque la opción Habilitada, y, a continuación, indique la configuración de las actualizaciones automáticas (notificar para descarar e instalar, descargar y planificar la instalación, etc.). Elija a continuación los días y las horas para instalar las actualizaciones.
En este caso se ha escogido la opción 3 para aplicarla a los servidores. Este parámetro permite gestionar, de manera manual, la instalación de las actualizaciones y la hora de reinicio posterior de los servidores. Para un equipo de usuario se optará por la opción 4, con el objetivo de estar seguro de que las actualizaciones se instalan. El usuario tendrá, no obstante, la posibilidad de posponer el reinicio del equipo si está conectado. Valide haciendo clic en Aplicar, y, a continuación, en Aceptar. Cierre, a continuación, el editor de directivas de grupo.
Puede forzar el refresco de la directiva de grupo en el puesto cliente mediante el comando gpupdate. Para forzar la detección por WSUS de un equipo cliente, ejecute desde el puesto el siguiente comando: wuauclt /detectnow. Desde la consola WSUS (Windows Server Update Services) puede, a continuación, visualizar el estado del despliegue de las actualizaciones. Despliegue el árbol y haga clic en Actualizaciones.
Hay disponibles vistas preconfiguradas. Estas vistas responden a las necesidades de la mayoría de los administradores. Puede no obstante crear vistas personalizadas si necesita información particular. Los criterios son numerosos: por producto, por clasificación, por grupos, etc. Seleccionando una de las vistas preconfiguradas, o una de las que ha creado, tendrá la posibilidad de aprobar o rechazar las actualizaciones (una cada vez, o por lotes) para permitir, a las máquinas cliente de WSUS, recuperarlas. Puede ver, a continuación, el ejemplo de una vista personalizada seleccionando las actualizaciones para Windows Server 2012. Aquí, las actualizaciones se clasifican por Fecha de llegada. Tiene la posibilidad de seleccionar varias a la vez utilizando las teclas [Ctrl] y/o [Shift]. La lista desplegable Aprobación permite ver las actualizaciones que ya han sido aprobadas o no (en el ejemplo, lo están para un grupo de equipos: Instalar (1/25). La lista desplegable Estado permite ver las actualizaciones que no han podido instalarse en todas las máquinas o que presentan algún problema en su instalación
También es posible obtener informes detallados acerca de las actualizaciones. Para ello basta con ir a la pestaña asociada y seleccionar el informe a visualizar.
Es preciso haber instalado Microsoft Report Viewer 2008 para poder consultarlos. Está disponible en la siguiente dirección: http://www.microsoft.com/eses/download/details.aspx?id=577. Aparecerá un mensaje, de todas maneras, indicándole que necesita esta herramienta si quiere visualizar un informe desde la consola de administración WSUS.
Existen informes preconfigurados a su disposición. No tiene la posibilidad de crear nuevos. Los modelos preexistentes se generan bajo demanda, de modo que se pueda disponer de la información más actualizada posible. La pestaña Opciones le permite configurar las opciones específicas a la instalación (idiomas, clasificaciones, productos, etc.) así como otros parámetros: • • • • • •
Aprobaciones automáticas: permite definir la forma en que se aplican los tipos de actualización (seguridad, críticas) para los equipos definidos. Notificaciones electrónicas: permite enviar notificaciones de informes acerca de las actualizaciones por correo electrónico. Asistente de limpieza del servidor: permite limpiar los equipos antiguos, las actualizaciones antiguas y los archivos antiguos de actualización. Equipos: permite especificar si los grupos de equipos para la actualización se administran desde WSUS o desde una directiva de grupo. Personalización: permite, en el caso de que se utilice servidores WSUS "hijos", conocer el estado de los equipos que le están asociados. Paquete acumulativo de informes: permite en el caso de una arquitectura con un WSUS frontal tener una centralización de todos los WSUS "hijos".
Conclusión En este capítulo ha visto los elementos esenciales para dotar de seguridad a su parque informático. En los aspectos relativos a la seguridad informática es mejor adoptar una actitud proactiva y anticipar los problemas e incidentes a los que deberá hacer frente. Ganará en rapidez para devolver su infraestructura a un estado productivo en caso de que ocurra algún problema importante. Piense bien su esquema de copia de seguridad en función de sus necesidades (volumen, franja horaria, etc.). Las instantáneas son un complemento muy bueno a la copia de seguridad Windows Server Backup. Tampoco dude en bascular a productos específicos como el de Microsoft (System Center Data Protection Manager). Le ofrecerán una granularidad suplementaria así como posibilidades extendidas de copia de seguridad de sus aplicaciones (Exchange, SQL, SharePoint, etc.). Prevenirse frente a amenazas como los virus, la explotación de fallos del sistema y demás contrariedades resulta también imprescindible. Conservar sus aplicaciones siempre actualizadas permite corregir los defectos de las mismas. WSUS es gratuito, aprovéchelo, le facilitará en gran medida la difícil tarea de la gestión de parches de seguridad de Microsoft. Ya no necesita acceder individualmente a cada PC para controlar el estado de las actualizaciones, ni tampoco para forzarlas. Todo ello se puede administrar en lo sucesivo de forma remota, centralizada y simplificada.
Más allá de Windows Server 2012 R2 y Windows 8.1 En el momento de escribir estas líneas, existe poca información disponible sobre las próximas versiones de Windows 8.1 y Windows Server 2012 R2. No nos arriesgaremos a especular acerca del nombre de la futura versión de Windows Server aunque, probablemente, Microsoft busque un cambio en la forma en que ponen a disposición de los usuarios las nuevas versiones y sus funcionalidades claves, con el objetivo de ofrecer actualizaciones de roles como Hyper-V y otros fuera de los ciclos clásicos de publicación de software. Este enfoque, mucho más modular, tiene la ventaja de que desvincula al sistema operativo de las funcionalidades propuestas. Esto aportará una mejor reactividad y adaptación a los cambios para las empresas que ya no estarán obligadas a estudiar el impacto ligado a una migración de todo el OS sino, únicamente, del módulo que se desea actualizar. Por supuesto, esta información se ofrece con todas las reservas y es posible cualquier enfoque cuando se trata de nuevos desarrollos y una adaptación al mercado.
El calendario esperado Microsoft pretende acortar el tiempo necesario entre la aparición de una versión mayor o menor de Windows: 2 años entre una versión mayor (2003) y una versión menor (2003 R2, parecida en 2005) y, a continuación, otros 3 años antes de la siguiente versión mayor (2008), y así con periodos de 2 años. Si se mantiene esta cadencia, permitirá evitar versiones intermedias, y evitar a los usuarios que se habitúen a una versión específica como ocurrió con Windows XP, pero también responder a sistemas competidores como Apple donde aparecen nuevas versiones de forma regular.
