Pour la majorité des PME sous Linux, oui. Samba AD couvre le socle technique d’un contrôleur de domaine : authentification Kerberos, annuaire LDAP, DNS, stratégies de groupe via SYSVOL, réplication entre contrôleurs et partage de fichiers SMB. La version stable 4.24.3, publiée le 26 mai 2026, embarque un niveau fonctionnel équivalent à Windows Server 2016.
Ce plafond à 2016 suffit à la majorité des infrastructures PME sans dépendance aux services Microsoft récents. Trois variables font la différence : l’organisation utilise-t-elle Exchange, Azure AD ou ADFS ? Ses applications métier exigent-elles un niveau fonctionnel 2019 ou 2022 ? Le parc est-il purement Linux ou mixte Windows/Linux ? Si la réponse aux deux premières questions est non, Samba AD mérite une évaluation sérieuse.
Ce que Samba AD fournit concrètement
Depuis sa version 4.0 de décembre 2012, Samba peut tenir le rôle de contrôleur de domaine Active Directory. Selon MeetCyber, le contrôleur de domaine Samba AD fournit :
- LDAP : annuaire pour les comptes utilisateurs, groupes et machines
- Kerberos : authentification centralisée pour les machines et services joints au domaine
- DNS : résolution des enregistrements SRV nécessaires à la découverte des services AD
- SYSVOL : réplication des Group Policy Objects (GPO) vers les machines du domaine
- SMB : partage de fichiers et accès aux ressources réseau
- Réplication multi-DC : synchronisation entre plusieurs contrôleurs de domaine
Ce périmètre couvre les opérations quotidiennes d’une infrastructure : ouverture de session centralisée, gestion des droits d’accès aux partages, application de politiques sur les postes, jonction de machines Linux et Windows au domaine. Pour un parc dont les besoins s’arrêtent là, le socle est complet.
Si le domaine dépasse cent mille objets (utilisateurs, groupes, ordinateurs combinés), la base LMDB, disponible depuis Samba 4.10, est nécessaire pour tenir la charge. En dessous de ce seuil, la configuration par défaut suffit.
Niveau fonctionnel : ce que le plafond à 2016 change réellement
Le niveau fonctionnel d’un domaine AD détermine les fonctionnalités disponibles pour l’ensemble des contrôleurs. En 2026, selon hives.cloud, Samba AD atteint l’équivalent de Windows Server 2016. Microsoft propose aujourd’hui des niveaux fonctionnels jusqu’à 2022.
Pour un parc standard sans applications métier spécifiques, l’écart entre 2016 et 2022 a peu d’incidences opérationnelles. Les mécanismes fondamentaux – Kerberos, LDAP, GPO, relations d’approbation entre domaines – sont disponibles dès le niveau 2016. L’écart devient concret dans deux situations précises : des applications qui vérifient explicitement le niveau fonctionnel du domaine avant d’accepter de s’y connecter, et les fonctionnalités AD introduites après 2016 dont certains éditeurs de logiciels métier ou des solutions de gestion d’identité modernes peuvent dépendre.
La vérification à faire avant tout déploiement : consulter la documentation de chaque application métier jointe au domaine pour identifier si elle documente un niveau fonctionnel minimum. Si une application exige 2019 ou 2022, Samba AD ne peut pas satisfaire cette exigence dans l’état actuel.
Ce que Samba AD ne couvre pas
Plusieurs fonctionnalités de Windows Server AD n’ont pas d’équivalent dans Samba, ou leur couverture reste partielle. Ce sont les points de rupture à identifier avant de démarrer un projet.
- ADFS (Active Directory Federation Services) : le service de fédération d’identité de Microsoft, utilisé pour les SSO inter-organisations et les intégrations avec des applications SaaS, est absent de Samba AD.
- Azure AD Connect : la synchronisation entre un AD on-premise et Azure Active Directory (Entra ID) repose sur un outil Microsoft qui ne s’intègre pas avec Samba AD.
- Intégration Exchange : Exchange Server étend le schéma AD avec ses propres attributs. Samba AD ne supporte pas ces extensions de schéma propriétaires ; une migration depuis un AD Microsoft avec Exchange joint sera bloquée ou partielle sur ce point.
- Certificate Services AD à grande échelle (AD CS) : Samba n’offre pas d’équivalent fonctionnel à l’autorité de certification intégrée de Windows Server pour les déploiements complexes. Si l’infrastructure repose sur AD CS pour distribuer des certificats machine à grande échelle, Windows Server reste obligatoire.
- Niveaux fonctionnels 2019 et 2022 : voir la section précédente.
Le cas d’un parc mixte Windows/Linux mérite une attention particulière. Les machines Windows peuvent rejoindre un domaine Samba AD via Winbind, et les GPO sont distribuées via SYSVOL. En pratique, le niveau de compatibilité des GPO dépend de la complexité des stratégies appliquées. Les politiques de base fonctionnent ; les modèles ADMX les plus récents ou les extensions de stratégies spécifiques à Windows 11 / Server 2022 peuvent se comporter différemment. La prudence consiste à tester les GPO critiques dans un environnement hors production avant tout déploiement.
Enfin, une migration depuis un AD Microsoft avec schéma étendu (Exchange, SCCM, par exemple) sera partielle : les extensions de schéma propriétaires ne se transfèrent pas vers Samba AD.
Arbre de décision rapide
- Votre organisation utilise Exchange, Azure AD Connect ou ADFS ?
– Oui → Samba AD ne peut pas remplacer Windows Server AD dans ce contexte.
– Non → continuer. - Vos applications métier exigent un niveau fonctionnel Windows Server 2019 ou 2022 ?
– Oui → Samba AD est insuffisant ; Windows Server reste nécessaire.
– Non ou inconnu → vérifier la documentation de chaque application, puis continuer si le résultat est négatif. - Votre infrastructure nécessite AD CS pour distribuer des certificats machine à grande échelle ?
– Oui → Samba AD ne couvre pas ce besoin.
– Non → continuer. - Votre parc dépasse cent mille objets AD ?
– Oui → prévoir la configuration LMDB (disponible depuis Samba 4.10).
– Non → la configuration par défaut convient.
Si vous atteignez la fin de cet arbre sans blocage, Samba AD est une alternative fonctionnelle à évaluer sérieusement.
L’économie réelle sur les licences
Avec Samba AD, il n’est pas nécessaire d’acquérir des CAL (Client Access Licenses) pour se connecter au contrôleur de domaine ou à un serveur de fichiers Samba. C’est l’économie directe et vérifiable : dans un modèle Windows Server, chaque machine ou utilisateur accédant au serveur génère une CAL.
Ce que Samba ne supprime pas : les CAL Microsoft restent dues pour tout autre service Windows encore présent dans l’infrastructure (un serveur d’impression Windows, un serveur RDS, etc.). L’économie réelle dépend donc du périmètre de migration. Plus l’infrastructure est homogène côté Linux, plus l’économie sur les licences est substantielle. Un parc mixte où subsistent plusieurs rôles Windows Server verra l’effet réduit en proportion.
Le coût de possession à estimer inclut aussi le temps d’administration : Samba AD nécessite des compétences Linux et une familiarité avec les outils en ligne de commande pour l’administration du domaine, les sauvegardes et les mises à jour. Ces compétences ont un coût qui varie selon les ressources internes disponibles.
Trois variables pour trancher
La décision se résume à trois questions concrètes. L’organisation a-t-elle des dépendances actives envers des services Microsoft cloud ou on-premise (Exchange, Azure AD, ADFS, AD CS) ? Si oui, Samba AD ne peut pas les absorber. Les applications métier documentent-elles un niveau fonctionnel AD minimum supérieur à 2016 ? Si oui, le plafond technique de Samba AD devient un obstacle réel. Le parc est-il majoritairement Linux, avec un besoin principal d’authentification centralisée, de gestion des accès aux partages et d’application de politiques de base ? Si oui, Samba AD couvre ce périmètre depuis plus d’une décennie.