Windows Virtual Desktop IV – Estrategia de identidad II – Azure Active Directory Domain Services
Hola a todos, amigos de Azurebrains !!
Hoy continuamos con la serie sobre Windows Virtual Desktop. En el post anterior vimos la primera de las estrategias de identidad que podemos llevar a cabo, Active Directory Domain Services sobre una VM.
Hoy tendremos la oportunidad de descubrir la otra estrategia de identidad que podemos implementar para poder gestionar los usuarios y grupos en Windows Virtual Desktop, la utilización de Azure Active Directory Domain Services como gestor de identidades en cloud.
En primer lugar, debemos destacar los posibles escenarios en los cuales podemos utilizar Azure ADDS como gestor de identidades:
- Azure AD DS para organizaciones híbridas.
- Azure AD DS para organizaciones solo en la nube.
En el caso de tener nuestro entorno on-premises con nuestro AD DS implementado y querer desplegar Windows Virtual Desktop mediante Azure AD DS (modelo PaaS), el escenario sería el siguiente:
Si, por el contrario, nuestra intención es implementar un escenario cloud-only en el que queremos implementar Azure AD DS como gestor de identidades, tendremos un escenario similar a éste:
Volviendo a la elección de la estrategia de identidad que estamos abordando tanto en este post como en el anterior, veamos cómo sería el proceso de implementar Azure AD DS en nuestro entorno, para poder conectar nuestro Active Directory al servicio de Windows Virtual Desktop.
Partimos del siguiente escenario implementado en el post anterior. Simulemos que este escenario IaaS es el entorno on-premises:
En primer lugar, debemos comenzar el proceso de despliegue del servicio Azure AD Domain Services:
A continuación, definiremos el apartado de networking. En nuestro caso, hemos creado una nueva vNet llamada wvd-aadds-vnet:
Vamos ahora a encargarnos de la parte de administración. Para ello, vamos a definir a los administradores del grupo AAD DC Administrators, cuyos permisos, entre otros, son:
- Utilizar Remote Desktop para conectarse remotamente a máquinas del dominio.
- Unir máquinas al dominio.
- Estar en el grupo de administradores de cada máquina unida al dominio.
Nuestro laboratorio está implementado con la estrategia de identidad basada en AD DS sobre Azure VM. En nuestro DC dimos de alta un usuario llamado wvd.joindomain, el cual tiene permisos de Domain Admin y que fue sincronizado en Azure AD mediante AD Connect. Con lo cual, vamos a escoger ese usuario para asignarlo al grupo AAD DC Administrators (este usuario sería sincronizado desde el entorno on-premises si este fuera nuestro escenario):
El hecho de tener creado un usuario con permisos de Domain Admin y sincronizado con Azure AD es un requisito imprescindible para que la adición de SessionHosts al dominio sea exitosa.
Si se tiene pensado implementar Azure AD Domain Services con el modo cloud-only, bastará con escoger un usuario que hayamos creado previamente en nuestro Azure AD (puede ser, mismamente, wvd.joindomain o el usuario que se considere que deba tener permiso de administración y de unir máquinas a dominio) e incluirlo en el grupo en AAD DC Administrators.
Veamos ahora los pasos que se producen en la sincronización y gestión de identidades:
- Esta gestión de identidades se realiza desde el Active Directory basado en Azure VM (mismo escenario que si estuviese alojado on-premises).
- Estas identidades son sincronizadas mediante Azure AD Connect hacia Azure AD
- Por último, es Azure AD quien se encarga del one-way synchronization desde Azure AD hacia el dominio gestionado en Azure AD Domain Services.
Finalmente, rellenamos los campos necesarios y creamos el servicio Azure AD Domain Services:
Tras este deployment, podremos configurar los servidores DNS para nuestra vnet. El diagrama final de lo implementado sería así:
De esta forma, tendremos nuestro Active Directory on-premises (o en Azure VM) y, en caso de perder conectividad con estas VMs o haber sufrido un ataque, podremos continuar haciendo uso de nuestro dominio.
Las aplicaciones y VMs podrán usar características de Azure AD DS como domain-join, LDAP read, LDAP bind, autenticación NTLM y Kerberos y políticas de grupo.
Se ha habilitado vNet Peering entre la vnet principal para aumentar la visibilidad entre entornos pero, como ya dije, esto es una circunstancia especial debido a nuestro tipo de escenario.
Una vez explicados 2 de las posibles estrategias de identidad (DC on Azure VM o Azure AD DS), escogeremos la que mejor nos convenga para nuestro entorno y la desplegaremos.
En los siguientes posts dejaremos a un lado la parte de estrategia de identidad y nos centraremos en la configuración de Windows Virtual Desktop (desktops y remote apps).
Hasta el siguiente post !!
<< La nube puede ser maravillosa >>
Darío Romero
