We use a Microsoft Access database with linked tables to an SQL Server, and are working on encrypting data as it moves across the network. I have installed a certificate on a SQL Server (2014) that has been issued from a domain certificate server, and that is working fine except the links won't work now. I haven't been able to find anything on how I may be able to get the linked tables working.
Related
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 have an old ASP Classic site which connects to a SQL Server database which uses a Linked Server to access a Microsoft Access database via OPENQUERY in a view (!), like this:
A Linked Server is configured to connect to the Access database using Microsoft.ACE.OLEDB.12.0
A view view_requests retrieves the data from a table in the Access database:
SELECT *
FROM OPENQUERY(MY_LINKED_SERVER, 'SELECT * from Requests') AS Rowset_1
The ASP Classic page retrieves the data:
Set getRequests = dbConnect.Execute("SELECT * FROM view_requests")
Since moving it from a Server 2003 to a Server 2012 machine it no longer works.
The error given on the ASP page is:
OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "MY_LINKED_SERVER" returned message "Cannot start your application. The workgroup information file is missing or opened exclusively by another user.
But I have a feeling this is misleading for several reasons. The error seems to occur in lots of different scenarios and none of the posts I've found represent mine exactly. The main thing to note is that the view works fine and I can therefore access the data via SQL Server, which to me suggest it's not an issue with user mappings and so on, but I may be wrong. The problem occurs when connecting via the ASP Classic page. We've tried using both .mdb and .accdb formats.
Any suggestions on what I can try would be much appreciated. Thanks!
This sounds like it might be a permissions problem (I was going to say 'access' but that came out confusing!).
How are you controlling access to the SQL database? Is it Windows Authentication or using a SQL logon? If it's Windows Auth, then you need to give either the calling user's (if using Impersonation on the web site) or the Windows Identity that ASP.NET is running under access to the Access database file. If using a SQL Logon then you need to give the Windows Identity that SQL Server is running under that access.
The error is not necessarily accurate and from my experience, it probably is not. The account that SQL Server is running under (NOT the SQL Login) must have full permission on the folder where the Access file is located. Another possibility is that the linked server is not using the correct ACE driver, or it is not installed. If using SQL Server 64 bit, you'll need the 64 bit ACE driver.
It seems the issue was that we were incorrectly mapping the SQL user to the remote server (Linked Server > Properties > Security), even though it seemed we'd tried every possible combination of settings under the sun! So it seems the original misleading error was trying to tell us that the user didn't have the permission.
It is currently working with the Local Login mapped to Admin, the default Access database user which has a blank password. Under For a login no defined in the list above, connections will: we have selected Be made using the login's current security context.
Thanks to AVG for pointing me in the right direction.
I have a virtual machine in the cloud that runs SQL Server and a database that is publishing for merge replication. I have followed all the steps as outlined in Microsoft documentation but my subscriber client is getting stuck with the following error...
The remote server 'xxxx.cloudapp.net' does not exist, or has not been designated as a valid Publisher, or you may not have permission to see available Publishers.
The client has created the subscription and is able to connect to the server in order to get this far and so the server definitely does exist and can be communicated with. I have given full permission to access the ReplData directory for all users so I cannot see how permission would be a problem.
Any ideas?
I have an old Access project (.adp) that was tied to a SQL Server database using integrated authentication. The .adp is only used this time of year. Since its last use, the SQL Server has been virtualized and patched to current. When I try to open the .adp, it gives me a "Cannot generate SSPI context" error. I got this with another .mdb and just remapped the linked tables through ODBC with a SQL Server login (integrated authentication is not a requirement). However, with this .adp file, just about all the options are greyed out. For example, Linked Table Manager and ODBC Database buttons are greyed out. I can't see any tables, nor apparently link or import any. Is there a way to remove integrated authentication from an .adp project? Or can I convert the database to an .mdb (exporting objects appears greyed out as well)?
NOTE: This is a limited use database with few users on its way out, so I'm very open to "creative" workarounds that don't require me rebuilding the whole thing.
Please, review the following:
Check that SQL Server allow integrated authentication
Your machine (where you open the adp project) and the server are both in the same
domain.
That error is typical when the client machine belongs to another domain or not belongs to any domain.
I have an Sql Server database that includes a linked server to an MS Access mdb database. The Access database has workgroup security and requires a valid user name and password. This is easily set up in the linked server dialog in sql management studio. The problem is that the Sql Server needs to be able to find the MS Access mdw file to be able to login.
The only way I have managed to get this to work is by setting the Registry value SystemDB of the registry key :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines
to the path of the workgroup file but this causes other problems (like with other MS Access apps or Excel).
Is there a better way of doing this?
I haven't done this for a while, nor in recent versions of SQL server, but I seem to remember that when you add a link to a Jet database it provides the opportunity to define the workgroup, username and password. Certainly if you're using ODBC, that's part of the basic ODBC driver for Jet.