Identyfikator SID Windows w sys.dm_exec_sessions pozwala powiązać sesję z konkretnym kontem domenowym.
Co oznacza SID w widoku sys.dm_exec_sessions
sys.dm_exec_sessions jest widokiem dynamicznym aparatu Microsoft SQL Server i pokazuje informacje o sesjach ustanowionych z instancją. Sesja powstaje po nawiązaniu połączenia klienta z SQL Serverem, a jej rekord może zawierać między innymi identyfikator sesji session_id, nazwę logowania login_name, nazwę komputera klienta, aplikację, stan połączenia oraz dane związane z uwierzytelnianiem Windows. Kolumna security_id przechowuje identyfikator bezpieczeństwa systemu Windows przypisany do logowania, którego używa dana sesja.
SID, czyli Security Identifier, nie jest zwykłą nazwą użytkownika. Windows nadaje go kontu lokalnemu, kontu domenowemu albo grupie i zachowuje jego tożsamość nawet wtedy, gdy nazwa obiektu zostanie zmieniona. W środowisku domenowym SID zawiera identyfikator domeny oraz względny identyfikator konkretnego obiektu. Dzięki temu SQL Server może rozpoznać konto na podstawie jego identyfikatora, a nie wyłącznie na podstawie tekstu widocznego w kolumnie login_name. Wartość jest zwracana jako typ binarny, dlatego nie należy traktować jej jak zwykłego tekstu ani porównywać z nazwą konta bez odpowiedniej konwersji.
Powiązanie sesji z loginem i obiektami Windows
W praktycznej analizie rekord z sys.dm_exec_sessions warto odczytywać razem z kolumnami login_name, original_login_name, nt_domain oraz nt_user_name. login_name wskazuje login rozpoznany przez SQL Server w bieżącym kontekście, natomiast original_login_name pomaga ustalić pierwotne konto użyte do utworzenia sesji, gdy później zastosowano zmianę kontekstu bezpieczeństwa. Kolumny nt_domain i nt_user_name opisują dane konta Windows przekazane podczas logowania, o ile sesja korzysta z uwierzytelniania Windows.
SID sesji można zestawiać z SID-em logina w widoku katalogowym sys.server_principals. W tym widoku kolumna sid również ma typ binarny i identyfikuje główny obiekt bezpieczeństwa na poziomie instancji. Takie porównanie pozwala wykryć sytuacje, w których sama nazwa logowania jest myląca albo nie wystarcza do jednoznacznej identyfikacji konta. Funkcje SUSER_SNAME i SUSER_SID mogą służyć do konwersji między SID-em a nazwą logowania, ale wynik należy interpretować w kontekście konkretnej instancji SQL Server, jej logów oraz aktualnego katalogu domenowego.
Jak interpretować różnice między SID-em a nazwą konta
Różnica między nazwą konta a SID-em ma znaczenie podczas diagnostyki dostępu. Jeśli konto domenowe zostanie usunięte i utworzone ponownie pod taką samą nazwą, nowy obiekt otrzyma inny SID. SQL Server może wtedy posiadać login wskazujący na stary SID, mimo że tekstowa nazwa wygląda znajomo. Podobny problem występuje po migracji domeny, odtwarzaniu konfiguracji na innej instancji albo ręcznym tworzeniu loginów Windows. Sprawdzenie wartości binarnych pozwala odróżnić identycznie nazwane, lecz różne obiekty bezpieczeństwa.
SID z widoku sesji nie opisuje samodzielnie wszystkich uprawnień użytkownika. Uprawnienia zależą od loginu serwerowego, członkostwa w rolach serwerowych, użytkownika bazodanowego, członkostwa w rolach bazowych oraz ewentualnego przełączania kontekstu. Do pełnej analizy trzeba więc połączyć dane sesji z sys.server_principals, odpowiednim sys.database_principals i informacjami o rolach. Sam fakt, że security_id odpowiada danemu SID-owi, potwierdza tożsamość obiektu użytego przez sesję, ale nie stanowi jeszcze dowodu, że konkretna operacja będzie dozwolona.
Kontrola sesji podczas diagnostyki SQL Server
Analiza SID-u jest przydatna przy badaniu nieoczekiwanych połączeń, błędów autoryzacji, dostępu przyznanego niewłaściwemu kontu oraz rozbieżności między konfiguracją domeny a konfiguracją instancji. Warto zapisać czas obserwacji, session_id, login_name, original_login_name, security_id, nazwę hosta i programu klienckiego. Zestawienie tych wartości z dziennikiem SQL Server, śladem audytowym oraz informacjami z systemu Windows ułatwia ustalenie, czy połączenie pochodziło od właściwego użytkownika, usługi lub zadania automatycznego.
Dostęp do danych z widoków dynamicznych jest kontrolowany uprawnieniami instancji. W starszych wersjach SQL Server odczyt informacji o wszystkich sesjach zwykle wymaga uprawnienia VIEW SERVER STATE. W SQL Server 2022 i nowszych wymagania dla części widoków wydajnościowych obejmują VIEW SERVER PERFORMANCE STATE, dlatego uprawnienia należy sprawdzić dla dokładnie używanej wersji silnika. Podczas diagnostyki trzeba też uwzględnić, że sesje systemowe, połączenia wewnętrzne i sesje zakończone mogą być prezentowane inaczej niż aktywne połączenia użytkowników. SID powinien być zatem jednym z elementów korelacji danych, a nie jedyną podstawą wniosku o źródle problemu.
