Przenoszenie logowań

Przenoszenie logowań między instancjami wymaga zsynchronizowania SID, inaczej mapowanie do baz zawiedzie.

Co dokładnie jest przenoszone razem z loginem

W SQL Server login jest obiektem na poziomie instancji, a użytkownik bazy danych jest obiektem należącym do konkretnej bazy. Login służy do uwierzytelnienia na serwerze i może otrzymać dostęp do jednej lub wielu baz. Użytkownik bazy jest natomiast powiązany z loginem za pomocą identyfikatora bezpieczeństwa SID. Sama zgodność nazwy, na przykład serwis po obu stronach, nie gwarantuje poprawnego powiązania. Jeżeli login na instancji docelowej ma inny SID niż login, dla którego wcześniej utworzono użytkownika w bazie, SQL Server może traktować tego użytkownika jako osieroconego.

Przy przenoszeniu bazy między instancjami należy więc rozdzielić trzy elementy: definicję loginu, jego SID oraz uprawnienia przypisane bezpośrednio do loginu lub odziedziczone przez role serwerowe. Kopia samej bazy obejmuje użytkowników, role bazodanowe i uprawnienia wewnątrz bazy, ale nie obejmuje loginów instancji. Z tego powodu po odtworzeniu kopii zapasowej na innym serwerze użytkownik zapisany w bazie może istnieć, lecz nie mieć prawidłowego powiązania z loginem używanym do logowania.

SID loginu a użytkownik zapisany w bazie

SID loginu można sprawdzić w widoku katalogowym sys.server_principals, a SID użytkownika bazy w sys.database_principals. Dla loginu SQL Server wartości te powinny odpowiadać sobie po stronie instancji i bazy. W praktyce warto porównać co najmniej nazwę podmiotu, typ, SID oraz członkostwo w rolach. Samo polecenie sp_change_users_login jest procedurą starszego typu i dotyczy użytkowników mapowanych do loginów SQL; w nowszych procedurach naprawczych stosuje się zwykle ALTER USER ... WITH LOGIN = ....

Jeżeli login już istnieje na instancji docelowej, a użytkownik bazy wskazuje na inny SID, można ponownie powiązać użytkownika z właściwym loginem poleceniem w rodzaju ALTER USER [nazwa_użytkownika] WITH LOGIN = [nazwa_loginu], wykonanym w kontekście odpowiedniej bazy. Operacja zmienia mapowanie użytkownika, ale nie powinna być traktowana jako automatyczne nadanie wszystkich praw. Uprawnienia użytkownika wynikające z członkostwa w rolach bazodanowych pozostają elementem bazy, natomiast uprawnienia serwerowe i członkostwo w rolach serwerowych trzeba odtworzyć osobno.

Bezpieczna kolejność migracji między instancjami SQL Server

Najpierw należy zinwentaryzować loginy na instancji źródłowej: loginy SQL, loginy Windows, grupy Windows, role serwerowe, uprawnienia nadane bezpośrednio oraz ustawienia takie jak status włączenia i domyślna baza. Następnie trzeba przygotować odpowiedniki na instancji docelowej przed udostępnieniem użytkownikom odtworzonej bazy. Dla loginu SQL istotne jest zachowanie tego samego SID. Przy tworzeniu loginu można podać wartość SID w instrukcji CREATE LOGIN, używając składni przeznaczonej dla loginów SQL. Hasło powinno być przenoszone wyłącznie za pomocą kontrolowanej procedury administracyjnej obsługującej właściwy format hasha, a nie przez odczytywanie lub zapisywanie go w zwykłym tekście.

Loginy Windows wymagają odrębnego podejścia, ponieważ ich SID jest związany z kontem lub grupą w domenie albo na komputerze. Utworzenie konta o identycznej nazwie nie musi oznaczać identycznego SID. Dlatego podczas migracji należy używać tego samego konta domenowego lub tej samej grupy, a następnie zweryfikować rozpoznany SID na instancji docelowej. Po odtworzeniu bazy trzeba sprawdzić użytkowników osieroconych, mapowanie loginów, role bazodanowe, uprawnienia do obiektów oraz działanie aplikacji korzystających z logowania SQL lub Windows.

Ważne jest także uwzględnienie loginów używanych przez zadania SQL Server Agent, połączenia aplikacyjne, replikację, narzędzia administracyjne i procedury korzystające z poświadczeń. Przeniesienie wyłącznie loginu interaktywnego może nie wystarczyć, jeżeli aplikacja używa innego konta technicznego. Po zmianie instancji należy przetestować logowanie, wybór domyślnej bazy, wykonywanie wymaganych zapytań oraz odwołania do nazw serwerów zapisane w konfiguracji aplikacji.

Weryfikacja mapowania po odtworzeniu bazy

Kontrolę należy wykonać na instancji docelowej po przywróceniu bazy i utworzeniu loginów. Trzeba sprawdzić, czy każdy wymagany login istnieje, jest włączony, ma właściwą domyślną bazę i odpowiada użytkownikowi o właściwym SID. Następnie należy zweryfikować członkostwo w rolach, uprawnienia nadane do schematów i obiektów oraz ewentualne odmowy uprawnień, ponieważ jawne DENY może zmienić wynik autoryzacji mimo obecności użytkownika w odpowiedniej roli.

Typowym objawem błędnego mapowania jest możliwość zalogowania się do instancji przy jednoczesnym braku dostępu do przeniesionej bazy albo komunikat wskazujący, że użytkownik nie może zostać zalogowany. Inny przypadek to pozornie poprawne logowanie, lecz odmowa wykonania konkretnej operacji z powodu brakującego członkostwa w roli lub pominiętego uprawnienia serwerowego. Sama zmiana nazwy loginu nie rozwiązuje problemu SID; trzeba sprawdzić rzeczywiste powiązanie katalogowe i dopiero potem wykonać remap użytkownika albo odtworzyć login z właściwym identyfikatorem.

Przy diagnostyce warto zachować listę loginów źródłowych, odpowiadających im użytkowników bazodanowych, SID-ów, ról oraz wyników prób logowania. Taki protokół pozwala odróżnić błąd uwierzytelniania od błędu autoryzacji i ogranicza ryzyko przypadkowego nadania zbyt szerokich praw. Po zakończeniu migracji należy ponownie sprawdzić połączenia aplikacyjne oraz logowania użytkowników, ponieważ poprawne utworzenie obiektów w katalogu SQL Server nie potwierdza jeszcze poprawności całego przepływu dostępu.