Re: insufficient privileges as sysdba 8.1.7 on Win2k

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:k6Pm9.45140$g9.128706_at_newsfeeds.bigpond.com...
>
> "todhsals" <todhsals_at_hotmail.com> wrote in message
> news:RZOm9.20426$xI5.4066_at_sccrnsc02...
> > I'm really trying to figure out why anything other than connect internal
> > will not work to shutdown and startup the database. As I understand it
> > internal is depreciated. Isn't sysdba necessary to startup and shutdown?
>
> You are right: INTERNAL is the Oracle 7 way of connecting as a privileged
> user, and ...AS SYSDBA is the 8.0 and above way of doing the same thing.
You
> must be one or the other to do privileged actions.
>
> Your particular scenario, I can't work out. You've got a password file
> (meaning that system...as sysdba should fail unless you've done the dirty
> and granted SYSDBA to system), but you also said in your original post:
>
> "The OS
> account I'm using is a domain account the local ORA_DBA and
> Administrators groups"
>
> Noe that's appalling grammar, but never mind: are you saying that the
> account I've logged onto this Windows box is a domain account, and it
> happens to be a member of the *LOCAL* ORA_DBA group?

Corrected by appaling spelling, "Noe" ; ) I saw the missing word right after I sent it.

Yes, domain user account that is a member of the local group named ORA_DBA. I'm quite certain the group was created by the install process because even the description line exactly matches the group description on functional box I installed myself & the group was created by the installer.

>
> If you log onto that box as Domain_Fred and Domain_Fred is a member of the
> local ORA_DBA group, then a connect / as sysdba should elicit a perfectly
> reasonable connection, and startups and shutdowns should be no problem.
>

This was my reading of the docs but it does not work. I have another 8.1.7/Win2k box & it works fine.

> O/S group membership always over-rides whatever you may have extant in
your
> password file.
>
> But it's a LOCAL group, not a domain one, though domain users can be a
> member of it.
>
> My only suggestion to you is: do you want password file authentication, or
> O/S authentication?? Pick one and stick with it. If O/S, set
> remote_login_passwordfile=NONE, set up memberships of the local ORA_DBA
> group (I tend to find that "Everyone" is a good go when debugging these
> sorts of things). If you want passwordfile authentication, then get rid of
> the ORA_DBA group, create a new password file, make absolutelty sure the
> remote_login_passwordfile parameter is set to EXCLUSIVE, grant SYSDBA to a
> select few users, and then all should be well.

My reading of the docs is that remote_login_passwordfile has no affect on local connections. This seems to be the case on my other 8.1.7/Win2k box. From the local console I can connect / as sysdba no password to startup, shutdown etc. From a remote box I can shutdown by connect sys as sysdba with the password.

The one difference is that on the system I'm having the trouble with, sqlnet_authentication_services is set to none (in sqlnet.ora), if I set it to NTS like the working box then I can't connect to it at all. This might not be relevant but I thought the problems might be related. Eventually I need to get OS auth working for users so I need to solve this part as well.

>
> This ain't rocket science. Be clear in what you want to achieve, then make
> sure the various settings are appropriate to the need.
>
> Regards
> HJR
>
> >
> > Just to add to my original post, the password file was recreated with
> orapwd
> > & nothing changed. The password file is being used when I connect
> internal.
> > I'm prompted for a password & it only works with the correct password.
> >
>
> PS... Did you re-grant SYSDBA to the relevant users? It's only that which
> transfers their data dictionary entries into the password file.
>

Yes & v$pwfile_users shows sys and system as sysdba.

>
>
> > Thanks,
> > Tod
> >
> >
> > "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
> > news:EIOm9.45127$g9.128744_at_newsfeeds.bigpond.com...
> > >
> > > "Rauf Sarwar" <rs_arwar_at_hotmail.com> wrote in message
> > > news:92eeeff0.0210021908.1aafc164_at_posting.google.com...
> > > > > Use oradim to drop the Oracle Windows service
> > > > > Delete the password file PWD<sid_name>.ora
> > > > > Recreate the Oracle Windows service with oradim
> > > > >
> > > > > That should do it unless somehow you have been playing around in
the
> > > > > registry and dropped the pointer to the password file.
> > > > >
> > > > > Daniel Morgan
> > > >
> > > >
> > > > You can also just recreate the password file using orapwd.
> > > > 1) Shutdown database as internal from svrmgrl
> > > > 2) Delete old PWD<SID>.ora file
> > > > 3) orapwd file=%ORACLE_HOME%\database\pwd<sid>.ora password=xxxxxx
> > > > 4) Start database as internal from svrmgrl
> > > > 5) grant sysdba to system;
> > >
> > > Ye Gods! Why Oh Why would you want to grant sysdba to SYSTEM???? When
> you
> > > connect system....AS SYSDBA, you are actually logged on as SYS. Half
the
> > > things you then proceed to do are never replicable via export/import
> (just
> > > for starters).
> > >
> > > PLEASE don't suggest we all connect as SYS. It's extremely bad news,
> and
> > > very bad practice.
> > >
> > > Don't do it.
> > >
> > > Regards
> > > HJR
> > >
> > > > 6) Exit from svrmgrl and login as system then try again
> > > >
> > > > /Rauf Sarwar
> > >
> > >
> >
> >
>
>
Received on Wed Oct 02 2002 - 23:20:21 CDT