Security

• 1: Full Access Permission Lists
• 2: Nodes with No Password
• 3: Stale Password Audit
• 4: User Full Access Report
• 5: Permission List Table Access Report
• 6: Dangerous Permissions Audit
• 7: SOAP to CI Access Audit
• 8: SSO Bypass Password Audit
• 9: PeopleTools Access Audit

1 - Full Access Permission Lists

Full Access Permission Lists Report

Report ID: security-full-access-permlists Category: Security Default Parameter: minMenuCount = 50

Purpose

This report identifies PeopleSoft permission lists that have an unusually high number of menu authorizations. Permission lists with 50+ menu authorizations are usually “superuser” lists that grew organically. Find them so you can audit who has them.

What It Detects

Permission lists where the total count of menu authorizations meets or exceeds a configurable threshold (default: 50).

Menu authorizations are entries in PSAUTHITEM that match real menus in PSMENUITEM via a parent-child join. This excludes special permissions like APPLICATION_DESIGNER, DATA_MOVER, QUERY, and WEBLIB entries.

Tables Queried

PSCLASSDEFN — Permission List Definitions

The primary record for PeopleSoft permission lists (also called “classes”).

PSAUTHITEM — Menu Authorization Entries

Each row represents a menu/bar/item combination that a permission list is authorized to access.

PSMENUITEM — Menu Item Details

Used via a parent-child join with PSAUTHITEM to validate that authorization entries correspond to real menu items. Only PSAUTHITEM entries matching a PSMENUITEM record are counted.

Data Flow

1. Fetch ALL permission lists from PSCLASSDEFN
   via SearchPermissionLists (batches of 300)
        |
        v
2. For EACH permission list:
   Query PSAUTHITEM joined with PSMENUITEM
   via GetMenuAuthorizations (pages of 100)
   Count total matching entries
        |
        v
3. Filter: keep only permission lists where
   menu auth count >= minMenuCount (default 50)
        |
        v
4. Sort results by menu auth count (descending)
        |
        v
5. Generate Markdown report with summary table

Report Output

The generated report contains:

• Header with database name, generation timestamp, and threshold value
• Summary showing total permission lists analyzed and count flagged
• Flagged Permission Lists table with columns:
  • Permission List (CLASSID)
  • Description (truncated to 50 characters)
  • Menu Auth Count
  • Last Updated By (operator ID)
  • Last Updated (timestamp)
• Recommendations section with remediation guidance

Parameters

Interpreting Results

• High counts (200+): These permission lists likely grant access to a very large portion of the application. They are often “admin” or “superuser” lists and should be reviewed to ensure they are only assigned to appropriate roles.
• Moderate counts (50-200): May indicate permission lists that have grown over time. Consider whether they can be split into more focused lists.
• Last Updated By: If the operator is not a known security administrator, investigate whether the change was authorized.

Recommendations

1. Review flagged permission lists for excessive access
2. Consider splitting broad permission lists into more focused, role-specific lists
3. Verify that the “Last Updated By” operator is authorized to make security changes

2 - Nodes with No Password

Nodes with No Password Report

Report ID: security-nodes-no-password Category: Security

Purpose

This report identifies active PeopleSoft message nodes that have no authentication configured or have authentication enabled but no passwords set. Anything on the network can post messages to these nodes.

What It Detects

The report categorizes problem nodes into three severity levels:

CRITICAL — Active Nodes with No Authentication

Active nodes where AUTHOPTN = 'N' (None). Any external system can communicate with these nodes without providing any credentials.

WARNING — Active Nodes with Auth but No Passwords

Active nodes that have an authentication option configured (AUTHOPTN is P, C, or T) but neither the internal password (IBPASSWORD) nor external password (IBEXTERNALPWD) fields contain a value.

INFO — Inactive Nodes with No Authentication

Nodes that are currently inactive (ACTIVE_NODE = '0') but have no authentication. While not an immediate risk, these would become vulnerable if reactivated.

Table Queried

PSMSGNODEDEFN — Message Node Definitions

The primary record for PeopleSoft Integration Broker message nodes.

Data Flow

1. Fetch ALL message nodes from PSMSGNODEDEFN
   via SearchNodes (batches of 300)
        |
        v
2. Categorize each node:
   - Is it active? (ACTIVE_NODE == "1")
   - What is its auth option? (AUTHOPTN)
   - Does it have any password? (IBPASSWORD or IBEXTERNALPWD)
        |
        v
3. Sort into three buckets:
   CRITICAL: Active + AuthOptn == "N"
   WARNING:  Active + AuthOptn != "N" + no passwords
   INFO:     Inactive + AuthOptn == "N"
        |
        v
4. Generate Markdown report grouped by severity

Categorization Logic

The report uses these helper methods on each node record:

Report Output

The generated report contains:

• Header with database name and generation timestamp
• Summary with total node counts, active count, and counts per severity category
• CRITICAL section (if any): Table with node name, description, node type, connector, user ID, last updated by/when
• WARNING section (if any): Table with node name, description, auth option label, internal/external password status (Set/Not Set), user ID, last updated
• INFO section (if any): Table with inactive node name, description, node type, last updated by/when
• Recommendations based on which severity categories have findings

Parameters

This report has no configurable parameters.

Interpreting Results

• CRITICAL findings require immediate action. Active nodes with no authentication mean any system on the network can send messages without credentials.
• WARNING findings should be investigated. Authentication is configured but credentials may not be properly set, rendering the authentication ineffective.
• INFO findings are lower priority but represent latent risk. If these nodes are ever reactivated, they would immediately become vulnerable.

Authentication Option Reference

Recommendations and Remediation

Inbound Nodes: Require Authentication and Lock Down the Default User ID

When a node has AUTHOPTN = 'N' (None), any client that can reach the Integration Gateway and specify that node name as the sender (<RequestingNode>) can invoke inbound service operations without a password. If the request passes routing checks, Integration Broker executes the subscription or request handler PeopleCode under the security context of the node’s Default User ID (PSMSGNODEDEFN.USERID).

To remediate an active node used for inbound integrations:

1. Enable Node Authentication: Navigate to PeopleTools > Integration Broker > Integration Setup > Node Definitions, open the node, and change Authentication Option from None to Password (AUTHOPTN = 'P') or Certificate (AUTHOPTN = 'C'). Note that Authentication Option = None is also incompatible with PeopleSoft Single Sign-On (SSO).
2. Assign a Dedicated, Low-Privilege Default User ID:
   • Create a unique OPRID per integration node following a clear naming convention such as {ORG_PREFIX}_{APP_NAME}_NODEUSER (for example, CHG_SSOSYSTEM_NODE_USER). This isolates permissions per partner and stamps LASTUPDOPRID audit columns with the specific integration identity.
   • Never assign a superuser account (such as PS or VP1) as a node’s Default User ID.
   • Do not set a PSOPRDEFN login password or grant PIA sign-on / WebLib permissions to this user (inbound node password validation checks the password on the node definition, not PSOPRDEFN).
   • Grant the Default User ID permission lists that authorize only the specific service operations (PSAUTHWS) and Component Interfaces required by that integration partner.
3. Eliminate Any-to-Local (~~ANY~~) Routings: Replace Any-to-Local routings on sensitive service operations (such as USER_PROFILE) with explicit sender-to-receiver node routings. See the Active Any-to-Local Routings and Unauthenticated Node Service Operations reports.

Outbound-Only HTTP Nodes and the ANONYMOUS Node

There are two cases where AUTHOPTN = 'N' appears intentionally:

• Outbound-Only External Nodes (HttpTargetConnector): Node Authentication (AUTHOPTN) validates inbound requests from a partner, not outbound requests sent by PeopleSoft. If an External node is used strictly as an outbound HTTP client target, Authentication Option = None is only safe if its Default User ID is a dummy account with zero service operation permissions (PSAUTHWS) and no inbound routings accept messages from that node.
• The Delivered ANONYMOUS Node: PeopleTools uses ANONYMOUS as the fallback node when an inbound request omits credentials (used for WSDL/XSD schema retrieval, PeopleSoft Test Framework, and public endpoints). Because ANONYMOUS has AUTHOPTN = 'N', its Default User ID must have strictly minimal permissions and must never be paired with sensitive Any-to-Local routings.

3 - Stale Password Audit

Stale Password Audit Report

Report ID: security-stale-passwords Category: Security

Purpose

This report identifies unlocked PeopleSoft user accounts whose passwords have not been changed within a configurable number of days. External auditors will ask. SSO accounts are automatically excluded, so the list is users who still have a real PeopleSoft password.

What It Detects

The report categorizes stale password accounts into three severity levels based on how long the password has been unchanged:

CRITICAL — Password Not Changed in Over 1 Year

Unlocked accounts where the password has not been changed in over 365 days. These represent the highest risk and should be addressed immediately.

WARNING — Password Not Changed in Over 180 Days

Unlocked accounts where the password is between 180 and 365 days old.

INFO — Password Exceeds Configured Threshold

Unlocked accounts where the password exceeds the configured threshold (default 90 days) but is less than 180 days old.

The report also separately identifies:

• No Password Change Date Recorded. Unlocked accounts with no recorded LASTPSWDCHANGE value (may be migrated or misconfigured)

SSO users (accounts with no PeopleSoft password set) are automatically excluded from this report.

Table Queried

PSOPRDEFN — Operator Definitions (User Accounts)

The primary record for PeopleSoft user accounts.

Data Flow

1. Fetch ALL users from PSOPRDEFN
   via SearchUsers (batches of 300)
        |
        v
2. Filter:
   - Skip locked accounts (ACCTLOCK = 1)
   - Skip SSO users (no password set)
        |
        v
3. Parse LASTPSWDCHANGE date and compute days since change
        |
        v
4. Categorize into severity buckets:
   CRITICAL: > 365 days since password change
   WARNING:  > 180 days
   INFO:     > staleDays threshold (default 90)
   Plus: No change date recorded
        |
        v
5. Sort each category by days since change (oldest first)
        |
        v
6. Generate Markdown report grouped by severity

Parameters

Report Output

The generated report contains:

• Header with database name, generation timestamp, and threshold parameter
• Summary with total user counts, unlocked count, and counts per severity category
• CRITICAL section (if any): Table with user ID (linked), description, last password change date, days since change, last sign-on, permission list
• WARNING section (if any): Same table format
• INFO section (if any): Same table format
• No Password Change Date section (if any): Table with user ID, description, last sign-on, permission list
• Recommendations based on which categories have findings

Interpreting Results

• CRITICAL findings require immediate action. Passwords unchanged for over a year are a significant security risk, especially if the accounts are actively used (check the Last Sign-on column).
• WARNING findings should be scheduled for remediation. These accounts are approaching a year without a password change.
• INFO findings indicate policy non-compliance. The accounts exceed your configured threshold but are not yet at the warning level.
• No Password Change Date accounts are often migrated accounts. Verify they are legitimate and consider requiring a password reset.
• SSO users (no PeopleSoft password set) are automatically excluded from this report.

Recommendations

1. Implement PeopleSoft password controls (PTPWDPOLICY) to enforce automatic password expiration. Configure under PeopleTools > Security > Password Configuration > Password Controls.
2. Investigate accounts with no password change date — these may need manual password resets.

4 - User Full Access Report

User Full Access Report

Report ID: security-user-access Category: Security Parameters: oprid (required) — the PeopleSoft User ID to audit

Purpose

This report generates a consolidated view of everything a single PeopleSoft user can access. It expands all roles and permission lists to show the full scope of a user’s security profile in one document. This is useful for security audits, access reviews, onboarding/offboarding verification, and compliance reporting.

What It Covers

The report walks the full PeopleSoft security hierarchy for the specified user:

1. User Details. Account status, authentication method, direct permission list assignments
2. Roles. All roles assigned to the user (including dynamic roles)
3. Permission Lists. Unique permission lists derived from assigned roles, with a reverse map showing which roles grant each
4. PeopleTools Access. Client tool access (Application Designer, Data Mover, etc.)
5. Menu/Component Access. All menu authorizations grouped by menu, showing components and display-only status
6. Service Operations. All authorized Integration Broker service operations
7. Component Interfaces. All authorized component interfaces
8. Process Groups. Authorized process scheduler groups
9. Query Tree / Row-Level Security. Accessible records via query tree security

Tables Queried

Data Flow

1. Fetch user details from PSOPRDEFN
        |
        v
2. Fetch all roles from PSROLEUSER
        |
        v
3. Batch-fetch permission lists for all roles
   from PSROLECLASS
        |
        v
4. Collect unique permission list ClassIDs
        |
        v
5. For ALL unique ClassIDs, fetch:
   - PeopleTools access (PSAUTHITEM special entries)
   - Menu authorizations (PSAUTHITEM + PSMENUITEM)
   - Service operation auths (PSAUTHWS)
   - Component interface auths (PSAUTHBUSCOMP)
   - Process group auths (PSAUTHPRCS)
   - Query tree access groups (SCRTY_ACC_GRP)
        |
        v
6. For query trees: walk tree hierarchy to
   resolve accessible leaf records
        |
        v
7. Generate consolidated Markdown report

How to Run

This report can be launched in two ways:

1. From the User Detail Page: Navigate to any user’s detail page and click the Run Full Access Report button in the right sidebar. The report automatically uses the current user and database.

2. From the Reports Page: Go to Reports > Run New Report > User Full Access Report. Click Go to Users to search for a user, then run it from the user’s detail page.

Report Output

The generated report contains:

• Summary table with counts for each access category
• User Details with account status, authentication, and direct permission lists
• Roles table with dynamic assignment indicators
• Permission Lists table showing which roles grant each permission list
• PeopleTools Access table showing Yes/No for each client tool
• Menu/Component Access grouped by menu name, with component links, labels, and display-only flags
• Service Operations table with operation and permission list links
• Component Interfaces table with interface and permission list links
• Process Groups table listing authorized process groups
• Query Tree tables showing accessible records with tree and access group context

All object names in the report are linked back to their detail pages in psLens for easy navigation.

Interpreting Results

• Large number of roles: Users with many roles may have accumulated access over time. Review whether all roles are still needed.
• Overlapping permission lists: Multiple roles may grant the same permission list. While not harmful, it can make access reviews harder.
• PeopleTools access: Application Designer, Data Mover, and Object Security access should be limited to developers and security administrators.
• Display-only flags: Components marked as display-only mean the user can view but not modify data through those pages.
• Process groups: Verify that users only have access to process groups relevant to their job function.

5 - Permission List Table Access Report

Permission List Table Access Report

Report ID: security-permlist-table-access Category: Security Parameters: classid (required) — the PeopleSoft Permission List (CLASSID) to audit

Purpose

This report maps a single PeopleSoft Permission List (CLASSID) to every SQL Table and View (PSRECDEFN) it grants Update or Read access to, and traces each record back to the exact sources that grant that access:

• Components & Pages (PSAUTHITEM → PSMENUITEM → PSPNLGRPDEFN / PSPNLGROUP → PSPNLFIELD with nested subpages/secondary pages expanded and subrecords resolved)
• Component Interfaces (PSAUTHBUSCOMP → PSBCITEM collections and properties)
• Query Access Trees (SCRTY_ACC_GRP → PSTREENODE leaf records)

Access Classification Rules

Only persistent SQL Tables (RECTYPE IN (0, 7)) and SQL Views (RECTYPE IN (1, 5, 6)) are included in the output. Derived/Work records (RECTYPE = 2) and unexpanded Subrecords (RECTYPE = 3) are excluded.

Component Pages

• Update + Read: Granted when all of the following hold:
  • The menu authorization is not display-only (PSAUTHITEM.DISPLAYONLY = 0)
  • The component does not disable saving (PSPNLGRPDEFN.DISABLESAVE = 0)
  • The underlying record is a SQL Table or Temporary Table (RECTYPE IN (0, 7))
  • The record has at least one editable page field (FIELDUSE & 1 = 0, excluding display-only, related display FIELDUSE & 16 != 0, static text, and visual lines) on that page or its nested subpages
• Read-Only: Granted when DISPLAYONLY = 1, DISABLESAVE = 1, the record is a SQL View (RECTYPE IN (1, 5, 6)), or all fields for that record on the page are display-only.

Component Interfaces

• Update + Read: Granted when PSAUTHBUSCOMP authorizes Save or Create (AUTHORIZEDACTIONS > 0), the underlying record is a SQL Table (RECTYPE IN (0, 7)), and PSBCITEM exposes at least one Read/Write collection or property (BCACCESS = 1, BCTYPE IN (3, 4)).
• Read-Only: Granted when the Component Interface only has read methods (Get/Find), the record is a View, or all exposed items for the record are read-only (BCACCESS = 2). Search key items (BCTYPE IN (1, 2, 5)) are excluded.

Query Access Trees

• Read-Only: All leaf records resolved from PSTREENODE via SCRTY_ACC_GRP are classified as Read-Only.

Limitations & Scope

Because this report evaluates declarative PeopleTools metadata rather than executing runtime code, keep the following scope rules in mind:

• PeopleCode & Batch SQL: Direct database reads or writes executed inside PeopleCode (SQLExec, Record.Insert/Update/Save, Application Package classes) or batch processes (PSAUTHPRCS / Application Engine) are not traced by this report.
• Component Search & Related-Display Records: Component search records (PSPNLGRPDEFN.SEARCHRECNAME / PSMENUITEM.SEARCHRECNAME) and related-display fields (FIELDUSE & 16 != 0) are excluded so the report focuses on component buffer data tables rather than lookup/prompt tables.
• Runtime Field Properties: Page fields that are marked editable in PSPNLFIELD (including invisible page fields) are counted as editable even if component PeopleCode dynamically hides or disables them at runtime (Field.DisplayOnly = True).

Tables Queried

How to Run

• From a Permission List Detail Page: Open any permission list and click Run Table Access Report in the right-hand Reports card.
• From the Run Report Page: Navigate to Reports > Security Reports, enter the Permission List name (CLASSID) in the Permission List Table Access card, and click Run Now.

6 - Dangerous Permissions Audit

Dangerous Permissions Audit Report

Report ID: security-dangerous-permissions Category: Security

Purpose

This report identifies permission lists that grant access to dangerous capabilities in PeopleSoft. Each of the eight checks is a known attack path: SOAP-to-CI lets a permission-list holder call any Component Interface without a dedicated service operation, USERPROFILES lets them mint new accounts, IB_NODE lets them point a node at attacker-controlled infrastructure. Each category is assigned a severity level (CRITICAL or HIGH) to help prioritize remediation.

What It Checks

The report audits 8 categories of dangerous access:

CRITICAL Severity

HIGH Severity

Table Queried

PSAUTHITEM — Authorization Items

Queried once per category with the specific WHERE clause for that check.

PSROLECLASS — Role/Permission List Assignments

Queried per permission list found, via GetPermissionListRoles.

PSOPRALIASTYPE / PSOPRDEFN — User Counts

Queried in batch via GetUnlockedUserCountForRoles to count unlocked users per role.

Data Flow

1. For each of 8 dangerous capability categories:
        |
        v
2. Query PSAUTHITEM with category-specific WHERE clause
   -> Extract unique permission lists (CLASSID)
        |
        v
3. For each permission list found:
   -> Fetch assigned roles via PSROLECLASS
        |
        v
4. Batch query unlocked user counts for all roles
        |
        v
5. Sort findings by total unlocked user count (descending)
        |
        v
6. Generate per-category section with severity badge,
   description, and permission list table
        |
        v
7. Generate summary and recommendations

Parameters

This report has no configurable parameters.

Report Output

The generated report contains:

• Header with database name and generation timestamp
• Per-category sections (8 total), each with:
  • Severity badge (CRITICAL or HIGH)
  • Description of the dangerous capability
  • Count of permission lists with this access
  • Table with: Permission List (linked), Roles, Unlocked User count
  • Or “No findings” if no permission lists have this access
• Summary with total categories checked and total permission lists found
• Recommendations for each category

Interpreting Results

• CRITICAL findings should be reviewed immediately. SOAP-to-CI access, user profile management, and node configuration can all be used for privilege escalation or unauthorized data access.
• HIGH findings should be scheduled for remediation. These capabilities are security-sensitive but may have legitimate use cases in limited quantities.
• Permission lists with no roles assigned may be orphaned but should still be reviewed — they could be assigned in the future.
• High unlocked user counts indicate broad exposure to the dangerous capability and should be prioritized for remediation.
• Display-only access is excluded. The report only flags non-display-only (DISPLAYONLY = 0) access for menu-based checks, so findings represent actual write/execute capability.

Recommendations

1. Remove WEBLIB_SOAPTOCI access in production environments unless absolutely required for integration — use dedicated service operations instead
2. Restrict WSDL generation to development environments only; in production, serve static WSDL files
3. Limit user profile management to a small number of designated security administrators
4. Implement change management processes for role and permission list modifications
5. Restrict purge operations to emergency use only and require approval workflows
6. Audit node configuration access regularly, as nodes contain authentication credentials

7 - SOAP to CI Access Audit

SOAP to Component Interface Access Audit Report

Report ID: security-soap-to-ci-access Category: Security

Purpose

“SOAP to CI” is a powerful tool that allows using excel or any web client to interact with PeopleSoft Component Interfaces via SOAP web services. However, this capability also introduces significant security risks if not properly controlled, as it can allow users to programmatically read or write data in the application database. The number of users with access to this WebLib should be tightly controlled and regularly audited.

The SOAP to Component Interface Access Audit report identifies all PeopleSoft users (OPRIDs) who have access to the SOAP-to-CI WebLib (WEBLIB_SOAPTOCI). This WebLib allows programmatic data loading into PeopleSoft using standard Component Interface Web Services (acting as the endpoint for Excel-to-CI and custom integrations like psDataLoader).

For each identified user, the report details:

1. The security paths (Roles and Permission Lists) granting WebLib access.
2. The specific Component Interfaces they are authorized to access and execute, and which Roles and Permission Lists grant that CI access.

This report is critical for security audits to ensure that only authorized integration accounts or administrators possess programmatic write access to the application database.

Tables Queried

PSAUTHITEM — WebLib Authorizations

Used to find permission lists that grant access to WEBLIB_SOAPTOCI.

PSROLECLASS — Role to Permission List Mapping

Used to trace permission lists back to roles.

PSROLEUSER — User to Role Mapping

Used to identify users assigned to the roles that grant Weblib access, and to map all roles assigned to those users.

PSOPRDEFN — Operator Definitions

Used to identify users who get direct access via their Primary Permission List (OPRCLASS), and to retrieve user account lock status and descriptions.

PSAUTHBUSCOMP — Component Interface Authorizations

Used to trace all Component Interface authorizations for the permission lists assigned to the identified users.

Data Flow

1. Query PSAUTHITEM to find all permission lists (CLASSID) authorizing WEBLIB_SOAPTOCI
        |
        v
2. Query PSROLECLASS to trace those permission lists back to Roles
        |
        v
3. Query PSROLEUSER and PSOPRDEFN to identify all users (OPRID) with:
   - Assignment to those Roles
   - Direct Primary Permission List (OPRCLASS) granting access
        |
        v
4. Fetch user details (description, lock status) for all identified users
        |
        v
5. Fetch all Roles and Permission Lists assigned to those users
        |
        v
6. Fetch all Component Interface (CI) authorizations (PSAUTHBUSCOMP) for those permission lists
        |
        v
7. For each user, map their SOAP-to-CI access paths and all authorized Component Interfaces
        |
        v
8. Sort users (active first, then by ID) and generate the Markdown report

Parameters

This report has no configurable parameters.

Report Output

The generated report contains:

• Header with database name and generation timestamp.
• Summary statistics (total users, active vs. locked, unique roles, unique permission lists).
• WebLib Access Path Summary Table listing each Role-Permission List pair granting SOAP-to-CI access and the number of active users with that assignment.
• User Access Details Section detailing each user:
  • User ID (linked to detail page) and Description.
  • Account lock status (Active/Unlocked vs. Locked 🔒).
  • Explicit Weblib Authorization Paths (Roles and Permission Lists granting Weblib access).
  • A table of Accessible Component Interfaces detailing which Role and Permission List grants access to each specific Component Interface.
• Remediation Recommendations to secure your environments.

Interpreting Results

• Unlocked users with SOAP-to-CI access must be verified. Programmatic SOAP-to-CI access should be reserved for integration service accounts or system administrators. Standard business users should not have access to this WebLib.
• Active users with no Component Interface access have WebLib access but cannot interact with any business objects. While they present less immediate risk, their WebLib access should still be revoked to adhere to the principle of least privilege.
• Locked users are flagged with Locked 🔒. While they cannot authenticate, their security definitions should still be cleaned up if their access is no longer required.
• Primary Permission List grants (indicated by Primary Permission List instead of a Role) should be avoided. Best practice is to assign Weblib access through Roles.

Recommendations

1. Restrict WEBLIB_SOAPTOCI: Remove this WebLib access from any roles assigned to standard business users. Ensure it is only assigned to dedicated integration/service accounts.
2. Implement Least Privilege for CIs: Verify that service accounts only have access to the specific Component Interfaces (CIs) required for their integration. Remove broad or administrative permission lists that grant access to unnecessary CIs.
3. Lock Stale Accounts: Ensure that any old, inactive, or deprecated integration accounts are explicitly locked in PSOPRDEFN.

8 - SSO Bypass Password Audit

SSO Bypass Password Audit

Report ID: security-sso-password-audit Category: Security

This page documents the SSO Bypass Password Audit report, which identifies native PeopleSoft user passwords stored in the PSOPRDEFN table.

Purpose

Environments using Single Sign-On (SSO) should not store native passwords in the PeopleSoft database. If PSOPRDEFN passwords exist, users can bypass SSO controls—including Multi-Factor Authentication (MFA)—by accessing PeopleSoft backdoor login paths (such as ?cmd=login query parameters or web service endpoints).

To prevent backdoor access, the fields OPERPSWD, PTOPERPSWDV2, and OPERPSWDSALT must be cleared to a single space, since PeopleSoft does not support database nulls.

Important: There are types of users that need to maintain their PeopleSoft password for various reasons that this report will flag.

• Anyone who needs 2-tier PeopleTools Access
  • Developers
  • Administrators
• Special Accounts
  • App Server Accounts
  • API User Accounts for External Integrations
  • SOAP-to-CI Users (maybe)

For any accounts that you know should have a password, you can enter rolename for accounts to avoid. One idea here is to create a new role like X_CAN_HAVE_PS_PASSWORD (replace X_ With your desired prefix) so you can clearly mark these special users and everyone else should have their passwords cleared.

What It Detects

The report checks the PSOPRDEFN table for any row where OPERPSWD, PTOPERPSWDV2, or OPERPSWDSALT is not a single space. Results are grouped into two sections based on account status:

1. Active Users with Local Passwords: High risk. These accounts can be logged into directly.
2. Locked Users with Local Passwords: Low risk. These accounts are locked, but their passwords should still be cleared.

Table Queried

PSOPRDEFN

The primary table containing PeopleSoft operator definitions.

PSROLEDEFN

Used to validate that the entered excluded roles are real roles.

PSROLEUSER

Used via a subquery to exclude users assigned to the specified excluded roles.

Data Flow

1. If excludeRoles is provided, validate each role against PSROLEDEFN
    |
    v
2. Query PSOPRDEFN for rows where OPERPSWD, PTOPERPSWDV2, or OPERPSWDSALT is not ' ' (filtering out users assigned to excluded roles via a PSROLEUSER subquery)
    |
    v
3. Segment users based on ACCTLOCK (0 = Active, 1 = Locked)
    |
    v
4. Compile a bulk SQL update script containing individual UPDATE statements for all affected users

Report Output

The report outputs:

• A summary of active and locked users containing passwords.
• Tables listing the user ID, description, last sign-on date, and active password fields.
• A bulk remediation SQL script with individual update queries.

Parameters

• excludeRoles: Comma-separated list of role names to exclude from the audit (optional). If specified, any user assigned to any of these roles is excluded from the report. The report validates that all entered role names exist in PSROLEDEFN.

9 - PeopleTools Access Audit

PeopleTools Access Audit Report

Report ID: security-peopletools-access Category: Security Default Parameter: activeOnly = false

Purpose

Special PeopleTools access (Application Designer, Data Mover, Object Security, Query, Import Manager, 2-Tier Client) is granted on the PeopleTools tab of a permission list and recorded in PSAUTHITEM. This report lists every user who holds any of that access and the path that grants it: permission list to role to user.

What It Detects

For each PeopleTools application, the permission lists that grant it, the roles that carry those permission lists, and the users in those roles. Each grant is marked Full (edit) or Read-only based on PSAUTHITEM.DISPLAYONLY. Each user is marked Active or Locked from PSOPRDEFN.ACCTLOCK.

The tools tracked are the MENUNAME values PeopleSoft uses for standalone tools access:

• APPLICATION_DESIGNER — Application Designer
• OBJECT_SECURITY — Object Security (Definition Security tool)
• DATA_MOVER — Data Mover
• IMPORT_MANAGER — Import Manager
• QUERY — Query
• CLIENTPROCESS — 2-Tier Client

Tables Queried

• PSCLASSDEFN — permission list names and descriptions.
• PSAUTHITEM — tools access grants (MENUNAME, DISPLAYONLY).
• PSROLECLASS — which roles include each permission list.
• PSROLEUSER — which users hold each role.
• PSOPRDEFN — account lock status (ACCTLOCK) and primary permission list (OPRCLASS).
• PSOPROBJ — Definition Security grants: permission list to object group, with DISPLAYONLY (edit vs read-only).
• PSOBJGROUP — object group membership (which definitions belong to a custom group).

Report Output

Four sections:

1. Summary — count of permission lists and distinct users per tool, plus the total number of users with any special access.
2. Access by Tool — each tool with its permission lists (Full or Read-only), descriptions, and the roles that carry them.
3. Access by User — every in-scope user with their account status, the tools they hold and at what level, a Def. Security column (can they edit definitions), and the permission lists and roles that grant them.
4. Definition Security (Object Security) — object group grants (PSOPROBJ): which permission lists can edit or read the definitions in each object group, and which users that reaches via primary permission list and roles.

Permission lists, roles, and users link back to their psLens detail pages.

Parameters

Interpreting Results

• Full vs Read-only. Read-only Application Designer access can open and inspect definitions but not save changes. Full access can modify them. Treat Full access in a production database as the higher risk.
• Locked users. Locked accounts still hold the grant. They appear so you can audit dormant access that would return if the account is unlocked. Set activeOnly = true to hide them.
• Object Security. Access to the Object Security tool lets a user change Definition Security itself, which governs which definitions developers can edit.

Definition Security details

Holding Application Designer access lets a developer open the tool. What definitions they can edit is controlled by Definition Security object groups (PSOBJGROUP) linked to permission lists through PSOPROBJ. The DISPLAYONLY flag on that link is the difference between read-only and edit access.

The delivered PEOPLETOOLS object group holds the system definitions and is read-only by default. An Edit grant on it (DISPLAYONLY = 0) means the permission list can modify delivered PeopleTools objects in Application Designer — a high-privilege grant worth auditing.

The report applies these grants to users through both their primary permission list (PSOPRDEFN.OPRCLASS) and their roles, and labels which path reaches each user. Permission-list-level grants are reported exactly from PSOPROBJ; the user roster is the set reached through those permission lists.