Ok, we solved this. The problem was that the field in the COBOL program was
longer than the password that was being stored in it. Therefore, when it tried
to connect to Oracle, it was sending the password padded with blanks at the
end, so it didn’t match. Once the COBOL program was changed so the field
length was the same length as the password, it worked.
I asked this question of the vendor back in December and they said it was fine
the way it was. Apparently, it worked ok in 11g, but in 12c it doesn’t. The
app is “certified” by the vendor with 12c, too.
Scott Canaan ’88 (srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>)
(585) 475-7886 – work (585) 339-8659 – cell
“Life is like a sewer, what you get out of it depends on what you put into it.”
– Tom Lehrer
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of raza siddiqui
Sent: Thursday, January 14, 2016 11:42 AM
To: rjoralist3@xxxxxxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Capturing user / password For Failed Logins
Are the logins being initiated using physical username / passwords or "/"
[slash or 'ops$' logins] ?
On 1/14/2016 8:13 AM, Rich J wrote:
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)<http://docs.oracle.com/cd/E11882_01/install.112/e27508/netv2.htm#DFSIG256%29>
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
--
