I am having a asp.net web application in which I am connecting to a Oracle DB using oracle.DataAccess component. My DBA created a new account and when I try to login with that account in toad, it simply worked fine but when I am passing the values in connection string in SERVER A it is giving me invalid username/password. I double checked the credentials and they are correct. Then I copied the entire website into a new SERVER B and when i tried, I am able to login to the oracle DB. I am very much confused about whats happening. Any Ideas? Is it possible to enable any trace on my servers?
Which version (Oracle DB and Oracle.DataAccess) do you use?
In Oracle 11 passwords are case-sensitive (by default), in prior version it was not. Thus Oracle.DataAccess version earlier than 11 may have problems dealing properly with case sensitive passwords.
Related
I'm considering using remote OS authentication to connect to an Oracle database (version 11g). What are the guidelines for using [remote_os_authent]
Here's what I want to do:
We set up a catalog DB to used by RMAN to store metadata about Oracle databases.
I want to connect to the catalog DB via the local machine and execute this command for resync catalog db:
rman target sys/pass#localdb;
connect catalog catuser/password#catdb;
RESYNC CATALOG;
Is it possible for me to do this through oracle Enterprise Manager job?
(I did this process by calling the execute file, but the problem is that the passwords are clear in the executable file.)
I need it because I do not want user passwords to be available and visible.
I can't use oracle valet for passwordless connection.
Using remote os authentication is considered a bad habit because it is insecure.
If you want to have scripting without having to store passwords in a readable format to prevent leaking passwords, easiest is to use the oracle wallet for this.
This still keeps you busy maintaining passwords in the database and in the wallet but it is pretty safe.
Your connection would be something line sqlplus /#tns_alias
where the tns_alias is the key into the wallet that fetches the username and the password.
An example of setup can be found here: http://ronr.blogspot.com/2017/01/cleartext-userid-and-passwords-in.html
An other option could be to enable Central Managed Users (CMU) and kerberos. This does need quite a bit of setup and is less suitable for scripting. For interactive use it works very nice, assuming you have kerberos correctly setup.
An example of CMU setup can be found here: https://blog.pythian.com/part-1-creating-an-oracle-18c-centrally-managed-users-testbed-using-oracle-cloud-infrastructure/
Please change back remote_os_authentication to false. It is not safe because users can easily be spoofed.
At first, please note that I am aware that this question has already been asked several times. However, the accepted (and non-accepted) solutions given so far did not work in my case, so something substantial must have changed since then, which hopefully justifies asking again.
Having said this:
I am currently trying to upgrade an Access 2010 .adp application to Access 2019 .accdb. The application includes a lot of VBA code which uses ADO objects to connect with and operate on Microsoft SQL server (currently: 2008 R2, but will be upgraded soon).
I'd like to keep the most part of the code, which means to stick with ADO, so the way to go is the new OleDB SQL server driver (which has been undeprecated / newly released in 2018). The SQL server runs on another machine than my client application.
I am not able to establish a connection to SQL server from VBA. When executing the following code snippet
Dim cnTemp As Connection
Set cnTemp = New Connection
cnTemp.CursorLocation = adUseServer
cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;Authentication=SqlPassword;User ID=sa;Password=secret;DataTypeCompatibility=80;"
I get the following error when the last line is executed:
SSL Provider: The certificate chain was issued by an authority which is not trusted.
OK, no problem, after all we have found all the other questions dealing with the same issue, all suggesting the same solution: Add Trust Server Certificate=True; to the connection string.
Well, tried that, but -to my surprise- still the same situation. Then I tried some other variants like TrustServerCertificate=True; or using true instead of True, but to no avail. I also tried adding Use Encryption for Data=True; which didn't help either (that could be expected). Furthermore, I tried some of the snippets I had found when researching the problem, but which are not documented by Microsoft as being valid in ADO connection strings (like Encrypt=true or Trusted_Connection=true;); of course, that made the situation worse, raising other error messages.
I have understood that I could solve that problem by putting the SQL server certificate into the client's trusted root certificate store, or by having SQL server use a certificate which has been issued by a known, trusted CA (e.g. Let's Encrypt).
However, I'd strongly like to know why adding Trust Server Certificate=true; to my connection string does not make the error go away and what I have to put in there to disable certificate validation (and by the way, I would be grateful if we wouldn't start a discussion about why this would be bad; this is just development and testing in a trusted, closed network, and I am aware of possible risks).
The reason TrustServerCertificate=True in the connection string is not honored is twofold. One is that it isn't a valid ADO classic (ADODB) connection string keyword. According to the ActiveX Data Objects (ADO) Connection String Keywords documentation, the keyword/value pair should be Trust Server Certificate=True (note spaces). The keyword is ignored entirely without the spaces and not trusted as a result.
However, this change alone will not trust the certificate because of the Authentication-SqlPassword specification. When the Authentication keyword is specified, the documentation footnote calls out:
To improve security, encryption and certificate validation behavior is
modified when using Authentication/Access Token initialization
properties or their corresponding connection string keywords. For details, see Encryption and certificate validation link.
The referenced link includes this important note:
Certificate validation can also be controlled through the Value field
of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI18.0\GeneralFlags\Flag2
registry entry. Valid values are 0 or 1. The OLE DB driver chooses the
most secure option between the registry and the connection
property/keyword settings. That is, the driver will validate the
server certificate as long as at least one of the registry/connection
settings enables server certificate validation.
So even with Trust Server Certificate=True, the cert will be validated when this registry value is set to 0.
One solution is to simply remove the Authentication=SqlPassword specification as long as you don't need the improved security provided by not trusting the server certificate:
cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;User ID=sa;Password=secret;Trust Server Certificate=True;DataTypeCompatibility=80;"
At first, I'd like to state that all credit goes to #Dan Guzman. It's his answer / comment which provided the solution.
However, I'd like to add some background, based on research I've done since posting my question.
The problem is that Microsoft's documentation obviously is wrong. Please have a look at the following document:
https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-2017#table3_1
It is located in the section SQL Server 2017 -> OLE DB -> Applications -> Using connection string keywords with OLE DB Driver for SQL server, so it should be the right one. It is divided into three sections; in the context of this question, the last table is what we're interested in, because only this one relates to connection strings with ADO.
That last table explicitly shows that Authentication=SqlPawword is valid in ADO / OLE DB connection strings (reformatting mine, no content altered):
Authentication SSPROP_AUTH_MODE Specifies the SQL or Active
Directory authentication used. Valid values are:
(not set): Authentication mode determined by other keywords.
ActiveDirectoryPassword: Active Directory authentication using login ID and password.
ActiveDirectoryIntegrated: Integrated authentication to Active Directory using the currently logged-in user's Windows account
credentials.
NOTE: It's recommended that applications using Integrated Security (or Trusted_Connection) authentication keywords or their corresponding
properties set the value of the Authentication keyword (or its
corresponding property) to ActiveDirectoryIntegrated to enable new
encryption and certificate validation behavior.
SqlPassword: Authentication using login ID and password.
NOTE: It's recommended that applications using SQL Server authentication set the value of the Authentication keyword (or its
corresponding property) to SqlPassword to enable new encryption and
certificate validation behavior.
It also says (again, formatting mine, no content altered):
Trust Server Certificate SSPROP_INIT_TRUST_SERVER_CERTIFICATE
Accepts the strings "true" and "false" as values. The default value
is "false", which means that the server certificate will be validated.
Every reasonable human being will understand this in the sense that Trust Server Certificate=true will disable certificate validation.
But when you look here
https://learn.microsoft.com/en-us/sql/relational-databases/native-client/applications/using-connection-string-keywords-with-sql-server-native-client?view=sql-server-2017
you'll notice that this document is structured like the first one, and that the last table does not mention the Authentication parameter.
However, this document is located in SQL Server 2017 -> Development -> SQL Server Native Client -> Applications -> Using Connection String Keywords. That means that it is not relevant for our case because it relates to SQL server native client (and not OLE DB), but it provides the correct information.
So we have the right document which provides the wrong information and an irrelevant document which provides the right information. Congratulations, Microsoft, you have made me waste a whole day again ...
Furthermore, I have found the following document:
https://learn.microsoft.com/en-us/sql/connect/oledb/features/using-azure-active-directory?view=sql-server-2017#encryption-and-certificate-validation
Reading the title ("Using Azure Active Directory"), it should relate to Azure only. However, I suspect that the following section relates to local SQL server installations as well (formatting mine, no content altered):
Certificate validation
To improve security, the new connection properties/keywords respect
the TrustServerCertificate setting (and its corresponding connection
string keywords/properties) independently of the client encryption
setting. As a result, server certificate is validated by default.
Note
Certificate validation can also be controlled through the Value field
of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI18.0\GeneralFlags\Flag2
registry entry. Valid values are 0 or 1. The OLE DB driver chooses the
most secure option between the registry and the connection
property/keyword settings. That is, the driver will validate the
server certificate as long as at least one of the registry/connection
settings enables server certificate validation.
So it could well be that we also have to change values in the registry to finally disable certificate validation when connecting to SQL server via ADO / OLE DB.
I'm developing chat application, I'm using ejabberd for my project. I installed ejabberd server(16.06) successfully and it performing good in auth method as internal. But it is not working when I'm changed auth method as sql. These are the things I'm changed in ejabberd.yml file
default_db: sql
auth_method: sql
## ODBC compatible or MSSQL server:
##
sql_type: mssql
sql_server: "Server=azure_server_name;DSN=DB_Name;UID=azure_DB_username;PWD=azure_DB_password"
sql_pool_size: 10
sql_keepalive_interval: 28800
mod_mam:
iqdisc: one_queue
db_type: sql
default: always
I'm getting following error for while I'm register new user and admin login into web admin portal
ejabberd_auth:is_user_exists:316 The authentication module ejabberd_auth_sql returned an error
when checking user <<"newuser">> in server <<"localhost">>
Error message: {timeout,{p1_fsm,sync_send_event,[<0.390.0>,{sql_cmd,{sql_query,{sql_query,<<"Q9525209">>,#Fun<sql_queries.9.38301790>,#Fun<sql_queries.10.38301790>,#Fun<sql_queries.11.38301790>,{sql_queries,145}}},3534866},60000]}}
I'm used register command:
bin>ejabberdctl register "newuser" "localhost" "password"
Thanks in advance. Please add your ideas and suggestions to resolve this issue.
Again- I am no Ejabberd expert- I imagine someone might have more experience with this; However, it seems that you're confusing Register which I assume is an action to create a login on the Ejabberd platform with the login that is being used on the database. (Or I'm misinterpreting your comments. One of the two.)
You will need to use a username/password combination that exists on the Azure SQL Database in your connection string.
Additionally, you might try the following connection string :
sql_server:"Server=tcp:azure_server_name.database.windows.net;DSN=DB_Name;UID=azure_DB_username;PWD=azure_DB_password"
I'm totally new to Oracle and have been tasked with setting up 12c for a class a professor is teaching next semester. He wants the students to be able to use their AD accounts to access the database they'll be working on. I looked at available options, and without extending the AD schema, kerberos looked to be my only option.
I tried following a combination of these:
http://www.ateam-oracle.com/configuring-your-oracle-database-for-kerberos-authentication/
https://docs.oracle.com/database/121/DBSEG/asokerb.htm#DBSEG9646
In terms of the Oracle documentation above, my process is breaking down on step 8. After step 7 (which I performed on a domain controller), when I attempt to login to SQLPLUS with SYSTEM account, I was receiving:
ORA-12641: Authentication service failed to initialize
If I try to connect with the SYSTEM (or Active Directory) account through SQL DEVELOPER I get this:
Listener refused the connection with the following error: ORA-12505, TNS:listener does not currently know of SID given in the connect descriptor
So I added NTS back to SQLNET.AUTHENTICATION_SERVICES, but the problem persists. On top of that, Enterprise Manager Express (https://:5500/em) is also no longer accessible.
This same thing happened the first time I tried stepping through the available documentation, and I managed to get everything back to a default by deleting sqlnet.ora, listerner.ora and starting from scratch... But now I'm back in the same place again.
If it is helpful, here are the contents of sqlnet.ora:
#
SQLNET.KERBEROS5_KEYTAB = c:\Windows\oracle.keytab
SQLNET.AUTHENTICATION_SERVICES = (BEQ, TCPS, KERBEROS5, NTS)
SQLNET.KERBEROS5_CONF = c:\Windows\krb5.ini
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE = oracle
SQLNET.KERBEROS5_CC_NAME=OSMSFT:
ADR_BASE = D:\app\oracle\product\12.1.0\dbhome_1\log
#
I did comment out SQLNET.AUTHENTICATION_SERVICES = (BEQ, TCPS, KERBEROS5, NTS) which I allowed me to login with the built-in accounts again, and brought Enterprise Manager Express back up.
Any guidance on this is greatly appreciated. Thanks!
I'm getting this error when running an SSIS package through SQL Agent
Failed to acquire connection "ORACLE ADO.NET". Connection may not be configured correctly or you may not have the right permissions on this connection.
When I log on as the SQL Agent User and run the ssis package directly it is fine. When I then execute it through the SQL agent job, it fails.
I've read around extensively on this topic, and it seems a lot of the advise concerns how you are logged in, configuring of proxy accounts, etc, etc, etc, none of which has been helpful.
I am logging onto an Oracle database with an ADO.NET conncetion. The connection string is as follows (datasource, userid and password have been changed):
Data Source=DATASOURCE;User ID=userid;Password=password;Persist Security Info=True;Unicode=True;
I'm loading this from a registry setting using package configuration. To check that I am getting the correct string, I am writing it into a temporary log table. I am definately getting the string I need from the correct registry setting.
I've tested the oracle login credentials though PL/SQL developer, and it lets me login just fine.
As far as I can tell, as I'm using an explicit user name and password for the Oracle connection it just shouldn't matter who the SSIs pacakge is run as. The only point of failure that Ican see would be the reading of the information from the registry, but that seems fine.
I'm really quite baffled, I must confess, and would appreciate any help some of the splendid experts here can offer.
Many thanks,
James
Ok, tracked this one down after quite a lot of pain.
It was working fine on one environment, but not another, so I fired up Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and ran a package through the SQL Agent job, comparing which system entities were hit on each enviroment.
On the failing environment, at the point of the bulk transfer operation, the package attempted to get the Oracle 11 client DLL, and then hung.
I knew that this was installed, and, moreoever, the DLL path was a system environment setting. After further investigation it was revealed that the server had not been rebooted since the Oracle Client install and the SQL Server Agent process had not bee recycled.
Yes, can you believe it, the old helpdesk fix "Can you reboot your computer?" worked.
Sigh!
We had issues at a client with running packages connecting to Oracle before stored on our sql server instance. The work around we found was to change the package property, protection level, to "Dont save Sensitive Data" and for security purposes, we encrypted the username and password in the package configuration that was decrypted by a udf in sql server. Of course, before you try the whole encryption part, I would recommend putting the username and password in the package configuration without encrypting the values to see if changing the protection level setting is the solution to your specific problem. I hope this helps.
I was getting this error when tnsnames.ora file did not have a valid entry for the environment