RE: User profile question

> For Rob's sign-on scenario, why not modify the sign-on
> screen to hide or
> protect the menu and program fields?  That is not a hard
> change, and it
> takes this security risk away.
> 
> Everywhere I have worked, the sign-on screen has been
> modified so that the
> user is only allowed to enter their ID and password.  It's
> less confusing
> for the users and gives better control over the sign-on so
> they don't get
> into something where they don't belong.

Modifying the signon screen is a great idea for a number of reasons -
but taking away the security risk is not one of them.

If you would like to prove this to yourself, create a very un-powerful
user "BUBBA" like so:

CRTUSRPRF USRPRF(BUBBA) PASSWORD() USRCLS(*USER) INLMNU(*SIGNOFF)
LMTCPB(*YES) TEXT('Test-can be deleted any day after creation date')
SPCAUT(*NONE)

Then FTP into your iSeries with BUBBA's ID.  You can expect to get
logged in successfully.

If you want to read data, do these ftp commands...

> cd /qgpl
> get qgpl/qddssrc.qdsignon c:\qdsignon.txt

...and you'll have a copy of the Signon Screeds DDS source on your C:
drive

If you were to do the same thing against one of your own production
files, just cd/yourlib - but don't try anything destructive like a
delete - it would very likely be successful.

A little roaming around here should convince you that INLPGM and INLMNU
(whether on the profile or on the signon screen) do not provide security
- they are merely a convenient way for you to customize the experience
of the user.

jte
 


--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Ron-
> Zimmerman@xxxxxxxxxxxxxxx
> Sent: Thursday, January 26, 2006 8:11 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: User profile question
> 
> For Rob's sign-on scenario, why not modify the sign-on
> screen to hide or
> protect the menu and program fields?  That is not a hard
> change, and it
> takes this security risk away.
> 
> Everywhere I have worked, the sign-on screen has been
> modified so that the
> user is only allowed to enter their ID and password.  It's
> less confusing
> for the users and gives better control over the sign-on so
> they don't get
> into something where they don't belong.
> 
> Thank you,
> Ronald L. Zimmerman
> I.T. Applications Manager
> Swiss Valley Farms, Co.      http://www.swissvalley.com
> "The Good for You Company"
> Email: Ron-Zimmerman@xxxxxxxxxxxxxxx
> 
> midrange-l-bounces@xxxxxxxxxxxx wrote on 01/26/2006
> 09:31:00 AM:
> 
> > Rob,
> >
> > I am not arguing the point about non-limited capability
> users and the
> > signon screen.  I agree that a user who is LMTCPB(*NO)
> can modify the
> > default menu/program/library entries on the signon
> screen and bypass
> > your initial program security.
> >
> > The point I was trying to make is that even users who
> are LMTCPB(*YES)
> > or (*PARTIAL) can have very broad access to the system
> by signing on
> > through other methods such as ftp.  Even if you specify
> that user BUBBA
> > has either a nonexistent initial program, or an
> INLPGM(*NONE) and
> > INLMNU(*SIGNOFF), BUBBA can still log onto the system
> through any of the
> > other connection points that do not use the 5250
> interactive signon
> > subsystem (ftp being the easiest one to test).
> >
> > Another way to look at it (and I bet we can agree on
> this) is that the
> > INLPGM and INLMNU parameters on a user profile are
> convenience tools -
> > they help you customize the environment for the user -
> they are not
> > security tools because you cannot guaranty that a user
> with a valid
> > profile and password will invoke these parameters at
> every logon.
> >
> > jte
> >
> >
> > --
> > John Earl | Chief Technology Officer
> > The PowerTech Group
> > 19426 68th Ave. S
> > Seattle, WA 98032
> > (253) 872-7788 ext. 302
> > john.earl@xxxxxxxxxxxxx
> > www.powertech.com
> >
> >
> >
> > This email message and any attachments are intended only
> for the use of
> > the intended recipients and may contain information that
> is privileged
> > and confidential. If you are not the intended recipient,
> any
> > dissemination, distribution, or copying is strictly
> prohibited. If you
> > received this email message in error, please immediately
> notify the
> > sender by replying to this email message, or by
> telephone, and delete
> > the message from your email system.
> > --
> >
> > > -----Original Message-----
> > > From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-
> > > bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> > > Sent: Thursday, January 26, 2006 5:14 AM
> > > To: Midrange Systems Technical Discussion
> > > Subject: RE: User profile question
> > >
> > > As I demonstrated earlier, INLPGM(...) will NOT
> prevent a
> > > user from
> > > signing on to a 5250 session.  They can always
> override
> > > the initial
> > > program on the sign in screen.  Typing in *NONE, or
> QCMD,
> > > are a couple of
> > > quick samples for the
> > > Program/procedure . . .    prompt
> > >
> > > Of course, now that I keep repeating this it's
> probably on
> > > Shalom's list
> > > or something so that kills using it and relying on
> > > "security by
> > > obscurity".
> > >
> > > Again, I can do this
> > > CRTUSRPRF USRPRF(DELETEME) PASSWORD() INLPGM(BUBBA)
> > > INLMNU(*SIGNOFF)
> > > and sign on using
> > > User  . . . . . . . . DELETEME
> > > Password  . . . . . .
> > > Program/procedure . . QCMD
> > > Menu  . . . . . . . . MAIN
> > > Current library . . .
> > > and get right in to a command line.
> > >
> > > However, if I also add LMTCPB(*YES), then any attempts
> to
> > > change the
> > > program, or menu, on the initial signon result in
> > > CPF1121 Initial program or procedure cannot be
> specified.
> > > CPF1122 Menu cannot be specified.
> > >
> > > Rob Berendt
> > > --
> > > Group Dekko Services, LLC
> > > Dept 01.073
> > > PO Box 2000
> > > Dock 108
> > > 6928N 400E
> > > Kendallville, IN 46755
> > > http://www.dekko.com
> > >
> > >
> > >
> > >
> > >
> > > "John Earl" <john.earl@xxxxxxxxxxxxx>
> > > Sent by: midrange-l-bounces@xxxxxxxxxxxx
> > > 01/25/2006 07:11 PM
> > > Please respond to
> > > Midrange Systems Technical Discussion <midrange-
> > > l@xxxxxxxxxxxx>
> > >
> > >
> > > To
> > > "Midrange Systems Technical Discussion" <midrange-
> > > l@xxxxxxxxxxxx>
> > > cc
> > >
> > > Fax to
> > >
> > > Subject
> > > RE: User profile question
> > >
> > >
> > >
> > >
> > >
> > >
> > > Jim,
> > >
> > > > CHGUSRPRF USRPRF(userid) PWDEXP(*NO)
> > > INLPGM(*LIBL/XXXXXXX)
> > > > <---- the
> > > > XXXXXXX will not allow the user to sign on, but is
> > > should
> > > > allow jobs,
> > > > that need the Userid to be *Enabled, to run.
> > >
> > >
> > > The INLPGM(*LIBL/XXXXXXX) will prevent a user from
> signing
> > > on to a 5250
> > > (telnet) session, but it will not inhibit signon from
> ftp,
> > > ODBC, OPSNAV,
> > > etc. etc. etc.  I'm pretty sure the INLPGM parameter
> is
> > > only used for
> > > 5250 signon.
> > >
> > > jte
> > >
> > >
> > >
> > > --
> > > John Earl | Chief Technology Officer
> > > The PowerTech Group
> > > 19426 68th Ave. S
> > > Seattle, WA 98032
> > > (253) 872-7788 ext. 302
> > > john.earl@xxxxxxxxxxxxx
> > > www.powertech.com
> > >
> > >
> > >
> > > This email message and any attachments are intended
> only
> > > for the use of
> > > the intended recipients and may contain information
> that
> > > is privileged
> > > and confidential. If you are not the intended
> recipient,
> > > any
> > > dissemination, distribution, or copying is strictly
> > > prohibited. If you
> > > received this email message in error, please
> immediately
> > > notify the
> > > sender by replying to this email message, or by
> telephone,
> > > and delete
> > > the message from your email system.
> > > --
> > >
> > >
> > >
> > > --
> > > This is the Midrange Systems Technical Discussion
> > > (MIDRANGE-L) mailing
> > > list
> > > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > > To subscribe, unsubscribe, or change list options,
> > > visit:
> > > http://lists.midrange.com/mailman/listinfo/midrange-l
> > > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > > Before posting, please take a moment to review the
> > > archives
> > > at http://archive.midrange.com/midrange-l.
> > >
> > >
> > > --
> > > This is the Midrange Systems Technical Discussion
> > > (MIDRANGE-L) mailing list
> > > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > > To subscribe, unsubscribe, or change list options,
> > > visit:
> > > http://lists.midrange.com/mailman/listinfo/midrange-l
> > > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > > Before posting, please take a moment to review the
> > > archives
> > > at http://archive.midrange.com/midrange-l.
> > >
> >
> >
> > --
> > This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the
> archives
> > at http://archive.midrange.com/midrange-l.
> >
> 
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
>