SGU-CredentialProvider/docs/unified-bootstrap-validation.md

# Validación del bootstrap Windows unificado

Fecha: 2026-09-10. Paquete: 0.5.1.

## Comprobaciones locales

- Publicación Release del Auth Broker y del Credential Provider completada.
- Pruebas Pester ejecutadas en Windows PowerShell 5.1: selección de rutas,
  dos interfaces, VPN en otra subred, preferencia por la ruta de Windows,
  restricción explícita de interfaz, APIPA, falta de ruta, prefijo más específico,
  ruta de host y conflictos, DNS limitado al dominio, reintentos y compatibilidad.
- Prueba TCP real con socket ligado a una IP e interfaz y servicio cerrado.
- Reenrolamiento: se conserva la contraseña de `alumno` si la cuenta ya existe,
  para no provocar rechazos de historial/complejidad tras aplicar las políticas
  del dominio; se mantienen las verificaciones de permisos de usuario estándar.
- 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: 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,
nombre de equipo `DESKTOP-LM7D7OM`, inicialmente en WORKGROUP.

Antes de la prueba se creó el checkpoint
`Before SGU unified enrollment 2026-09-10`. El cliente sólo tenía conexión al
`Default Switch`; se añadió la tarjeta `SGU AD Test` al switch `Laboratorio AD`
y se configuró administrativamente `192.168.50.202/24` sin puerta de enlace.
Esta preparación de la red del laboratorio es independiente del bootstrap:
el enrolador no asignó esa dirección y no recibió parámetros de IP del cliente,
interfaz, dominio, NetBIOS ni OU.

Se ejecutó el paquete con la IP del DC, una credencial en memoria y
`-SkipRestart` para inspeccionar el resultado; después se reinició el cliente.

Resultados comprobados:

- Selección automática de `Laboratorio AD` y descubrimiento autenticado de
  `lci.lasalle.mx`, `LCI` y `OU=Laboratorio`.
- Proveedor y certificados instalados; salud mTLS verificada antes de la unión.
- Unión al dominio completada y `Test-ComputerSecureChannel` verdadero después
  del reinicio.
- `Test-SguClientEnrollment.ps1` con exigencia de dominio, broker, acceso remoto
  y RustDesk: `IsValid=True`, sin incidencias, después del guard de arranque.
- Interfaz privada `DomainAuthenticated`; interfaz de Internet `Public`, con
  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

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.