Automate direct domain enrollment across Windows versions

docs/azure-deployment-validation-2026-09-10.md

@@ -0,0 +1,136 @@
+# 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.