Do we require to install Oracle client on local machine if we are using SQL Developer(local machine) for accessing the oracle database on the server(different from local)?
Sometimes yes. For example when your account expires, then there is no way how to change your password via JDBC. This is Oracle specific feature, there it is not supported by JDBC standard.
When DBA creates you account with expiring password, and your password expires, then you have no other way then connecting via OCI to resolve this.
JDBC does not allow you to open a session using two passwords(old one and a now one).
Also errors messages from OCI drivers contain more information then JDBC ones.
We don't require to install Oracle 11g client if we want to access the Oracle database which is present on different machine or server. We just require the tool for accessing the same. For example, SQL Developer. Also we require the credentials such as username, password, hostname, sid, port no.
Related
Testing SQL queries with large datasets against Azure SQL server may be costly, so it is better for me to test my code against a local server. I would like to create a new local server with "SQL Server authentication" rather than "Windows authentication", and I would like to keep my default local server that uses Windows authentication.
In lack of better phrasing:... is it "common" to have multiple SQL servers with different authentication methods on the same Windows-10 pc ?
If it is "straight-forward" to do this, then please share "how-to", or share better jargon for web searches. I did not find much information on this when googling "create new local server with sql server authentication"
As you may easily catch from the text: I'm not an IT expert...
Yes, you can use at an instance and solely your will to provide the accesses.
where you can use Windows Authentication mode and mixed mode.
More information about Windows Authentication may be found at: Connecting Using Windows Authentication.
We may utilize SQL Server Authentication to solve your problem by passing the user name and password.
I wanted to read AWS Postgresql from within SQL Server, so
I created a system ODBC connection to Postgresql on the SQL Server machine, tested it, fine.
I then created a Linked Server to connect to postgresql.
In the Security tab (For a login not defined in the list above, connections will), I selected "Be made using the login's current security context".
When using this linked server while connected to SQL Server through windows authentication, it works fine.
If I connect to SQL Server using a SQL Server authenticated account, trying to access postgresql data through that same Linked Server fails authentication.
I fixed that by switching my security setting to "Be made using this security context" and giving the POSTGRESQL login/password (same that I gave at the ODBC level).
Question:
Without repeating the postgresql details at the Linked Server stage, why is it working with Window sauthentication account and not for SQL Server authenticated accounts?
Neither are relevant to Postgresql?...
I made it work but still confused...
I will have to guess a bit to help you, but I hope to give you enough context to understand what is happening so you can debug further.
When you connect to SQL Server using integrated authentication, the domain controller gives out a token to talk to SQL and this is used to authenticate your connection from your client to SQL Server's process. Underneath the covers, Windows can use either NTLM or Kerberos to do this handshake. You can read more about this here in this blog post:
NTLM vs. Kerberos Blog. This protocol choice matters when trying to use linked servers since it has to then authenticate to something else over the network.
At this point, it matters what credentials are used to run SQL Server (usually as a service in the services window to see). If you are running SQL as Local System or Network Service or something else defined by windows (instead of as a specific user on the network), it may or may not have permissions to talk out to your target remote server (whether it be postgres or something else). When you use Kerberos and enable delegation (which the domain admin needs to do), you can have the original integrated auth credentials "flow" over the linked server link to the next connection. NTLM does not do this. Therefore, the usual scenario is to create a map in the local SQL Server of what credentials to use when talking out to a remote linked server.
If you are talking to an ODBC driver, then you are likely using the msdasql (OLEDB to ODBC bridge) provider and then also having to go through its authentication stack. It has been too long for my memory as to whether it even supports integrated auth at all, much less delegation in Kerberos. However, you may be able to debug this problem further if you:
consider which account is running SQL
consider which mechanism is used to do integrated auth to sql and whether that would work with delegation
determine which credentials are used to make the outbound connection to your ODBC target. You should be able to debug much of this through the profiler mechanism as there is a distributed query/linked server set of events IIRC.
I can't speak to your postgres provider specifically, but this should give you some more tools to debug. Hope that helps you get one step further.
I want to access a remote Microsoft SQL Server 2012 database from a Java web application (JSP and surrounding classes) using Microsoft JDBC Driver 4.0. I was told the username/password for the database, but would prefer not storing the verbatim password as part of the web application's configuration.
Does Microsoft SQL Server 2012 support another authentication method where I could pass e.g. some kind of service token instead from a remote (not necessarily Windows-based) host, and more generally, what are best practices for storing and configuring database access configuration parameters in such a scenario?
From a Windows box in an Active Directory (AD) environment, you can use integrated security. This will connect to SQL Server using the AD security credentials of the current process (Windows account).
Specify integratedSecurity=true instead of user name and password in the connection string. See Building the Connection URL for more information.
SQL Server also supports Kerberos authentication using the Microsoft JDBC driver for Linux as specified with the authorizationScheme connection string keyword.
I created a database using microsoft sqlserver and an application that use the database. The application would be deployed on the client's computer as well as the database.
Do i need to install microsoft sqlserver on my client's computer in order to the database to work?
no, you have just to configure your database to accept connection from other computer, and set the connection string for your server and databse
more explanation :
If I understand your edit, you want to Know if you have to install SqlServer in the Client Machine to run your application;
if this is your real question then yes, the sql server is relational database management system (an engine to manupulate your data base)
and in this case you have to update your string connexion related to the new sqlserver engine name and the path to this engine
I need to connect to a secure SQL Server database using Perl DBI. I need to find a way to authenticate the user securely (without fear of eavesdropping, and without storing passwords on the client side). I'm using SQL Server 2008 on Windows Server 2008, and Perl 5.10 on XP.
SQL Server supports encrypted connections via something called the "SQL Server Native Access Client API", but I cannot tell whether this is supported by any DBD driver, or how to use it if it is.
I am reluctant to use the DBD::ODBC driver with SQL Server authentication, because ODBC transmits user IDs and passwords in cleartext.
I can't use the DBD::ODBC driver with Windows authentication (trusted connection), because the server is not on any Active Directory domain that is accessible from the client's network.
How can I secure my connections to the database? Thanks.
I am reluctant to use the DBD::ODBC driver with SQL Server authentication, because ODBC transmits user IDs and passwords in cleartext.
That is not strictly true. If you are using a recentish SQL Server and have not disabled encryption in it then the username/password and connection string are encrypted as follows:
The client contacts the server and tells it what it is capable of (e.g., it can do SSL). If the server then supports SSL it requires the client end to encrypt the connection info and falls back to unencrypted after that. You should also see the "Use Strong encryption for data" checkbox in the DSN.
Two options:
Create an IPSec tunnel between two locations. Some info here:
technet.microsoft.com/en-us/library/cc737154(WS.10).aspx
technet.microsoft.com/en-us/library/cc786385(WS.10).aspx
Enable SSL. I am not sure how well it would be protected.
technet.microsoft.com/en-us/library/ms189067.aspx
I would suggest that you use some kind of secured connection system. It might be IPSec, but it is often viewed as complicated, so you might be better (or faster) off with OpenVPN, which I use, and generally am happy with.
It can be used on virtually any operating system, is fast, and free. You can check it here: http://openvpn.net/