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:

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. 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.