Windows Virtual Desktop III – Estrategia de identidad I – Active Directory Domain Services (ADDS)
Hola a todos, amigos de Azurebrains !!
Hoy continuamos con la serie sobre Windows Virtual Desktop en la que nuestro querido amigo y compañero Roberto Tejero nos había adelantado los Prerrequisitos para el despliegue y la Preparación del entorno, creando el tenant de Windows Virtual Desktop (en adelante, WVD) y generando un Service Principal para la realización de ciertas tareas específicas, ya sea despliegue manual, o automatizado, sin la necesidad de utilizar nuestras propias identidades nominales.
En este artículo veremos una de las estrategias de identidad que podemos llevar a cabo a la hora de implantar el servicio de WVD. En este primer post sobre hablaremos sobre la autenticación contra Active Directory Domain Services. En este caso, lo llevaremos a cabo desde Azure VM.
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:
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:
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 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:
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
