Votre application Java (Tomcat) et PostgreSQL tournent sur Windows Server 2022, et les utilisateurs y accèdent via un navigateur. Faut‑il acheter des CAL pour chaque poste ? Voici une réponse claire, des cas concrets et une méthode de décision.
Les postes de travail ont‑ils besoin de CAL avec Windows Server 2022 ?
Vue d’ensemble de la question
Contexte : une instance Windows Server 2022 Standard héberge PostgreSQL 14 et Tomcat 9. Les clients internes accèdent à l’application via un navigateur Web. Question : faut‑il des Device CAL (ou des User CAL) pour ces postes ?
La réponse dépend non pas de Tomcat ou de PostgreSQL en soi, mais de la manière dont les utilisateurs accèdent (directement ou indirectement) aux services Windows. Ci‑dessous, un tableau de décision prêt à l’emploi, puis des explications détaillées, des exemples et un checklist d’audit.
Réponse & solution
| Situation d’accès | CAL requise ? | Explications utiles |
|---|---|---|
| Accès Web pur (le navigateur échange uniquement avec l’application déployée sur Tomcat ; aucun partage réseau, aucune session RDP, pas d’authentification intégrée Windows) | Non | Les « web workloads » purement HTTP/HTTPS servis par l’application ne déclenchent pas, à eux seuls, l’obligation d’une CAL. L’accès reste applicatif et ne consomme pas de service Windows par le poste client. |
| Accès direct aux services Windows Server (partages SMB, impression, RPC/COM, WMI, WinRM/PowerShell Remoting, Kerberos/NTLM, RDP, etc.) | Oui | Tout périphérique ou utilisateur qui consomme un service natif Windows doit être couvert par une CAL (Device ou User). Les 2 sessions RDP d’administration sont une exception spécifique, sans usage utilisateur final. |
| Accès externe (clients hors de l’entreprise) | Pas de CAL individuelles si l’on opte pour un External Connector, sinon CAL par utilisateur/périphérique. | L’External Connector accorde un droit d’accès illimité aux utilisateurs non employés de l’organisation. Utile pour des portails partenaires/clients. |
| Scénarios mixtes (par ex. application Web + partages de fichiers, ou Web + authentification AD) | CAL nécessaires | Dès qu’un service Windows est utilisé (authentification AD, impression, SMB…), chaque périphérique ou utilisateur concerné doit être couvert. |
Notes importantes : (1) Si votre application Web utilise l’authentification intégrée Windows (NTLM/Kerberos) ou interroge Active Directory pour authentifier/autoriser un utilisateur, vous entrez dans la zone « consommation d’un service Windows » : des CAL sont requises pour les utilisateurs internes concernés. (2) Le multiplexage (accès via un serveur applicatif, une passerelle, un pool de connexions, une API) n’élimine pas les besoins en CAL pour les utilisateurs finaux qui accèdent indirectement au serveur.
Bonnes pratiques et compléments utiles
Choisir le bon type de CAL
- Device CAL : idéale quand plusieurs employés partagent le même poste (ex. kiosques, ateliers, salles de contrôle). Un seul périphérique = une CAL, quel que soit l’utilisateur.
- User CAL : préférable quand un même utilisateur accède depuis plusieurs appareils (PC pro + portable + tablette + mobile). Une personne = une CAL, quel que soit l’appareil.
- Règle pratique : plus d’appareils que de personnes ? pencher pour User CAL. Plus de personnes par appareil ? pencher pour Device CAL.
Évaluer la charge externe
- Si vous exposez un portail à des clients/partenaires, comparez le coût cumulé de CAL individuelles versus un External Connector. Ce dernier est conçu pour couvrir tous les utilisateurs externes identifiés.
- Pour du trafic Internet anonyme (lecture de contenu sans identification), les CAL ne s’appliquent généralement pas. Dès qu’il y a identification ou fonctions Windows sous‑jacentes : réévaluer.
Vérifier les clauses « web workload »
- Un workload Web pur signifie : pas d’usage direct par le poste client de SMB, RDP, RPC/COM, WMI, impression Windows, et pas d’authentification Windows intégrée. L’application traite les identités et les sessions côté applicatif.
- Si vous activez l’authentification AD (Kerberos/NTLM), la délégation, la lecture du profil utilisateur dans AD, ou des accès à des partages Windows, vous quittez le cas « web pur » : prévoyez des CAL.
Documenter votre architecture
- Cartographiez les flux : qui parle à qui ? via quels protocoles ? quels composants Windows sont impliqués (AD DS, DNS Windows, impression, SMB, RDP, WMI, WinRM) ?
- Identifiez les types d’utilisateurs : employés internes, prestataires, clients, anonymes. Associez‑leur un mode de couverture (User CAL, Device CAL, External Connector).
- Conservez des preuves (schémas, exports de configuration, règles réseau) pour faciliter tout audit.
Consulter un expert ou votre revendeur Microsoft
- Les règles évoluent et certaines architectures (clusters, conteneurs, hôtes virtualisés, VDI, BYOD étendu) exigent une validation spécifique.
Zoom sur les points qui déclenchent des CAL
- Authentification AD/Windows : tout utilisateur interne authentifié via Kerberos/NTLM consomme un service Windows (AD DS). Prévoyez des CAL pour ces utilisateurs.
- Partages de fichiers (SMB) : téléchargement de rapports depuis
\\serveur\partage, accès à des modèles, export via un lecteur réseau → CAL. - Impression Windows : impression via le spouleur Windows du serveur → CAL pour les utilisateurs/périphériques imprimant via ce serveur.
- Administration à distance : PowerShell Remoting (WinRM), WMI, RPC/COM → CAL.
- RDP : l’usage « utilisateur » de RDP exige des RDS CAL en plus des CAL Windows. Seules deux sessions d’administration simultanées sont incluses par serveur.
- Multiplexage : si une appliance, un pool ou un service applicatif « agrège » les connexions, les CAL se calculent sur les utilisateurs ou périphériques finaux, pas sur la taille du pool.
Ce qui ne déclenche pas de CAL côté client (scénario Web pur)
- Un navigateur qui échange en HTTP/HTTPS uniquement avec Tomcat, sans appels Windows exposés au client.
- Une authentification gérée par l’application (base utilisateurs interne, OAuth/OpenID, SSO non‑Windows), sans requêtes Kerberos/NTLM ni accès AD depuis le poste client.
- Des interactions strictement applicatives (API REST, JSON) où le poste ne monte pas de partage, n’imprime pas via le spouleur serveur et n’ouvre pas de session RDP.
Exemples concrets (et verdict CAL)
| Exemple | Description | Verdict CAL |
|---|---|---|
| Tomcat + PostgreSQL, login applicatif | L’utilisateur s’authentifie dans l’appli (base interne), lit/écrit des données via HTTP/HTTPS, pas de partage SMB ni RDP, pas d’IWA (auth intégrée). | Pas de CAL pour l’accès Web. Couvrez néanmoins le serveur par licences cœurs Windows Server. |
| Web + impression via serveur | Le bouton « Imprimer » envoie le job au spouleur Windows du serveur d’impression. | CAL requises pour chaque utilisateur/périphérique imprimant via ce serveur. |
| Web + fichiers sur partage | Téléchargement de documents depuis \\filesrv\projets ou dépôt de pièces jointes vers un partage SMB. | CAL requises pour les utilisateurs/périphériques accédant au partage. |
| Web + SSO Windows (IWA) | Authentification transparente via Kerberos/NTLM, l’appli s’appuie sur l’identité AD de l’utilisateur. | CAL requises pour les utilisateurs internes authentifiés. |
| Portail clients externes | Partenaires se connectant à un extranet pour suivi de commandes. | Choix entre CAL individuelles ou External Connector pour couvrir tous les externes. |
FAQ rapide
« PostgreSQL est open‑source ; cela change‑t‑il les CAL ? »
Non. Le besoin en CAL concerne l’accès aux services Windows, pas le SGBD. Que PostgreSQL soit open‑source n’influe pas sur le calcul des CAL Windows.
« Et si je migre Tomcat/PostgreSQL sur Linux ? »
Vous n’auriez plus besoin de CAL Windows pour les utilisateurs Web de ce workload. Mais attention aux autres ressources Windows (fichiers, impression, AD) éventuellement consommées par les utilisateurs : elles, si présentes, impliquent des CAL.
« Les sessions RDP pour support N1/N2 sont‑elles couvertes ? »
Non, le support utilisateur via RDP nécessite des RDS CAL en plus des CAL Windows. Seules les 2 sessions administratives simultanées par serveur sont incluses.
« Une passerelle API ou un reverse proxy me dispense‑t‑elle de CAL ? »
Non. Le multiplexage ne réduit pas le nombre de CAL. Le décompte se fait sur les utilisateurs/périphériques finaux qui accèdent indirectement au serveur.
« Comment compter en environnement virtualisé ? »
Les CAL sont par utilisateur ou périphérique et couvrent l’accès à toutes les instances de Windows Server dans l’organisation, quel que soit l’hôte. Les licences serveur (par cœur) et les droits de virtualisation (Standard vs Datacenter) sont un sujet distinct.
Modèle de décision (pas à pas)
- Cartographiez les accès : le poste client n’initie‑t‑il que des échanges HTTP/HTTPS vers Tomcat ? Oui/Non.
- Identités : l’utilisateur est‑il authentifié via AD/Windows (IWA, Kerberos/NTLM) ? Oui → CAL. Non → continuer.
- Services Windows consommés par le poste : SMB (lecteurs réseau), impression Windows, WMI/WinRM, RDP ? Oui → CAL.
- Population externe : des clients/partenaires identifiés accèdent‑ils au système ? Évaluer External Connector vs CAL individuelles.
- Choisir User vs Device CAL selon le ratio utilisateurs/appareils et les usages BYOD/télétravail.
- Documenter & archiver les décisions (qui est couvert, par quel type de CAL, justification).
Checklist d’audit de conformité
- Architecture et flux réseau à jour (schéma logique, ports/protocoles).
- Liste des services Windows exposés (SMB, RDP, AD DS, impression, WMI/WinRM…).
- Inventaire des utilisateurs (internes/externes) et périphériques (fixes, mobiles, kiosques), corrélé au type de CAL.
- Justificatifs d’authentification (mécanismes SSO, IWA, OAuth, annuaires).
- Trace des exceptions (2 sessions RDP administratives, comptes de service).
- Décision formelle sur External Connector pour les externes, si applicable.
- Preuves de communication interne (notes, procédures) et mises à jour en cas d’évolution.
Erreurs fréquentes à éviter
- Supposer que « c’est du Web » ⇒ pas de CAL : c’est faux si AD, SMB, impression ou RDP entrent en jeu.
- Oublier le multiplexage : un portail ou une API n’efface pas les CAL des utilisateurs en aval.
- Confondre CAL Windows et RDS CAL : deux familles distinctes, souvent complémentaires.
- Ignorer les prestataires (internes vs externes) : l’External Connector peut être plus économique selon le volume.
- Ne pas documenter la logique de couverture : en audit, l’absence de justification coûte cher.
Rappels sur la licence serveur (pour éviter les amalgames)
- Windows Server s’achète par cœurs pour chaque hôte (avec des règles de minimum par processeur et par serveur). Cela est indépendant des CAL.
- Standard vs Datacenter : la différence porte surtout sur les droits de virtualisation (nombre d’VM) et certaines fonctionnalités. Les CAL, elles, restent nécessaires selon les accès.
- Les CAL se facturent par utilisateur ou par périphérique et couvrent l’accès à toutes les instances Windows Server de l’organisation.
Synthèse opérationnelle
- Application Web pure (HTTP/HTTPS vers Tomcat, sans services Windows consommés par le poste, sans IWA) → pas de CAL côté client.
- Services Windows utilisés (AD/Windows, SMB, impression, RDP, WMI/WinRM…) → CAL requises (Device ou User selon le meilleur fit).
- Accès externes volumineux → évaluer External Connector.
- Documentez votre architecture, conservez les preuves, tenez‑vous informé des évolutions des règles.
Études de cas chiffrées (méthode de calcul)
Cas A : 40 employés, 25 postes partagés (atelier)
Usage majoritairement multi‑utilisateurs par poste. Hypothèse : accès à des partages SMB pour exporter des rapports. Device CAL souvent plus économique (25 vs 40). Ajouter des RDS CAL si des sessions utilisateurs RDP sont prévues.
Cas B : 60 employés, 120 appareils (PC, laptop, tablette), télétravail
Usage multi‑appareils par utilisateur. Hypothèse : SSO Windows sur le portail. User CAL généralement plus pertinente : une CAL couvre l’utilisateur sur l’ensemble de ses terminaux.
Cas C : Portail partenaires (2000 comptes externes)
Comparaison : 2000 CAL individuelles vs External Connector. Au‑delà de quelques centaines d’utilisateurs externes, l’External Connector est souvent plus simple et rentable sur le plan administratif.
Modèle de traçabilité (exemple de fiche)
| Élément | Décision / État | Justification | Preuves |
|---|---|---|---|
| Mécanisme d’authentification | Login applicatif (pas d’IWA) | Évite l’usage direct d’AD côté client | Capture d’écran config SSO, schéma d’architecture |
| Accès fichiers | Pas de SMB côté poste | Téléchargements via l’appli uniquement | Politique pare‑feu, règles reverse proxy |
| Impression | Spouleur applicatif → imprimantes réseau IP | Pas d’impression via serveur Windows | Documentation déploiement |
| Population externe | Partenaires identifiés | External Connector à étudier | Estimation volumétrique, business case |
Conclusion
Pour un workload Web pur (Tomcat/PostgreSQL) où les postes clients n’utilisent aucun service Windows et où l’authentification est applicative, les CAL côté client ne sont pas requises. Dès que vous introduisez une brique Windows consommée depuis le poste (AD, SMB, impression, RDP, WMI/WinRM…), des CAL deviennent nécessaires pour chaque utilisateur ou périphérique concerné. Pour des populations externes, comparez CAL individuelles et External Connector. Enfin, documentez votre architecture et faites valider les cas limites : c’est la meilleure assurance de conformité dans la durée.
Récapitulatif en une ligne : Application web pure → pas de CAL ; services Windows utilisés → CAL (Device ou User) ; accès externes → envisager l’External Connector.