Jak znaleźć przyczynę zablokowanego konta użytkownika w domenie Windows AD

Po niedawnym incydencie z programem Outlook zastanawiałem się, jak najskuteczniej rozwiązać następujący problem:

Załóżmy dość typową małą i średnią infrastrukturę AD: kilka DC, kilka wewnętrznych serwerów i klientów Windows, kilka usług wykorzystujących AD i LDAP do uwierzytelnienia użytkownika z DMZ (przekaźnik SMTP, VPN, Citrix itp.) I kilka wewnętrznych wszystkie usługi polegające na uwierzytelnianiu AD (Exchange, SQL Server, serwery plików i drukowania, serwery usług terminalowych). Masz pełny dostęp do wszystkich systemów, ale jest ich trochę za dużo (licząc klientów), by sprawdzać indywidualnie.

Załóżmy teraz, że z nieznanego powodu jedno (lub więcej) konto użytkownika jest blokowane z powodu zasad blokowania hasła co kilka minut.

• Jaki byłby najlepszy sposób na znalezienie odpowiedzialnego za to serwisu / maszyny?
• Zakładając, że infrastruktura jest czysta, standardowy system Windows bez dodatkowego narzędzia do zarządzania i kilka zmian od domyślnych jest jakiś sposób, aby proces znalezienia przyczyny takiej blokady mógł zostać przyspieszony lub ulepszony?
• Co można zrobić, aby poprawić odporność systemu na taki DOS z blokadą konta? Wyłączenie blokady konta jest oczywistą odpowiedzią, ale potem napotykasz na problem użytkowników mających dostęp do łatwych do wykorzystania haseł, nawet przy wymuszonej złożoności.

Dodanie czegoś, czego nie widzę w podanych odpowiedziach.

Jaki byłby najlepszy sposób na znalezienie odpowiedzialnego za to serwisu / maszyny?

Nie możesz po prostu spojrzeć na dziennik zabezpieczeń na PDCe, ponieważ chociaż PDCe ma najbardziej aktualne informacje dotyczące blokad kont dla całej domeny, nie ma informacji o tym, z którego klienta (IP lub nazwa hosta) nie powiodły się próby logowania, przy założeniu, że nieudane próby logowania miały miejsce na innym kontrolerze DC poza PDCe. PDCe powie, że „Konto xyz zostało zablokowane”, ale nie powie skąd, jeśli nieudane logowanie nastąpiłoby na innym kontrolerze domeny. Tylko kontroler domeny, który faktycznie potwierdził logowanie, zarejestruje niepowodzenie logowania, w tym adres klienta. (Również nie włącza kontrolerów RODC do tej dyskusji.)

Istnieją dwa dobre sposoby, aby dowiedzieć się, skąd pochodzą nieudane próby logowania, gdy masz kilka kontrolerów domeny. Przekazywanie zdarzeń i narzędzia do blokowania kont Microsoft .

Wolę przekazywanie wydarzeń do centralnej lokalizacji. Przekazywanie nieudanych prób logowania ze wszystkich kontrolerów domeny do centralnego serwera rejestrowania. Masz tylko jedno miejsce, w którym możesz szukać nieudanych logowań w całej domenie. W rzeczywistości osobiście nie przepadam za narzędziami do blokowania kont Microsoft, więc teraz jest jeden dobry sposób.

Przekazywanie zdarzeń Pokochasz to.

Zakładając, że infrastruktura jest czysta, standardowy system Windows bez dodatkowego narzędzia do zarządzania i kilka zmian od domyślnych jest jakiś sposób, aby proces znalezienia przyczyny takiej blokady mógł zostać przyspieszony lub ulepszony?

Patrz wyżej. Następnie możesz mieć swój system monitorowania, taki jak SCOM lub Nagios lub cokolwiek, czego używasz, przeczesać ten dziennik pojedynczych zdarzeń i wysadzić swój telefon komórkowy za pomocą wiadomości tekstowych lub cokolwiek innego. Nie ma większego przyspieszenia.

Co można zrobić, aby poprawić odporność systemu na taki DOS z blokadą konta?

1. Edukacja użytkowników. Powiedz im, aby przestali konfigurować usługi Windows do działania na kontach użytkowników domeny, wylogowali się z sesji RDP, gdy będą gotowe, naucz je, jak wyczyścić Windows Credential Vault z buforowanych haseł dla programu Outlook itp.
2. Skorzystaj z zarządzanych kont usług, gdzie możesz, aby użytkownicy nie musieli już zarządzać hasłami do tych kont użytkowników. Użytkownicy psują wszystko. Jeśli dasz użytkownikowi wybór, on lub ona zawsze dokona złego wyboru. Więc nie daj im wyboru.
3. Egzekwowanie limitów czasu sesji zdalnej przez GPO. Jeśli użytkownik jest bezczynny w sesji RDP przez 6 godzin, rozpocznij go.

Mieliśmy ten sam problem podczas czyszczenia kont administratora w większym środowisku jakiś czas temu. Chociaż dzienniki kontroli DCs technicznie dostarczają potrzebnych informacji, postanowiliśmy wdrożyć produkt ADAudit Plus firmy ManageEngine, który skanuje te dzienniki i szuka prób logowania, wraz z wszelkimi zmianami w AD. Korzystając z wbudowanej funkcji raportowania i odrobiny pracy z programem Excel, byliśmy w stanie (dość łatwo) wyśledzić, skąd pochodzą dane logowania. W naszym przypadku było to głównie związane z tym, że administratorzy używali kont administratora zamiast kont usług podczas wdrażania różnych aplikacji.

Co można zrobić, aby poprawić odporność systemu na taki DOS z blokadą konta?

Nie możesz

Istnieje wiele rzeczy, które mogą spalić twój dom. Jak prosty kod, aby wielokrotnie żądać adresów IP, dopóki zakres DHCP nie zostanie wyczerpany. Lub prosty kod, który tworzy katalogi, dopóki MFT nie zostanie zapełniony i trzeba ponownie sformatować partycję, aby ją przywrócić. Nie możesz chronić się przed wszystkim.

Bardziej powszechnym scenariuszem z blokadami są ludzie, którzy wprowadzają swoje dane uwierzytelniające na znacznie szerszej gamie urządzeń niż było to kilka lat temu. Takie jak drukarki (do skanowania e-mailem) lub smartfon lub tablet. Jeśli zapomną, gdzie wprowadzili swoje dane uwierzytelniające lub nie będą już mieli dostępu do urządzenia, możliwe, że urządzenie będzie kontynuować próbę uwierzytelnienia na zawsze. Autoryzacja poczty e-mail to trudny wektor do śledzenia tych urządzeń, a nawet jeśli to zrobisz, użytkownik może nie mieć do niego dostępu lub wiedzieć, gdzie on jest. IP 10.4.5.27? Znam jednego użytkownika, który musiał codziennie dzwonić do działu pomocy technicznej, aby odblokować swoje konto, a następnie natychmiast się zalogował, a następnie jego konto ponownie się zablokowało. Robili to przez miesiące. Powiedziałem im, żeby zmienili nazwę swojego konta.

Życie ma czynniki zniechęcające, nie możemy usunąć wszystkich.