ToddN2000 Jul 18, 2012   7:30 PM GMT

I feel your pain. We had that happen here not to long ago.. The password was changed just befor a long holiday weekend and nobody remember it before it was disabled. We had no other user profile with SECADM rights. The solution was to have IBM come in and work their magic. It took hours but we did get it back and we now have a backdoor setup just in case with the password stored in our vault.

129,715 pointsBadges:

TomLiotta Jul 18, 2012   10:43 PM GMT

My QSECOFR Profile has been disabled...In general, you should simply sign on with your usual *SECOFR profile and re-enable QSECOFR. Then again, QSECOFR possibly should be *DISABLED at all normal times since no one should be signing on with it except maybe once or twice a year. (Why not? To avoid this question's issue for the most common reason, but more significant security issues are involved.)   For almost every AS/400, the first thing that should be done when it's first brought up is to create a local *SECOFR profile to do all general security officer work. Second thing is to change all default passwords. From then on, the only times you should be signing on with QSECOFR is because you are following IBM directions that say "Sign on as QSECOFR." There are no other reasons that require it.   The QSECOFR *USRPRF can issue the CHGDSTPWD command to set the QSECOFR SST/DST profile password to the default value. Any *SECOFR *USRPRF can set the QSECOFR *USRPRF password to any valid value.   But if (1) you can't use the QSECOFR *USRPRF, and (2) you can't use the QSECOFR SST/DST profile, and (3) you don't have another *SECOFR *USRPRF, and (4) you don't have another SST/DST profile with security capabilities, then... you probably will need to pay IBM to do the work.   Tom

125,585 pointsBadges:

Dinnu Jul 19, 2012   5:03 AM GMT

There two default profiles for SST along with QSECOFR Try to use 11111111 or 22222222 as user I'd as well as password This should work

360 pointsBadges:

TomLiotta Jul 19, 2012   6:45 AM GMT

Try to use 11111111 or 22222222...   Neither of those should work, though 22222222 might. Both of those should have non-default passwords and so will need to be known.   11111111 in particular shouldn't have sufficient authority, though 22222222 might if it can be accessed. QSRV is another possibility that would have enough authority.   But if DST/SST password was changed for QSECOFR, those should have been changed at the same time. If they weren't, there wasn't much point in changing QSECOFR.   Maybe it's worth pointing out that QSECOFR default DST/SST password is QSECOFR and must be entered upper-case. Maybe it wasn't forgotten as much as never known.   Tom

125,585 pointsBadges:

qmaster Jul 19, 2012   10:44 AM GMT

Thanks Tom,It worked.

1,675 pointsBadges:

TomLiotta Jul 19, 2012   9:06 PM GMT

Thanks Tom,It worked.   What worked?   I hope it's understood that if anything in this thread worked, it means that there was essentially no security on the system at all. Within the scope of the question, you were very lucky. But there is no guarantee of the integrity of anything on the system until none of the suggestions in this thread will work (other than creating a secondary *SECOFR and a secondary DST/SST profile and keeping those secure along with secure default profiles of both types).   Tom

125,585 pointsBadges:

qmaster Jul 20, 2012   4:17 AM GMT

I did like below..login as  QSECOFR...run CHGDSTPWD *DEFAULT...Opened my HMC Console and opened HMC Interface too..  to force DST to console...and tried QSECOFR as ID and pwd as QSECOFR and system asked me to change the password..i did it..then back to normal session for STRSST and tried with new password for QSECOFR ...thats way itworked....In your last thread ,You mentioned that DST Profile...What does it mean..do we've any USRIDs for DST login as well...so far i'm in belief that SST ID will be used to login for DST screens...and that is what my above writing telling to me ....?

1,675 pointsBadges:

TomLiotta Jul 21, 2012   4:00 AM GMT

This started off with this:   My QSECOFR Profile has been disabled after couple of wrong attempts with in correct password.Now,I forgot what actually the password is …   So how did you manage this part?   I did like below..login as  QSECOFR…run CHGDSTPWD *DEFAULT…   If we knew you could log in to QSECOFR, it would have been easy.   In your last thread ,You mentioned that DST Profile…What does it mean..   Log in DST (or SST), take option 8: 'Work with service tools user IDs and Devices' and look over those options. Then go back to the main SST menu and review option 7: 'Work with system security'. Both of those areas will give you an idea of what's available.   After you see what's in there, you might come back here to ask detail questions.   Tom

125,585 pointsBadges: