Użytkownik AD w SSMS

Użytkownik AD w SSMS łączy się z instancją, wykorzystując uwierzytelnianie Windows zamiast konta SQL.

Kim jest użytkownik AD w SSMS

Użytkownik AD w SSMS to konto zarządzane przez Active Directory, używane do połączenia z serwerem Microsoft SQL Server za pomocą uwierzytelniania Windows. W SQL Server Management Studio w polu typu uwierzytelniania wybiera się opcję „Windows Authentication”. SSMS przekazuje wtedy do serwera tożsamość zalogowanego użytkownika systemu Windows, zamiast wysyłać nazwę i hasło konta utworzonego bezpośrednio w SQL Server. W typowej sieci firmowej konto ma postać DOMENA\użytkownik albo jest członkiem domenowej grupy zabezpieczeń.

Active Directory odpowiada za potwierdzenie tożsamości konta, natomiast SQL Server decyduje, jakie uprawnienia otrzyma po poprawnym zalogowaniu. Sam fakt istnienia użytkownika w domenie nie oznacza automatycznego dostępu do każdej instancji ani do każdej bazy. Administrator SQL Server musi utworzyć odpowiedni login Windows na poziomie instancji, a następnie może powiązać go z użytkownikiem w konkretnej bazie danych i nadać mu role lub uprawnienia do obiektów.

Jak przebiega logowanie Windows Authentication

Podczas łączenia SSMS korzysta z poświadczeń bieżącej sesji Windows. Jeżeli komputer i serwer SQL Server należą do tej samej domeny lub domen, a rozpoznawanie nazw i relacje zaufania działają prawidłowo, uwierzytelnienie może odbyć się z użyciem protokołu Kerberos. W określonych sytuacjach, na przykład przy braku prawidłowej rejestracji usługi lub przy połączeniu przez adres IP, system może użyć NTLM. Wybór mechanizmu zależy od konfiguracji środowiska Windows, domeny, nazwy serwera i sposobu zestawienia połączenia.

W oknie połączenia SSMS użytkownik zwykle nie wpisuje osobnego hasła dla Windows Authentication, ponieważ hasło zostało już użyte podczas logowania do systemu. Aby uruchomić SSMS z innym kontem domenowym, można użyć funkcji uruchomienia programu jako inny użytkownik systemu Windows. Wtedy proces SSMS działa w kontekście wybranego konta i właśnie ta tożsamość jest przedstawiana instancji SQL Server. Przy diagnozowaniu problemów trzeba więc sprawdzić nie tylko nazwę wpisaną w polu „Server name”, ale również konto, pod którym faktycznie uruchomiono program.

Login, użytkownik bazy i uprawnienia

Administrator może utworzyć login domenowy w SQL Server poleceniem CREATE LOGIN [DOMENA\użytkownik] FROM WINDOWS;. Zamiast pojedynczego konta często dodaje się grupę Active Directory, na przykład DOMENA\SQL-ReadOnly, a następnie tworzy w bazie użytkownika powiązanego z tym loginem. Takie rozwiązanie upraszcza zarządzanie: członkostwo w grupie jest zmieniane w Active Directory, a uprawnienia SQL pozostają przypisane do grupy. Login istnieje na poziomie instancji, natomiast użytkownik bazy danych i jego role dotyczą określonej bazy.

Po uwierzytelnieniu SQL Server sprawdza, czy dla przedstawionej tożsamości istnieje login Windows albo login grupy, której użytkownik jest członkiem. Następnie oceniane są uprawnienia wynikające z ról serwerowych, ról bazodanowych, członkostwa w grupach oraz nadanych zezwoleń i odmów. Brak dostępu może więc oznaczać kilka różnych problemów: nieprawidłową nazwę instancji, brak łączności z serwerem, nieudane uwierzytelnienie domenowe, brak loginu w SQL Server, brak użytkownika w wybranej bazie albo niewystarczające uprawnienia do tabeli, widoku, procedury lub innego obiektu.

Diagnostyka połączenia z instancją SQL Server

Przy problemach z użytkownikiem AD w SSMS należy najpierw ustalić, czy konto jest zalogowane do właściwej domeny i czy komputer może rozwiązać nazwę serwera SQL Server. Następnie trzeba zweryfikować nazwę instancji, port, działanie usługi SQL Server Browser w przypadku instancji nazwanej oraz reguły zapory sieciowej. Komunikat „Login failed for user” wskazuje na problem na etapie logowania lub autoryzacji, ale pełną przyczynę zwykle zawiera dziennik błędów SQL Server. Administrator powinien sprawdzić kod stanu błędu, nazwę loginu i bazę, z którą próbowano się połączyć.

Warto również porównać połączenie przy użyciu nazwy hosta z połączeniem przez adres IP, ponieważ różnica może wpływać na negocjację Kerberos. Jeżeli użytkownik jest członkiem grupy domenowej dodanej do SQL Server, nowe członkostwo może wymagać ponownego logowania do Windows, aby lokalny token bezpieczeństwa zawierał aktualne informacje. Przy diagnostyce uprawnień należy rozdzielić etap uwierzytelniania od autoryzacji: poprawne rozpoznanie konta nie gwarantuje prawa do odczytu lub modyfikacji danych. Sprawdzenie loginu, mapowania użytkownika w bazie i członkostwa w rolach pozwala ustalić, w którym miejscu przepływu następuje odmowa.