Пожалуйста, объясните, что требуется для настройки связанного сервера SQL Server.
Сервер A предназначен только для входа в Windows SQL 2005. Сервер B такой же (только для входа в Windows SQL 2005).
Сервер A работает под управлением Windows XP. Сервер B работает под управлением Windows Server 2003.
Обе службы SQL Server работают под одной учетной записью домена. Я вошел на свою рабочую станцию с учетной записью домена, которая имеет права администратора на обоих серверах SQL.
Обратите внимание, что это оба SQL Server 2005 SP2 - мне указывали на старые исправления, но они уже применяются.
Проблема, с которой я столкнулся, заключается в этой ошибке:
«Ошибка входа для пользователя NT AUTHORITY \ ANONYMOUS LOGON. (Microsoft SQL Server, ошибка: 18456)»
Насколько я понимаю, это проблема "HOP".
то есть вы пытаетесь использовать сервер A для передачи ваших данных для входа (с SSPI) на сервер B.
В SQL Server 2005 они добавили целый ряд проблем с безопасностью, которые усложнили задачу. Слова «Kerberos Authentication» станут изюминкой в жизни большинства системных администраторов / администраторов баз данных. Он эффективно используется для сквозной аутентификации.
Вот основы того, что вам нужно. 1) Серверы (A и B) необходимо настроить в Active Directory (AD) с включенным делегированием для Kerberos. (это устанавливается через панель администратора активного каталога)
2) Учетная запись службы, под которой работают ваши SQL-серверы, также должна иметь включенное делегирование (это также устанавливается через панель администратора активного каталога). - если они не работают под учетной записью службы, вам необходимо ее создать.
3) Серверы должны иметь SPN, определенные для экземпляра, ХОСТА и имени машины. (Используя инструмент SetSPN в инструментах поддержки Windows)
Инструменты поддержки (SetSPN входит в этот набор) http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&DisplayLang=en
(Обзор того, как добавить SPN) http://technet.microsoft.com/en-us/library/bb735885.aspx
4) Возможно, вам потребуется сделать вашу БД "заслуживающей доверия".
ALTER DATABASE SET заслуживает доверия
5) После того, как вы все это сделаете, перезапустите свои экземпляры.
6) Затем попробуйте снова создать связанный сервер.
Наконец, вы можете протестировать свое соединение с SQL Server. Это должно работать нормально, если у вас все настроено правильно.
SELECT *
FROM OPENDATASOURCE('SQLNCLI',
'Data Source=ServerB;Integrated Security=SSPI;'
).MASTER.dbo.syscolumns
Это сообщит вам тип аутентификации вашего соединения.
select auth_scheme from sys.dm_exec_connections where session_id=@@SPID
Вы хотите получить здесь «KERBEROS», а не «NTLM».
Это скользкий путь, KERBEROS и сквозное делегирование, придерживайтесь этого, и вы в конечном итоге разберетесь.
Ссылки Kerberos http://blogs.msdn.com/sql_protocols/archive/2005/10/12/479871.aspx
Другие проявления проблемы 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
Надеюсь, все это поможет.
Вы также можете использовать SQL Server Management Studio (SSMS) для управления \ создания связанных серверов, если вам удобнее работать с графическим интерфейсом. Для этого:
Обратите внимание, что это предполагает, что пользователи, которые имеют логины на сервере A, также имеют логины на сервере B.
Я схожу с ума от той же проблемы! Я помню, что делать это с 2000 всегда было легко. Я был по всему Google, и я не могу заставить это работать. Точно такая же настройка, оба сервера работают под учетной записью домена, Windows auth.
Я пытаюсь использовать именованные каналы вместо TCP и, по крайней мере, получаю другую ошибку:
EXEC sp_addlinkedserver
@server='statler',
@srvproduct='',
@provider='SQLNCLI',
@datasrc='np:statler',
@provstr='Integrated Security=SSPI'
-- Then I try this:
select net_transport, auth_scheme
from statler.master.sys.dm_exec_connections
where session_id=@@spid
/*
Getting closer, but still fails:
OLE DB provider "SQLNCLI" for linked server "statler" returned message
"Login timeout expired".
OLE DB provider "SQLNCLI" for linked server "statler" returned message
"An error has occurred while establishing a connection to the server.
When connecting to SQL Server 2005, this failure may be caused by the
fact that under the default settings SQL Server does not allow
remote connections.".
Msg 5, Level 16, State 1, Line 0
Named Pipes Provider: Could not open a connection to SQL Server [5].
OLE DB provider "SQLNCLI" for linked server "statler" returned message
"Invalid connection string attribute".
*/
Это может иметь какое-то отношение к включению каналов имен, но я могу подключиться через sqlcmd с сервера A к серверу B следующим образом:
WALDORF:> Sqlcmd.exe /E /Snp:statler
Если я не использую именованные каналы, а просто делаю:
New Linked Server
Server Type: SqlServer
Security: be made using the current login's security context
Я получаю это:
Login failed for user NT AUTHORITY\ANONYMOUS LOGIN
[Редактировать] Я начал обсуждение этого вопроса на Sql Server Central. По сути, вам нужно выполнить сложную настройку, связанную с делегированием Kerberos, чтобы это работало.
http://www.sqlservercentral.com/Forums/Topic574262-146-1.aspx
Я решил просто создать единственную ограниченную учетную запись Sql Login для обработки связанных запросов. Я ненавижу прибегать к этому, но он кажется более безопасным, чем изменения, которые вы должны внести, чтобы заставить его работать с Windows auth.
Если вы выполните поиск по sp_addlinkedserver и sp_linkedservers, вы получите несколько примеров. Его довольно просто настроить.
Также, если у вас есть SQL Manager, вы можете добавить его с помощью графического интерфейса.
В основном вам нужно связать два сервера либо с помощью SP, упомянутых Тимом, либо через графический интерфейс, а затем установить правила доступа (что даже не требуется, если вы используете проверку подлинности Windows на обоих серверах).
Я знаю, что это должно быть легко, но у меня это совсем не работает - у меня проблемы с безопасностью. Поэтому я хотел бы, чтобы кто-нибудь объяснил мне шаги.
Раньше я делал это на SQL 2000 без проблем.
Значит, вы можете связать их, но не можете выполнить запрос из-за неправильных учетных записей?
Имеет ли пользователь Windows, которого вы пытаетесь использовать, права на чтение данных на обоих серверах?
Однажды у меня тоже была проблема, потому что свойство «доступ к данным» было установлено в false по неизвестной причине.
Также попробуйте, что произойдет, если вы явным образом назначите одного пользователя другому пользователю для ссылки.
(Все это можно сделать в SQL Manager.)
Тим опубликовал точные шаги, которые, как я предполагал, были правильными. Шаг 5 - страница безопасности. Я выбираю «Использовать текущий контекст безопасности входа в систему».
Когда я нажимаю ОК, я получаю следующую ошибку. Я не знаю, почему он пытается использовать «NT Authority \ Anonymous login». Я вошел на свою рабочую станцию с моей учетной записью домена, которая имеет все права на обоих серверах.
НАЗВАНИЕ: Microsoft SQL Server Management Studio
«Связанный сервер был создан, но не прошел проверку соединения. Сохранить связанный сервер?»
------------------------------ ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ:
Исключение при выполнении инструкции или пакета Transact-SQL. (Microsoft.SqlServer.ConnectionInfo)
Ошибка входа для пользователя NT AUTHORITY \ ANONYMOUS LOGON. (Microsoft SQL Server, ошибка: 18456)
Для получения справки щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=09.00.3068&EvtSrc=MSSQLServer&EvtID=18456&LinkId=20476
Попробуйте сделать это, пока вы вошли в систему локально на сервере, если вы делаете это с удаленного компьютера, возможно, вы не отправляете правильные учетные данные.