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


  1.  Home
  2. MIDRANGE-L
  3. December 2001

RE: QUSER on ODBC requests

OK, so have the pc program ask the as/400 for a valid userid and password.
The 400 could validate that the request was valid (remote ip, MAC, time,
etc.) and return a user and password. A 5 second counter would then start
and when it expires the password for that user would be changed. Can it be
defeated, of course, but you'd have to set your ip, mac address and ask for
the password at the specific date and time that's much more secure than a
user called 'transfer' with a password of 'transfer'.

-Walden


------------
Walden H Leverich III
President
Tech Software
(516)627-3800 x11
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com



-----Original Message-----
From: jt [mailto:jt@ee.net]
Sent: Friday, December 14, 2001 14:19
To: midrange-l@midrange.com
Subject: RE: QUSER on ODBC requests


Rob,

I'd sure like to see an acceptable solution to this one, myself...

Hardcode passwords in code..: no good at all...!  But have password keyed in
on every batch FTP and Domino app use...:  AIN'T GONNA HAPPEN...!

jt

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of rob@dekko.com
| Sent: Friday, December 14, 2001 1:51 PM
| To: midrange-l@midrange.com
| Subject: RE: QUSER on ODBC requests
|
|
|
| Everyone may rant on how hard coding user id's and passwords are a bad
| idea but there are some applications where this is a necessity.  Well,
| I suppose
| you could put them in a dataarea or some such animal but you get the same
| results.
|
| For example, you want to do some batch ftp between one system and
| another. Remember I said batch.  And you get this EDI process that
| runs unattended. I have no urge to hire someone to key in a userid and
| password.  If I did, I'd make the poor bugger click on icons or some
| other worthless application to look busy.
|
| Again,  I have a Domino application which gets data from the 400.  The
| people running this application sometimes don't even have iSeries
| passwords.  Are you saying that instead of just clicking on a button
| to retrieve the data, that now I should also pop up a box that prompts
| them for an iSeries user id and password?  Ludicrous!
|
| Rob Berendt
|
| ==================
| "They that can give up essential liberty to obtain a little temporary
| safety deserve neither liberty nor safety." Benjamin Franklin
|
|
|
|                     "Gary Monnier"
|                     <garymon@powertechg       To:
| <midrange-l@midrange.com>
|                     roup.com>                 cc:
|                     Sent by:                  Fax to:
|                     midrange-l-admin@mi       Subject:     RE:
| QUSER on ODBC requests
|                     drange.com
|
|
|                     12/14/2001 01:38 PM
|                     Please respond to
|                     midrange-l
|
|
|
|
|
|
| At least the hard coded user profile isn't set to expire.  Hard coding
| user profiles and passwords is a REALLY BAD IDEA.  Just think of all
| the special
| coding that could be done by hard coding user id and password.
|
| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of alan shore
| Sent: Friday, December 14, 2001 10:17 AM
| To: midrange-l@midrange.com
| Subject: RE: QUSER on ODBC requests
|
|
| Something else I have just realized. If there are any applications
| with hard-coded user profiles and passwords, that means the system is
| set up NOT to expire passwords after a number of days. Yet another bad
| idea. Passwords
| SHOULD be set to expire after a number of days (we use 30) and to
| force the
| profile into an inactive state once 3 concurrent invalid attemps are made.
|
| >>> "Gary Monnier" <garymon@powertechgroup.com> 12/14/01 12:36PM >>>
| GOOD IDEA!  My experience has been that administrators, not to mention
| managers, want to know if applications have hardcoded passwords.
|
| --
| Gary Monnier               garymon@powertechgroup.com
| The PowerTech Group        www.powertechgroup.com
| 19426 68th Avenue South
| Kent, WA 98032
| Phone  253.872.7788
| Fax    253.872.7904
|
|
|
| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Kurt Goolsbee
| Sent: Friday, December 14, 2001 8:47 AM
| To: midrange-l@midrange.com
| Subject: RE: QUSER on ODBC requests
|
|
| This message is in MIME format. Since your mail reader does not
| understand this format, some or all of this message may not be
| legible.
| --
| [ Picked text/plain from multipart/alternative ]
| BAD IDEA.  If you change the password for QUSER and there are applications
| with user and password hardcoded then they will stop working.  Clearly you
| don't know if this is the case so how are you going to set the password
| back?
|
| > -----Original Message-----
| > From:         bdietz@3x.com [SMTP:bdietz@3x.com]
| > Sent:         Friday, December 14, 2001 6:16 AM
| > To:           midrange-l@midrange.com
| > Subject:           Re: QUSER on ODBC requests
| >
| >
| > John one way to check and see if it is really QUSER, Change the
| > password for QUSER.  If QUSER is hardcoded into a DSN or some such
| > thing this
| would
| > surley break it.  You should then be able to narrow down what is
| > happening.
| >
| >
| > -------------------------
| >  Bryan Dietz
| > 3X Corporation
| >
| >
| >
| >
| >
| >
| >                       "John Earl"
| >                       <johnearl@powertec        To:
| > <midrange-l@midrange.com>
| >                       hgroup.com>               cc:
| >                       Sent by:                  Subject:  Re: QUSER on
| > ODBC requests
| >                       midrange-l-admin@m
| >                       idrange.com
| >
| >
| >                       12/13/2001 04:01
| >                       PM
| >                       Please respond to
| >                       midrange-l
| >
| >
| >
| >
| >
| >
| > Walden,
| >
| > Yeah, we checked this out.  All of our reports use the "Current
| > User" rather than the "Job User" to report on.  This customer is
| > having QUSER show up as the "Current User".  :(
| >
| > jte
| >
| > --
| > John Earl
| > johnearl@powertechgroup.com
| > The Powertech Group          www.powertechgroup.com
| > Kent, Washington, USA       +1 253-872-7788
| >
| >
| > ----- Original Message -----
| > From: Walden H. Leverich <WaldenL@TechSoftInc.com>
| > To: <midrange-l@midrange.com>
| > Sent: Thursday, December 13, 2001 11:50 AM
| > Subject: RE: QUSER on ODBC requests
| >
| >
| > > John,
| > >
| > > Just curious, are you sure they mean "authority of" and not
| > that their audit
| > > stamps say "QUSER"??? All the "classic" methods of retrieving
| > the user id
| > > (RTVJOB, RPG PSDS, etc.) will show QUSER not the profile from
| > the swap.
| > >
| > >
| > > ------------
| > > Walden H Leverich III
| > > President
| > > Tech Software
| > > (516)627-3800 x11
| > > WaldenL@TechSoftInc.com
| > > http://www.TechSoftInc.com
| > >
| > >
| > >
| > > -----Original Message-----
| > > From: John Earl [mailto:johnearl@powertechgroup.com]
| > > Sent: Thursday, December 13, 2001 14:38
| > > To: MIDRANGE-L@midrange.com
| > > Subject: QUSER on ODBC requests
| > >
| > >
| > > This is a multi-part message in MIME format.
| > > --
| > > [ Picked text/plain from multipart/alternative ]
| > > We have a customer who is having a problem when they issue
| > Client Access
| > > ODBC requests.  It seems all of the transactions run under the
| > authority of
| > > user profile QUSER.
| > >
| > > This is odd because even though the QZDASOINIT jobs start as
| > QUSER, every
| > > time one of these prestart jobs receives an *SQLSRV request the
| > job is
| > > supposed to swap the job's "Current User" to the user id that
| > logged on to
| > > CAE.   In every other implementation of CAE that I have ever
| > seen, when a
| > > QZDASOINIT job gets an incoming ODBC request, it will swap the
| > current user
| > > and proceed with the request.  This site seems to leave the
| > current user at
| > > "QUSER".
| > >
| > > I'm guessing it is a configuration problem.   Does anyone know
| > of an OS/400,
| > > ODBC or CAE configuration option that might cause all ODBC
| > request to run
| > > under QUSER?   It must have got preset somewhere????
| > >
| > > The customer is using the Client Access Express, OS/400 V4R5
| > and Windows XP.
| > >
| > > Any thoughts?
| > >
| > > jte
| > >
| > >
| > > --
| > > John Earl
| > johnearl@powertechgroup.com
| > > The Powertech Group          www.powertechgroup.com
| > > Kent, Washington, USA       +1 253-872-7788
| > >
| > >
| > > --
| > >
| >
| >
| >
| >
| >
| > _______________________________________________
| > This is the Midrange Systems Technical Discussion (MIDRANGE-L)
| > mailing list To post a message email: MIDRANGE-L@midrange.com
| > To subscribe, unsubscribe, or change list options,
| > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
| > or email: MIDRANGE-L-request@midrange.com
| > 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@midrange.com
| To subscribe, unsubscribe, or change list options,
| visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
| or email: MIDRANGE-L-request@midrange.com
| 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@midrange.com
| To subscribe, unsubscribe, or change list options,
| visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
| or email: MIDRANGE-L-request@midrange.com
| 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@midrange.com
| To subscribe, unsubscribe, or change list options,
| visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
| or email: MIDRANGE-L-request@midrange.com
| 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@midrange.com
| To subscribe, unsubscribe, or change list options,
| visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
| or email: MIDRANGE-L-request@midrange.com
| 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@midrange.com
| To subscribe, unsubscribe, or change list options,
| visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
| or email: MIDRANGE-L-request@midrange.com
| 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@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
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 ...
Follow-Ups:
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.