# Despliegue SGU en Azure y enrolamiento de Windows11-002 Fecha: 2026-09-10. Suscripción `1254ca0e-3950-4711-8b4b-e33b4677d950`. ## Infraestructura y bosque | Componente | Configuración comprobada | | --- | --- | | Grupo de recursos / región | `rg-sgu-lab` / `centralus` | | VM Azure / nombre Windows | `sgu-lab-dc` / `SGU-DC01` | | Sistema y tamaño | Windows Server 2025 Azure Edition / `Standard_D2s_v5` | | Dirección del controlador de dominio | `10.77.0.4` | | Bosque / dominio / NetBIOS | `lci.lasalle.mx` / `lci.lasalle.mx` / `LCI` | | SID del dominio Azure | `S-1-5-21-2324484875-464590158-1758545597` | | VNet / pool P2S | `10.77.0.0/16` / `172.30.0.0/24` | | Gateway | `sgu-lab-vpngw`, `VpnGw1AZ`, estado `Succeeded` | | Protocolos configurados | IKEv2 y OpenVPN; prueba real con IKEv2 | | Cliente Hyper-V / nombre Windows | `Windows11-002` / `DESKTOP-LM7D7OM` | Se creó un bosque nuevo en Azure. Tiene el mismo nombre DNS que el bosque del laboratorio local, pero una identidad distinta; no es una réplica ni una migración de sus usuarios. El cliente de esta prueba consulta el bosque Azure mediante una regla NRPT para `.lci.lasalle.mx`. La promoción y la configuración SGU terminaron a las `22:10:36Z`. Se comprobó `bootstrap-complete.json`, los servicios AD DS, DNS, ADWS, Netlogon y SGUAuthBroker, los registros SRV y las pruebas dcdiag Connectivity, Advertising, SysVolCheck, NetLogons y Services, todas con resultado satisfactorio. RustDesk, WinRM, escritorio remoto y el colector de eventos quedaron configurados. Los puertos administrativos y de AD no están abiertos a Internet. ## Enrolamiento y VPN El cliente usa Windows 11 Enterprise LTSC x64, build 26100. Se creó el checkpoint `Before-SGU-Azure-Enrollment-20260910` antes de modificarlo. Se instaló un certificado de máquina y el perfil nativo `SGU Azure P2S`. Con el túnel conectado, el bootstrap recibió la IP `10.77.0.4` y una credencial de dominio; descubrió automáticamente dominio, NetBIOS, OU y la interfaz VPN `172.30.0.2`. No recibió una IP del cliente ni una interfaz elegida manualmente. El objeto `DESKTOP-LM7D7OM` quedó habilitado en `OU=Laboratorio,DC=lci,DC=lasalle,DC=mx`. El proveedor SGU y sus certificados mTLS quedaron instalados. La validación con dominio, broker, acceso remoto y RustDesk exigidos devolvió `IsValid=True`, `Issues=[]`, `BrokerHealth=ok`, `RemoteAccessReady=True` y `RustDeskReady=True`. El guard de enrolamiento terminó con código 0. Para este cliente Enterprise se instaló también `SGU Azure Device`, un perfil VPNv2 de dispositivo bajo SYSTEM, con IKEv2, certificado de máquina, Always On y ruta dividida `10.77.0.0/16`. El perfil manual permanece disponible. La NIC de Internet conserva DHCP y DNS `172.18.176.1`; el túnel utiliza la dirección `172.30.0.2` y la red del dominio. La primera prueba de arranque del túnel detectó Netlogon 5719 y `ERROR_NO_LOGON_SERVERS`: la red VPN estaba disponible después de que Netlogon intentara localizar el dominio. Reiniciar únicamente Netlogon recuperó el canal seguro sin restablecer la contraseña de máquina. Se probaron `ExpectedDialupDelay=60` y `NegativeCachePeriod=3`, siguiendo la guía de Microsoft para [conectividad de dominio tardía al arrancar](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/netlogon-event-id-5719-or-group-policy-event-1129). No resolvieron por sí solos esta VM; se devolvieron a sus valores predeterminados 0 y 45, respectivamente. Se instaló `SGU-Azure-DomainConnectivity`, una tarea SYSTEM de arranque con demora de 30 segundos y reintentos. Ejecuta `scripts/Repair-SguAzureDomainConnectivity.ps1`: espera al perfil VPN y a LDAP del controlador, comprueba el canal seguro y reinicia Netlogon únicamente si es necesario. Después vuelve a ejecutar el guard SGU, espera su resultado y reintenta fallos transitorios de resolución de grupos del dominio. No guarda credenciales ni restablece automáticamente la contraseña de la cuenta de equipo. El resultado se registra en `C:\ProgramData\SGU\Enrollment\azure-domain-connectivity.json`. La verificación final se realizó a las **17:00:55 UTC-6**, después del arranque de las **16:57:35 UTC-6**, sin sesión interactiva (`UserName=null`): - `SGU Azure Device=Connected`, `172.30.0.2`, red `DomainAuthenticated`. - `Test-ComputerSecureChannel=True`; DC localizado en `10.77.0.4`. - `IsValid=True`, sin incidencias; broker, acceso remoto y RustDesk correctos. - `SGU-Azure-DomainConnectivity` terminó con código 0 y registró la recuperación de Netlogon y `EnrollmentGuardResult=0`. - `SGU-CredentialProvider-EnrollmentGuard` terminó con código 0. - La captura muestra el acceso institucional SGU en la pantalla de inicio de sesión. Se obtuvo directamente de Hyper-V, sin usar el escritorio del host. En este arranque, la recuperación completa de dominio y guard terminó unos dos minutos y medio después del inicio de Windows. No se comprobó un inicio de sesión interactivo con un usuario institucional del nuevo bosque; se validaron la unión, la confianza de máquina, los servicios y la salud mTLS. ## Correcciones y versiones usadas - La plantilla Azure usa `VpnGw1AZ`, IP de gateway con zonas 1/2/3 y OpenVPN como alternativa a IKEv2. Azure rechazó las opciones anteriores VpnGw1/SSTP. - El disco del controlador tiene caché `None` para las escrituras de AD DS. - El bootstrap del servidor omite la VF de Accelerated Networking que figura activa sin una interfaz IPv4; configura el adaptador que realmente tiene IP. La prueba de regresión cubre ese caso. - Servidor: paquete local `0.5.2-azure.2`, SHA-256 `BE29411A1A1C0FE0BB2BB7DB0418EF40881C98A721B42D1F52D54E22487077AC`. - Cliente: paquete local `0.5.2-azure.1`, con la corrección del saludo sin género. Las diferencias posteriores de `.2` corresponden al servidor. Estos paquetes de validación no reemplazan el release 0.5.1 publicado en Gitea. La configuración del device tunnel y de su tarea de recuperación se aplicó a esta VM; no está integrada como opción automática en el instalador publicado. ## Evidencias y acceso administrativo Las evidencias están en `artifacts/azure-deployment-20260910/`, excluido de Git: - `server-verification.json`: bootstrap del servidor y dcdiag. - `azure-computer-verification.json`: objeto de equipo en el bosque Azure. - `client-enrollment-result.json`: resultado original de unión. - `client-validation-before-final-reboot.json`: validación completa antes del reinicio. - `client-postboot-verification.json`: comprobación posterior del arranque, incluyendo canal seguro, VPN, usuario interactivo y resultados de las tareas. - `windows11-azure-login.jpg`: captura directa del framebuffer de Hyper-V. - `enable-device-tunnel.ps1`: XML y comandos usados para el túnel de esta VM. - `state.json`: inventario y estado de la operación. La cuenta administrativa del bosque es `LCI\azureadmin`. Su contraseña generada está protegida con DPAPI en `credentials.clixml`, dentro de ese directorio del host, para el usuario que ejecutó el despliegue. No se guardó en este documento. La contraseña DSRM se generó en la VM Azure y se conserva protegida para SYSTEM en `C:\ProgramData\SGU\Secrets\dsrm-password.clixml`. La revisión automática rechazó la limpieza de la cuenta de almacenamiento temporal `sgustagea8e952c02421` y su rol, y después la limpieza de archivos y de la tarea temporal del cliente, sin indicar un motivo específico. No se eliminaron. El PFX del cliente permanece cifrado y bajo una ACL restringida a Administradores/SYSTEM; la tarea instaladora del túnel no tiene disparador recurrente. Esta limpieza queda pendiente. OpenVPN y otras configuraciones de VPN no se probaron. Esta validación no extiende el soporte Always On device tunnel a ediciones Windows Pro.