Re: Oracle password authentication

<jkyf_at_us.sina.com> wrote in message news:8snp73$n44$1_at_nnrp1.deja.com...
> I am study for OCP.
> Can anyone clarify what's the different between OS and password file
> authentication?
> I setup the password file and create user, but when I select users in
> password file, it only shows me SYS and SYSTEM.
>

And how did you select users in your password file? I only ask because SYSTEM is not a privileged user, and is therefore not in the Password File (Internal and SYS are), unless you specifically grant sysdba to SYSTEM (which is an extremely bad idea).

OS authentication and password file authentication are simply two different methods of authenticating a privileged user onto the system -and by privileged user, I mean one who is able to perform the five basic privileged actions -Create Database, Startup, Shutdown, Backup, Recover.

In OS authentication, you simply set up an appropriate O/S group (usually 'dba' on Unix, and ORA_sid_DBA on NT), and then put O/S User details into those groups. Merely by logging on to the NT box, therefore, you acquire the privileges associated with the ORA_sid_DBA group -which happen to be the privileges to perform the 5 privileged actions. When you type 'connect / as sysdba' in Server Manager, the 'as sysdba' tells Oracle you are trying to be a privileged user. It goes off and checks the O/S group for its membership list -if your O/S username appears in the list, you're allowed on.

With Password File authentication, you are doing much the same thing -except that instead of getting Oracle to check the membership lists of the O/S groups, you are asking it to check the contents of a password file that you have created. Hence the connect string would look like 'connect joe/bloggs as sysdba'. Once again, the magic words 'as sysdba' indicate you want to get on to the database as a privileged user. Oracle now goes off to the password file, and if there is an entry for joe with a password of bloggs, you're allowed on.

So both methods are doing exactly the same thing, just in slightly different ways. Why pick the one way over another? It basically comes down to a trust and security issue. If you've enabled O/S authentication, then anyone who walks up to your machine will be able to administer the database as a privileged user -your logging on to NT has given that PC (effectively) privileged user rights on the database. With a separate password, someone could use your PC -but they would have to know an additional password before being able to administer the database.

O/S authentication is thus useful in a secure environment (say, when you do your administration from within the server room itself). Password file authentication is useful for unsecure environments (where you do your administration seated at your normal desk out in the open-plan office).

If you are going to use O/S authentication, then you set the init.ora parameter REMOTE_LOGIN_PASSWORDFILE to the value NONE.

If you are going to use a password file, you have to determine whether the password file is going to be unique to the database/instance, or is one file going to serve for multiple databases. In the first case, you'd set remote_login_passwordfile to be EXCLUSIVE. In the second, you'd set it to be shared.

The nasty surprise is that a shared password file cannot accept any entries of real users. In other words, if you were to say 'grant sysdba to joe' inside a server manager session, it would fail if the password file is shared -because granting the sysdba privilege to someone implies that their normal data dictionary details (name and password) are written into the password file -but a shared password file can NOT be written to. Hence, the ONLY privileged users contained within a shared password file are SYS and Internal (and Internal is not a real User at all, and you ought to start forgetting about it because in future versions of Oracle he won't be there at all).

That's the basic story. There is one further complication that I won't go into, which is that normal, under-privlileged users (!) can actually use O/S authentication -in other words, humble users who are only allowed to do a bit of inserting, updating and deleting can actually connect to the database merely by virtue of having been authenticated by (say) the NT domain. There connect strings look like this: 'connect /' -no 'as sysdba' key words, but no username or passwords either. The thing is that this sort of authentication uses a completely different mechanism to that employed for Privileged User O/S authentication, and really shouldn't be called O/S authentication at all. Until you are happy with the two methods of Privileged User authentication, I wouldn't worry about it.

Regards
HJR
> JK
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Received on Sat Oct 21 2000 - 03:33:59 CDT