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

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