Kerberos

Kerberos to protokół uwierzytelniania sieciowego wykorzystywany m.in. do zintegrowanego logowania do SQL Server.

Kerberos jako protokół uwierzytelniania sieciowego

Kerberos jest protokołem uwierzytelniania opartym na biletach, zaprojektowanym do potwierdzania tożsamości użytkowników i usług w sieci bez przesyłania hasła przy każdym kolejnym połączeniu. W typowym środowisku domenowym użytkownik loguje się do centrum dystrybucji kluczy, czyli KDC (Key Distribution Center). KDC jest logicznie podzielone na usługę uwierzytelniającą AS (Authentication Service) oraz usługę przyznawania biletów TGS (Ticket Granting Service). Po pomyślnym uwierzytelnieniu AS wydaje bilet TGT (Ticket-Granting Ticket), który służy później do uzyskiwania biletów przeznaczonych dla konkretnych usług.

Podstawą działania Kerberosa jest zaufanie do KDC oraz używanie nazw usług zapisanych jako SPN (Service Principal Name). Klient, który chce połączyć się z określoną usługą, przedstawia bilet uzyskany z TGS. Usługa może zweryfikować bilet i ustalić, dla jakiego konta został wystawiony, bez bezpośredniego odczytywania hasła użytkownika. W protokole stosowane są znaczniki czasu, dlatego poprawna synchronizacja zegarów między klientem, kontrolerem domeny i serwerem usługi ma znaczenie praktyczne. Zbyt duża różnica czasu może spowodować odrzucenie biletu mimo poprawnych danych logowania.

Bilety, SPN i przebieg logowania zintegrowanego

Proces rozpoczyna się od uwierzytelnienia użytkownika wobec usługi AS. W środowisku Active Directory dane potrzebne do wyprowadzenia klucza kryptograficznego są związane z kontem domenowym, a klient otrzymuje TGT. Gdy aplikacja potrzebuje dostępu do konkretnej usługi, zwraca się do TGS i wskazuje jej nazwę SPN. TGS wystawia bilet usługowy przeznaczony dla wskazanego konta. Następnie klient przekazuje ten bilet serwerowi usługi, a serwer sprawdza jego autentyczność oraz zgodność z własną konfiguracją.

SPN opisuje usługę poprzez klasę usługi, nazwę hosta i często numer portu albo dodatkowy identyfikator instancji. Dla SQL Server znaczenie ma poprawne powiązanie SPN z kontem, pod którym działa właściwa usługa bazy danych. Jeżeli SPN nie istnieje, wskazuje niewłaściwe konto albo występuje w domenie więcej niż raz, Kerberos może nie zostać użyty. Wtedy klient może przejść na mechanizm NTLM, o ile konfiguracja i biblioteki połączeniowe na to pozwalają. Taki fallback zmienia sposób uwierzytelniania i może wpływać na działanie funkcji wymagających delegowania poświadczeń.

Kerberos w połączeniach z SQL Server

W przypadku SQL Server uwierzytelnianie zintegrowane z domeną może korzystać z Kerberosa, gdy klient, serwer i konfiguracja usługi spełniają wymagane warunki. Sam wybór opcji zintegrowanego uwierzytelniania nie gwarantuje jeszcze użycia Kerberosa. Serwer SQL Server musi być osiągalny pod nazwą odpowiadającą zarejestrowanemu SPN, a usługa musi działać na koncie, dla którego ten SPN został utworzony. Istotne są także poprawne rozpoznawanie nazw DNS, dostęp klienta do kontrolera domeny oraz synchronizacja czasu.

Przy połączeniu z SQL Server używana jest nazwa instancji i sposób adresowania, które wpływają na wybór właściwego SPN. Dotyczy to zarówno instancji domyślnej, jak i instancji nazwanej, ponieważ każda z nich może wymagać odrębnych wpisów zależnych od nazwy hosta, portu i konta usługi. Błąd logowania może wynikać z niezgodności nazwy użytej przez klienta z nazwą zarejestrowaną w domenie, z braku uprawnień do odczytu biletu albo z niedostępności KDC. W diagnostyce należy odróżnić błąd samego uwierzytelniania Kerberos od późniejszego błędu autoryzacji w SQL Server. Prawidłowy bilet potwierdza tożsamość, ale nie nadaje automatycznie uprawnień do konkretnej bazy, schematu ani tabeli.

Rozpoznawanie problemów z uwierzytelnianiem Kerberos

Analizę warto rozpocząć od ustalenia, jakiej nazwy używa klient oraz na jakie konto wskazuje usługa SQL Server. Następnie sprawdza się, czy dla tej usługi istnieje dokładnie jeden właściwy SPN i czy nie został przypisany do innego konta. Duplikat SPN może powodować niejednoznaczność podczas pobierania biletu. Nieprawidłowa rozdzielczość DNS może natomiast sprawić, że klient połączy się z adresem serwera, ale nie uzyska biletu dla nazwy usługi oczekiwanej przez SQL Server. Warto również zweryfikować stan biletu TGT i biletów usługowych w pamięci klienta, zamiast zakładać, że wcześniejsze logowanie zapewniło aktualne poświadczenia.

W środowisku SQL Server sposób użytego uwierzytelniania można rozpoznawać na podstawie właściwości bieżącego połączenia oraz logów klienta i serwera. Jeżeli połączenie działa wyłącznie po zmianie nazwy serwera, może to wskazywać na problem z SPN albo DNS, a nie na uszkodzenie samego silnika bazy danych. Jeżeli działa zwykłe logowanie zintegrowane, ale nie działa scenariusz wymagający przekazania tożsamości do kolejnej usługi, należy sprawdzić delegowanie i zakres biletu. Diagnostyka powinna obejmować także ustawienia zapory, dostępność portu SQL Server, stan kontrolera domeny oraz zgodność czasu, ponieważ konfiguracja Kerberosa dla SQL Server wymaga analizy środowiska domenowego, kont usług i zasad obowiązujących po stronie administratora.