Konfiguracja serwera połączonego z serwerem SQL SQL Server

Proszę wyjaśnić, co jest wymagane do skonfigurowania połączonego serwera SQL Server.

Serwer A to tylko logowanie Windows w Windows 2005 Serwer B jest taki sam (tylko logowanie Windows w Windows 2005)

Serwer A działa na systemie Windows XP Serwer B działa na systemie Windows Server 2003

Obie usługi SQL Server działają na tym samym koncie domeny. Jestem zalogowany na mojej stacji roboczej za pomocą konta domeny, które ma uprawnienia administracyjne na obu serwerach SQL.

Zauważ, że oba są SQL Server 2005 SP2 - Mam wcześniej wskazane stare poprawki, ale są one już zastosowane.

Mam problem z tym błędem: „Logowanie nie powiodło się dla użytkownika„ NT AUTHORITY \ ANONYMOUS LOGON ”. (Microsoft SQL Server, błąd: 18456)”

Z mojego zrozumienia tego problemu jest to problem „HOP”.

tzn. próbujesz użyć serwera A do przekazania danych logowania (za pomocą SSPI) do serwera B.

W SQL Server 2005 dodali całą masę problemów bezpieczeństwa, które sprawiają, że jest to trudniejsze niż powinno być. Słowa „Uwierzytelnianie Kerberos” staną się barem życia większości sys-admins / DBA. Jest skutecznie wykorzystywany do uwierzytelniania przekazywanego.

Oto podstawy tego, czego potrzebujesz. 1) Serwery (A i B) należy skonfigurować w usłudze Active Directory (AD) z włączonym delegowaniem dla protokołu Kerberos. (ustawia się to w panelu administracyjnym Active Directory)

2) Konto usługi, na którym działają Twoje serwery SQL, musi również mieć włączoną delegację (jest to również ustawiane w panelu administracyjnym Active Directory). - jeśli nie działają na koncie usługowym, musisz je utworzyć.

3) Serwery muszą mieć zdefiniowane nazwy SPN dla instancji, hosta i nazwy komputera. (Korzystanie z narzędzia o nazwie SetSPN w narzędziach obsługi systemu Windows)

Narzędzia wsparcia (SetSPN jest w tym zestawie) http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&DisplayLang=en

(Omówienie sposobu dodawania nazwy SPN) http://technet.microsoft.com/en-us/library/bb735885.aspx

4) Może być konieczne ustawienie DB na „godny zaufania”

ZMIEŃ ZESTAW BAZY DANYCH godne zaufania na

5) Po tym wszystkim zrestartuj instancje.

6) Następnie spróbuj ponownie utworzyć połączony serwer.

Wreszcie możesz przetestować połączenie z SQL Server. Powinno to działać poprawnie, jeśli masz wszystko poprawnie skonfigurowane.

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

Dzięki temu dowiesz się, jaki jest typ uwierzytelnienia połączenia.

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

Chcesz dostać tutaj „KERBEROS”, a nie „NTLM”.

To śliskie zbocze, KERBEROS i delegacja tranzytowa, trzymaj się go, a w końcu to rozwiążesz.

Odnośniki 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

Inne przejawy problemu 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

Mam nadzieję, że to wszystko pomoże.

Możesz także użyć programu SQL Server Management Studio (SSMS) do zarządzania \ tworzeniem połączonych serwerów, jeśli masz większą wygodę korzystania z GUI. Aby to zrobić:

1. Uruchom SSMS i połącz się z jednym z wystąpień SQL Server, które chcesz połączyć
2. Rozwiń „Obiekty serwera” w Eksploratorze obiektów
3. Kliknij prawym przyciskiem myszy „Połączone serwery” i wybierz „Nowy połączony serwer”
4. W oknie dialogowym „Nowy połączony serwer” wybierz „SQL Server” jako typ serwera i wprowadź wystąpienie SQL Server, z którym chcesz się połączyć.
5. Na stronie „Bezpieczeństwo” wybierz sposób uwierzytelniania użytkowników z bieżącego serwera na serwerze połączonym. Wspomniałeś, że oba serwery są skonfigurowane do używania Logowań Windows. W takim przypadku w sekcji zatytułowanej „W przypadku loginu niezdefiniowanego na powyższej liście połączenia będą:” Prawdopodobnie wybrałbym opcję „Wykonaj przy użyciu bieżącego kontekstu bezpieczeństwa Loginu” .

Należy pamiętać, że zakłada to, że użytkownicy, którzy logują się na serwerze A, również logują się na serwerze B.

Mam bzika na punkcie tego samego problemu! Pamiętam, że zrobienie tego z 2000 było zawsze łatwe. Byłem w wyszukiwarce Google i nie mogę tego uruchomić. Dokładnie taka sama konfiguracja, oba serwery działają na koncie domeny, uwierzytelnianie systemu Windows.

Próbuję użyć nazwanych potoków zamiast TCP i przynajmniej dostaję inny błąd:

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".

*/

Może to mieć coś wspólnego z włączaniem potoków nazw, ale mogę połączyć się za pomocą narzędzia sqlcmd z serwera A do serwera B w następujący sposób:

WALDORF:>  Sqlcmd.exe /E /Snp:statler

Jeśli nie użyłem nazwanych potoków i po prostu:

New Linked Server
Server Type: SqlServer
Security: be made using the current login's security context

Rozumiem:

Login failed for user NT AUTHORITY\ANONYMOUS LOGIN

[Edytuj] Rozpocząłem dyskusję na ten temat na Sql Server Central. Zasadniczo musisz wykonać skomplikowaną konfigurację związaną z delegowaniem Kerberos, aby to zadziałało.

http://www.sqlservercentral.com/Forums/Topic574262-146-1.aspx

Postanowiłem utworzyć tylko jedno, ograniczone konto Sql Login do obsługi połączonych zapytań. Nienawidzę uciekać się do tego, ale wydaje się to bezpieczniejsze niż zmiany, które musisz wprowadzić, aby działało z systemem Windows Auth.

Jeśli wykonasz wyszukiwanie na sp_addlinkedserver i sp_linkedservers, otrzymasz kilka przykładów. Konfiguracja jest bardzo prosta.

Również jeśli masz SQL Managera, możesz dodać go za pomocą GUI.

Zasadniczo musisz połączyć dwa serwery albo SP wymienionymi przez Tima, albo GUI, a następnie ustawić reguły dostępu (co nie jest nawet potrzebne, jeśli używasz uwierzytelniania Windows na obu serwerach).

Wiem, że to powinno być łatwe, ale w ogóle nie działa dla mnie - mam tutaj problemy z bezpieczeństwem. Chciałbym więc, żeby ktoś przeliterował mi kroki.

Robiłem to w przeszłości na SQL 2000 bez żadnych problemów.

Więc możesz je połączyć, ale nie możesz wykonać zapytania z powodu niewłaściwych kont?

Czy użytkownik systemu Windows, którego próbujesz użyć, ma prawa do odczytu danych na obu serwerach?

Kiedyś miałem również problem, ponieważ właściwość „dostęp do danych” została ustawiona na false z nieznanego powodu.

Wypróbuj również, co się stanie, jeśli jednoznacznie ustawisz jednego użytkownika na innego użytkownika dla łącza.

(Wszystko to można zrobić w SQL Managerze).

Tim opublikował dokładne kroki, które według mnie były prawidłowe. Krok 5 to strona bezpieczeństwa. Wybieram „Wykonaj przy użyciu bieżącego kontekstu bezpieczeństwa logowania”.

Po kliknięciu OK pojawia się następujący błąd. Nie wiem, dlaczego próbuje użyć „NT Authority \ Anonimowego logowania”. Jestem zalogowany na mojej stacji roboczej za pomocą konta domeny, które ma wszystkie prawa na obu serwerach.

TYTUŁ: Microsoft SQL Server Management Studio

„Połączony serwer został utworzony, ale test połączenia nie powiódł się. Czy chcesz zachować połączony serwer?”

------------------------------ DODATKOWE INFORMACJE:

Wystąpił wyjątek podczas wykonywania Transact-SQL instrukcji lub partii. (Microsoft.SqlServer.ConnectionInfo)

---

Logowanie nie powiodło się dla użytkownika „NT AUTHORITY \ ANONYMOUS LOGON”. (Microsoft SQL Server, błąd: 18456)

Aby uzyskać pomoc, kliknij: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=09.00.3068&EvtSrc=MSSQLServer&EvtID=18456&LinkId=20476

Spróbuj to zrobić, gdy jesteś zalogowany lokalnie na serwerze, jeśli robisz to ze zdalnego komputera, możesz nie wysyłać odpowiednich poświadczeń.