rmoff

May 6, 2010

What am I missing here??? ORA-01017: invalid username/password; logon denied

Filed under: dac, ORA-01017, oracle — rmoff @ 17:01

What’s going on here? The username/password is definitely valid, proved by the sqlplus connection.

Configuring DAC in OBIA 7.9.5.1:

What can I do for you?

1 - Enter repository connection information
2 - Test repository connection
3 - Enter email account information
4 - Send test email
5 - Save changes
6 - Exit

Please make your selection: 1

These are your connection type choices:

1 - MSSQL
2 - DB2
3 - Oracle (OCI8)
4 - Oracle (Thin)
5 - Keep current ( Oracle (Thin) )

Please make your selection: 4

Current value for Instance is MYDB.
Press return to keep it or enter a new value.
> MYDB

Current value for Database Host is server.company.com.
Press return to keep it or enter a new value.
> server.company.com

Current value for Database Port is 1521.
Press return to keep it or enter a new value.
> 1521

Current value for Table owner name is DAC_REPO_795.
Press return to keep it or enter a new value.
> DAC_REPO_795

Press return to keep current password, enter a new value otherwise.
> HAS425Al

What can I do for you?

1 - Enter repository connection information
2 - Test repository connection
3 - Enter email account information
4 - Send test email
5 - Save changes
6 - Exit

Please make your selection: 2

Connecting to repository...
Can't connect to the database.
ORA-01017: invalid username/password; logon denied

Validate connectivity with SQLPLUS:

$sqlplus DAC_REPO_795/HAS425Al@MYDB

SQL*Plus: Release 10.2.0.1.0 - Production on Thu May 6 16:08:44 2010

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

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

Resolved by forcing the password to uppercase, but all our other DAC installations don’t require this, and this DAC installation connects with a mixed-case password to a different Oracle instance with no problem.

sys.aud$ shows the connection coming in, so I’m definitely hitting the correct Oracle instance with the correct username. Presumably the password is getting corrupted somewhere, but why, and why only in this particular instance??

What on earth am I missing???


Update:
Thanks for people’s comments.
1) All the databases are 11.1.0.7
2) All databases are sec_case_sensitive_logon = TRUE

The schema in question had been created through expdp/impdp of another schema on the same DB.

I’ve discovered an SR with similar symptoms for a different bit of Oracle software (SOA / OC4J), but in common both use JDBC drivers to connect to Oracle 11g.
I’m confident that the problem must lie in here somewhere, but cannot replicate it even with many different JDBC versions:
11.1.0.7
10.2.0.1.0
10.1.0.5.0
9.0.2.0.0

*scratches head*

Advertisements

5 Comments

  1. Not a solution, just an observation.

    Prior to 11g, Oracle didn’t care if passwords were mixed case or not…unless you used the password manager thingy. OK, maybe not. 🙂

    Comment by chet — May 6, 2010 @ 17:40

  2. What about environment variables?

    Nope…never mind. It can find the database.

    Comment by chet — May 6, 2010 @ 17:55

  3. Is this the only 11g instance you connect to? Case sensitivity is enforced by default from that release. It can be controlled by a SEC_ parameter, I forget what it’s called but it is obvious. Show parameter SEC will list it for you.

    Comment by niall litchfield — May 6, 2010 @ 18:14

  4. Current value for Database Host is server.company.com.
    Press return to keep it or enter a new value.
    > server.company.com

    Shouldn’t you enter in “localhost” or something? server.company.com can’t be right, can it?

    Comment by chet — May 6, 2010 @ 22:27

  5. There’s a database parameter that says whether to use mixed case passwords in 11g or not. So it could be that the other 11g instance isn’t enforcing mixed case (and obviously that will still allow access with a mixed case password).

    Also if the other instance has its password set under the 10g ‘rules’ it only has the hash of the uppercase password. Again while the mixed case password would work, so would an uppercase version of it.

    In short I suspect while you have another instance that is using a mixed-case password, it mighht not be enforcing it.

    PS. If it was complaining about a case-insensitive password, Chet might have been right about environment NLS settings. The lower-to-uppercase translation is linguistic sensitive, so using some exotic characters in a password makes it reliant on a compatible language setting.

    Comment by Gary — May 7, 2010 @ 00:06


RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Blog at WordPress.com.

%d bloggers like this: