Tryb uwierzytelniania (Windows/SQL)

Tryb uwierzytelniania decyduje, czy SQL Server akceptuje wyłącznie konta Windows, czy także własne konta serwera.

Dwa modele uwierzytelniania w SQL Server

Tryb uwierzytelniania w SQL Server określa, jakie tożsamości mogą zostać użyte podczas logowania do instancji silnika. W trybie Windows Authentication SQL Server akceptuje poświadczenia kont oraz grup z systemu Windows. Weryfikacja tożsamości odbywa się wtedy z wykorzystaniem mechanizmów systemowych, a uprawnienia do instancji i baz danych są zwykle nadawane kontom lub grupom domenowym. Użytkownik nie przekazuje SQL Serverowi osobnego hasła przechowywanego przez silnik, ponieważ uwierzytelnienie jest powiązane z zalogowaną sesją Windows.

Drugi wariant to Mixed Mode, czyli tryb mieszany. Pozwala on korzystać jednocześnie z kont Windows oraz z loginów SQL Server. Login SQL Server jest niezależną tożsamością z nazwą użytkownika i hasłem przechowywanymi przez silnik. W tym trybie może działać między innymi wbudowany login sa, o ile został włączony. Samo ustawienie trybu mieszanego nie nadaje loginowi żadnych praw do baz danych; określa jedynie, że taki rodzaj logowania jest dopuszczalny.

Login, użytkownik bazy i nadawanie uprawnień

W SQL Server trzeba odróżnić login od użytkownika bazy danych. Login jest definiowany na poziomie instancji i służy do uwierzytelnienia połączenia z serwerem. Użytkownik bazy danych jest obiektem konkretnej bazy i określa, z jakimi uprawnieniami login może korzystać z jej danych oraz obiektów. Po poprawnym zalogowaniu SQL Server musi więc jeszcze ustalić, do jakiej bazy użytkownik ma dostęp i jakie operacje może wykonywać.

W przypadku kont Windows login może reprezentować pojedyncze konto albo grupę systemową. Nadanie uprawnień grupie pozwala zarządzać dostępem przez członkostwo w grupie, ale skutki zmian zależą od aktualnego stanu kont i zasad obowiązujących w środowisku Windows. Dla loginów SQL Server dostęp jest oparty na nazwie loginu i jego haśle. Login może mieć przypisanego użytkownika w wielu bazach, przy czym w każdej z nich ten użytkownik może należeć do innych ról bazodanowych.

Uwierzytelnianie nie zastępuje autoryzacji. Udane logowanie oznacza tylko, że SQL Server rozpoznał tożsamość. Dopiero mapowanie loginu na użytkownika bazy, członkostwo w rolach oraz jawnie nadane uprawnienia decydują, czy można odczytywać tabele, wykonywać procedury, modyfikować dane albo zmieniać konfigurację. Błąd logowania i błąd braku uprawnień są zatem różnymi problemami, mimo że oba mogą pojawić się podczas próby uruchomienia aplikacji.

Zmiana trybu i typowe objawy niezgodności

Tryb uwierzytelniania jest ustawieniem instancji SQL Server. Można go zmienić w SQL Server Management Studio w właściwościach serwera, w sekcji dotyczącej zabezpieczeń, wybierając Windows Authentication albo SQL Server and Windows Authentication mode. Po zmianie tego ustawienia konieczne jest ponowne uruchomienie usługi SQL Server, aby instancja zaczęła stosować nowy model logowania. Sama zmiana trybu nie tworzy loginów SQL Server, nie ustawia ich haseł i nie naprawia brakujących użytkowników w bazach.

Jeżeli aplikacja próbuje połączyć się przy użyciu loginu SQL Server, a instancja działa wyłącznie w trybie Windows Authentication, logowanie zakończy się błędem niezależnie od tego, czy podane hasło jest prawidłowe. Odwrotna sytuacja także powoduje problemy: aplikacja skonfigurowana do używania konta Windows wymaga dostępnej tożsamości systemowej, właściwego formatu nazwy oraz odpowiednich uprawnień. W praktyce trzeba sprawdzić, czy parametry połączenia wskazują właściwą instancję, jaki typ uwierzytelniania deklaruje aplikacja oraz czy wskazany login istnieje na tym konkretnym serwerze.

Po włączeniu Mixed Mode warto zweryfikować stan każdego używanego loginu SQL Server, jego mapowanie do bazy i możliwość wykonania wymaganych operacji. Należy również uważać na login sa: jeśli jest niepotrzebny, powinien pozostać wyłączony, ponieważ jest powszechnie znaną nazwą administracyjną. Gdy jest wymagany przez zgodną konfigurację, trzeba używać silnego hasła i kontrolować jego dostęp. Problemy mogą wynikać także z wyłączonego loginu, wygasłego hasła, wymuszonej polityki haseł albo braku użytkownika w bazie docelowej.

Rozpoznanie problemu podczas pracy z SQL Server

Analizę należy rozpocząć od rozdzielenia trzech etapów: nawiązania połączenia z właściwą instancją, uwierzytelnienia loginu oraz autoryzacji w wybranej bazie. Jeżeli komunikat wskazuje na odrzucenie loginu, sprawdza się tryb instancji i rodzaj używanych poświadczeń. Jeżeli połączenie zostało nawiązane, ale aplikacja otrzymuje odmowę wykonania zapytania, bardziej prawdopodobny jest problem z użytkownikiem bazy, rolą lub konkretnym uprawnieniem.

Przy diagnozie trzeba porównać konfigurację aplikacji z konfiguracją SQL Server. Istotne są między innymi nazwa serwera i instancji, wybrana baza początkowa, sposób uwierzytelniania oraz login używany przez proces aplikacji. Dla Windows Authentication znaczenie ma konto, pod którym działa aplikacja lub usługa, a nie konto osoby, która jedynie otworzyła narzędzie konfiguracyjne. Dla SQL Authentication znaczenie mają stan loginu, hasło oraz zasady jego wygasania.

W środowisku, w którym występuje błąd po zmianie ustawień, należy uwzględnić ponowne uruchomienie usługi i sprawdzić logi SQL Server dotyczące odrzuconych prób logowania. Sam fakt, że logowanie działa z jednego narzędzia, nie dowodzi poprawności konfiguracji aplikacji, ponieważ narzędzie może używać innego konta, innej instancji albo innego trybu uwierzytelniania. Prawidłowa diagnoza kończy się wskazaniem konkretnego etapu, na którym przepływ zostaje przerwany: wybór instancji, weryfikacja loginu czy dostęp do obiektów bazy.