SSO Bypass Password Audit

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.
Tailored Operational Context
  • Target Database:
  • Context Type:
  • Alert Severity:
  • Triggered Time:
  • Firing Context:

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.

FieldDescriptionValues
OPRIDUser ID (primary key)
OPRDEFNDESCUser description
ACCTLOCKAccount lock status1 = Locked, 0 = Active
LASTSIGNONDTTMLast sign-on date and time
OPERPSWDLegacy password hash
PTOPERPSWDV2Password hash (V2)
OPERPSWDSALTPassword salt

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.