I never really worked on a machine with a securiy level > 30, but i do have experiences with security problems on several machines, customers did install software on machines with seclvl 40 and no addnl. problems occurred.

Before you do anything, read OS/400 Security from cover to cover.

If all of your users have *ALLOBJ authority, you can go to security level 30 without the risk of being inoperable. After the necessary IPL, set rights for the objects on your machine.

Then create new user profiles for every kind of user, e.g. TESTMGR, TESTUSER, ... These users should not have any unnecessary special authority. Then try to perform all tasks you want the user to do (and those you do not want them to do!). Don't forget to test your backup operations! If you need more authority for a certain task, change the programs to run with the security of the owner and change the owner of the program. Do not offer command lines in these programs!

Then you can change your existing user profiles.
I think that this is the most effortless way to achieve at least a minimum level of security. Be careful, take enough time for this.

And check terminals and PC's for recorded Sign Ons. Many users do this, many others do know this. Your effort in securing your machine is useless, when users write down their passwords. But they will, if you force them to change passwords too often. (Look under the keyboard, too!)

A sealed envelope with QSECOFR-password is also a good idea. So you can leave the company for holidays...

Hope you find these thougts useful…

---

This is *NOT* true! At security level 20 all users have *ALLOBJ special authority, but it will be removed after changing to 30 or above.

---

We just went through this in preparation for upgrading to a RISC box, which comes in at a default sec level of 40. our strategy was simple, and i'll give the basics here. the whole episode is made easier by the fact that a lot of our programs have built in security/access checks (does user A have access to B) and our CASE tool (LANSA) takes care of a variety of security issues on its own, but...we created a (disabled) group profile MAOWN which had limited authority, and assigned everyone to it. then we went through all of the objects on the system and changed its authority to PUBLIC *USE and MAOWN *ALL. we then set up all our programs to use adopted authority (USEADPAUT). the one snakey area we had was in our old system 36 stuff. however, since we had a CLP wrapped around it (we accessed them through softmenu) the authority stack was in place already. we weren'tsure that it would work, but we are at level 30 now and have startedturning folks over to level 40 without any problems.

---

Well, at level 20 you really don't need *ALLOBJ special auth for accessing objects.

Next, unless you have a good reason for it, level 30 is normally suficient : It enforces object level permissions which is, I imagine, what you want.

Anyway, that change is a serious issue, and rather than a pure AS/400 technical question, your problem is to determine the exact security requirements of your (legacy) software. See: if some user comes out not having access to, say, a printer queue, he won't be able to manage it's spool files, but thats not great trouble : the output will be still there & you may correct it in a breeze. But consider what can happen if an autorization vilolation occurs in a deeply nested proccess, which is, to make it worse, not immediatly undoable, and on which (to make it even worse) depends crucial information flow of your company. Nice, hu? So the real glitch will be in your applications. And, security schemes for vertical applications are normaly far from simple. There surely are objects which need to be shared by different users in different areas, and sometimes in subtle an unexpected ways.

One advice : plan it carefully, and whith COMPLETE knowledge of your applications requirements. This may be tricky, because if your apps have lived 5 years with zero concern for security, it is probably because its builders didn´t foresee for that in any way. If this is the case, better try the simplest scheme possible. Try it out fore some days with a test library. And, of course, don't go out on vacation the day after changing QSECLEVEL.

---