SQL Server to SQL Server linked server setup

Please explain what is required to set up a SQL Server linked server.

Server A is SQL 2005 Windows logins only . Server B is the same (SQL 2005 Windows logins only) .

Server A runs Windows XP . Server B runs Windows Server 2003 .

Both SQL Server services are running under the same domain account. I am logged into my workstation with a domain account that has administrative rights on both SQL Servers.

Note these are both SQL Server 2005 SP2 - I've had old hot-fixes pointed out to me, but those are already applied.

The issue I am having is this error:

"Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. (Microsoft SQL Server, Error: 18456)"

Solution 1:

From My understanding of this issue it's a "HOP" issue.

i.e. you are trying to use server A to relay your login details (with SSPI) to Server B.

In SQL Server 2005 they have added a whole load of security issues that make this harder than it should be. The words "Kerberos Authentication" will become the bain of most sys-admins/DBA's lives. It effectively is used for pass-through authentication.

Here are the basics of what you need. 1) The servers (A and B) need to be set-up in Active Directory(AD) with delegation for Kerberos enabled. (this is set through your active directory admin panel)

2) The service account that your SQL Servers run under need to have delegation enabled also (this is also set through your active directory admin panel). - if they are not running under a service account, you need to create one.

3) The Servers need to have SPN's defined for the instance and the HOST and the machine name. (Using a tool called SetSPN in the windows support tools)

Support Tools (SetSPN is in this set) http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&DisplayLang=en

(Overview of how to add an SPN) http://technet.microsoft.com/en-us/library/bb735885.aspx

4) You may need to set your DB to "trustworthy"

ALTER DATABASE SET trustworthy on

5) After you have all of this done restart your instances.

6) Then try create your linked server again.

Finally you can test your connection to SQL Server. This should work fine if you have it all configured correctly.

SELECT *
FROM OPENDATASOURCE('SQLNCLI',
    'Data Source=ServerB;Integrated Security=SSPI;'
    ).MASTER.dbo.syscolumns

This will tell you your connection authentication type.

select auth_scheme from sys.dm_exec_connections where session_id=@@SPID

You want to get 'KERBEROS' here and not 'NTLM'.

It's a slippy slope, KERBEROS and Pass-through delegation, stick with it and you will eventually figure it out.

References Kerberos http://blogs.msdn.com/sql_protocols/archive/2005/10/12/479871.aspx

http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx

http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/the-biggest-mistake-serviceprincipalname-s.aspx

Other manifestations of the problem http://www.sqlservercentral.com/Forums/Topic460425-359-1.aspx

http://msdn2.microsoft.com/en-us/library/aa905162(sql.80).aspx

http://msdn2.microsoft.com/en-us/library/ms189580.aspx

I hope this all helps.

Solution 2:

You can also use SQL Server Management Studio (SSMS) to manage \ create linked servers as well if you're more comfortable with the GUI. To do so:

1. Launch SSMS and connect to one of the instances of SQL Server you want to link
2. Expand "Server Objects" in Object Explorer
3. Right click "Linked Servers" and choose "New Linked Server"
4. On the "New Linked Server" dialog, select "SQL Server" as the Server Type and enter the instance of SQL Server you'd like to link to.
5. On the "Security" page, select how users will authenticate from the current server to the linked server. You mentioned both servers are set up to use Windows Logins. If this is the case, under the section labeled "For a login not defined in the list above, connections will:" I would probably choose the option labeled "Be made using the Login's current security context".

Note that this assumes that users who have logins on server A also have logins on server B.