Oracle.ManagedDataAccess and ORA-01017: invalid username/password; logon denied

DerHaifisch picture DerHaifisch · Oct 16, 2014 · Viewed 26.1k times · Source

I have a challenging situation on one of our servers. I have an ASP.NET MVC 3 application that needs to connect to an Oracle 12c database. It does so using the following connection string:

User ID=myuserid;Password=mypass;Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<IP ADDRESS>)(PORT = 1521)))(CONNECT_DATA=(SERVICE_NAME=PDB1)));

I'm also using Oracle's Oracle.ManagedDataAccess, version 4.121.1.0. Each attempt to connect results in the following error:

ORA-01017: invalid username/password; logon denied

I can connect successfully on my desktop with the above credentials. I have the same code on another server, but using an older, un-managed version of the library, and it can connect successfully with the aforementioned credentials. However, the server on which I would like my code to run fails every single time using the same credentials that enable successful connections on different servers.

On the server that fails, I can:

  • connect via SQLPLUS
  • hit the database with TNSPING
  • Create a System DSN to establish an ODBC connection

I have checked the TNSNAMES.ORA in all locations and they appear to be correct.

After hitting the database too many times, the account actually locked indicating that I was, indeed, hitting the database and that the database did not like the credentials presented. I checked the applications that previously connected successfully and they also failed with an error indicating that the account was locked. Unlocking the account caused those applications to connect successfully with the exception of the server with which I am having problems.

I am at my wit's end.

Does anyone have any other suggestions as to what might cause this problem?

EDIT:

I installed WireShark on my local computer and on the offending server. I captured communication between my desktop and the database as well as the offending server and the database. I found that my desktop communicated the password:

0080  35 42 31 41 43 34 30 00 01 01 01 0d 0d 41 55 54   5B1AC40......AUT
0090  48 5f 50 41 53 53 57 4f 52 44 01 40 40 43 30 36   H_PASSWORD.@@C06
00a0  37 39 42 31 31 42 46 36 42 41 43 44 39 30 38 44   79B11BF6BACD908D
00b0  37 39 34 34 31 31 46 34 32 33 30 42 34 36 44 36   794411F4230B46D6
00c0  35 36 36 33 31 42 45 39 39 41 36 43 36 37 42 44   56631BE99A6C67BD
00d0  43 33 35 42 42 44 36 44 42 45 37 34 36 00 01 0d   C35BBD6DBE746...

whereas the server with which I am having problems, did not (or at least that's the assumption):

0080  39 33 39 37 32 33 46 00 01 01 01 0d 0d 41 55 54   939723F......AUT
0090  48 5f 50 41 53 53 57 4f 52 44 01 40 40 00 00 00   H_PASSWORD.@@...
00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 0d   ................

Does anyone know of a security/configuration setting that would prevent passwords from being transmitted even though they are present in the connection string?

Edit (20180713):

In my particular case, the issue was the FIPS setting.

For those doing research, there are several ways around this.

  1. You can alter the registry setting located at HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled. If FIPS is enabled, the value is 1. If disabled, the value is 0. You do not need to reboot.

  2. Most likely, the reason why you are running into this issue is that FIPS is enabled and you are using the Oracle managed data access library. A solid workaround is to use the unmanaged library. However, to use this library, you need to install the Oracle Instant Client. The client is available for download in the Oracle Data Access Components.

  3. Upgrade your server to Oracle 12.2c. Oracle 12c versions before 12.2c still have this problem.

If you do not have FIPS enabled, the most likely you will need to investigate whether your database has the SEC_CASE_SENSITIVE_LOGON setting set to true. You will need to execute ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE; and then reset all of your passwords.

Answer

Jeff McConnell picture Jeff McConnell · Oct 31, 2014

I have been struggling with this same issue for a couple of weeks and finally have a resolution. I had to disable the FIPS security policy, try setting this key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy] "Enabled"=dword:00000000

to zero, it worked perfectly for me

I was following your thread your blank password issue eventually pointed me here:

https://community.oracle.com/thread/2557592?start=30&tstart=0