How to Change the SYSADM Password in PeopleSoft: Complete Step-by-Step Guide
A complete walkthrough for changing the SYSADM (Access ID) password in PeopleSoft — covering why it must be done through Data Mover, how PSACCESSPRFL works, the exact commands for Oracle and SQL Server, and everything you need to update afterwards to keep your environment running.
PSACCESSPRFL go out of sync, nobody will be able to log in. Always follow the full process described in this guide.
📋 Table of Contents
- What Is the SYSADM Account?
- How PeopleSoft Stores & Uses the SYSADM Password
- Prerequisites & Pre-Change Checklist
- Step-by-Step: Change SYSADM Password (Oracle DB)
- Step-by-Step: Change SA Password (SQL Server)
- PeopleTools 8.55+ Changes (PSACCESSPROFILE Table)
- What to Update After Changing the Password
- Verifying the Change Was Successful
- Troubleshooting — When Things Go Wrong
- Frequently Asked Questions
What Is the SYSADM Account?
SYSADM is the Oracle database schema owner for PeopleSoft. It is the database-level user that owns all PeopleSoft tables, indexes, views, and sequences. When the Application Server, Process Scheduler, and Data Mover connect to the database to read or write PeopleSoft data, they ultimately connect as SYSADM (or through an Access ID that maps to SYSADM).
This is different from PeopleSoft user accounts (like PS, VP1, or any named user) which are stored in PSOPRDEFN. SYSADM is an Oracle database account, not a PeopleSoft operator.
| Account | Platform | Role |
|---|---|---|
| SYSADM | Oracle DB | Schema owner of all PeopleSoft objects. Access ID used by all PeopleSoft processes. |
| SA | Microsoft SQL Server | Equivalent of SYSADM for MSSQL environments. Same concepts apply. |
| people | Oracle DB | Connect ID — used by PeopleSoft to establish the initial DB connection before switching to SYSADM. Has SELECT on PSSTATUS, PSOPRDEFN, PSACCESSPRFL only. |
| SYSADM1 | Oracle DB | The default Symbolic ID — a logical name in PeopleSoft that maps to the SYSADM Access ID. Stored in PSACCESSPRFL / PSACCESSPROFILE. |
How PeopleSoft Stores & Uses the SYSADM Password
Understanding this mechanism is what separates an admin who does this safely from one who locks everyone out. PeopleSoft’s access model works through three linked layers:
PSOPRDEFN (OPRID)
SYSADM1
ACCESSID + ACCESSPSWD (encrypted)
SYSADM account
Figure 1: How PeopleSoft maps a user login to the SYSADM database account
Every PeopleSoft operator (user) is assigned a Symbolic ID (e.g., SYSADM1). That Symbolic ID maps to an Access ID and Access Password stored encrypted in PSACCESSPRFL (or PSACCESSPROFILE for PT 8.55+). When someone logs in, PeopleSoft decrypts the Access Password and uses it to connect to Oracle as SYSADM.
The encryption of the Access Password uses SYSADM’s database password as part of the key. This is why both the Oracle password and the PSACCESSPRFL record must be changed together — if they diverge, the decrypted password won’t match Oracle’s password and every login will fail with an ORA-01017: invalid username/password error.
PSACCESSPRFL.PT 8.55 and later: A new table
PSACCESSPROFILE is used instead. The CHANGE_ACCESS_PASSWORD command in Data Mover handles both tables automatically — but if you use SQL directly, you must know which table applies to your PeopleTools version.
Prerequisites & Pre-Change Checklist
Step-by-Step: Change SYSADM Password (Oracle Database)
Follow these steps exactly and in order. Do not skip or reorder them.
Step-by-Step: Change SA Password (SQL Server)
For Microsoft SQL Server environments, the schema owner account is SA (or a custom account if your installation used one). The process is identical in concept but uses MSSQL syntax:
PeopleTools 8.55+ Changes (PSACCESSPROFILE Table)
Starting with PeopleTools 8.55, Oracle introduced a new table called PSACCESSPROFILE to store Access ID information, replacing the older PSACCESSPRFL. If you run CHANGE_ACCESS_PASSWORD through Data Mover, it handles both tables automatically — no manual SQL needed.
However, if you ever need to reset the Access ID manually via SQL (for example, if Data Mover won’t start because passwords are already corrupted), use this approach for PT 8.55+:
-- Reset PSACCESSPROFILE to known state (PT 8.55+)
-- Run as SYS or SYSADM in SQL*Plus BEFORE running ENCRYPT_PASSWORD in Data Mover
UPDATE SYSADM.PSACCESSPROFILE
SET STM_ACCESS_ID = 'SYSADM',
SYMBOLICID = 'SYSADM1',
STM_ACCESS_PSWD = 'new_password', -- plain text — will be encrypted by ENCRYPT_PASSWORD
VERSION = 1,
ENCRYPTED = 0
WHERE SYMBOLICID = 'SYSADM1';
COMMIT;
-- Also reset the older table for compatibility
UPDATE SYSADM.PSACCESSPRFL
SET ACCESSID = 'SYSADM',
SYMBOLICID = 'SYSADM1',
ACCESSPSWD = 'new_password', -- plain text — will be encrypted
VERSION = 0,
ENCRYPTED = 0
WHERE SYMBOLICID = 'SYSADM1';
COMMIT;
ENCRYPT_PASSWORD *; to encrypt the plain-text passwords you just wrote. Leaving passwords unencrypted in the database is a serious security risk.
What to Update After Changing the Password
The Data Mover step updates the database record. But several other configuration files still store the old password in encrypted form. You must update all of them before restarting your domains.
Complete Update Checklist
| Component | How to Update | Required? |
|---|---|---|
| Oracle DB (SYSADM user) | ALTER USER SYSADM IDENTIFIED BY new_pwd | 🔴 Yes — Step 1 |
| PSACCESSPRFL / PSACCESSPROFILE | Data Mover: CHANGE_ACCESS_PASSWORD | 🔴 Yes — Step 2 |
| psappsrv.cfg (App Server) | psadmin -c configure -d <domain> | 🔴 Yes |
| psprcs.cfg (Process Scheduler) | psadmin -p configure -d <domain> | 🔴 Yes |
| Configuration Manager (pscfg.exe) | Update profile Access Password field manually | 🟡 If using 2-tier |
| integrationGateway.properties | Edit file and re-encrypt via gateway admin page | 🟡 Check if applicable |
Verifying the Change Was Successful
After completing all steps and updating all config files, restart your domains and verify:
- Start Application Server —
psadmin -c start -d APPDOM— check logs for “Connected to database” message, no ORA-01017 errors - Start Process Scheduler —
psadmin -p start -d PRCSDOM— verify PSPRCSRV connects successfully - Start Web Server —
psadmin -w start -d peoplesoft - Log into PIA — Navigate to your PeopleSoft URL and log in as a regular user (e.g., PS or VP1). A successful login confirms the encryption is correct.
- Run a test process — Submit a simple Application Engine or SQR process through Process Monitor and confirm it runs to Success.
- Verify in SQL*Plus — Connect as SYSADM with the new password from SQL*Plus to confirm the database-level change is correct:
sqlplus SYSADM/new_password@TNS_ALIAS
Troubleshooting — When Things Go Wrong
If you cannot start Data Mover in Bootstrap mode because the passwords are completely out of sync, reset the PSACCESSPRFL table manually via SQL*Plus as SYS, setting passwords to plain text (ENCRYPTED=0), then immediately log into Data Mover and run ENCRYPT_PASSWORD *:
-- Run as SYS in SQL*Plus UPDATE SYSADM.PSACCESSPRFL SET ACCESSID='SYSADM', ACCESSPSWD='new_password', VERSION=0, ENCRYPTED=0 WHERE SYMBOLICID='SYSADM1'; COMMIT; -- For PT 8.55+ UPDATE SYSADM.PSACCESSPROFILE SET STM_ACCESS_ID='SYSADM', STM_ACCESS_PSWD='new_password', VERSION=1, ENCRYPTED=0 WHERE SYMBOLICID='SYSADM1'; COMMIT; -- Then immediately open Data Mover Bootstrap mode and run: -- ENCRYPT_PASSWORD *;
Frequently Asked Questions
Master PeopleSoft Security & Administration
Learn password management, security configuration, Data Mover scripting, and all critical admin tasks with hands-on lab access and expert-led instruction from corporate professionals.
