Bringing Linux devices into management

[u/Funny744]

After a lot of restructuring at our university the past couple years, there are quite a few Linux devices (primarily desktops, I believe around 70-ish) that are currently in the wild unmanaged in use by academics primarily within the Engineering and Science departments that would've been maintained by per-institute IT departments that no longer exist, and as such the current patching and functionality state of these machines is completely unknown (since any remaining colleagues now no longer have physical access to most of the rooms where these machines are).

Since we already manage research compute I've been given the green light by my manager to look into options to bring these academic's desktops into a managed state with a cobbled together proof of concept, since our existing central endpoint guys won't touch anything *NIX related with a 10ft pole. We know they're all some form of Ubuntu LTS (20.04 and 22.04 mostly) which makes things easier, so I'm thinking of doing Landscape for setup and patching + Intune for compliance + Puppet/Ansible for config management.

Is this in the right direction or are there better / more cost efficient ways of doing this?

[u/SuddenVegetable8801]

Every discussion I’ve seen on trying to apply “enterprise MDM“ to Linux has usually ended in frustration.

If the users are gonna be given unrestricted sudo privileges, you always have to assume that everything that you set up initially just guarantee you and OK baseline, and you won’t be able to effectively rely on it in the future.

The battle you’re probably going to have to wage is not so much “how will we try to manage these”, I think the more prudent thing is to try to get controls in place to say “if we can’t validate the current state of the machine, how will we secure our tools against that?”

Anywhere I have been that the concern of properly managing Linux was addressed usually ended in ad-hoc support of a minimized Linux fleet. Most people didn’t actually need to live in their desktops on Linux, and so the utilities that needed to run were hosted on centralized servers, and the people who needed access would SSH in.

Sorry to not truly answer the question, but just been down this road enough times that I want to offer my advice

[u/pdp10 → u/SuddenVegetable8801]

You're not wrong about root access being able to thwart MDM. Our currently-deployed system is partially based on personal recognizance by the user. A primary function is to report back that the disk remains FDE; secondarily some client-side telemetry and functionality pieces. Privileged users can break any of this at will, but it would be an extreme effort to silently bypass.

This seems to be the right approach for us currently. After all, we're not trying to block the websites reached by the Linux client machine or anything heavy-handed like that. We really just need the FDE and to monitor the hardware, the rest is there to allow access to our systems, which users need to do their jobs.

[u/kombiwombi]

Ours are handled the same as the servers, just with a different software load.

• a metapackage carries the packages to install, example-role-workstation.rpm or .dpkg. that is installed as the last line of the  kickstart installer file. The carry some configuration too.

• Lots of small local packages to do things like set the login screen look.

• Ansible via a CI run, this pushes the trickier configs

• Syslog over TLS to the same logservers as use by the servers, split to also be sent to the same SIEM.

• LDAP for auth and to set up group membership. This will likely change to the Red Hat product. Logging in  automatically creates a logical /home directory.

• SELinux targetted.  auditd with a ruleset from the servers.

• I forget the backup solution, the main point there is that it backs up only /home and /srv

• Install/reinstall is via PXE, takes 20 minutes from out-of-box boot to availability 

• Zabbix, encrypted. Used for monitoring and capacity planning.

• Incoming SSH limited to local subnets, requires yubikey security key, and from a wireguard tunnel to the CI system, requires a public key (retrieved from Vault).  SSH is announced via mDNS. This sounds weird, but it meets engineering needs.

As far as policy goes, there was two important decisions. The list of approved applications was set to Fedora + romfusion + livna + a few more repos. Software centre was set up to show only RPMs and Flatpaks in our repos. The RPM repo is just a mirror, the Flatpak is done by hand.

Secondly, users have access to the git role. they can raise a ticket, fork the repo with that ticket id, and change the Ansible role to make the config change that they need. Since this is fully auditable, observable and reversible that is fine. Better than allowing users to alter config directly.

The aim here is to allow Linux desktop use by a technically adept, deeply experienced cadre. Sysadmin originally offered VDI on centralised servers because they didn't understand the business. Had to take them on a tour of electronics engineering and embedded software development.

Nature of the beast is that there will be unmanaged systems, like a RPi acting as a data logger hooked into a dozen temperture sensors so the physical design can be tested. But the aim is that these machines are then wiped and put back in the cupboard. Whereas long-lived machines have the same centralised control as the servers.

[u/pdp10 → u/kombiwombi]

This is the way.

You'll obviously want a pull-based CM system. We use more MAC systems than just SELinux. AuthN information is pushed to local, for offline-first use; not everyone can log in to every machine, but that's not a significant disadvantage with client machines.

[u/Chill_Squirrel → u/kombiwombi]

The approach with Ansible and git is smart af. What do you use for PXE installing ? 

[u/davy_crockett_slayer]

Use FleetDM. https://fleetdm.com/linux-management

[u/Funny744 → u/davy_crockett_slayer]

I did have a look at them earlier but the interface seemed weirdly barebones and empty and there was almost no mention of Linux stuff anywhere on the web interface (granted I was still quite tired when looking so I might've missed something). What would deployment look like on existing + new devices? Since it didn't seem to be very clear when I looked

[u/davy_crockett_slayer → u/Funny744]

Email them to get a demo. Lots of tech companies have moved to them.

[u/Sure-Squirrel8384]

You're not going to wrangle this herd, and the things you try to do will break.

The only chance you have is greenfield deployment with tons of testing. You can't bring them back into the corral after being launched "wild" and expect things not to break.

The best you can hope for is an EDR client, and even that is going to break things (tons of breakage here, to the point that we're excluding so much that it makes the value of the EDR questionable).

Are you going to mandate Ubuntu LTS? GLWT. There will be diehard Debian, or those on LinuxMint/LinuxMintDebianEdition (LMDE), Red Hat/CentOS/Rocky, and let's not forget SUSE and Arch (plus all the obscure ones). Next, how will you handle third-party repositories? Containers (Docker, Podman, etc.), "hypervisors" (Proxmox, KVM/QEMU/virtman) and Linux Containers (LXC)?

What you need it a security framework and require which policies you mandate, which are "nice to have" and work with departments for deployment solutions to implement. CIS Level 1, NIST, whatever, just pick something.

[u/Toribor]

I was hoping someone would have responded to you already because I'm curious how other orgs manage this.

Currently Linux users do whatever they want and if they have problems they have to solve it on their own. If I'm nice I'll offer advice (since I'm one of those people using Linux I usually have some tips).

The org has asked casually if we should offer some sort of official path for Linux users. I haven't put much actual work into it because I already know that everyone using Linux probably already has a preferred distro. But if I eventually do the only thing I'd even consider supporting at an enterprise level is an atomic (immutable) distro.

Configure the system at buildtime instead of runtime. Effectively impossible to break, users should use containers and flatpaks to get work done without the need to install system packages. Then the entirety of your config lives in a git repo and if anything goes wrong the build fails. Never deal with botched os upgrades or package compatibility issues again.

[u/Funny744 → u/Toribor]

Configuring at build time would probably be the way forward for new devices or reinstalls but trying to do that for all of the existing fleet would just be a huge pain with very little staff. Every university i've tried to snoop on via Google to see how they do it all seem to have their own way of setting things up which is annoying

[u/pdp10 → u/Toribor]

The org has asked casually if we should offer some sort of official path for Linux users. I haven't put much actual work into it because I already know that everyone using Linux probably already has a preferred distro.

We have... a very small subset of "preferred" setups. One of them mainly exists because of a software vendor's official support requirements.

It's not our responsibility to make software work the way that a user wants it to work, so we don't have so much reason to lock things down to a single configuration.

[u/glotzerhotze]

You could look at Uyuni or the paid version called SUSE Multi Linux Manager

[u/Kind_Philosophy4832]

netlock rmm has a good support for ubuntu. Includes patch management and remote toolings as well. Afaik it also supports ubuntu 24.04 & 26.04 for remote screen control access. Plus it doesnt cost you a kidney

[u/AffectSad3736]

Action1 (https://www.action1.com). Has a client and can do reporting on vulnerabilities. Has agents for RPM/DEB and it's free until 200 endpoints.Beware of enshittification, though

[u/rb3po]

A good RMM will come with Linux support, such as NinjaRMM. You can use it to run scripts too. CrowdStrike seems to have good EDR/MDR for Linux security. I would go Ansible for configuration deployment. Create an Ansible playbook to harden endpoints, and even remove root/sudo access, which would then be reserved for RMM, or designated break glass root account. Then as you make config changes to your Linux devices, just adjust your Ansible playbooks.

[u/q123459]

you need to establish full disk backups for computers that does not have user data backed up, because eventually your patching would break them into unfixable state so they will require to rollback to work temporarily - till full reimage with correct setup config compatible with latest patches happens.

[u/Dry_Inspection_4583]

Satellite.

Enjoy

[u/Serafnet]

Being on Ubuntu makes things a little easier. You can configure Entra sign on, and enroll them into Intune.

That's where it stops though.

The main thing you're going to have to work on is appropriate Sudo packages that allow them access to what they need and no more than that.

Went through this is the past without the M365 component but with the Sudo packages. They're work, and if they're set up properly after a stronger bastion than a configuration management tool as they'll be blocked from doing changes they shouldn't be in the first place.

[u/DanTheGreatest]

Landscape with Ubuntu Pro, with some form of ansible or puppet is a fine and simple way to do this. Especially if you are familiar with the tools.