Altiward
Request early access
Altiward guide · SIEM evidence

Mac admin evidence in your SIEM.

Altiward adds session records and findings based on observed Mac admin rights. Here's how that differs from forwarding SAP Privileges events, with configuration details for teams that also need its native logs.

Last reviewed

Bring observed admin membership and findings into your SIEM. Altiward checks the Mac's admin group against recorded grants and sends session records and findings for unexpected admins, detected admin-account creation, expiry enforcement and missing check-ins. See the Altiward console and example SIEM event.

Privileges can also forward its own grant and revocation events using RemoteLogging. Those events are useful, but don't by themselves show all admin membership or confirm that checks are still running. The setup below covers this native logging path; it is separate from Altiward's server export.

Checked against Privileges 2.6.0 (17 September 2026), SAP's RemoteLogging documentation, and Splunk and Microsoft documentation current in October 2026. Where a detail comes from reading Privileges' source code rather than SAP's documentation, we say so.

Native Privileges logging: syslog or webhook?

Syslog is a direct route to a log receiver, but omits the grant's expiry time. The webhook includes more fields, but cannot send a custom authentication header. Altiward's session records and findings add the membership checks and enforcement context described above.

Privileges sends to one or the other: ServerType takes a single value, syslog or webhook.

SyslogWebhook
TransportTCP only from Privileges 2, optionally TLS. Port 514, or 6514 with TLS.HTTPS POST of a JSON object. Mutual TLS from 2.3.0.
What's in itUser, whether they're now admin or standard, and the reason. No expiry time and no machine ID.User, admin or not, event, reason, timestamp, expiry, the Mac's hardware UUID, and any WebhookCustomData you add, such as the serial number.
AuthenticationTLS server certificate. No client certificate.No custom headers, so no bearer or HEC token header. A secret in the URL, or a client certificate (mTLS).
Best forSentinel through Azure Monitor Agent; Splunk through Splunk Connect for SyslogSplunk HEC, or anywhere you want the expiry time

Either way, turn on QueueUnsentEvents (2.4.0+) so events from a Mac that's offline are kept and sent later. Up to 20 are queued unless you change QueuedEventsMax.

Set up syslog in Privileges

In your Privileges configuration profile, for the corp.sap.privileges domain:

<key>RemoteLogging</key>
<dict>
  <key>ServerType</key>
  <string>syslog</string>
  <key>ServerAddress</key>
  <string>syslog.example.org</string>
  <key>QueueUnsentEvents</key>
  <true/>
  <key>SyslogOptions</key>
  <dict>
    <key>UseTLS</key>
    <true/>
    <key>ServerPort</key>
    <integer>6514</integer>
  </dict>
</dict>

Messages follow RFC 5424. The facility defaults to 4 (security) and the severity to 6 (informational); change them with LogFacility and LogSeverity. MessageFormat (2.3.0+) picks the TCP framing: 1, the default, for non-transparent framing, or 2 for octet counting, which most modern receivers prefer. Long reasons are cut off at MaximumMessageSize, 480 bytes by default.

For TLS, the server's certificate has to be trusted by the Mac and meet Apple's requirements for TLS server certificates: the host name in the subject alternative name, a SHA-2 signature, and a validity of 825 days or less. If it's from a private CA, deploy the CA certificate with your MDM.

From the 2.6.0 source, a message looks like this (the app name is Privileges, and the message ID is PRIV_A when someone becomes admin and PRIV_S when they go back to standard):

<38>1 2026-10-18T09:12:03.123Z jdoe-mbp Privileges 812 PRIV_A - SAPCorp: User jdoe now has administrator privileges for the following reason: "Install the printer driver"

Set up the webhook in Privileges

Set ServerType to webhook and ServerAddress to the full HTTPS URL. Add WebhookCustomData (2.1.0+) to include values your MDM can fill in, such as the serial number or computer name. SAP's documented payload:

{
  "admin": true,
  "custom_data": { "name": "Testuser's Mac", "serial": "XYZ1234567" },
  "delayed": false,
  "event": "corp.sap.privileges.granted",
  "expires": "2024-11-28T07:40:59Z",
  "machine": "E60E8CCB-32F1-4495-A436-BD1939C2BC32",
  "reason": "",
  "timestamp": "2024-11-28T07:20:59Z",
  "user": "testuser"
}

event is corp.sap.privileges.granted or corp.sap.privileges.revoked. delayed is true for an event that was queued and sent late. On a revocation, reason says why the rights ended.

Two things to plan for. First, Privileges sets only a Content-Type header, so a receiver that needs an Authorization header won't accept it directly. Second, in our reading of the 2.6.0 source, Privileges treats the event as sent once the request completes, whatever HTTP status comes back. A rejected request (401, 400, 500) isn't queued or retried, so test the endpoint end to end before you roll it out.

Splunk

Syslog into Splunk

The supported route is Splunk Connect for Syslog (SC4S). Turn on its TLS listener with SC4S_SOURCE_TLS_ENABLE=yes, which listens on 6514, and put the certificate and key in /opt/sc4s/tls/server.pem and server.key. SC4S has no parser for Privileges, so its events arrive with SC4S's fallback sourcetype. Add a simple filter on the app name Privileges to give them their own sourcetype and index.

For a small fleet, a TLS input directly on a Splunk Enterprise instance also works (inputs.conf reference):

[tcp-ssl:6514]
sourcetype = sap:privileges:syslog
index = macos

[SSL]
serverCert = /opt/splunk/etc/auth/mycerts/server.pem

Webhook into the HTTP Event Collector

HEC normally wants Authorization: Splunk <token>, which Privileges can't send. HEC can accept the token in the query string instead, but only for tokens where you've set allowQueryStringAuth = true. Splunk warns that query strings "may be observed in transit and/or logged in cleartext", so use a dedicated token for this, scoped to one index, over HTTPS only (Format events for HEC). On Splunk Cloud, this setting may need a request to Splunk Support.

Use the raw endpoint. The /event endpoint treats a top-level event key as the event itself, and in Privileges' payload that's just the event name. Include a channel GUID, which HEC needs when indexer acknowledgement is on:

https://hec.example.org:8088/services/collector/raw?token=<token>&channel=<GUID>&sourcetype=sap:privileges:webhook&index=macos

Then parse it as JSON in props.conf:

[sap:privileges:webhook]
KV_MODE = json
SHOULD_LINEMERGE = false
TIME_PREFIX = "timestamp":"
TIME_FORMAT = %Y-%m-%dT%H:%M:%SZ

If a token in a URL isn't acceptable, put a reverse proxy in front of HEC that requires a client certificate from the Mac (Privileges presents one from the keychain for mTLS) and adds the Authorization header itself.

Microsoft Sentinel

Syslog through Azure Monitor Agent

Use the Syslog via AMA connector with a Linux forwarder. AMA accepts both RFC 3164 and RFC 5424 messages, and events land in the Syslog table. A forwarder outside Azure needs Azure Arc.

  1. Run Microsoft's forwarder installer on the Linux host. It sets up rsyslog to listen on 514 over TCP and UDP.
  2. Add a TLS listener on 6514 to rsyslog, following rsyslog's TLS server guide, and point Privileges at it.
  3. In the data collection rule, collect facility auth at Info or above, or whichever facility and severity you set in SyslogOptions.

Webhook through a relay

The Logs Ingestion API needs an Entra ID bearer token and a JSON array, and Privileges sends neither. Put a relay in between: a Logic App with an HTTP request trigger, whose URL carries a shared access signature, or an Azure Function with a function key. The relay wraps each event in an array and posts it to a data collection rule that writes to a custom table, such as SapPrivileges_CL, using a managed identity with the Monitoring Metrics Publisher role on that rule.

Don't build on the older HTTP Data Collector API. Microsoft ended support for it on 14 September 2026.

Searches to start with

Splunk, webhook events: grants per person, with the longest duration they asked for.

index=macos sourcetype=sap:privileges:webhook event="corp.sap.privileges.granted"
| eval granted_min=round((strptime(expires,"%Y-%m-%dT%H:%M:%SZ")-strptime(timestamp,"%Y-%m-%dT%H:%M:%SZ"))/60)
| stats count max(granted_min) as longest_min values(reason) as reasons by user, machine

Sentinel, syslog events: elevations per person and Mac. This assumes the RFC 5424 app name lands in ProcessName; check a sample event from your forwarder first.

Syslog
| where ProcessName == "Privileges" and SyslogMessage has "SAPCorp: User"
| extend User = extract(@"User (\S+) now has", 1, SyslogMessage),
         Reason = extract(@"reason: \"(.*)\"", 1, SyslogMessage)
| where SyslogMessage has "administrator privileges"
| summarize Elevations = count(), Reasons = make_set(Reason) by User, HostName

Then look for the gaps: a grant with no revocation after its expiry time has passed.

What these events don't tell you

Privileges' events describe what Privileges did. They're sent by its agent, in the session of the person who holds admin, so a Mac where that agent stopped simply goes quiet. They don't include admin rights Privileges never granted, such as a second admin account. Privileges 2.6.0 does log every change to the admin group, with the process that made it, on macOS 14 or later with its system extension on, but that record stays on the Mac and sends nothing to a SIEM. When Mac admin rights outlive their timer covers those cases.

Altiward adds membership checks, expiry enforcement and session evidence, exported by your server as OCSF events. A missing Altiward check-in is a finding about lost visibility, not a complete record of what happened while the agent was unavailable. Correlate session times and detected account changes with your existing security telemetry when investigating activity. See how it works.

Sources

Altiward is in early access.

Altiward will be free for up to 25 Macs. For larger fleets, talk to us about licensing.

Request early access