Algunas consideraciones de diseño para Microsoft AD Certificate Services 2012

Recientemente he recopilado algo de experiencia en el despliegue del rol Active Directory Certificate Services sobre Windows Server 2012 y 2012 R2 y, sin ser para nada una guía exhaustiva ni ser escrita por un experto en infraestructura Windows Server; quisiera compartir algunas consideraciones a tener en cuenta, especialmente en un ambiente en el que los consumidores de los certificados serán servicios de VMware:

La arquitectura

Hay varias opciones para el despliegue para lo cual considero recomendable leer y revisar la documentación de Microsoft al respecto de éste tema. Sin embargo la versión corta e imprecisa es que hay que tomar varias decisiones:

¿Enterprise o Standalone CA?

Standalone CA quiere decir que no va a estar unida al dominio y, por lo tanto, va a carecer de funciones como autenticar solicitudes de certificados contra AD, entregar certificados automáticamente ó usar plantillas.

Las Enterprise CA de Microsoft están unidas al entorno de Active Directory y por lo tanto, complementan la autenticación de AD con la entrega automatizada de certificados a los miembros del dominio, el uso de plantillas y la autenticación de solicitudes de certificado. Para el uso de Microsoft CA en un entorno con VMware vSphere, es necesario hacer configurar Enterprise CAs pues, como tocaré más adelante, se requiere plantilla de certificado con algunas variables adicionales a partir de vSphere 5.1

Root y Subordinates

Microsoft AD Certificate Services contempla una jerarquía de niveles de confianza y de autoridad en la que el mayor nivel es la Root Certificate Authority (Root CA) que debe ser confiada por todos los miembros del dominio y tiene permisos para emitir así como para revocar certificados, y también tiene el rol de distribuir los Listados de Revocación (CRLs) actualizados a todos los miembros de la jerarquía.

Las entidades subordinadas son todas aquellas que están bajo la entidad Root, siendo la subordinada inmediatamente abajo la que se conoce como entidad “Intermedia” que obtiene los certificados de la Root CA y los puede usar para emitir a entidades más “abajo” en la jerarquía.

En resumen, la decisión de diseño aquí corresponde a si el entorno de despliegue requiere solamente una Root CA que es autosuficiente para emitir certificados o se requieren también subordinadas.  La mejor práctica de Microsoft se refiere a desplegar una Root CA que permanezca aislada (de hecho, apagada después de implementada) y que sea una o más entidades subordinadas las que sean visibles para los dispositivos finales y controlen la emisión y revocación de certificados digitales; con la firma original de la Root CA.

Algoritmo de hash

Al configurar el rol de AD Certificate Services (para ello se puede seguir la guía de Technet)  la opción de algoritmo de hashing predeterminado es SHA-2 cuyo equivalente más seguro y completamente soportado por las versiones recientes de vSphere (ver KB) es SHA-256 que es mucho más resistente a ataques de colisión y tiene el potencial de ser el estándar de uso en la implementación de Public Key Infrastructure (PKI) en un entorno VMware.

Conclusión

Espero hayan sido de utilidad algunos de éstos datos, en el futuro si el todopoderoso tiempo lo permite, estaré agregando diagramas para clarificar mejor los asuntos.

 

Saludos!

Advertisements

¿Cómo configurar widgets en vCenter Operations Manager?

No se puede corregir aquello que no puedes medir. Es ésta una de las premisas que en mi opinión guía la planeación de TI en sus diferentes capas.

VMware vCenter Operations Manager ofrece una cantidad casi abrumadora de métricas para el Software-Defined Data Center y poder asignarle un contexto y una metodología clara de presentación y análisis es clave en el éxito de la introducción de vCOPS en la organización.

Para lograr ésta meta, la creación de dashboards personalizados para vCOPS Custom ha probado ser una estrategia eficaz,  incluyendo en ésos espacios los widgets apropiados.

En éste artículo se cubrirá la configuración del widget “Top-N Analysis” en el contexto de la creación de un nuevo dashboard. Para conocer los diferentes tipos de widget así como mayores generalidades sobre dashboards de vCOPS, recomiendo la lectura del manual de usuario.

Procedimiento

1. Inicie sesión en vCOPS custom (https://URL_vCOPS_UI/vcops-custom)

2.  Dirigirse a la parte superior y dar click en Dasboards > Add:

23. En la sección de la izquierda, seleccionar el widget que se va a agregar y arrastrarlo a la sección derecha:

54. Una vez haya terminado de editar las propiedades del dashboard, proceda a dar click en OK

5. Dirigirse al nuevo dashboard y editar el widget haciendo click en el ícono de engrane de la parte superior:

46.  Allí verá múltiples opciones. Mencionaremos algunas puntuales:

Self provider: se deshabilita ésta opción en caso que se desee colectar métricas desde otro widget para mostrarlas en el widget actual. En caso de habilitarlo, el widget actual será quien colecte y despliegue las métricas, siendo éste el caso más común.

Bars count: define el tipo de Top que se va a desplegar, por ejemplo un valor de 5 en éste campo, significa que se mostrará un Top 5 de la métrica que elija.

Widget mode: puede trabajar con etiquetas o métricas. En éste caso se fija la opción en “Metric”.

7. En la parte inferior podrá seleccionar el tipo de métrica a desplegar. En el ejemplo se desplegará un Top 10 con las más altas latencias de lectura en los datastore de los múltiples vCenter conectados a ésta instancia de vCOPS:

6

Y éste es el resultado final (se omiten nombres para proteger la identidad de los implicados 😉 ):7Esta fue una muy breve introducción a la configuración del widget TOP-N Analysis.

Recursos adicionales

Curso: vCOPS Analyze and Predict

Libro: vCOPS Essentials de Lauren Malhoit

Saludos!

 

Configuración de un repositorio de disponibilidad continua para perfiles de usuario en pools RDS de VMware Horizon with View 6

Si, ya era hora de tener un título largo.

Como es sabido por casi todos, VMware Horizon 6 ahora soporta Microsoft RDS (yay!) y con ello se presenta una real alternativa para productos como Citrix XenDesktop al poder entregar pools de sesiones basadas en RDS.

En una implementación de éste tipo, no es soportado por ahora el uso de VMware Persona Management para la gestión de los perfiles de usuario por lo que se deben gestionar usando Group Policy en Active Directory.  Es común encontrar que un requerimiento funcional para un entorno de VDI es la redirección de los perfiles de usuario a un servidor de archivos centralizado, y aún mejor, establecer el mecanismo para proveer alta disponibilidad a ése repositorio.

Este post cubre las herramientas nativas de Microsoft Windows Server 2012 con las que se puede satisfacer éste requerimiento y la manera en que interopera con VMware Horizon 6.

Escenario de prueba

Windows Server 2012 R2 Standard Edition (x2)

Dos unidades compartidas:

1 para Quorum/witness disk

1 para almacenamiento de datos

Roles/features habilitados en los dos nodos:

Failover Cluster, File Server

Tres (3) tarjetas de red en cada servidor @1GBPs:

1 para almacenamiento iSCSI

1 para comunicación interna del clúster

1 para conexión de clientes al clúster

PROCEDIMIENTO

CREAR EL FAILOVER CLUSTER

  1. Instalar el rol de File Server con las herramientas de administración en cada nodo:

Install-WindowsFeature FS-FileServer –IncludeManagementTools

  1. Instalar el Feature de Failover Clustering en cada nodo:

Install-WindowsFeature Failover-Clustering –IncludeManagementTools

  1. En solo UNO de los dos nodos configurar el feature de Failover Cluster:

A. Iniciar Failover Cluster Manager

B. Crear un nuevo cluster:

cafs1C.    Agregar el FQDN del nodo donde se está llevando a cabo la configuración:

cafs2

D.    En la siguiente pantalla, seleccionar “Yes” para correr la validación
E.    Correr todas las pruebas de validación:

cafs3F.    Una vez concluyan las pruebas, se obtiene un reporte que puede arrojar error, warning o éxito. En caso que arroje Error, se deberán solucionar los inconvenientes reportados, en estado warning se puede crear el clúster pero se debe atender a las recomendaciones para tener un servicio completamente funcional:

cafs4G.    Seleccionar una dirección IP en la red de comunicación interna del cluster y asignar un nombre NETBIOS, éste nombre e IP deben corresponder a una entrada en el DNS:

cafs5

CONFIGURAR EL ROL

En el Failover Cluster Manager, dirigirse a la sección Roles > Configure Role… :

cafs6B. Seleccionar el rol de File Server y dar click a “Next”:

cafs7C. En el caso de almacenamiento de perfiles de usuario, es seguro seleccionar la opción de “File Server for general use”. Es importante señalar también que éste opción es la única que soporta replicación DFS, y ésta característica es esencial para mantener los folders de perfiles replicados entre nodos:

cafs8D. Seleccionar un nombre NETBIOS y una dirección IP que usarán los clientes para acceder a los folders. Este NETBIOS e IP deben corresponder a una entrada en el DNS y el usuario con que se ejecuta el wizard debe tener permisos de escritura en el Controlador de Dominio, pues se agregará el nombre NETBIOS como una computadora más del dominio:

cafs9E. A continuación seleccionar el almacenamiento que se requiere habilitar en modo de Disponibilidad Continua.

Una vez se concluyen estos pasos, se verá el File Server en la pestaña de Roles:

cafs10

AGREGAR EL FILE SHARE DE ALTA DISPONIBILIDAD

A. Seleccionar el File Server dentro de la sección “Roles” y en el menú de la parte derecha seleccionar “Add File Share”:cafs11B.    En el menú que se despliega, seleccionar “SMB Share – Quick” y dar click en “Next”:

cafs12

C.    Seleccionar el volumen y el path que apuntará a este share:

cafs13D.    Asignar un nombre al share:

cafs14E.    Configurar las opciones necesarias, en el caso de usar el share para perfiles de usuario, es recomendable habilitar Access-Based Enumeration como una manera de aislar la visibilidad de los perfiles solo para los usuarios propietarios del perfil:

cafs15F.    En las siguientes pantallas configurar los permisos del share (los usuarios del dominio que vayan a ingresar al pool RDS deben tener permisos de escritura en éste share), y luego proceder a confirmar
G.    Verificar que el share se ha creado seleccionando el File Server en la sección “Roles”:

cafs16En éste punto ya se puede probar el acceso al share desde el Explorer de cualquier equipo en el mismo bosque (forest) Active Directory que aquel en el que está registrado el File Server:

cafs17

A partir de éste punto, todas las operaciones de escritura/lectura sobre el SMB share quedaràn replicadas entre los File Server del clúster y los archivos permanecerán accesibles aún si hay miembros del clúster que no estén disponibles, siempre y cuando no se supere el número de fallas que el clúster tolera.

Redirección de los perfiles de usuario al CAFS

En éste punto se debe contar con acceso administrador al controlador de dominio Active Directory del entorno al que perteneces el pool RDS, lo anterior para poder editar la GPO y especificar la redirección de los folders de los perfiles de usuario al share previamente creado:

 

  1. Iniciar sesión como con rol de Domain Administrator en el controlador de dominio
  2. Ejecutar la herramienta Group Policy Management
  3. Seleccionar la OU donde están alojados Remote Desktop Session Host
  4. Editar la GPO asignada a esa OU:

cafs185.    Ir a User Configuration\Policies\Windows Settings\Folder Redirection

6.    Allí seleccionar los folders que se van a redigir y en cada uno:
a.    Dar clic derecho
b.    Properties…
c.    Seleccionar Setting: Basic – Redirect everyone’s folder to the same location
d.    Seleccionar Target folder location: Create a folder for each user under the root path
e.    En el campo de root path ingresar la ruta del share recientemente creado:

cafs20

CONCLUSION

Después de éste largo post y el procedimiento -que no es nada complicado aunque pareciera-, puede contar con un repositorio de disponibilidad continua al cual puede agregar servidores de archivos como miembros del clúster para elevar aún más la resiliencia de los perfiles de usuario.

Saludos!

Problema con script de instalación automatizada de componentes para vCAC IaaS : rápida solución

VMware vCloud Automation Center IaaS es el motor de automatización para el aprovisionamiento de Infraestructura como Servicio (por defecto para VMware vSphere);  extensible a otras plataformas de virtualización.

La instalación de éste módulo requiere una considerable cantidad de prerequisitos de software cuya habilitación manual no sólo es tediosa sino una práctica anacrónica en éstos tiempos.

El buen Brian Graff (@vTagion) ha escrito y publicado un script muy útil que automatiza la habilitación de features/roles/reglas/etc que requiere vCAC IaaS para una exitosa instalación.

Sin embargo,  en algunas ocasiones al tratar de instalar en Windows Server 2012, la ejecución del script puede fallar en completarse arrojando el siguiente mensaje de error:

Add-WindowsFeature :  The source files could not be downloaded

La solución consiste en editar el script (archivo .ps1) y buscar las líneas que contengan el texto:

“Add-WindowsFeature”

y agregar al final el parámetro:

-source:e:\sources\sxs

Donde E: corresponde a la unidad en que esté montado el medio de instalación de Windows Server 2012.

Luego de agregar ése parámetro en cada lugar del script donde se invoque Add-WindowsFeature y guardar los cambios, la ejecución del script se completa con éxito.

Antes de ejecutar el script:

blog3_1

Ejecución del script:

blog3_2Re verificación de prerequisitos desde el instalador:

blog3_3Saludos!

Clúster de ESXi 5.5 no publica Storage Policies a vCloud Director 5.5.1

Para habilitar un aprovisionamiento automatizado y que cumpla con los Acuerdos de Nivel de Servicio en términos de ubicación de máquinas virtuales para un entorno administrado por VMware vCloud Director, se deben cumplir los siguientes pre-requisitos:

1. Licenciamiento vSphere Enterprise Plus

2. Servicio VMware Profile Driven Storage ejecutándose en el vCenter Server

3. Clústers con Storage Policies habilitado y licenciados

4. Storage capabilities creados y asignados a datastores

5. Storage profiles creados y con storage capabilities asignadas

Sin embargo con todas éstas etapas completadas con éxito y en un entorno que ha sido migrado de vSphere+vCloud 5.1 a 5.5 los pasos anteriores pueden no ser suficientes desde el punto de vista de vCloud Director 5.5

En vSphere 5.5 los Storage capabilities definidos por usuario se consideran legacy para dar paso al auge definitivo de las Storage Policies definidas ya sea por Tags de vCenter o por capacidades de almacenamiento descubiertas a través de VAAI. Lo anterior por supuesto tiene mucho sentido toda vez que la capa de storage de vSphere se centra cada vez más en los metadatos para sentar las bases del almacenamiento de objetos que es VMware VSAN.

vCloud Director 5.5 tiene compatibilidad reversa con los perfiles de almacenamiento definidos por usuario que vienen de vSphere 5 o superiores. Sin embargo para nuevos clúster ESXi (o Provider Virtual Datacenters en la jerga de vCloud) los perfiles (o Directivas) deben crearse siguiendo ésta secuencia:

1. Crear una nueva categoría de Tags en vSphere Web Client, que sea sólo aplicable a Datastores o Datastore Clústers:

Creación de una nueva categoría en vSphere Web Client

Creación de una nueva categoría en vSphere Web Client

Debido a que un datastore (objeto) sólo opera con unas prestaciones determinadas a la vez,  se selecciona una cardinalidad de una sola etiqueta por objeto.

2. Crear una etiqueta por cada tipo de almacenamiento presente en un entorno sin acceso a descubrimiento de capacidades por VAAI. Asociar esas etiquetas a la categoría previamente creada:

Etiquetas

3. Asignar las etiquetas a cada datastore (ya sea manualmente o mejor aún: usando PowerCLI :

Asignar etiqueta a datastore

4. Crear una nueva Storage Policy (o editar un Storage Profile existente) para tomar como Rule Set el Tag recién creado:

Nueva Storage Policy

blog2_5blog2_6Al finalizar el asistente se listarán los datastores a los que se haya asignado la etiqueta:

blog2_7

5. Dirigirse a vCloud Director > Gestionar y Supervisar > vCenters. Dar clic derecho sobre el vCenter sobre el que se hayan asigando las nuevas Storage Policies y seleccionar “Actualizar directivas de almacenamiento”:

blog2_8

6. Dirigirse al Provider vDC que corresponde al clúster en que se configuraron las Storage Policies y seleccionar la pestaña “Directivas de Almacenamiento”, allí se agregarán las directivas recientemente creadas:

blog2_9

Windows Server con Desktop Experience no permite el uso de Temas Aero

Ya sea que use Citrix Xendesktop, Microsoft RDS, VMware Horizon View u otra suite para implementar VDI, siempre habrá una etapa en la que tendrá que habilitar Desktop Experience como Feature en Windows Server 2008/2012 para entregar Sesiones hosteadas y a la vez ofrecer una experiencia de usuario muy similar a la de un desktop Windows7/8.

Un artículo en Technet indica el sencillo procedimiento para habilitar Desktop Experience como característica del sistema operativo, pero aún después de ello (y del reinicio solicitado) puede ser que no se pueda habilitar ningun tema de escritorio Aero y pocas cosas hayan cambiado a simple vista.

Esta es una restricción pensada en optimizar el uso de memoria en las tareas para las que un server NO está pensado (como una rica experiencia gráfica).

**ATENCIÓN: Los siguientes pasos solo debe ejecutarlos si el caso de uso lo requiere y se ha contemplado en el diseño el consumo extra en CPU y RAM**

Aplican tanto para Windows Server 2008/2012:

1.  Dirigirse a Panel de Control

2.  System

3.  Advanced system settings

4.  Performance > Settings

5.  Seleccionar “Adjust for best appearance”Captura16. Luego de ello ya se puede personalizar el tema de Escritorio del servidor:

Captura2Lamento que el ejemplo parezca un poco de la vieja escuela (Windows 2008 – Windows 7), pero aún son muchas las organizaciones cuya implementación de VDI se basa por completo en éstas versiones.

Saludos!