Syspirit 
Windows a ses GPO. Vous cochez une case dans une console, et 500 postes appliquent le réglage. L’utilisateur bidouille dans son coin ? À la prochaine synchro, tout revient en place.
Sous Linux, je me suis souvent posé la question de savoir comment arriver à une gestion de ce type, mais je n’ai jamais pris le temps de vraiment m’y intéresser.
En faisant ma veille, je suis tombé sur Bor, un outil qui promet exactement ça pour les postes Linux : un serveur central, des agents, des policies appliquées en continu. Le projet a fait 195 points sur Hacker News début août, et ça m’a intrigué.
Avant de parler de Bor, on va déjà faire un tour de ce qui existe et des capacités des différents outils.
Ansible, le réflexe qui ne suffit pas
Quand on parle de configurer un parc Linux, tout le monde pense à Ansible (ou à pyinfra, son cousin plus rapide et écrit en Python). Et c’est légitime : vous décrivez l’état voulu dans un playbook, vous lancez, et vos machines sont configurées. Pas d’agent à installer, ça passe par SSH, ça marche.
Sauf qu’un playbook applique un état à un instant T.
Vous poussez votre configuration Firefox sur 200 postes le lundi. Mardi, un utilisateur remet ce qu’il veut dans les préférences, et ça restera comme ça jusqu’à votre prochain run.
C’est exactement là que se situe la différence avec une GPO :
- Un playbook applique une configuration
- Une GPO maintient une configuration
Et une fois qu’on a ça en tête, on comprend mieux le paysage des autres outils.
Ce qui existe déjà
Puppet, Chef et Rudder
C’est la réponse historique au problème. Un agent tourne sur chaque machine, se réveille toutes les 30 minutes environ, compare l’état réel à l’état voulu et corrige ce qui a bougé. On appelle ça la correction de dérive, et c’est déjà beaucoup plus proche de l’esprit GPO.
Rudder mérite une mention au passage : c’est français, c’est open source, et l’interface web évite d’écrire du code pour chaque règle.
Le souci, c’est que ces outils sont pensés pour du serveur. Vous pouvez les détourner pour du poste de travail, mais vous allez écrire beaucoup de règles à la main pour des choses qu’une GPO Windows fait en trois clics.
Les GPO Samba
Là on tient le vrai équivalent : Samba sait appliquer de vraies GPO sur des machines Linux jointes à un domaine Active Directory. Winbind applique les policies machine depuis Samba 4.14 et les policies utilisateur depuis la 4.18. La commande samba-gpupdate s’occupe du rafraîchissement, toutes les 90 à 120 minutes.
Seulement, le périmètre couvert est étroit. On parle de policies de mot de passe, de tickets Kerberos, de smb.conf, de privilèges sudo, de scripts cron et de messages de connexion. Utile, mais on est loin de pouvoir verrouiller les réglages du bureau ou la configuration d’un navigateur.
ADSys, la réponse de Canonical
ADSys est un client GPO natif développé par Canonical. Vous joignez vos machines à votre AD existant, et vous pilotez vos postes Linux depuis la même console que vos postes Windows. Les policies machine s’appliquent au démarrage, les policies utilisateur à l’ouverture de session. Là on touche à du concret : réglages dconf, privilèges d’administration, scripts, proxy.
FreeIPA
FreeIPA, lui, ne gère que les identités, pas la configuration des postes. Utilisateurs, groupes, règles sudo, certificats. C’est l’équivalent de la partie annuaire d’un Active Directory, pas de la partie GPO.
Le récapitulatif
| Outil | Ce qu’il gère | Application |
|---|---|---|
| Ansible / pyinfra | Tout : fichiers, paquets, services | Ponctuelle, à chaque exécution |
| Puppet / Chef / Rudder | État système complet | Continue, cycle de 30 min environ |
| GPO Samba | Mots de passe, Kerberos, sudo, cron | Toutes les 90 à 120 min |
| ADSys | dconf, privilèges, scripts, proxy | Au démarrage et à la connexion |
| FreeIPA | Identités, sudo, accès par hôte | À l’authentification |
Ce qui manque dans ce tableau, vous l’avez peut-être remarqué : personne ne couvre vraiment la configuration du poste de travail, sur plusieurs distributions, avec un vrai verrouillage. C’est ce trou que Bor est venu combler.
Bor, le petit nouveau
Le principe
Bor, c’est trois morceaux : un serveur central, un agent écrit en Go installé sur chaque machine, et une interface web pour créer les policies.
Ici, pas d’intervalle de rafraîchissement : chaque agent maintient un flux gRPC permanent avec le serveur, chiffré en mTLS. Quand vous modifiez une policy dans l’interface, elle part sur les postes dans la seconde. Si un poste était éteint ou hors ligne, il se reconnecte et le serveur lui rejoue exactement ce qu’il a manqué.
L’enrôlement d’une machine se fait avec un jeton à usage unique valable 5 minutes, généré depuis l’interface. Chaque agent reçoit alors son propre certificat, émis par une autorité de certification interne créée automatiquement. Sur une machine déjà jointe à un domaine, l’enrôlement peut se faire tout seul via son ticket Kerberos.
Autre détail qui compte : ce sont les agents qui se connectent au serveur, et pas l’inverse. Pas besoin d’ouvrir de port entrant sur les postes.
Ce qui change vraiment : le verrouillage
C’est là que Bor se distingue d’un playbook Ansible, et c’est le point le plus intéressant.
Il ne se contente pas d’écrire le bon réglage, il s’appuie sur les mécanismes de verrouillage natifs de chaque environnement :
- Les clés dconf sont écrites avec leur fichier de verrous, ce qui fait que le réglage devient tout simplement non modifiable depuis l’interface de GNOME
- KDE Plasma est configuré via son mode Kiosk
- Pour le reste, l’agent surveille les répertoires concernés avec inotify et remet le fichier en place s’il est modifié
Résultat : l’utilisateur ne peut pas défaire le réglage, et s’il y arrive quand même, c’est corrigé avant qu’il ne s’en rende compte. On est bien dans la logique GPO.
Concrètement, ça donne ça dans l’interface : chaque réglage a une valeur, et une option Enforced (Immutable) qui décide si l’utilisateur peut y toucher ou non.
Côté couverture, la v0.8.0 sortie le 1er août gère Firefox, Thunderbird, Chrome, Chromium, Edge, GNOME dconf, KDE Plasma, polkit, firewalld, ainsi que les paquets et les dépôts. Les paquets d’installation existent pour Debian, Ubuntu, Fedora, RHEL, Alpine et Arch.
Chaque policy suit un cycle de vie en trois temps, brouillon, publiée puis archivée, avec un numéro de version qui s’incrémente à chaque modification.
Le parti pris le plus intéressant
Sur Hacker News, quelqu’un demande à Blagovest Petrov, le développeur de Bor, s’il est possible d’exécuter des scripts personnalisés. La réponse est non, et c’est volontaire :
Once a management agent runs arbitrary scripts as root, it stops being a policy system and becomes remote-code-execution-as-a-service.
C’est un choix assumé, et plutôt rare. Ça ferme des cas d’usage, mais ça réduit aussi énormément la surface d’attaque. À comparer avec ADSys, qui vend justement cette fonctionnalité avec son abonnement.
Dernier point à avoir en tête : Bor ne gère aucun utilisateur, uniquement des machines. Ce n’est pas un contrôleur de domaine et ça ne remplace pas votre annuaire. Il se branche sur un Active Directory, un Samba ou un FreeIPA existant, en LDAP et Kerberos.
Ce qui est fait, et ce qui ne l’est pas
Bon point : la roadmap est publiée sur la page d’accueil, avec ce qui est terminé, en cours et prévu. Ça évite de découvrir les manques une fois le déploiement lancé.
Côté terminé, il y a du sérieux : journal d’audit, RBAC, intégration LDAP et AD, connexion par passkey, prise en charge des HSM pour les clés de l’autorité de certification, sonde Prometheus.
Mais trois absences ont des conséquences très concrètes :
- Les agents ne se mettent pas à jour tout seuls. Pour un outil de gestion de parc, c’est cocasse : à chaque version, il faut repasser sur toutes les machines par un autre moyen.
- Pas de bibliothèque de modèles. Là où Windows fournit ses ADMX prêts à l’emploi, ici chaque policy se construit à la main.
- Pas de multi-tenant. Si vous gérez les parcs de plusieurs clients, il faudra attendre.
Les réserves
Maintenant, il faut regarder les chiffres en face.
Le développeur travaille dessus depuis plus d’un an, mais n’a publié le projet sur GitHub que le 19 février 2026. On en est à la version 0.8.0.
Et il est tout seul pour le faire vivre. C’est assez impressionnant pour un side-project de cette ampleur, mais le fait que tout repose sur une seule personne reste risqué pour l’utiliser en production.
Et il ne s’en cache pas. Dans son post d’annonce sur LinkedIn, il écrit :
This is still a side project, but I’m serious about building an open source community around it.
Et sous ce post LinkedIn justement, un commentaire tombe :
Ce commentaire est signé David Mulder, ingénieur chez SUSE. Et quelques réponses plus bas, il précise :
yeah, I wrote the Samba client Group Policy ;-) and now I’m working on Intune policy compliance for Linux.
L’objection vient donc de la personne qui a écrit le client GPO de Samba. Difficile de trouver plus légitime sur le sujet.
La réponse du développeur de Bor n’esquive pas : oui, Samba implémente une partie des GPO. Mais selon lui le problème est ailleurs, et il tient en une phrase : Linux n’a pas de couche d’abstraction standard pour les policies. Même avec le support GPO, l’application des réglages du bureau, de polkit ou de NetworkManager n’est ni unifiée ni cohérente.
L’argument se tient. Sauf que David Mulder lui a répondu par un XKCD 927 : il existe 14 standards concurrents, quelqu’un en crée un universel pour tout couvrir, et il en existe désormais 15.
Les deux ont raison en même temps. Bor comble un vrai manque, et Bor est un standard de plus.
Conclusion
Il existe donc plusieurs outils pour gérer son parc et se rapprocher plus ou moins des GPO. Tout dépend de vos besoins, et il faut pas mal creuser et comparer avant de trancher.
Et c’est là tout le problème côté Linux : le sujet est bien moins mature que sur Windows. Beaucoup d’options, et aucune qui coche toutes les cases.
Pour moi, Bor est celui qui se rapproche le plus des GPO Windows, et celui qui a le plus de potentiel. Reste à voir si le dev tient la distance et si une communauté se construit autour.
Projet à suivre de près !
Liens utiles :