Administrative access can be established through the database host's operating system or a configured database password file. An access review must include both, together with powerful database role and privilege grants. Record who can connect, by which path, for which duty, and in which host/database/container scope.
Oracle DBA Lesson 68 Part 2 — Audit the Paths to Administrative Privilege
Local operating system authentication
Oracle installation assigns operating system groups to administrative privileges.
| Installed group purpose | Local connection privilege | Typical duty |
|---|---|---|
| OSDBA | SYSDBA | Broad database administration |
| OSOPER | SYSOPER | A restricted set of instance operations |
| OSBACKUPDBA | SYSBACKUP | Backup and recovery |
| OSDGDBA | SYSDG | Data Guard administration |
| OSKMDBA | SYSKM | Encryption keystore administration |
| OSRACDBA | SYSRAC | Clusterware agent connection path |
These names are group purposes. The Linux group names come from the installation and can differ from the purpose names. Common defaults include dba and backupdba. Confirm the installed mapping for the intended Oracle home. Membership in an unrelated group with a familiar name does not establish that mapping.
On the intended database host, inspect the current host, the process identity, the effective groups, and the selected environment:
hostname
id
printf '%s\n' "$ORACLE_HOME" "$ORACLE_SID"hostname identifies where the shell is running. id without an account argument reports the current process's user and group IDs and shows its effective session membership. The two environment values identify the selected Oracle home and instance. Confirm that the sqlplus executable resolves to the intended installation. A stale PATH or an inherited connection environment can select a different home.
With database-host OSDBA membership and the correct local environment:
sqlplus / as sysdbaThe slash requests external authentication. In this local Linux example, Oracle uses the operating system identity and configured group membership. No database password is supplied. AS SYSDBA requests the administrative privilege, and the resulting administrative session uses SYS as its session user. That session identity alone does not identify the original human or host account, so retain the OS and database audit evidence when attributing activity.
For an OSBACKUPDBA member, the corresponding local request is:
sqlplus / as sysbackupThe named privilege determines the administrative session. SYSBACKUP supports backup and recovery. It does not assign every SYSDBA capability.
Jump-host scope
A Linux shell on a jump host has the jump host's identity, group membership, and environment. Local database-host authentication uses the process on the actual database host and that installation's group mapping. Inspect that database-host session and its database environment before interpreting local administrative access.
Remote operating system authentication across arbitrary hosts follows separate rules. Windows domain-based remote OS authentication has its own documented conditions. A jump-host shell by itself is insufficient evidence of local database-host OSDBA access.
See database administrator authentication.
Named remote password-file connection
A common account C##BACKUP_ADMIN, a root service alias db_admin_service, a supported password file, and a SYSBACKUP grant for the intended scope form a named remote password-file connection. From the configured client:
sqlplus -L c##backup_admin@db_admin_service as sysbackup
Enter password:Enter the existing account's password interactively, and keep it out of command arguments, shell history, and spools. SQL*Plus -L requests a single initial login attempt. The service alias resolves the database destination from the network configuration. In this password-file arrangement, Oracle authenticates the account with the password file and checks the requested administrative privilege. The password prompt keeps the secret out of the command text. It does not configure encrypted transport; that depends on the network configuration.
The database password file is a separate persistent authentication file. It may be stored in a filesystem on disk or in ASM. It supports administrative authentication when the database is not open and ordinary dictionary-based login is unavailable. A usable remote connection also depends on the database, listener, and service state. An unavailable or idle instance may require a configured administrative or static service. A password-file entry does not make an unreachable endpoint connectable.
Password-file authentication can also be used locally. When matching operating system membership applies, operating system authentication takes precedence for that local administrative connection. A successful local login from an OSDBA account does not prove that a password-file password was tested.
After a successful AS SYSBACKUP connection, the administrative session user is SYSBACKUP. Oracle's documented current schema is SYS. Preserve the named connecting identity and the audit context when attributing work. These administrative semantics differ from the ordinary unproxied account session in Part 1.
See authentication of database administrators and SQL*Plus Quick Start.
Password-file configuration
In an administrative SQL*Plus session:
SHOW CON_NAME
SHOW PARAMETER remote_login_passwordfileSHOW is a SQL*Plus command. REMOTE_LOGIN_PASSWORDFILE controls whether Oracle checks for a password file.
| Value | Interpretation |
|---|---|
| EXCLUSIVE | The file serves instances of the same database and can include SYS and named non-SYS administrators. Grants and updates depend on the supported format and configuration. |
| SHARED | The file can serve multiple databases, but the database disables password-file modifications. Administrative grants/revokes and password updates have important restrictions. |
| NONE | Oracle ignores the password file; the documented administrative authentication path is operating system authentication. |
EXCLUSIVE is the documented default. A missing file makes EXCLUSIVE or SHARED behave like NONE. The configured value is one piece of evidence. Also inspect the actual file location, format, and relevant account entries. This parameter is not dynamically modifiable, and it is not independently modifiable inside a PDB.
SELECT file_name, format, is_asm
FROM v$passwordfile_info;Interpret the documented fields for the installed release. Format affects supported functionality. The separation-of-duty privileges introduced in 12c need a compatible password-file format.
See REMOTE_LOGIN_PASSWORDFILE, V$PASSWORDFILE_INFO, and SHOW.
Privilege flags and container scope
From an administrative session in the intended scope:
SELECT username, sysdba, sysoper, sysbackup,
sysdg, syskm, con_id
FROM v$pwfile_users
ORDER BY username, con_id;The illustrated password-file row is:
| USERNAME | SYSDBA | SYSOPER | SYSBACKUP | SYSDG | SYSKM | CON_ID |
|---|---|---|---|---|---|---|
| C##BACKUP_ADMIN | FALSE | FALSE | TRUE | FALSE | FALSE | 1 |
The row shows a common account with a root-local SYSBACKUP administrative grant. SYSBACKUP TRUE is that administrative privilege, and SYSDBA FALSE keeps the two flags distinct. CON_ID = 1 means the row pertains to the root. A C## name alone does not establish an all-container grant. A grant with CONTAINER=ALL is a different scope.
Oracle documents CON_ID = 0 for data pertaining to the whole CDB or a non-CDB, 1 for root-only data, and other IDs for the applicable container. Read the rows from the administrative context that can see the intended scope. For a fuller review, also read COMMON. A value of YES indicates an administrative privilege granted with CONTAINER=ALL:
SELECT username, sysdba, sysbackup, common, con_id
FROM v$pwfile_users
ORDER BY username, con_id;The documented view also exposes SYSASM and account and authentication metadata. Select additional fields when the review needs them. A row does not by itself show a successful connection, recent use, or complete access attribution.
See V$PWFILE_USERS.
Complete the access inventory
Password-file users cover one authentication store. Also review database-host OSDBA, OSBACKUPDBA, and the other installed administrative group memberships. Effective membership can come from local files or from a directory identity service. Listing only /etc/group can miss directory-managed or effective access. A group change may require a refreshed host login before it affects a process.
The inventory should identify:
| Evidence | What to establish |
|---|---|
| Intended host and Oracle home | Which installation and instance the mapping controls |
| Effective OS groups | Which host identities can request each local administrative privilege |
| Password-file configuration and entries | Named accounts, actual file/format, requested privileges and container scope |
| Powerful database grants | Ordinary role and system privilege paths, including nested role relationships |
| Assigned duty and attribution | Why access is needed, who owns the identity and how use is attributable |
The DBA role contains many ordinary database system privileges. It does not include SYSDBA, SYSOPER, SYSBACKUP, SYSDG, or SYSKM. Review it as a powerful ordinary privilege path alongside administrative authentication.
A starting query for direct DBA role grants in the connected container is:
SELECT grantee, granted_role, admin_option
FROM dba_role_privs
WHERE granted_role = 'DBA'
ORDER BY grantee;This query does not resolve nested roles, every powerful system privilege, PUBLIC access, operating system delegation, or every common and local grant. Expand the review to the actual scope.
In a cluster, SYSRAC is reserved for the Oracle Clusterware agent's operating system authentication. It cannot be granted to database users, and it is unsupported in a password file. Record the configured agent and host path. SYSRAC is not an ordinary named password-file grant.
See DBA_ROLE_PRIVS.
Recap
Review administrative access through the database host's operating system groups, the password file, and powerful ordinary grants. Group purposes such as OSDBA and OSBACKUPDBA map to local privileges such as SYSDBA and SYSBACKUP. Confirm the Linux group names installed for that Oracle home. A local sqlplus / as sysdba connection uses the database host's operating system identity and supplies no database password. The session user is SYS. AS SYSBACKUP makes the session user SYSBACKUP, with current schema SYS, and does not assign every SYSDBA capability. When matching operating system membership applies, local operating system authentication takes precedence, and a successful OSDBA login does not prove that a password-file password was tested. A jump-host shell carries the jump host's identity and is insufficient evidence of database-host OSDBA access.
The password file is a separate authentication file on a filesystem or in ASM. It can authenticate named administrators when the database is not open. REMOTE_LOGIN_PASSWORDFILE defaults to EXCLUSIVE and can also be SHARED or NONE. A missing file makes EXCLUSIVE or SHARED behave like NONE. V$PWFILE_USERS shows the privilege flags and CON_ID. The illustrated C##BACKUP_ADMIN row is root-local SYSBACKUP: SYSBACKUP is TRUE, SYSDBA is FALSE, and CON_ID is 1. COMMON = YES means the administrative privilege was granted with CONTAINER=ALL. The DBA role is a separate ordinary privilege path and does not include those administrative privileges. A direct DBA_ROLE_PRIVS query does not expand nested roles. SYSRAC belongs to the Clusterware agent's operating system authentication and is unsupported in the password file. Record who can connect, by which path, for which duty, and in which host, database, and container scope.
No comments:
Post a Comment