Operating System Authentication in Oracle AI Database 26ai

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 implements this through OPS$ accounts, also called externally authenticated accounts. Worth stating plainly, since older material sometimes claims otherwise: this mechanism has not been removed. IDENTIFIED EXTERNALLY remains a real, documented, working clause in Oracle AI Database 26ai, and OS_AUTHENT_PREFIX still defaults to OPS$ exactly as it always has. What has changed is Oracle's own guidance about when to use it, not its availability.

What OPS$ Accounts Are

A DBA can create a database account tied to an operating system username by prefixing the username with OPS$ (or whatever prefix OS_AUTHENT_PREFIX is set to) and using the IDENTIFIED EXTERNALLY clause instead of IDENTIFIED BY password:

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 can connect to the database without supplying a password:

sqlplus /

The classic use case was Unix cron jobs running database scripts on a schedule. By eliminating the need for a hardcoded password in a shell script, OPS$ accounts avoided the risk of storing credentials in plain text. The tradeoff runs the other way, though: any OS user who can assume the identity of COIN_ADMIN at the operating system level gains automatic database access, with no additional authentication challenge at all. The database is trusting the operating system's own login security entirely, and that security boundary is exactly what current Oracle documentation cautions about directly:

"Oracle strongly recommends that you do not use IDENTIFIED EXTERNALLY with operating systems that have inherently weak login security."

That is the actual, current guidance: a security recommendation to weigh against your specific environment, not a statement that the feature has been withdrawn.

Why the Guidance Has Shifted Even Though the Feature Has Not

Two real trends explain why OS authentication is used less often today than it once was, even though nothing stops you from configuring it. First, the security boundary between the operating system and the database is only as strong as the operating system's own login controls, and a compromised OS account automatically compromises the associated database account with no second check. Second, modern enterprise environments increasingly run Oracle on shared infrastructure, virtualized hosts, and cloud platforms where the OS identity of a connecting process is a considerably less reliable signal than it was on a dedicated, physically controlled Unix server decades ago. Neither trend removed the feature; both make it a weaker choice than it used to be relative to the alternatives below, which is a genuinely different claim than "this no longer works."

Strategy 1: Password File Authentication

For DBAs who need to perform privileged administrative operations, particularly remote SYSDBA connections, the password file is a strong option regardless of whether OS authentication is also in use. 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

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, has secure alternatives worth strong consideration even though OPS$ itself still works.

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, visually similar to the old sqlplus / syntax, but backed by a secure encrypted wallet rather than OS identity. This is a genuinely stronger option than OPS$ for automated scripts, since it does not depend on trusting the operating system's own login boundary at all.

Strategy 3: Centrally Managed Users (CMU)

Oracle Centrally Managed Users 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 a similar password-free connection experience to OPS$ accounts, but backed by Kerberos ticket validation rather than raw OS identity, a meaningfully stronger security model since the ticket itself carries cryptographic proof rather than relying on trusting whichever OS account happens to be logged in. RADIUS authentication serves a similar purpose for organizations with existing RADIUS infrastructure, commonly used for network access control extended to database access.

Strategy 5: Schema-Only Accounts

Current Oracle releases support schema-only accounts, database schemas that own objects but cannot be used to log in directly. This addresses a common pattern where application schemas need 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 at all. 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. This is unrelated to OPS$ specifically, but solves an adjacent problem worth knowing about in the same context: keeping an application's object owner separate from any account capable of interactive login.

Strategy 6: Cloud and Web-Based Authentication

In Oracle Cloud Infrastructure environments, Identity and Access Management (IAM) integration allows database users and roles to be mapped to OCI IAM users and groups, and similarly to Microsoft Entra ID for Azure-based deployments, as covered in Lesson 7. Authentication is handled by the cloud provider's identity service, eliminating any dependency on OS-level accounts on the database host entirely.

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 an Approach

The right choice depends on the specific use case, and OS authentication genuinely remains one legitimate option among several rather than an unavailable one:

1. Automated scripts and cron jobs. Oracle Wallet with external password store is generally the stronger choice over OPS$ accounts, since it does not tie database access to OS-level login security at all. OPS$ still works if you have a specific reason to prefer it, but Wallet is worth defaulting to for new work.
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 with proxy authentication for application connections, regardless of what authentication method the application's actual connecting user relies on.
5. Legacy environments already relying on OPS$. If you inherit a system using OS authentication and it is running on a properly secured, dedicated host with strong OS login controls, migrating away is a security improvement worth planning, but not an urgent fix for something broken; the mechanism itself still functions correctly.

Summary

OPS$ accounts and OS authentication remain fully available in Oracle AI Database 26ai; IDENTIFIED EXTERNALLY and OS_AUTHENT_PREFIX are current, documented features, not deprecated ones. What has genuinely changed is the security calculus: tying database access to OS identity creates a weaker security boundary in modern multi-tenant and cloud environments than it did on a dedicated, tightly controlled server, and Oracle's own documentation explicitly cautions against it on operating systems with weak login security. Oracle provides a strong set of alternatives worth preferring for new work: password files for privileged administrative access, Oracle Wallet for automated script authentication, Centrally Managed Users and Kerberos for enterprise single sign-on, and schema-only accounts for application schemas that should never be used as interactive logins. Each is a genuine security improvement over OPS$ for the scenario it targets, which is a different, more honest claim than saying OPS$ no longer works at all.