Prawidłowo wskazane secpol.msc to lokalne zasady zabezpieczeń systemu Windows, czyli narzędzie, w którym faktycznie definiuje się politykę haseł dla kont użytkowników. W praktyce, po uruchomieniu secpol.msc (Win+R → secpol.msc) przechodzisz do „Zasady konta” → „Zasady haseł” i tam ustawiasz takie parametry jak minimalna długość hasła, wymuszanie złożoności (małe/duże litery, cyfry, znaki specjalne), maksymalny okres ważności hasła, historia haseł czy blokada możliwości użycia poprzednich haseł. To są dokładnie te ustawienia, które w firmach są podstawą dobrych praktyk bezpieczeństwa. W środowisku domenowym podobne zasady ustawia się zwykle w GPO na kontrolerze domeny, ale lokalnie na pojedynczej stacji roboczej właśnie przez secpol.msc. Moim zdaniem warto kojarzyć, że secpol.msc dotyczy szerzej lokalnej polityki bezpieczeństwa: nie tylko haseł, ale też np. zasad blokady konta, ustawień UAC, ograniczeń dotyczących logowania, audytu zdarzeń bezpieczeństwa. W wielu małych firmach, gdzie nie ma domeny, to jest główne narzędzie do ustandaryzowania zabezpieczeń na komputerach użytkowników. Z punktu widzenia dobrych praktyk (np. wytyczne CIS Benchmarks czy ogólne zalecenia bezpieczeństwa Microsoftu) definiowanie silnej polityki haseł w secpol.msc to absolutna podstawa – szczególnie wymuszanie złożoności, minimalnej długości oraz okresowej zmiany hasła. W realnej administracji systemami Windows to jedno z pierwszych miejsc, które sprawdza się podczas audytu bezpieczeństwa stacji roboczej lub serwera.
W tym pytaniu łatwo pomylić różne narzędzia MMC, bo wszystkie wyglądają podobnie z zewnątrz, ale każde służy do zupełnie innych zadań administracyjnych. Sedno sprawy jest takie, że polityka haseł użytkowników w Windows jest elementem lokalnej lub domenowej polityki bezpieczeństwa, a nie konfiguracji sprzętu, usług czy logów. Dlatego właściwym miejscem jest właśnie konsola lokalnych zasad zabezpieczeń, uruchamiana jako secpol.msc. Częstym skojarzeniem jest tpm.msc, bo też brzmi „bezpiecznie”. Jednak TPM (Trusted Platform Module) to moduł sprzętowy służący do bezpiecznego przechowywania kluczy kryptograficznych, wykorzystywany m.in. przez BitLocker. W tpm.msc zarządzasz chipem TPM, inicjalizujesz go, czyścisz, sprawdzasz stan, ale nie ustawisz tam długości hasła użytkownika czy wymagań złożoności. To jest bezpieczeństwo na poziomie sprzęt–szyfrowanie, a nie polityka kont. Z kolei services.msc to przystawka do zarządzania usługami systemowymi. Tam możesz włączać, wyłączać, zmieniać tryb uruchamiania różnych usług Windows i oprogramowania (np. serwer wydruku, usługi aktualizacji, usługi bazodanowe). Nie ma tam żadnych ustawień dotyczących haseł, polityk logowania czy blokady konta. Błąd myślowy bywa taki, że skoro usługi są „systemowe”, to może tam też są „usługi bezpieczeństwa”. Niestety nie – to zupełnie inny obszar. eventvwr.msc natomiast to Podgląd zdarzeń. Tym narzędziem analizuje się logi systemowe, aplikacyjne, zabezpieczeń. Można w nim zobaczyć np. nieudane logowania, zdarzenia związane z blokadą konta czy zmianą hasła, ale samo narzędzie służy wyłącznie do monitorowania i diagnostyki, a nie do definiowania polityki. Typowy błąd polega na myleniu „miejsca, gdzie coś widać” z „miejscem, gdzie się to konfiguruje”. Podsumowując: polityka haseł to element lokalnej polityki bezpieczeństwa, więc logicznie należy jej szukać właśnie w secpol.msc, a nie w narzędziach do TPM, usług czy logów zdarzeń.