Licences Windows Server pour FTP/SFTP : CAL, RDS, limites et guide complet

Vous hébergez ou projetez d’héberger un service FTP/SFTP sur Windows Server pour ~60 périphériques d’un même LAN ? Voici un guide clair et opérationnel : licences (CAL vs RDS), limites, dimensionnement, sécurité et pas‑à‑pas IIS/OpenSSH pour une mise en production conforme et performante.

Vue d’ensemble de la question

Contexte : vous souhaitez exposer un service de transfert de fichiers à ~60 périphériques (postes, scanners, automates industriels, NAS, etc.) connectés au même réseau local que le serveur Windows Server. Les questions clés portent sur le type de licences à acquérir, l’utilité des RDS CAL, les éventuelles limites de connexions et les effets de la période de grâce RDS de 120 jours.

Rappel essentiel : architecture des licences Microsoft

Avant de répondre point par point, il est utile de replacer FTP/SFTP dans le cadre global des licences Windows Server :

• Licence Windows Server (par cœur) : chaque serveur physique/virtuel doit être licencié (cœurs CPU). Cela n’autorise pas, à elle seule, l’accès des utilisateurs ou périphériques au serveur.
• Windows Server CAL : licence d’accès client obligatoire pour chaque utilisateur ou périphérique qui consomme un service du serveur (fichier, impression, FTP, SMB, etc.). Deux modes : Par utilisateur ou Par périphérique.
• RDS CAL : licence additionnelle requise uniquement si des utilisateurs ouvrent une session Bureau à distance (Remote Desktop Services) sur un hôte RDS.
• Rôle/Service : FTP (rôle IIS) et SFTP (OpenSSH Server) sont des composants système. Ils ne demandent pas de licence spécifique supplémentaire au‑delà des CAL Windows Server.

Réponse & solutions (synthèse immédiate)

Sujet	Explications
Différence CAL Windows Server / RDS CAL	Windows Server CAL : autorise l’accès légal à tous les services du serveur (fichiers, impression, FTP, etc.). RDS CAL : requise uniquement si l’utilisateur ouvre une session Bureau à distance (Remote Desktop).
FTP/SFTP ne consomme pas de RDS CAL	Un client FTP/SFTP (FileZilla, WinSCP, scp, etc.) n’initie pas de session RDS ; aucune RDS CAL n’est donc nécessaire, que l’accès soit local ou distant.
Choix du mode de CAL Windows Server	Par périphérique : idéal si plusieurs personnes partagent un même poste. Par utilisateur : recommandé si chaque personne possède plusieurs appareils (PC, mobile, tablette). Pour ~60 périphériques, visez 60 CAL périphérique ou jusqu’à 60 CAL utilisateur selon votre scénario.
Limite de connexions simultanées	Les CAL n’imposent aucune contrainte technique. Le nombre de sessions FTP/SFTP parallèles dépend uniquement du matériel (CPU, RAM, stockage, réseau) et de la configuration IIS FTP ou OpenSSH Server.
Licence RDS temporaire de 120 jours	La période de grâce concerne exclusivement RDS. Si vous n’utilisez pas le Bureau à distance (RDSH), elle n’a aucun effet sur votre service FTP/SFTP.
Implémenter SFTP sans supplément	Depuis Windows Server 2019, le rôle OpenSSH Server s’ajoute via les fonctionnalités facultatives ; il fournit un SFTP natif et sécurisé, sans coût additionnel.
Bonnes pratiques	1. Créer un groupe FTPUsers et restreindre les ACL au répertoire racine. 2. Activer l’isolation (IIS) ou la restriction SFTP (p. ex. ChrootDirectory sur OpenSSH, voir notes ci‑dessous). 3. Forcer TLS 1.2+ pour FTPS explicite ou privilégier SFTP/SSH. 4. Surveiller les performances avec Performance Monitor pour cibler les goulots d’étranglement.

Informations complémentaires utiles

• Éditions Standard/Datacenter (2019/2022) : aucune limite intégrée de connexions FTP/SFTP (la capacité dépend des ressources serveur et de vos réglages).
• Édition Essentials 2019 : plafonnée à 25 utilisateurs ou 50 appareils, CAL incluses. Au‑delà, passer à Standard.
• OpenSSH Server : SFTP natif ; pour des fonctions avancées (quota applicatif, MFA, rapports détaillés), envisagez des solutions tierces si besoin.
• Tests de charge : simulez 60 sessions concurrentes et surveillez CPU/Mémoire/Disque/Réseau pour anticiper une montée en gamme (second serveur, équilibrage de charge, stockage SSD/NVMe).

Focus licences : ce que vous devez vraiment acheter

Windows Server CAL : par utilisateur ou par périphérique ?

Choisissez le mode qui minimise le nombre total de CAL nécessaires, en restant cohérent dans votre conformité :

Scénario	Recommandation	Exemple de calcul
60 périphériques partagés par 20 opérateurs	CAL par périphérique	60 CAL périphérique (les 20 opérateurs sont couverts via les postes qu’ils utilisent)
30 utilisateurs chacun avec 2 à 3 appareils	CAL par utilisateur	30 CAL utilisateur (chaque utilisateur couvre ses différents terminaux)
Utilisateurs externes temporaires (prestataires)	Au cas par cas	Attribuer des CAL utilisateur nominatifs si ces comptes accèdent régulièrement, ou fournir des postes gérés en interne (CAL périphérique)

Important : les Windows Server CAL ne sont pas « comptées » par le système en temps réel. La conformité repose sur votre inventaire (contrats/attestations, registres d’attribution, justificatifs d’achat). En revanche, les RDS CAL sont effectivement consommées et tracées par le serveur de licences RDS lorsqu’un rôle RDSH est déployé.

RDS CAL : quand en avez‑vous besoin ?

• Vous n’en avez pas besoin si vos utilisateurs/périphériques ne se connectent pas par Bureau à distance pour ouvrir une session interactive (GUI) sur le serveur.
• Vous en avez besoin si vous déployez Remote Desktop Session Host (RDSH) ou d’autres composants RDS pour offrir des sessions/ applications publiées.
• 2 sessions d’administration : Windows Server autorise deux sessions RDP « d’administration » (plus la console) sans RDS CAL, réservées à l’exploitation. Elles ne doivent pas servir de remplacement à RDS pour des usages utilisateurs.

Connexions simultanées : où sont les vraies limites ?

Ni les Windows Server CAL, ni l’absence de RDS CAL ne limitent techniquement les connexions FTP/SFTP. Les facteurs réellement limitants sont :

• Processeur : chiffrement (SFTP/FTPS), compression et IO scheduling.
• Mémoire : buffers réseau, cache de fichiers.
• Stockage : IOPS/latence disque (SSD/NVMe recommandé), file system journal.
• Réseau : bande passante (1/2,5/10 GbE), MTU, gigue, saturation des switches.
• Paramètres du service : limites de sessions et timeouts dans IIS FTP, valeurs MaxSessions / MaxStartups dans OpenSSH, plage de ports passifs (FTPS).

Paramètres utiles (IIS FTP)

• Connections : définir un plafond raisonnable (ex. 500, 1000) par site selon la mémoire disponible.
• Control/Data Channel Time‑out : évitez les timeouts trop longs, surtout en environnement LAN (ex. 120‑300 s).
• FTP User Isolation : activez l’isolation par répertoire utilisateur pour cloisonner les espaces.
• FTPS (SSL/TLS) : utilisez « Require SSL/TLS » et désactivez le FTP clair si possible.
• Passive ports : bornez, par exemple 50000‑51000, et ouvrez exactement cette plage dans le pare‑feu.

Paramètres utiles (OpenSSH Server / SFTP)

• MaxSessions : nombre de sessions multiplexées par connexion (valeur par défaut souvent suffisante, adaptez si MobaXterm/WinSCP ouvrent plusieurs canaux).
• MaxStartups : limite des connexions non authentifiées simultanées ; utile contre les rafales.
• LoginGraceTime : durée maximum d’authentification avant coupure.
• AllowGroups / DenyGroups : limitez aux groupes autorisés (p. ex. FTPUsers).
• PubkeyAuthentication yes : privilégiez l’authentification par clés plutôt que mots de passe.
• Isolation SFTP : utilisez une stratégie d’isolement (droits NTFS stricts et/ou ChrootDirectory selon vos besoins et compatibilités).

La période de grâce RDS de 120 jours : concrètement

Si vous installez le rôle Remote Desktop Session Host (RDSH), Windows Server accorde une période de grâce de ~120 jours durant laquelle les clients peuvent ouvrir des sessions RDS sans serveur de licences configuré. À l’expiration :

• Les nouvelles sessions RDS seront refusées si aucun serveur de licences RDS n’est renseigné/activé avec des RDS CAL valides.
• Votre service FTP/SFTP (IIS FTP ou OpenSSH) n’est pas impacté : il ne dépend pas de RDS.
• Vous conservez les 2 sessions RDP d’administration pour la maintenance du serveur (usage restreint).

Pas‑à‑pas : déployer SFTP natif avec OpenSSH Server

Installation

1. Ouvrez Paramètres > Fonctionnalités facultatives (ou utilisez PowerShell ci‑dessous).
2. Installez OpenSSH Server.

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Set-Service -Name sshd -StartupType Automatic
Start-Service sshd
# Activez la règle de pare-feu si nécessaire :
Get-NetFirewallRule -DisplayName '*OpenSSH*' | Enable-NetFirewallRule

Configuration minimale de sécurité

1. Créez un groupe d’accès : New-LocalGroup -Name "FTPUsers" -Description "Accès SFTP"
2. Ajoutez les comptes nécessaires (locaux ou AD) à FTPUsers.
3. Dans C:\ProgramData\ssh\sshd_config, durcissez et limitez : # Extrait indicatif – adaptez à votre politique PubkeyAuthentication yes PasswordAuthentication no Subsystem sftp internal-sftp AllowGroups FTPUsers # Optionnel : restreindre un groupe à SFTP uniquement Match Group FTPUsers ForceCommand internal-sftp # Selon vos contraintes d'isolement : # ChrootDirectory C:/SFTP/%u # AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys # End Match Note : si vous utilisez ChrootDirectory, appliquez des droits NTFS stricts : le dossier « chroot » ne doit pas être modifiable par l’utilisateur, qui écrira dans un sous‑dossier dédié (ex. data). Testez soigneusement permissions et parcours.
4. Créez l’arborescence, les ACL et l’audit : # Exemple : répertoire SFTP par utilisateur New-Item -ItemType Directory -Path "D:\SFTP\%USERNAME%\data" -Force | Out-Null # ACL : lecture sur la racine, écriture uniquement dans "data" # (Utilisez icacls ou via l'Explorateur selon votre pratique)
5. Redémarrez le service : Restart-Service sshd

Points de contrôle

• Connexion SFTP avec clés (WinSCP, FileZilla, scp).
• Écriture/lecture confinées au périmètre attendu.
• Journalisation : Applications et Services Logs > OpenSSH, et traces des accès NTFS.

Pas‑à‑pas : déployer FTP/FTPS avec IIS

Installation

1. Ajoutez les rôles Web Server (IIS) > FTP Server (Service FTPS et Extensibility si nécessaire).
2. Installez un certificat TLS (interne ou public) pour FTPS.

Création du site FTP

1. Dans le Gestionnaire IIS : Add FTP Site… → sélectionnez le répertoire racine et l’adresse IP.
2. Sécurité : Require SSL/TLS (FTP explicite recommandé). Choisissez le certificat.
3. Authentification : Activez Basic (ou plus fort si vous avez une fédération) ; Autorisation : Specified roles or user groups → FTPUsers.
4. Isolation : FTP User Isolation → User name directory (ou mode Active Directory si pertinent).
5. Limitez les ports passifs (ex. 50000‑51000) et ouvrez uniquement cette plage dans le pare‑feu.

Checklist de durcissement FTPS

• Désactivez le FTP clair (ou autorisez‑le uniquement pour des flux internes maîtrisés).
• Forcer TLS 1.2+ et des suites de chiffrement robustes.
• Établissez des quotas de volume côté stockage si nécessaire (FSRM).
• Activez les logs IIS (format W3C) et l’archivage périodique.
• Surveillez les erreurs 4xx/5xx pour repérer les clients mal configurés.

Sécurité, conformité et cloisonnement

Comptes et accès

• Utilisateurs nominaux, mots de passe forts ou clés SSH (recommandé).
• Groupe dédié (FTPUsers) avec droits NTFS minimaux.
• Stratégies de verrouillage, expiration, et MFA si un frontal applicatif le permet.
• Interdisez le RDP au groupe FTP via la stratégie « Refuser l’ouverture de session via les Services Bureau à distance ».

Journalisation & traçabilité

• Activez les journaux (IIS FTP ou OpenSSH) et conservez‑les selon votre politique de rétention.
• Activez l’audit des accès aux fichiers (Object Access) pour les dossiers de données sensibles.
• Automatisez la rotation des logs et leur centralisation (SIEM ou équivalent).

Performance et capacité : comment dimensionner pour 60 périphériques

En LAN, 60 sessions FTP/SFTP simultanées sont généralement modestes, mais tout dépend du profil d’E/S et de la taille des fichiers.

Profil de charge	Risque	Mesure	Remède
Beaucoup de petits fichiers	Overhead d’E/S, latence FS	PerfMon : Avg. Disk sec/Transfer, IOPS	NVMe, cache, batch ZIP côté client
Gros fichiers séquentiels	Bande passante réseau	PerfMon : Network Interface Bytes/sec	10 GbE, jumbo frames, éviter goulots
Beaucoup de connexions courtes	CPU (TLS/SSH)	PerfMon : % Proc, Context Switches/sec	Activer AES‑NI, moderniser CPU, clés ECDSA/Ed25519

Plan de test recommandé

1. Créer 60 comptes de test (ou scripts) qui ouvrent des sessions simultanées.
2. Simuler les transferts typiques (taille/volume, vitesse cible).
3. Mesurer : CPU, RAM, Latence disque, Débit réseau, Erreurs applicatives.
4. Identifier le premier goulot, corriger, puis re‑tester avec un pas de +20 % de charge.

Haute disponibilité et évolutivité

• Stockage partagé : si deux serveurs hébergent FTP/SFTP, centralisez les données (SMB/DFS, iSCSI) pour éviter la divergence.
• Répartition de charge : DNS Round‑Robin ou load balancer L4 pour répartir les sessions (attention aux connexions persistantes).
• Sauvegarde : sauvegardez à froid ou à chaud selon l’outil, testez la restauration fichier par fichier.
• Gouvernance : définissez des priorités (SLA), des fenêtres de maintenance et un PRA simple.

FAQ ciblée

Faut‑il des RDS CAL pour FTP/SFTP ?

Non. Les RDS CAL ne s’appliquent qu’aux sessions Bureau à distance. Un client FTP/FTPS/SFTP n’en ouvre pas : pas de RDS CAL requise.

Les CAL limitent‑elles le nombre de connexions ?

Non. Les CAL sont un droit d’usage, pas une bride technique. La capacité réelle est dictée par vos ressources matérielles et réglages IIS/OpenSSH.

Que se passe‑t‑il après les 120 jours de grâce RDS ?

Si un rôle RDSH est installé mais qu’aucun serveur de licences RDS n’est configuré, les nouvelles sessions RDS sont refusées après la période de grâce. Le service FTP/SFTP n’est pas affecté.

Et si je n’ai que des périphériques (scanners, NAS) sans comptes nominatifs ?

Le mode CAL par périphérique est adapté ; veillez à inventorier les endpoints physiques qui accèdent au service et tenez un registre à jour.

Essentials 2019 suffit‑il ?

Essentials 2019 inclut des CAL mais limite à 25 utilisateurs ou 50 périphériques. Pour ~60 périphériques, passez à Standard/Datacenter.

Modèle de registre de conformité (exemple)

Type CAL	Mode	Nombre	Justificatif	Attribution
Windows Server CAL	Par périphérique	60	Bon de commande #WS‑2025‑001	Inventaire endpoints (numéro de série, emplacement)
RDS CAL	—	0	N/A	N/A (pas de RDSH déployé)

Checklist finale (prête à l’emploi)

• Licences : Windows Server licencié (cœurs) + 60 CAL (mode choisi). Aucune RDS CAL si pas de RDSH.
• Sécurité : préférer SFTP (OpenSSH) ou FTPS avec TLS 1.2+. Désactiver FTP clair si possible.
• Isolement : FTP User Isolation (IIS) ou restrictions SFTP (groupe dédié, chroot/ACL strictes).
• Pare‑feu : SSH 22/TCP (SFTP), FTPS 21/TCP + plage passive bornée. Segmentation réseau conseillée.
• Journaux : activés, archivés, supervisés.
• Test de charge : 60 sessions concurrentes, validation des temps de transfert et de la stabilité.
• Exploitation : procédure de rotation des mots de passe/clés, renouvellement des certificats, sauvegarde et PRA.

Conclusion

Pour un service FTP/SFTP desservant ~60 périphériques en LAN, la formule gagnante est simple : Windows Server CAL obligatoires (par périphérique ou par utilisateur selon votre contexte), RDS CAL inutiles tant que personne n’ouvre de session Bureau à distance, et aucune limite technique liée aux CAL sur les connexions. La période de grâce RDS de 120 jours ne concerne que les déploiements RDS ; elle n’affecte pas votre FTP/SFTP. Côté technique, misez sur SFTP (OpenSSH) ou FTPS durci, une isolation stricte des espaces, un pare‑feu précis et une supervision proactive pour garantir performance et conformité.

---

Annexe : pas‑à‑pas express (récapitulatif)

Étape	FTP/FTPS (IIS)	SFTP (OpenSSH)
Installation	Ajouter rôle IIS > FTP Server	Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Sécurisation	Certificat TLS, FTPS requis, ports passifs bornés	Clés SSH, PubkeyAuthentication yes, groupes autorisés
Isolement	FTP User Isolation	Restrictions SFTP : ACL strictes et/ou ChrootDirectory selon besoin
Pare‑feu	21/TCP + plage passive	22/TCP
Journalisation	Logs IIS (W3C)	Journaux OpenSSH + audit NTFS
Licences	Windows Server CAL (User/Device)	Windows Server CAL (User/Device)
RDS CAL	Non (sauf usage RDSH)	Non (sauf usage RDSH)

---

Mentions et bonnes pratiques de conformité

• Conservez les preuves d’achat et un registre d’attribution des CAL.
• Vérifiez périodiquement l’adéquation mode CAL ↔ réalité du terrain (évolution du parc, multi‑appareils, externes).
• Si un rôle RDS est installé par erreur, désinstallez‑le pour éviter la confusion avec la période de grâce et éliminer un besoin de RDS CAL.
• Évitez les comptes partagés ; si vous devez en utiliser, documentez‑les et encadrez‑les strictement.

En bref : pour 60 périphériques accédant à un service FTP/SFTP sur Windows Server, procurez‑vous 60 Windows Server CAL (mode Device conseillé si le ratio personnes/postes est élevé), ne déployez pas RDS si vous n’en avez pas l’usage, et focalisez votre effort sur la sécurité, l’isolation et la supervision.