Operating System Authentication in Oracle

Operating system authentication — the practice of allowing a database user to connect without a password by relying on their OS login identity — was once a common technique in Oracle environments, particularly for automating administrative scripts on UNIX systems. Oracle implemented this through OPS$ accounts, also called externally authenticated accounts. This mechanism has been deprecated since Oracle 12c Release 2 and is not available in Oracle 19c or Oracle 23ai. DBAs inheriting legacy environments that relied on OS authentication must understand what replaced it and how to migrate securely to supported alternatives.

What OPS$ Accounts Were

In older Oracle versions, a DBA could create a database account tied to an operating system username by prefixing the username with OPS$ and using the IDENTIFIED EXTERNALLY clause instead of IDENTIFIED BY password:

-- Deprecated since Oracle 12c R2 — do not use in 19c or 23ai
CREATE USER OPS$COIN_ADMIN IDENTIFIED EXTERNALLY
  DEFAULT TABLESPACE users
  TEMPORARY TABLESPACE temp
  QUOTA 5000K ON users;

With this account in place, a user logged into the operating system as COIN_ADMIN could connect to the database without supplying a password:

-- Legacy connection method — no longer supported
sqlplus /

The primary use case for OPS$ accounts was UNIX cron jobs that ran database scripts on a schedule. By eliminating the need for a hardcoded password in a shell script, OPS$ accounts avoided the security risk of storing credentials in plain text files. However, Oracle removed this feature because it created a different security vulnerability — any OS user who could assume the identity of COIN_ADMIN at the operating system level gained automatic database access without any additional authentication challenge.

Why OPS$ Accounts Were Deprecated

Oracle deprecated OS authentication in 12c Release 2 for two primary reasons. First, the security boundary between the operating system and the database was considered too weak — a compromised OS account automatically compromised the associated database account. Second, modern enterprise environments increasingly run Oracle on shared infrastructure, virtualized hosts, and cloud platforms where the OS identity of a connecting process is not a reliable authentication signal.

Attempting to create an OS-authenticated user in Oracle 19c or 23ai using the IDENTIFIED EXTERNALLY syntax results in an error. The feature is gone, not simply restricted.

Strategy 1: Password File Authentication

For DBAs who need to perform privileged administrative operations — particularly remote SYSDBA connections — the password file is the direct replacement for OS authentication. Create the password file using the orapwd utility:

orapwd file=$ORACLE_HOME/dbs/orapwORCL password=AdminPass#2024 entries=10

Enable remote password file authentication by setting the initialization parameter:

ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE SCOPE = SPFILE;

Grant the required administrative privilege to the target user:

GRANT SYSDBA TO coin_admin;

The user can then connect remotely with full administrative privileges:

sqlplus coin_admin/AdminPass#2024@dbname as sysdba

In Oracle 23ai, specialized administrative roles provide more granular alternatives to the broad SYSDBA privilege. Rather than granting full SYSDBA access, assign the minimum role required for the task:

-- For backup operations only
GRANT SYSBACKUP TO backup_admin;

-- For Data Guard management only
GRANT SYSDG TO dg_admin;

-- For Transparent Data Encryption key management only
GRANT SYSKM TO encryption_admin;

Strategy 2: Automating Scripts Without Hardcoded Passwords

The original motivation for OPS$ accounts in UNIX cron jobs — avoiding hardcoded passwords in shell scripts — is addressed in modern Oracle environments through several secure alternatives.

Oracle Wallet: Store the database credential in an Oracle Wallet and reference it in scripts using an alias from tnsnames.ora. The wallet is encrypted and the credential is never exposed in the script itself:

-- Add credential to wallet
mkstore -wrl /etc/oracle/wallet -createCredential mydb_alias coin_admin AdminPass#2024

-- Connect in script using wallet alias — no password in script
sqlplus /@mydb_alias

External Password Store: Oracle's external password store (`sqlnet.ora` with `WALLET_LOCATION`) allows connection strings of the form `/@alias` exactly as the old `sqlplus /` worked, but backed by a secure encrypted wallet rather than OS identity. This is the direct functional replacement for OPS$ accounts in automated scripts.

Strategy 3: Centrally Managed Users (CMU)

Oracle Centrally Managed Users, introduced in Oracle 18c and enhanced in 19c and 23ai, allows the database to authenticate users directly against Microsoft Active Directory or other LDAP-compliant directory services. This eliminates the need for individual OS accounts on the database server while providing centralized identity management across the enterprise.

-- Configure CMU in sqlnet.ora
LDAP_DIRECTORY_ACCESS = PASSWORD
LDAP_DIRECTORY_SYSAUTH = YES

With CMU configured, an Active Directory user can authenticate to Oracle using their directory credentials. The DBA maps directory groups to Oracle database roles, allowing role assignments to be managed entirely within Active Directory without touching the database.

Strategy 4: Kerberos and RADIUS Authentication

For environments with existing Kerberos infrastructure — common in organizations using Active Directory — Oracle supports Kerberos authentication through Oracle Advanced Security. A Kerberos-authenticated user can connect to Oracle without supplying a database password, using their existing Kerberos ticket:

sqlplus /@dbname

This provides the same password-free connection experience that OPS$ accounts offered, but backed by Kerberos ticket validation rather than OS identity — a significantly stronger security model. RADIUS authentication serves a similar purpose for organizations with existing RADIUS infrastructure, commonly used for network access control that is extended to database access.

Strategy 5: Schema-Only Accounts in Oracle 23ai

Oracle 23ai introduces schema-only accounts — database schemas that own objects but cannot be used to log in directly. This addresses a common pattern where application schemas needed to exist in the database without being accessible as interactive user accounts:

CREATE USER app_schema NO AUTHENTICATION
  DEFAULT TABLESPACE app_data
  QUOTA UNLIMITED ON app_data;

Schema-only accounts are the modern equivalent of locked application schemas, but more secure — the NO AUTHENTICATION clause ensures the account can never be unlocked and given a password. Application code connects through a separately authenticated application user that has been granted access to the schema's objects, rather than connecting directly as the schema owner.

Strategy 6: Cloud and Web-Based Authentication

In Oracle Cloud Infrastructure environments running Oracle 23ai, Identity and Access Management (IAM) integration allows database users and roles to be mapped to OCI IAM users and groups. Authentication is handled by the cloud provider's identity service, eliminating any dependency on OS-level accounts on the database host.

Oracle Database Actions (SQL Developer Web) and Oracle REST Data Services (ORDS) provide browser-based management interfaces that authenticate through database or cloud-native credentials, allowing DBAs to perform administrative tasks without requiring a terminal session or OS login on the database server at all.

Choosing the Right Replacement

The appropriate replacement for OS authentication depends on the specific use case it was serving:

1. Automated scripts and cron jobs — Oracle Wallet with external password store. Provides password-free connection identical to the old sqlplus / syntax, backed by encrypted credential storage.
2. Remote SYSDBA access — Password file with REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE. Use specialized roles (SYSBACKUP, SYSDG, SYSKM) rather than broad SYSDBA wherever possible.
3. Enterprise single sign-on — Centrally Managed Users with Active Directory, or Kerberos authentication for environments with existing Kerberos infrastructure.
4. Application schemas — Schema-only accounts in Oracle 23ai with proxy authentication for application connections.

Summary

OPS$ accounts and OS authentication were removed from Oracle in 12c Release 2 and are not available in Oracle 19c or 23ai. The security rationale was sound — tying database access to OS identity created an unacceptable attack surface in modern multi-tenant and cloud environments. Oracle provides a complete set of replacements: password files for privileged administrative access, Oracle Wallet for automated script authentication, Centrally Managed Users and Kerberos for enterprise SSO, and schema-only accounts for application schemas that should never be used as interactive logins. Each replacement is more secure than the OPS$ mechanism it supersedes.