Cum de a transfera datele de conectare si parolele între instanţe ale SQL Server

IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată și poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate și articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cunoștințe în mai multe limbi. Articolele traduse automat și post-editate pot conține greșeli de vocabular, sintaxă și/sau gramatică. Microsoft nu este responsabil de inexactitățile, erorile sau daunele cauzate de traducerea greșită a conținutului sau de utilizarea acestuia de către clienți. Găsiți mai multe informații despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 918992
INTRODUCERE
Acest articol descrie modul de a transfera datele de conectare si parolele între instanţe de Microsoft SQL Server 2005, Microsoft SQL Server 2008 şi Microsoft SQL Server 2012 pe diferite fermă de servere.

Pentru mai multe informaţii despre cum de a transfera datele de conectare si parolele între instanţe de alte versiuni de SQL Server, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
246133 Cum de a transfera datele de conectare si parolele între instanţe ale SQL Server
Informaţii suplimentare
În acest articol, serverul A şi server B sunt fermă de servere diferite. În plus, atât serverul A şi server B se execută SQL Server 2005.

Notă Aceste informații se aplică, de asemenea, SQL Server 2008 şi SQL Server 2012.

După ce mutaţi o bază acoperire de date la instanţă de SQL Server pe serverul A la instanţă de SQL Server pe server B, utilizatorii pot fi în măsură să vă conectaţi la baza acoperire de date pe server B. în plus, utilizatorii pot primi următorul mesaj de eroare:
Conectare a eşuat pentru utilizator "MyUser'. (Microsoft SQL Server, Error: 18456)
Această problemă apare deoarece aţi nu transfera datele de conectare si parolele la instanţă de SQL Server pe serverul A la instanţă de SQL Server pe server B.

Pentru a transfera datele de conectare, utilizaţi una dintre următoarele metode, în funcţie de situaţia dumneavoastră.

Metoda 1: Loghează-te folosind pre-SQL Server 2000 parola

Pentru a rezolva această problemă, să solicite utilizatorului să vă conectaţi la serverul care execută SQL Server folosind pre-SQL Server 2000 login.

Notă Parola hash-se actualizează automat atunci când utilizatorul se conectează utilizând parola pre-SQL Server 2000.

Metoda 2: Resetare parola în SQL Server

Pentru a rezolva această problemă, reiniţializaţi parola în SQL Server, apoi script de conectare.

Notă Algoritmul de hash parola este utilizat atunci când a reseta parola.

Metoda 3: Creaţi un jurnal care nu are o parola necompletate

Pentru a crea un jurnal care nu are o parola necompletate, urmaţi aceşti paşi:
  1. Serverul A, începe SQL Server Management Studio, şi apoi conectaţi la instanţă de SQL Server la care te-ai mutat baza acoperire de date.
  2. Deschide o cadru fereastră nouă Editor de interogare şi apoi executaţi următorul script.
    USE masterGOIF OBJECT_ID ('sp_hexadecimal') IS NOT NULL  DROP PROCEDURE sp_hexadecimalGOCREATE PROCEDURE sp_hexadecimal    @binvalue varbinary(256),    @hexvalue varchar (514) OUTPUTASDECLARE @charvalue varchar (514)DECLARE @i intDECLARE @length intDECLARE @hexstring char(16)SELECT @charvalue = '0x'SELECT @i = 1SELECT @length = DATALENGTH (@binvalue)SELECT @hexstring = '0123456789ABCDEF'WHILE (@i <= @length)BEGIN  DECLARE @tempint int  DECLARE @firstint int  DECLARE @secondint int  SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))  SELECT @firstint = FLOOR(@tempint/16)  SELECT @secondint = @tempint - (@firstint*16)  SELECT @charvalue = @charvalue +    SUBSTRING(@hexstring, @firstint+1, 1) +    SUBSTRING(@hexstring, @secondint+1, 1)  SELECT @i = @i + 1ENDSELECT @hexvalue = @charvalueGO IF OBJECT_ID ('sp_help_revlogin') IS NOT NULL  DROP PROCEDURE sp_help_revloginGOCREATE PROCEDURE sp_help_revlogin @login_name sysname = NULL ASDECLARE @name sysnameDECLARE @type varchar (1)DECLARE @hasaccess intDECLARE @denylogin intDECLARE @is_disabled intDECLARE @PWD_varbinary  varbinary (256)DECLARE @PWD_string  varchar (514)DECLARE @SID_varbinary varbinary (85)DECLARE @SID_string varchar (514)DECLARE @tmpstr  varchar (1024)DECLARE @is_policy_checked varchar (3)DECLARE @is_expiration_checked varchar (3)DECLARE @defaultdb sysname IF (@login_name IS NULL)  DECLARE login_curs CURSOR FOR      SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM sys.server_principals p LEFT JOIN sys.syslogins l      ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name <> 'sa'ELSE  DECLARE login_curs CURSOR FOR      SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM sys.server_principals p LEFT JOIN sys.syslogins l      ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name = @login_nameOPEN login_cursFETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denyloginIF (@@fetch_status = -1)BEGIN  PRINT 'No login(s) found.'  CLOSE login_curs  DEALLOCATE login_curs  RETURN -1ENDSET @tmpstr = '/* sp_help_revlogin script 'PRINT @tmpstrSET @tmpstr = '** Generated ' + CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'PRINT @tmpstrPRINT ''WHILE (@@fetch_status <> -1)BEGIN  IF (@@fetch_status <> -2)  BEGIN    PRINT ''    SET @tmpstr = '-- Login: ' + @name    PRINT @tmpstr    IF (@type IN ( 'G', 'U'))    BEGIN -- NT authenticated account/group      SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' FROM WINDOWS WITH DEFAULT_DATABASE = [' + @defaultdb + ']'    END    ELSE BEGIN -- SQL Server authentication        -- obtain password and sid            SET @PWD_varbinary = CAST( LOGINPROPERTY( @name, 'PasswordHash' ) AS varbinary (256) )        EXEC sp_hexadecimal @PWD_varbinary, @PWD_string OUT        EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT         -- obtain password policy state        SELECT @is_policy_checked = CASE is_policy_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name        SELECT @is_expiration_checked = CASE is_expiration_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name             SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' WITH PASSWORD = ' + @PWD_string + ' HASHED, SID = ' + @SID_string + ', DEFAULT_DATABASE = [' + @defaultdb + ']'        IF ( @is_policy_checked IS NOT NULL )        BEGIN          SET @tmpstr = @tmpstr + ', CHECK_POLICY = ' + @is_policy_checked        END        IF ( @is_expiration_checked IS NOT NULL )        BEGIN          SET @tmpstr = @tmpstr + ', CHECK_EXPIRATION = ' + @is_expiration_checked        END    END    IF (@denylogin = 1)    BEGIN -- login is denied access      SET @tmpstr = @tmpstr + '; DENY CONNECT SQL TO ' + QUOTENAME( @name )    END    ELSE IF (@hasaccess = 0)    BEGIN -- login exists but does not have access      SET @tmpstr = @tmpstr + '; REVOKE CONNECT SQL TO ' + QUOTENAME( @name )    END    IF (@is_disabled = 1)    BEGIN -- login is disabled      SET @tmpstr = @tmpstr + '; ALTER LOGIN ' + QUOTENAME( @name ) + ' DISABLE'    END    PRINT @tmpstr  END  FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin   ENDCLOSE login_cursDEALLOCATE login_cursRETURN 0GO


    NotăAcest script creează două proceduri stocate în baza acoperire de date master. Procedurile sunt numitesp_hexadecimal şi sp_help_revlogin.
  3. Executaţi următoarea declaraţie:
    EXEC sp_help_revlogin
    Script-ul de ieşire care generează sp_help_revlogin stocate procedură este script-ul de logare. Acest script de conectare creează datele de conectare, care avea identificatorul originale de securitate (SID) şi parola iniţială.
  4. Pe server B, începe SQL Server Management Studio, şi apoi conectaţi la instanţă de SQL Server la care te-ai mutat baza acoperire de date.

    Importante Înainte de a merge la pasul 5, revedeţi informaţiile din secţiunea "Observații".
  5. Deschide o cadru fereastră nouă Editor de interogare şi apoi executaţi scriptul de ieşire care este generat la Pasul 3.

Remarci

Revedeţi următoarele informaţii înainte de a executa scriptul de ieşire pe rând pe server B:
  • Dacă încercaţi să creaţi un nou 2012 de Server SQL login by folosire un pre-SQL Server 2000 login, care este un scenariu, primiţi următoarea eroare:
    MSG 15021, nivel 16, stat 2, linia 1
    Valoare nevalidă dat parametru de parolă. Specificați o valoare validă parametru.
    Notă Primiţi această eroare în SQL Server 2012 din cauza hash parola de 16-octet care este furnizat pentru situaţiile de LOGIN crea şi modifica LOGIN.

    Pentru a rezolva această problemă pe un server care execută SQL Server 2012, a crea o conectare care are o parolă necompletată. Pentru aceasta, executaţi următorul script:
    CREATE LOGIN [Test] WITH PASSWORD = '', SID = 0x90FD605DCEFAE14FAB4D5EB0BBA1AECC, DEFAULT_DATABASE = [master], CHECK_POLICY = ON, CHECK_EXPIRATION = OFF

    După ce creaţi login care are o parolă necompletată, utilizatorul poate modifica parola la următoarea încercare de conectare.
  • O parolă poate fi hashed în trei moduri:
    • VERSION_LEGACY: această haşiş este un hash de 16 octeţi pre-SQL Server 2000.
    • VERSION_SHA1: acest hash este generat folosind algoritmul SHA1 şi este utilizat în SQL Server 2000 prin SQL Server 2008 R2.
    • VERSION_SHA2: acest hash este generat folosind algoritmul SHA2 512 şi este utilizat în SQL Server 2012.
  • În SQL Server 2008 R1 şi în versiunile anterioare, pre-SQL Server 2000 parola hash-uri au fost susţinute. Atunci când un utilizator logat utilizând o parolă care utilizează un pre-SQL Server 2000 hash hash a fost actualizat pentru a folosi SHA1 hash parola.
  • În cazul în care un utilizator care are o parolă care utilizează pre-SQL Server 2000 hash există pe un server care execută SQL Server 2008 R2, acest lucru înseamnă că utilizatorul nu a autentificat la acel server.
  • Revizuire script-ul de ieşire cu atenţie. În cazul în care serverul A şi server B sunt în diferite domenii, trebuie să modificaţi script-ul de ieşire. Apoi, trebuie să înlocuiţi nume de sign-in de domeniu originale folosind nume de sign-in de domeniu nou în declaraţiile de creare LOGIN. Login-uri integrate, care se acordă accesul în noul domeniu nu au acelaşi SID ca datele de conectare în domeniul originale. Prin urmare, utilizatorii sunt orfani din aceste conectări. Pentru mai multe informaţii despre modul de rezolvare a acestor utilizatori orfani, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
    240872 Cum de a rezolva probleme de permisiune atunci când vă mutaţi o bază acoperire de date între fermă de servere care execută SQL Server
    În cazul în care serverul A şi server B sunt în acelaşi domeniu, SID acelaşi este utilizat. Prin urmare, utilizatorii sunt puţin probabil să fi solitari.
  • În script-ul de ieşire, login-uri sunt create utilizând parola criptată. Aceasta este argumentul HASHED în declaraţia de creare LOGIN. Acest argument specifică că parola este introdus după argumentul parola este deja hashed.
  • implicit, numai un membru al rolului sysadmin fixe serverul pot rula o instrucţiune SELECT din vedere sys.server_principals . Excepţia cazului în care un membru de sysadmin stabilit rol de server acordă permisiuni necesare pentru utilizatori, utilizatorii pot crea sau rula script-ul de ieşire.
  • Paşii din acest articol nu transfera informaţii de bază acoperire de date implicit pentru o conectare special. Acest lucru este pentru că baza acoperire de date implicit nu poate exista mereu pe server B. Pentru a defini bazei acoperire de date implicit pentru un login, utilizează instrucţiunea ALTER LOGIN prin trecerea în nume de sign-in şi implicit baza acoperire de date ca argumente.
  • Serverul case-insensitive A şi sensibil la server B: ordinea de sortare a serverul A poate fi case-insensitive, şi ordinea de sortare de server B poate fi sensibil la. În acest caz, utilizatorii trebuie să tastaţi parolele din toate literele mari după ce transferaţi datele de conectare si parolele la instanţă pe server B.

    Sensibil la serverul A şi case-insensitive server B: ordinea de sortare a serverul A poate fi sensibil la, şi ordinea de sortare de server B poate fi case-insensitive. În acest caz, utilizatorii pot autentifica utilizând datele de conectare si parolele pe care le transfera la instanţă pe server B decât dacă este adevărată una dintre următoarele condiții:
    • Parolele originale conţin litere nr.
    • Toate literele în parole originale sunt litere mari.
    Minuscule sau case-insensitive pe ambele fermă de servere: ordinea de sortare atât serverul A şi serverul B poate fi sensibil la, sau ordinea de sortare atât serverul A şi serverul B poate fi case-insensitive. În aceste cazuri, utilizatorii nu experienţă o problemă.
  • Nume de utilizator care este deja în instanţă pe server B poate avea un nume care este la fel ca un nume în script-ul de ieşire. În acest caz, veţi primi următorul mesaj de eroare când executaţi scriptul de ieşire pe rând pe server B:
    MSG 15025, nivel 16, stat 1, linia 1
    Serverul principal "MyLogin"există deja.
    În mod similar, un nume de utilizator care este deja în instanţă pe server B poate avea un SID care este la fel ca un SID în script-ul de ieşire. În acest caz, veţi primi următorul mesaj de eroare când executaţi scriptul de ieşire pe rând pe server B:
    MSG 15433, nivel 16, stat 1, linia 1
    Parametru furnizate sid este în uz.
    Prin urmare, trebuie să faceţi următoarele:
    1. Revizuire script-ul de ieşire cu atenţie.
    2. Examinaţi conţinutul Vezi sys.server_principals în instanţă pe server B.
    3. Adresa aceste mesaje de eroare, după caz.
  • În SQL Server 2005, SID pentru o conectare este folosit pentru a pune în aplicare de nivel de bază acoperire de date acces. O conectare pot avea diferite SIDs în diferite baze acoperire de date pe un server. În acest caz, login numai puteţi accesa baza acoperire de date a SID care corespunde SID în vederea sys.server_principals . Această problemă poate apărea dacă două baze acoperire de date sunt combinate la diferite fermă de servere. Pentru a rezolva această problemă, eliminaţi manual conectare la baza acoperire de date care are o nepotrivire de SID utilizând instrucţiunea DROP USER. Apoi, adăugaţi din nou Conectare utilizând instrucţiunea de a crea USER.
Referinţe
Pentru mai multe informaţii despre cum se depanează utilizatorii de orfani, du-te la Depanarea orfani utilizatori Site-ul Reţea Microsoft pentru dezvoltatori (MSDN).

Pentru mai multe informaţii despre instrucţiunea crea LOGIN, du-te la Creare LOGIN (Transact-SQL) Site-ul MSDN.

Pentru mai multe informaţii despre instrucţiunea ALTER LOGIN, du-te la ALTER LOGIN (Transact-SQL) Site-ul MSDN.

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 918992 - Ultima examinare: 08/03/2013 08:29:00 - Revizie: 2.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Workgroup, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise

  • kbsqlsetup kbexpertiseadvanced kbhowto kbinfo kbmt KB918992 KbMtro
Feedback