# Database Access with Oracle Exadata

Teleport can provide secure access to Oracle Exadata via the [Teleport Database Service](https://goteleport.com/docs/enroll-resources/database-access.md). This allows for fine-grained access control through [Teleport's RBAC](https://goteleport.com/docs/enroll-resources/database-access/rbac.md).

In this guide, you will:

1. Configure your Oracle Exadata database with mTLS authentication.
2. Add the database to your Teleport cluster.
3. Connect to the database via Teleport.

## How it works

The Teleport Database Service authenticates to your Oracle Exadata database using mutual TLS. Oracle Exadata trusts the Teleport certificate authority for database clients, and presents a certificate signed by either the Teleport database CA or a custom CA. When a user initiates a database session, the Teleport Database Service presents a certificate signed by Teleport. The authenticated connection then proxies client traffic from the user.

**Teleport Enterprise (Self-Hosted)**

![Enroll Oracle with a self-hosted Teleport cluster](/docs/assets/images/oracle_selfhosted-b86a597fc5b6d731beff75a9bd8b71b3.png)

**Teleport Enterprise (Cloud)**

![Enroll Oracle with a cloud-hosted Teleport cluster](/docs/assets/images/oracle_selfhosted_cloud-83cd919797f36b5e688024a1125e0585.png)

## Prerequisites

- A running Teleport Enterprise cluster. If you want to get started with Teleport, [sign up](https://goteleport.com/signup) for a free trial or [set up a demo environment](https://goteleport.com/docs/get-started/deploy-community.md).

- The `tctl` and `tsh` clients.

  Installing `tctl` and `tsh` clients

  1. Determine the version of your Teleport cluster. The `tctl` and `tsh` clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at `/v1/webapi/find` and use a JSON query tool to obtain your cluster version. Replace teleport.example.com:443 with the web address of your Teleport Proxy Service:

     ```
     $ TELEPORT_DOMAIN=teleport.example.com:443
     $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
     ```

  2. Follow the instructions for your platform to install `tctl` and `tsh` clients:

     **Mac**

     Download the signed macOS .pkg installer for Teleport, which includes the `tctl` and `tsh` clients:

     ```
     $ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
     ```

     In Finder double-click the `pkg` file to begin installation.

     ---

     DANGER

     Using Homebrew to install Teleport is not supported. The Teleport package in Homebrew is not maintained by Teleport and we can't guarantee its reliability or security.

     ---

     **Windows - Powershell**

     ```
     $ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
     Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
     NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
     Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
     ```

     **Linux**

     All of the Teleport binaries in Linux installations include the `tctl` and `tsh` clients. For more options (including RPM/DEB packages and downloads for i386/ARM/ARM64) see our [installation page](https://goteleport.com/docs/installation.md).

     ```
     $ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ cd teleport
     $ sudo ./install
     Teleport binaries have been copied to /usr/local/bin
     ```

* Oracle Exadata server instance 19c or later.
* The `sqlcl` [Oracle client](https://www.oracle.com/pl/database/sqldeveloper/technologies/sqlcl/) installed and added to your system's `PATH` environment variable or any GUI client that supports JDBC Oracle thin client.
* To check that you can connect to your Teleport cluster, sign in with `tsh login`, then verify that you can run `tctl` commands using your current credentials. For example, run the following command, assigning teleport.example.com to the domain name of the Teleport Proxy Service in your cluster and email\@example.com to your Teleport username:
  ```
  $ tsh login --proxy=teleport.example.com --user=email@example.com
  $ tctl status
  Cluster  teleport.example.com
  Version  19.0.0-dev
  CA pin   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
  ```
  If you can connect to the cluster and run the `tctl status` command, you can use your current credentials to run subsequent `tctl` commands from your workstation. If you host your own Teleport cluster, you can also run `tctl` commands on the computer that hosts the Teleport Auth Service for full permissions.

## Step 1/6. Configure Oracle Exadata

---

NOTE

This guide assumes default configuration of the Oracle Exadata system. In particular:

- Preconfigured TCPS listener.
- An existing database certificate in the grid wallet.
- A single Oracle Exadata VM is accessible to the `opc` user through SSH with a hostname demodb-vm. Repeat the steps to configure additional VMs.
- The SCAN DNS name is demodb-vm-scan.exadatadomain.oke.oraclevcn.com.

Adjust the commands to match your configuration.

---

### Update per-database configuration

Connect to the Oracle Exadata VM by logging in as the `opc` user and then switch to the `oracle` user:

```
$ ssh opc@demodb-vm
$ sudo su - oracle
```

For each database-specific Oracle home, update the `$ORACLE_HOME/network/admin/sqlnet.ora` file with the following entries:

```
SSL_CLIENT_AUTHENTICATION = TRUE
SQLNET.AUTHENTICATION_SERVICES = (ALL)

```

For example, if there is a database named `spark`, the `oracle` user should have access to the automatically generated `/home/oracle/spark.env` file, which contains database-specific environment variables. After sourcing this file, the path `$ORACLE_HOME/network/admin/sqlnet.ora` will point to the `sqlnet.ora` file for the `spark` database and its associated Oracle home.

```
Load environment variables for the 'spark' database
$ . spark.env

Edit the configuration file at $ORACLE_HOME/network/admin/sqlnet.ora
...
```

Repeat these steps for each additional database or database home as required.

### Configure Oracle user account

Your Oracle user accounts must be configured to require a valid client certificate.

**New user**

Create new user:

```
CREATE USER alice IDENTIFIED EXTERNALLY AS 'CN=alice';
GRANT CREATE SESSION TO alice;

```

**Existing user**

Alter existing user:

```
ALTER USER alice IDENTIFIED EXTERNALLY AS 'CN=alice';

```

---

WARNING

This operation will void existing authentication methods like password. The certificate-based auth will become the sole method of authentication for this user.

---

### Trust Teleport Database Client CA

Teleport uses mutual TLS authentication with Oracle Exadata. It must be configured with Teleport's certificate authority to be able to verify client certificates.

Export the Teleport Database Client CA on your local machine and copy it to target Oracle Exadata VM.

```
Export Teleport's database client certificate authority
$ tctl auth export --type=db-client > teleport-db-client-ca.crt
Copy the CA to the Oracle Exadata VM
$ scp teleport-db-client-ca.crt opc@demodb-vm:/tmp/teleport-db-client-ca.crt
```

As the `grid` user, update the grid TCPS wallet to trust the Teleport User Database CA.

```
Read the wallet password
$ mkstore -wrl /u01/app/oracle/admin/cprops/cprops_wallet -nologo -viewEntry grid_tcps_wallet_passwd
grid_tcps_wallet_passwd = <wallet password>
Update the grid TCPS wallet; provide the password when prompted
$ orapki wallet add -wallet "/var/opt/oracle/dbaas_acfs/grid/tcps_wallets" -trusted_cert -cert /tmp/teleport-db-client-ca.crt
```

### Enable TLS auth for grid listener

Adjust your grid listener configuration at `$ORACLE_HOME/network/admin/listener.ora` to enable TLS auth with the following entry:

```
SSL_CLIENT_AUTHENTICATION = TRUE

```

### Restart the listener

Once finished, restart the listener.

```
$ lsnrctl stop
$ lsnrctl start
```

## Step 2/6. Collect database configuration data

Export the built-in database certificate from Oracle. Teleport will use this certificate to verify the database connection.

```
Export the database certificate. Update the "-dn" parameter to match your actual setup.
$ orapki wallet export -wallet "/var/opt/oracle/dbaas_acfs/grid/tcps_wallets" -dn "CN=demodb-vm-scan.exadatadomain.oke.oraclevcn.com" -cert /tmp/oracle-server-certificate.crt
```

Save the `/tmp/oracle-server-certificate.crt` file to a temporary location. The final location depends on the Teleport installation method, which will be detailed in the next step.

Check the TCPS address of the local listener. This address will be used by Teleport for the connection. In the example below, the address is 10.20.30.40:2484.

```
$ sqlplus / as sysdba
...
SQL> SHOW PARAMETER local_listener;

. NAME           TYPE   VALUE
. -------------- ------ ------------------------------
. local_listener string (ADDRESS=(PROTOCOL=TCP)(HOST=10.20.30.40)(PORT=1521)),
.                       (ADDRESS=(PROTOCOL=TCPS)(HOST=10.20.30.40)(PORT=2484))
```

## Step 3/6. Configure and Start the Database Service

### Create Teleport join token

The Database Service requires a valid join token to join your Teleport cluster. Run the following `tctl` command and save the token output in `/tmp/token` on the server that will run the Database Service:

```
$ tctl tokens add --type=db --format=text
abcd123-insecure-do-not-use-this
```

### Teleport Database Service

Install and configure Teleport where you will run the Teleport Database Service:

**Linux Server**

To install a Teleport Agent on your Linux server:

The recommended installation method is the cluster install script. It will select the correct version, edition, and installation mode for your cluster.

1. Assign teleport.example.com:443 to your Teleport cluster hostname and port, but not the scheme (https\://).

2. Run your cluster's install script:

   ```
   $ curl "https://teleport.example.com:443/scripts/install.sh" | sudo bash
   ```

On the host where you will run the Teleport Database Service, start Teleport with the appropriate configuration.

Note that a single Teleport process can run multiple different services, for example multiple Database Service agents as well as the SSH Service or Application Service. The step below will overwrite an existing configuration file, so if you're running multiple services add `--output=stdout` to print the config in your terminal, and manually adjust `/etc/teleport.yaml`.

Copy the Oracle Database certificate and make it available at `/var/lib/teleport/oracle-server-certificate.crt` on the Teleport Database Service host.

Run the following command to generate a configuration file at `/etc/teleport.yaml` for the Database Service. Update example.teleport.sh to use the domain name of the Teleport Proxy Service:

```
$ sudo teleport db configure create \
   -o file \
   --token=/tmp/token \
   --proxy=example.teleport.sh:443 \
   --name="oracle" \
   --protocol=oracle \
   --uri="10.20.30.40:2484" \
   --ca-cert-file="/var/lib/teleport/oracle-server-certificate.crt" \
   --labels=env=dev
```

Manually edit the generated config file to include `tls.mode: verify-ca`.

The final entry for the oracle database will look similar to this:

```
db_service:
  enabled: true
  databases:
  - name: oracle
    uri: "10.20.30.40:2484"
    protocol: oracle
    tls:
      mode: verify-ca
      ca_cert_file: /var/lib/teleport/oracle-server-certificate.crt

```

Configure the Teleport Database Service to start automatically when the host boots up by creating a systemd service for it. The instructions depend on how you installed the Teleport Database Service.

**Package Manager**

On the host where you will run the Teleport Database Service, enable and start Teleport:

```
$ sudo systemctl enable teleport
$ sudo systemctl start teleport
```

**TAR Archive**

On the host where you will run the Teleport Database Service, create a systemd service configuration for Teleport, enable the Teleport service, and start Teleport:

```
$ sudo teleport install systemd -o /etc/systemd/system/teleport.service
$ sudo systemctl enable teleport
$ sudo systemctl start teleport
```

You can check the status of the Teleport Database Service with `systemctl status teleport` and view its logs with `journalctl -fu teleport`.

**Kubernetes Cluster**

Create a secret containing the database CA certificate in the same namespace as Teleport using the following command:

```
$ kubectl create secret generic db-ca --from-file=ca.pem=/path/to/oracle-server-certificate.crt
```

Create a file called `values.yaml` with the following content. Update JOIN\_TOKEN to the join token you created earlier using the `tctl tokens add` command:

```
roles: db
proxyAddr: example.teleport.sh:443
enterprise: true
authToken: "JOIN_TOKEN"
databases:
  - name: oracle
    uri: "10.20.30.40:2484"
    protocol: oracle
    static_labels:
      env: dev
    tls:
      mode: verify-ca
      ca_cert_file: /etc/teleport-tls-db/db-ca/ca.pem
extraVolumes:
  - name: db-ca
    secret:
      secretName: db-ca
extraVolumeMounts:
  - name: db-ca
    mountPath: /etc/teleport-tls-db/db-ca
    readOnly: true

```

Teleport provides Helm charts for installing the Teleport Database Service in Kubernetes Clusters.

Configure Helm to fetch Teleport charts from the Teleport Helm repository:

```
$ helm repo add teleport https://charts.releases.teleport.dev
```

Refresh the local Helm cache by fetching the latest charts:

```
$ helm repo update
```

Install the chart:

```
$ helm install teleport-kube-agent teleport/teleport-kube-agent \
  --create-namespace \
  --namespace teleport-agent \
  --version 19.0.0-dev \
  -f values.yaml
```

Make sure that the Teleport Agent pod is running. You should see one `teleport-kube-agent` pod with a single ready container:

```
$ kubectl -n teleport-agent get pods
NAME                    READY   STATUS    RESTARTS   AGE
teleport-kube-agent-0   1/1     Running   0          32s
```

## Step 4/6. (Optional) Configure Teleport to pull audit logs from Oracle Audit Trail

Teleport can pull audit logs from Oracle Audit Trail. In order to enable this feature, you will need to configure Oracle Audit Trail and create a dedicated Teleport user that will be used to fetch audit events from Oracle Audit Trail.

Create an internal Oracle `teleport` user that will fetch audit events from Oracle Audit Trail:

```
CREATE USER teleport IDENTIFIED EXTERNALLY AS 'CN=teleport';
GRANT CREATE SESSION TO teleport;
GRANT SELECT ON dba_audit_trail TO teleport;
GRANT SELECT ON V_$SESSION TO teleport;

```

Enable the table in Oracle Audit Trail:

```
ALTER system SET audit_trail=db,extended scope=spfile;

```

Restart your Oracle instance to propagate audit trail changes.

Enable Oracle auditing for the `alice` user:

```
AUDIT ALL STATEMENTS by alice BY access;

```

You must enable auditing for each Teleport user that will be used to connect to Oracle. Additionally you can create a different audit policy for each user.

Configure the Teleport Database Service to pull audit logs from Oracle Audit Trail:

```
db_service:
  enabled: true
  databases:
  - name: oracle
    protocol: "oracle"
    uri: "10.20.30.40:2484"
    oracle:
      audit_user: "teleport"
    tls:
      mode: verify-ca
      ca_cert_file: /var/lib/teleport/oracle-server-certificate.crt

```

Teleport doesn't clean up audit trail events from Oracle Audit Trail. Make sure to configure an Oracle Audit Trail cleanup policy to avoid running out of disk space.

## Step 5/6. Create a Teleport user

---

TIP

To modify an existing user to provide access to the Database Service, see [Database Access Controls](https://goteleport.com/docs/enroll-resources/database-access/rbac.md)

---

**Teleport Community Edition**

Create a local Teleport user with the built-in `access` role:

```
$ tctl users add \
  --roles=access \
  --db-users="*" \
  --db-names="*" \
  alice
```

**Teleport Enterprise/Enterprise Cloud**

Create a local Teleport user with the built-in `access` and `requester` roles:

```
$ tctl users add \
  --roles=access,requester \
  --db-users="*" \
  --db-names="*" \
  alice
```

| Flag         | Description                                                                                                                              |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `--roles`    | List of roles to assign to the user. The builtin `access` role allows them to connect to any database server registered with Teleport.   |
| `--db-users` | List of database usernames the user will be allowed to use when connecting to the databases. A wildcard allows any user.                 |
| `--db-names` | List of logical databases (aka schemas) the user will be allowed to connect to within a database server. A wildcard allows any database. |

---

WARNING

Database names are only enforced for PostgreSQL, MongoDB, and Cloud Spanner databases.

---

For more detailed information about database access controls and how to restrict access see [RBAC](https://goteleport.com/docs/enroll-resources/database-access/rbac.md) documentation.

## Step 6/6. Connect

Once the Database Service has joined the cluster, log in to see the available databases:

```
$ tsh login --proxy=example.teleport.sh --user=alice
$ tsh db ls
Name   Description    Allowed Users Labels  Connect
------ -------------- ------------- ------- -------
oracle         [*]                   env=dev
```

Connect to the `"oracle"` database. Pass the correct service name as the `--db-name` parameter.

You can check the service names by inspecting the database configuration on the Oracle Exadata VM.

```
> lsnrctl services | grep paas
Service "spark_PDB1.paas.oracle.com" has 1 instance(s).
```

```
$ tsh db connect --db-user alice --db-name spark_PDB1.paas.oracle.com oracle
SQLcl: Release 24.2 Production on Fri Aug 09 15:29:41 2024

Copyright (c) 1982, 2024, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
Version 19.24.0.0.0

SQL> select user from dual;

USER
________
ALICE

SQL>
```

To log out of the database and remove credentials:

```
Remove credentials for a particular database instance.
$ tsh db logout oracle
Remove credentials for all database instances.
$ tsh db logout
```

## (Optional) Configure additional hostnames

In some deployments the same logical database is reachable via multiple hostnames with different characteristics, for example:

- replicated databases
- hostnames that traverse different network paths

If this applies to your setup, list all hosts in order of preference to improve connection resiliency.

If a TCP dial error occurs for a host, the next host in the list is tried automatically. Non-network errors (e.g., certificate or authentication failures) are not retried and do not advance to the next host.

By default, hosts are attempted in the listed order. Retries cycle through the list and wrap to the start as needed (e.g., `host1 → host2 → host3 → host1 → ...`). To randomize the sequence per connection attempt, set `shuffle_hostnames`; the same cyclic pattern then applies to that randomized order.

`retry_count` controls the number of retries per host after the initial attempt on a network error. The default is `2`, so there are 3 total attempts per host (1 initial + 2 retries) before moving to the next host in sequence.

This setup supports failover and basic load-balancing for new connections: enabling `shuffle_hostnames` spreads initial connection attempts across hosts (load-balancing), while retries automatically move to the next host if the current one is unreachable (failover).

```
- name: oracle
  protocol: oracle
  uri: host1:2484,host2:2484,host3:2484  # Multiple hosts; dials in sequence and wraps (host1 → host2 → host3 → host1 ...). Dialing sequence can be randomized with `shuffle_hostnames`.
  static_labels:
    env: dev
  oracle:
    # Randomize host order per connection attempt to spread load. Optional.
    shuffle_hostnames: true
    # Retries per host on network errors only; non-network errors stop (default: 2). Optional.
    retry_count: 5            

```

## Troubleshooting

### Connection hangs or is refused

A common issue when connecting to an Oracle database is a connection timeout or refusal. This typically indicates a networking problem where the Teleport Database Service cannot reach the Oracle database endpoint. Verify that network routing and access controls, such as firewalls and VPC security groups, allow traffic to flow from the Database Service host to the database endpoint.

You can validate connectivity using a native Oracle client, which helps confirm whether the issue is with Teleport or the underlying network configuration. For example, using Oracle SQLcl:

```
# Example: Oracle SQLcl
sql -L myuser/mypassword@oracle-instance.example.com:2484

```

Network connectivity issues are often detected by automated [health checks](https://goteleport.com/docs/enroll-resources/database-access/guides/health-checks.md).

To check the health status of all registered databases:

```
# All databases
tctl db ls --format=json | jq -r '.[] | [.metadata.name, .status.target_health]'

```

An unhealthy database will have output similar to the following:

```
...
  "oracle",
  {
    "address": "11.22.33.44:2484",
    "protocol": "TCP",
    "status": "unhealthy",
    "transition_timestamp": "2025-09-25T09:47:39.435973Z",
    "transition_reason": "threshold_reached",
    "transition_error": "dial tcp 11.22.33.44:2484: i/o timeout",
    "message": "1 health check failed"
  }
...

```

### TLS negotiation fails

Properly configuring TLS on an Oracle database can be challenging. Different underlying issues can result in the same error message, such as the following from Teleport:

```
Original Error: *tls.permanentError remote error: tls: handshake failure

```

Or you might see the following in the Oracle logs:

```
ORA-00609: could not attach to incoming connection
ORA-28860: Fatal SSL error

```

To identify the root cause, follow the debugging steps in the sections below. The output of the following `openssl` command can help diagnose many common TLS issues. Capture the output and use it as you follow the debugging steps.

```
$ openssl s_client -connect db.example.com:2484 -showcerts
```

#### Wrong server certificate

Teleport rejects connections to databases with untrusted server certificates. If you are using Teleport to issue certificates, ensure that the server certificate was issued by the Teleport Database CA. An invalid server certificate will prevent Teleport from establishing a secure connection.

You can view the Teleport Database CA certificate with the following command:

```
tctl auth export --type=db | openssl x509 -issuer -noout
...
issuer=O=teleport.example.com, CN=teleport.example.com, serialNumber=200129862304303044762346177566738813560

```

Compare the `issuer` in the server certificate with the `issuer` of the Teleport Database CA certificate. The `openssl s_client` command from the previous section will show you the server certificate:

```
# openssl s_client output:
...
Server certificate
subject=CN=db.example.com
issuer=O=teleport.example.com, CN=teleport.example.com, serialNumber=200129862304303044762346177566738813560
...

```

You can also inspect the Oracle wallet directly using the `orapki` utility to verify the server certificate.

```
# Prompt for wallet password
orapki wallet display -complete -wallet /path/to/wallet

```

The "User Certificates" section of the output should contain the server's certificate. Its `Issuer` should match the `Subject` of the Teleport Database CA.

```
User Certificates:
Subject:        CN=db.example.com
Issuer:         SERIALNUMBER=200129862304303044762346177566738813560,CN=teleport.example.com,O=teleport.example.com
Serial Number:  ...

```

#### Wrong client certificate

If the Oracle server rejects client certificates presented by the Teleport Database Service, you should verify that the Oracle database trusts the Teleport Database User CA.

You can view the Teleport Database User CA with this command:

```
tctl auth export --type=db-client | openssl x509 -issuer -noout
issuer=O=teleport.example.com, CN=teleport.example.com, serialNumber=183359545647055551607366887578713393931

```

Compare the Teleport Database User CA with the list of CAs trusted by the Oracle database. The `openssl s_client` command from earlier will show the list of CAs the Oracle database trusts:

```
# openssl s_client output:
...
---
Acceptable client certificate CA names
O=teleport.example.com, CN=teleport.example.com, serialNumber=183359545647055551607366887578713393931

```

Ensure that the Teleport Database User CA certificate has been added to the correct wallet and that the Oracle server configuration references this wallet.

You can also inspect the Oracle wallet directly using the `orapki` utility to verify that the Teleport Database User CA is trusted.

```
# Prompt for wallet password
orapki wallet display -complete -wallet /path/to/wallet

```

The "Trusted Certificates" section of the output should contain the Teleport Database User CA. Its `Issuer` should match the `issuer` of the Teleport Database User CA.

```
Trusted Certificates:
Subject:        SERIALNUMBER=183359545647055551607366887578713393931,CN=teleport.example.com,O=teleport.example.com
Issuer:         SERIALNUMBER=183359545647055551607366887578713393931,CN=teleport.example.com,O=teleport.example.com
Serial Number:  ...

```

#### Wrong TLS version

Teleport rejects connections that use TLS 1.0 or 1.1 due to known weaknesses. Ensure that the `SSL_VERSION` parameter in your Oracle configuration is set to `1.2` or higher to enable TLS 1.2 or a newer version.

#### No common cipher suites

Ensure that the `SQLNET.CIPHER_SUITE` parameter in your Oracle configuration contains modern TLS cipher suites that match the configured TLS version. The following cipher suites are secure and widely supported across different Oracle versions.

For TLS 1.2:

- `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`
- `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`

For TLS 1.3:

- `TLS_AES_128_GCM_SHA256`
- `TLS_AES_256_GCM_SHA384`

### `Must be logged on to the server` error

The following error indicates that the login procedure has failed:

```
ORA-17430: Must be logged on to the server.

```

This is most commonly caused by the Oracle database enforcing native encryption or data-integrity checksums on a TCPS endpoint. Teleport uses TLS for transport security, and does not support native Oracle encryption.

To disable the redundant encryption requirement for the TCPS endpoint, add the following line to your `sqlnet.ora` file:

`SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS=TRUE`

Make sure to use an up-to-date version of the Oracle database. In older versions, this setting may not disable data-integrity checksums, which will lead to continued failures.

### Invalid username

An incorrectly specified username will result in the following error:

```
ORA-01017: invalid username/password; logon denied

```

When using TLS-based authentication, Oracle maps the Common Name (CN) from the client certificate to an external user in the database. Verify the `EXTERNAL_NAME` for your user in the `dba_users` table. It should be in the format `cn=<name>`, where `<name>` matches the value of the `--db-user` flag used in the `tsh db login` command.

You can query the `dba_users` table to check the `EXTERNAL_NAME` of your users:

```
SQL> SELECT username, authentication_type, external_name
  2  FROM   dba_users
  3  WHERE  authentication_type = 'EXTERNAL'
  4  ORDER  BY 1;

USERNAME      AUTHENTICATION_TYPE    EXTERNAL_NAME
_____________ ______________________ ________________
ALICE         EXTERNAL               cn=alice

```

## Next steps

- Learn how to [restrict access](https://goteleport.com/docs/enroll-resources/database-access/rbac.md) to certain users and databases.

* View the [High Availability (HA)](https://goteleport.com/docs/enroll-resources/agents/high-availability.md) guide.

- Take a look at the YAML configuration [reference](https://goteleport.com/docs/enroll-resources/database-access/reference/configuration.md).

* See the full CLI [reference](https://goteleport.com/docs/enroll-resources/database-access/reference/cli.md).

Read the documentation about:

- [Oracle Audit Trail](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/audit-traditional-auditing.html#guid-adf45b07-547a-4096-8144-50241fa2d8dd)
- [`sqlnet.ora`](https://docs.oracle.com/en/database/oracle/oracle-database/18/netrf/parameters-for-the-sqlnet-ora-file.html#guid-28040885-6832-4ffc-9258-0ef19fe9a3ac) and [`listener.ora`](https://docs.oracle.com/en/database/oracle/oracle-database/18/netrf/oracle-net-listener-parameters-in-listener-ora-file.html#guid-f9fa0df5-2faf-45ca-b6a1-f0166c7bfe54) configuration
- [Oracle Exadata](https://docs.oracle.com/en/engineered-systems/exadata-database-machine/)
- [Oracle Real Application Clusters (RAC)](https://docs.oracle.com/en/database/oracle/oracle-database/19/racad/index.html)