RE: QUSER on ODBC requests

I think John would be a bit more diplomatic than that <G>.

-----Original Message-----
From: midrange-l-admin@midrange.com
[mailto:midrange-l-admin@midrange.com]On Behalf Of Kurt Goolsbee
Sent: Friday, December 14, 2001 2:05 PM
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 ]
        Then he could say "Man some bone head programmer hard coded QUSER in
a DSN string.  We should get them to change it or you are going to have to
bring your machine down to a restricted state so we can restore security
data."

> -----Original Message-----
> From: Gary Monnier [SMTP:garymon@powertechgroup.com]
> Sent: Friday, December 14, 2001 2:08 PM
> To:   midrange-l@midrange.com
> Subject:      RE: QUSER on ODBC requests
>
> I kinda think John would recommend saving serurity data in the very least
> before trying the test suggested.
>
> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Kurt Goolsbee
> Sent: Friday, December 14, 2001 11:08 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 ]
> Well, the original message was posted by John Earl and he said it was one
> of
> his customers machines.  If you, as an ISV or a consultant, went to your
> customer and made this change, you could stop core business applications
> from running.  If the %$#@ing computer isn't working then neither are your
> employees, except the IT staff trying to figure out what happened.  What
> is
> the dollar value associated that?  What are you going to tell the person
> that approves your invoices?  "It's really a good thing.  Sorry you can't
> do
> business but I found and fixed a big security problem for you.  Don't
> blame
> me because you have stupid programmers."
>
> I know that John wouldn't go and do something like this but nobody else
> should either.
>
> A trend that we are seeing more and more of is that the people in change
> of
> administering the AS/400(s) are less and less technical.  The NT guy is
> now
> in charge of the AS/400 and he/she doesn't know not to use Q profiles.
>
> > -----Original Message-----
> > From:       bdietz@3x.com [SMTP:bdietz@3x.com]
> > Sent:       Friday, December 14, 2001 11:55 AM
> > To: midrange-l@midrange.com
> > Subject:    RE: QUSER on ODBC requests
> >
> >
> > One vote for good one vote for bad.......any others?.......
> >
> > I lamented whether or not I would suggest changing the password, I had
> > thought about just disabling the profile but thought it could cause
> other
> > problems.
> >
> > I do not believe it is good practice to use ANY of the "Q" profiles for
> > day-to-day activities.  These should be assigned to a profile created to
> > meet company naming/authority standards.
> >
> > This was mearly a troubleshooting exersize.
> >
> > Bryan
> >
> > ========================================================
> >
> > GOOD IDEA!  My experience has been that administrators, not to mention
> > managers, want to know if applications have hardcoded passwords.
> >
> > =========================================
> >
> > 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?
> >
> > ===========================================
> >
> >  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
> >  surely break it.  You should then be able to narrow down what is
> > happening.
> >
> >
> >
> >
> > _______________________________________________
> > 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.