View Full Version : IBM default passworkds
01-01-1995, 02:00 AM
I just started a new job and since the last person was terminated, the Pres. wants ALL the passwords changed. Can I just change the IBM supplied profiles to a new password? I thought I could not do this for those. I asked one of our consultants and he didn't know either. TIA Cheri
12-14-2000, 08:47 AM
Cheri, Of course you can change the default passwords. In fact, if they have not been changed and you allow dial-up or internet communication, your system is wide open. Most of your defaults can be changed to *NONE so they can't be signed on. Of course there are some like the server profiles that must be enabled, but can have their password changed. One of the most reliable ways of knocking out outside communications is to dial into the system, attempt to sign on as QSRV or other service profile. Even if you don't get the password correct, you can keep trying and hope that you disable the profile after too many incorrect signon attempts. I suggest that you write a CL to read each user profile, set the default password to the user profile with the password expired. This will force everybody to set up a new password. -bret P.S. Cheri, look at the book store on the MC homepage. There is a book by Wayne O Evans called AS/400 security. I just purchased it to keep up to date. The best part? It's only 15 dollars for the time being. Here is the link to the book. http://www.mc-store.com/mc-store/wayoevonasse.html
12-14-2000, 08:49 AM
Cheri, If you use a profile with *SecAdm authority, it can change anyone it wants. If you would like to do this quickly, I would suggest doing a WrkUsrPrf *all. You can then put a 2 in front of every profile and on the command line put PwdExp(*Yes) . This will set every profile's password to an expired status and this results in everyone needing to change their password at the next signon (note: You may run into trouble trying to start PC connections with expired profiles). You can then modify the Q* profile however you wish. You might do a WrkUsrPrf Q*; then put a 2 in front of every profile and on the command line put Password(*None). This will disallow signing on for this profile. You would probably then want to go to specific profiles and give them other passwords (QSecOfr, QSrv, etc.) Bill
12-14-2000, 04:04 PM
Bill, A minor correction... you need *SECADM and *ALLOBJ to change everybody's user-id. *SECADM alone does not guarantee you can modify everybody's user-id, specially for user-ids created using another administrator's id.
12-14-2000, 04:30 PM
Cheri, For purposes of security, you should change all user passwords to *NONE. Do this also for QSYSOPR, QPGMR, QUSER, QSRV, and QSRVBAS. You should also change the passwords for QSECOFR and DST. Is this safe to do? In most cases, probably "yes". But only you can answer that question with certainty. You have to dig through all your application program code to see if there are hard-coded user-ids and passwords.
12-15-2000, 05:23 AM
Cheri - Personally, I like the idea of changing QSECOFR's password AND DISABLING the user profile. This prevents QSECOFR from being using anywhere except the system console (you can always sign on from the console using QSECOFR). HTH, Steve
12-15-2000, 05:30 AM
If you use QSECOFR to crate the program and have it adopt the owner authority then you won't have to worry about the authority of the profile you use to run it.
12-15-2000, 05:32 AM
If you are FTP'n to the AS/400 you also have to check any code that is being used on other machines.
12-15-2000, 05:44 AM
On other thing to look at. Under Security Tools there is an option to analyze default passwords. This function will list all the profiles that have the passwords as the signon.
12-15-2000, 05:47 AM
Cheri, I agree with Steve's suggestion here. I had forgotten about that. I have QSECOFR, QSECADM, QSYSOPR set to *none and *disabled. I created a profile with SECOFR authority for when I need to sign on and do something that only QSECOFR could do. This really is not much, and when I do software installs or updates, I still do it from the console under QSECOFR for continuity. -bret
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.