Password Files - SECOND EDITION

The password file is an optional file that permits the remote SYSDBA or administrator access to the database.

When you attempt to start Oracle, there is no database available that can be consulted to verify passwords. When you start Oracle on the local system (i.e., not over the network, but from the machine the database instance will reside on), Oracle will use the OS to perform the authentication.

When Oracle was installed, the person performing the installation was asked to specify a group for the administrators. Normally, on UNIX/Linux, this group will be DBA by default, and OSDBA on Windows.

It can be any legitimate group name on that platform, however. That group is “special,” in that any user in that group can connect to Oracle “as SYSDBA” without specifying a username or password. For example, in my Oracle 11g Release 2 install, I specified an ora11gr2 group. Anyone in the ora11gr2 group may connect without a username/password:

$ groups tkyte ora11gr2

$ sqlplus / as sysdba

CHAPTER 3 ■ FILES

110

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options sys%ORA11GR2> show user

USER is "SYS"

That worked. I’m connected and I could now start up this database, shut it down, or perform whatever administration I wanted to. But suppose I wanted to perform these operations from another machine, over the network. In that case, I would attempt to connect using @tns-connect-string.

However, this would fail:

$ sqlplus /@ora11gr2 as sysdba

ERROR:

ORA-01031: insufficient privileges

OS authentication won’t work over the network for SYSDBA, even if the very unsafe (for security reasons) parameter REMOTE_OS_AUTHENT is set to true. So, OS authentication won’t work and, as discussed earlier, if you’re trying to start up an instance to mount and open a database, then by definition there’s no database yet in which to look up authentication details. It is the proverbial chicken and egg problem.

Enter the password file. The password file stores a list of usernames and passwords that are allowed to remotely authenticate as SYSDBA over the network. Oracle must use this file to authenticate them, not the normal list of passwords stored in the database.

So, let’s correct our situation. First, we’ll start up the database locally so we can set the

REMOTE_LOGIN_PASSWORDFILE. Its default value is NONE, meaning there is no password file; there are no remote SYSDBA logins. It has two other settings: SHARED (more than one database can use the same password file) and EXCLUSIVE (only one database uses a given password file). We’ll set ours to EXCLUSIVE, as we want to use it for only one database (i.e., the normal use):

sys%ORA11GR2> alter system set remote_login_passwordfile=exclusive scope=spfile;

System altered.

This setting can’t be changed dynamically while the instance is up and running, so we’ll have to shut down and this will take effect upon the next restart. The next step is to use the command-line tool (on UNIX and Windows) named orapwd to create and populate the initial password file:

$ orapwd

Usage: orapwd file=<fname> entries=<users> force=<y/n> ignorecase=<y/n> nosysdba=<y/n>

where

file is the name of password file (required);

password is the password for SYS; it will be prompted if not specified at command line;

entries are the maximum number of distinct DBAs (optional);

CHAPTER 3 ■ FILES

force indicates whether to overwrite existing file (optional);

ignorecase specifies whether passwords are case-insensitive (optional);

nosysdba indicates whether to shut out the SYSDBA logon (optional Database Vault only).

There must be no spaces around the equal-to (=) character.

The command we’ll use when logged into the operating system account that owns the Oracle software is

$ orapwd file=orapw$ORACLE_SID password=bar entries=20

This creates a password file named orapworcl in my case (my ORACLE_SID is orcl). That’s the naming convention for this file on most UNIX platforms (see your installation/OS admin guide for details on the naming of this file on your platform), and it resides in the $ORACLE_HOME/dbs directory. On Windows, this file is named PW%ORACLE_SID%.ora and it’s located in the %ORACLE_HOME%\database directory. You should navigate to the correct directory prior to running the command to create that file, or move that file into the correct directory afterward..

Now, currently the only user in that file is SYS, even if there are other SYSDBA accounts on that database (they are not in the password file yet). Using that knowledge, however, we can for the first time connect as SYSDBA over the network:

$ sqlplus sys/bar@ora11gr2 as sysdba

Connected to an idle instance.

idle>

■

Note If you experience an ORA-12505 “TNS:listener does not currently know of SID given in connect

Descriptor” error during this step, that means that the database listener is not configured with a static registration entry for this server. The DBA has not permitted remote SYSDBA connections when the database instance is not up. This will be the case for most Oracle installations for version 9i and above. You would need to configure static server registration in your listener.ora configuration file. Please search for "Configuring Static Service

Information" (in quotes) on the OTN (Oracle Technology Network) documentation search page for the version of the database you are using for details on configuring this static service.

We have been authenticated, so we are in. We can now successfully start up, shut down, and remotely administer this database using the SYSDBA account. Now, we have another user, OPS$TKYTE, who has been granted SYSDBA, but will not be able to connect remotely yet:

$ sqlplus 'ops$tkyte/foobar' as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 20 16:37:35 2010

…

CHAPTER 3 ■ FILES

112

With the Partitioning, OLAP, Data Mining and Real Application Testing options sys%ORA11GR2> show user

USER is "SYS"

sys%ORA11GR2> exit

$ sqlplus 'ops$tkyte/foobar'@ora11gr2 as sysdba

ERROR:

ORA-01031: insufficient privileges Enter user-name:

The reason for this is that OPS$TKYTE is not yet in the password file. In order to get OPS$TKYTE into the password file, we need to “regrant” that account SYSDBA:

$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 20 16:38:43 2010

…

With the Partitioning, OLAP, Data Mining and Real Application Testing options sys%ORA11GR2> grant sysdba to ops$tkyte;

Grant succeeded.

sys%ORA11GR2> exit

$ sqlplus 'ops$tkyte/foobar'@ora11gr2 as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 20 16:38:53 2010

…

With the Partitioning, OLAP, Data Mining and Real Application Testing options sys%ORA11GR2>

This created an entry in the password file for us, and Oracle will now keep the password in sync. If OPS$TKYTE alters his password, the old one will cease working for remote SYSDBA connections and the new one will start:

sys%ORA11GR2> alter user ops$tkyte identified by something_else;

User altered.

sys%ORA11GR2> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options

$ sqlplus 'ops$tkyte/foobar'@ora11gr2 as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 20 16:40:12 2010

CHAPTER 3 ■ FILES

ERROR:

ORA-01017: invalid username/password; logon denied

Enter user-name: ops$tkyte/something_else@ora11gr2 as sysdba Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options

The same process is repeated for any user who was a SYSDBA but is not yet in the password file.

Dans le document SECOND EDITION (Page 161-165)