Automate direct domain enrollment across Windows versions
This commit is contained in:
@@ -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.
|
||||
@@ -1,24 +1,27 @@
|
||||
# Active Directory SGU en Azure con VPN Point-to-Site
|
||||
# Active Directory SGU en Azure: VPN opcional o enrolamiento directo
|
||||
|
||||
Esta variante conserva Active Directory en una VM Windows Server 2025 con IP
|
||||
pública de Azure, pero **no publica Active Directory en Internet**. La IP pública
|
||||
sirve para el ciclo de vida y, opcionalmente, RDP desde un único CIDR
|
||||
administrativo. DNS, Kerberos, LDAP, SMB, RPC, WinRM, Auth Broker, monitoreo y
|
||||
RustDesk viajan por Azure VPN Gateway Point-to-Site (P2S).
|
||||
La misma plantilla despliega Active Directory en Windows Server 2025 y permite
|
||||
elegir entre Azure VPN Gateway Point-to-Site (P2S) o acceso público directo. El
|
||||
modo directo restringe AD, WinRM, Auth Broker y RustDesk a los CIDR públicos
|
||||
indicados; el cliente configura DoH y la resolución del dominio automáticamente.
|
||||
La lista pública vacía no expone esos servicios.
|
||||
|
||||
La plantilla crea:
|
||||
|
||||
- VNet `10.77.0.0/16`, subnet del DC `10.77.0.0/24` y `GatewaySubnet`;
|
||||
- VNet `10.77.0.0/16`, subnet del DC `10.77.0.0/24` y, si se solicita, `GatewaySubnet`;
|
||||
- Windows Server 2025 con IP privada estática `10.77.0.4` reservada en la NIC;
|
||||
- IP pública Standard para la VM, protegida por NSG;
|
||||
- VPN Gateway `VpnGw1` con IKEv2/SSTP y autenticación por certificados;
|
||||
- VPN Gateway opcional `VpnGw1AZ` con IKEv2/OpenVPN y autenticación por certificados;
|
||||
- pool P2S `172.30.0.0/24`, autorizado en los firewalls SGU;
|
||||
- DNS de la NIC del servidor apuntando a `10.77.0.4`.
|
||||
|
||||
Los prefijos son parámetros. Deben ser RFC1918 y no deben solaparse con las
|
||||
redes usadas por Hyper-V, el `Default Switch`, Wi-Fi o Ethernet locales.
|
||||
Los prefijos privados deben ser RFC1918 y no deben solaparse con las redes usadas
|
||||
por Hyper-V, el `Default Switch`, Wi-Fi o Ethernet locales. Los prefijos de
|
||||
enrolamiento directo deben ser CIDR IPv4 públicos explícitos.
|
||||
|
||||
## 1. Crear la autoridad P2S y el certificado de administración
|
||||
## 1. Elegir el modo de conectividad
|
||||
|
||||
Para P2S, crear la autoridad y el certificado de cada cliente:
|
||||
|
||||
En la estación administrativa donde está el repositorio:
|
||||
|
||||
@@ -33,6 +36,10 @@ el `.cer` público. El PFX es una credencial de acceso a la VNet: se debe copiar
|
||||
únicamente a la VM correspondiente y eliminarse de ubicaciones compartidas
|
||||
después de importarlo.
|
||||
|
||||
Para acceso directo no se necesita certificado P2S. Se necesita conocer el
|
||||
segmento público de salida del laboratorio; por ejemplo, la IP
|
||||
`200.13.89.183` pertenece a `200.13.89.0/24`.
|
||||
|
||||
## 2. Desplegar Azure
|
||||
|
||||
Requisitos: Azure CLI, una sesión iniciada con `az login`, permisos para crear
|
||||
@@ -47,6 +54,19 @@ $azure = .\scripts\Deploy-SguAzureInfrastructure.ps1 `
|
||||
-P2sRootCertificatePath $p2s.RootCertificatePath
|
||||
```
|
||||
|
||||
Sin VPN y autorizando un laboratorio completo:
|
||||
|
||||
```powershell
|
||||
$azure = .\scripts\Deploy-SguAzureInfrastructure.ps1 `
|
||||
-SubscriptionId '00000000-0000-0000-0000-000000000000' `
|
||||
-ResourceGroupName 'rg-sgu-lab' `
|
||||
-Location 'centralus' `
|
||||
-AdministratorUsername 'azureadmin' `
|
||||
-DeployVpnGateway $false `
|
||||
-PublicEnrollmentSourceAddressPrefixes '200.13.89.0/24' `
|
||||
-AdministratorSourceAddressPrefix '200.13.89.0/24'
|
||||
```
|
||||
|
||||
La contraseña local de la VM se solicita como `SecureString`, se coloca sólo en
|
||||
un archivo temporal con ACL exclusiva para el usuario actual y se elimina al
|
||||
terminar. No aparece en los argumentos de Azure CLI ni queda guardada en el
|
||||
@@ -61,9 +81,10 @@ pública actual:
|
||||
```
|
||||
|
||||
No utilice `0.0.0.0/0`. El despliegue de un VPN Gateway suele tardar bastante
|
||||
más que la VM; el comando espera hasta que Azure entregue un resultado final.
|
||||
más que la VM; omitirlo reduce tiempo y costo. El comando espera hasta que Azure
|
||||
entregue un resultado final.
|
||||
|
||||
## 3. Descargar P2S y entrar por la IP privada
|
||||
## 3. Conectarse al servidor
|
||||
|
||||
Cuando el gateway esté `Succeeded`:
|
||||
|
||||
@@ -85,8 +106,11 @@ una unidad local para copiar `sgu-server-bootstrap-VERSION.zip` a la VM. La NIC
|
||||
ya apunta a su futura dirección DNS propia, por lo que la resolución pública no
|
||||
está disponible hasta que el bootstrap instale DNS y sus reenviadores. Así no es
|
||||
necesario abrir 3389 en la IP pública. La opción
|
||||
`AdministratorSourceAddressPrefix` queda como ruta de recuperación temporal,
|
||||
no como el camino normal.
|
||||
`AdministratorSourceAddressPrefix` queda como ruta de recuperación temporal.
|
||||
|
||||
En modo directo, use RDP contra `$azure.DomainControllerPublicIp` desde un origen
|
||||
incluido en `AdministratorSourceAddressPrefix`. RDP y enrolamiento tienen listas
|
||||
separadas para poder retirar RDP sin interrumpir los clientes.
|
||||
|
||||
## 4. Ejecutar el bootstrap dentro de Windows Server
|
||||
|
||||
@@ -110,9 +134,10 @@ Resolve-DnsName _ldap._tcp.dc._msdcs.lci.lasalle.mx -Type SRV -Server 10.77.0.4
|
||||
```
|
||||
|
||||
El JSON debe indicar `NetworkConfigurationMode = PlatformManaged`, el pool P2S
|
||||
en `TrustedClientNetworks` y ambos prefijos en `AllowedRemoteAddresses`.
|
||||
en `TrustedClientNetworks` cuando exista VPN y los CIDR directos en
|
||||
`PublicEnrollmentNetworks` cuando se hayan habilitado.
|
||||
|
||||
## 5. Emitir un certificado y enrolar cada VM Hyper-V
|
||||
## 5. Enrolar cada VM Hyper-V
|
||||
|
||||
En la estación administrativa, emita una credencial distinta por equipo:
|
||||
|
||||
@@ -144,9 +169,28 @@ En una sola ejecución el comando:
|
||||
5. registra mTLS, instala SGU/RustDesk y une el equipo al dominio;
|
||||
6. reinicia Windows.
|
||||
|
||||
Si la red local bloquea IKEv2 (UDP 500/4500), el paquete de Azure también
|
||||
incluye un perfil SSTP sobre TCP 443, pero ese fallback todavía requiere
|
||||
instalación manual con el instalador oficial incluido en `WindowsAmd64`.
|
||||
Para el modo directo, cada Windows 10/11 usa el lanzador normal y la IP pública;
|
||||
no necesita perfil ni certificado VPN:
|
||||
|
||||
```bat
|
||||
Start-SguClientEnrollment.cmd 20.9.81.130
|
||||
```
|
||||
|
||||
El bootstrap pide la cuenta de dominio, prueba todas las interfaces con ruta,
|
||||
descubre el bosque por WinRM, instala el certificado público DoH, configura NRPT
|
||||
y los nombres del DC/broker, registra mTLS y une la máquina. No pide una IP del
|
||||
cliente ni una interfaz.
|
||||
|
||||
Si la red local bloquea IKEv2 (UDP 500/4500), se puede generar un perfil
|
||||
OpenVPN sobre TCP 443 para Azure VPN Client. Ese fallback requiere instalar
|
||||
y configurar el cliente correspondiente; el bootstrap instala el perfil nativo
|
||||
IKEv2. Azure ya no admite SSTP al crear este gateway.
|
||||
|
||||
La prueba real con `Windows11-002` y un bosque en Azure está documentada en
|
||||
[la validación del despliegue del 10 de septiembre de 2026](azure-deployment-validation-2026-09-10.md).
|
||||
Incluye un device tunnel para Enterprise y recuperación de Netlogon cuando el
|
||||
túnel tarda en estar disponible al arrancar. Son configuraciones adicionales
|
||||
aplicadas a esa VM; el instalador publicado crea el perfil manual anterior.
|
||||
|
||||
Windows 10/11 Pro admite unión a AD y VPN nativa, pero Microsoft no licencia el
|
||||
**Always On VPN device tunnel** para Pro. Por ello el perfil se instala para
|
||||
@@ -155,21 +199,23 @@ pantalla de inicio de sesión; antes del primer logon de una cuenta de dominio,
|
||||
conecte `SGU Azure P2S` allí. Enterprise/Education pueden recibir posteriormente
|
||||
un device tunnel Always On, pero eso no es requisito del enrolamiento SGU.
|
||||
|
||||
Validación dentro del cliente, con la VPN conectada:
|
||||
Validación dentro del cliente, con la VPN conectada o usando el acceso directo:
|
||||
|
||||
```powershell
|
||||
Get-VpnConnection -Name 'SGU Azure P2S' -AllUserConnection
|
||||
Get-DnsClientNrptRule | Where-Object DisplayName -like 'SGU Azure P2S*'
|
||||
Test-NetConnection 10.77.0.4 -Port 5985
|
||||
Test-NetConnection 20.9.81.130 -Port 5985
|
||||
Resolve-DnsName _ldap._tcp.dc._msdcs.lci.lasalle.mx -Type SRV
|
||||
nltest.exe /dsgetdc:lci.lasalle.mx
|
||||
```
|
||||
|
||||
## Seguridad y referencias
|
||||
## Alcance de red y referencias
|
||||
|
||||
No agregue reglas NSG públicas para 53, 88, 135, 389, 445, 464, 636, 3268,
|
||||
3269 ni RPC dinámico. El conjunto de puertos necesario para una unión de dominio
|
||||
es precisamente la razón de encapsularlo en P2S.
|
||||
P2S mantiene los puertos de AD dentro del túnel. El modo directo abre el conjunto
|
||||
necesario para la unión sólo desde `publicEnrollmentSourceAddressPrefixes` y
|
||||
replica la misma lista en Windows Firewall mediante `PublicEnrollmentNetworks`.
|
||||
Prefiera `/32` si la salida es estable; use `/24` únicamente cuando deba admitir
|
||||
todo el segmento. Retire el CIDR cuando termine la prueba si ya no se requiere.
|
||||
|
||||
- [Azure VPN Gateway P2S con certificados](https://learn.microsoft.com/en-us/azure/vpn-gateway/point-to-site-certificate-gateway)
|
||||
- [Cliente P2S nativo de Windows](https://learn.microsoft.com/en-us/azure/vpn-gateway/point-to-site-vpn-client-certificate)
|
||||
|
||||
@@ -19,7 +19,7 @@ por esa u otra interfaz.
|
||||
|
||||
Cuando el servidor vive en Azure, no se configura la IP dentro del sistema
|
||||
operativo. La NIC reserva la IP privada y se usa el modo `PlatformManaged`; el
|
||||
procedimiento completo, incluidos VPN Gateway y los clientes Hyper-V, está en
|
||||
procedimiento completo, con VPN Gateway opcional o enrolamiento público directo, está en
|
||||
[azure-vpn-deployment.md](azure-vpn-deployment.md).
|
||||
|
||||
1. Descargar y extraer `sgu-server-bootstrap-VERSION.zip`.
|
||||
@@ -70,6 +70,18 @@ privada. También vuelve a iniciar brevemente esa NIC privada si Windows Server
|
||||
2025 todavía la clasifica como Public al terminar la promoción. La salida HTTPS
|
||||
continúa por la NIC que tenga el gateway predeterminado.
|
||||
|
||||
Para permitir clientes que llegan directamente desde un segmento público, use
|
||||
`-PublicEnrollmentNetworks` al preparar el servidor. El parámetro valida y
|
||||
normaliza cada CIDR y limita a esos orígenes los puertos de AD, DoH, WinRM,
|
||||
broker y RustDesk:
|
||||
|
||||
```powershell
|
||||
.\Initialize-SguDomainController.ps1 `
|
||||
-ServerIPv4Address 10.77.0.4 `
|
||||
-NetworkConfigurationMode PlatformManaged `
|
||||
-PublicEnrollmentNetworks 200.13.89.0/24
|
||||
```
|
||||
|
||||
El broker arranca con una lista de clientes vacía. Eso no abre el servicio: mTLS
|
||||
rechaza todos los certificados hasta que el primer cliente registra el suyo.
|
||||
Los archivos opcionales colocados en `payload\server-content\Packages` al crear
|
||||
@@ -114,12 +126,19 @@ el error queda en `C:\ProgramData\SGU\Bootstrap\Client\latest-error.log`.
|
||||
El manifiesto usa `Auto` y ambos Windows ejecutan el mismo código. Azure P2S está
|
||||
incluido para ambos; otras VPN ya conectadas usan el lanzador habitual.
|
||||
|
||||
También puede proporcionarse directamente la IP pública del DC. Tras autenticar
|
||||
WinRM, el bootstrap configura DoH y resolución dividida, valida el SRV de AD y
|
||||
continúa sin pedir la IP del cliente. El segmento de salida del laboratorio debe
|
||||
estar en la lista `PublicEnrollmentNetworks` del servidor y en el NSG/firewall
|
||||
perimetral; por ejemplo, `200.13.89.0/24` cubre las salidas `.1` a `.254`.
|
||||
|
||||
Después de UAC, se solicita interactivamente la credencial autorizada para unir
|
||||
equipos. La contraseña existe sólo en memoria. El bootstrap:
|
||||
|
||||
1. selecciona una interfaz con conectividad comprobada al servidor;
|
||||
2. abre una sesión WinRM autenticada con el DC, descubre el dominio y configura
|
||||
DNS mediante NRPT sólo para ese dominio, conservando el DNS de Internet;
|
||||
DNS mediante NRPT sólo para ese dominio; cuando la IP es pública, además
|
||||
configura y valida automáticamente DoH, conservando el DNS de Internet;
|
||||
3. crea en el cliente un certificado mTLS RSA-3072 no exportable y envía sólo su
|
||||
parte pública al broker;
|
||||
4. recupera por esa sesión autenticada el certificado público del broker;
|
||||
@@ -134,6 +153,11 @@ equipos. La contraseña existe sólo en memoria. El bootstrap:
|
||||
`rustdesk.lci.lasalle.mx` y registra el ID del dispositivo en el inventario
|
||||
protegido del DC.
|
||||
|
||||
Cuando la IP del DC es pública, el paso 2 crea o reutiliza DoH en el servidor,
|
||||
recupera su certificado público, configura el cliente y valida el registro SRV
|
||||
antes de continuar. El mismo doble clic funciona en LAN, una VPN ya conectada o
|
||||
Internet directo; el operador sólo proporciona IP del DC y credenciales.
|
||||
|
||||
Para elegir adaptador o nombre del equipo explícitamente:
|
||||
|
||||
```powershell
|
||||
|
||||
@@ -36,6 +36,22 @@ contrario, el contenedor de equipos configurado en AD. Los parámetros
|
||||
explícitamente. Para otra cuenta, editar el usuario sugerido como
|
||||
`DOMINIO\usuario` o `usuario@dominio`. No se guardan contraseñas.
|
||||
|
||||
Si la IPv4 proporcionada es pública, el mismo flujo configura automáticamente
|
||||
la conectividad directa. Después de autenticar WinRM, el servidor crea o reutiliza
|
||||
un certificado DoH, publica DNS cifrado en TCP 443 y devuelve únicamente su
|
||||
certificado público. El cliente lo confía, registra el servidor DoH, agrega la
|
||||
regla NRPT y fija localmente los nombres del DC, dominio, broker y RustDesk a esa
|
||||
IP. A continuación comprueba el registro SRV de AD y continúa con la unión. El
|
||||
operador sigue introduciendo solamente IP del DC, usuario y contraseña.
|
||||
|
||||
El servidor o firewall perimetral debe autorizar previamente el segmento público
|
||||
del laboratorio. En el bootstrap del servidor se hace con
|
||||
`-PublicEnrollmentNetworks 200.13.89.0/24`; en Azure, con
|
||||
`-PublicEnrollmentSourceAddressPrefixes 200.13.89.0/24`. La lista vacía no abre
|
||||
puertos. Este modo requiere Windows 11 o una versión de Windows 10 que exponga
|
||||
los cmdlets DNS-over-HTTPS; en equipos anteriores funciona si la red ya permite
|
||||
DNS tradicional hacia el DC.
|
||||
|
||||
El DNS se configura mediante una regla NRPT para el dominio descubierto,
|
||||
conservando los servidores DNS de los adaptadores y la resolución de Internet.
|
||||
Las políticas DNS/VPN corporativas deben permitir resolver ese dominio.
|
||||
|
||||
+6
-6
@@ -2,12 +2,12 @@
|
||||
|
||||
## Public Azure deployment
|
||||
|
||||
Owning a public Azure IP does not make the domain controller an Internet-facing
|
||||
directory service. The supported cloud topology exposes no AD DS, DNS, SMB,
|
||||
RPC, WinRM, broker, monitoring, or RustDesk port publicly. Hyper-V and later
|
||||
physical Windows clients enter the VNet through certificate-authenticated Azure
|
||||
VPN Gateway P2S; the Azure NSG and Windows firewall accept the P2S pool and the
|
||||
private VNet only. See [azure-vpn-deployment.md](azure-vpn-deployment.md).
|
||||
The Azure topology supports certificate-authenticated P2S or direct enrollment.
|
||||
P2S keeps AD services inside the VNet. Direct enrollment exposes the required
|
||||
AD, DNS/DoH, WinRM, broker and RustDesk ports only to explicit public IPv4 CIDRs;
|
||||
an empty allowlist exposes none of them. Azure NSG and Windows Firewall enforce
|
||||
the same source list. RDP uses a separate allowlist. See
|
||||
[azure-vpn-deployment.md](azure-vpn-deployment.md).
|
||||
|
||||
## Password handling
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user