SGU-CredentialProvider/docs/azure-vpn-deployment.md

# Active Directory SGU en Azure: VPN opcional o enrolamiento directo

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

```powershell
$p2s = .\scripts\New-SguAzureP2sCertificates.ps1 `
  -ClientName 'AdminWorkstation'
```

Se pide una contraseña para proteger el PFX. La clave privada de la autoridad
raíz permanece no exportable en `Cert:\CurrentUser\My`; Azure recibe solamente
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
red, gateway, IP pública y VM, y una suscripción seleccionable.

```powershell
$azure = .\scripts\Deploy-SguAzureInfrastructure.ps1 `
  -SubscriptionId '00000000-0000-0000-0000-000000000000' `
  -ResourceGroupName 'rg-sgu-lab' `
  -Location 'centralus' `
  -AdministratorUsername 'azureadmin' `
  -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
repositorio.

Por omisión ningún puerto administrativo de la VM se abre desde Internet. Para
habilitar temporalmente RDP durante el bootstrap, indique exclusivamente su IP
pública actual:

```powershell
-AdministratorSourceAddressPrefix '203.0.113.10/32'
```

No utilice `0.0.0.0/0`. El despliegue de un VPN Gateway suele tardar bastante
más que la VM; omitirlo reduce tiempo y costo. El comando espera hasta que Azure
entregue un resultado final.

## 3. Conectarse al servidor

Cuando el gateway esté `Succeeded`:

```powershell
$vpn = .\scripts\Get-SguAzureP2sPackage.ps1 `
  -SubscriptionId '00000000-0000-0000-0000-000000000000' `
  -ResourceGroupName 'rg-sgu-lab' `
  -VpnGatewayName $azure.VpnGatewayName

.\scripts\Install-SguAzureP2sClient.ps1 `
  -VpnProfilePackagePath $vpn.PackagePath `
  -ClientCertificatePfxPath $p2s.ClientCertificatePath `
  -ClientRootCertificatePath $p2s.RootCertificatePath `
  -Connect
```

Con el túnel conectado, use RDP contra `10.77.0.4` y habilite la redirección de
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.

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

Descargue y extraiga `sgu-server-bootstrap-VERSION.zip` dentro de la VM. La IP
que recibe el bootstrap es la **privada** de la NIC, nunca la pública:

```bat
Start-SguAzureServerBootstrap.cmd 10.77.0.4 172.30.0.0/24
```

El modo `PlatformManaged` comprueba que Azure ya asignó `10.77.0.4/24`, pero no
deshabilita DHCP, no reemplaza la ruta predeterminada y no reinicia el adaptador.
El DNS de AD publica únicamente la dirección privada. `168.63.129.16` se usa
como reenviador DNS de la plataforma Azure.

Después del reinicio de promoción, verificar:

```powershell
Get-Content C:\ProgramData\SGU\Bootstrap\Server\bootstrap-complete.json
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` cuando exista VPN y los CIDR directos en
`PublicEnrollmentNetworks` cuando se hayan habilitado.

## 5. Enrolar cada VM Hyper-V

En la estación administrativa, emita una credencial distinta por equipo:

```powershell
$w11 = .\scripts\New-SguAzureP2sCertificates.ps1 -ClientName 'Windows11'
```

Copie a la VM Windows 10/11 de Hyper-V:

- `sgu-windows-client-bootstrap-VERSION.zip` extraído (Windows 10/11 x64);
- `$vpn.PackagePath`;
- `$w11.ClientCertificatePath`;
- `sgu-azure-p2s-root.cer`.

Desde la carpeta extraída del bootstrap de cliente, instale P2S y enrole:

```bat
Start-SguAzureClientEnrollment.cmd 10.77.0.4 C:\SGU\sgu-azure-vpn-client.zip C:\SGU\sgu-azure-p2s-Windows11.pfx C:\SGU\sgu-azure-p2s-root.cer
```

En una sola ejecución el comando:

1. importa el certificado de cliente en `LocalMachine\My` sin dejar la
   contraseña en disco;
2. instala un perfil IKEv2 de todos los usuarios llamado `SGU Azure P2S`;
3. agrega la ruta `10.77.0.0/16` y una regla NRPT que envía sólo
   `.lci.lasalle.mx` al DNS `10.77.0.4`;
4. conecta P2S con certificado de máquina;
5. registra mTLS, instala SGU/RustDesk y une el equipo al dominio;
6. reinicia Windows.

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
todos los usuarios y se puede seleccionar desde el control de red de la
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 o usando el acceso directo:

```powershell
Get-VpnConnection -Name 'SGU Azure P2S' -AllUserConnection
Get-DnsClientNrptRule | Where-Object DisplayName -like 'SGU Azure P2S*'
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
```

## Alcance de red y referencias

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)
- [Instalación de certificados P2S](https://learn.microsoft.com/en-us/azure/vpn-gateway/point-to-site-how-to-vpn-client-install-azure-cert)
- [Puertos necesarios para unir un dominio](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/active-directory-domain-join-troubleshooting-guidance)
- [Requisitos de edición de Windows](https://learn.microsoft.com/en-us/windows/security/licensing-and-edition-requirements)
- [Limitación de Always On device tunnel](https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-always-on-device-tunnel)