|
-- -- [ 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: | <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 . -- [ Content of type unknown/unknown deleted ] --
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
