Stopping User from Using the System Request Menu
March 19, 2008 Hey, Joe
|
We have some users who misuse the System Request menu by locking critical records and then transferring to an alternate job. They also sometimes use System Request-2 to cancel their previous requests when they should let those requests run straight through to completion. We’d like to restrict access to the System Request menu just for those users. How can I lock them out? –Bert There have always been some security and processing issues with allowing everyone to access the System i and AS/400 System Request menu. System Request menu access can be abused and some people need to be kept out. The good news is that it is relatively easy and painless to lock out one, two, or even all *PUBLIC users from accessing the menu. The key to locking out System Request menu users lies in knowing that the menu uses a Panel Group (*PNLGRP) object called QGMNSYSR that resides in library QGPL. QGMNSYSR is critical to accessing the System Request menu and if a user doesn’t have authority to that object, he won’t be able to access the menu. By default, the *PUBLIC user has *USE authority to QGMNSYSR, which means that everyone can usually get to the menu. (The *PUBLIC user is a catch-all designation that tells the system what access users can get if they are not explicitly authorized to the object.) If you want to limit QGMNSYSR access for just one user, you can do it by changing QGMNSYSR’s authority list to exclude that user from accessing the object. To remove a user’s authority to QGMNSYSR, run the following Grant Object Authority command (GRTOBJAUT).
GRTOBJAUT OBJ(QSYS/QGMNSYSR)
OBJTYPE(*PNLGRP)
USER(User_Name) AUT(*EXCLUDE)
This adds an exclusion entry for the user to QGMNSYSR’s authority list. You could also use the Edit Object Authority (EDTOBJAUT) command to add exclusion entries. To do this, run EDTOBJAUT like this: EDTOBJAUT OBJ(QSYS/QGMNSYSR) OBJTYPE(*PNLGRP) From the Edit Object Authority screen that appears, press the F6 key, Add New Users, to add an *EXCLUDE authority entry for the user. Both techniques perform the same function. After running these commands, the object’s authority list would look like this. User Group Authority *PUBLIC *USE User_name *EXCLUDE QSYS *ALL And whenever your locked out user tries to access the System Request menu, he will get the following error message: CPD2317 - No authority to use system request functions. The nice thing about this technique is that you can easily add *EXCLUDE entries for individual users, users belonging to certain group profiles, or for all users who are specifically listed in an authorization list object (object type *AUTL). It’s also a simple matter to exclude all *PUBLIC users from the System Request menu by running the following GRTOBJAUT command. GRTOBJAUT OBJ(QSYS/QGMNSYSR) OBJTYPE(*PNLGRP) USER(*PUBLIC) AUT(*EXCLUDE) Adding this entry stops all *PUBLIC users from accessing the System Request menu. By restricting *PUBLIC users, you can completely lock down the menu to unauthorized usage. The nice thing is that if you do restrict *PUBLIC access to the menu, you can always let specific users back in by explicitly giving them access to QGMNSYSR. This can be done by running the following GRTOBJAUT command. GRTOBJAUT OBJ(QSYS/QGMNSYSR) OBJTYPE(*PNLGRP) USER(User_name) AUT(*USE) So it’s a relatively easy process to restrict and grant access to the System Request menu. It’s just a matter of knowing which command to use. Additional Information From a Previous Article Regarding my article on Configuring Messaging Software for Overnight Monitoring, Kurt Thomas of CCSS wrote in to remind me that Bytware and Help/Systems aren’t the only ones offering monitoring and paging software for the System i: I work for CCSS, and our QSystems Management line of products allows you to use the methodology you described. QRemote Control allows you to send out SMS messages directly [to the user], using a small GSM device. It also allows you to not only receive messages from the system, but to actively request information about the system; and to use escalations for structured notifications. Kurt’s point is well taken and when searching for System i software products, you should always check out the full range of vendors who offer those products. –Joe RELATED STORY Configuring Messaging Software for Overnight Monitoring
|
