RE: "Not authorized to command XXXXXXXX"

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
In the case of our branch in the U.K., with which we have a 5-hour time
difference, I have no desire waking up to 3 a.m. phone calls asking me
to please run the STRHOSTSVR command.  To the best of my knowledge, the
only reason we need STRHOSTSVR is to be able to run Client Access.
Quite frankly, and I freely admit that I may not fully understand the
security implications (which is why I'm on this list!), but I see no
reason why the five technical people, one with a strong AS/400
background, should not be given the authority to run STRHOSTSVR or any
of the commands that have to do with communications or device
configuration.

OTOH, I restrict the use of certain commands such as PWRDWNSYS, ENDSYS,
well actually, a lot of the ENDxxx commands.

- Dan
Dan Bale says "BAN DALE!"
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------

> -----Original Message-----
> From: Jim Langston [SMTP:jlangston@celsinc.com]
> Sent: Monday, August 20, 2001 7:24 PM
> To:   security400@midrange.com
> Subject:      RE: [Security400] "Not authorized to command XXXXXXXX"
>
> Well, primarily because QSECOFR has *ALLOBJ as you point out, but I
> think
> also because you shouldn't be running commands with the QSECOFR
> account.
>
> What are you trying to do with the user LTEIT?  If you want LTEIT to
> be able
> to run any system command, that might be a start, but I think IBM
> purposely
> restricted the command STRHOSTSVR so you would have to change the
> authority
> to it yourself and you knew what the security was.
>
> A lot of people may just not worry about it and sign on as QSECOFR and
> start
> it when they want to.
>
> Regards,
>
> Jim Langston
> Programmer/Analyst
> Cels Enterprises, Inc.
>
> -----Original Message-----
> From: security400-admin@midrange.com
> [mailto:security400-admin@midrange.com]On Behalf Of Bale, Dan
> Sent: Monday, August 20, 2001 3:29 PM
> To: security400@midrange.com
> Subject: RE: [Security400] "Not authorized to command XXXXXXXX"
>
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> I used EDTOBJAUT per your advice.  This seems to match what the
> security
> reference says.
>
> Why isn't QSECOFR in this list?  Is it because it has *ALLOBJ special
> authority?
>
> Maybe I should just create a new PDM option: GRTOBJAUT &N *CMD
> USER(LTEIT) AUT(*USE) and use it on all command objects in QSYS?
> (LTEIT
> is the group profile for admins.)
>
> Dan Bale
> IT - AS/400
> Handleman Company
> 248-362-4400  Ext. 4952
> D.Bale@Handleman.com
>   Quiquid latine dictum sit altum viditur.
>   (Whatever is said in Latin seems profound.)
>
> -------------------------- Original Message --------------------------
>
> > -----Original Message-----
> > From:       Jim Langston [SMTP:jlangston@celsinc.com]
> > Sent:       Monday, August 20, 2001 6:00 PM
> > To: security400@midrange.com
> > Subject:    RE: [Security400] "Not authorized to command XXXXXXXX"
> >
> > Generally what I do when I come across this type of situation is I
> > EDTOBJAUT
> > on the given command and see how they are currently set up.  I see
> on
> > our
> > system it is also set up:
> >
> >                           Object
> >  User        Group       Authority
> >  QSYS                    *ALL
> >  QSRV                    *USE
> >  QSRVBAS                 *USE
> >  QSYSOPR                 *USE
> >  QPGMR                   *USE
> >  *PUBLIC                 *EXCLUDE
> >
> > which basically means the system, programmers and the security
> officer
> > can
> > run the command.  If I wanted someone else to use this command I
> would
> > add
> > them as *USE.
> >
> > EDTOBJAUT is generally the first place I look when securing or
> > unsecuring
> > commands.
> >
> > Regards,
> >
> > Jim Langston
> > Programmer/Analyst
> > Cels Enterprises, Inc.
> >
> > -----Original Message-----
> > From: security400-admin@midrange.com
> > [mailto:security400-admin@midrange.com]On Behalf Of Bale, Dan
> > Sent: Monday, August 20, 2001 2:40 PM
> > To: security400@midrange.com
> > Subject: [Security400] "Not authorized to command XXXXXXXX"
> >
> >
> > <SNIP>
> > Am I correct that I can give the group profile for admins *USE
> > authority
> > to the STRHOSTSVR command to solve our dilemna?  Or is there
> something
> > else that needs to be done?
> >
> > Dan Bale
> > <SNIP>