Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: "ORACLE" won't go away as password for INTERNAL!!!

Re: "ORACLE" won't go away as password for INTERNAL!!!

From: Sybrand Bakker <postbus_at_sybrandb.demon.nl>
Date: Sun, 1 Apr 2001 17:32:26 +0200
Message-ID: <tceicgk9venled@beta-news.demon.nl>

Evidently if the two systems are in the same domain, and you log in on *both* systems as *domain* administrator (as opposed to *local* administrator), yes it will work that way . And of course you can debate whether or not the server should be logged as *local* administrator, instead as domain administrator. IIRC according to Oracle that is the correct policy.
So this is all really not an Oracle issue. If you or your NT sysadmin don't secure the network, or use easy to guess passwords, this is what will happen.

Regards,

Sybrand Bakker

"PC User" <seeMessage_at_NOSPAM.com> wrote in message news:YsHx6.1892$iU.366079_at_news1.rdc1.mb.home.com...
> Thanks Howard, for making it clear for me. I still don't have that warm
 and
> fuzzy feeling that comes from knowing that every thing will be alright.
> But anyway, it could be my paranoia or lack of knowledge/experience
> with this issue. Following is what I observed.
>
> The server machine in my test case had "secret" as the password for
> the Administrator account. On the client machine (many many miles
> away, connected only to the internet), the password was "secret" as well
> for the Administrator account. Since password for the Administrator
> account was same on both machines, I was able to connect to Oracle's
> "internal" account using anything as password. Oracle's network
> software somehow must be sending the Administrator password, used
> to login to the client machine, over to the server machine. Once I changed
> the Administrator password on one of these machines (so that both
> weren't same anymore), I couldn't login to the "internal" account. I then
> had to know the valid sys password.
>
> So the real key in this case is the Administrator password of the server
> machine.
>
> I know I have just reiterated what you had written. Don't ask me why...
>
> cheers,
> nn.
>
>
> "Howard J. Rogers" <howardjr_at_www.com> wrote in message
> news:3ac669c3_at_news.iprimus.com.au...
> >
> > "PC User" <seeMessage_at_NOSPAM.com> wrote in message
> > news:xEtx6.1803$iU.306808_at_news1.rdc1.mb.home.com...
> > > thanks for your reply and thanks for reminding me to rtfm. it is great
> > > that this issue has been resolved in a newer version. but what about
> > > thos who are stuck with an older version. do you know that oracle
> > > listens on port 1521, and anyone with little knowledge of the sid
> > > and oracle client software can connect to the database with full
> > > access. don't you see this as a problem? if not, please let me know
 what
> > > you do to make this security issue go away... in one of me tests, i
 was
> > > able to connect to a oracle server sitting in another city, over the
> > > internet
> > > using sql*plus. it let me in when i provided internal/oracle as
 credentials
> > > and i could do whatever i wanted. granted that people who leave their
> > > db servers so exposed on the internet may be deserve this kind of
 wakeup
> > > call, but what about the internal people and connections?
> > >
> >
> >
> > I think you're missing the point. Sybrand explained that connect
> > internal/completeandutterrubbishi'vejustmadeup will work fine -because
> > you've already logged on to the *operating system* and supplied valid
> > credentials, to the point where Windows 2000 is happy to let you on to
 the
> > box. There is thus no security problem at all: Fred Bloggs won't know
 your
> > O/S login credentials, will he? So Fred Bloggs typing
> > internal/completeandutterrubbishi'vejustmadeup will produce an error,
> > because he won't have picked up membership rights of the W2K ORA_DBA
 group.
> > Oracle will therefore check the password file for Internal's password,
 and
> > will find a mismatch.
> >
> > If you don't want the O/S credentials checked at all, even for yourself,
> > then simply force Oracle to use a password file. That's done by
 removing
> > all entries from the ORA_DBA local NT group (conceivably the ORA_sid_DBA
> > group), and by changing the init.ora parameter remote_login_passwordfile
 to
> > be either SHARED or EXCLUSIVE.
> >
> > I think if Oracle was as wide open to security abuse as you seem to
 think
 it
> > is, we might all have heard about it before now, don't you?
> >
> > Regards
> > HJR
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > thanks and regards,
> > > nn.
> > >
> > > p.s. i was extra carefull to not even use a single capitalized letter
 this
> > > time.... :-)
> > >
> > >
> > > "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message
> > > news:tcc5j3avhi8dda_at_beta-news.demon.nl...
> > > >
> > > > "PC User" <seeMessage_at_NOSPAM.com> wrote in message
> > > > news:Nrox6.1739$iU.277031_at_news1.rdc1.mb.home.com...
> > > > > Hi,
> > > > >
> > > > > I am running Oracle 8.1.6 on Windows 2000 server (SP/1).
> > > > >
> > > > > I have noticed that no matter what I do, the default password for
 Internal
> > > > > (i.e. "oracle") is *always* valid.
> > > > >
> > > > > Following is what I have tried:
> > > > > alter user sys identified by syssecret
> > > > >
> > > > > <I stopped the Oracle before I deleted and recreated the password
 file
 using
> > > > > orapwd. >
> > > > > orapwd file=pwdorcl.ora password=intsecret entries=5
> > > > >
> > > > > Following is what happens after above commands...
> > > > > Password "syssecret" is valid for user Sys.
> > > > > --what follows is realy interesting--
> > > > > Password "syssecret" is valid for user Internal. *AND*
> > > > > Password "intsecret" is valid for user Internal. *AND*
> > > > > ***** Password "oracle" is valid for user Internal.
> > > > >
> > > > > Of the last three, Internal accepting Sys' password makes sense as
 Sys
 and
> > > > > Internal are supposed to share the password. But, HOW DO I GET RID
 OF
 THIS
> > > > > "oracle" PASSWORD?
> > > > >
> > > > > Thanks and Regards,
> > > > > Nasir.
> > > > > nasirnoor_at_REMOVETHISsysspan.com
> > > > >
> > > > >
> > > >
> > > > This is just working as designed. In fact 'connect / as sysdba'
 would
 do.
> > > > This is the preferred syntax as internal is already obsolete and has
 been
> > > > removed in 9i.
> > > > The philosophy behind this is : if you are already a privileged user
 on
 the
> > > > server, an extra password in Oracle won't stop you.
> > > > If you really don't want this (and again : internal is no more in
 9i)
 I
> > > > think you should remove the ora_dba local group from your server.
> > > > You might experience connect sys as sysdba with the old internal
 password
> > > > still works, but then again you might not. In that you need to
 explicitly
> > > > grant sysdba privilege to users.
> > > > I don't think you really need to SHOUT to resolve this problem; a
 little
> > > > reading in the NT specific Oracle documentation or the getting
 started
> > > > documentation would have resolved this issue also. It's a pity to
 see
 many
> > > > people waste so much time because they seem to forget reading the
 docs.
> > > >
> > > > Hth,
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Received on Sun Apr 01 2001 - 10:32:26 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US