Cuando un clúster de Remote Desktop Session Host (RDSH) en Windows Server 2019 sigue limitado a dos conexiones aun después de instalar licencias per‑user, el problema casi nunca está en el servidor de licencias. Normalmente se trata de un bloqueo en la ruta de red o en la capa intermedia de acceso privilegiado. En esta guía profundizamos en un caso real —con CyberArk PAM y dos servidores PSM—, explicamos cómo se diagnosticó, cuál fue la causa raíz y qué pasos seguir para evitar que vuelva a ocurrir.
Resumen del escenario
La organización contaba con:
- Un servidor de licencias RDS sobre Windows Server 2019 con 20 CAL instaladas y activadas per user.
- Dos hosts RDSH nuevos, también en Windows Server 2019 Datacenter.
- Un par de Privileged Session Manager (PSM) de CyberArk detrás de un Connection Broker.
- Firewall interno segmentando la subred de producción (PSM /24) de la de servicios (RDSH /24).
Todo parecía correcto: el Licensing Diagnoser mostraba las licencias disponibles y el modo de licencia aparecía fijado a “Per User”. Sin embargo, al intentar la tercera conexión simultánea surgía el mensaje: El servidor remoto exige desconectar la sesión existente
.
Síntomas y pistas iniciales
- Solo dos usuarios podían iniciar sesión a la vez desde CyberArk.
- Conexiones RDP directas desde un portátil de administración sí consumían licencias de forma adecuada.
- El visor de eventos de los RDSH no mostraba errores relevantes de TLS Handshake ni de TerminalServices‑Licensing.
- Desde el primer PSM los usuarios sí obtenían CAL; desde el segundo, no.
Análisis del entorno
Cada PSM encapsula la sesión RDP del usuario antes de enviarla al Connection Broker, que a su vez balancea contra los nodos RDSH con Session Collection. El licenciamiento se negocia después de establecer el canal TLS y antes de presentar la pantalla de inicio de sesión de Windows. Si algo interrumpe ese intercambio (puerto 3389 o puertos dinámicos RPC 49152‑65535) el servidor no puede asociar la CAL y revierte al modo de gracia (dos conexiones).
Pruebas de conectividad
Test-NetConnection -ComputerName RDSH01 -Port 3389desde PSM‑A ⇒ Éxito.Test-NetConnection -ComputerName RDSH01 -Port 3389desde PSM‑B ⇒ Fallido.- Captura tcpdump/Pktmon en RDSH mostraba SYN desde PSM‑B, pero la respuesta nunca volvía (SYN‑ACK se perdía).
Descartando configuraciones de licencias
Se verificó la GPO Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Licensing:
- Use the specified Remote Desktop licensing mode = Enabled → Per User.
- Specify the license servers = Enabled →
licsrv01.ad.contoso.com.
En el registro (HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCMLicensing) los valores LicensingMode = 4 y SpecifiedLicenseServers coincidían, así que el problema claramente no era de configuración.
Causa raíz
El firewall interno carecía de una regla que permitiese el retorno del tráfico TCP 3389 desde la subred de los RDSH (x.y.32.0/24) hacia la subred del segundo PSM (x.y.40.0/24). El handshake RDP se establecía solo en un sentido; al no completarse, el host dejaba la sesión en estado “listener” y jamás llegaba a solicitar una CAL al servidor de licencias.
Solución aplicada
- Se agregó la regla ALLOW 3389 INBOUND SRC x.y.40.0/24 DST x.y.32.0/24.
- Se limpió la caché de DNS y las sesiones de licencia (
RD Licensing Diagnoser → Refresh All). - Los usuarios probaron de nuevo desde CyberArk PSM‑B y, esta vez, la tercera y cuarta conexiones consumieron CAL sin restricciones.
Validación después de la corrección
- Comando
qwinsta /server:RDSH01mostró más de dos sesiones activas. - El visor de eventos
Microsoft‑Windows‑TerminalServices‑RemoteConnectionManager/Operationalregistró Event 1149: Remote Desktop Services: User authentication succeeded con License Issued = Yes. - En el servidor de licencias, RD Licensing Manager marcó 4 de 20 CAL emitidas.
Buenas prácticas de licenciamiento y red
| Área | Verificación recomendada |
|---|---|
| Licenciamiento | Confirmar modo “Per User” en GPO y en claves LicensingMode, además de listar el servidor en SpecifiedLicenseServers. |
| Versiones | Mantener la secuencia Licensing Server ≥ CAL Version ≥ RDSH. En entornos homogéneos 2019 se cumple por defecto. |
| Conectividad | Comprobar TCP 3389 y puertos dinámicos RPC desde todos los orígenes (PSM, jump servers, agentes de automatización) hasta cada RDSH. |
| Capa intermedia | Verificar que proxies, IDS/IPS o Deep Packet Inspection no intervengan en el TLS handshake ni en la negociación de licencias. |
| Diagnóstico continuo | Usar RD Licensing Diagnoser solo como comprobación final; primero inspeccionar red y autenticación. |
Checklist de verificación rápida
- ☑ Servidor de licencias activado y con CAL per user.
- ☑ Modo Per User aplicado vía GPO y registro.
- ☑ Conectividad bidireccional TCP 3389 entre PSM/jump server ⇄ RDSH.
- ☑ No hay NAT hair‑pinning o rutas asimétricas.
- ☑ TLS 1.2 habilitado en RDSH y licenciamiento.
- ☑ Certificado RDS válido y sin algoritmo débil (SHA‑1).
Preguntas frecuentes (FAQ)
¿Por qué se limita a dos conexiones aunque existan CAL instaladas?
Dos conexiones es el modo de gracia cuando el servidor no puede contactar al servidor de licencias o completar el proceso de asignación. Una interrupción de red o un certificado inválido fuerza ese retroceso.
¿Las CAL per device evitarían el problema?
No. El proceso de negociación es idéntico; si el flujo RDP se corta antes de registrar la licencia, el resultado seguirá siendo un límite de dos sesiones.
¿Cómo depurar el puerto 3389 cuando hay inspección SSL?
Use Wireshark con filtro tcp.port == 3389 y habilite Decode As → TPKT. Si no aparece el paquete Licensing Response, hay algo interrumpiendo la fase post‑handshake.
Glosario de términos
RDSHServidor que hospeda sesiones de Escritorio Remoto simultáneas para varios usuarios. CALLicencia de Acceso de Cliente que autoriza a un usuario o dispositivo a conectarse legalmente a los servicios RDS. PSMMódulo de CyberArk que graba y controla accesos privilegiados vía RDP/SSH. Connection BrokerComponente de RDS que distribuye las sesiones entre distintos hosts.
Conclusión
El incidente demostró que, en infraestructuras con herramientas PAM como CyberArk, la capa de red es tan importante como la configuración de licencias. La ausencia de una simple regla de firewall impidió completar el round‑trip del puerto 3389, provocando que los RDSH permanecieran en modo de prueba con solo dos conexiones. Una vez abierta la ruta, las CAL se asignaron automáticamente y el servicio recuperó la capacidad esperada.