Łączenie do SQL przez AD

Łączenie do SQL przez AD to uwierzytelnianie w bazie tożsamością domenową użytkownika zamiast osobnym kontem serwera.

Na czym polega uwierzytelnianie do SQL Server przez Active Directory

Łączenie do SQL przez AD oznacza użycie tożsamości domenowej użytkownika lub komputera do uwierzytelnienia w Microsoft SQL Server. Osobne hasło zapisane dla konta SQL Server nie jest wtedy podstawowym mechanizmem logowania. Użytkownik uwierzytelnia się w domenie Active Directory, a SQL Server otrzymuje potwierdzenie jego tożsamości od systemu Windows. W aplikacji taki tryb jest zwykle określany jako Windows Authentication albo Integrated Security.

Po poprawnym uwierzytelnieniu SQL Server musi jeszcze sprawdzić uprawnienia. Sama obecność konta w Active Directory nie daje automatycznie dostępu do każdej bazy ani do każdej tabeli. W instancji SQL Server tworzy się login systemu Windows, na przykład DOMENA\jan.kowalski, albo login dla grupy domenowej. Następnie login może zostać powiązany z użytkownikiem w konkretnej bazie danych, a użytkownik otrzymuje role i uprawnienia odpowiadające zakresowi pracy.

Droga uwierzytelnienia: Kerberos, NTLM i konto usługi

W środowisku domenowym SQL Server może korzystać z protokołu Kerberos, który używa biletów wydawanych przez usługę uwierzytelniania domeny. Dla połączeń do zdalnego serwera poprawne działanie Kerberos zależy między innymi od rozpoznawalnej nazwy usługi, poprawnego rekordu DNS oraz zarejestrowanego identyfikatora SPN dla konta uruchamiającego usługę SQL Server. SPN wiąże nazwę usługi z konkretnym kontem i pozwala klientowi ustalić, do jakiego serwera należy skierować bilet.

Jeżeli warunki wymagane przez Kerberos nie są spełnione, system Windows może zastosować NTLM, o ile konfiguracja i topologia połączenia na to pozwalają. Taka sytuacja może ujawnić się jako problem występujący wyłącznie przy połączeniu zdalnym, przy użyciu aliasu DNS albo podczas przechodzenia przez dodatkową warstwę pośrednią. Znaczenie ma również konto usługi SQL Server. Usługa uruchomiona pod kontem domenowym może mieć inne możliwości rejestracji SPN niż usługa działająca pod kontem wbudowanym. Dlatego diagnoza powinna obejmować nazwę serwera używaną przez klienta, rozwiązywanie DNS, konfigurację instancji oraz sposób uruchomienia usługi.

Konfiguracja loginów, grup i parametrów połączenia

W SQL Server login systemu Windows może zostać utworzony dla użytkownika albo grupy domenowej. Przykładowa instrukcja ma postać CREATE LOGIN [DOMENA\GrupaSQL] FROM WINDOWS. W bazie danych tworzy się następnie użytkownika odpowiadającego temu loginowi, a dostęp nadaje się przez role bazodanowe lub jawne uprawnienia. Wykorzystanie grupy domenowej upraszcza zarządzanie, ponieważ zmiana członkostwa w grupie może zmienić dostęp bez tworzenia osobnego loginu SQL Server dla każdej osoby.

Klient musi jednak używać właściwego trybu uwierzytelniania. W popularnych bibliotekach .NET dla SQL Server spotyka się parametry Integrated Security=True albo Trusted_Connection=True. Ich znaczenie jest związane z użyciem poświadczeń systemu Windows zamiast pary nazwa użytkownika i hasło przeznaczonej dla loginu SQL Server. W aplikacji działającej jako usługa ważne jest konto procesu, ponieważ połączenie wykorzystuje tożsamość procesu, a niekoniecznie konto osoby zalogowanej na pulpicie. Przy zadaniach uruchamianych przez harmonogram, pulę aplikacji lub usługę systemową należy więc sprawdzić, pod jakim kontem faktycznie działa dany proces.

Rozpoznawanie problemów z połączeniem przez AD

Objaw „logowanie nie powiodło się” może oznaczać kilka różnych problemów. Nieprawidłowe hasło domenowe, wyłączone konto, brak dostępu komputera do kontrolera domeny i błędny parametr uwierzytelniania dotyczą warstwy Active Directory lub klienta. Komunikat o braku loginu w SQL Server wskazuje natomiast na sytuację, w której tożsamość została rozpoznana, ale nie ma odpowiedniego loginu w instancji. Błąd związany z dostępem do bazy może pojawić się wtedy, gdy login istnieje, lecz nie ma użytkownika w wybranej bazie albo użytkownik nie ma wymaganych praw.

W praktycznej diagnostyce należy porównać połączenie lokalne i zdalne, nazwę hosta oraz nazwę używaną w parametrach połączenia. Warto ustalić, czy klient korzysta z nazwy komputera, pełnej nazwy DNS, aliasu lub nazwy instancji. Następnie sprawdza się stan usługi SQL Server, dostępność portu, konfigurację protokołów sieciowych, członkostwo konta w grupach domenowych oraz obecność loginu Windows w instancji. Przy podejrzeniu problemu z Kerberos analizuje się rejestrację SPN i konto usługi. Diagnostyka laptopa lub komputera może również obejmować lokalne błędy DNS, nieaktualne połączenie z domeną, niewłaściwy zegar systemowy oraz konfigurację aplikacji używającej SQL Server.