Użytkownik AD jako login pozwala uwierzytelniać się w SQL Server tożsamością domenową bez odrębnego hasła serwerowego.
Tożsamość domenowa jako login w SQL Server
Użytkownik AD jako login w SQL Server oznacza konto utworzone w usłudze Active Directory, które służy do uwierzytelniania bez tworzenia osobnego hasła przechowywanego przez SQL Server. Przykładem takiej tożsamości jest konto CONTOSO\jan.kowalski. Podczas logowania SQL Server korzysta z mechanizmów uwierzytelniania systemu Windows i sprawdza, czy przedstawiona tożsamość domenowa jest prawidłowa. Hasło użytkownika pozostaje obsługiwane przez domenę, a nie przez katalog loginów SQL Server.
Sam fakt istnienia konta w Active Directory nie nadaje jeszcze uprawnień do baz danych. W instancji SQL Server musi istnieć odpowiedni login typu Windows principal. Login jest obiektem na poziomie całej instancji, dlatego może zostać użyty do uzyskania dostępu do jednej lub wielu baz, zależnie od przypisanych mapowań i ról. W praktyce rozdziela się dwa etapy: uwierzytelnianie, czyli potwierdzenie tożsamości konta, oraz autoryzację, czyli określenie operacji dozwolonych dla tej tożsamości.
Utworzenie loginu Windows i mapowanie do bazy
Login domenowy tworzy się w SQL Server poleceniem CREATE LOGIN z klauzulą FROM WINDOWS. Dla pojedynczego konta może to wyglądać następująco: CREATE LOGIN [CONTOSO\jan.kowalski] FROM WINDOWS;. Nazwa w nawiasach kwadratowych obejmuje zarówno nazwę domeny, jak i nazwę konta. SQL Server odwołuje się w ten sposób do istniejącego podmiotu zabezpieczeń systemu Windows, a nie zakłada niezależnego użytkownika z hasłem.
Po utworzeniu loginu trzeba utworzyć użytkownika w konkretnej bazie danych i powiązać go z loginem. W kontekście wybranej bazy stosuje się na przykład CREATE USER [CONTOSO\jan.kowalski] FOR LOGIN [CONTOSO\jan.kowalski];. Dopiero taki użytkownik może otrzymać uprawnienia bazodanowe, na przykład przez dodanie do roli za pomocą ALTER ROLE. Przykładowo ALTER ROLE db_datareader ADD MEMBER [CONTOSO\jan.kowalski]; nadaje członkostwo w roli umożliwiającej odczyt danych zgodnie z uprawnieniami tej roli. Zakres dostępu powinien wynikać z rzeczywistej potrzeby, ponieważ członkostwo w rolach takich jak db_owner daje bardzo szerokie uprawnienia w obrębie bazy.
Konta grupowe, protokół logowania i typowe warunki działania
Zamiast dodawać do SQL Server każde konto osobno, można utworzyć login dla grupy domenowej, na przykład CREATE LOGIN [CONTOSO\Ksiegowosc] FROM WINDOWS;. Członkowie tej grupy mogą wtedy korzystać z dostępu wynikającego z mapowania grupy w bazie danych. Takie rozwiązanie upraszcza zmiany kadrowe i administracyjne, ale wymaga sprawdzenia rzeczywistego członkostwa w grupie oraz tego, czy komputer i użytkownik poprawnie otrzymują informacje z kontrolera domeny. W przypadku zagnieżdżonych grup końcowy zakres uprawnień zależy od pełnego łańcucha członkostwa rozpoznawanego przez system Windows i SQL Server.
Logowanie Windows może wykorzystywać Kerberos albo NTLM. Kerberos jest preferowany w środowiskach, w których wymagane jest wzajemne poprawne rozpoznanie usługi i delegowanie poświadczeń. Przy połączeniu do nazwanej usługi SQL Server znaczenie ma między innymi poprawna nazwa serwera, rozpoznawanie DNS oraz rejestracja właściwego Service Principal Name, czyli SPN. Niepoprawny SPN, brak zaufania między domenami, niedostępny kontroler domeny albo uruchomienie usługi SQL Server na koncie, dla którego nie można prawidłowo zarejestrować tożsamości usługi, może skutkować wyborem NTLM lub nieudanym logowaniem. W narzędziach diagnostycznych warto rozróżnić błąd uwierzytelniania Windows od błędu braku loginu, braku użytkownika w bazie oraz odmowy uprawnienia do konkretnego obiektu.
Weryfikacja dostępu i diagnostyka problemów z loginem AD
Podczas diagnozowania problemu należy najpierw potwierdzić, z jaką tożsamością działa połączenie i do jakiej instancji SQL Server faktycznie trafia. W otwartej sesji można sprawdzić między innymi SUSER_SNAME(), które zwraca nazwę loginu rozpoznanego na poziomie instancji, oraz USER_NAME(), które pokazuje użytkownika bazodanowego w bieżącym kontekście. Przydatne jest także SELECT ORIGINAL_LOGIN();, ponieważ pozwala ustalić pierwotny login sesji, zwłaszcza gdy w dalszym przepływie użyto zmiany kontekstu zabezpieczeń.
Jeżeli CREATE LOGIN ... FROM WINDOWS nie działa, trzeba sprawdzić zapis nazwy domeny i konta, dostępność Active Directory oraz możliwość rozpoznania podmiotu przez serwer SQL Server. Jeżeli login działa, lecz dostęp do bazy jest odrzucany, należy zweryfikować obecność użytkownika w tej konkretnej bazie i jego członkostwo w rolach. Jeśli problem występuje tylko przy połączeniu przez nazwę aliasową albo nazwę DNS, a nie przy nazwie rzeczywistej hosta, podejrzenie może dotyczyć Kerberos, SPN lub konfiguracji klienta. Diagnostyka laptopa albo komputera PC może obejmować sprawdzenie profilu domenowego, stanu połączenia z siecią firmową, aktualnego biletu Kerberos oraz ustawień narzędzia używanego do łączenia z SQL Server. Wnioski powinny wynikać z komunikatu błędu i konfiguracji konkretnej instancji, a nie wyłącznie z samego faktu, że konto istnieje w Active Directory.
