Configuring Operating System Users for a PDB

The DBMS_CREDENTIAL.CREATE_CREDENTIAL procedure configures user accounts to be operating system users for a pluggable database (PDB).

About Configuring Operating System Users for a PDB

Instead of the oracle operating system user, a specific user account can be the operating system user for a pluggable database (PDB).

If you do not set a specific user to be the operating system user for the PDB, then by default the PDB uses the oracle operating system user. For the root, you can use the oracle operating system user when you must interact with the operating system.

For better security, Oracle recommends that you set a unique operating system user for each PDB. Doing so helps to ensure that operating system interactions are performed as a less powerful user than the oracle operating system user, and helps to protect data that belongs to one PDB from being accessed by users who are connected to other PDBs.

PDB_OS_CREDENTIAL Initialization Parameter

When the database accesses an external procedure with the extproc agent, the PDB_OS_CREDENTIAL initialization parameter determines the identity of the operating system user employed when interacting with the operating system from a PDB.

Using an operating system user described by a credential whose name is specified as a value of the PDB_OS_CREDENTIAL initialization parameter can ensure that operating system interactions are performed as a less powerful user. In this way, the feature protects data belonging to one PDB from being accessed by users connected to another PDB. A credential is an object that is created using the CREATE_CREDENTIAL procedure in the DBMS_CREDENTIAL package.

The Oracle operating system user is usually a highly privileged user. Using this account for operating system interactions is not recommended. Also, using the same OS user for operating system interactions from different PDBs might compromise data belonging to a given PDB.

Configuring an Operating System User for a PDB

The DBMS_CREDENTIAL.CREATE_CREDENTIAL procedure can set an operating system user for a pluggable database (PDB).

  1. Log in to the CDB root as a user who has the EXECUTE privilege for the DBMS_CREDENTIAL PL/SQL package and the ALTER SYSTEM system privilege.

    For example:

    sqlplus c##sec_admin
Enter password: password

  2. Run the DBMS_CREDENTIAL.CREATE_CREDENTIAL procedure to create an Oracle credential for the operating system user.

    For example, to set the credential for a user named os_admin:

    BEGIN
 DBMS_CREDENTIAL.CREATE_CREDENTIAL (
    credential_name => 'PDB1_OS_USER',
    username        => 'os_admin',
    password        => 'password');
END;
/

  3. Connect to the PDB for which the operating system user will be used.

    For example:

    CONNECT cc##sec_admin@pdb_name
Enter password: password

    To find the available PDBs in a CDB, log in to the CDB root container and then query the PDB_NAME column of the DBA_PDBS data dictionary view. To check the current container, run the show con_name command.

  4. Set the PDB_OS_CREDENTIAL initialization parameter for the user whose credential was set in Step 2.

    For example:

    ALTER SYSTEM SET PDB_OS_CREDENTIAL = PDB1_OS_USER SCOPE = SPFILE;

    The PDB_OS_CREDENTIAL parameter is a static parameter, so you must set it using the SCOPE = SPFILE clause.

  5. Restart the CDB.

    SHUTDOWN IMMEDIATE
STARTUP

Related Topics

Setting the Default Credential in a PDB

You can set the database property DEFAULT_CREDENTIAL for a specified PDB.

A default credential is useful when accessing objects in object storage by using functionality that does not allow explicit specification of a credential object, or when specifying a credential is optional. Examples include the following:

For more information about Data Pump and Object Storage, see Oracle Data Pump.

For read-only tablespaces on Object Storage, accessing the data files of the tablespace requires authentication and authorization in OCI. A credential with read and write privileges must exist for the bucket where the files of the read-only tablespace are stored. Oracle Database uses DEFAULT_CREDENTIAL to move the files to Object Storage and for subsequent access to the tablespace stored in Object Storage.

For more information about Read-Only Tablespaces on Object Storage, see Using Read-Only Tablespaces on Object Storage in Oracle AI Database Administrator’s Guide.

  1. Log in to a PDB with administrator privileges.

  2. Use the ALTER DATABASE statement to set the default credential.

    For example, to set the credential to SYSTEM.HR_CRED:

    ALTER DATABASE PROPERTY SET DEFAULT_CREDENTIAL = 'SYSTEM.HR_CRED';

    The following example assumes that a default credential exists. This command imports data from an object store , prefacing the URL with the string DEFAULT_CREDENTIAL:

    impdp hr@pdb1 table_exists_action=replace \
  dumpfile=DEFAULT_CREDENTIAL:https://example.com/ostore/obucket/myt.dmp

External (Non-Database) User Authentication and Access to the Database

External authentication centralizes user security for database access improving security and reducing database administrative workload. You can perform external authentication with either local database authorization or external authorization.

External Authentication with Local Database Authorization

Local database authorization can be configured using the operating system, Kerberos authentication, public key infrastructure (PKI) cerification authentication, and RADIUS authentication.

About External Authentication with Local Database Authorization

This external authentication model creates a one-to-one mapping of the external user to the database schema (user).

External users are mapped one-to-one to a database schema (user). A database schema is commonly referred to as a database user and a database account. These three terms can be used interchangeably. The external user authorization is through the existence of the mapping to the database schema and the associated direct grant of privileges and roles to the mapped schema.

Security is vastly improved over local database user management since credentials are managed in a single place, frequently as part of a single-sign on technology. Only one credential needs to be memorized by the user and password resets are most likely managed automatically instead of by DBAs for each database. Removing user access is as simple as expiring the external user account instead of tracking down every database user account.

Oracle Database supports the following technologies for this model:

Operating System Authentication

Users can be authenticated to the Oracle Database CDB root through operating system authentication.

Using the operating system to authenticate users has both advantages and disadvantages. This is only applicable to the CDB root. This is not supported with PDB or application containers.

This functionality has the following benefits:

However, you should be aware of the following drawbacks to using the operating system to authenticate users:

Kerberos Authentication

Kerberos is a trusted third-party authentication system that relies on shared secrets.

Kerberos presumes that the third party is secure, and provides single sign-on capabilities, centralized password storage, database link authentication, and enhanced PC security. It does this through a Microsoft Active Directory Kerberos service or an MIT Kerberos compatible service.

Related Topics

Public Key Infrastructure Centificate Authentication

Authentication systems based on public key infrastructure (PKI) issue digital certificates to user clients.

These clients can use these certificates to authenticate directly to servers in the enterprise without directly involving an authentication. Oracle Database provides a PKI for using public keys and certificates, consisting of the following components:

Related Topics

RADIUS Authentication

Remote Authentication Dial-In User Service (RADIUS) is a standard lightweight protocol used for user authentication, authorization, and accounting.

Oracle Database provides a RADIUS API to securely connect with RADIUS services

Related Topics

External Authentication with External Authorization

External authorization can be configured centrally managed users, Microsoft Entra ID, Oracle Cloud Infrastructure Identity and Access Management, and Oracle Enterprise User Security.

About External Authentication with External Authorization

This model allows the identity service administrators to fully manage an organization’s joiners, movers, and leavers within the identity service.

External users are authenticated externally as with the previous model, but the external user can be mapped exclusively to a schema or more commonly in this model, many external users are mapped to the same schema (shared schema). The shared schema is mapped to an identity group or some other grouping mechanism unique to the identity service. The external user can also be optionally mapped to a database global role through membership in an identity group or grouping mechanism).

A common deployment model using this model is to map all users to a single shared schema with low or no privileges and grant the differentiated privileges through global roles. Using this mechanism, a joiner is authorized to the database by the identity service administrator by adding them to one or more identity groups. Someone moving in the organization can have their database authorization changed by moving them from one group to another. When a user leaves the company or doesn’t require database access anymore, they will be removed from all identity groups mapped to databases.

This is another step up in security since the identity team manages the database authorizations, leaving the database administrators free to manage the database instead of individual users.

Oracle Database supports the following technologies for this model:

Centrally Managed Users with Microsoft Active Directory

You can configure Oracle Database to directly connect with Microsoft Active Directory for authentication and authorization using centrally managed users (CMU).

Password, Kerberos and PKI certificate-based authentication are supported with CMU-AD. You can map users exclusively to a database schema or to a shared schema through membership in a group mapped to a global shared schema. Additional roles for the user can optionally be available through additional group memberships mapped to database global roles.

Related Topics

Microsoft Entra ID Integration

Microsoft Azure users can connect to the database directly using Microsoft Entra ID OAuth2 access tokens.

Users authenticate to Microsoft Entra ID along with any associated multi-factor authentication configured by the Entra ID administrator. Microsoft Azure users and groups are assigned to the registered database app roles in Entra ID. These app roles are mapped to database schemas and global roles.

Related Topics

Oracle Cloud Infrastructure Identity and Access Management Integration

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) users can connect to an Oracle DBaaS database.

Users authenticate to OCI IAM along with any associated multi-factor authentication configured by the IAM administrator. IAM user and groups are mapped to database schemas and global roles for authorization.

Related Topics

Oracle Enterprise User Security

Oracle Identity Directory (OID) users can access the Oracle Database through password, Kerberos, and PKI certificate authentication.

Note: Oracle Enterprise User Security is deprecated starting with Oracle AI Database 26ai.

Shared schema mapping is done through directory subtrees and Enterprise Roles grant additional roles and privileges to the OID user.

Related Topics