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.
## 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.
| Field | Description | Values |
| -------------- | -------------------------- | -------------------------- |
| OPRID | User ID (primary key) | |
| OPRDEFNDESC | User description | |
| ACCTLOCK | Account lock status | `1` = Locked, `0` = Active |
| LASTSIGNONDTTM | Last sign-on date and time | |
| OPERPSWD | Legacy password hash | |
| PTOPERPSWDV2 | Password hash (V2) | |
| OPERPSWDSALT | Password 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
```text
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`.