Estrategia de identidad (I) en Windows Virtual Desktop – Active Directory Domain Services (AD DS)

Publicado por

La gestión de identidades en Windows Virtual Desktop juega un papel muy importante debido a las configuraciones complejas que trae consigo. Hoy veremos la primera de esas estrategias de identidad: aprenderemos los pasos para conectar el servicio Windows Virtual Desktop a un entorno de Active Directory implementado en máquinas virtuales de Azure y permitir la autenticación de usuarios de dominio en nuestros escritorios y aplicaciones remotas.

Si nos hemos decantado por la estrategia de identidad de Active Directory Domain Services (en adelante, AD DS) en Azure VMs, lo primero que debemos hacer es, precisamente, crear esas VMs que harán la labor de Domain Controller.

  • Si estamos ante un escenario de demo, bastará con implementar una única VM y, tras su despliegue, proceder a la configuración de AD DS.
  • Si estamos ante un escenario en producción, deberemos implementar otras alternativas, como por ejemplo, la creación de 2 VMs para Domain Controllers y que éstas se encuentren contenidas en un Availability Set.

Una vez tengamos generado nuestro entorno de Active Directory, podemos definir una pequeña y sencilla estructura de usuarios, grupos y OUs que nos permitirán la gestión de todo lo referente a WVD. En nuestro caso, lo hemos definido de la siguiente forma:

La imagen tiene un atributo ALT vacío

El siguiente paso será incluir contenido en cuanto a identidades. Para esta infraestructura hemos generado una serie de usuarios para que sean sincronizados y poder hacer uso de ellos en Azure AD:

La imagen tiene un atributo ALT vacío

Adicionalmente, hemos generado un usuario que va a ser el encargado de realizar la función de unir los SessionHost al dominio automáticamente en el momento en el que vayamos a desplegar nuestros HostPools más adelante:

La imagen tiene un atributo ALT vacío

La contraseña de la cuenta debe cumplir con los requisitos de complejidad de la contraseña de Azure, así como con los requisitos locales de AD. Los requisitos de Azure significan que la contraseña debe tener un mínimo de 12 y un máximo de 128 caracteres. Por lo tanto, nos tenemos que asegurar de establecer la contraseña para que tenga un mínimo de 12 caracteres además de sus requisitos locales de AD. Sin esto, la implementación fallará.

A continuación, debemos generar una nueva VM (o podemos utilizar la misma en caso de encontrarnos en un entorno de pruebas) para la instalación y configuración de Active Directory Connect, la herramienta de sincronización que nos permitirá vincular nuestras identidades en Active Directory contra Azure Active Directory.

(En este post hemos obviado el proceso de instalación y configuración de AD DS, DCs y AD Connect, networking…)

El resultado de la infraestructura implementada en este artículo es el siguiente:

La imagen tiene un atributo ALT vacío

En el siguiente artículo analizaremos otra posibilidad de autenticación y estrategia de identidad a la hora de implementar WVD: Azure Active Directory Domain Services (AD DS modalidad PaaS en Azure).

Hasta el siguiente post !!

<< La nube puede ser maravillosa >>

Darío Romero

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *