# IB Node Security Audit
> This report audits Integration Broker node user accounts for security issues that go beyond authentication configuration (which is covered by the N...
---
Site [llms.txt](/llms.txt)
---
New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
## 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](/docs/reports/security/security-nodes-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.). The check covers the user's primary permission list and every permission list granted through the user's roles. Node accounts should never need development tool access.
## Tables Queried
### PSMSGNODEDEFN — Message Node Definitions
| Field | Description | Values |
| ----------- | ------------------------------------------- | ---------------------------- |
| MSGNODENAME | Node name (primary key) | |
| ACTIVE_NODE | Whether the node is active | `1` = Active, `0` = Inactive |
| LOCALNODE | Whether this is a local node | `1` = Local, `0` = External |
| USERID | PeopleSoft user ID associated with the node | |
| NODE_TYPE | Node type | |
### PSIBRTNGDEFN — Routing Definitions
| Field | Description | Values |
| ---------------- | ------------------- | ---------------------------- |
| SENDERNODENAME | Sending node name | Node name or `~~ANY~~` |
| RECEIVERNODENAME | Receiving node name | |
| EFF_STATUS | Effective status | `A` = Active, `I` = Inactive |
### PSOPRDEFN — User Definitions
| Field | Description | Values |
| -------- | ----------------------- | ---------------------------- |
| OPRID | User ID (primary key) | |
| OPRCLASS | Primary permission list | |
| ACCTLOCK | Account lock status | `0` = Unlocked, `1` = Locked |
### PSROLEUSER / PSROLECLASS — Role Permission Lists
Used to find every permission list a node user holds through roles. PeopleTools access is usually granted through a role, not the primary permission list.
### PSAUTHITEM — Menu/Tools Authorizations
Used to check if a permission list grants PeopleTools client access (APPLICATION_DESIGNER, DATA_MOVER, etc.).
## Data Flow
```text
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 and the user's
role permission lists (PSROLEUSER -> PSROLECLASS)
|
v
4. For each unique permission list found (primary + roles):
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 accounts (their roles and primary permission list)
3. Create distinct service accounts for each Integration Broker node
4. Deactivate nodes with no active routings if they are no longer needed