Widok sys.dm_exec_connections z nazwą domeny

sys.dm_exec_connections można łączyć z danymi domenowymi, by ustalić pochodzenie danej sesji.

Widok sys.dm_exec_connections z nazwą domeny jako punkt wyjścia do analizy sesji

Widok sys.dm_exec_connections służy do obserwowania połączeń nawiązywanych z instancją Microsoft SQL Server. Zwracane dane opisują między innymi identyfikator sesji, typ połączenia, adres sieciowy, port, protokół oraz wybrane informacje związane z transportem. Sam widok nie jest katalogiem użytkowników domenowych i zwykle nie zawiera pełnej, czytelnej nazwy domeny Windows. Z tego powodu analiza pochodzenia sesji wymaga połączenia kilku źródeł informacji, a nie ograniczenia się do pojedynczego wiersza.

W praktyce punktem odniesienia jest identyfikator session_id, który pozwala zestawić połączenie z danymi dostępnymi w innych widokach dynamicznego zarządzania. Dzięki temu można przejść od parametrów technicznych połączenia do informacji o zalogowanym kontekście, aktywnym żądaniu, aplikacji lub procesie po stronie systemu. Nazwa domeny może być widoczna w nazwie konta, na przykład w formacie domena\użytkownik, albo wynikać z konfiguracji uwierzytelniania i danych środowiska Windows. Nie należy jednak zakładać, że każdy adres sieciowy lub każdy identyfikator sesji jednoznacznie wskazuje domenę użytkownika.

Do interpretacji wyniku potrzebne jest rozróżnienie pomiędzy połączeniem a sesją. Połączenie opisuje kanał komunikacyjny, natomiast sesja reprezentuje kontekst pracy zalogowanego podmiotu. Jedna sesja może być analizowana razem z informacjami o aktualnym żądaniu, a jedno źródło połączenia może w określonych scenariuszach obsługiwać więcej niż jeden etap pracy. Wnioski powinny więc opierać się na zgodnych identyfikatorach, czasie obserwacji i porównaniu kilku kolumn.

sys.dm_exec_connections z nazwą domeny na tle innych widoków SQL Server

Najważniejsze znaczenie ma zestawienie sys.dm_exec_connections z sys.dm_exec_sessions. Pierwszy widok dostarcza informacji o warstwie połączenia, drugi natomiast opisuje sesję, w tym nazwę logowania, nazwę użytkownika, nazwę aplikacji, nazwę hosta i czas rozpoczęcia pracy. Takie połączenie pozwala sprawdzić, czy połączenie sieciowe pasuje do kontekstu uwierzytelnienia widocznego dla SQL Server. Przykładowy schemat relacji wygląda następująco:

• sys.dm_exec_connections.session_id służy do odszukania odpowiadającego wpisu w sys.dm_exec_sessions;
• login_name może wskazywać konto domenowe albo konto lokalne, zależnie od użytego sposobu logowania;
• host_name i program_name pomagają powiązać sesję z urządzeniem oraz aplikacją, ale nie powinny być traktowane jako dowód tożsamości;
• client_net_address identyfikuje adres po stronie źródłowej, o ile sterownik i sposób zestawienia połączenia udostępniają tę informację;
• connect_time umożliwia porównanie momentu nawiązania połączenia z wpisami dziennika oraz innymi zdarzeniami.

W przypadku analizy wykonywanego polecenia przydatne bywa również połączenie z sys.dm_exec_requests. Ten widok pokazuje bieżące żądania i może pomóc ustalić, co dana sesja robi w chwili pobierania danych. Tekst zapytania można uzyskać przez odpowiednie funkcje systemowe, pamiętając, że dostęp do części informacji zależy od uprawnień. Jeżeli celem jest ustalenie źródła problemu z logowaniem, warto dodatkowo porównać dane z dziennikami SQL Server, Podglądem zdarzeń Windows oraz rejestrem uwierzytelniania.

Widok ten różni się od narzędzi monitorujących użytkowników w czasie rzeczywistym. Nie jest samodzielnym mechanizmem audytu i nie zastępuje trwałego rejestrowania zdarzeń. Wynik zapytania przedstawia stan obserwowany w określonym momencie, dlatego po rozłączeniu sesji część danych może przestać być dostępna. Przy wymaganiu odtworzenia historii potrzebne są wcześniej skonfigurowane mechanizmy audytowe, rejestrowanie zdarzeń logowania lub kontrola po stronie systemu operacyjnego.

Typowe problemy przy odczycie sys.dm_exec_connections i domeny

Jednym z częstszych problemów jest brak pełnej nazwy domeny wprost w sys.dm_exec_connections. Jest to naturalne, ponieważ widok został przeznaczony do opisu połączeń, a nie do prezentowania całej hierarchii tożsamości Windows. Nazwa domeny może znajdować się w login_name, lecz przy logowaniu za pomocą konta SQL Server pojawi się nazwa niezależna od domeny. Przy połączeniu pośredniczącym, usłudze aplikacyjnej lub puli połączeń widoczne może być konto techniczne, a nie osoba inicjująca działanie.

Drugą trudnością jest wartość client_net_address. W zależności od protokołu, konfiguracji sieci, translacji adresów oraz sposobu obsługi połączenia może ona być pusta, lokalna albo wskazywać adres pośredni. Adres IP nie zawiera nazwy domeny i nie powinien być automatycznie zamieniany na nazwę komputera bez dodatkowego sprawdzenia. Odwrotne rozpoznawanie DNS może zwrócić nazwę nieaktualną, wieloznaczną albo niedostępną w chwili wykonywania zapytania.

Trzeci problem wynika z uprawnień. Bez odpowiednich praw część kolumn lub szczegółów może być ograniczona. Wtedy niepełny rezultat nie musi oznaczać błędu w zapytaniu. Należy sprawdzić wersję SQL Server, zastosowany model uprawnień i zakres widoczności metadanych. Istotne jest również rozpoznanie, czy analizowana sesja nadal istnieje. Zapytanie wykonane kilka minut później może nie pokazać połączenia, które zakończyło pracę, nawet jeśli zdarzenie było istotne.

Warto uważać także na różnice między nazwą logowania, nazwą użytkownika bazy danych, nazwą hosta i nazwą domeny. Są to różne pojęcia. Konto może mieć dostęp do kilku baz, użytkownik bazy może być mapowaniem logowania, a nazwa komputera może zostać zmieniona niezależnie od konta. Zestawienie tych pól bez uwzględnienia ich znaczenia prowadzi do błędnych wniosków dotyczących pochodzenia sesji.

Praktyczne wskazówki dla sys.dm_exec_connections z nazwą domeny

Analizę najlepiej rozpocząć od zapisania czasu wykonania oraz zakresu obserwacji. Następnie należy pobrać identyfikatory sesji i połączyć je z widokiem sesji, zachowując wyłącznie kolumny potrzebne do rozpoznania kontekstu. Przydatne jest filtrowanie po nazwie bazy, aplikacji, hosta lub adresie, ale filtry powinny być stosowane ostrożnie. Zbyt wąskie kryterium może ukryć połączenie, które używa innej nazwy programu albo adresu pośredniczącego.

W zapytaniu kontrolnym można uwzględnić między innymi:

• identyfikator sesji i identyfikator połączenia;
• czas nawiązania połączenia;
• nazwę logowania i nazwę użytkownika sesji;
• nazwę hosta oraz aplikacji;
• adres po stronie źródłowej, port i protokół;
• stan sesji oraz ostatnie znane żądanie.

Przed interpretacją warto wykonać kilka obserwacji w odstępach czasu i porównać ich wyniki. Pozwala to oddzielić stałe cechy środowiska od danych zmiennych, takich jak port źródłowy, identyfikator sesji czy aktualnie wykonywane żądanie. Jeżeli potrzebne jest potwierdzenie domeny, należy porównać nazwę logowania z informacjami z systemu Windows i zasadami uwierzytelniania. W razie rozbieżności sprawdza się konfigurację sterownika, sposób korzystania z połączeń oraz to, czy aplikacja nie używa wspólnego konta.

Nie zaleca się zapisywania pełnych wyników bez kontroli dostępu, ponieważ mogą zawierać nazwy kont, hostów i aplikacji. Do dokumentacji wystarczy zwykle ograniczony zestaw kolumn, czas obserwacji oraz opis zastosowanych filtrów. Dobrą praktyką jest również rozdzielenie danych identyfikacyjnych od danych dotyczących treści zapytań. Ułatwia to późniejszą analizę i zmniejsza ryzyko ujawnienia informacji, które nie są potrzebne do rozwiązania problemu.

Kiedy zgłosić się do serwisu z analizą sys.dm_exec_connections

Wsparcie techniczne może być potrzebne wtedy, gdy wynik sys.dm_exec_connections nie zgadza się z nazwą konta, adresem urządzenia lub oczekiwanym sposobem logowania. Dotyczy to zwłaszcza sytuacji, w których pojawiają się nieznane sesje, częste rozłączenia, problemy z dostępem do bazy albo różne nazwy domenowe zależnie od używanej aplikacji. Przed przekazaniem danych warto zanotować przybliżony czas zdarzenia, nazwę bazy, komunikat błędu oraz wynik ograniczony do niezbędnych kolumn.

W Warszawie takie sprawy można przekazać do firmy Warszawskie Pogotowie Komputerowe 24/7, która zajmuje się diagnostyką problemów związanych z komputerami, systemem Windows, siecią oraz oprogramowaniem używanym do pracy z bazami danych. Podczas zgłoszenia przydatne będzie określenie, czy chodzi o brak nazwy domeny, błędne powiązanie sesji z hostem, trudność z uwierzytelnieniem, czy też potrzebę uporządkowania sposobu zbierania logów. Pozwala to dobrać zakres analizy do rzeczywistego problemu i uniknąć wnioskowania wyłącznie na podstawie jednego odczytu.

Jeżeli połączenie zostało już zamknięte, bieżący widok może nie wystarczyć do odtworzenia zdarzenia. W takiej sytuacji analizuje się dostępne dzienniki, konfigurację SQL Server, ustawienia systemu Windows i sposób działania aplikacji. Dopiero porównanie tych źródeł umożliwia wiarygodne ustalenie, czy nazwa domeny pochodzi z konta logowania, urządzenia, konfiguracji sieciowej, czy z warstwy pośredniej obsługującej połączenie.