SQL Server w środowisku RODC

SQL Server w środowisku RODC ma ograniczoną możliwość uwierzytelniania Kerberos ze względu na charakter tego kontrolera domeny.

SQL Server w środowisku RODC – czym jest to połączenie

SQL Server w środowisku RODC oznacza pracę bazy danych w sieci, w której przynajmniej jeden kontroler domeny działa jako Read-Only Domain Controller. RODC przechowuje replikowany, przeznaczony do odczytu zestaw danych katalogowych Active Directory, ale nie pozwala na swobodne zapisywanie zmian bezpośrednio na tym kontrolerze. Takie rozwiązanie bywa stosowane w oddziałach, punktach terenowych i lokalizacjach, w których trzeba ograniczyć ryzyko przejęcia kontrolera domeny albo zmniejszyć zakres danych dostępnych poza główną serwerownią.

Sam SQL Server nie staje się przez to bazą tylko do odczytu. Instancja może nadal obsługiwać operacje zapisu, zapytania, procedury składowane, zadania agenta oraz aplikacje biznesowe. Ograniczenie dotyczy przede wszystkim sposobu korzystania z usług domenowych podczas uwierzytelniania użytkowników i kont usług. RODC jest elementem infrastruktury Active Directory, natomiast SQL Server pozostaje systemem zarządzania relacyjną bazą danych. Te dwa obszary współpracują, lecz nie należy utożsamiać roli kontrolera domeny z rolą serwera bazodanowego.

W praktyce szczególne znaczenie ma konfiguracja konta usługi SQL Server, SPN, DNS, delegowania oraz zasad buforowania poświadczeń na RODC. Jeżeli aplikacja korzysta z logowania zintegrowanego z domeną, każde odstępstwo od prawidłowej konfiguracji może ujawnić się jako błąd logowania, przejście do NTLM albo brak dostępu do zasobu zależnego od domeny.

SQL Server i RODC – kontekst techniczny oraz porównanie metod logowania

Kerberos opiera się na biletach wydawanych przez usługę uwierzytelniania domenowego. W przypadku SQL Servera klient powinien rozpoznać nazwę usługi, odnaleźć właściwy Service Principal Name i uzyskać bilet odpowiadający tej usłudze. Jeżeli SQL Server działa pod kontem domenowym, a SPN nie został przypisany prawidłowo, klient może nie potrafić jednoznacznie wskazać instancji. Przy połączeniu przez alias, nazwę krótką, nazwę FQDN albo nazwę wirtualną znaczenie ma także to, czy dla każdej używanej nazwy istnieje właściwy wpis.

RODC nie pełni funkcji równorzędnej z zapisywalnym kontrolerem domeny. Żądania wymagające zmiany danych katalogowych muszą zostać obsłużone przez kontroler zapisywalny, a część informacji może nie być obecna lokalnie. Dotyczy to także poświadczeń użytkowników i usług, ponieważ ich buforowanie na RODC podlega osobnym zasadom. Gdy dane potrzebne do uwierzytelnienia nie są dostępne lokalnie, wymagane jest połączenie z kontrolerem, który może udzielić odpowiedzi.

W porównaniu z Kerberosem NTLM ma inny model działania i zwykle nie wymaga takiego samego dopasowania SPN. Nie oznacza to jednak, że automatyczne przejście na NTLM rozwiązuje problem w sposób docelowy. Zmiana protokołu może ukryć błąd konfiguracji, ograniczyć możliwości wzajemnego uwierzytelniania i utrudnić analizę tożsamości usługi. W środowisku z RODC należy więc ustalić, czy połączenie rzeczywiście korzysta z Kerberosa, czy tylko pozornie działa dzięki mechanizmowi zastępczemu.

Różnica między kontrolerem zapisywalnym a RODC jest istotna również podczas awarii łącza. Przy pełnej dostępności sieci aplikacja może działać bez widocznych różnic. Po utracie połączenia z główną lokalizacją ujawniają się natomiast zależności związane z lokalnym buforem poświadczeń, odnajdywaniem kontrolera domeny, rozwiązywaniem nazw i dostępnością SPN. Sama obecność RODC nie gwarantuje więc, że logowanie do SQL Servera będzie możliwe w trybie odłączonym.

SQL Server w RODC – typowe problemy z uwierzytelnianiem

Jednym z częstszych objawów jest komunikat o nieudanym logowaniu przy użyciu konta domenowego, mimo że to samo konto działa z innej stacji. Przyczyną może być brak biletu Kerberos, niepoprawny SPN, niedostępność kontrolera zapisywalnego, rozbieżność czasu albo użycie nazwy, która nie odpowiada nazwie zarejestrowanej dla usługi. Błąd może pojawić się także wtedy, gdy aplikacja uruchamia się pod kontem lokalnym, a próbuje uzyskać dostęp do bazy przez mechanizm wymagający tożsamości domenowej.

Inny problem stanowi wielokrotna rejestracja SPN. Jeżeli ta sama nazwa usługi została przypisana do więcej niż jednego konta, KDC nie ma pewności, któremu kontu należy wystawić bilet. Rezultatem bywa odrzucenie uwierzytelnienia albo nieprzewidywalne przełączanie między Kerberosem i NTLM. Podobny efekt może wywołać uruchomienie SQL Servera pod innym kontem niż to, dla którego wcześniej przygotowano konfigurację.

Znaczenie ma również DNS. Klient musi prawidłowo odnaleźć nazwę SQL Servera, kontroler domeny oraz usługę odpowiedzialną za uwierzytelnianie. Błędny sufiks DNS, nieaktualny rekord, niezgodność nazwy komputera z nazwą używaną przez aplikację lub korzystanie z publicznego resolvera zamiast z DNS domenowego mogą spowodować, że problem będzie wyglądał jak awaria samej bazy.

Nie należy pomijać synchronizacji czasu. Kerberos wykorzystuje ograniczony przedział ważności biletów, dlatego większa różnica czasu między klientem, SQL Serverem i kontrolerem domeny może doprowadzić do odrzucenia biletu. Warto także sprawdzić, czy zapora sieciowa nie blokuje komunikacji z DNS, usługami katalogowymi, KDC i portem używanym przez konkretną instancję SQL Servera.

SQL Server oraz RODC – praktyczne wskazówki diagnostyczne

Diagnostykę warto rozpocząć od ustalenia, jak dokładnie klient łączy się z bazą. Należy zapisać używaną nazwę serwera, nazwę instancji, port, sposób logowania i konto procesu aplikacji. Warto porównać połączenie przez nazwę komputera, pełną nazwę DNS oraz ewentualny alias. Jeżeli działa tylko jedna z tych form, wskazuje to na problem z rozpoznawaniem usługi, DNS albo SPN, a niekoniecznie na uszkodzenie danych bazy.

Następnie sprawdza się, który protokół został faktycznie użyty. Informacji można szukać w właściwościach sesji SQL Servera, dziennikach aplikacji i narzędziach systemowych analizujących bilety Kerberos. Sam poprawny wynik zapytania nie dowodzi jeszcze, że użyto Kerberosa, ponieważ połączenie mogło zostać zaakceptowane przez NTLM. Istotne jest rozróżnienie tych przypadków przed wprowadzaniem zmian w konfiguracji.

Weryfikacji wymagają konto usługi SQL Server, uprawnienia do rejestracji SPN oraz wpisy przypisane do wszystkich nazw, których używają klienci. Po zmianie konta, nazwy hosta, portu, aliasu albo sposobu uruchamiania usługi trzeba ponownie ocenić kompletność konfiguracji. Nie powinno się usuwać wpisów metodą prób i błędów, ponieważ może to zakłócić inne połączenia korzystające z tej samej tożsamości.

Warto też sprawdzić zasady Password Replication Policy na RODC. Konto może być poprawne, ale jego poświadczenia nie muszą być dozwolone do buforowania lokalnie. Przy niedostępnym połączeniu z głównym kontrolerem domeny taki brak staje się widoczny. Należy zweryfikować, czy konto użytkownika lub konto usługi może być użyte w danej lokalizacji, a także czy nie znajduje się na liście jawnie odmawiającej buforowania.

Zmiany powinny być wykonywane etapami, z zachowaniem informacji o stanie początkowym. Po każdej korekcie warto ponowić test z tego samego komputera, przy użyciu tej samej nazwy i tego samego konta. Pomaga to odróżnić poprawę rzeczywistą od efektu pozostawionego biletu w pamięci albo chwilowej dostępności kontrolera domeny.

SQL Server w środowisku RODC – kiedy zgłosić problem do serwisu

Zgłoszenie do serwisu jest uzasadnione, gdy logowanie do SQL Servera działa tylko z wybranych komputerów, połączenie traci dostęp po odłączeniu lokalizacji od głównej sieci albo aplikacja zaczyna używać NTLM mimo wcześniejszej pracy z Kerberosem. Pomocna będzie informacja o czasie wystąpienia problemu, nazwie używanej przez aplikację, koncie usługi, komunikacie błędu oraz zmianach wykonanych przed awarią. Przydatne są także fragmenty dzienników, opis topologii DNS i wskazanie, czy problem dotyczy jednej bazy, całej instancji, czy tylko wybranej lokalizacji.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić analizę komputera, z którego występuje problem z dostępem do bazy, konfiguracją domeny lub komunikacją sieciową. W ramach ustaleń warto wyraźnie zaznaczyć, że diagnostyka ma objąć relację między SQL Serverem, RODC, DNS, SPN i kontem usługi, a nie tylko ponowne uruchomienie aplikacji. Pozwala to zebrać dane potrzebne do dalszej, uporządkowanej naprawy i ograniczyć ryzyko przypadkowego osłabienia uwierzytelniania.

Nie powinno się usuwać kontrolera RODC, zmieniać kont usług ani wyłączać wymagania Kerberos bez wcześniejszego sprawdzenia zależności. Takie działania mogą chwilowo przywrócić dostęp, ale jednocześnie utrudnić późniejszą kontrolę tożsamości i zwiększyć zakres niepożądanych połączeń. Bezpieczniejsza jest analiza ścieżki uwierzytelniania, potwierdzenie właściwego SPN, sprawdzenie replikacji oraz test z kilku punktów sieci.

Jeżeli problem dotyczy samego laptopa używanego do administracji, warto zabezpieczyć kopię komunikatów i nie zmieniać samodzielnie ustawień domenowych przed zebraniem podstawowych danych. Dzięki temu łatwiej rozdzielić awarię urządzenia, błąd DNS, brak lokalnie dostępnych poświadczeń RODC oraz nieprawidłową konfigurację usługi SQL Server.