Obiekty użytkowników Active Directory posiadają kilka atrybutów metadanych logowania, które są często wykorzystywane w raportach audytowych i administracji. Jednym z ich najczęstszych zastosowań jest identyfikacja kont użytkowników, które były nieaktywne przez dłuższy czas,

Jednak każdy z tych atrybutów metadanych logowania ma pewne unikalne zachowania, które należy zrozumieć. W przeciwnym razie użycie tych atrybutów może skutkować raportowaniem, które w najlepszym wypadku jest mylące, a w najgorszym niedokładne lub wprowadzające w błąd. To zagadnienie opisał Michael Olig na blogu Stealthbits, a dziś mu się przyjrzymy.


Atrybut Last-Logon

Atrybut „Last-Logon” zawiera reprezentację Windows FileTime ostatniego pomyślnego uwierzytelnienia użytkownika przez kontroler domeny. Jest to najstarszy atrybut metadanych logowania użytkownika i istnieje od pierwszej wersji Active Directory.

Atrybut „Last-Logon” jest aktualizowany za każdym razem, gdy kontroler domeny pomyślnie przetwarza żądanie logowania. Chociaż atrybut ten wydaje się być doskonałym sposobem na dokładną identyfikację nieaktualnych kont użytkowników, istnieje duże zastrzeżenie, które należy wziąć pod uwagę.

„Last-Logon” nie jest atrybutem replikowanym; każdy kontroler domeny utrzymuje własną wersję tego atrybutu dla konkretnego użytkownika. Takie zachowanie jest celowe – wzrost ruchu replikowanego, niezbędnego do utrzymania tego atrybutu w synchronizacji pomiędzy kontrolerami domeny w sieci byłby przytłaczający, zwłaszcza w momencie jego wprowadzenia dwadzieścia lat temu. Jest też powodem, dla którego należy zachować ostrożność przy używaniu tego atrybutu do raportowania nieaktualnych kont użytkowników.

Ponieważ atrybut „Last-Logon” nie jest replikowany, jego wartość może być interpretowana tylko w kontekście kontrolera domeny, który jest odpytywany. Wartość atrybutu niekoniecznie jest ostatnim logowaniem użytkownika, ale raczej ostatnim logowaniem użytkownika przez określony kontroler domeny. Podobnie, atrybut o wartości zero (NULL) nie musi oznaczać, że użytkownik nigdy się nie logował; może to oznaczać, że kontroler domeny, który zwrócił wartość, nigdy nie przetworzył żądania logowania od tego użytkownika (aby się upewnić, trzeba by sprawdzić pozostałe kontrolery domeny).

Chociaż atrybut Last-Logon może być używany do audytu związanego z logowaniem, dokładne raportowanie będzie wymagało odpytywania każdego kontrolera domeny zdolnego do przetwarzania żądań logowania w celu zidentyfikowania jego ostatnio zaktualizowanej wartości dla konkretnego konta użytkownika.


Atrybut Last-Logon-Timestamp

„Last-Logon-Timestamp” zawiera reprezentację Windows FileTime ostatniego logowania użytkownika do domeny. Atrybut ten został wprowadzony wraz z systemem Windows Server 2003. W przeciwieństwie do atrybutu „Last-Logon”, atrybut „Last-Logon-Timestamp” jest atrybutem replikowanym; jego wartość dla każdego konkretnego użytkownika jest synchronizowana z każdym kontrolerem domeny.

Problem z atrybutem „Last-Logon-Timestamp” polega na tym, że nie jest on zawsze aktualizowany, gdy kontroler domeny pomyślnie przetwarza żądanie logowania. Zamiast tego atrybut ten ma dynamiczną częstotliwość aktualizacji, która jest ograniczona przez wartość atrybutu ms-DS-Logon-Time-Sync-Interval, który domyślnie ma wartość NOT SET i jest traktowany jako 14 dni. Nieczęsto zdarza się, aby ten atrybut był zmieniany, ale jeśli jesteś ciekawy, możesz łatwo zidentyfikować jego rzeczywistą wartość za pomocą PowerShell:

Źródłó: Stealthbits Blog

W domenie z domyślnym limitem aktualizacji wynoszącym 14 dni, atrybut „Last-Logon-Timestamp” jest aktualizowany tylko wtedy, gdy kontroler domeny pomyślnie przetwarza żądanie logowania, a okres od ostatniej aktualizacji atrybutu jest większy od 9 aż do 14 dni. Zmienność tego okresu jest wynikiem losowego udziału procentowego, który jest uwzględniony w logice sterującej częstotliwością aktualizacji. To zachowanie odzwierciedla kompromis, który został osiągnięty w celu ograniczenia ruchu replikującego niezbędnego do utrzymania tego atrybutu w synchronizacji pomiędzy kontrolerami domeny w sieci. Losowość tego rozwiązania służy dalszemu ograniczeniu prawdopodobieństwa konieczności powielania znacznej liczby użytkowników, którzy mieli swój „Last-Logon-Timestamp” zaktualizowany w tym samym czasie.

Poniżej znajduje się uproszczony przykład logiki, która steruje częstotliwością aktualizacji atrybutu Last-Logon-Timestamp:

(Current Datetime – Last-Logon-Timestamp) ≥ (ms-DS-Logon-Time-Sync-Interval – (Random % * 5 days))

W praktyce atrybut „Last-Logon-Timestamp” uprości audyt i raportowanie związane z logowaniem. Jedyny potencjalny problem wiąże się z raportowaniem nieaktywnych użytkowników. W przypadku stosowania do identyfikacji nieaktywnych użytkowników próg “nieaktywności” musi przekraczać wartość „ms-DS-Logon-Time-Sync-Interval” domeny o wystarczającą ilość czasu, aby replikacja zdążyła rozprzestrzenić jakiekolwiek znaczące aktualizacje.


LastLogonDate (PowerShell)

Osoby zaznajomione z PowerShell mogą rozpoznać LastLogonDate, ale nie będą w stanie znaleźć go nigdzie w schemacie Active Directory. Dzieje się tak dlatego, że LastLogonDate jest tak naprawdę lokalnie obliczaną wartością, która wyświetla zreplikowaną wartość atrybutu Last-Logon-Timestamp w “przyjaznym” formacie. Nic dziwnego, że LastLogonDate ma wszystkie zalety i wszystkie wady (wymaga konwersji z Windows DateTime) atrybutu Last-Logon-Timestamp, co sprawia, że jest to najlepsza opcja dla większości raportów audytowych związanych z logowaniem użytkowników.


ms-DS-Last-Successful-Interactive-Logon-Time

Kolejny atrybut „ms-DS-Last-Successful-Interactive-Logon-Time” został wprowadzony w systemie Windows Server 2008, ale wiele osób nie wie, jak go używać, ponieważ jest domyślnie wyłączony. Atrybut ten (gdy jest włączony) zawiera datę i godzinę ostatniego udanego interaktywnego logowania użytkownika. Chociaż wydaje się, że włączenie tego atrybutu jest niezwykle przydatne, prawdopodobnie będziemy mieli problem ze znalezieniem domeny, która to zrobiła.

Istnieje kilka istotnych powodów, które sprawiają, że funkcja ta pozostaje wyłączona, o czym za chwilę. W środowisku laboratoryjnym polecamy sprawdzić atrybut ms-DS-Last-Successful-Interactive-Logon-Time, poprzez włączenie ustawienia Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Logon Options → Display information about previous logons during user logon GPO i wymuś pewne aktualizacje Group Policy.
UWAGA! Nie włączajcie tego ustawienia w domenie produkcyjnej bez uprzedniego przetestowania, bo mogą pojawić się problemy.

Pierwszym problemem związanym z atrybutem „ms-DS-Last-Successful-Interactive-Logon-Time” jest to, że jego wartość jest aktualizowana tylko wtedy, gdy logowanie interaktywne zostanie uwierzytelnione (myślimy o logowaniach typu “Ctrl-Alt-Del”). Oznacza to, że ważne czynności uwierzytelniania, takie jak logowanie do udziału w sieci i uwierzytelnianie LDAP, nie spowodują aktualizacji. Jeśli spróbujesz użyć atrybutu ms-DS-Last-Successful-Interactive-Logon-Time do wygenerowania raportów audytu związanych z logowaniem, prawdopodobnie uzyskasz potencjalnie niepełne wyniki. Na przykład, raporty identyfikujące nieaktywne konta użytkowników będą prawdopodobnie niedokładnie uwzględniać konta usług domeny, które są bardzo aktywne, a logują się w sposób nieinteraktywny.

Do drugiego problemu z atrybutem „ms-DS-Last-Successful-Interactive-Logon-Time” nawiązuje nazwa ustawienia GPO, które umożliwia takie zachowanie: “Display information about previous logons during user logon” (Wyświetl informacje o poprzednich logowaniach podczas logowania użytkownika). Gdy to ustawienie jest włączone, za każdym razem, gdy użytkownik loguje się w sesji interaktywnej (tj. za każdym razem, gdy loguje się na komputerze połączonym z domeną), zostanie mu wyświetlony komunikat zawierający datę i godzinę ostatniego udanego logowania, datę i godzinę ostatniego nieudanego logowania oraz liczbę nieudanych logowań, które miały miejsce od ostatniego udanego logowania. Tego komunikatu nie można wyłączyć i musi on zostać potwierdzony, zanim pojawi się pulpit użytkownika. Będzie to powodowało, że sporo użytkowników końcowych będzie bez końca narzekać, że jest to ogromna niedogodność, która znacząco i negatywnie wpłynęła na ich ogólną wydajność.

Włączenie tego ustawienia sprawia, że raportowanie o nieaktualnych użytkownikach jest naprawdę proste i niezawodne, ale tylko w przypadku kont użytkowników, które są używane do sesji interaktywnych. Dodatkowo, koszty związane z tym “łatwym przyciskiem” do audytowania logowania to znaczny wzrost ruchu w replikacji Active Directory oraz, co ważniejsze, skargi użytkowników końcowych, którzy są zirytowani nowym kliknięciem w procesie logowania.


Podsumowanie

Generując raporty z audytu logowania do Active Directory, najlepszym rozwiązaniem jest prawdopodobnie zebranie logów zdarzeń kontrolera domeny i przetworzenie ich. Choć dzienniki zdarzeń są niezwykle zapełnione, są również wiarygodne i dostarczają informacji historycznych, których Active Directory nie posiada.

Jeśli nie jest to możliwe, użyj LastLogonDate. Albo, jeszcze lepiej, użyj cmdlet’a „Search-ADAccount” wbudowanego w moduł ActiveDirectory PowerShell:

Search-ADAccount -AccountInactive -DateTime ((Get-Date).AddDays(-30)) -UsersOnly

Polecenie Search-ADAccount w rzeczywistości wykorzystuje za kulisami LastLogonDate. Domyślnie okres nieaktywności wynosi 15 dni, co powinno być wystarczające w większości środowisk. Powyższy przykład zawiera składnię potrzebną do zastąpienia okresu nieaktywności wartością 30 dni.

Podziel się z innymi tym artykułem!