| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Internal password confusion
Thanks, Howard - your response clarifies a whole lot! I will investigate the issues you raised (about environment, and srvrmgrl, etc) in more detail based on your post.
There are SO MANY posts on this topic that don't come close to this level of clarity! Thanks again ... Chris
On Thu, 11 Jan 2001 19:11:07 +1100, "Howard J. Rogers" <howardjr_at_www.com> wrote:
>
>"Chris S" <cschofie_at_nospam.home.com> wrote in message
>news:3a5d49b8.208713544_at_192.168.0.10...
>> Platform: NT; Oracle version: 8.1.6 EM. Default install.
>>
>> I found myself unable to connect to a database using the userid
>> 'internal', password 'oracle'. Same failure in both svrmgrl and DBA
>> Studio.
>>
>> After much reading on these newsgroups, and experimenting, here's what
>>
>> I found.
>>
>> I used ORAPWD to recreate the password file with a password of
>> 'oracle'. I could then connect as 'internal/oracle' in svrmgrl. I
>> could also
>> connect as 'sys/oracle' - which agrees with the various posts and help
>>
>> texts that say that ORAPWD changes BOTH 'internal' and 'sys' (contrary
>> to what some posters have said).
>
>
>It doesn't "change" SYS. It creates a superhero bersion of sys that is
>capable of exercising SYSDBA privileges, and yes -the password for that
>version of SYS is set to whatever you specify in the orapwd utility. The
>point being, that if you do a "connect internal" followed by a "select user
>from dual", you will discover that you've been logged on as SYS in any case.
>
>In short, "internal" is a short-hand way of typing "connect sys/oracle as
>sysdba", but is functionally equivalent (and, since "internal" is
>disappearing in 8.1.7 onwards, you'd best get into the habit of using the
>long-hand format).
>
>
>>
>> However, in dba studio, I found that I could connect as
>> 'sys/change_on_install' as a 'normal' user, or as 'sys/oracle' as
>> sysdba user. So I concluded that there are really two 'versions' of
>> the sys user in my environment at this point - 'sys/internal' and
>> 'sys/oracle'!
>>
>
>SYS has an entry in the data dictionary. His password there is
>"change_on_install" by default. If you "connect sys/change_on_install", you
>are using data dictionary authentication: SYS gets on as a powerful, but
>ordinary User.
>
>If you want SYS to exercise the SYSDBA privileges (ie, startup, shutdown,
>backup, recover and create) then you have to have an external authentication
>mechanism -either o/s or (as you have found by using orapwd) password file.
>If you are trying to start the damn thing up, you'd be pretty stuffed if
>your only authentication mechanism was contained within the data dictionary
>of the (closed!) database itself.
>
>So, yes. SYS can take one of two possible guises. Ordinary, powerful SYS
>via the data dictionary. Or superher SYSDBA SYS, authenticated externally
>to the data dictionary.
>
>> This is not reproducible in svrmgrl or sql*plus - in these apps, only
>> the 'sys/change_on_install' works. But I just re-tested - dba studio
>> allows me to connect as sysdba using sys/oracle!
>>
>
>Interesting. Rest assured that connect sys/oracle as sysdba *will* work in
>server manager (or sqlplus for that matter, in 8i onwards). I suspect that
>the problem is that dba studio knows where your password file is, but server
>manager doesn't. Time to check your environment variables. Password files
>reside in ORACLE_HOME/dbs (from memory). As a command line tool, you want
>to make sure that the ORACLE_HOME environment variable is set correctly
>before trying to use Server Manager.
>
>Regards
>HJR
>
>
>
>
>> For what it's worth...
>>
>>
>> ===========
>> Remove 'nospam' from email to reply - Thanks
>
 |
 |