Vamos a por el cuarto articulo sobre Windows 365, una vez hemos visto Windows 365 (III) – La arquitectura, hoy vamos a ver los requisitos para poder disfrutar de este servicio.
Windows 365 tiene una serie de dependencias que deben de configurarse correctamente:
Windows AD & Azure AD
Windows 365 hace uso de Azure Active Directory (Azure AD) y Active Directory Domain Services (AD DS) on-prem.
Las cuentas de usuario deben crearse en AD y sincronizarse con AAD para iniciar sesión en su PC en la nube junto con autenticación de usuario para la conexión de Protocolo de escritorio remoto (RDP).
Se recomienda que se cree una OU en AD para los objetos de equipo de PC en la nube.
Requiere una cuenta que pueda unirse al dominio los PC en la nube en AD, debiéndose delegar el acceso para crear objetos de computadora en la OU, así como también grupos para la asignación de licencias, políticas y la gestión de dispositivos, que se pueden crear en AD o AAD.
Actualmente la autenticación AAD es compatible, lo que reduce la dependencia de AD DS.
Azure AD Connect
La mayoría de vosotr@s ya tendréis Azure AD Connect configurado en vuestro entorno; solo debemos recordar el incluir la OU si el filtrado está habilitado, ya que necesitamos sincronizar tanto a los usuarios como a los dispositivos en Azure AD.
También puede usar el comando (cmdlet) para iniciar una sincronización en cualquier momento:
ADStart-ADSyncSyncCycle -PolicyType Delta
PD: Si el tiempo de sincronización es superior a 90 minutos provocará un error de aprovisionamiento.
Dispositivo Hybrid AAD Join
Es requerido para la inscripción en el MDM del PC en la nube, pero también habilita SSO y acceso condicional para el PC en la nube y aunque es probable ya tengáis esto configurado, para aquellos que no, se recomienda usar AD connect para configurar HAADJ.
Si no se quiere HAADJ en todos los dispositivos con Windows 10, siga los pasos de validación controlada, para unir solo los PC en la nube con Windows 365, habilitado a través de clave de registro mediante de GPO.
Suscripción Azure
Se requiere una suscripción de Azure para implementar una VNet, para los PC en la nube, pudiéndose ser una suscripción existente o nueva. La recomendación es crear un nuevo grupo de recursos en lugar de utilizar uno existente.
El servicio de Windows 365 configurará RBAC en la suscripción; grupo de recursos y VNet por lo que hay que ser cautos, busque herramientas de terceros como Terraform que podrían revertir cualquier cambio en RBAC.
Azure Virtual Network
Este paso es un requisito previo para que los PC en la nube contacten con los DCs.
Windows 365 requiere una VNet en una región admitida y que la VNet y Windows365 estén en la misma región.
Es una práctica recomendada implementar VNets cerca de la ubicación de los usuarios para que pueda reducir la latencia.
La VNet se puede emparejar con una VNet que tenga conectividad a un DC local o puede vincularla a un ExpressRoute si se tiene pero, por supuesto, la conectividad local puede ser VPN de Site-to-Site o ExpressRoute:
- Express Route es una conexión privada dedicada a Azure a través de un proveedor de servicios
- Site-to-Site VPN es una conexión privada a Azure a través de Internet con ancho de banda limitado
Por último, pero no menos importante, hay que tener cuidado con el direccionamiento IP porque una sola subred debe tener suficientes direcciones IP para todas los PC en la nube necesarias.
También se necesita que los PC en la nube lleguen al DC local, lo que significa que deben resolverlo y es por eso que:
- Azure Virtual Network debe usar un servidor DNS que pueda resolver registros de Active Directory locales.
- Puede usar un dispositivo DNS de terceros siempre que pueda resolver los registros de dominio de AD
URLs del servicio
Requeridas para la comunicación con Windows 365, AVD, AAD, Intune y, opcionalmente, Endpoint Analytics y Defender desde PC en la nube.
Las URL deben omitirse de los servidores proxy y permitirse en los firewalls.
No se recomienda la inspección de paquetes SSL y es probable que interrumpa el aprovisionamiento o el funcionamiento de un PC en la nube.
Los dispositivos físicos del usuario necesitarán acceso a los recursos de AVD.
Configuración de Intune
Los PCs en la nube con la versión Enterprise se inscribirán en Intune por lo que hay que revisar que no hay políticas de restricción de inscripción que bloqueen los dispositivos Windows, revisando también que las URL de inscripción son correctas y coinciden con los valores predeterminados.
El usuario no necesita una licencia de Intune para la inscripción; sin embargo, no obtendrán la política de usuario hasta que se les asigne una licencia.
Los CPC se inscriben en Intune usando el mismo método que utiliza Co-Management para inscribir dispositivos: a través de una API.
Enjoy!
Referencias: