Znaleźliśmy konto administratora domeny - z którego nie korzystamy, z wyjątkiem scenariusza odzyskiwania po awarii - ma ostatnią datę w atrybucie LastLogonTimeStamp. O ile mi wiadomo, nikt nie powinien korzystać z tego konta w danym okresie (i kilka miesięcy później), ale być może jakiś idiota skonfigurował go do uruchomienia zaplanowanego zadania.
Ze względu na liczbę zdarzeń w dzienniku bezpieczeństwa (i brak narzędzia SIEM do analizy) chciałem ustalić, który kontroler domeny ma rzeczywisty czas ostatniego logowania (tj. Nie replikowany atrybut) dla konta, ale sprawdziłem każdy kontroler domeny w domenie, i każdy z nich ma ostatni znak „none” dla Administratora.
Jest to domena podrzędna w lesie, więc możliwe, że ktoś użył tego konta administratora domeny podrzędnej, aby uruchomić coś w domenie nadrzędnej.
Czy ktoś może pomyśleć o sposobie ustalenia, który kontroler domeny dokonuje logowania, oprócz zbadania potencjalnych 20 milionów zdarzeń z 16 kontrolerów lasu w czasie zarejestrowanym w LastLogonTimestamp? Przypuszczam, że mógłbym najpierw skierować do kontrolerów domeny domeny nadrzędnej (ponieważ wydaje się, że potomki kontrolerów domeny nie wykonały autoryzacji).
Wyjaśnienie
[Dodano po wyzerowaniu przyczyny po użyciu repadminzgodnie z poniższym opisem]
Pierwotna przyczyna tego żądania była spowodowana przez nasz zespół ds. Bezpieczeństwa IT, który zastanawiał się, dlaczego najwyraźniej często logujemy się przy użyciu domyślnego konta administratora domeny.
Wiedzieliśmy, że NIE logowaliśmy się. Okazuje się, że istnieje mechanizm o nazwie „Kerberos S4u2Self”, który polega na tym, że proces wywołujący działający jako System lokalny dokonuje pewnej eskalacji uprawnień. Wykonuje logowanie sieciowe (nie interaktywne) jako Administrator na kontrolerze domeny. Ponieważ nie jest interaktywny, dlatego nie ma lastLogonkonta na żadnym kontrolerze domeny (to konto nigdy nie było zalogowane na żadnym bieżącym kontrolerze domeny).
W tym artykule wyjaśniono, dlaczego narzędzie pinguje dzienniki i sprawia, że zespół bezpieczeństwa ma kocięta (maszyny źródłowe to Server 2003, co gorsza). I jak to wyśledzić. https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/
Wyciągnięte wnioski - dostarczaj raporty o lastLogonatrybutach zespołom ds. Bezpieczeństwa IT tylko wtedy, gdy dotyczy to logowania administratora.