Tworzenie logowania

Tworzenie logowania poleceniem CREATE LOGIN dodaje nowe konto uprawnione do połączenia z instancją.

Znaczenie logowania na poziomie instancji SQL Server

W Microsoft SQL Server login jest obiektem zapisanym na poziomie instancji. Określa tożsamość, która może przejść etap uwierzytelnienia podczas nawiązywania połączenia z silnikiem bazy danych. Sam login nie oznacza jeszcze dostępu do konkretnych tabel, widoków ani procedur. Po pomyślnym uwierzytelnieniu SQL Server ustala, jakie operacje są dozwolone, korzystając z członkostwa w rolach serwerowych, uprawnień nadanych bezpośrednio oraz powiązania z użytkownikiem w wybranej bazie danych.

Instrukcja CREATE LOGIN służy do utworzenia takiej tożsamości. W zależności od wariantu składni login może korzystać z konta systemu Windows albo z uwierzytelniania SQL Server, w którym nazwa i hasło są obsługiwane przez silnik bazy. W pierwszym przypadku SQL Server ufa tożsamości dostarczonej przez system Windows lub domenę. W drugim sprawdza dane zapisane w swojej konfiguracji. Dostępność obu metod zależy od trybu uwierzytelniania ustawionego dla instancji.

Login jest wspólny dla całej instancji, natomiast użytkownik bazy danych jest obiektem przypisanym do jednej konkretnej bazy. Aby konto mogło wykonywać operacje w bazie, zwykle trzeba utworzyć lub wskazać odpowiadającego mu użytkownika, a następnie nadać uprawnienia. Rozdzielenie tych poziomów pozwala oddzielić prawo do połączenia z instancją od prawa do korzystania z danych.

Składnia, typy kont i zakres uprawnień

Przy tworzeniu loginu Windows używa się nazwy konta lub grupy w formacie rozpoznawanym przez system, natomiast dla loginu SQL Server podaje się nazwę oraz hasło. Opcjonalne elementy mogą określać między innymi bazę domyślną, język sesji, identyfikator SID albo zasady sprawdzania hasła. Baza domyślna wpływa na miejsce, do którego użytkownik trafia po zalogowaniu, lecz nie zastępuje uprawnień w tej bazie. Jeżeli wskazana baza jest niedostępna, uszkodzona albo użytkownik nie może z niej korzystać, połączenie może wymagać jawnego wskazania innej bazy.

Dla loginów SQL Server istotne są opcje CHECK_POLICY i CHECK_EXPIRATION. Pozwalają one powiązać kontrolę hasła z zasadami systemu Windows oraz określić, czy hasło może wygasać. Ich użycie powinno wynikać z przyjętej polityki bezpieczeństwa, ponieważ wyłączenie kontroli upraszcza działanie, ale zwiększa ryzyko używania słabych lub długo niezmienianych haseł. Hasło nie powinno być wpisywane do skryptów przechowywanych w repozytorium ani przekazywane w jawnych plikach konfiguracyjnych.

Po utworzeniu login może zostać dodany do roli serwerowej, na przykład do roli umożliwiającej zarządzanie określonym zakresem obiektów instancji. Uprawnienia administracyjne należy przyznawać możliwie wąsko, ponieważ członkostwo w roli sysadmin daje pełną kontrolę nad instancją i bazami. W samej bazie użytkownika można przypisać do ról bazodanowych albo nadać mu uprawnienia do wybranych schematów, obiektów i operacji. Bez tego login może uwierzytelnić się poprawnie, ale nadal otrzymać odmowę przy próbie odczytu lub zmiany danych.

CREATE LOGIN różni się od CREATE USER. Pierwsza instrukcja tworzy tożsamość rozpoznawaną przez instancję, druga tworzy reprezentację tej tożsamości w konkretnej bazie. W środowiskach korzystających z użytkowników zawartych w bazie model może wyglądać inaczej, dlatego przed zmianą konfiguracji trzeba ustalić, czy aplikacja używa klasycznych loginów instancji, czy mechanizmu zawartego w bazie.

Odmowy dostępu, niespójne konta i diagnostyka

Jednym z częstych problemów jest pomylenie poprawnego uwierzytelnienia z autoryzacją. Komunikat o udanym rozpoznaniu loginu nie oznacza, że konto ma prawo wykonać zapytanie. Odmowa może wynikać z braku użytkownika w bazie, braku członkostwa w odpowiedniej roli, uprawnienia nadanego na innym poziomie albo połączenia z inną bazą niż zakładano.

W przypadku loginu Windows przyczyną może być użycie niewłaściwego konta, brak członkostwa w grupie, zmiana nazwy domenowej albo działanie aplikacji pod inną tożsamością niż użytkownik interaktywny. Przy loginie SQL Server należy sprawdzić, czy instancja dopuszcza ten tryb uwierzytelniania, czy login jest włączony oraz czy hasło spełnia wymagania ustawione dla konta. Samo ponowne uruchomienie aplikacji nie naprawi błędnej konfiguracji uprawnień.

Warto także odróżnić brak loginu od problemu z połączeniem. Błąd dotyczący nazwy instancji, portu, protokołu, zapory albo niedostępności procesu SQL Server pojawia się przed sprawdzeniem danych uwierzytelniających. Z kolei błąd hasła, wyłączonego konta lub braku dostępu do bazy dotyczy już dalszego etapu. Analiza komunikatu, parametrów połączenia i dzienników SQL Server pomaga ustalić, w którym miejscu przepływ został przerwany.

Po odtworzeniu bazy na innej instancji mogą wystąpić tak zwani użytkownicy osieroceni. Użytkownik nadal istnieje w bazie, lecz nie jest prawidłowo powiązany z loginem obecnym na nowej instancji. W takiej sytuacji utworzenie kolejnego konta o podobnej nazwie nie zawsze rozwiązuje problem, ponieważ znaczenie ma zgodność identyfikatora SID oraz właściwe przypisanie użytkownika. Zmiany należy wykonywać po wykonaniu kopii zapasowej i po ustaleniu, które konto powinno zachować dostęp.

Gdy problem z bazą towarzyszy awarii komputera

Jeżeli błąd logowania pojawił się po awarii laptopa lub komputera stacjonarnego, najpierw trzeba ustalić, czy przyczyną jest konfiguracja SQL Server, czy stan urządzenia. Uszkodzony dysk może powodować utratę plików baz danych, niestabilne działanie systemu, błędy odczytu oraz przerwane uruchamianie usług. Problemy z pamięcią, zasilaniem, płytą główną albo przegrzewaniem również mogą sprawiać wrażenie losowych błędów aplikacji.

Warszawskie Pogotowie Komputerowe wykonuje usługi serwisu laptopów, komputerów stacjonarnych i ich podzespołów. W przypadku uszkodzonych nośników możliwy jest także podstawowy odzysk danych. Przed naprawą dysku warto ograniczyć uruchamianie systemu i zapisywanie nowych plików, ponieważ dalsza praca może pogorszyć stan nośnika oraz utrudnić zachowanie danych.

Do serwisu sprzętowego warto zgłosić komputer, gdy logowaniu towarzyszą zawieszanie systemu, samoczynne restarty, znikanie dysku, nietypowe odgłosy nośnika, problemy z uruchamianiem lub nagłe wyłączanie urządzenia. Jeżeli sprzęt działa prawidłowo, a SQL Server zwraca wyłącznie odmowę dostępu, przyczyny należy szukać w loginie, użytkowniku bazy, rolach, trybie uwierzytelniania albo parametrach połączenia. W takim przypadku przygotowanie dokładnego komunikatu błędu, wersji SQL Server i informacji o momencie wystąpienia problemu ułatwia dalszą konsultację z administratorem środowiska.