Similar problem to one reported here:
Can't create linked server to Snowflake
Difference is while connecting to snowflake I cannot authenticate user in the SSMS:
ODBC driver must be verified by external browser (no password) but it is not happening here. Internet browser in SSMS is working fine, but it is not used to authenticate ODBC user. Configuration of ODBC is fine, as it is working in PowerBI and starting authentication process in default internet browser. Any ideas?
ODBC driver must be verified by external browser
Linked server connections run in the SQL Server process, so there's no interactive access to the desktop to do any kind of interactive authentication.
Related
i have active directory, both sql server db01 and db02 are joined in domain and setup default all.
i'm trying to connect another sql server instance db02 from db01 sql server
file->connect
Server Type: Database Engine
Server Name (i tried IP address or FQDN but it's still not working)
Authentication: Windows Authentication
Domain\Administrator
When i click connect button it says
enter image description here
i also tried enabling the sa account and setting password, can't also connect
i tried firewall off on both db01 and 02, still the same issue.
all services for sql is running, and network tcp and pipename are enabled.
remote connection is set to enable/allow
did i miss anything?
I think the error message tells you correctly that the problem is around authentication.
Either you are using a non-Windows application to connect to the the SQL server instances OR you are logged with your normal account BUT you are trying to authenticate as Domain\Administrator. Windows authentication will mostly not let you do that.
A problem with some non-Windows tools is that they let you try to connect using Windows Authentication and typing in a username, but it will never work. Instead, to use windows authentication you have to login to Windows as Domain\Administrator OR run your Application as Domain\Administrator, using e.g. right-click 'Run as other user'
To connect from a non-Windows platform using windows authentication depends entirely on your application and driver having correctly implemented it.
I am trying to get MuleSoft to talk to a SQL Server using an Active Directory User.
I have gotten it to connect using a user defined in SQL Server, however our DBAs are saying we have to connect with an AD User.
I am getting "login failed" errors
java.sql.SQLException: Cannot get connection for URL jdbc:sqlserver://AG-Q4Test1:1433;databaseName=T10SRV01 : Login failed for user 'HQ\MuleSoftSvc'
I have tried to connect using my credentials and have received the same error. I can connect using SQL Management Studio with my credentials.
I am using the Microsoft SQL Server Driver com.microsoft.sqlserver:mssql-jdbc.6.2.2.jre8
I am thinking that is because its using Windows Authentication
But will this work in CloudHub?
The method described in the KB article will not work in CloudHub because applications don't run in Windows. Take into account that you should not make any assumptions on the operating system and platform for applications deployed on CloudHub.
I was able get Windows Auth working from my local runtime using this article.
After more digging I found this KB Article from MuleSoft which states that Windows Auth is not supported in CloudHub.
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.
We have a client who uses MS Access to manipulate data in their SQL Server DB. I know that we can set up SQL Server to authenticate using Active Directory. If we set this up, can they use their AD logins to connect to SQL Server through Access? How?
I tried Googling this, but to no avail. Any links or direction would be much appreciated. Thank you.
Also, please direct me to the correct place, if I should ask this question elsewhere.
Yes this should be pretty straight forward. You can use Windows Authentication to connect to sql server.
When establishing ODBC connection from your Client, The Wizard for connection configuration to SQL Server takes you to a page which gives you options to choose how you want to connect to SQL SERVER. There you can choose to use Windows Authentication or SQL Server Authentication. You can choose the Windows Authentication Option.
Now when a client tries to connect to the SQL Server their windows credentials will be used to authenticate the user. And obviously if they are on a network their AD Account will Authenticate them.
See below a snapshot from ODBC Data Source Administrator wizard when configuring connection to sql server.
MSSQL Server is in the "abc" domain and have mixed mode authentication.
I am connecting from the machine which is not in domain or in a domain "xyz" but with in the same network using MSSQL Jdbc driver 2.0. I have logged in as admin or account in xyz domain.
It works fine using following url for connection for "sa" or SQL Mode Authentication.
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;DatabaseName=dbname
It doesn't work For window authentication using credential "MSSQLDomain\username" i.e "abc\username", using following url
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;integratedSecurity=true;DatabaseName=dbname;
Gives following error.
Login failed for user ''. The user is not associated with a trusted
SQL Server connection.
I have tried adding property Trusted_Connection=Yes to url, but still gives same error.
I don't want to map the drive of the SQL Server. I am able to access the any shared folder of the SQL Server Machine by providing "MSSQLDomain\username" and password.
It works fine for both authentication mode, if both machine is in same domain.
If I am using jtDS Driver from the machine which is not in domain or in "xyz" domain within same network i.e same subnet, it works fine.
This is the deliberate and correct behaviour of Windows Authentication.
It is because the Domain from which you are connecting from, is not the same Windows Domain as the one where your SQL Server instance resides.
I believe there are methods for bridging the Domains so to speak, however they require custom and tricky implementation. You also will have to configure a trust relationship between the domains.
The following thread contains discussions which you will likely find useful.
http://sql-server-performance.com/Community/forums/p/24601/137574.aspx
Changing the login credentials might help,
use SQL authentication instead of nt authentication
https://support.microsoft.com/en-us/kb/555332
Symptoms
After you install Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005, or SQL Server 2000 and you try to connect to the server that is running SQL Server, you receive one of the following error messages:
Login failed for user '%.*ls'. The login is a SQL Server login and cannot be used with Windows Authentication.%.*ls
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Login failed for user ''. (Microsoft SQL Server, Error: 18456)
Resolution
This problem occurs if the user tries to log in with credentials that cannot be validated. This problem can occur in the following scenarios:
Scenario 1:
The login may be a SQL Server login but the server only accepts Windows Authentication
To resolve this issue, configure SQL Server in Mixed Authentication Mode.
Scenario 2:
You are trying to connect by using SQL Server Authentication but the login used does not exist on SQL Server
To resolve this issue, verify that the SQL Server login exists. For more information, see Create a login in SQL Server Books Online.
Scenario 3:
The login may use Windows Authentication but the login is an unrecognized Windows principal
An unrecognized Windows principal means that Windows can't verify the login. This might be because the Windows login is from an untrusted domain. To resolve this issue, verify that you are logged in to the correct domain.
I have been involved with making a SQL server connection cross to domains like that, and it is exceptionally painful. In order to use credentials from another domain, the domain where you are assigning the permissions has to trust the domain, where the account is coming from. IT Pro's are generally VERY reluctant to trust another domain in this manner, and for good reason, so if this trust relationship has not been established it might not be very likely to convince the admins to do this.
Once you have the trust relationship established, you will probably need to register the SPN's for your SQL server in Active Directory, and assign delegation permissions. This type of environment is very difficult to setup, troubleshoot and maintain.
I hope that there is some other way that you can do this, because it sounds like you are headed for a very difficult scenario.
Hope it helps
Rihan