Security

• 1: Full Access Permission Lists
• 2: Nodes with No Password
• 3: Stale Password Audit
• 4: User Full Access Report
• 5: Dangerous Permissions 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

1. Immediately configure authentication on active nodes with AUTHOPTN='N'
2. Set AUTHOPTN to P (Password) or C (Certificate) and configure credentials
3. Set internal or external passwords on nodes that have auth enabled but no credentials

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. Enter the OPRID manually.

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 - 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