Right, I see where you are coming from, I still want to make the stronger argument that we should not strive to re-work Linux in Windows' image. Most such initiatives, like gconf/dconf, have severely degraded the desktop experience.

I have some experience at places where Linux are run on desktops at scale, but they all have in common that these are engineers for whom Linux is the better experience to begin with. It's not like that for administrative staff and management. And as much as I'd like to tell people to use Prezi instead of Powerpoint, and Markdown instead of Word, sometimes Libre Office is the best answer.

We have to be practical. Still, I feel that too often it is engineering that has to use tools intended for administrative people. Once in a while, they other way around may not be that bad.

For a modern workplace, where smartphone and cloud based applications rule, the traditional Windows tools like AD and GP can only do so much. You also need MDM tools, and something like SAML. If you are looking for an out-of-the-box tool that can manage both Linux and Windows clients, Red Hat has FreeIPA. It's not AD, but it goes beyond that capability.

I don't know. What's the Windows equivalent of dpkg (from 1993) and ssh (from 1995)?

Still nothing, three decades later. Not because Microsoft engineers couldn't do it, of course, but becasue they didn't want to. It doesn't fit the Windows model. They did recently adopt SSH, but that was because they want to use Windows in cloud-like environments, where expectations are set by Linux-style tools.

By the time Windows got to the point where it even could be centrally managed in any reasonable fashion, Linux environments was routinely run an order of magnitude larger still.

There is a reason why the whole cloud runs Linux. Anything else is a rounding error. That's because Linux is inherently so much less work to manage at scale.

If something like Group Policies would somehow be accepted by the Linux community, that could only be a step backwards. A well run Ansible or Puppet or similar environment works on a completely different scale.

Lixnux version of AD is FreeIPA, with group policies translating to dconf - at least that was the way "enterprise" linux vendors (like RH or Canonical) were moving towards.

Now, how well is dconf integrated with all the software you want to run is another thing (it was done by GNOME, and ignored by KDE), and whether this is still the way they are all moving is yet another question but the infrastructure was being built.

The concept does not really exist it is a Windows thing. You could call Puppet or other config managements group policies, but Linux is not a monolith so it is more organic.

AD is LDAP+Kerberos, which has existed in the Unix/Linux world long before Microsoft bastardized it. So pick any of half a dozen LDAP server implementations and any of 3 or 4 Kerberos implementations and use those. If you want point-and-click/drool interfaces, use FreeIPA. If you really want it to look like AD, use Samba 4. Even Windows boxes will hardly know the difference.

Group policies don't exist and won't ever exist on Linux. Group policies are LDAP entries that are copied on system boot and user login into their respective parts of the local registry. Software may then read, interpret and use those registry entries. On Linux that wouldn't work for numerous reasons. First, on a multiuser system rebooting to apply configuration changes is not viable. On windows that's apparently fine because its single-user anyways, and reboots are an accepted fact of life. Also, to apply a system policy that is intended to limit what a user could do, asking the user's software nicely via registry entries is stupid and insecure. Lots of software won't even read the registry and have group policies that it will obey. Want to get around an Internet Explorer Group policy? Use Chrome or Firefox!

So what you do instead on Linux is: If it's just configuration, just copy it over, using the usual text configuration formats that are common on Linux. There are lots of tools to do this, starting from simple hack jobs like using scp to full configuration management systems like ansible or puppet. The "group" part is handled by those systems as part of their function, you can easily group/subgroup/discover/inventory/parameterize. If it's policy, so you want to restrict what a user can do, you use the higher-privileged layers of the system to put in actual restrictions, not just "group policy" suggestions. You can configure the user's home directory to be mounted noexec, so software execution after an unauthorized installation is impossible. You can put them in containers, namespaces, limit their resources and system access using cgroups, filesystem permissions, and more fine-grained permission systems like SELinux. If you are so inclined, you can forbid the user from opening files starting with the letter 'f', using eBPF syscall filters (this will of course break everything, but I needed a stupid example ;). All those can also be configured with your configuration management system of choice.

Just as a comparison: Our windows team needs 3h just to re-image a laptop, just for windows. After that, all the software needs to be reinstalled, all the data copied over. Then, after 2 days and 10 reboots or something, it will have picked up all the policies, updates and things and maybe be usable. Our Linux installation takes 45 minutes. Including all the software that was previously assigned to this system, including all the settings. It will be fully updated, configured and usable after the first reboot.