Impostazione del server collegato server SQL Server SQL

Spiega cosa è necessario per impostare un server collegato a SQL Server.

Server A è l'accesso di Windows solo SQL Server Server B è lo stesso (solo SQL login di Windows 2005)

  • MSSQL 2012 utilizzo dei core CPU?
  • L'authentication di Windows in SQL Server consente all'utente di visualizzare qualsiasi database
  • C'è una cronologia di connessione per SQL Server?
  • C'è un modo per determinare la versione di SQL Server utilizzata per creare un file MDF o BAK?
  • Ripristino del database da un altro server
  • migrare gli accessi e la password da sql 2000 a sql2005
  • Server A esegue Windows XP Server B esegue Windows Server 2003

    Entrambi i servizi di SQL Server vengono eseguiti con lo stesso account di dominio. Sono connesso alla mia workstation con un account di dominio che dispone di diritti amministrativi su entrambi i server SQL.

    Notare che questi sono entrambi SQL Server 2005 SP2 – ho avuto vecchi aggiornamenti rapidi mi hanno indicato, ma sono già applicati.

    Il problema che sto avendo è questo errore: "L'accesso non è riuscito per l'utente 'AUTHORITY \ ANONYMOUS LOGON' di utente" (Microsoft SQL Server, Error: 18456) "

  • Come trasferire un database su base settimanale per scopi di analisi
  • Impostazione di un semplice ethernet & dial-up server
  • come dividere un database molto grande sul server sql
  • SQL Server e spazio su disco
  • Raccomandazioni sulla configuration hardware di SQL Server
  • il sistema locale e NT AUTHORITY \ SYSTEM lo stesso?
  • 9 Solutions collect form web for “Impostazione del server collegato server SQL Server SQL”

    Da mia comprensione di questo problema è un problema "HOP".

    vale a dire che si sta tentando di utilizzare il server A per trasmettere i dati di accesso (con SSPI) al server B.

    In SQL Server 2005 hanno aggiunto un integer carico di problemi di protezione che rendono questo più duro di quanto dovrebbe essere. Le parole "Autenticazione Kerberos" diventeranno la barra della maggior parte delle vite di sys-admins / DBA. E 'efficace per l'authentication pass-through.

    Ecco le basi di ciò che ti serve. 1) I server (A e B) devono essere configurati in Active Directory (AD) con delegazione per Kerberos abilitata. (questo viene impostato tramite il pannello di amministrazione della directory triggers)

    2) L'account di servizio in cui eseguire i server SQL è necessario distriggersre anche la delegazione (questo è anche impostato tramite il pannello di amministrazione della directory triggers). – se non si esegue sotto un account di servizio, è necessario crearne uno.

    3) I server devono disporre di SPN definiti per l'istanza e l'HOST e il nome della macchina. (Utilizzando uno strumento denominato SetSPN negli strumenti di supporto di Windows)

    Strumenti di supporto (SetSPN è presente in questo set) http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&DisplayLang=en

    (Panoramica su come aggiungere un SPN) http://technet.microsoft.com/en-us/library/bb735885.aspx

    4) Potrebbe essere necessario impostare il DB in "affidabile"

    ALTER DATABASE SET affidabile

    5) Dopo aver fatto tutto questo, riavvii le tue istanze.

    6) Quindi provare a creare nuovamente il server collegato.

    Infine è ansible testare la connessione a SQL Server. Questo dovrebbe funzionare bene se hai tutto configurato correttamente.

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

    Ciò vi dirà il tipo di authentication di connessione.

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

    Volete get qui "KERBEROS" e non "NTLM".

    È un pendio scivoloso, KERBEROS e la delegazione Pass-through, bastone con esso e alla fine lo scoprinetworking.

    Referenze 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

    Altre manifestazioni del problema 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

    Spero che tutto questo aiuti.

    È inoltre ansible utilizzare SQL Server Management Studio (SSMS) per gestire \ creare server collegati anche se si è più a tuo agio con la GUI. Fare così:

    1. Avviare SSMS e connettersi a una delle istanze di SQL Server che si desidera colbind
    2. Espandere "Oggetti server" in Esplora oggetti
    3. Fare clic con il button destro del mouse su "Server collegati" e scegliere "Nuovo server collegato"
    4. Nella window di dialogo "Nuovo server collegato", select "SQL Server" come Tipo di server e immettere l'istanza di SQL Server a cui si desidera colbind.
    5. Nella pagina "Sicurezza", select come gli utenti verranno autenticati dal server corrente al server collegato. Si è menzionato che entrambi i server sono impostati per utilizzare Windows Logins. Se questo è il caso, nella sezione indicata "Per un login non definito nell'elenco precedente, le connessioni verranno:" Probabilmente scegliere l'opzione etichettata "Fatto utilizzando il context di protezione corrente di Login" .

    Tieni presente che questo presuppone che gli utenti che dispongono di login sul server A dispongano anche di login sul server B.

    Sto andando i dadi con lo stesso problema! Ricordo di averlo fatto con il 2000 è stato sempre facile. Sono stato in tutto Google e non posso farlo funzionare. La stessa impostazione esatta, entrambi i server in esecuzione su un account di dominio, auth di Windows.

    Sto cercando di utilizzare i pipi denominati invece di TCP e alless ho un errore diverso:

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

    Questo potrebbe avere qualcosa a che fare con l'abilitazione dei nomi pipes, ma posso colbind tramite sqlcmd dal server A al server B come questo:

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

    Se non usi pipes denominati, e fai semplicemente:

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

    Ottengo questo:

     Login failed for user NT AUTHORITY\ANONYMOUS LOGIN 

    [Edit] Ho iniziato una discussione su Sql Server Central su questo. Fondamentalmente, devi fare una certa configuration complicata in relazione alla delegazione Kerberos per far funzionare questo.

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

    Ho deciso di creare un solo account di accesso Sql limitato per gestire le query collegate. Odio ricorrere a questo, ma sembra più sicuro dei cambiamenti che devi fare per farlo funzionare con windows auth.

    Se fai una ricerca su sp_addlinkedserver e sp_linkedserver, ottieni alcuni esempi. E 'abbastanza semplice da installare.

    Anche se si dispone di SQL Manager, è ansible aggiungere con GUI.

    Fondamentalmente è necessario colbind i due server da parte delle SP citati da Tim o tramite GUI e quindi impostare le regole di accesso (che non è neanche necessario se si utilizza l'authentication di Windows su entrambi i server).

    So che questo dovrebbe essere facile, ma non funziona affatto per me – ho qui problemi di sicurezza. Quindi vorrei che qualcuno spiegasse i passi per me.

    Lo ho fatto in passato su SQL 2000 senza problemi.

    Quindi puoi collegarli, ma non puoi eseguire una query a causa di account sbagliati?

    L'utente di Windows che si tenta di utilizzare ha i diritti di leggere i dati sul server?

    Una volta ho avuto anche un problema perché la properties; "accesso ai dati" era impostata su false per qualche motivo sconosciuto.

    Provare anche ciò che accade se esplicitamente impostate un utente su un altro utente per il collegamento.

    (Questi tutti possono essere eseguiti in SQL Manager.)

    Tim ha pubblicato i passi esatti che avevo assunto erano quelli corretti. Il passo 5 è la pagina di sicurezza. Faccio una scelta utilizzando il context di protezione corrente di accesso.

    Quando faccio clic su ok, ho il seguente errore. Non so perché sta cercando di usare 'Autorità NT \ login anonimo'. Sono connesso alla mia workstation con il mio account di dominio che ha tutti i diritti su entrambi i server.

    TITOLO: Microsoft SQL Server Management Studio

    "Il server collegato è stato creato ma non è riuscito a eseguire un test di connessione. Vuoi mantenere il server collegato?"

    —————————— INFORMAZIONI AGGIUNTIVE:

    È stata un'exception durante l'esecuzione di un'istruzione o un batch di Transact-SQL. (Microsoft.SqlServer.ConnectionInfo)


    Accesso non riuscito per l'utente 'NT AUTHORITY \ ANONYMOUS LOGON'. (Microsoft SQL Server, errore: 18456)

    Per l'aiuto, fare clic su: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=09.00.3068&EvtSrc=MSSQLServer&EvtID=18456&LinkId=20476

    Provare a fare questo mentre si è connessi a livello locale al server, se lo si esegue da una macchina remota potrebbe non essere l'invio delle credenziali corrette.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.