Integracja z Windows (Active Directory)

Integracja z Windows przez Active Directory umożliwia uwierzytelnianie do SQL Server za pomocą kont domenowych.

Rola Active Directory w uwierzytelnianiu SQL Server

Integracja SQL Server z systemem Windows za pośrednictwem Active Directory pozwala używać kont użytkowników i grup domenowych podczas logowania do instancji bazy danych. Użytkownik nie musi wtedy otrzymywać oddzielnego loginu przechowywanego wyłącznie w SQL Server. Tożsamość jest potwierdzana przez mechanizmy domeny Windows, a SQL Server otrzymuje informację, dla jakiego konta lub członka grupy ma utworzyć sesję. W praktyce login może mieć postać DOMENA\uzytkownik, a login grupowy DOMENA\grupa.

W SQL Server rozróżnia się uwierzytelnianie Windows oraz uwierzytelnianie SQL Server. Przy uwierzytelnianiu Windows klient korzysta z poświadczeń aktualnie zalogowanego konta domenowego albo z poświadczeń przekazanych podczas nawiązywania połączenia. Sam fakt istnienia konta w Active Directory nie daje jeszcze dostępu do konkretnej bazy. Administrator SQL Server musi utworzyć odpowiedni login na poziomie instancji, a następnie, zależnie od potrzeb, powiązać go z użytkownikiem bazy danych i nadać mu uprawnienia.

Przepływ logowania domenowego do instancji

Podczas połączenia klient SQL Server Native Client, sterownik ODBC, dostawca OLE DB albo biblioteka używana przez aplikację negocjuje mechanizm uwierzytelniania obsługiwany przez środowisko Windows. W typowej domenie używany jest Kerberos, jeżeli spełnione są warunki wymagane przez ten protokół, między innymi poprawna rozpoznawalność nazwy usługi oraz prawidłowy wpis Service Principal Name (SPN) dla konta usługi SQL Server. Gdy Kerberos nie może zostać użyty, środowisko może przejść na NTLM, który ma inne właściwości i ograniczenia.

Po poprawnym uwierzytelnieniu SQL Server sprawdza, czy odpowiadający tożsamości login Windows istnieje w instancji. Login można utworzyć na przykład za pomocą instrukcji CREATE LOGIN [DOMENA\uzytkownik] FROM WINDOWS albo CREATE LOGIN [DOMENA\grupa] FROM WINDOWS. Następnie w konkretnej bazie danych tworzy się użytkownika powiązanego z loginem, na przykład przez CREATE USER [DOMENA\uzytkownik] FOR LOGIN [DOMENA\uzytkownik]. Uprawnienia są nadawane użytkownikowi lub roli bazodanowej, a nie automatycznie wszystkim kontom obecnym w domenie.

Kerberos, SPN i zależności konfiguracyjne

Najczęstszym źródłem problemów w integracji SQL Server z Active Directory jest rozbieżność między nazwą używaną przez klienta a konfiguracją usługi. Kerberos identyfikuje usługę między innymi na podstawie nazwy SPN. Jeżeli klient łączy się przez alias, nazwę wielokrotną, nazwę FQDN albo niestandardowy port, konfiguracja musi umożliwiać jednoznaczne wskazanie właściwej usługi SQL Server. Znaczenie ma także konto, na którym działa usługa, oraz uprawnienia potrzebne do zarejestrowania lub odczytania właściwego SPN.

Do diagnostyki można wykorzystać właściwości bieżącej sesji SQL Server. Zapytanie SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID; pokazuje mechanizm uwierzytelniania użyty przez aktualne połączenie; wartość KERBEROS oznacza logowanie przez Kerberos, a NTLM wskazuje użycie NTLM. Należy również sprawdzić rozwiązywanie nazw DNS, dostępność kontrolera domeny, synchronizację czasu oraz sposób uruchomienia usługi SQL Server. Błąd logowania może wynikać zarówno z problemu z uwierzytelnieniem domenowym, jak i z braku loginu, użytkownika bazy albo wymaganego uprawnienia.

Uprawnienia, grupy domenowe i diagnostyka dostępu

Grupy Active Directory upraszczają zarządzanie uprawnieniami w SQL Server, ponieważ dostęp można przypisać grupie zamiast konfigurować każdy komputer lub każdego użytkownika osobno. Przykładowo login grupy domenowej może zostać dodany do roli bazodanowej, a członkostwo w tej grupie będzie decydowało o dostępie. Taki model wymaga jednak kontroli zagnieżdżonych grup, aktualności członkostwa oraz tego, czy użytkownik otrzymał nowy token bezpieczeństwa po zmianie uprawnień. Zmiana członkostwa nie zawsze jest widoczna w już uruchomionej sesji systemu Windows.

Podczas sprawdzania problemu należy rozdzielić kilka etapów: uwierzytelnienie konta w domenie, rozpoznanie loginu przez instancję SQL Server, mapowanie loginu na użytkownika konkretnej bazy oraz autoryzację wykonywanej operacji. Poprawne zalogowanie do instancji nie oznacza automatycznie dostępu do każdej bazy ani do każdego obiektu. Diagnostyka powinna obejmować komunikat błędu po stronie klienta, log SQL Server, nazwę używaną w parametrach połączenia, wynik auth_scheme oraz faktyczne członkostwo w rolach. W ten sposób można odróżnić błąd domeny Windows od błędu konfiguracji uprawnień w SQL Server.