RE: QUSER on ODBC requests

--
--
[ Picked text/plain from multipart/alternative ]

Here's what I did.  Now... Please be careful lobbing in the shells, ok?

FTP's are run from a script file.  The script file resides in a normal and
secured place.  The script file may or may not have a hard-wired user name
and/or password, (including Anonymous).  Some jobs do not require a secure
password and can be kept in the clear fairly easily.  Other times there may
be legitimate security issues.

When the job runs, the script file goes to Qtemp.  If a password is required
it is asked for at that time  and the FTP runs from Qtemp.

There's a bit more to it than that, but thats the salient point.

--------------------------------------------
Booth Martin
MartinB@Goddard.edu
802-454-8315 x235
--------------------------------------------
-------Original Message-------

From: midrange-l@midrange.com
Date: Friday, December 14, 2001 02:35:25 PM
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:

| &lt;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" &lt;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:

| > &lt;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 &lt;WaldenL@TechSoftInc.com>

| > To: &lt;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


.
--
[ Content of type unknown/unknown deleted ]
--