Cum se rezolvă problemele de permisiune atunci când mutați o bază de date între serverele care execută SQL Server

Se aplică la: Microsoft SQL Server 2005 Developer EditionMicrosoft SQL Server 2005 Enterprise EditionMicrosoft SQL Server 2005 Express Edition

Rezumat


Acest articol descrie modul de conectare standard și integrate pe hartă pentru a rezolva probleme de permisiune atunci când mutați o bază de date între serverele care execută SQL Server.

Mai multe informații


Atunci când mutați o bază de date de pe un server care execută SQL Server la un alt server care execută SQL Server, se poate produce o nepotrivire între numerele de identificare de securitate (SID) de conectare în baza de date master și utilizatorii utilizator bază de date. În mod implicit, SQL Server 7.0, SQL Server 2000 și SQL Server 2005 oferă procedura de sistem stocată sp_change_users_login pentru a mapa acești utilizatori nepotrivite. Cu toate acestea, puteți utiliza numai procedura sp_change_users_login stocate pentru maparea conectare standard de SQL Server și trebuie să efectuați aceste mapare pentru un utilizator la un moment. Pentru mai multe informații despre procedura sp_change_users_login stocate, consultați subiectul "sp_change_users_login" în SQL Server 7.0, SQL Server 2000 și manualele Online SQL Server 2005.

În SQL Server 7.0 sau versiuni mai recente, puteţi menţine maparea între conectare în baza de date master și utilizatorii în baza de date de utilizator utilizând Sid-urilor. Această mapare este necesară pentru a menține permisiunile corecte pentru conectare în bazele de date de utilizator . Atunci când această maparea este pierdut, conectare aveți permisiunea de probleme care includ, dar nu sunt limitate la următoarele:
  • Dacă log in SQL Server nu există pe serverul nou și utilizatorul încearcă să faceți log on, este posibil să primiți următorul mesaj de eroare:
    Server: Msg 18456, Level 16, starea 1
    Login nereușit pentru utilizator '%ls'.
  • Dacă SQL Server login există pe serverul nou, dar SID-ul în baza de date master diferă de SID-ul în baza de date de utilizator , utilizatorul poate face log on la SQL Server cu succes; cu toate acestea, atunci când utilizatorul încearcă să acceseze date, utilizatorul poate să primiți următorul mesaj de eroare:
    Server: Msg 916, nivel 14, starea 1, Line1
    Server de utilizator ' %. * ls' nu este un utilizator valid în baza de date ' %. * ls'.
    Notă În SQL Server 2005, este posibil să primiți următorul mesaj de eroare:

    Server de utilizator '%s' nu este un utilizator valid în baza de date '%s'. Adăugați contul de utilizator în baza de date mai întâi.
Pentru mai multe informații despre modelul de securitate SQL Server 7.0, consultați documentația "Microsoft SQL Server 7.0 securitate". Pentru a vizualiza documentația, vizitați următorul site Web Microsoft:Pentru mai multe informații despre modelul de securitate SQL Server 2000, faceți clic pe următorul număr de articol pentru a vedea articolul în baza de cunoștințe Microsoft:

Caracteristici de securitate Microsoft SQL Server 2000 S322712 322712 și cele mai bune practici

Restricții

  • Dacă există utilizatori în tabelul sysusers fără un prefix numele computerului sau numele de domeniu care dețin obiecte și aceste obiecte se face referire în aplicațiile utilizând numele de două părți
    numele de utilizator. objectname, aplicația poate întrerupe, deoarece procedura sp_sidmap stocate redenumește acești utilizatori cu prefixul de nume de computer sau nume de domeniu, așa cum apare în tabelul sysxlogins . Pentru a rezolva această problemă, după sp_sidmap procedură stocată s-a terminat, redenumiți utilizatorii care au fost afectate în tabelul sysusers a fost numele lor sau contactați furnizorul de suport principal.
  • Acest articol nu ia în considerare aliasuri. Trebuie să gestionați aliasuri manual.
  • Dacă nu există o conectare standard de SQL Server pe noul server SQL Server, aveți posibilitatea să adăugați conectare cu o parolă NULL. Trebuie să modificați parola pentru aceste conectări în mod corespunzător.
  • Dacă un utilizator a fost creat în baza de date de utilizator cu un nume care diferă de cea care apare în tabelul sysxlogins , este imposibil să știți login corespunzătoare pentru acel utilizator. De aceea, înainte să executați sp_sidmap procedura stocată:
    1. Transfer toate obiectele care deține acest utilizator la o bază de date de așteptare.
    2. Fixați utilizatorului, adăugați utilizatorul care are numele corect, și apoi transferă înapoi toate obiectele pentru acest utilizator.
  • Dacă un utilizator nu are nici o conectare corespunzătoare nici un prefix numele computerului local sau numele de domeniu, primiți un mesaj pentru acest utilizator. Acest mesaj indică faptul că trebuie să adăugați mai întâi utilizator la nivel de Windows și adăugați-l la SQL Server ca nume de utilizator. După aceasta, trebuie să executați din nou procedura sp_sidmap stocate.
  • Dacă un utilizator are un prefix numele domeniului sau numele de server local Windows, dar login corespunzătoare nu există în tabelul sysxlogins , procedura stocată încearcă să adăugaţi acest ca o nouă de conectare la SQL Server. Dacă utilizatorul Windows nu există, se generează un mesaj de ieșire în fereastra rezultate și apoi manual creează login după aceasta adaugă mai întâi utilizator de Windows.
  • Dacă există mai multe login pentru un utilizator în tabelul sysusers , vedeți un mesaj de ieșire în fișierul rezultatele și se listează toate datele de conectare, care au același nume de utilizator. În acest moment, trebuie să interveni manual pentru a vă asigura că utilizatorul corespunde numai o singură autentificare.

    Exemplu Dacă tabelul sysusers are un utilizator numit "johndoe" și tabelul sysxlogins are conectări cu nume, cum ar fi "Test\johndoe" și "Test2\johndoe", atunci când executați procedura stocată, primiți un mesaj care afirmă că unul dintre utilizatorii are mai multe autentificare și că administratorul de sistem trebuie să alegeți unul. Aceasta este singura dată care trebuie să executați a doua procedură stocată, sp_prefix_sysusersname, care este furnizat în acest articol. În plus, această situație este descrisă în detaliu în fișierul Readme.txt.

Hartă de conectare standard și integrate

După ce mutați o bază de date de pe un server care execută SQL Server server pe alt server care execută SQL Server server, urmați acești pași pentru intervenția utilizatorului minim:

SQL Server 7.0 și SQL Server 2000

  1. Asigurați-vă că există o înregistrare în tabelul sysxlogins în baza de date master pentru fiecare utilizator în tabelul sysusers bazei de date.

    Notă Pentru a adăuga o conectare standard de SQL Server, consultați subiectul "sp_addlogin" în SQL Server Books Online. Pentru a adăuga o autentificare integrată SQL Server, consultați subiectul "sp_grantlogin" în SQL Server Books Online.
  2. Descărcați fișierul MapSids.exe și apoi să extrageți fișierele Sp_sidmap.sql și Readme.txt.
  3. Faceți Log on la serverul care execută SQL Server ca administrator de sistem și executați fișierul Sp_sidmap.sql în baza de date de utilizator. Execută fișierul Sp_sidmap.sql creează două proceduri stocate, sp_sidmap și sp_prefix_sysusersname.
  4. Asigurați-vă că baza de date nu este accesată de orice alt utilizator decât cel pe care se execută proceduri stocate.
  5. Asigurați-vă că Query Analyzer afișează rezultatele în text format și nu în format grilă. Pentru aceasta, apăsați fie
    CTRL ^ T chei, sau interogare, și apoi faceți clic pe rezultate în Text. Acest lucru este foarte important, astfel încât să puteți vedea rezultatele și mesaje informativ într-o fereastră și Salvați datele de ieșire într-un fișier text. Este posibil să trebuiască acest fişier mai târziu pentru a rezolva unele dintre mapările.
  6. Deoarece nu este posibilă verificarea dacă parametrii sunt transmise corect, asigurați-vă că le trece corect procedura sp_sidmap stocate:
    EXEC sp_SidMap @old_domain = old_domain_name,
    @new_domain = new_domain_name,
    @old_server = old_server_name,
    @new_server = new_server_name
    Înlocuiți valorile pentru numele de domeniu vechiul și noul și numele de server în mod corespunzător.
  7. Salvați rezultatele într-un fișier și urmați instrucțiunile furnizate în fișierul Readme.txt.

    Notă Când executați aceste proceduri stocate, tabelul sysusers este singurul tabel care modifică în baza de date. Pentru a reveni la o stare de unde ați pornit, restaurarea bazei de date din copia de rezervă sau reatașați baza de date.

SQL Server 2005

Dacă se execută SQL Server 2005, utilizați clauza Cu conectare a instrucțiunea ALTER utilizator pentru remaparea unui utilizator la un nou login. Pentru mai multe informații, vizitați următorul site Web Microsoft Developer Network (MSDN):Notă Pentru a utiliza clauza Cu conectare a instrucțiunea ALTER utilizator , trebuie să aplicați SQL Server 2005 Service Pack 2.

Referințe


Pentru mai multe informații, faceți clic pe următoarele numere de articol pentru a vedea articolele în baza de cunoștințe Microsoft:

274188 subiectul "Troubleshooting orphaned users" în manualele Online este incomplet

246133 cum se transferă datele de conectare și parolele între instanțe de SQL Server

168001 utilizator Log on sau permisiunea erori după restaurarea imagine

EXEMPLU de 298897 : Mapsids.exe ajută la hartă Sid-uri între utilizator și bazele de date Master atunci când baza de date este mutat