While connecting Oracle 18c using oracle 10g I am getting error like
"ORA-28040: No matching authentication protocol exception".
I can able to connect "SQL DEVELOPER" but not able to connect "Command prompt"
It is not possible, see Client / Server Interoperability Support Matrix for Different Oracle Versions (Doc ID 207303.1)
Even if you set SQLNET.ALLOWED_LOGON_VERSION_... the connection will most likely fail with another error.
Oracle documentation says:
Connections to Oracle Database from clients earlier than release 10g fail with the error ORA-28040: No matching authentication protocol.
Starting with Oracle Database 18c, the default value for the SQLNET.ALLOWED_LOGON_VERSION parameter changes from 11 in Oracle Database 12c (12.2) to 12 in Oracle Database 18c. The use of this parameter is deprecated.
SQLNET.ALLOWED_LOGON_VERSION is now replaced with the SQLNET.ALLOWED_LOGON_VERSION_SERVER and SQLNET.ALLOWED_LOGON_VERSION_CLIENT parameters. If you have not explicitly set the SQLNET.ALLOWED_LOGON_VERSION_SERVER parameter in the upgraded database, then connections from clients earlier than release 10g fail with the error ORA-28040: No matching authentication protocol.
See if it helps.
In 18c the default minimum version has been changed from 11 to 12 and SQLNET.ALLOWED_LOGON_VERSION is deprecated and replaced with SQLNET.ALLOWED_LOGON_VERSION_SERVER and SQLNET.ALLOWED_LOGON_VERSION_CLIENT
set
SQLNET.ALLOWED_LOGON_VERSION_SERVER=10
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=10
in your sqlnet.ora and reload listener lsnrctl reload
Related
all
I'm trying to connect to an Oracle 19C database. I have installed two Oracle Clients (11g and 12c) because we need to support legacy programs. I can connect with no issue with any user using sqlplus through the 12c client. But if I use the 11g (11.2.0) client with any user. I always get:
ERROR:
ORA-01017: invalid username/password; logon denied
Both clients have exactly the same sqlnet.ora and tnsnames.ora files, so both clients point to the same database.
Any idea? Do I need to set some specific configuration in the 19c server? Or do I need to make some change in the 11g client? Is this even possible?
Thank you.
Have a look at Client / Server Interoperability Support Matrix for Different Oracle Versions (Doc ID 207303.1)
#9 - 11.2.0.3 or 11.2.0.4 only. For Oracle Autonomous Transaction Processing and Oracle Autonomous Data Warehouse, there is additional limitation and 11.2.0.4 is the minimum supported client version.
Usually it is a bad idea to install more than one Oracle client (i.e. one each for 32-bit and 64-bit).
For some components, e.g. "Oracle OleDB Provider" it is even not possible to have more than just one version (again, one each for 32-bit and 64-bit) installed. This is a limitation of the old Windows COM architecture.
For other components it may work, however you need to set your %PATH% environment variable accordingly that it points to the correct folder where currently desired version is installed.
Add to sqlnet.ora
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=11
SQLNET.ALLOWED_LOGON_VERSION_SERVER=11
Change the password in 11 client
In my current project, facing problem of connecting the oracle server from oracle client. Here are the details
Oracle Server 12.2.0.1 64-bit
Oracle Client 12.2.0.1 32-bit
But after analysis, I noticed that I have a common requirement to connect all the oracle servers e.g. 11g, 12c, 18c, 19c from any of the oracle client.
I tried to find common version of oracle.dataaccess.dll which will work for all the above oracle servers from any of the oracle clients. But I couldn't able to find. For example 4.122.19.1 works for all the servers only if client is 19c. For 12c client, it's not working and so on. Is there any common version of oracle.dataaccess.dll available to serve this purpose?
Or do I need to use some other assembly in my project?
I also tried to use Oracle.ManagedDataAccess.dll. But it has an issue of locating the tnsnames.ora.
Any help/suggestions will be greatly appreciated.
I am facing this issue even after following the below settings.
Replacing ojdbc14.jar with ojdbc6.jar[also tried ojdbc5.jar]
Added "SQLNET.ALLOWED_LOGON_VERSION_SERVER=8" to sqlnet.ora
file[under network/admin folder].
This is happening after upgrading the DB from 11g to 12c.
ORA-28040: No matching authentication protocol
I faced a similar issue when trying to connect a
32-bit Oracle 11g Client to a 64-bit Oracle 12c Server
I then proceeded to add the following to sqlnet.ora
SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 8
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
I then experienced the following error
ORA-01017: invalid username/password: logon denied
Adding the following to the Client sqlnet.ora as well as the Server, I was able to connect an old version of Toad and PL/SQL to the new 12c Server.
SQLNET.AUTHENTICATION_SERVICES = (NONE)
JDBC drivers have both a Java version and an Oracle version. The versions are usually correlated, but it's possible for an ojdbc14.jar to support a later version of Oracle than a ojdbc6.jar. Make sure you are using the latest version of ojdbc6.jar.
Run this command to see which version of Oracle the driver was built for:
>java -jar ojdbc6.jar -getversion
Oracle 11.2.0.3.0 JDBC 4.0 compiled with JDK6 on Thu_Jun_28_00:38:25_PDT_2012
#Default Connection Properties Resource
#Mon Dec 21 12:38:41 CST 2015
For SQLNET.ORA changes, to be safe you should restart both the listener and the database. This sounds extreme, but there are some parameters that require restarting the database.
Also make sure that you are modifying all relevant SQLNET.ORA files. If the database's Oracle home is different than the listener's Oracle home you should modify both.
First of all the difference between ojdbc driver's versions depends on the version of the JDK you use drivers with.
So ojbdc14 is suitable for JDK version 1.4, ojdbc5 for JDK 1.5, and so on.
I'm currently using ojdbc7.jar with a 12c database version since my environment uses a JDK 1.7, so upgrade this first.
Having said that, in the Parameters for the sqlnet.ora File for Oracle 12c release page you can read:
Purpose
To set the minimum authentication protocol allowed for clients, and
when a server is acting as a client, such as connecting over a
database link, when connecting to Oracle Database instances.
Usage Notes
The term VERSION in the parameter name refers to the version of the
authentication protocol, not the Oracle Database release.
If the version does not meet or exceed the value defined by this
parameter, then authentication fails with an ORA-28040: No matching
authentication protocol error.
The default for this property is 11.
Allowed values are 8,10,11,12 and 12a.
The recommended value is 12. Try this out.
Moreover there is a useful and interesting solution Database Administrators Stack Exchange
You should use the latest JDBC thin driver (12.1.0.2) and JDK8. With this configuration your driver will support the latest version of the database password verifier and your issue should be resolved.
After upgrading Oracle 12c or higher versions
for java version jdk7 & jdk8 supported ojdcc7.jar
for java version jdk6 ojdbc6.jar
This worked for us...
Download [ojdcc7.jar]: https://mvnrepository.com/artifact/com.oracle/ojdbc7/12.1.0.2
I have two service names defined in a tnsnames.ora file and an encryption scheme in sqlnet.ora.
I'm using oracle instantclient, SQL*Plus 11.2 to connect to an Oracle9i server and an Oracle 11g.
I can connect to the 11g database, but get the error below when trying to connect to 9i.
ERROR:
ORA-12645: Parameter does not exist.
How can I specify the sqlnet.ora to be used only for the 11g connection?
Edit: Adding sqlnet.ora file. My understanding to make sure connection is encrypted is to set the client parameter to requested/require. But, anything other than reject yields the above error when connecting to 9i.
SQLNET.ENCRYPTION_CLIENT=rejected
Connection to 9i successful, but I want encryption on the 11g connection!
I have a situation where I need to transfer Oracle 9i archive logs to an Oracle 10g database, from where they are to be mined by a log-miner and then used by an Oracle streams capture/apply processes.
(Oracle 9 archive logs can be read by the Oracle 10 logminer - I can manually copy the archive logs across, manually register them and have them mined, captured then applied).
The difficulty is that the way Oracle does archive log transfer changed quite a bit between 9i and 10g and setting up the 9i database to transfer to the remote machine like so:
log_archive_dest_state_2 = enable
log_archive_dest_2 = "service=OTHERMACHINE arch optional"
no longer works.
I get this in the 9i logs:
*** 2009-05-22 04:03:44.149
RFS network connection lost at host 'OTHERMACHINE'
Error 3113 attaching RFS server to standby instance at host 'OTHERMACHINE'
Error 3113 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'OTHERMACHINE'
Heartbeat failed to connect to standby 'OTHERMACHINE'. Error is 3113.
*** 2009-05-22 04:03:44.150
kcrrfail: dest:2 err:3113 force:0
ORA-03113: end-of-file on communication channel
And in the 10g log I get:
Fri May 22 04:07:42 2009
WARNING: inbound connection timed out (ORA-3136)
My question is:
Does anyone know how I could configure my 9i or 10g server such that the 10g server will accept the 9i connection in such a way that I can transfer the 9i archive logs to the 10g server. It would be a bonus if the archive logs would be automatically registered in the 10g server.
Note I have not set up a full DataGuard configuration here and the 10g database is not a secondary server.
Thanks for any suggestions.
Edit
Note that I can log on to the 10g server from the 9i server via sqlplus, so connectivity is not the problem
Edit 2
After a large amount of time searching for a solution, I've finally decided that such a mechanism doesn't work, and that a non-Oracle method of transferring archive logs from 9i to 10g will need to be used (e.g. rsync).
Are your databases current with patches?
Also, do your connections typically take a while to authenticate? After V10.1, the default SQLNET.INBOUND_CONNECT_TIMEOUT is set to 60 seconds. Prior to that version it defaults to indefinite.
Ref Metalink 345197.1: Connections that Used to Work in Oracle 10.1 Now Intermittently Fail with ORA-3113,ORA-3106 or ORA-3136 in 10.2