Lesson 2	Why password files?
Objective	Explain why password files are necessary in Oracle 23ai

Oracle Password Files (Why They Are Necessary Explained)

Password files are necessary because Oracle needs a way to authenticate you when you are connecting over a network to a database that has not been opened. If you are connecting to an instance over a network, then you have not logged into the database server, and Oracle has no way to verify that you are who you say you are. It can check your password against those stored in the database, but that only works if the database is open. DBAs often need to connect to an instance when a database is not open. A good example is when you need to connect in order to start an instance. To get around this problem, DBA passwords are stored in the password file.

A password file is not a database file. A password file is a small, binary file that contains only the encrypted passwords of DBAs who have been granted SYSDBA, SYSOPER, or other administrative privileges. Because it is not a database file, Oracle can read it using standard operating system file I/O at any stage of the instance lifecycle. This is what enables you to use tools such as Oracle Enterprise Manager Cloud Control to remotely manage a database in a secure manner even when the database is not open.

There are three steps to using a password file:

Create the password file
Configure your database to use the password file
Identify the users that are DBAs

The rest of this module shows you how to perform these tasks.

How Oracle Authenticates Database Administrators

Oracle uses two distinct mechanisms to authenticate users who connect with administrative privileges. Understanding which mechanism applies in a given situation is the conceptual foundation of this lesson.

Local OS Authentication - No Password File Required

When a DBA connects directly on the database server - physically present at the machine or through a local terminal session - Oracle can delegate authentication to the operating system. On Linux and Unix systems, any OS user who is a member of the dba group can connect as SYSDBA without providing a database password:

sqlplus / AS SYSDBA

On Windows, membership in the ORA_DBA local group provides the same capability. Oracle trusts the operating system's identity verification and does not consult the password file or the data dictionary. This is OS authentication, and it requires no password file.

The sqlnet.ora parameter SQLNET.AUTHENTICATION_SERVICES controls whether OS authentication is permitted. In hardened security environments, setting this parameter to (NONE) disables OS authentication and forces all connections - including local ones - to use password file authentication:

# sqlnet.ora - disable OS authentication
SQLNET.AUTHENTICATION_SERVICES = (NONE)

With this setting, even a DBA sitting at the server console must provide a password to connect as SYSDBA.

Remote Network Authentication - Password File Required

When a DBA connects over a network - from a workstation, a monitoring tool, or a remote management console - OS authentication is not available. The remote client has not logged into the database server's operating system, so Oracle cannot verify the user's identity through OS group membership.

For remote connections, Oracle uses one of two mechanisms depending on whether the database is open. If the database is open, Oracle can authenticate against the data dictionary - the SYS password stored in the database itself. If the database is not open, the data dictionary is unavailable, and Oracle must rely entirely on the password file.

The Authentication Decision Matrix

The following table summarizes which authentication mechanism Oracle uses for each connection type:

Connection Type	Authentication Method
Local, OS user in dba group, DB any state	OS authentication - no password file needed
Remote network, DB open	Data dictionary or password file (REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE)
Remote network, DB in MOUNT state	Password file only - data dictionary not accessible
Remote network, DB in NOMOUNT state	Password file only - data dictionary not accessible
Remote network, DB not started	Password file only - instance not running

Why the Database Being Closed Changes Everything

The Data Dictionary Is Unavailable When the Database Is Closed

The Oracle data dictionary - the collection of tables and views in the SYS schema that stores all metadata about users, objects, privileges, and passwords - lives inside the database files. To read the data dictionary, Oracle must have the database files open and the buffer cache populated. When the database is shut down or only mounted, the data dictionary is physically inaccessible.

This creates a fundamental bootstrapping problem for remote DBA access. A DBA needs to connect as SYSDBA to start the database. Starting the database requires authentication. But authentication against the data dictionary requires the database to already be open. The password file breaks this circular dependency by providing an authentication source that Oracle can read before the database is open.

Password Files as OS-Level Files - Readable at Any Instance State

Unlike database files - which require the Oracle instance to be running, the control file to be mounted, and the datafiles to be opened - the password file is a plain operating system binary file stored in the file system. Oracle reads it using the same OS file I/O that any program uses to read a file. No instance startup is required, no buffer cache is needed, and no SQL processing is involved.

The password file is encrypted so its contents cannot be read directly by opening it in a text editor, but Oracle's authentication code can decrypt and validate credentials from it at any point - before STARTUP NOMOUNT, during STARTUP MOUNT, and after the database is fully open. This is the property that makes password files essential for remote DBA access.

The Three Instance States Where Password Files Are Essential

Oracle database startup proceeds through three states, and password file authentication is required for remote connections at each of the first two:

NOMOUNT - The instance is started (SGA allocated, background processes running) but no control file is mounted. The DBA must connect as SYSDBA to issue ALTER DATABASE MOUNT. Only password file authentication is available.
MOUNT - The control file is open and read, but the datafiles are not yet opened. The DBA must connect as SYSDBA to issue ALTER DATABASE OPEN, to perform media recovery, or to enable ARCHIVELOG mode. Only password file authentication is available.
OPEN - The database is fully open. Both data dictionary authentication and password file authentication are available for remote SYSDBA connections.

Database shutdown reverses this sequence, and password file authentication remains the only option for remote access once the database begins shutting down.

Five Reasons Oracle Password Files Are Necessary

1. Authentication Before Database Open

The most fundamental reason for password files is pre-open authentication. When a database is shut down, in NOMOUNT state, or in MOUNT state, the internal user accounts stored within the database are not accessible because the data dictionary cannot be read. A password file enables the database server to authenticate remote administrators without requiring the database to be fully operational. This is essential for startup, shutdown, and recovery operations - the core tasks that define database administration.

2. Remote Administrative Access

Password files enable administrators to connect remotely to the database with SYSDBA or SYSOPER privileges through Oracle Net Services. This is critical for modern enterprise environments where DBAs manage databases from workstations, from Oracle Enterprise Manager Cloud Control, or from automation scripts running on separate servers. Without a password file, remote SYSDBA access is not possible regardless of the database state. The DBA would be required to have physical or OS-level access to the database server for every administrative operation.

3. Security and Role-Based Access Control

The password file provides a controlled registry of who holds the highest-level database privileges. Only users explicitly listed in the password file can connect with SYSDBA or SYSOPER privileges. This creates a clear audit boundary - querying V$PWFILE_USERS shows exactly which accounts hold elevated access, independent of any data dictionary state. In Oracle 12c and later, this registry extends to SYSBACKUP, SYSDG, SYSKM, and SYSRAC - targeted privilege grants that follow the principle of least privilege by giving backup operators, Data Guard administrators, and encryption key managers only the specific authority they need rather than full SYSDBA access.

4. Consistency Across Oracle RAC Instances

In Oracle Real Application Clusters environments, multiple database instances run simultaneously across different servers, all sharing the same database files. Password file authentication must be consistent across all nodes - if one node recognizes a DBA's credentials and another does not, cluster management becomes unreliable. In Oracle 12.2 and later, storing the password file in an Oracle ASM disk group makes it a single shared file accessible by all RAC nodes, eliminating the synchronization problem entirely. Any grant of SYSDBA or change to the SYS password is immediately recognized across all cluster instances.

5. High-Availability and Recovery Operations

In high-availability environments - Oracle Data Guard standby databases, Oracle RAC, or any configuration where individual nodes may be in various states of availability - administrators regularly connect to database instances that have not yet fully started, are being recovered, or are in a restricted mode. Password files allow authentication and administrative operations in all these states. A Data Guard administrator connecting to a physical standby that is in MOUNT state to monitor redo apply progress, or an RMAN operator connecting to perform point-in-time recovery, requires password file authentication because the standby data dictionary may not be accessible in read-write mode.

Oracle 23ai and Cloud Authentication Context

In Oracle Database 23ai, the password file mechanism is unchanged for on-premises deployments. The orapwd utility, REMOTE_LOGIN_PASSWORDFILE parameter, and V$PWFILE_USERS view all function as described in this module.

For Oracle cloud deployments, the authentication model is extended rather than replaced. Oracle Autonomous Database and Oracle Database@Azure use Identity and Access Management (IAM) for administrative access, where the cloud platform's identity provider authenticates administrators and issues session tokens rather than relying on a password file. However, for Oracle Database on OCI Compute - where you manage your own Oracle Database installation on a cloud VM - the traditional password file approach applies exactly as in on-premises environments.

The conceptual principle remains consistent across all deployment models: Oracle needs a secure, database-independent mechanism to authenticate DBAs who connect before or without a fully open database. Whether that mechanism is a binary password file on the local filesystem or an IAM token from a cloud identity provider, the underlying requirement is the same.

In the next lesson, you will learn how to create an Oracle password file using the orapwd utility, including the syntax, required parameters, and platform-specific file naming requirements.