Summary
The JumpCloud integration currently supports these service categories:
all | directory | radius | sso | systems | ldap | mdm
(from packages/jumpcloud/data_stream/events/manifest.yml, jumpcloud 1.17.1.)
JumpCloud's Privileged Access Manager (PAM) produces audit events for privileged sudo grants (temporary local admin elevation via the accessrequests API). These events are exposed by JumpCloud's Directory Insights API but are not collected by this integration because the services enum does not include a PAM category and the collector does not request PAM events.
Observed behavior
With jumpcloud 1.17.1 and services: ['all']:
POST /api/v2/systems/{id}/associations with additionalAttributes.sudo.enabled=true (standing admin grant) is ingested as event.action: association_change with full payload (sudo attrs, passwordSource, connection from/to). Works.
POST /api/v2/accessrequests with additionalAttributes.sudo.enabled=true (temporary admin elevation, JumpCloud PAM) produces nothing in logs-jumpcloud.*. An ES|QL hunt across event.action LIKE "*access*" OR "*pam*" OR "*elev*" OR "*privileg*" returns zero rows.
Proposed change
- Add PAM as a supported value in the
services variable in packages/jumpcloud/data_stream/events/manifest.yml, and ensure all includes it.
- Update the httpjson stream template so the collector requests PAM events from Directory Insights when PAM is selected (or implicitly via
all).
- Extend the ingest pipeline to recognize PAM event types and map them to ECS (
event.category: iam, event.action set appropriately).
- Add a
_dev/test fixture covering a PAM event.
Why
Temporary privileged access events are a high-value SIEM signal: they are the authoritative record of who got admin on which endpoint, when, and for how long. Without this change:
- ISO 27001 A.8.2 (privileged access rights) and SOC 2 CC6.1 evidence collection miss the most relevant control.
- Detection use cases (grants outside business hours, back-to-back grants on the same device, grants exceeding duration thresholds, grants to users who already have standing admin) are not implementable because the events never reach Elasticsearch.
References
Environment
- Elastic Cloud stateful, Elasticsearch + Kibana
8.19.14
jumpcloud 1.17.1
Summary
The JumpCloud integration currently supports these service categories:
(from
packages/jumpcloud/data_stream/events/manifest.yml,jumpcloud 1.17.1.)JumpCloud's Privileged Access Manager (PAM) produces audit events for privileged sudo grants (temporary local admin elevation via the
accessrequestsAPI). These events are exposed by JumpCloud's Directory Insights API but are not collected by this integration because theservicesenum does not include a PAM category and the collector does not request PAM events.Observed behavior
With
jumpcloud 1.17.1andservices: ['all']:POST /api/v2/systems/{id}/associationswithadditionalAttributes.sudo.enabled=true(standing admin grant) is ingested asevent.action: association_changewith full payload (sudo attrs, passwordSource, connection from/to). Works.POST /api/v2/accessrequestswithadditionalAttributes.sudo.enabled=true(temporary admin elevation, JumpCloud PAM) produces nothing inlogs-jumpcloud.*. An ES|QL hunt acrossevent.action LIKE "*access*" OR "*pam*" OR "*elev*" OR "*privileg*"returns zero rows.Proposed change
servicesvariable inpackages/jumpcloud/data_stream/events/manifest.yml, and ensureallincludes it.all).event.category: iam,event.actionset appropriately)._dev/testfixture covering a PAM event.Why
Temporary privileged access events are a high-value SIEM signal: they are the authoritative record of who got admin on which endpoint, when, and for how long. Without this change:
References
Environment
8.19.14jumpcloud 1.17.1