SQL Server w środowisku z GPO

SQL Server w środowisku z GPO może dziedziczyć zasady haseł i ograniczenia narzucone centralnie przez administratora domeny.

Jak GPO wpływa na SQL Server

SQL Server działający w domenie Windows może podlegać skutkom zasad grupy, ale GPO nie jest osobnym mechanizmem konfigurującym wszystkie ustawienia silnika bazy danych. Zasady grupy oddziałują przede wszystkim na system operacyjny, konta użytkowników i usług, zasady zabezpieczeń, zaporę sieciową, rejestr oraz sposób uwierzytelniania domenowego. SQL Server korzysta z tych elementów podczas uruchamiania usługi, nawiązywania połączeń i sprawdzania uprawnień.

Najważniejsze znaczenie ma rozróżnienie między logowaniem Windows a logowaniem SQL Server. Przy uwierzytelnianiu Windows użytkownik lub konto usługi jest sprawdzane przez domenę albo lokalny system Windows, dlatego obowiązują go zasady haseł i blokad wynikające z Active Directory oraz GPO. Przy logowaniu SQL Server konto jest przechowywane w silniku bazy danych. Dla takiego konta SQL Server może jednak korzystać z zasad haseł Windows, jeżeli włączono opcję CHECK_POLICY. Nie oznacza to, że GPO konfiguruje samo konto w taki sam sposób jak konto domenowe.

Polityka haseł, blokady i konta usługowe

Dla loginów SQL Server ustawienie CHECK_POLICY = ON powoduje stosowanie zasad haseł systemu Windows dostępnych na komputerze, na którym działa SQL Server. Dotyczy to między innymi wymaganej złożoności, minimalnej długości, historii haseł oraz blokowania konta po wielokrotnych nieudanych próbach, o ile dana wersja i konfiguracja systemu udostępniają te mechanizmy. Ustawienie CHECK_EXPIRATION = ON pozwala dodatkowo wymuszać wygaśnięcie hasła zgodnie z polityką systemową. Te opcje dotyczą loginów SQL Server, a nie kont Windows używanych przez aplikacje lub usługi.

Konto usługi SQL Server, SQL Server Agent albo innego składnika może być kontem domenowym, kontem wirtualnym, kontem zarządzanym przez system lub lokalnym kontem systemowym. GPO może ograniczyć możliwość logowania takiego konta jako usługi, zmienić jego prawa użytkownika albo wpłynąć na dostęp do katalogów, udziałów sieciowych i certyfikatów. W rezultacie usługa może nie wystartować po zmianie zasad, mimo że konfiguracja instancji SQL Server nie została zmieniona. Podobny skutek może wystąpić po wymuszeniu rotacji hasła konta domenowego, gdy nowe dane uwierzytelniające nie zostaną wprowadzone do konfiguracji usługi.

Połączenia sieciowe a zasady grupy

GPO może wpływać na dostępność połączeń do SQL Server przez konfigurację Zapory Windows Defender, reguł ruchu przychodzącego i wychodzącego oraz ustawień sieciowych. Dla domyślnej instancji SQL Server często używany jest port TCP 1433, ale numer portu może być inny. Instancje nazwane mogą korzystać z dynamicznych portów, a SQL Server Browser pomaga klientowi ustalić port właściwej instancji przez protokół UDP 1434. Zablokowanie odpowiedniej reguły zapory może więc powodować błąd połączenia, nawet gdy usługa silnika działa prawidłowo.

Polityka grupy może także narzucać ustawienia protokołów zabezpieczeń, ograniczać starsze mechanizmy uwierzytelniania albo zmieniać konfigurację systemowego stosu sieciowego. SQL Server może wtedy zgłaszać błędy logowania, odrzucać połączenia z określonych komputerów lub nie uzyskiwać dostępu do zasobów domenowych. Przy analizie należy oddzielić błąd transportu, taki jak brak dostępu do portu, od błędu uwierzytelniania, w którym serwer jest osiągalny, ale nie akceptuje podanych poświadczeń.

Metodyka rozpoznania konfliktu konfiguracji

Diagnostykę rozpoczyna się od ustalenia, czy problem dotyczy wszystkich połączeń, tylko jednego loginu, konkretnej aplikacji czy wyłącznie uruchamiania usługi. W Podglądzie zdarzeń warto sprawdzić dzienniki systemowe i aplikacyjne, a w dzienniku SQL Server odszukać komunikaty dotyczące błędów logowania, uruchamiania usługi, uprawnień do plików oraz inicjalizacji protokołów sieciowych. Należy zanotować czas zdarzenia, nazwę instancji, konto wykonujące operację i kod błędu, ponieważ sam komunikat „login failed” nie wskazuje jeszcze, czy przyczyną jest hasło, blokada, brak mapowania loginu do użytkownika bazy czy polityka domenowa.

Stan zasad zastosowanych do komputera można porównać z konfiguracją lokalną przy użyciu narzędzi takich jak gpresult i raport wynikowych zasad grupy. Trzeba uwzględnić kolejność przetwarzania GPO, dziedziczenie z jednostek organizacyjnych oraz ewentualne wymuszenie zasad. Następnie sprawdza się konto usługi, jego prawo „Log on as a service”, status blokady lub wygaśnięcia hasła oraz uprawnienia do katalogów SQL Server. Dla połączeń sieciowych należy zweryfikować nasłuchiwanie właściwego portu, konfigurację SQL Server Configuration Manager i reguły zapory. Zmian nie powinno się wprowadzać przez przypadkowe wyłączanie polityki haseł albo zapory, ponieważ może to jedynie ukryć przyczynę i zmienić poziom bezpieczeństwa całego komputera.