Restrict user to use SYSREQ

135 pts.
Tags:
AS/400 administration
AS/400 Client Access
AS/400 security
AS/400 subsystems
AS/400 user permissions
AS/400 user profiles
QINTER
SYSREQ
Hi.. Can anyone help me...to restrict some user to user sysreq. thank you

Answer Wiki

Thanks. We'll let you know when a new response is added.

You can stop selected users from accessing the System Request function by using the <a href=”http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/xsysreq.htm”>Presystem Request Program exit point</a> in conjunction with the <a href=”http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/qwtsetpx.htm”>Set Profile Exit Programs</a> API.

Bruce Vining
<a href=”http://www.brucevining.com/”>Bruce Vining Services</a>

——————————————————————

Hi,
Yes you can restrict user from using another AS400 session i.e Sys req Go to WRKUSRPRF command
there you can see <b>Limit device sessions </b>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 <b>all</b> objects.

*ALLOBJ is a <b>special authority</b> — by definition, it overrides <i>all</i> private authorities that you might attempt to create. That’s the whole point of it.

Tom

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Kiong
    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.
    135 pointsBadges:
    report
  • Kiong
    Thank for the answer.. But all my user hae authority *allobj should it can be a problem?
    135 pointsBadges:
    report
  • Kiong
    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)
    135 pointsBadges:
    report
  • Gilly400
    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.
    23,730 pointsBadges:
    report
  • Kiong
    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
    135 pointsBadges:
    report
  • BigKat
    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
    8,350 pointsBadges:
    report
  • Gilly400
    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.
    23,730 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following