× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.
> 


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.