Uwierzytelnianie SQL Server

Uwierzytelnianie SQL Server dopuszcza logowanie kontem Windows, kontem serwera lub oboma w trybie mieszanym.

Dwa sposoby logowania do instancji SQL Server

Uwierzytelnianie SQL Server określa, w jaki sposób silnik Microsoft SQL Server potwierdza tożsamość osoby lub aplikacji próbującej nawiązać połączenie. W trybie uwierzytelniania Windows SQL Server korzysta z poświadczeń konta Windows. Użytkownik loguje się przy użyciu konta lokalnego albo domenowego, a serwer sprawdza jego tożsamość za pośrednictwem mechanizmów systemu Windows. W środowisku domenowym może być używane uwierzytelnianie Kerberos, natomiast w określonych sytuacjach system może zastosować NTLM.

Drugim mechanizmem jest SQL Server Authentication. W tym przypadku poświadczenia są zapisane w SQL Server jako login serwera, na przykład login utworzony poleceniem CREATE LOGIN. Użytkownik podaje nazwę loginu i hasło niezależnie od tego, czy posiada konto Windows. Trzecią możliwością jest tryb mieszany, w którym ta sama instancja akceptuje zarówno loginy Windows, jak i loginy SQL Server. Tryb mieszany nie oznacza połączenia dwóch kont w jeden profil; są to odrębne mechanizmy identyfikacji i odrębne obiekty bezpieczeństwa.

Tryb mieszany i konfiguracja instancji

Tryb uwierzytelniania jest właściwością instancji SQL Server, a nie pojedynczej bazy danych. W SQL Server Management Studio można go zmienić we właściwościach serwera, w sekcji Security, wybierając opcję Windows Authentication mode albo SQL Server and Windows Authentication mode. Po zmianie ustawienia usługa SQL Server musi zostać ponownie uruchomiona, aby nowy tryb zaczął obowiązywać. Sama zmiana trybu nie nadaje użytkownikom uprawnień do baz danych i nie tworzy automatycznie dodatkowych loginów.

Login Windows może być pojedynczym kontem lub grupą Windows. Po utworzeniu albo dodaniu loginu do instancji administrator mapuje go w konkretnej bazie danych na użytkownika bazy, a następnie przypisuje role lub uprawnienia. Login SQL Server jest przechowywany w katalogu systemowym instancji i ma własne hasło. Wbudowany login sa jest przykładem loginu SQL Server, ale jego dostępność zależy od konfiguracji i stanu konta. W nowej instalacji korzystającej wyłącznie z Windows Authentication login sa nie służy do logowania metodą SQL Server Authentication.

Loginy, użytkownicy baz i uprawnienia

W SQL Server login reprezentuje tożsamość na poziomie instancji, natomiast użytkownik jest obiektem istniejącym w konkretnej bazie danych. Po pomyślnym uwierzytelnieniu serwer sprawdza, czy login ma dostęp do wskazanej bazy oraz jakie operacje może w niej wykonywać. Login może mieć użytkownika w jednej bazie, w wielu bazach albo w żadnej. Dlatego poprawne hasło nie gwarantuje dostępu do tabel, widoków, procedur składowanych ani innych obiektów.

Przy konfiguracji loginu SQL Server można włączyć kontrolę zgodności hasła z zasadami systemu Windows za pomocą opcji CHECK_POLICY, a także kontrolę okresu ważności hasła przez CHECK_EXPIRATION. Przykładowo login tworzy się poleceniem CREATE LOGIN nazwa WITH PASSWORD = 'hasło', a użytkownika w bazie poleceniem CREATE USER nazwa FOR LOGIN nazwa. W praktycznym wdrożeniu należy stosować osobne loginy dla aplikacji i administratorów, ograniczać uprawnienia do wymaganego zakresu oraz unikać używania konta sa przez aplikacje. Uwierzytelnianie nie zastępuje szyfrowania połączenia: ochronę transmisji należy skonfigurować osobno, z użyciem ustawień szyfrowania i certyfikatu serwera.

Objawy błędnej konfiguracji uwierzytelniania

Błąd logowania może wynikać z wyboru niewłaściwego typu uwierzytelniania w kliencie, wyłączonego trybu SQL Server Authentication, nieaktywnego loginu, błędnego hasła, braku uprawnień do wskazanej bazy albo nieprawidłowej nazwy instancji. Komunikat SQL Server o numerze 18456 oznacza odrzucone logowanie, ale szczegółowy powód wymaga sprawdzenia dziennika błędów SQL Server oraz odpowiedniego stanu błędu. Przy logowaniu Windows należy dodatkowo sprawdzić członkostwo konta lub grupy, dostęp do instancji oraz konfigurację domeny i SPN, jeżeli wymagane jest Kerberos.

Diagnostyka powinna rozpocząć się od ustalenia, czy klient używa Windows Authentication, czy SQL Server Authentication, oraz do której instancji kieruje połączenie. Następnie w SQL Server Management Studio można sprawdzić tryb uwierzytelniania, stan loginu, mapowanie użytkownika w bazie i przypisane role. W przypadku aplikacji trzeba zweryfikować źródło connection stringa, nazwę serwera, nazwę bazy i sposób przechowywania poświadczeń, bez ujawniania haseł w logach. Przy naprawie problemu należy zmienić tylko właściwy element konfiguracji, ponieważ włączenie trybu mieszanego nie naprawi braku uprawnień, a nadanie szerokich uprawnień nie rozwiąże błędnego hasła lub nieosiągalnej instancji.