Oracle "ORA-01017: invalid username/password; logon denied": the real causes

1. Is it the right database?

On Oracle 12c and later, one server holds several pluggable databases (PDBs), in one container. A user created in ORCLPDB1 doesn’t exist in the root, or in another PDB, and that gives you this error. Look at where you’re connecting:

sqlplus app@//10.0.0.5:1521/ORCLPDB1

The part after the port is the service. Compare it with what exists:

SELECT name, open_mode FROM v$pdbs;

Then find the user in all of them:

SELECT con_id, username, account_status FROM cdb_users WHERE username = 'APP';

The common mistake: connecting to the default service, such as FREE or ORCLCDB, which is the root, when your user lives in a PDB.

2. Case and special characters

Since 11g, passwords are case-sensitive. An upgrade or a change in a client may then break a password that used to work.

Then there are the characters. A password containing @, / or $ gets misread on the command line, so quote it, and quote it for the shell too:

sqlplus 'app/"pass@word"@//10.0.0.5:1521/ORCLPDB1'

An easier way is to leave it out, and let SQL*Plus ask:

sqlplus app@//10.0.0.5:1521/ORCLPDB1

An @ in a password is a typical cause, since Oracle then reads what’s after it as the database. The Password Generator has a shell-safe option for this reason.

User names are stored in uppercase unless they were created in quotes. A user created as "app" must log in as "app", in quotes.

3. Locked or expired accounts

These usually have their own messages: ORA-28000: The account is locked, and ORA-28001: the password has expired. But check as an admin, as a brute-force lock or a default profile often turns out to be the reason:

SELECT username, account_status, lock_date, expiry_date, profile
FROM dba_users WHERE username = 'APP';

Fix it:

ALTER USER app ACCOUNT UNLOCK;
ALTER USER app IDENTIFIED BY "new-password-here";

Who’s locking it? An application or a scheduled job with an old password can keep failing, and lock the account again. See who’s trying:

SELECT os_username, userhost, timestamp, returncode
FROM dba_audit_session
WHERE username = 'APP' AND returncode = 1017
ORDER BY timestamp DESC FETCH FIRST 10 ROWS ONLY;

That view depends on your audit settings, and on newer systems, unified_audit_trail has this.

4. An old client

Old clients can’t use the newer password hashes, and they may report this same error, or ORA-28040: No matching authentication protocol. Update the client, as Oracle’s Instant Client is a free download. To see what versions a user’s password supports:

SELECT username, password_versions FROM dba_users WHERE username = 'APP';

Lowering SQLNET.ALLOWED_LOGON_VERSION_SERVER in sqlnet.ora gets you past it in an emergency, at the cost of weaker password hashing. Then the user’s password must be set again for it to apply. It’s better as a short-term step while you upgrade.

5. Getting in as an admin

On the server, as the oracle operating system user, you don’t need a password. The system’s group membership does the job:

sqlplus / as sysdba

ALTER SESSION SET CONTAINER = ORCLPDB1;
ALTER USER app IDENTIFIED BY "new-password-here";

If that says ORA-01017 too, then your system user isn’t in the dba group, or ORACLE_SID is wrong. Check both with id and echo $ORACLE_SID. SYS over the network uses a separate password file, which orapwd manages.

In Docker, with gvenzl/oracle-free, the password comes from ORACLE_PASSWORD, and it only applies on the first start, on an empty volume. To change it later:

docker exec ora resetPassword new-password-here

6. A wallet or external sign-in

sqlplus /@MYDB uses a wallet, and a stale one gives this error. Run mkstore -wrl <wallet> -listCredential, and check that the entry matches. For a user set up as IDENTIFIED EXTERNALLY, sign-in comes from the system, or Kerberos or LDAP, rather than a database password.