Re: Capturing user / password For Failed Logins

  • From: Rich J <rjoralist3@xxxxxxxxxxxxxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Thu, 14 Jan 2016 10:13:53 -0600

 

On 2016/01/14 07:34, Scott Canaan wrote: 

We have an application that is getting an ORA-01017 when trying to connect to 
the database. This is a new environment for this application. In the past, 
the application was running on one server and the database on another. To 
attempt to speed things up, we've co-located the application and database, 
along with an upgrade to Oracle 12.1.0.2. In doing so, I installed both the 
Oracle database software and Oracle client software in the same Oracle Home. 
The idea is to use a bequeath connection and bypass the network to eliminate 
the network traffic. 

If the user uses SQL*Plus, they can connect to the database. Using the same 
login, the application itself gets the ORA-01017. It is a COBOL application. 
The vendor is insisting that they are passing the correct password. The SA is 
insisting that I have to turn some tracing on to show the password being 
passed in. As far as I know, the password is encrypted in the login process. 

Is there any way to get this information? The vendor refuses to help us until 
we can prove that the password being sent is wrong.

Do you have DB auditing on? That would at least rule out username
issues. 

Since this app is on the DB server, is it running under the oracle
database owner's user? This note in the docs
(http://docs.oracle.com/cd/E11882_01/install.112/e27508/netv2.htm#DFSIG256)
[1] struck me: 

"If clients are running under a user ID different from the DBA user ID,
then Oracle recommends using a net service name to connect through a
listener to the destination database." 

Also, I'm wondering if SQL*Net tracing would work with bequeath. IIRC,
it used to be (9i) that if the first DB connection failed, SQL*Net would
resend with the password plaintext, but that has to have changed... 

GL! 

Rich 

Links:
------
[1]
http://docs.oracle.com/cd/E11882_01/install.112/e27508/netv2.htm#DFSIG256)

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 01-2016