Automate direct domain enrollment across Windows versions

docs/unified-bootstrap-validation.md

@@ -16,7 +16,7 @@ Fecha: 2026-09-10. Paquete: 0.5.1.
 - El empaquetador genera un solo ZIP Windows con los lanzadores habitual y Azure,
   el instalador VPN, el runtime offline y el manifiesto SHA-256.
 
-## Prueba real en Hyper-V
+## Prueba real en Hyper-V: Windows 11
 
 Servidor: VM `Windows Server`, dominio `lci.lasalle.mx`, DC `192.168.50.10`.
 Cliente: VM `Windows11-002`, Windows 11 Enterprise LTSC, build 26100,
@@ -46,12 +46,126 @@ Resultados comprobados:
   DHCP y su servidor DNS originales. Resolución pública y HTTPS comprobados
   contra `www.microsoft.com` (HTTP 200).
 
+## Prueba real en Hyper-V: Windows 10
+
+Fecha: 2026-09-10. Cliente: VM `Windows10-001`, Windows 10 Enterprise LTSC
+x64, build 19044, nombre de equipo `DESKTOP-HDKRD5V`, inicialmente en WORKGROUP.
+Se usó el mismo ZIP 0.5.1 publicado en Gitea, sin modificar sus scripts ni
+binarios. SHA-256 del ZIP:
+
+```text
+4DBE45697D74110F65C6D7825A593121B19C53B5F286F0DBC00068F3AFE45FB0
+```
+
+Se guardó el checkpoint `Before SGU Windows10 validation 2026-09-10`.
+La VM ya tenía dos tarjetas: `Ethernet` en `Default Switch`, con DHCP y DNS
+`172.18.176.1`, y `Ethernet 2` en `Laboratorio AD`, con dirección APIPA.
+
+Primero se ejecutó el bootstrap sin preparar la IP privada. Reintentó la
+conexión, diagnosticó que `Ethernet 2` no tenía una IPv4 utilizable y que la ruta
+de Internet no alcanzaba WinRM del servidor. No solicitó una IP del cliente,
+no modificó sus direcciones y mantuvo el equipo en WORKGROUP.
+
+Para la prueba positiva se configuró administrativamente
+`192.168.50.203/24` en `Ethernet 2`, sin puerta de enlace, y se esperó a que
+Windows confirmara la dirección como `Preferred`. Esta preparación corresponde
+a la red de laboratorio sin DHCP; no la realizó el bootstrap. Se ejecutó de
+nuevo el ZIP con sólo la IP del DC, una credencial en memoria y `-SkipRestart`,
+sin parámetros de interfaz, IP del cliente, dominio, NetBIOS ni OU.
+
+Resultados:
+
+- Selección automática de `Ethernet 2`, descubrimiento de `lci.lasalle.mx`,
+  `LCI` y `OU=Laboratorio`, y unión al dominio completada.
+- Proveedor y certificados instalados; proveedor validado antes de la unión.
+- Tras reiniciar, `Test-ComputerSecureChannel=True` y tarea
+  `SGU-CredentialProvider-EnrollmentGuard` finalizada con `LastTaskResult=0`.
+- Validación con dominio, salud del broker, acceso remoto y RustDesk exigidos:
+  `IsValid=True`, `Issues={}`, `BrokerHealth=ok`, `RemoteAccessReady=True` y
+  `RustDeskReady=True`.
+- Runtime .NET y binarios presentes; proveedor de contraseña de Windows
+  conservado. Cuenta `alumno` presente, sin permisos de administrador y con
+  expiración de contraseña deshabilitada.
+- `Ethernet 2` quedó como `DomainAuthenticated`; `Ethernet` permaneció como
+  `Public`, conservando su DHCP y DNS original. HTTPS hacia
+  `https://www.microsoft.com` respondió HTTP 200.
+
+No fue necesario corregir el bootstrap para esta prueba. La VM quedó encendida
+y enrolada, con el ZIP extraído en sus Descargas y el checkpoint previo disponible.
+
+### Comprobación posterior del escritorio
+
+La validación anterior comprobaba el enrolamiento, pero no el fondo visible
+en una sesión de usuario. Al revisar la sesión de `Windows10-001`, el fondo
+seguía siendo el predeterminado de Windows. El registro del generador mostró
+un fallo de validación al asignar el género vacío devuelto por AD al parámetro
+`Gender`, cuyo `ValidateSet` sólo permite `Male` o `Female`.
+
+Se corrigió `Set-SguWelcomeWallpaper.ps1` para mantener el saludo neutral cuando
+el dato no está disponible. Se actualizaron el generador instalado y su copia
+en el paquete de autorreparación, y se ejecutó en el contexto de la sesión
+interactiva existente, sin cerrar sesión ni solicitar otra contraseña.
+El registro terminó con `OK`, la configuración del usuario apuntó al JPEG
+generado y se verificó visualmente el fondo institucional con nombre y saludo.
+La tarea temporal utilizada para actualizar la sesión se retiró al finalizar;
+la ejecución habitual al iniciar sesión sigue a cargo de la GPO.
+
+Se agregaron cuatro pruebas de renderizado JPEG: género ausente, vacío o
+desconocido, valores reconocidos y prioridad de un valor explícito. Todas
+pasaron en Windows PowerShell 5.1. Esta corrección posterior está en el código
+y en la VM; el ZIP publicado como 0.5.1 no se modificó.
+
+## Prueba real de enrolamiento público directo: Windows 10
+
+Fecha: 2026-09-11. Se repitió el enrolamiento de `Windows10-001` contra el DC
+Azure `20.9.81.130`, sin perfil ni interfaz VPN. El cliente conservó sus dos NIC
+y seleccionó por sí solo `Ethernet` con DHCP (`172.18.183.201`), porque era la
+ruta que alcanzaba WinRM. El segmento público de salida autorizado fue
+`200.13.89.0/24`.
+
+La VM aún nombraba `lci.lasalle.mx`, pero su canal seguro pertenecía al bosque
+anterior y estaba roto. El flujo creó o reutilizó la cuenta de equipo en la OU
+descubierta, restableció la contraseña de máquina contra
+`SGU-DC01.lci.lasalle.mx`, reinició Netlogon y conservó el equipo unido. También
+toleró SID huérfanos del bosque anterior al comprobar los grupos locales.
+
+Windows 10 Enterprise LTSC build 19044 no expone los cmdlets DoH. El bootstrap
+lo detectó y usó DNS tradicional hacia la misma IP pública, limitado por NSG y
+Windows Firewall al CIDR permitido. Después de un reinicio real se comprobó:
+
+- `Test-ComputerSecureChannel=True` y resolución SRV del DC;
+- `IsValid=True`, sin incidencias;
+- `BrokerHealth=ok`, `RemoteAccessReady=True` y `RustDeskReady=True`;
+- ningún perfil VPN instalado;
+- paquete final `0.5.9`, SHA-256 del ZIP de Windows:
+  `E7AF77252E444FB7EBACF3C90005D322EE19F76DD9387AC5782C57EA9EE617B7`.
+
+## Prueba real con Azure VPN
+
+El 2026-09-10 se desplegó `sgu-lab-dc` en Azure Central US, se creó el bosque
+`lci.lasalle.mx` y se enroló `Windows11-002` mediante un gateway real
+`VpnGw1AZ`. El controlador tiene IP `10.77.0.4` y el cliente obtuvo
+`172.30.0.2` por IKEv2 con certificado de máquina. El bootstrap descubrió
+automáticamente la interfaz VPN, el dominio y la OU a partir de la IP del DC
+y la credencial administrativa.
+
+Se comprobaron el objeto de equipo en `OU=Laboratorio`, el canal seguro y la
+validación SGU completa, incluyendo salud mTLS, acceso remoto y RustDesk.
+Para Enterprise se configuró un device tunnel y una recuperación de Netlogon
+para la conectividad tardía al arrancar. El bosque Azure es independiente del
+bosque local con el mismo nombre.
+
+La infraestructura, versiones de paquetes, ajustes adicionales y evidencias
+están en [el informe de Azure](azure-deployment-validation-2026-09-10.md).
+Se usaron paquetes locales de validación `0.5.2-azure.*`; el release publicado
+0.5.1 no se reemplazó durante este despliegue.
+
 ## Alcance pendiente
 
-Windows 10 se cubrió mediante pruebas de compatibilidad y código compartido,
-pero no se ejecutó una instalación real en Windows 10 en esta sesión. La VPN
-Azure y otras VPN requieren validación en sus redes reales; las pruebas locales
-cubren rutas en otra subred, pero no un gateway Azure activo.
+OpenVPN y otras VPN requieren validación en sus redes reales. Las pruebas
+Windows realizadas cubren Enterprise LTSC x64, builds 19044 y 26100; no todas
+las ediciones ni builds. Azure se probó con Windows 11; la prueba de Windows 10
+descrita arriba corresponde a la LAN.
 
 El servidor debe tener SGU preparado. La IP de un DC no permite crear una VPN,
 adivinar una IP libre ni sustituir permisos, DHCP o políticas de firewall.