Gérer un domaine Windows sans payer une licence Microsoft Server – c’est exactement ce que fait Samba depuis 2012. Ce qui était une utopie pour les administrateurs systèmes Linux est aujourd’hui une réalité deployée en production dans des milliers d’organisations. Voici ce que vous devez savoir avant de vous lancer.
Qu’est-ce que Samba Active Directory?
Samba Active Directory est une implémentation open source du protocole Active Directory de Microsoft. Concrètement, votre serveur Linux se comporte comme un contrôleur de domaine Windows – il gère l’authentification des utilisateurs, les stratégies de groupe, les comptes machines, et l’ensemble de l’annuaire LDAP de votre réseau.
La différence fondamentale avec un AD Windows classique ne se voit pas côté client. Un poste Windows 10 ou 11 rejoint un domaine Samba exactement comme il rejoindrait un domaine Microsoft. Les tickets Kerberos sont émis, les GPO s’appliquent, les partages réseau se montent – l’interopérabilité est réelle et documentée.
Là où la différence est tangible, c’est du côté administration. Samba n’embarque pas une interface graphique native équivalente à la console Active Directory Users and Computers. Vous pilotez principalement via la commande samba-tool en ligne de commande, ou depuis un poste Windows avec les outils RSAT connectés au domaine Samba. Ce choix architectural est assumé : Samba cible des administrateurs à l’aise avec un terminal.
Samba est distribué sous licence GNU General Public License et fait partie du Software Freedom Conservancy. Zéro coût de licence, code auditable, communauté active – c’est le profil exact d’un logiciel que beaucoup d’organisations cherchent pour leur infrastructure critique.
Samba 4 : l’évolution qui a tout changé
L’histoire de Samba commence en 1992, quand Andrew Tridgell développe un outil pour faire communiquer son serveur Unix avec des postes DOS. Pendant vingt ans, Samba s’impose comme la référence pour le partage de fichiers SMB sur Linux. Mais ce n’est qu’avec la version 4.0, sortie en 2012, que le projet prend une autre dimension : la capacité à fonctionner comme un vrai contrôleur de domaine Active Directory.
Ce bond a demandé une réécriture quasi complète de certains composants. L’équipe a dû implémenter from scratch les protocoles Kerberos, LDAP et DNS dans leur variante AD, en s’appuyant sur le reverse engineering du protocole Microsoft et les spécifications ouvertes publiées progressivement par la firme de Redmond.
Depuis, le projet avance à un rythme soutenu. Samba 4.20.0 est sorti le 27 mars 2024, suivi de la 4.21.0 le 2 septembre 2024. En mai 2026, les versions 4.24.3, 4.23.8 et 4.22.10 sont disponibles comme sorties de sécurité, la branche 4.24 étant la plus récente de la suite. À partir de la version 4.19, les niveaux fonctionnels AD 2012, 2012 R2 et 2016 sont disponibles en implémentation initiale, avec notamment l’émission de « Claims » AD dans le PAC – une fonctionnalité attendue depuis longtemps par les grandes organisations.
Samba Active Directory vs Active Directory Windows : quelles différences?
La question revient souvent quand on compare active directory vs samba : que perd-on réellement en passant sur une infrastructure open source ? La réponse est nuancée selon votre cas d’usage.
Sur le plan protocolaire, Samba couvre l’essentiel : LDAP, Kerberos, DNS, SMB, réplication multi-DC et Group Policy. En 2026, le niveau fonctionnel atteint équivaut à Windows Server 2016, ce qui suffit pour la grande majorité des environnements d’entreprise, y compris ceux soumis aux exigences de conformité NIST 800-171.
| Critère | Samba AD | Active Directory Windows |
|---|---|---|
| Coût de licence | Gratuit (GPL) | Windows Server + CAL |
| Niveau fonctionnel max. | 2016 (depuis 4.19) | 2022 |
| Administration graphique native | Via RSAT Windows uniquement | Console MMC intégrée |
| Support LMDB (gros annuaires) | Oui, au-delà de 100 000 objets | Oui (base JET native) |
| Intégration Azure AD / Entra ID | Limitée | Native |
| Clients supportés | Windows 10/11, Linux, macOS | Windows 10/11, Linux, macOS |
Les fonctionnalités avancées liées à l’écosystème Microsoft cloud – Azure AD Connect, Entra ID, Rights Management Services – restent les points faibles de Samba. Si votre organisation s’appuie fortement sur Microsoft 365 avec synchronisation d’annuaire, Samba AD n’est pas le bon choix à ce stade. En revanche, pour un domaine on-premise autonome, la couverture fonctionnelle est solide.
Comment installer Samba Active Directory sur Debian/Linux?
Pour un déploiement samba ad debian, commencez par une installation propre du paquet et l’arrêt des services qui pourraient entrer en conflit avec le DNS ou Kerberos.
apt install samba krb5-config winbind smbclient
systemctl stop smbd nmbd winbind
systemctl disable smbd nmbd winbindEnsuite, provisionnez le domaine avec samba-tool domain provision. Cette commande génère l’ensemble de la configuration initiale – krb5.conf, smb.conf, base LDAP – en une seule passe :
samba-tool domain provision \
--use-rfc2307 \
--realm=MONDOMAINE.LAN \
--domain=MONDOMAINE \
--adminpass='MotDePasseF0rt!'Une fois le provisionnement terminé, démarrez uniquement le service samba-ad-dc et vérifiez que Kerberos fonctionne correctement :
systemctl start samba-ad-dc
kinit administrator@MONDOMAINE.LAN
samba-tool domain level showPour créer vos premiers objets, samba-tool propose une syntaxe directe : samba-tool user create nomutilisateur, samba-tool group addmembers "Domain Admins" nomutilisateur, ou encore samba-tool dns zonelist 127.0.0.1 pour vérifier vos zones DNS. La documentation officielle du projet Samba couvre chaque sous-commande avec des exemples détaillés – c’est la référence à garder ouverte lors de votre premier déploiement de active directory samba linux.
Déployer un contrôleur de domaine Samba AD avec Docker
Le déploiement active directory samba docker gagne en popularité, surtout pour les environnements de test et les petites infrastructures qui veulent éviter de dédier un serveur physique au rôle de DC. Le principe : un conteneur expose les ports 53 (DNS), 88 (Kerberos), 389 (LDAP), 445 (SMB) et 636 (LDAPS) vers le réseau hôte.
L’image la plus utilisée dans la communauté est diemuzi/samba-domain, maintenue sur Docker Hub. Le lancement minimal ressemble à ceci :
docker run -d --name samba-dc \
--network host \
-e DOMAIN=MONDOMAINE.LAN \
-e DOMAINPASS=MotDePasseF0rt! \
-e HOSTIP=192.168.1.10 \
-v /data/samba:/var/lib/samba \
diemuzi/samba-domainDeux points d’attention spécifiques à la conteneurisation. Le mode réseau –network host est quasiment obligatoire : Kerberos et la découverte AD reposent sur des mécanismes DNS et de broadcast qui fonctionnent mal derrière un NAT Docker classique. Le deuxième point concerne la persistance : montez impérativement le répertoire /var/lib/samba sur un volume externe, sinon vous perdez l’intégralité de votre annuaire au redémarrage du conteneur.
En production, un conteneur DC est acceptable pour des organisations de taille modeste avec une tolérance aux interruptions raisonnables. Pour un environnement critique avec réplication multi-DC, privilégiez des VM dédiées – la gestion du réseau et de la réplication SYSVOL y est beaucoup moins acrobatique.
Samba AD assure une authentification robuste grâce à Kerberos et SSSD
L’authentification samba active directory repose sur Kerberos, exactement comme un AD Microsoft. Lorsqu’un utilisateur se connecte, son poste client contacte le KDC (Key Distribution Center) – rôle assuré par Samba sur le DC – pour obtenir un TGT (Ticket Granting Ticket). Ce ticket sert ensuite à demander des tickets de service pour chaque ressource du domaine. Le mot de passe ne transite jamais en clair sur le réseau.
Depuis Samba 4.20, la version minimale requise est MIT Kerberos 1.21 lorsque vous compilez Samba avec MIT Krb5 pour le rôle AD DC. Vérifiez votre version avec krb5-config --version avant toute compilation depuis les sources – un décalage de version provoque des erreurs d’authentification difficiles à diagnostiquer.
Pour les clients Linux membres du domaine, SSSD (System Security Services Daemon) complète le tableau. Son rôle est double : il résout les identités AD localement et met en cache les credentials pour permettre la connexion même hors ligne. Un commercial dont le laptop Linux tente de s’authentifier sans accès au DC retrouve sa session grâce au cache SSSD – concrètement, c’est la différence entre un outil professionnel et un gadget de lab.
Comment gérer les GPO avec Samba Active Directory?
Les samba active directory gpo fonctionnent sur le même mécanisme que sous Windows : les politiques de groupe sont stockées dans le partage SYSVOL, répliqué entre tous les contrôleurs de domaine du domaine. Chaque client, Windows ou Linux avec SSSD, récupère et applique les GPO assignées à son OU lors de l’authentification ou du rafraîchissement périodique.
La gestion en ligne de commande passe par samba-tool gpo. Les opérations courantes :
samba-tool gpo create "NomDeLaPolitique"– crée une nouvelle GPO videsamba-tool gpo link "NomDeLaPolitique" "OU=Serveurs,DC=mondomaine,DC=lan"– lie la GPO à une OUsamba-tool gpo list --machine-name=MONPC– liste les GPO applicables à un postesamba-tool gpo show {GUID-DE-LA-GPO}– affiche le détail d’une politique
Pour éditer le contenu des GPO – restrictions de connexion, paramètres de mots de passe, scripts de démarrage, droits utilisateurs – l’approche la plus pratique reste la console GPMC depuis un poste Windows avec RSAT, connecté au domaine Samba. La commande samba-ad gpo en ligne de commande permet de créer et lier des GPO, mais l’édition fine des templates ADMX est beaucoup plus confortable avec l’interface graphique Windows.
Samba Active Directory dans un environnement mixte Linux/Windows : ce qu’il faut savoir
Intégrer des postes Windows 10 et 11 dans un domaine Samba se fait exactement comme avec un AD Microsoft : panneau de configuration, « Joindre un domaine », nom du domaine, credentials administrateur. Côté Windows, l’expérience est transparente. Les profils itinérants, les lecteurs réseau mappés via GPO, l’authentification SSO – tout fonctionne.
Pour les clients Linux, l’intégration passe par le couple Kerberos + SSSD + winbind. Une fois configuré, un utilisateur du domaine se connecte à son poste Ubuntu ou Debian avec ses credentials AD, sans compte local distinct. La commande id nomutilisateur@mondomaine.lan retourne les groupes AD de l’utilisateur directement depuis l’annuaire.
Sur les gros annuaires, Samba supporte LMDB pour les domaines dépassant 100 000 objets – utilisateurs, groupes, machines confondus. C’est le backend recommandé pour les organisations avec un parc important ; le backend TDB historique montre ses limites au-delà de quelques dizaines de milliers d’entrées.
Le niveau fonctionnel Windows Server 2016 atteint par Samba en 2026 couvre les exigences de conformité NIST 800-171, ce qui ouvre la porte aux marchés publics américains et aux entreprises soumises à des audits de sécurité stricts. Ce n’était pas acquis il y a encore deux ans.
Limites et points de vigilance avant d’adopter Samba comme contrôleur de domaine
Samba AD n’est pas adapté à toutes les situations. Avant de migrer votre infrastructure, voici les points concrets qui ont fait renoncer – ou reculer – des équipes expérimentées.
- Gestion des GPO complexes : créer des politiques avancées (AppLocker, redirection de dossiers, paramètres de registre ciblés) reste laborieux sans RSAT Windows. Vous aurez besoin d’un poste Windows dans votre réseau pour administrer confortablement.
- Réplication multi-DC : configurer deux DCs Samba en réplication est documenté, mais la synchronisation SYSVOL via rsync ou DFSR reste moins mature que sous Windows. Les incidents de réplication partielle sont plus fréquents et plus difficiles à diagnostiquer.
- Fonctionnalités AD avancées : AD Certificate Services, AD Federation Services, Azure AD Connect – aucun équivalent natif. Si votre architecture repose sur ces briques, Samba n’est pas un substitut.
- Support commercial : Red Hat, SUSE et quelques intégrateurs offrent un support payant, mais les délais et la profondeur d’expertise varient énormément selon les cas.
- Documentation de migration : migrer un AD Windows existant vers Samba n’est pas une opération triviale. Les outils existent, mais le chemin est semé d’ajustements manuels.
Samba AD convient parfaitement aux organisations qui partent de zéro sur une infrastructure Linux, aux environnements de développement et de test, et aux PME qui veulent un domaine fonctionnel sans budget licence. Les grandes entreprises avec un SI Windows historique et des dépendances Azure auront plus de mal à justifier la migration.
Un administrateur qui maîtrise son terminal, qui n’a pas peur de lire une page de man, et qui construit une infrastructure sans dette technique Microsoft – pour lui, Samba AD n’est pas un compromis. C’est exactement l’outil qu’il cherchait.