Łączenie z SQL Server z kont AD przez VPN

Łączenie z SQL Server kontem AD przez VPN wymaga, by klient miał dostęp do kontrolera domeny, inaczej uwierzytelnianie Kerberos zawiedzie.

Łączenie z SQL Server z kont AD przez VPN — czym jest

Łączenie z SQL Server z kont AD przez VPN oznacza pracę aplikacji klienckiej z bazą danych znajdującą się w sieci firmowej, gdy użytkownik korzysta z poświadczeń domenowych, a dostęp do tej sieci jest uzyskiwany przez tunel VPN. W takim układzie nie wystarcza samo zestawienie połączenia z adresem serwera SQL. Musi zostać zachowana spójność kilku elementów: trasy sieciowej, rozpoznawania nazw, dostępu do usług domenowych, poprawnego czasu systemowego, konfiguracji sterownika oraz uprawnień przypisanych do konta lub grupy w domenie.

Uwierzytelnianie kontem Active Directory może przebiegać z wykorzystaniem Kerberos, a w niektórych konfiguracjach także mechanizmów negocjowanych przez system Windows. Kerberos nie jest jednak zwykłym logowaniem hasłem przesyłanym do SQL Server. Komputer i użytkownik muszą mieć możliwość odnalezienia właściwych usług domenowych, uzyskania biletu uwierzytelniającego oraz przedstawienia go usłudze SQL. Jeżeli VPN zapewnia wyłącznie dostęp do pojedynczego adresu IP, bez dostępu do kontrolera domeny i wymaganych usług DNS, logowanie zintegrowane może zakończyć się błędem mimo prawidłowego hasła.

W praktyce rozdziela się trzy warstwy diagnostyczne. Pierwsza dotyczy samego VPN i ustalenia, czy komputer otrzymał właściwe trasy oraz czy może komunikować się z zasobami wewnętrznymi. Druga obejmuje domenę Active Directory, czyli odnajdywanie kontrolera, synchronizację czasu i pobieranie biletów. Trzecia odnosi się do SQL Server: nazwy instancji, portu, protokołu, certyfikatu, sterownika oraz uprawnień użytkownika. Takie rozdzielenie pozwala uniknąć sytuacji, w której problem sieciowy jest mylony z brakiem uprawnień do bazy.

Łączenie z SQL Server z kont AD przez VPN a Kerberos i NTLM

Najważniejsza różnica między Kerberos a NTLM dotyczy sposobu potwierdzania tożsamości. Kerberos wykorzystuje bilety wydawane przez usługę domenową i wymaga poprawnej identyfikacji usługi SQL Server. Dla połączenia istotna jest nazwa, pod którą klient dociera do SQL Server, ponieważ na jej podstawie może być wyszukiwany identyfikator usługi. Gdy używana jest nazwa niezgodna z konfiguracją, alias bez właściwego wpisu albo adres IP zamiast nazwy hosta, może dojść do przejścia na inny mechanizm lub całkowitego odrzucenia logowania.

NTLM bywa tolerancyjny wobec części nieprawidłowości, ale nie powinien być traktowany jako uniwersalne obejście. Dostęp przez VPN może działać na jednym komputerze, a nie działać na innym, ponieważ każdy z nich może mieć inny stan biletu, inny DNS, inną trasę albo odmienne zasady bezpieczeństwa. Warto również pamiętać, że po zmianie połączenia sieciowego wcześniej pobrane bilety mogą nie odpowiadać bieżącej ścieżce dostępu. Rozłączenie i ponowne zestawienie VPN, a następnie ponowne uwierzytelnienie, może ujawnić, czy problem wynikał ze starego kontekstu sesji.

Istotną rolę odgrywa czas. Kerberos dopuszcza tylko ograniczoną różnicę czasu między komputerem użytkownika, kontrolerem domeny i hostem SQL Server. Zegar ustawiony ręcznie, niewłaściwa strefa czasowa lub opóźniona synchronizacja mogą więc powodować komunikaty sugerujące błąd hasła, chociaż dane logowania są prawidłowe. Kontroluje się także, czy klient korzysta z domenowego DNS. Publiczny DNS może rozwiązać nazwę witryny internetowej, lecz nie musi znać rekordów potrzebnych do odnajdywania usług domenowych.

Ważne jest też odróżnienie uwierzytelniania od autoryzacji. Udane zalogowanie kontem domenowym nie oznacza automatycznie dostępu do konkretnej bazy, schematu lub tabeli. Konto może być rozpoznane, ale nie mieć przypisanego użytkownika w bazie albo należeć do grupy bez odpowiednich ról. Z kolei komunikat o braku instancji, niedostępnym hoście lub przekroczonym czasie oczekiwania zwykle kieruje diagnostykę najpierw w stronę sieci i konfiguracji klienta.

Łączenie z SQL Server z kont AD przez VPN — typowe problemy

Jednym z częstych problemów jest częściowo zestawiony tunel. VPN może sygnalizować poprawne połączenie, lecz przekazywać tylko ruch do wybranych podsieci. Wtedy aplikacja może widzieć adres SQL Server, ale nie może skontaktować się z kontrolerem domeny, usługą DNS albo innym składnikiem potrzebnym do uwierzytelnienia. Podobny efekt występuje, gdy trasy z VPN są nadpisywane przez lokalną sieć Wi-Fi albo gdy aktywny jest drugi interfejs z priorytetem wyższym niż interfejs tunelowany.

Drugi typ błędu dotyczy nazw. Połączenie zapisane jako nazwa skrócona, pełna nazwa DNS, alias lokalny i adres IP nie musi być równoważne z punktu widzenia uwierzytelniania. Nazwa może rozwiązywać się do niewłaściwego hosta, wskazywać nieaktualny adres albo omijać konfigurację potrzebną do uzyskania biletu dla usługi. Przy instancjach nazwanych dochodzi dodatkowo kwestia odnalezienia właściwego portu. Jeżeli ruch do usługi pomocniczej jest blokowany, można mieć wrażenie, że SQL Server jest niedostępny, choć sam host odpowiada.

Trzeci problem stanowią sterowniki i biblioteki używane przez aplikację. Starszy sterownik może nie obsługiwać wymaganej metody szyfrowania, nie rozpoznawać aktualnego wariantu uwierzytelniania albo zwracać ogólny komunikat, który nie wskazuje prawdziwej przyczyny. Warto sprawdzić, czy aplikacja korzysta z tego samego dostawcy połączenia co narzędzie testowe. Połączenie działające w jednym programie nie zawsze dowodzi, że identyczna konfiguracja jest używana w drugim.

Problemy mogą także wynikać z zasad bezpieczeństwa. Blokada logowania interaktywnego, ograniczenia dotyczące delegowania poświadczeń, wymaganie szyfrowania lub niezgodność certyfikatu mogą pojawić się dopiero po aktualizacji systemu albo zmianie polityki domenowej. Nie powinno się wyłączać zabezpieczeń bez ustalenia, które ustawienie powoduje błąd. Tymczasowe złagodzenie polityki może ukryć przyczynę i utrudnić późniejsze przywrócenie bezpiecznej konfiguracji.

Łączenie z SQL Server z kont AD przez VPN — praktyczne wskazówki diagnostyczne

Diagnostykę rozpoczyna się od zapisania dokładnego komunikatu i momentu wystąpienia błędu. Inne znaczenie ma odmowa logowania po kilku sekundach, a inne brak odpowiedzi podczas nawiązywania połączenia. Następnie sprawdza się, czy VPN jest aktywny przed uruchomieniem aplikacji oraz czy po zestawieniu tunelu zmieniły się trasy i serwery DNS. Pomocne jest porównanie działania po nazwie hosta oraz po adresie IP, ale wynik takiego porównania należy interpretować ostrożnie, ponieważ adres IP może ominąć mechanizmy wymagane przez Kerberos.

Warto potwierdzić, że komputer jest zalogowany do właściwej domeny i że konto nie jest zablokowane, wygasłe lub pozbawione wymaganych praw. Sprawdza się również synchronizację czasu oraz możliwość odnalezienia kontrolera domeny przez DNS. Jeżeli problem pojawił się po zmianie hasła, zmianie sieci lub wznowieniu pracy ze stanu uśpienia, ponowne uwierzytelnienie użytkownika może być ważnym testem. Nie należy jednak wielokrotnie usuwać profilu użytkownika ani zmieniać konfiguracji domeny bez kopii ustawień i bez zapisania wcześniejszych wyników.

Po stronie SQL Server weryfikuje się, czy usługa działa, czy nasłuchuje na oczekiwanym porcie i czy zapora dopuszcza ruch z puli adresów używanej przez VPN. Dla instancji nazwanej trzeba ustalić, w jaki sposób klient poznaje port. Dla połączeń szyfrowanych sprawdza się nazwę certyfikatu, zaufanie do urzędu certyfikacji oraz zgodność nazwy użytej przez aplikację z nazwą certyfikatu. Każda zmiana powinna być testowana osobno, ponieważ równoczesna modyfikacja DNS, zapory, sterownika i uprawnień utrudnia wskazanie przyczyny.

Bezpieczną praktyką jest zebranie informacji bez ujawniania haseł i pełnych danych wrażliwych: wersji systemu, wersji sterownika, rodzaju klienta VPN, użytej nazwy hosta, czasu wystąpienia błędu i ogólnej treści komunikatu. Logi mogą zawierać identyfikatory użytkowników, nazwy komputerów oraz adresy wewnętrzne, dlatego powinny być przekazywane wyłącznie uprawnionym osobom. Testy wykonuje się na koncie, którego użycie jest dozwolone, bez pożyczania cudzych poświadczeń i bez zapisywania hasła w plikach konfiguracyjnych.

Łączenie z SQL Server z kont AD przez VPN — kiedy zgłosić się do serwisu

Do serwisu warto zgłosić się wtedy, gdy połączenie działa tylko sporadycznie, zawodzi po zmianie sieci, powoduje blokowanie konta albo wymaga każdorazowego ręcznego czyszczenia ustawień. Pomocna jest również konsultacja, gdy kilka aplikacji pokazuje różne komunikaty lub gdy nie ma pewności, czy źródłem problemu jest komputer użytkownika, konfiguracja VPN, DNS, domena czy sam SQL Server. W ramach przygotowania należy zanotować, od kiedy występuje usterka, czy dotyczy jednego użytkownika oraz jakie zmiany poprzedziły jej pojawienie się.

Warszawskie Pogotowie Komputerowe 24/7 wykonuje naprawy z reguły do 3 dni roboczych. Przy przekazywaniu sprzętu można opisać, czy problem występuje wyłącznie podczas pracy poza biurem, czy także w sieci lokalnej. Takie informacje ułatwiają odtworzenie warunków i ograniczenie diagnostyki do właściwego obszaru. Nie zaleca się samodzielnego wyłączania zapory, zabezpieczeń uwierzytelniania ani zasad domenowych tylko po to, aby uzyskać chwilowy dostęp do bazy.