Restrict user to use SYSREQ
Home > IT Answers > AS/400 > Restrict user to use SYSREQ
Kiong
135 pts.
0
Q:
Restrict user to use SYSREQ
AS/400 administration, AS/400 Client Access, AS/400 security, AS/400 user profiles, AS/400 subsystems, QINTER, AS/400 user permissions, SYSREQ
Hi..

Can anyone help me...to restrict some user to user sysreq.

thank you
ASKED: Mar 19 2009  2:42 AM GMT
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
RELATED QUESTIONS
0
Bvining
4885 pts.
0
A:
 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0
  • AddThis Social Bookmark Button
You can stop selected users from accessing the System Request function by using the Presystem Request Program exit point in conjunction with the Set Profile Exit Programs API.

Bruce Vining
Bruce Vining Services

------------------------------------------------------------------

Hi,
Yes you can restrict user from using another AS400 session i.e Sys req Go to WRKUSRPRF command
there you can see Limit device sessions System Value make it 1 in this way your users will not be able to use another session.

With Regards
Qureshi.Khalid




Hi Kiong,

The simplest way to prevent users from accessing this menu is by restricting authority to the panel group QGMNSYSR object type *PNLGRP.

To prevent specific users from seeing the System Request Menu, specify *EXCLUDE authority for those users:

GRTOBJAUT OBJ(QSYS/QGMNSYSR) +
OBJTYPE(*PNLGRP) +
USER(USERA) AUT(*EXCLUDE)

To prevent most users from seeing the System Request Menu, revoke public authority and grant *USE authority to specific users:

RVKOBJAUT OBJ(QSYS/QGMNSYSR) +
OBJTYPE(*PNLGRP) +
USER(*PUBLIC) AUT(*ALL)

GRTOBJAUT OBJ(QSYS/QGMNSYSR) +
OBJTYPE(*PNLGRP) +
USER(USERA) AUT(*USE)

You can also prevent users from selecting specific options from the System Request Menu by restricting the authority to the associated commands within this menu by revoking authority on the commands for a user.

===================================================================

Since you added that your users have *ALLOBJ special authority, you might as well start by telling your boss that it can't be done. Anything that you put in place can be ignored or circumvented, or even removed, by any *ALLOBJ users. And if an additional special authority is also needed, an *ALLOBJ user can obtain other special authorities.

You can't restrict a user from certain objects and simultaneously give that user access to all objects.

*ALLOBJ is a special authority -- by definition, it overrides all private authorities that you might attempt to create. That's the whole point of it.

Tom
Last Answered: Oct 19 2009  1:52 PM GMT by Bvining   4885 pts.
Latest Contributors: TomLiotta   8025 pts., A5   35 pts., Dreamz1974   515 pts.
  •   
0
0
RSS - Discussions Help
Discuss This Answer:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Kiong   135 pts.  |   Mar 19 2009  4:02AM GMT

Hi Kiong,

The simplest way to prevent users from accessing this menu is by restricting authority to the panel group QGMNSYSR object type *PNLGRP.

To prevent specific users from seeing the System Request Menu, specify *EXCLUDE authority for those users:

GRTOBJAUT OBJ(QSYS/QGMNSYSR) +
OBJTYPE(*PNLGRP) +
USER(USERA) AUT(*EXCLUDE)

To prevent most users from seeing the System Request Menu, revoke public authority and grant *USE authority to specific users:

RVKOBJAUT OBJ(QSYS/QGMNSYSR) +
OBJTYPE(*PNLGRP) +
USER(*PUBLIC) AUT(*ALL)

GRTOBJAUT OBJ(QSYS/QGMNSYSR) +
OBJTYPE(*PNLGRP) +
USER(USERA) AUT(*USE)

You can also prevent users from selecting specific options from the System Request Menu by restricting the authority to the associated commands within this menu by revoking authority on the commands for a user.

 

Kiong   135 pts.  |   Mar 19 2009  4:04AM GMT

Thank for the answer..

But all my user hae authority *allobj
should it can be a problem?

 

Kiong   135 pts.  |   Mar 19 2009  8:17AM GMT

i already do

RVKOBJAUT OBJ(QSYS/QGMNSYSR) +
OBJTYPE(*PNLGRP) +
USER(*PUBLIC) AUT(*ALL)

but the user still can do sysreq
*note all my user have aut(*allobj)

 

Gilly400   23625 pts.  |   Mar 19 2009  11:29AM GMT

Hi,

If your users have *ALLOBJ, then you won’t be able to restrict them. *ALLOBJ is not a good idea if you want to be able to restrict users on your system. It’s like giving administrator authority to all your windows users. I would suggest that you remove the *ALLOBJ from all users that don’t need it.

Regards,

Martin Gilbert.

 

Kiong   135 pts.  |   Mar 19 2009  2:00PM GMT

HI..

thats my problem…my boss want me to restrict user use sysreq..
but i can’t remove authority *allobj from my user..because our application need the user have that
authority to run aplication.

oh…its make me confused..

any idea of it…please help me
thanks before for all comment.

warm regard

 

BigKat   2540 pts.  |   Mar 19 2009  2:10PM GMT

In that case, you might need to look into Exit Point programs. I have not done this, but in articles I have read, you can create an exit point program that is attached to IBM commands, and when they are called, your program is run and it can validate parameters, change parameters, and even prevent the command from being run. If you can programmatically differentiate between your users (don’t forget the APIs) and who should and should not be able to use SYSREQ, you could stop them.

Sorry I don’t have links to the articles or some samples I could include
K

 

Gilly400   23625 pts.  |   Mar 19 2009  2:38PM GMT

Hi,

I find it very strange that an application needs *ALLOBJ. If I was in your position I would contact the supplier of your application and find out if it’s absolutely necessary. I can understand that some authorities may be necessary for an application, but *ALLOBJ defeats the object of having object level security on the AS/400.

I think your situation is one step away from giving all your users the password for QSECOFR…

Regards,

Martin Gilbert.

 
0