Local Groups Inventory

For every managed machine, Athena inventories the local security groups defined on that machine and who belongs to each one — including the members of privileged groups such as Administrators on Windows or sudo / wheel on Linux. This gives you a fleet-wide view of local privileged access: you can answer "who is a local administrator on this endpoint?" from the console instead of logging on to each device.

This is read-only discovery. Athena reports the local groups and membership each machine already has; it does not create, delete, or change groups, and it does not add or remove members. To change local group membership, run a remote command or a deployment that performs the change on the endpoint.

What's collected#

For each machine, Athena records every local group (not domain or directory groups) and, for each group, the following:

Field	Meaning
Group Name	The name of the local group — for example `Administrators`, `Remote Desktop Users`, `Users` on Windows, or `sudo`, `wheel`, `docker` on Linux.
Description	The group's description text. Windows local groups carry a description; Linux groups do not, so this is blank on Linux.
Members	The list of accounts that belong to the group — the users (and, on Windows, nested groups) that the operating system reports as members.
GID	The numeric group ID. Present on Linux; Windows local groups do not use numeric GIDs.
Privileged	Whether the group grants administrative/elevated rights, so privileged groups can be recognized at a glance. See Privileged groups below.

Local groups only. This record covers the groups defined on the machine itself. Domain / directory group membership is managed and audited in your directory service, not here. On a domain-joined Windows machine, a domain account or domain group that has been added to a local group (for example, a domain group nested into local Administrators) appears as a member of that local group.

Privileged groups#

Each group is flagged as privileged when it grants administrative or elevated rights, so you can focus on the groups that matter for access review:

Windows — groups that confer elevated local rights, such as Administrators and Remote Desktop Users.
Linux — the well-known privileged groups (sudo, wheel, admin, root, docker, lxd, libvirt), plus any group granted rights through the machine's sudoers configuration (/etc/sudoers and /etc/sudoers.d/).

Reviewing the members of privileged groups across the fleet is a practical way to spot local administrator sprawl — for example, personal accounts added directly to local Administrators, or a user added to docker (which is effectively root-equivalent on Linux).

Platform coverage#

Local groups are collected on both Windows and Linux endpoints, using each operating system's native facilities, so a mixed fleet answers the same access questions consistently.

Aspect	Windows	Linux
Which groups	Local (non-domain) security groups on the machine.	Groups defined on the machine.
Members	Reported per group, including nested groups.	Reported per group.
Description	Reported.	Not applicable — blank.
GID	Not applicable.	Reported.
Privileged flag	Well-known elevated groups (e.g. Administrators).	Well-known privileged groups plus groups granted rights in `sudoers`.

Where to see it#

Open a machine from the Agents list, then in the agent detail view's left-hand navigation choose Local Groups. The section lists every local group in a table with three columns — Group Name, Description, and Members — with the members shown one per line so you can read who belongs to a group at a glance.

A search box above the table filters as you type and matches on the group name, the description, and the member names. Typing an account name shows every local group on that machine the account belongs to; typing Administrators jumps straight to the local administrators. Long lists are paginated using your configured default page size.

Like the rest of inventory, the values reflect the machine's last successful collection on its regular reporting cadence rather than a live query at open time. For the wider inventory surface and refresh behaviour, see Inventory.

Scope note. Local group membership is a per-machine inventory field, viewed on a machine's detail view. It is not currently one of the fields you can build a dynamic collection, an automatic tag, or a report-builder column from. If you need a fleet-wide rule (for example, "flag any machine whose local Administrators group contains an unexpected account"), evaluate it on the endpoint with a compliance rule or a custom scan and surface the answer through the scan results — which you can then use in collections, tagging, and reports like any other collected field.

Reading it over the API#

Local groups are part of an agent's full inventory. Fetch the complete inventory document and read the localGroups array:

# Fetch the full inventory for one agent, then inspect local groups & membership
$headers = @{ Authorization = "Bearer $token" }

$inv = Invoke-RestMethod `
  -Uri "https://athena.example.com:8443/api/agents/$agentId/inventory" `
  -Headers $headers `
  -SkipCertificateCheck

# List every local group and its members
$inv.data.localGroups |
  Select-Object groupName, isPrivileged, @{ n='members'; e={ $_.members -join ', ' } }

# Just the members of the local Administrators group
($inv.data.localGroups | Where-Object groupName -eq 'Administrators').members

Each element of localGroups carries groupName, description, members (an array), gid (Linux), and isPrivileged. Reading inventory requires the Helpdesk role or higher. The localGroups array is empty or absent when a machine has not yet reported this data. For the full inventory surface and the PowerShell module used to script against the server, see Inventory and the PowerShell Module reference.