BeyondTrust Integrations: — REST API, SAML/MFA, ServiceNow, SIEM & Entra ID

① Identity in — SAML SSO, MFA & directory groups

Think of the Password Safe portal as the bank’s locker ROOM, not the locker. The lockers (vaulted credentials) are strong, but the room entrance is where identity matters: the bank checks your Aadhaar-verified pass at the door (SSO + MFA), and the register at the gate decides which counters you may visit (your groups). In BeyondTrust terms: SAML handles the door, directory groups handle the register.

Why push login out to an IdP like Entra ID or Okta? Two reasons. First, MFA lives at the IdP — Conditional Access, number matching, phishing-resistant FIDO2 — and PAM inherits all of it without its own MFA stack. Second, joiner-mover-leaver becomes one change: HR disables the AD account, the IdP refuses the login, and PAM access dies the same second. No orphan PAM accounts for the auditor to find.

The console path to memorise: Configuration > Authentication Management > SAML Configuration, then Create New SAML Identity Provider +. You paste the IdP’s Identifier (entity ID), Single Sign-on Service URL and signing certificate; BeyondInsight auto-generates the Service Provider side — its own Entity ID and the Assertion Consumer Service URL the IdP must post assertions to. One hard floor worth quoting in interviews: incoming SAML assertions can no longer be signed with SHA1 — weak-signature assertions are rejected outright.

PRA has its own door: /login > Users & Security > Security Providers accepts SAML, LDAP, RADIUS and Kerberos providers, and Group Policies pick users up by the group attribute the IdP sends. Same pattern, different console — one IdP can front BeyondInsight, Password Safe and PRA together, which is exactly what you want: one login story, one MFA story, one off-boarding story.

Now the register at the gate: directory groups drive authorization. A BeyondInsight group can be created from an AD/LDAP or Entra ID query, and everything hangs off that group — Password Safe roles (Requestor, Approver, ISA), Smart Group permissions, and the access policy that says when and how its members may connect. Onboarding the new DBA Aditya = add him to one AD group. Nothing inside PAM changes hands.

Four words that carry this whole section

Tap each card — these four turn up in every SSO troubleshooting call.

② ITSM — ServiceNow ticket-gated access

Every Indian housing society runs this control already: a visitor enters only against a slip the flat owner pre-approved, and the slip number is written into the gate register next to the entry and exit times. Months later, anyone can trace visit → approval → slip. That is exactly what the ServiceNow integration does for privileged access: no ticket, no entry; and the entry is written back against the ticket.

Mechanically there are two layers. The lighter one is built into Password Safe access policies: the ticket number field can be made required, so a release request must carry a reference. The full integration is the certified ServiceNow app: users request checkout from the ticket itself using Incident, Change Request or Problem flows; Password Safe validates the ticket exists and is in an open, valid state before releasing anything; and the session link lands back on the ticket record. Requirements worth memorising: Password Safe 22.2+, managed accounts with API access enabled, and an API registration assigned to a BeyondInsight group containing the requestor accounts.

PRA carries the same gate for remote sessions: a Jump Policy has the literal checkbox "Require a ticket ID before a session starts", pointing at your configured ticket system. So a vendor engineer Jumping to a production switch and a DBA checking out the sa password both answer the same question first: which approved change is this? Remember the PRA constraint from lesson 13 — a Jump Policy cannot enable both a schedule and approval at once, but ticket-ID can ride alongside either.

③ SIEM & SOC — syslog, Splunk/Sentinel, the events that matter

A jeweller’s CCTV that records to a hard disk nobody watches still loses the gold — it only helps the post-mortem. A PAM that logs only to itself is the same device. The fix is one connector: BeyondInsight ships every privileged event to your SIEM, where a detection wakes a human in minutes instead of an auditor in months.

The console path: Configuration > General > Connectors > Create New Connector, type Syslog Event Forwarder — pick a format your SIEM parses (CEF or LEEF, plus newline/tab-delimited and JSON), point it at the collector, and tick the Event Filters for what to forward. Splunk shops can skip syslog: the Splunk Event Forwarder connector posts straight to the HTTP Event Collector (default port 8088) with a Splunk API key. PRA forwards too: every /login, /appliance and console authentication event can ship via UDP 514 or TLS TCP 6514, and Management > Outbound Events fires webhooks on session start/end for SOAR pipelines.

The five event families that matter

Do not forward everything and drown. Five families cover most PAM risk: password release/check-out (who took which key), rotation failures (the vault’s own health — a burst means the functional account broke), session start/stop (proxy + PRA), policy and Smart Rule changes (attackers widen policies before they steal), and failed logins + API sign-ins (SignAppin failures, OAuth grants, new source IPs). Wire one named detection per family before you build anything fancier.

index=pam sourcetype="beyondtrust:beyondinsight" "Password change failed"
| stats count AS failures BY ManagedSystem, FunctionalAccount
| where failures > 5
| sort - failures

ManagedSystem    FunctionalAccount   failures
db-prod-1        svc-psafe-fa        14
app-prod-3       svc-psafe-fa        11
-- same FA failing everywhere = fix ONE credential, not 25 servers

Syslog
| where SyslogMessage has "SignAppin"
| extend SrcIP = extract(@"from ([\d\.]+)", 1, SyslogMessage)
| summarize firstSeen = min(TimeGenerated) by SrcIP
| where firstSeen > ago(1d)

SrcIP            firstSeen
203.0.113.77     2026-06-10T02:14:09Z
-- 1 row: a brand-new source IP using the API at 02:14. Page someone.

That second detection is not paranoia — it is history. In December 2024, attackers used a stolen Remote Support SaaS API key to reset local application passwords and reach 17 customers including the US Treasury (CVE-2024-12356 rode alongside as the software flaw). MFA never saw it, because machine keys do not do interactive login. The only controls that catch a stolen key are the ones in this section and the next: anomaly detection on key usage, IP restrictions, scoping and rotation.

④ The REST APIs — Password Safe, PRA, and the JIT cloud edge

Everything you have clicked in this series is callable. The Password Safe public API lives at /BeyondTrust/api/public/v3 and authenticates with the PS-Auth header: a 128-character key from an API registration, plus runas — a real Password Safe user whose roles decide what the call may touch. Sign in once with POST Auth/SignAppin; the session cookie keeps state until POST Auth/Signout.

# 1. Sign in (session cookie carries state between calls)
curl -sk -c /tmp/ps.jar -X POST \
  "https://bi.icicilab.in/BeyondTrust/api/public/v3/Auth/SignAppin" \
  -H "Authorization: PS-Auth key=c479a66f...9484d; runas=icici\svc-ansible; pwd=[S3cure#21];"

# 2. Find the account (must be Enable for API Access)
curl -sk -b /tmp/ps.jar \
  "https://bi.icicilab.in/BeyondTrust/api/public/v3/ManagedAccounts?systemName=db-prod-1&accountName=sa_dbpatch"

{"UserId":42,"UserName":"icici\\svc-ansible","Name":"Ansible Service"}
{"PlatformID":4,"SystemId":12,"SystemName":"db-prod-1",
 "AccountId":47,"AccountName":"sa_dbpatch","DefaultReleaseDuration":120}

Then the same request → retrieve → check-in loop a human does in the portal: POST Requests raises the request (put the change number in Reason — the audit trail thanks you), GET Credentials/{requestId} retrieves the secret, PUT Requests/{requestId}/Checkin releases it and triggers rotate-on-release. Two traps from lesson 6 still apply here: GET ManagedAccounts only returns accounts with Enable for API Access set and where the runas user holds Requestor/ISA, and a 2FA-enabled user’s first SignAppin deliberately returns 401 + a WWW-Authenticate-2FA header — the challenge, not an error. ISA users skip approval entirely via POST ISARequests.

# 3. Raise the request (ticket number rides in Reason)
curl -sk -b /tmp/ps.jar -X POST -H "Content-Type: application/json" \
  "https://bi.icicilab.in/BeyondTrust/api/public/v3/Requests" \
  -d '{"SystemId":12,"AccountId":47,"DurationMinutes":60,"Reason":"CHG0031245 patch window"}'

# 4. Retrieve, use, check in (check-in triggers rotate-on-release)
curl -sk -b /tmp/ps.jar "https://bi.icicilab.in/BeyondTrust/api/public/v3/Credentials/891"
curl -sk -b /tmp/ps.jar -X PUT -H "Content-Type: application/json" \
  "https://bi.icicilab.in/BeyondTrust/api/public/v3/Requests/891/Checkin" -d '{}'

891
"xR9$mK2#vL8@pQ4w"
(HTTP 204 No Content — checked in, rotation queued)

Where do keys come from? Configuration > General > API Registrations > Create API Registration. An API Key Policy registration issues the 128-character key (masked in the UI — click Show Key); an API Access Policy registration enables OAuth client-credentials for application users instead. Scoping is the whole game: add authentication rules restricting the source IP, range or CIDR (plus X-Forwarded-For rules behind load balancers), keep the runas users least-privilege, and note the platform direction — client certificates are being retired as an API registration auth method, so build new automation on keys or OAuth.

PRA speaks a different dialect: pure OAuth. Create an API account at /login > Management > API Configuration, then exchange client_id:secret (Base64, Basic header) at POST /oauth2/token for a Bearer token that lives one hour — an account holds at most 30 live tokens, and regenerating the secret kills them all instantly. The Configuration API under /api/config/v1 covers Jump Items, users, policies and Vault accounts (mass-onboarding 500 Shell Jump items = a for-loop, not a week of clicking), the command API drives sessions, and the reporting API exports session logs and recordings — the no-code alternative being the Integration Client pulling .xml logs and .flv recordings to SQL Server or a file share.

# Token: client_id:secret Base64-encoded in a Basic header (1-hour lifetime)
curl -s -X POST "https://pra.icicilab.in/oauth2/token" \
  -H "Authorization: Basic $(printf 'a3f9c2e1:8d41e7bb' | base64)" \
  -d "grant_type=client_credentials"

# Spend the Bearer: list Jump Items
curl -s "https://pra.icicilab.in/api/config/v1/jump-item" \
  -H "Authorization: Bearer eyJhbGciOi..." -H "Accept: application/json"

{"access_token":"eyJhbGciOi...","token_type":"Bearer","expires_in":3600}
[{"id":7,"name":"core-sw-01","jump_type":"shell_jump","hostname":"172.16.40.7"},
 {"id":8,"name":"pay-prod-2","jump_type":"remote_rdp","hostname":"10.20.8.11"}]

The cloud edge rounds out the ecosystem. Identity Security Insights ingests AD, Entra ID, Okta, AWS, GCP and GitHub to map paths to privilege — the back-lanes (group nesting, role chains) an attacker would walk from a normal account to domain admin. Entitle brings JIT entitlements: like a Tatkal ticket instead of a lifetime rail pass, cloud access is granted for one journey and expires by itself — the standing-privilege killer. Both fold into the Pathfinder platform direction, and both are interview-current: "how would you remove standing access in AWS?" now has a BeyondTrust answer.