Re: OS Authentication with winXP client Linux Server

On Jul 30, 4:14 pm, hjr.pyth..._at_gmail.com wrote:
> On Jul 31, 6:19 am, DA Morgan <damor..._at_psoug.org> wrote:
>
>
>
>
>
> > fitzjarr..._at_cox.net wrote:
> > > On Jul 30, 11:49 am, DA Morgan <damor..._at_psoug.org> wrote:
> > >> fitzjarr..._at_cox.net wrote:
> > >>> I'll be more than happy to forward this on to whomever configured the
> > >>> server I inherited. Such wasn't MY choice for authentication methods,
> > >>> however it's the method I have been given and I have no authority to
> > >>> change it.
> > >>> Sometimes we must play the hand we're dealt.
> > >>> David Fitzjarrell
> > >> Forwarding it on to the person who didn't know enough to do it correctly
> > >> the first time is essentially guaranteed to change nothing.
>
> > >> Forward it to your management with a note indicating that it is a severe
> > >> hazard to the health and safety of the organization's data and provide
> > >> the documentation to prove it.
> > >> --
> > >> Daniel A. Morgan
> > >> University of Washington
> > >> damor..._at_x.washington.edu (replace x with u to respond)
> > >> Puget Sound Oracle Users Groupwww.psoug.org
>
> > > Management made the decision for this authentication scheme.
>
> > > David Fitzjarrell
>
> > Based on what input?
> > --
> > Daniel A. Morgan
> > University of Washington
> > damor..._at_x.washington.edu (replace x with u to respond)
> > Puget Sound Oracle Users Groupwww.psoug.org
>
> I agree with what Dan's question is getting at: Management usually
> only do something because they've been told it's good for them. Were
> this management to be properly informed that their databases are not
> secure and the data they contain are therefore subject to non-
> auditable change or destruction by anyone anytime, for which the
> current DBA cannot take responsibility or be held accountable, I
> seriously doubt they would continue to insist on having the parameter
> set. I'd say it's one of the primary DBA responsibilities: to properly
> appraise management of risk. And this is risky stuff!
>
> We all get saddled with systems that have some howler or another,
> inherited from some less-capable DBA than our good selves... but if we
> just accept it, I'd suggest we're ducking a key responsibility. In
> this case, I had exactly the same problem about December of last year
> (see:http://www.dizwell.com/prod/node/455) and I was fortunately in a
> position to change the parameter after a modest bit of explanation and
> demonstration. If they hadn't agreed to the change, I would either (a)
> have resigned or (b) carried on working there having sent an email to
> senior management pointing out that as their DBA I took zero
> responsibility for the future integrity of their databases and the
> data they contained. It is always management's prerogative to ignore
> the advice they are given, but that they should be given it is, I
> would suggest, what DBAs are there to do.- Hide quoted text -
>
> - Show quoted text -

You act as though I've said nothing to management; nothing could be further from the truth. I was told, by several in the management chain, that the Network Security group was charged with securing the intranet from intruders, and as such my concerns were unfounded. Explain as I could nothing would budge anyone from laying responsibliity elsewhere, most notably to a group not represented in the exchange.

David Fitzjarrell Received on Tue Jul 31 2007 - 07:36:43 CDT