- Error code
- ORA-01017
- Product
- Oracle Database
- Versions
- Oracle Database 19c, 21c, 23ai and 26ai (wording differs: see below)
- Category
- Logins, Accounts & Privileges
- Last reviewed
- 24 October 2026
On this page
What it means
ORA-01017 means Oracle rejected the logon: the user name or password (or other credential) did not match an account in the database you reached, or you are not authorised to access that database.
Oracle's current reference describes two cases: an invalid credential, or a valid credential for someone who is not authorised to access this database. 19c and 21c word it as "invalid username/password". The message is deliberately vague: Oracle does not tell the client whether the user exists, so you have to check each part yourself.
Three things trip people up most. Passwords are case sensitive: the SQL Language Reference says a connect string must use the same case as the CREATE USER or ALTER USER statement that set the password. User names are not, unless the user was created with a quoted name: CREATE USER app_user stores APP_USER, while CREATE USER "app_user" stores the lower-case name exactly. And in a multitenant database, a local user exists in only one pluggable database (PDB), so the same user name and password fail when you connect to the root or to another PDB. On Oracle Database Free, for example, application users normally live in FREEPDB1, not in the root service FREE.
Other authentication methods fail with the same error: an outdated password in a wallet or a connection pool, or an operating system user who is not set up for OS authentication. A locked account gives ORA-28000 and an expired password ORA-28001 instead, and a user without CREATE SESSION gets ORA-01045, so ORA-01017 itself points at the credential or the database you reached.
Common causes
- The password is typed in the wrong case, or a client tool changes or truncates it (special characters such as @ or / in a connect string are a common trap).
- The user was created with a quoted lower-case or mixed-case name, so the unquoted name the client sends does not match.
- The connect string reaches the wrong database or container: the CDB root instead of the PDB, a test database instead of production, or a different service.
- The password was changed but an application, connection pool, scheduler job or wallet still uses the old one.
- The account uses a different authentication method (external, global or centrally managed), and the credential or directory mapping is not valid for this database.
Diagnose it
Read-only These queries only read the data dictionary (USER_, ALL_ and DBA_ views) and dynamic performance views (V$). They do not change data, privileges or settings, so they are safe to run first. DBA_ and V$ views need the matching privileges.
Does the user exist in this container, and how does it authenticate?
Run as a DBA (or another user who can read DBA_USERS) in the same container the client connects to.
SELECT username, account_status, authentication_type, common,
password_versions, last_login, password_change_date
FROM dba_users
WHERE UPPER(username) = 'APP_USER';No row: the user does not exist here (check the container and service). A name in lower case: it was created quoted, so the client must send it quoted. AUTHENTICATION_TYPE PASSWORD means a database password; EXTERNAL or GLOBAL means another method. ACCOUNT_STATUS should be OPEN.
Which database and container did the connection reach?
Connect with any account that works through the same connect string, then check where you are. In SQL*Plus, SHOW CON_NAME gives the same answer.
SELECT SYS_CONTEXT('USERENV', 'DB_NAME') AS db_name,
SYS_CONTEXT('USERENV', 'CON_NAME') AS container,
SYS_CONTEXT('USERENV', 'SERVICE_NAME') AS service
FROM dual;The database, container and service the connect string leads to. CDB$ROOT means you are in the root, where local PDB users do not exist.
Who is failing to log in, and from where?
Oracle's predefined ORA_LOGON_FAILURES unified audit policy records failed logons; the Security Guide says it is enabled by default for new databases, but not for databases upgraded from earlier versions. Where it is on, the audit trail shows the client machine and program sending the bad credential. Reading UNIFIED_AUDIT_TRAIL needs audit viewing privileges.
SELECT event_timestamp, dbusername, os_username, userhost, client_program_name, return_code
FROM unified_audit_trail
WHERE action_name = 'LOGON'
AND return_code = 1017
AND event_timestamp > SYSTIMESTAMP - INTERVAL '1' DAY
ORDER BY event_timestamp DESC;The host and program of each failed attempt. A server or program you did not expect is usually an application or job still using an old password.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Send the exact credential to the right service
Client or network sideCheck the password's case and connect to the service of the database (or PDB) where the user exists. In SQL*Plus, a password with special characters can be enclosed in double quotes; an EZConnect string names host, port and service explicitly.
sqlplus app_user@//dbhost:1521/FREEPDB1
-- enter the password at the prompt, in the exact case it was setReset the password (DBA), then update every place that stores it
Changes permissionsIf nobody knows the current password, a user with the ALTER USER privilege can set a new one in the correct container. Then update the application configuration, connection pools, wallets and scheduled jobs before they lock the account with repeated failures.
Caution: Changing the password immediately breaks every client still using the old one, and their retries count as failed logins that can lock the account (ORA-28000). Plan the change with the application owners.
ALTER USER app_user IDENTIFIED BY "New#Passw0rd-2026";Use the name exactly as it was created
Client or network sideIf DBA_USERS shows the name in lower or mixed case, it was created as a quoted identifier, and the client must send it in exactly that case, as a quoted name (how to quote it depends on the client tool). For new users, create them with unquoted names so the name works in any case.
Do not weaken authentication to make the error go away
Read-onlyDo not turn off password case sensitivity (the SEC_CASE_SENSITIVE_LOGON parameter is deprecated in Oracle's reference) or fall back to older password verifiers to work around a client. Fix the credential or upgrade the client instead.
Examples
Connecting to the root container with a PDB user
Not reproduced here: no Oracle Database is installed for this site. The message text is from Oracle's error reference for current releases; Oracle Database 19c and 21c print "invalid username/password; logon denied". The service names follow Oracle Database Free (FREE is the root, FREEPDB1 the default PDB) and are illustrative for other databases.
-- APP_USER is a local user created in FREEPDB1
sqlplus app_user@//localhost:1521/FREEERROR: ORA-01017: invalid credential or not authorized; logon denied
A password typed in the wrong case
Not reproduced here: no Oracle Database is installed for this site. The message format is from Oracle's error reference; the user, password and service are illustrative. The SQL Language Reference states that passwords are case sensitive, so "reports#2026" does not match "Reports#2026".
CREATE USER report_user IDENTIFIED BY "Reports#2026";
GRANT CREATE SESSION TO report_user;
-- later, from a client
CONNECT report_user/reports#2026@//dbhost:1521/SALESPDBERROR: ORA-01017: invalid credential or not authorized; logon denied
How to prevent it
Store application credentials in one place (a wallet or a secrets store) so a password change is made once, and rotate passwords with a plan that updates every client before the old password stops working. Create users with unquoted names, and document which PDB and service each application uses.
Audit failed logons and watch for repeated ORA-01017 from one host: it is usually a stale password, and left alone it ends with a locked account (ORA-28000).
Common questions
Why do I get ORA-01017 when the password is definitely right?
Check that you reach the right database and container: a local user exists only in its own PDB, so connecting to the root or another PDB fails with the same error. Also check the case of the password and whether the user name was created quoted.
Are Oracle passwords case sensitive?
Yes. Oracle's SQL Language Reference says a connect string must use the same case as the statement that set the password. User names are case insensitive unless they were created as quoted identifiers.
Why does the newer message say not authorized?
Current releases reworded ORA-01017 to cover a valid credential for someone who is not authorised to access the database, for example with centrally managed or directory users. 19c and 21c say invalid username/password; the checks are the same.
Learn more on CodeWithSQL
Official documentation
- ORA-01017 (Oracle Database Error Messages)
- CREATE USER (Oracle SQL Language Reference 19c)
- DBA_USERS (Oracle Database Reference 19c)
- UNIFIED_AUDIT_TRAIL (Oracle Database Reference 19c)
Last technically reviewed 24 October 2026; examples and diagnostics run on Oracle Database Error Messages reference (26ai, 21c and 19c); not run locally. Messages and explanations follow Oracle's Database Error Messages reference; no Oracle Database was available, so the examples were not run locally.