User profiles are such a wonderful and flexible part of the IBMi operating system. Group profiles, Security levels, authorization lists…. good stuff:
Managing User Profiles
Question I am having a problem with user profiles disabling randomly.
Answer 1. It sounds like someone has used the Security Toolkit to activate the “automatically disable inactive profiles” option. That’s not really it’s name. It’s name is “Analyze Profile Activity” on the menu option, which sounds benign enough, but in fact it will initiate this scheduled auto-disable.
From the Security Toolkit (GO SECTOOLS) choose option 4 (ANZPRFACT) and set the number of days to *NOMAX. This will prevent any profile from being automatically disabled by this new feature.
Alternately, you could leave the auto-disable at 90 days, and then use options 2 & 3 on that same menu to exclude certain profiles from being disabled.
Answer 2. When you use ANZPRFACT command for the first time it creates an entry in the job scheduler to run weekly. Just delete the job from the job scheduler. I don’t know what problems you are having with the command. But I had a problem with the command under V3R2 for new profiles. If the user profiles weren’t use they would get disabled. I called IBM support line and I installed a PTF that would look at the last used date and the creation date of the object.
Answer 3. Check QSYSOPR messages for if users are signing on wrong more than X number of times. The system value QMAXSIGN and QMAXSGNACN for when this happens….they may be set to disable your user profiles. You would also get a msg in QSYSOPR msgs if this happens.
Question: I would like to create a program to change group profiles on the fly. The idea is to create a generic menu that will allow a user to have one user profile and password but be able to get into different softwares. 1- BPCS 2- Payroll, each software requires a different library list and different group profile. I thought I could just do a chgjobd for the job description to pick up the new library list (?), but how can I change the group profile?
Answer 1. You might look at QWTSETP API to change effective user profile for the job. You will have two user profiles and switch between them under the covers. Of course, this will require additional password maintenance.
You can find API’s descriptions in a set of API books. Books can be found either on softcopy library CD or directly from IBM online library http://as400bks.rochester.ibm.com/. Look for a bookshelf named “Systems Programming Support Bookshelf“. This particular API is in the book “ OS/400 Security APIs“.
Answer 2. Changing the Group Profile attribute for a User’s Profile requires *SECADM special authority. It would be possible to have your menu program call a program, that would run under owner authority and be owned by a profile with *SECADM authority, that could change the User’s Group Profile. But I wouldn’t do it.
CHGJOBD is not used to change a user’s library list, it is used to change the attributes of a JOBD.
I would break your problem into it’s two parts: For the LIBL, each menu option needs to do it’s own CHGLIBL to set up it’s needed LIBL. If you want to be more polished, before the CHGLIBL do a RTVJOBA USRLIBL(&LIBL) and store it in a DTAARA in QTEMP so you can put it back the way it was when the user comes out of the menu option.
For the Group Profiles, I would challenge why and how they are being used. With BPCS, if you have a Group Profile called maybe SSA that everyone belongs to and it has complete access to data files, then from a security perspective you are very vulnerable to any non-BPCS interfaces, i.e.. ODBC, FTP, data-transfer, etc. I would recommend looking at implementing Object/Resource control with programs adopting authority to control data access. Then most users don’t need to belong to any groups. That said, another area you may want to look at is Supplemental Groups. You can now set up a profile so that it gets group authority to objects from more than one group.
Answer 3. CHGJOBD will not change the library list on the fly. The user would have to signoff and signon again for the change to take effect. The simplest way to change library lists would probably be to use the CHGLIBL command from a CL program associated with the menu options.
As for changing the group profile, the CHGUSRPRF command would do it, but I think that too would only take effect after signing off and signing back on. I would look into having one group profile for all software packages.
Question: I notice that IBM recommends that the QSECOFR and QSYSOPR profiles not
be used. They instead recommend creation of alternate profiles for
I don’t really know the reasoning behind using a different profile instead the system supplied ones. Anyone know why?
Answer: This protects against someone guessing user IDs and passwords. Using a profile with a different username means one more thing for a hacker to guess. As always, pay close attention to which special authorities are actually needed by users, and audit those with certain ones – secadm/allobj especially.
Question: Is it possible to look up an AS400 user’s password within the system? Any input on this will be appreciated. Thank you. (6/2000)
Answer 1: Essentially no. There are some hackers who claim to crack AS/400 passwords with brute force, but the risk of this kind of attack will always exist, unless IBM extends the character set or length of passwords in the future.
Answer 2: Passwords are stored on the AS/400 in encrypted form. There is an API to retrieve the encrypted password. The encryption method is DES. Due to the limited character set allowed in passwords, the password can be decrypted on a modern PC in a few hours.
BTW: if you apply any or all of the rules for passwords controlled by the QPWD* system values, you make the decryption easier as you diminish the key space. A long password is not more secure than a short password. What I really mean to say, though, is that since the password is encrypted in pieces, it is the size of the largest piece (7 characters) that determines the time. The 8th, 9th, and 10th characters are part of the last piece (only 3 long – so decrypts in seconds)).
A 7-character piece only takes a couple of hours on average.
Answer 3: Just a few days ago, a 17-line RPG-IV program was posted to MI400-L that sniffs user IDs and passwords as they sign on to the system. I tried it, it works. I understand that it works at security level 30 and below and for user classes that 95% of the AS/400 shops out there use. From what I can tell, the author has managed to get this to work at level 40 with the same features as the code published the other day and at level 50 with the program changed to a system state program.
The signon program reads a screen buffer with your user ID and password you just typed. The contents of that buffer hangs around until signoff or another signon (when it will contain yet another password !). A general principle of secure working is the erase the contents of all buffers and variables as soon asthey are no longer needed. IBM violated that simple principle.
This is real, folks. Any programmer in your shop can do this. With a 17-line RPG-IV program! I remember the flap awhile ago with the brute force password cracker; too much trouble and too prone to being discovered. But this monster appears to give me all the anonymity I need. A little patience to sniff out all the ID’s & passwords and, with any luck, get the QSECOFR or any other UserID with security officer privileges.
Question: Is there a solution for the password sniffing problem just mentioned? (6/9/2000)
Answer: IBM is working on a solution to the password sniffing problem. PTFs should be available soon for all supported releases. For product 5769SS1 (OS/400), the V4R3 PTF number is SF62894, the V4R4 PTF is SF62895, and the V4R5 PTF is SF62896.
After you apply the PTF for your system you will need to activate it by terminating and then restarting all subsystems that perform interactive work. Doing an IPL is one way to do this. Since your passwords may have been compromised, after applying and activating the fix, you may wish to change the passwords on your systems.
Subsystem monitor jobs use a single open for each 250 or so display devices. So for example, if the subsystem supports 600 display devices, there will be three opens and three input/output buffers. Each buffer is used for the sign-on screens for only one set of devices.
The fix provided by the PTFs is to blank out the password in the buffer immediately after it is read into a local variable. The program that does this already blanked out its local variables when it was done verifying the users sign-on password. Not blanking out the password in the input buffer was an oversight. I will not try to offer an excuse for why the developer missed this. (I am not that developer.)