Authentication of Database Administrators

You can authenticate database administrators by using strong authentication, from the operating system, or from the database using passwords.

About Authentication of Database Administrators

Database administrators perform special administrative operations, such as shutting down or starting databases.

Oracle Database provides methods to secure the authentication of database administrators who have the SYSDBA, SYSOPER, SYSBACKUP, SYSDG, or SYSKM administrative privilege.

Strong Authentication, Centralized Management for Administrators

Strong authentication methods for centrally managed databases include directory authentication, Kerberos authentication, and SSL authentication.

About Strong Authentication for Database Administrators

Strong authentication lets you centrally control SYSDBA and SYSOPER access to multiple databases.

Consider using this type of authentication for database administration for the following situations:

To enable the Oracle Internet Directory server to authorize SYSDBA and SYSOPER connections, use one of the following methods described in this section, depending on your environment.

Configuring Directory Authentication for Administrative Users

Oracle Internet Directory configures directory authentication for administrative users.

  1. Configure the administrative user by using the same procedures you would use to configure a typical user.

  2. In Oracle Internet Directory, grant the SYSDBA or SYSOPER administrative privilege to the user for the database that this user will administer.

    Grant SYSDBA or SYSOPER only to trusted users.

  3. Set the LDAP_DIRECTORY_SYSAUTH initialization parameter to YES:

ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;
When set to `YES`, the `LDAP_DIRECTORY_SYSAUTH` parameter enables `SYSDBA` and `SYSOPER` users to authenticate to the database by using a strong authentication method.
  1. Set the LDAP_DIRECTORY_ACCESS parameter to either PASSWORD or SSL. For example:
ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = PASSWORD;
Ensure that the `LDAP_DIRECTORY_ACCESS` initialization parameter is not set to `NONE`. Setting this parameter to `PASSWORD` or `SSL` ensures that users can be authenticated using the `SYSDBA` or `SYSOPER` administrative privileges through Oracle Internet Directory.

In an Oracle Real Application Clusters (Oracle RAC) environment, ensure that all instances have the same `LDAP_DIRECTORY_ACCESS` setting, either through the `ALTER SYSTEM` statement or through the `init.ora` file.

In an Oracle Data Guard or Active Data Guard environment, ensure that the standby database has the same `LDAP_DIRECTORY_ACCESS` setting as the primary database. In this environment, the `ALTER SYSTEM` statement propagates its settings from the primary database to the standby database. If you choose to update the `init.ora` file, remember that the `init.ora` parameters are used by both the primary database and the standby database, so you do not need to manually propagate this setting from one database to the other.

Afterward, this user can log in by including the net service name in the CONNECT statement in SQL*Plus. For example, to log on as SYSDBA if the net service name is orcl:

CONNECT someuser@orcl AS SYSDBA
Enter password: password

If the database is configured to use a password file for remote authentication, Oracle Database checks the password file first.

Configuring Kerberos Authentication for Administrative Users

Oracle Internet Directory can be used to configure Kerberos authentication for administrative users.

  1. Configure the administrative user by using the same procedures you would use to configure a typical user.

    See Configuring Kerberos Authentication, for more information.

  2. Configure Oracle Internet Directory for Kerberos authentication.

    See Oracle Database Enterprise User Security Administrator’s Guide for more information.

  3. In Oracle Internet Directory, grant the SYSDBA or SYSOPER administrative privilege to the user for the database that this user will administer.

    Grant SYSDBA or SYSOPER only to trusted users. See Guidelines for Securing User Accounts and Privileges for advice on this topic.

  4. Set the LDAP_DIRECTORY_SYSAUTH initialization parameter to YES:

ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;
When set to `YES`, the `LDAP_DIRECTORY_SYSAUTH` parameter enables `SYSDBA` and `SYSOPER` users to authenticate to the database by using strong authentication methods. See [*Oracle Database Reference*](unilink:REFRN10281) for more information about `LDAP_DIRECTORY_SYSAUTH`.
  1. Set the LDAP_DIRECTORY_ACCESS parameter to either PASSWORD or SSL. For example:
ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = SSL;
Ensure that the `LDAP_DIRECTORY_ACCESS` initialization parameter is not set to `NONE`. Setting this parameter to `PASSWORD` or `SSL` ensures that users can be authenticated using `SYSDBA` or `SYSOPER` through Oracle Internet Directory. See [*Oracle Database Reference*](unilink:REFRN10251) for more information about `LDAP_DIRECTORY_ACCESS`.

In an Oracle Real Application Clusters (Oracle RAC) environment, ensure that all instances have the same `LDAP_DIRECTORY_ACCESS` setting, either through the `ALTER SYSTEM` statement or through the `init.ora` file.

In an Oracle Data Guard or Active Data Guard environment, ensure that the standby database has the same `LDAP_DIRECTORY_ACCESS` setting as the primary database. In this environment, the `ALTER SYSTEM` statement propagates its settings from the primary database to the standby database. If you choose to update the `init.ora` file, remember that the `init.ora` parameters are used by both the primary database and the standby database, so you do not need to manually propagate this setting from one database to the other.

Afterward, this user can log in by including the net service name in the CONNECT statement in SQL*Plus. For example, to log on as SYSDBA if the net service name is orcl:

CONNECT /@orcl AS SYSDBA

Configuring User Authentication with Transport Layer Security

Both the client and server side can authenticate administrative users with Transport Layer Security (TLS).

  1. For both the client and the server, get user certificates signed by the same root Certificate Authority (CA) certificate, either public or self-signed.

  2. Configure the client to use TLS:

    1. Add the signed user certificate to the client wallet. The CA root trust certificate should already be in the client wallet. Ensure that any intermediate certificates that are required for the user certificate are added to the wallet before you add the user certificate.

      You can use orapki to configure the client wallet and user certificate.

    2. Set TLS as an authentication service in the sqlnet.ora file.

      SSL_CLIENT_AUTHENTICATION=TRUE

    3. Optionally, for better security, set the client to use full or partial DN matching.

      When DN matching is enabled, the client will check the server certificate to ensure that host names will match what the client is configured to match. You perform this step when you enable Oracle Internet Directory to use TLS. Note: The database client and server will use the strongest TLS protocol and cipher suite to establish a connection. Therefore, you do not need to specify the TLS version and cipher suites unless you have specific security requirements that require it. Be aware that if you set specific TLS versions and cipher suites, you will need to update the configuration when the older versions are no longer used.

  1. Configure the listener for TLS on the client, the listener, and server.

    1. Create a separate listener entry for TLS connections using the secure database port 1522.

      For example:

      LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = example.com)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCPS)(HOST = example.com)(PORT = 1522))
    )
  )

    2. Comment out the non-TLS listener entry (for example, the line with PROTOCOL = TCP) or leave it in for non-TLS required connections.

    3. Add SSL_CLIENT_AUTHENTICATION = FALSE to the sqlnet.ora file so the database server authenticates the client, not the listener.

      The same wallet that the server uses can be used by the listener, along with the same server certificate. The listener will look for the wallet using the standard Oracle Database wallet search order. Alternatively, you can specify the wallet location in the listener by setting the WALLET_LOCATION parameter. (You cannot use the WALLET_ROOT parameter for this purpose, because the listener cannot use it.)

  2. Configure the server to use TLS:

    1. In the sqlnet.ora file, set SSL_CLIENT_AUTHENTICATION to FALSE (or OFF) to enable one-way TLS.

    2. For the TLS server wallet, do the following:

      • Set the WALLET_ROOT parameter to a location for the TLS server.

      • Create the tls directory under WALLET_ROOT/pdb_guid.

      • Move the TLS server wallet to the WALLET_ROOT/pdb_guid/tls directory.

    3. In the sqlnet.ora file, add the following parameter:

      SSL_CLIENT_AUTHENTICATION=TRUE

      If you want to restrict authentication to only TCPS, then set AUTHENTICATION_SERVICES to TCPS.

  3. Create a new schema or alter an existing schema to map to the user.

    CREATE USER user_name IDENTIFIED EXTERNALLY AS 'user DN on certificate';

  4. Grant the database schema to appropriate administrative privileges, such as SYSDBA, SYSOPER, and so on.

    Administrative users with TLS authentication can authenticate with TLS. To enable these users, grant the appropriate administrative privilege to the user schema. The administrative user must log in using this administrative privilege. For example, for a user who was granted the SYSOPER administrative privilege:

    CONNNECT /@pdb_name AS SYSOPER

Afterward, this user can log in by including the net service name in the CONNECT statement in SQL*Plus. For example, to log on as SYSDBA if the net service name is orcl:

CONNECT /@orcl AS SYSDBA

Authentication of Database Administrators by Using the Operating System

For both Windows and UNIX systems, you use DBA-privileged groups to authenticate for the operating system.

Operating system authentication for a database administrator typically involves establishing a group on the operating system, granting DBA privileges to that group, and then adding the names of persons who should have those privileges to that group. (On UNIX systems, the group is the dba group.)

Note: In a multitenant environment, you can use operating system authentication for a database administrator only for the CDB root. You cannot use it for for PDBs, the application root, or application PDBs.

On Microsoft Windows systems:

Authentication of Database Administrators by Using Their Passwords

Password files are used to authenticate database administrators.

That is, Oracle Database users who have been granted the SYSDBA, SYSOPER, SYSASM, SYSBACKUP, SYSDG, and SYSKM administrative privileges are first authenticated using database-specific password files.

These privileges enable the following activities:

Risks of Using Password Files for Database Administrator Authentication

Be aware that using password files may pose security risks.

For this reason, consider using the authentication methods described in Strong Authentication, Centralized Management for Administrators.

Examples of password security risks are as follows: