SSMS – Connect using Windows Authentication

Uwierzytelnianie Windows w SSMS wykorzystuje tożsamość zalogowanego użytkownika systemu do nawiązania połączenia.

Jak SSMS wykorzystuje tożsamość systemu Windows

Opcja „Connect using Windows Authentication” w SQL Server Management Studio (SSMS) służy do nawiązania połączenia z instancją Microsoft SQL Server przy użyciu bieżącego konta Windows. Użytkownik nie wpisuje w oknie logowania osobnego loginu ani hasła do SQL Server. SSMS przekazuje do serwera kontekst zabezpieczeń procesu, a SQL Server sprawdza, czy wskazana tożsamość systemu Windows ma prawo zalogować się do instancji. W typowym przypadku login jest rozpoznawany jako konto domenowe w formacie DOMENA\użytkownik albo konto lokalne komputera.

Windows Authentication nie oznacza automatycznego dostępu do każdej bazy ani do wszystkich operacji administracyjnych. Po pomyślnym uwierzytelnieniu SQL Server wykonuje jeszcze autoryzację. Login Windows musi istnieć w instancji jako login serwera albo należeć do grupy Windows, dla której taki login utworzono. Następnie uprawnienia mogą wynikać z członkostwa w rolach serwerowych, ról bazodanowych oraz przydzielonych uprawnień do konkretnych obiektów, takich jak tabele, widoki, procedury składowane lub schematy.

Wybór serwera, instancji i trybu uwierzytelniania

W oknie połączenia SSMS trzeba podać właściwy typ serwera oraz nazwę instancji SQL Server. Dla instancji domyślnej często używa się samej nazwy hosta, adresu IP albo nazwy komputera. Instancja nazwana może wymagać zapisu w rodzaju HOST\NAZWA_INSTANCJI. W środowisku lokalnym spotykane są także oznaczenia localhost, kropka lub (local), ale działają tylko wtedy, gdy odpowiednia instancja SQL Server rzeczywiście znajduje się na tym samym komputerze i nasłuchuje pod oczekiwanym adresem.

Po wybraniu Windows Authentication pole loginu jest zwykle nieaktywne, ponieważ SSMS korzysta z konta Windows uruchamiającego aplikację. Jeżeli konieczne jest użycie innego konta, aplikację można uruchomić w kontekście tego konta systemowego, na przykład przez funkcję „Uruchom jako inny użytkownik”. Samo wpisanie innej nazwy w polu połączenia nie zmienia tożsamości Windows używanej przez proces. Należy również odróżnić Windows Authentication od SQL Server Authentication, w którym serwer otrzymuje osobny login SQL Server i hasło skonfigurowane niezależnie od konta systemu Windows.

Co dzieje się podczas połączenia z SQL Server

Po zatwierdzeniu formularza SSMS rozpoczyna komunikację z wybraną instancją SQL Server. Serwer musi być osiągalny przez sieć, właściwa usługa SQL Server musi działać, a nazwa instancji i sposób określenia portu muszą odpowiadać rzeczywistej konfiguracji. Przy połączeniach sieciowych znaczenie ma także zapora oraz protokół sieciowy skonfigurowany dla instancji. Błąd Windows Authentication może więc pojawić się zarówno z powodu braku uprawnień, jak i dlatego, że klient nie dotarł do właściwego serwera.

W środowisku domenowym uwierzytelnianie może korzystać z Kerberos, jeżeli spełnione są wymagania dotyczące domeny, nazwy usługi i identyfikatora SPN, czyli Service Principal Name. Gdy Kerberos nie jest dostępny, w określonych warunkach może zostać użyty NTLM. Różnica ma znaczenie między innymi przy połączeniach do zdalnych hostów oraz przy operacjach wymagających przekazania poświadczeń dalej. Nie należy jednak utożsamiać samego wyboru Windows Authentication w SSMS z gwarancją użycia konkretnego protokołu; o zastosowanym mechanizmie decydują również topologia domeny, konfiguracja SQL Server, nazwa użyta do połączenia i ustawienia systemowe.

Komunikaty takie jak „Login failed for user” oznaczają zwykle, że serwer odrzucił próbę logowania albo nie znalazł wymaganej mapy loginu do instancji. Z kolei komunikat o braku możliwości nawiązania połączenia wskazuje częściej na problem z nazwą serwera, usługą, portem, zaporą lub dostępnością sieci. Przy analizie problemu warto zapisać pełną nazwę instancji, konto używane przez proces SSMS, dokładny tekst błędu oraz informację, czy połączenie jest lokalne, czy zdalne.

Znaczenie ustawienia dla diagnostyki połączenia

Sprawdzenie Windows Authentication powinno być powiązane z weryfikacją kilku niezależnych elementów: poprawności nazwy serwera, działania usługi SQL Server, obecności loginu Windows w instancji oraz uprawnień do docelowej bazy. Możliwe jest poprawne uwierzytelnienie i jednoczesny brak dostępu do konkretnej bazy, na przykład gdy login nie został utworzony jako użytkownik tej bazy albo użytkownik nie ma wymaganych praw. Z tego powodu samo przełączenie metody logowania nie rozwiązuje problemów z autoryzacją.

Podczas diagnostyki należy także sprawdzić, czy SSMS został uruchomiony pod oczekiwanym kontem, szczególnie gdy komputer jest używany przez kilka osób lub aplikacja została uruchomiona z podwyższonymi uprawnieniami. W przypadku kont domenowych znaczenie może mieć utrata łączności z kontrolerem domeny, wygasłe poświadczenia albo ograniczenia wynikające z zasad domenowych. Przy koncie lokalnym trzeba odróżnić nazwę użytkownika lokalnego komputera od konta domenowego o podobnej nazwie. Takie rozróżnienie pomaga ustalić, czy problem dotyczy sieci i usług systemowych, czy konfiguracji loginów oraz uprawnień w SQL Server.