IB Node Security Audit

Tailored Operational Context
  • Target Database:
  • Context Type:
  • Alert Severity:
  • Triggered Time:
  • Firing Context:

IB Node Security Audit Report

Report ID: ib-node-security-audit Category: Integration Broker

Purpose

This report audits Integration Broker node user accounts for security issues that go beyond authentication configuration (which is covered by the Nodes with No Password report). It checks for elevated user privileges on nodes, shared user accounts across multiple nodes, and nodes with no active routings.

What It Detects

CRITICAL — Anonymous Node User Analysis

Checks the ANONYMOUS node’s associated PeopleSoft user account. Flags as HIGH RISK if:

  • The user account is unlocked (can log into PIA directly)
  • The user has PeopleTools access (Application Designer, Data Mover, etc.)

The ANONYMOUS node handles unauthenticated IB traffic. Its user should have minimal privileges and a locked account.

WARNING — Shared Node Users

Identifies cases where the same PeopleSoft User ID (OPRID) is configured on multiple active nodes. Each node should have its own distinct service account for:

  • Audit trail — Knowing which node performed an action
  • Security isolation — Revoking one node’s access without affecting others
  • Least privilege — Tailoring permissions per node’s specific needs

WARNING — Active Nodes with No Active Routings

Finds active non-local nodes that have no active routings in PSIBRTNGDEFN. These nodes may be:

  • Leftover from decommissioned integrations
  • Candidates for deactivation to reduce attack surface
  • Covered only by wildcard (~~ANY~~) routings (reported separately)

WARNING — Node Users with PeopleTools Access

Identifies node service accounts whose permission lists grant access to PeopleTools clients (Application Designer, Data Mover, Query, etc.). Node accounts should never need development tool access.

Tables Queried

PSMSGNODEDEFN — Message Node Definitions

FieldDescriptionValues
MSGNODENAMENode name (primary key)
ACTIVE_NODEWhether the node is active1 = Active, 0 = Inactive
LOCALNODEWhether this is a local node1 = Local, 0 = External
USERIDPeopleSoft user ID associated with the node
NODE_TYPENode type

PSIBRTNGDEFN — Routing Definitions

FieldDescriptionValues
SENDERNODENAMESending node nameNode name or ~~ANY~~
RECEIVERNODENAMEReceiving node name
EFF_STATUSEffective statusA = Active, I = Inactive

PSOPRDEFN — User Definitions

FieldDescriptionValues
OPRIDUser ID (primary key)
OPRCLASSPrimary permission list
ACCTLOCKAccount lock status0 = Unlocked, 1 = Locked

PSAUTHITEM — Menu/Tools Authorizations

Used to check if a permission list grants PeopleTools client access (APPLICATION_DESIGNER, DATA_MOVER, etc.).

Data Flow

1. Fetch ALL message nodes from PSMSGNODEDEFN
   (batches of 300)
        |
        v
2. Fetch ALL active routings from PSIBRTNGDEFN
   Build set of node names with active routings
        |
        v
3. For each unique UserID on active nodes:
   Look up user in PSOPRDEFN
        |
        v
4. For each unique permission list found:
   Check PSAUTHITEM for PeopleTools access
        |
        v
5. Analyze and categorize findings:
   - Anonymous node user privileges
   - Shared node users (same OPRID on 2+ nodes)
   - Active nodes not in routing coverage set
   - Node users with PeopleTools access
        |
        v
6. Generate Markdown report grouped by severity

Interpreting Results

  • CRITICAL findings on the ANONYMOUS node indicate that unauthenticated IB traffic is processed under a user with elevated privileges. This is a significant security risk.
  • Shared node users increase blast radius if one account is compromised and make it harder to trace which node performed specific actions.
  • Nodes with no routings represent unnecessary attack surface. If a node isn’t routing any messages, it should be deactivated.
  • PeopleTools access on node accounts means a compromised integration could potentially be used to modify PeopleSoft objects.

Recommendations

  1. Lock the ANONYMOUS node user account to prevent direct PIA login
  2. Remove PeopleTools access from node service account permission lists
  3. Create distinct service accounts for each Integration Broker node
  4. Deactivate nodes with no active routings if they are no longer needed