Syspirit 
Windows has its GPOs. You tick a box in a console, and 500 machines apply the setting. A user starts fiddling on their side? At the next sync, everything is back in place.
On Linux, I have often wondered how to get to that kind of management, but I never really took the time to look into it.
While going through my usual tech watch, I came across Bor, a tool that promises exactly that for Linux desktops: a central server, agents, and policies enforced continuously. The project hit 195 points on Hacker News in early August, and that got my attention.
Before getting to Bor, let’s take a tour of what already exists and what each tool can actually do.
Ansible, the reflex that is not enough
When it comes to configuring a Linux fleet, everyone thinks of Ansible (or pyinfra, its faster cousin written in Python). And fair enough: you describe the desired state in a playbook, you run it, and your machines are configured. No agent to install, it goes over SSH, it works.
Except that a playbook applies a state at a point in time.
You push your Firefox configuration to 200 machines on Monday. On Tuesday, a user sets the preferences back to whatever they want, and it stays that way until your next run.
That is exactly where the difference with a GPO lies:
- A playbook applies a configuration
- A GPO maintains a configuration
Once you have that in mind, the rest of the landscape makes a lot more sense.
What already exists
Puppet, Chef and Rudder
This is the historical answer to the problem. An agent runs on each machine, wakes up roughly every 30 minutes, compares the actual state to the desired one and fixes whatever has drifted. It is called drift correction, and it is already much closer to the spirit of a GPO.
Rudder deserves a mention here: it is French, it is open source, and its web interface saves you from writing code for every single rule.
The catch is that these tools are built for servers. You can bend them towards desktops, but you will be writing a lot of rules by hand for things a Windows GPO does in three clicks.
Samba GPOs
This is where you find the real equivalent: Samba can apply actual GPOs to Linux machines joined to an Active Directory domain. Winbind has enforced machine policies since Samba 4.14 and user policies since 4.18. The samba-gpupdate command handles the refresh, every 90 to 120 minutes.
The scope, however, is narrow. We are talking password policies, Kerberos tickets, smb.conf, sudo privileges, cron scripts and login messages. Useful, but a long way from locking down desktop settings or a browser configuration.
ADSys, Canonical’s answer
ADSys is a native GPO client developed by Canonical. You join your machines to your existing AD, and you drive your Linux desktops from the same console as your Windows ones. Machine policies apply at boot, user policies at login. This is where things get concrete: dconf settings, admin privileges, scripts, proxy.
FreeIPA
FreeIPA, on the other hand, only handles identities, not desktop configuration. Users, groups, sudo rules, certificates. It is the directory half of an Active Directory, not the Group Policy half.
The recap
| Tool | What it handles | Enforcement |
|---|---|---|
| Ansible / pyinfra | Everything: files, packages, services | One-off, on each run |
| Puppet / Chef / Rudder | Full system state | Continuous, roughly every 30 min |
| Samba GPO | Passwords, Kerberos, sudo, cron | Every 90 to 120 min |
| ADSys | dconf, privileges, scripts, proxy | At boot and at login |
| FreeIPA | Identities, sudo, host-based access | At authentication |
What is missing from this table, as you may have noticed: nobody really covers desktop configuration, across several distributions, with proper lockdown. That is the gap Bor set out to fill.
Bor, the new kid
How it works
Bor comes in three pieces: a central server, an agent written in Go installed on each machine, and a web interface to author policies.
There is no refresh interval here: each agent holds a persistent gRPC stream to the server, encrypted with mTLS. When you change a policy in the interface, it reaches the machines within a second. If a machine was powered off or offline, it reconnects and the server replays exactly what it missed.
Enrolling a machine is done with a one-time token valid for 5 minutes, generated from the interface. Each agent then receives its own certificate, issued by an internal certificate authority created automatically. On a machine already joined to a domain, enrollment can happen on its own through its Kerberos ticket.
Another detail that matters: the agents connect to the server, not the other way around. No inbound port to open on the machines.
What really changes: lockdown
This is where Bor differs from an Ansible playbook, and it is the most interesting part.
It does not just write the right setting, it leans on the native lockdown mechanisms of each environment:
- dconf keys are written along with their locks file, which simply makes the setting impossible to change from the GNOME interface
- KDE Plasma is configured through its Kiosk mode
- For everything else, the agent watches the relevant directories with inotify and puts the file back if it is modified
The result: the user cannot undo the setting, and if they somehow manage to, it is corrected before they even notice. That is GPO behaviour.
In practice, here is what it looks like in the interface: every setting has a value, and an Enforced (Immutable) option that decides whether the user can touch it or not.
On coverage, v0.8.0 released on 1 August handles Firefox, Thunderbird, Chrome, Chromium, Edge, GNOME dconf, KDE Plasma, polkit, firewalld, plus packages and repositories. Installation packages exist for Debian, Ubuntu, Fedora, RHEL, Alpine and Arch.
Every policy follows a three-stage lifecycle, draft, released then archived, with a version number that increments on each change.
The most interesting design choice
On Hacker News, someone asks Blagovest Petrov, the developer behind Bor, whether custom scripts can be executed. The answer is no, and it is deliberate:
Once a management agent runs arbitrary scripts as root, it stops being a policy system and becomes remote-code-execution-as-a-service.
It is a conscious choice, and a fairly rare one. It closes off some use cases, but it also massively reduces the attack surface. Worth comparing with ADSys, which sells that exact feature with its subscription.
One last thing to keep in mind: Bor manages no users at all, only machines. It is not a domain controller and it does not replace your directory. It plugs into an existing Active Directory, Samba or FreeIPA, over LDAP and Kerberos.
What is done, and what is not
Good sign: the roadmap is published right on the home page, with what is done, in progress and planned. It saves you from discovering the gaps once the rollout has started.
On the done side, there is real substance: audit log, RBAC, LDAP and AD integration, passkey login, HSM support for the certificate authority keys, Prometheus metrics.
But three absences have very concrete consequences:
- Agents do not update themselves. For a fleet management tool, that is ironic: on every release, you have to go back over all the machines by some other means.
- No template library. Where Windows ships its ready-made ADMX files, here every policy is built by hand.
- No multi-tenancy. If you manage fleets for several clients, you will have to wait.
The reservations
Now, time to look at the numbers.
The developer has been working on it for over a year, but only published the project on GitHub on 19 February 2026. It is currently at version 0.8.0.
And he is entirely on his own to keep it alive. That is fairly impressive for a side project, but everything resting on one person is still a risk.
And he does not hide it. In his announcement post on LinkedIn, he writes:
This is still a side project, but I’m serious about building an open source community around it.
And right under that LinkedIn post, a comment lands:
That comment is signed David Mulder, engineer at SUSE. And a few replies down, he adds:
yeah, I wrote the Samba client Group Policy ;-) and now I’m working on Intune policy compliance for Linux.
So the objection comes from the person who wrote the Samba GPO client. It is hard to find anyone more legitimate on the subject.
Bor’s developer does not dodge it: yes, Samba implements part of Group Policy. But in his view the problem lies elsewhere, and it fits in one sentence: Linux has no standard policy abstraction layer. Even with GPO support, enforcement across desktop settings, polkit or NetworkManager is neither unified nor consistent.
The argument holds. Except that David Mulder replied with an XKCD 927: there are 14 competing standards, someone builds a universal one to cover them all, and now there are 15.
Both are right at the same time. Bor fills a real gap, and Bor is one more standard.
Conclusion
So there are several tools out there to manage a fleet and get more or less close to GPOs. It all depends on your needs, and it takes a fair amount of digging and comparing before you decide.
And that is the whole problem on the Linux side: the topic is far less mature than on Windows. Plenty of options, and none that ticks every box.
For me, Bor is the one that comes closest to Windows GPOs, and the one with the most potential. It remains to be seen whether the developer goes the distance and whether a community builds around it.
Definitely a project to keep an eye on!
Useful links: