Windows Server 2022 CAL vs RDS CAL per un JumpServer PAM – Guida completa e pratica per capire quali licenze servono, come dimensionarle correttamente e come evitare errori di compliance quando il server RDS funge da “salto” per l’accesso privilegiato.
Contesto: perché un JumpServer in un progetto PAM
In una strategia di Privileged Access Management (PAM), il JumpServer è il punto di ingresso controllato da cui gli amministratori accedono in modalità remota agli asset sensibili. Centralizza autenticazione, audit, controllo delle sessioni e applica policy come MFA e Just‑In‑Time (JIT). Se il JumpServer è un host Remote Desktop Services (RDS), i suoi utenti avviano sessioni RDP verso il desktop o le app pubblicate sul server stesso e poi “saltano” verso gli altri sistemi amministrabili. Questo scenario richiede di distinguere con precisione tra le licenze Windows Server CAL e RDS CAL (talvolta chiamate TS CAL nei vecchi documenti) e di comprenderne durata e modelli.
CAL vs RDS CAL: cosa abilitano e quando sono obbligatorie
Tipo di licenza | A cosa serve | Quando è obbligatoria |
---|---|---|
Windows Server CAL (per utente o per dispositivo) | Consente l’accesso ai servizi di base del sistema operativo: autenticazione al dominio, condivisione file/stampa, servizi di directory, API di rete, gestione criteri, ecc. | Ogni utente/dispositivo che accede in qualunque modo a un’istanza di Windows Server deve possederne una, indipendentemente dall’uso di RDP. |
Remote Desktop Services CAL (RDS CAL, per utente o per dispositivo) | Abilita le sessioni Remote Desktop (full desktop o RemoteApp) su un host RDS: connessione RDP interattiva, brokered, licenziata. | Va acquistata in aggiunta alla CAL standard per ciascun utente/dispositivo che effettua una sessione RDP verso l’host RDS (JumpServer compreso). |
Messaggio chiave: le RDS CAL non sostituiscono le CAL di Windows Server. Per un JumpServer RDS servono entrambe, in cumulo, per ogni soggetto che esegue una sessione RDP.
Durata delle licenze e modelli di acquisto
- Perpetue (on‑prem tradizionale) – In modelli di licensing classici (es. Open Value, Enterprise Agreement e successori), le CAL Windows Server e le RDS CAL sono perpetue. È possibile aggiungere Software Assurance (SA) per benefici come upgrade a versioni successive, diritti di mobilità e supporto.
- A sottoscrizione – In scenari Service Provider (SPLA) o hosting gestito in cui il fornitore eroga servizi RDS ai propri clienti, esistono Subscriber Access Licenses (SAL) con canone mensile. Questo modello non si applica alle classiche installazioni on‑prem del cliente finale.
Applicazione pratica per un JumpServer
- Licenza di base Windows Server 2022 per il sistema operativo del JumpServer (per core, edizione Standard/Datacenter secondo necessità di virtualizzazione – tema distinto dalle CAL).
- Una Windows Server CAL per ogni utente o dispositivo che accede al server (qualsiasi accesso, non solo RDP).
- Una RDS CAL aggiuntiva per ogni utente o dispositivo che avvierà una sessione RDP verso il JumpServer.
Se gli utenti si collegano da molti dispositivi diversi conviene in genere la modalità User CAL; se invece più persone condividono poche postazioni fisse, spesso è più conveniente la Device CAL.
Per‑User o Per‑Device? Matrice decisionale
Criterio | User CAL | Device CAL |
---|---|---|
Utenti con molti endpoint (laptop + desktop + VDI + tablet) | Tipicamente più conveniente: 1 licenza per persona, uso su n dispositivi | Meno efficiente: servirebbe 1 licenza per ciascun device |
Postazioni condivise a turni (NOC, help desk, controllo accessi) | Possibile, ma non ottimale | Spesso ideale: 1 licenza per device usato da più persone |
Forza lavoro variabile (contractor stagionali) | Flessibile: assegni la licenza all’utente | Può essere meno flessibile se cambiano i device |
Tracciamento e reportistica | Per le RDS CAL l’uso per‑utente è “honor based”: serve governance | Per‑device è contabilizzato dal server licenze RDS |
Dimensionamento: come contare le licenze “giuste”
Formula di base (on‑prem):
- CAL Windows Server totali = numero di utenti o numero di dispositivi che accedono a qualunque server Windows nel dominio/foresta (scelta coerente con il modello per‑utente o per‑device).
- RDS CAL totali = numero di utenti o dispositivi che eseguono sessioni RDP verso host RDS (JumpServer compreso). Non contano gli utenti che non usano RDP.
Esempio: 35 amministratori interni e 5 contractor occasionali che usano il JumpServer da molteplici dispositivi. Tutti gli amministratori accedono a risorse Windows Server; 28 di loro faranno sessioni RDP quotidiane, 12 solo saltuarie.
- Scegli CAL per utente per semplificare: 40 Windows Server User CAL (35 + 5).
- Valuta l’uso reale RDP: se tutti i 40 possono potenzialmente avviare sessioni, servono 40 RDS User CAL. Se i 12 “saltuari” sono realmente esclusi dall’RDP, potresti acquistare 28 RDS User CAL e mantenere un processo rigoroso che impedisca l’RDP agli altri 12 (gruppi AD, RD Collection ACL, RD Gateway policies).
Nota: il “multiplexing” o l’accesso tramite applicazioni intermediarie non riduce la necessità di CAL. Anche l’uso di un RD Gateway non sostituisce le RDS CAL: le sessioni finali su host RDS restano soggette a licenza.
Eccezioni e limiti da conoscere
- Eccezione amministrativa a 2 sessioni: Windows Server consente fino a due connessioni RDP simultanee per amministrazione del server senza RDS CAL. Questa modalità non è adatta a un JumpServer PAM, dove più utenti accedono con regolarità: occorrono RDS CAL.
- Utenti esterni (non dipendenti): per le CAL Windows Server esiste il Windows Server External Connector per server specifici, come alternativa alle CAL per‑utente. Non esiste un External Connector per RDS: gli utenti esterni che fanno RDP necessitano di RDS CAL individuali (o SAL in scenari service provider).
- Ambienti multi‑foresta: la titolarità della CAL segue l’utente o il device, non il server. Assicurati che le policy di trust e i gruppi di sicurezza riflettano chi può avviare RDP, allineando il perimetro alla quantità di RDS CAL acquistate.
Ruoli RDS e gestione delle licenze
Per un JumpServer RDS minimale servono almeno:
- RD Session Host (il JumpServer stesso);
- RD Licensing (Server Licenze RDS), attivato e con pacchetti di RDS CAL installati;
- Opzionali ma consigliati: RD Gateway (per accesso HTTPS + MFA), RD Web (portal), RD Connection Broker (se aggiungi alta disponibilità o più host).
Passi essenziali per la conformità:
- Installa il ruolo Remote Desktop Services e il servizio RD Licensing su un server idoneo.
- Attiva il server licenze tramite RD Licensing Manager.
- Installa i pacchetti di RDS CAL (per utente o per dispositivo) nel Licensing Manager.
- Configura la modalità di licenza dell’RD Session Host (per utente/per dispositivo) e specifica il server licenze.
- Verifica con Diagnostica RDS che la distribuzione sia in stato “Configured” e senza errori.
Gli host RDS hanno un periodo di grazia durante il quale accetteranno connessioni prima che il server licenze sia attivato; non considerarlo un sostituto del corretto licensing. In modalità Per Utente, l’assegnazione è in gran parte basata sulla conformità organizzativa (il server licenze non “impedisce” le connessioni se superi il conteggio); predisponi quindi procedure di governance e reportistica.
Sicurezza e best practice per un JumpServer PAM
- Segmentazione e Tiering: posiziona il JumpServer in una rete di gestione (Tier 0) isolata, con ACL che consentano solo il minimo traffico necessario verso i sistemi amministrati.
- Autenticazione forte: impiega RD Gateway con autenticazione a più fattori. Integra con Conditional Access e limiti di origine (IP, device compliant).
- Just‑In‑Time e Just‑Enough‑Administration: concedi i privilegi per la sola durata necessaria, usando gruppi dinamici, PIM/PAM e scadenze automatiche.
- Hardening e monitoraggio: disabilita SMB non necessari, applica criteri GPO restrittivi, registra e analizza le sessioni (comandi, clipboard, file transfer), attiva la registrazione PowerShell e il controllo AppLocker/WDAC.
- Esperienza utente controllata: valuta RemoteApp per pubblicare solo gli strumenti amministrativi richiesti, riducendo il rischio rispetto al full desktop.
- Alta disponibilità: se il salto è critico, usa due RD Gateway e due Session Host dietro broker/Load Balancer; il server licenze può essere ridondato.
Checklist di compliance
- Inventario: elenco aggiornato di utenti e/o dispositivi che possono accedere a server Windows (per CAL) e che possono avviare RDP (per RDS CAL).
- Allineamento AD: gruppi dedicati (es. RDS_AllowedUsers) usati nei criteri RD e Gateway per riflettere la platea licenziata.
- Server Licenze RDS correttamente attivato, con pacchetti CAL installati, modalità coerente (User/Device).
- Policy di esclusione: impedisci l’RDP agli utenti non licenziati (NLA, GPO, RD CAP/RAP sul Gateway).
- Audit periodico: confronta i log di connessione (Gateway, Security, RDP) con il registro licenze per assicurare che le assegnazioni corrispondano all’uso reale.
- Documentazione: conserva contratti, proof of purchase, SA attiva, note interne sui criteri di assegnazione delle licenze.
Domande frequenti
Serve la RDS CAL se uso solo RD Gateway? Sì. Il Gateway incapsula RDP in HTTPS, ma la sessione finale è sempre RDP verso un host RDS; quindi occorre la RDS CAL oltre alla Windows Server CAL.
Se pubblico solo una RemoteApp, basta la CAL standard? No. La pubblicazione di RemoteApp è una funzionalità RDS: richiede RDS CAL oltre alla Windows Server CAL.
Le due connessioni RDP “gratuite” sono sufficienti per un JumpServer? No. Sono destinate esclusivamente all’amministrazione del server e non per dare accesso agli amministratori verso altri sistemi. Un JumpServer RDS richiede RDS CAL.
Posso mescolare per‑utente e per‑device? Sì, ma non sulla stessa istanza di Session Host per un singolo criterio di assegnazione; a livello organizzativo puoi avere entrambe le tipologie, purché la configurazione e i conti tornino (governance rigorosa consigliata).
Come cambiano le CAL con Standard vs Datacenter? L’edizione e la licenza per core coprono i diritti di esecuzione e virtualizzazione del server. Le CAL (Windows Server + RDS) sono sempre aggiuntive e indipendenti dall’edizione.
Ho utenti esterni occasionali; come gestirli? Per l’accesso ai servizi Windows Server puoi valutare l’External Connector. Per RDP, ogni utente esterno ha comunque bisogno di una RDS CAL individuale (oppure modelli a sottoscrizione in scenari erogati da service provider).
Guida compatta all’implementazione licenze RDS
- Definisci la platea di utenti (o dispositivi) che possono usare RDP sul JumpServer.
- Scegli il modello: RDS User CAL se gli utenti usano molti device; RDS Device CAL se più persone condividono poche postazioni.
- Acquista e attiva Windows Server CAL (User/Device) per tutti i soggetti che accedono a server Windows.
- Acquista e attiva RDS CAL (User/Device) per tutti i soggetti che faranno RDP verso il JumpServer.
- Configura RD Licensing, imposta la modalità coerente (User/Device) e verifica la conformità con i log di accesso.
- Rafforza l’accesso con RD Gateway + MFA, pubblicazioni minimali (RemoteApp) e policy che impediscano RDP agli utenti non licenziati.
Riepilogo esecutivo
- CAL Windows Server: necessaria per qualsiasi accesso a servizi Windows Server.
- RDS CAL: necessaria in aggiunta per ogni sessione RDP (desktop o app) verso host RDS.
- Durata: on‑prem tipicamente perpetue con opzione Software Assurance; modelli a sottoscrizione (SAL) nei contesti service provider/hosted.
- JumpServer: richiede entrambe le licenze per ciascun utente o dispositivo che avvia RDP. Scegli per‑utente o per‑device in base al profilo d’uso.
- Compliance: configura il server licenze, governa i gruppi autorizzati all’RDP, monitora i log e riallinea periodicamente.
Appendice: errori comuni da evitare
- Confondere CAL e licenza per core: la licenza per core ti consente di far girare Windows Server, non copre l’accesso degli utenti.
- Supporre che RD Gateway “elimini” le RDS CAL: falso; il Gateway è solo un proxy sicuro.
- Affidarsi al periodo di grazia: è temporaneo e non sostituisce l’attivazione del Licensing Server con i pacchetti CAL.
- Non allineare User/Device tra policy e acquisti: rischi di risultare fuori compliance anche se “pensavi” di aver abbastanza licenze.
- Non documentare: senza prove d’acquisto e procedure scritte, un audit diventa difficile anche se in realtà sei conforme.
Conclusioni
Per il JumpServer RDS in un progetto PAM la regola d’oro è semplice: CAL Windows Server + RDS CAL per ogni utente/dispositivo che avvia RDP, con modello per‑utente o per‑device scelto in base al profilo operativo. Affianca al corretto licensing una solida architettura di sicurezza (Gateway + MFA, RemoteApp, JIT, audit completo) e una rigorosa governance dei gruppi autorizzati. Così ottieni un accesso privilegiato controllato, misurabile e conforme.
Disclaimer: Questo contenuto è informativo e non sostituisce i termini contrattuali. Verifica sempre con il tuo rivenditore o con il produttore le condizioni applicabili al tuo accordo.