I have two SQL Servers which have been linked using sp_addlinkedserver 'ServerB\Instance' from ServerA and sp_addlinkedserver 'ServerA\Instance' from ServerB.
If I execute the following query from ServerA then everything is okay:
SELECT *
FROM [ServerB\Instance].Database.dbo.Table
If I execute the following query from ServerB an error occurs:
SELECT *
FROM [ServerA\Instance].Database.dbo.Table
Error:
Msg 18456, Level 14, State 1, Line 1
Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'.
The service accounts that SQL Server runs under on ServerA and ServerB have been given elevated permissions on both servers in an attempt to solve the issue but no success.
I have done research but want to avoid a convoluted process when communication one way is okay.
I have solved this by following the process:
Deleted both linked servers.
Executed sp_addlinkedserver for ServerA from ServerA RDP (SSMS) and for ServerB from ServerB RDP (SSMS).
Previously I had executed sp_addlinkedserver for both servers from the one server RDP (SSMS) session only. Executing from each server has solved the problem. If someone can add comments as to why this is then I will be very grateful.
In SQL Management Studio, view the properties for the linked server from Server B to Server A. There's a security "tab" that you can view from there. That will tell you the security context the connection from B to A is using. The error you are getting normally occurs when you don't have a valid security context set for the linked server.
The reason that it can work from A to B and not B to A is that you need to set up the linked server correctly on each side. Just doing it for one is not going to work to go both ways.
You have to map your local user to a remote user on the other server.
Do can do this by calling sp_addremotelogin() as explained here: http://msdn.microsoft.com/en-us/library/ms186338.aspx
To work around this problem, use one of the following methods:
Map the clients on server A to a standard security login on server B, by using either the sp_addlinkedsrvlogin stored procedure or the Security tab of the Linked Server Properties dialog box in Enterprise Manager.
If you are running the distributed query on an instance of SQL Server that is running on a Microsoft Windows 2000-based computer, configure SQL Server to listen for client requests by using the Named Pipes Server network library, instead of using the TCP/IP Server network library or the Multiprotocol Server network library. To configure the Server network libraries for SQL Server, use the Server Network Utility.
Take a look at:
http://support.microsoft.com/kb/238477
Related
I have a SQL statement that merges 2 databases together, from 2 different servers (SQL Server 2012 for both).
The two servers are linked, so when executing the statement in a query window from Management Studio with the SA account it works perfectly.
However, I need to automatize this. I created a Job in the SQL Server Agent, and I keep getting an authentication error. This is because the user that is executing the SQL Server Agent service doesn't have the SA rights on both servers.
This is the error:
The OLE DB provider 'providerName' for the connection server
'serverName' reported an error. Authentication failed.
I tried setting a superadmin user from the Active Directory with all rights on both servers to execute the SQL Server Agent, but I still get the error.
Is there any way to fix this?
Thanks
You can store your linked server credentials with your linked server definition (forbid my picture editing skills ;-)):
Alternatively - and much more preferabele from security point of view - setup same account on both servers (you can then limit the account privileges as you need) and use the third option ('Be made using the login's current security context')
We have 2 SQL Servers in each of our environments. Server A is our Data Warehouse SQL Server and Server B is our OLTP server. We have the following environments PROD, STAGE, SIT, DEV. We have configured a linked sever on Server A in each environment to read, write and Exec a stored procedure on Server B. A SQL job was created on Server A to do a simple select statement from Server B to test the connection. The service account that will be running all of the jobs was configured as the job owner and "Run as User". In Prod, STAGE and SIT the test job is working. In DEV the test job is failing with the message "Access to the Remote Server is Denied because the current security context is not trusted"
I have logged in to server A as the service account and run the exact select command to server B in a query window and the command successfully returns results.
I tried a SQL job on Server A in DEV that calls an SSIS package. It uses the same service account as the test job via a proxy & credential. The SSIS package is calling a stored procedure on Server B. When I run this job it succeeds and executes a stored procedure on Server B that writes data to server B.
I validated that the Service account has administrator privileges set the same across all environments.
I validated that the Linked server has the same configuration across all environments.
I have tried to set up the Linked Server to link the service account on Server A to a SQL account on Server B
I have tried to set up the Linked Server to "Be made using the login's current security context" on Server B
I have tried changing the SQL job to run as an operating system CmdExec. SQLCMD -E -Q "select * from [Server].[Database].[Schema].table" using the same proxy and credential as the job that is working. This resulted in the following error
"A network-related or instance-specific effor has occured while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections."
I validated that the servers can ping each other.
I ran SQLCMD -L via the command line to validate that the servers are both present.
I enabled the Named Pipes protocol on both servers A and B in the configuration manager.
I tried running the test job under my credentials as an SA and got the same
"Access to the Remote Server is Denied because the current security context is not trusted" message.
I tried copying and pasting the SQL from the test job into a query window on Server A using my credentials and was able to run the query successfully.
I tried recreating the SQL job.
I tried restarting the SQL Services.
The only appreciable difference I can think of between this environment and the others is that Server A is a named instance and Server B is a default instance.
Also of note, the SQL Browser service on Server B is being run by a local account instead of a service account. SQL Browser on Server A is being run by a service account.
I am trying to create a linked server in SQL Server:
--Create the link to server "uranium"
EXEC master.dbo.sp_addlinkedserver
#server = N'uranium',
#srvproduct=N'',
#provider=N'SQLNCLI'
--Add the catch-all login with SQL Server authentication
EXEC master.dbo.sp_addlinkedsrvlogin
#rmtsrvname=N'uranium',
#useself=N'False',
#locallogin=NULL,
#rmtuser=N'BatteryStaple',
#rmtpassword='Horsecorrect'
And it creates fine. But any attempt to query the linked server, e.g.:
SELECT * FROM uranium.Periodic.dbo.Users
results in
Msg 18456, Level 14, State 1, Line 1
Login failed for user 'BatteryStaple'.
Except i know the credentials are correct:
Login: BatteryStaple
Password: Horsecorrect
because i can login when i connect directly using SQL Server Management Studio, or any other technology that is able to connect to a database.
Bonus Reading
Login Failed for linked server (he forgot to call sp_addlinkedsrvlogin)
Why am I getting a “login failed” when creating this linked server? (he's trying to use integrated authentication)
MSDN Blogs: SQL Linked Server Query failed with “Login failed for user …” (he's trying to make integrated authentication work)
Note: New SQL Server 2014 install. Every existing SQL 2000, 2005, 2008, 2008 R2 can communicate to their uranium linked server. I'm certain it is related to Microsoft's frustrating broken by default policy.
The issue is that the SQL Server Management Studio interface creates the linked server using the OLEDB Provider:
This is equivalent to the original T-SQL:
--Create the link to server "uranium"
EXEC master.dbo.sp_addlinkedserver
#server = N'uranium',
#srvproduct=N'', #provider=N'SQLNCLI'
The fix is to create the linked server as SQL Server:
--Create the link to SQL Server "uranium"
EXEC master.dbo.sp_addlinkedserver
#server = N'uranium',
#srvproduct=N'SQL Server'
Shouldn't matter. Probably a regression in Microsoft SQL Server 2014 12.0.4213.0. Might be fixed in a service pack - if there is one.
But there it is; solved.
Old post, but might be useful still. In my case it was that only Windows Authentication was set. Setting authentication for both Windows and SQL Server on the linked server fixed it.
The issue for me was this: Since I was trying to connect to instance via servername\instancename - ALL my instances were running on port 1433 so the "Add Linked Server" was actually connecting to the default instance - and the login was failing.
Go to SQL Configuration Manager
Click on Protocols for [instancename]
Open TCP/IP properties and be sure it's enabled AND flip to the "IP Addresses" Tab and change the port on ALL IPs that you are using for your linked server IP is (a) active and (b) using a unique port - like 14333 (this was important as my VPN IP was not "active".
You may have to do this for both 32 and 64 if your machine is running both
DONT FORGET TO STOP and START THE INSTANCE
This is the fix
In SSMS 2008, I am trying to execute a stored procedure in a database on another server. The call looks something like the following:
EXEC [RemoteServer].Database.Schema.StoredProcedureName
#param1,
#param2
The linked server is set up correctly, and has both RPC and RPC OUT set to true. Security on the linked server is set to Be made using the login's current security context.
When I attempt to execute the stored procedure, I get the following error:
Msg 18483, Level 14, State 1, Line 1
Could not connect to server 'RemoteServer' because '' is not defined as a remote login at the server. Verify that you have specified the correct login name.
I am connected to the local server using Windows Authentication. Anyone know why I would be getting this error?
'Be made using the login's current security context' translates as impersonation (aka. as 'self-mapping' in SQL Server linked in terms). Access a remote server under an impersonated context means delegation. So you need to set up the constraint delegation, see Configuring Linked Servers for Delegation:
Requirements for the Client
The Windows user must have access permissions to SQLSERVER1 and
SQLSERVER2.
The user AD property Account is sensitive and cannot be delegated must not be
selected.
The client computer must be using TCP/IP or named pipes network connectivity.
Requirements for the First/Middle Server (SQLSERVER1)
The server must have an SPN registered by the domain administrator.
The account under which SQL Server is running must be trusted for delegation.
The server must be using TCP/IP or named pipes network connectivity.
The linked server logins must be configured for self mapping.
Requirements for the Second Server (SQLSERVER2)
If using TCP/IP network connectivity, the server must have an SPN registered by the domain administrator.
The server must be using TCP/IP or named pipes network connectivity.
run the following command, and it may fix it for you
exec sp_AddRemoteLogin 'YourServerName','LoginName'
I think (not sure) that the passwords have to be the same on both machines.
We are using a SQL Native Client to connect to a local SQL Server 2005 from a Borland application. It will fine for selects, inserts, and updates. When we delete we get the error:
Could not find server
SERVERNAME\SQLEXPRESS in
sys.servers. Verify that the correct
server name was specified. If
necessary, execute the stored
procedure sp_addlinkedserver to add
the server to sys.servers
The default instance, the only instance, is SERVERNAME\SQLEXPRESS, and we are not using linked servers. Any ideas? I believe we moved the MDF and LDF files to a new server for this DB, and then reattached it.
Update 1
There is no SQL. This is all happening through programmatic interaction with cursors. It is an ODBC driver using ADO. You run TableObj->Delete to remove the record.
Got it. I ran
SELECT ##servername
That returned the old host name of the box. I than ran
sp_dropserver 'OLDHOSTNAME\SQLEXPRESS'
go
sp_addserver 'NEWHOSTNAME\SQLEXPRESS', local
I then got
Server 'NEWHOSTNAME\SQLEXPRESS' is not
configured for DATA ACCESS
I ran
sp_serveroption 'ICS-POS3-NEW\SQLEXPRESS', 'data access' , 'true'
This got me the error
Transaction context in use by another
session
Which is because of linked servers. I found that the local option on the add server did not take affect until I restarted the server. I restarted, then it just worked.