Linux: The System IAM Forgot

When I started out in IT, Identity & Access Management wasn't really a discipline — it was just common sense. You controlled who could get in, you made sure they could only do what they needed to do, and you documented it well enough that you could explain it to someone if things went wrong. It was practical, technical, and grounded in how systems actually worked.

Over time, a whole industry grew up around that common sense. IAM became its own domain, with frameworks, tools, vendors, certifications, and eventually entire teams dedicated to it. That growth is, in many ways, a good thing. But something got lost in the translation.

How IAM Drifted Away from the Machine Room

As IAM matured, it shifted its centre of gravity. What began as a discipline for IT and security teams — a way to make their processes safer, more efficient, and more defensible — gradually became something else: a governance and compliance instrument. The primary audience moved from engineers to auditors and leadership. The primary output moved from access controls to documentation, dashboards, and attestation reports.

That shift in focus isn't inherently wrong. Organisations do need to explain the state of their IT to boards and regulators. But something important was lost in the simplification. The abstraction that makes IAM legible to a non-technical audience — identities, applications, entitlements — works beautifully for most of the landscape. It falls apart when applied to Linux.

The IAM Model and Why Linux Breaks It

The dominant IAM model works like this: a user has an identity, an identity grants access to applications, and applications contain entitlements. Active Directory is the canonical example and it fits the model perfectly. One account. One directory. Groups define what that account can do across hundreds of servers. If you model AD as an application, and its security groups as roles, everything slots neatly into your IGA tool — you can certify access, run access reviews, and produce clean reports.

Most applications work this way, and most IAM tooling is built around that assumption.

Linux doesn't work that way.

Every Linux server has its own local user directory and its own set of local groups. That means two Linux servers means two user directories, two sets of accounts, and two sets of entitlements. In the eyes of your IGA or IAM tool, that also means two applications. Scale to 100 servers and you have 100 applications. Scale to 1,000 servers and you're not just struggling with visibility — you're actively congesting your IAM tool to the point where performance degrades, storage balloons, and the clean governance model collapses under its own weight.

"But We Centralised Authentication"

At this point, a reasonable response is: we solved this with Active Directory integration and SSSD. And that's a valid point — centralised authentication using SSSD genuinely helps. With it, you can use a single directory to control which AD accounts can authenticate to Linux servers, bringing the model closer to the clean one-account-many-applications structure that IAM tools expect.

Done well — and it can be done well — this is a solid architectural choice. It reduces account sprawl, simplifies provisioning, and gives you meaningful authentication governance.

But most organisations are not prepared to go all the way with that journey. And even those that are find that centralised authentication only solves part of the problem. Because in Linux, authentication is just the beginning.

The Privilege Layer Nobody Is Mapping

Here is where Linux diverges fundamentally from the IAM model that most tools and frameworks are built around.

On a Linux server, accounts and groups are just the start. You also have:

• Sudo policies — defining which users and groups can execute which commands with elevated privileges, potentially including unrestricted root access
• File and directory permissions — owner, group, and world access at every level of the filesystem
• SSH key configurations — password auth, key-based auth, or directory auth, each with different trust and audit implications
• NSS Switch configurations — controlling whether the system resolves users and sudo rules from a local file or a directory, in what order

And here is the critical point: if a user can become root through a sudo policy — even a narrowly scoped one — then all bets are off. Every other control below that becomes academic.

The observant reader might say: "What about SELinux?" That would be a fair challenge, and SELinux is genuinely powerful. But SELinux is also a beast in its own right. Getting it configured meaningfully takes months of expertise. The business rarely wants to pay for that, because SELinux doesn't make for nice PowerPoints or help anyone hit their quarterly targets. So it gets enabled, checked off a compliance list, and never actually enforced in a way that changes the security posture.

The Uncomfortable Analogy

Consider this: many organisations are deeply anxious about protecting the credentials for their Domain Administrator account. They have PAM tools, YubiKeys, break-glass procedures, PagerDuty alerts, the works. And rightly so — Domain Admin is powerful.

But the Linux hypervisor that Active Directory runs on? Often ignored. Left with local accounts nobody has audited, sudo rules that haven't been reviewed since the server was built, SSH keys that were added during a late-night incident and never removed.

It is a bit like buying expensive diamonds, leaving them on the kitchen counter, drawing the curtains so nobody can see them — and leaving the front door wide open.

"We Have SIEM. We'll See It When It Happens."

A well-instrumented security stack is genuinely impressive. Audit logs forwarded to a SIEM, UEBA use cases configured for privilege abuse, CrowdStrike EDR on every host, CIS hardening enforced via Ansible playbooks, PAM configured, IAM in place. That combination is more mature than most environments.

But there is a question that tooling like that cannot easily answer: right now, across your Linux fleet, who has sudo access, what commands can they run, and has any of it drifted from what you intended six months ago?

A SIEM can tell you what happened. It can flag anomalies after the fact. It can detect when someone runs a suspicious command. But turning raw audit logs into "this service account has unrestricted sudo on 14 servers and hasn't been reviewed in eight months" requires heavy correlation work that most teams simply don't have bandwidth to maintain continuously.

Centralised sudoers management via AD groups controls who gets in — but do you have visibility into what those sudoers rules actually permit at the command level on each host? AD group membership and the actual sudoers entries on each server can drift in ways that are entirely invisible from the directory side.

The SIEM detects incidents. The goal is to know about the conditions that make incidents possible — before one happens and costs your business millions.

The Real Privilege Landscape vs. the Assumed One

Most organisations have two privilege landscapes on their Linux estate. The first is the assumed one — documented in Confluence, signed off in the last access review, good enough for the auditor. The second is the real one: shaped by years of incidents, Ansible playbooks that quietly added service accounts, engineers who needed temporary root access and never had it revoked, and sudo rules that made sense in 2021 and haven't been looked at since.
The gap between those two landscapes is where attackers live.

So here's the question worth sitting with: when did someone last map the actual privilege landscape across your Linux estate? Not the assumed one — the real one. What's present in /etc/passwd, /etc/sudoers, /etc/sudoers.d/, the SSH authorised keys files, the PAM configuration, the NSS Switch entries, and the local group memberships — across every server, not just a sample.

If you don't have a clear answer to that, you're not alone. That’s what this article really describes — and it’s exactly the gap we built LinuxGuard to close. LinuxGuard is, honestly, the tool I've been missing for two decades of working with large Linux estates.

The 28-Day Linux Identity & Security Audit

LinuxGuard's 28-day Linux Identity & Security Audit is a fixed-scope, fixed-fee engagement that maps every user, group, sudo rule, SSH key, service account, and PAM configuration across your estate. Findings are risk-scored against real exploit patterns — the paths an attacker would actually use first — and mapped to NIS2, DORA, CIS, NIST, SOC 2, PCI DSS, and ISO 27001. You get a board-ready summary, a technical deep-dive, and a phased remediation plan.

No assumptions. No checkboxes. A complete, evidence-based map of who can do what — and whether any of it was ever actually intended.

Book your audit →

LinuxGuard is a Linux Identity & Security Posture platform built for security, IAM, and compliance teams. Learn more at linuxguard.io.