Ta sekcja zawiera odpowiedzi na wiele często zadawanych pytań dotyczących ochrony haseł firmy Microsoft.
Pytania ogólne
Jakie wskazówki należy podać użytkownikom na temat wybierania bezpiecznego hasła?
Aktualne wskazówki firmy Microsoft dotyczące tego tematu można znaleźć pod następującym linkiem:
Wskazówki dotyczące haseł firmy Microsoft
Czy lokalna ochrona haseł firmy Microsoft entra jest obsługiwana w chmurach innych niż publiczne?
Lokalna ochrona haseł firmy Microsoft Entra jest obsługiwana zarówno w chmurach globalnych platformy Azure, jak i w chmurach platformy Azure Government.
Centrum administracyjne firmy Microsoft Entra umożliwia modyfikację lokalnej konfiguracji "Ochrona hasłem dla usługi Active Directory systemu Windows Server" w nieobsługiwanych chmurach; takie zmiany utrzymują się, ale nigdy nie obowiązują. Rejestracja lokalnych agentów serwera proxy lub lasów nie jest obsługiwana w chmurach nieobsługiwanych, a wszelkie takie próby rejestracji zawsze kończą się niepowodzeniem.
Jak mogę zastosować korzyści z ochrony haseł firmy Microsoft do podzbioru moich użytkowników lokalnych?
Nieobsługiwane. Po wdrożeniu i włączeniu usługi Microsoft Entra Password Protection ma zastosowanie równie do wszystkich użytkowników.
Jaka jest różnica między zmianą hasła a zestawem haseł (lub resetowaniem)?
Zmiana hasła jest wtedy, gdy użytkownik wybierze nowe hasło po udowodnieniu, że ma wiedzę o starym haśle. Na przykład zmiana hasła ma miejsce, gdy użytkownik zaloguje się do systemu Windows, a następnie zostanie wyświetlony monit o wybranie nowego hasła.
Zestaw haseł (czasami nazywany resetowaniem hasła) jest wtedy, gdy administrator zastępuje hasło na koncie nowym hasłem, na przykład za pomocą narzędzia do zarządzania Użytkownicy i komputery usługi Active Directory. Ta operacja wymaga wysokiego poziomu uprawnień (zazwyczaj administratora domeny), a osoba wykonująca operację zwykle nie ma wiedzy o starym haśle. Scenariusze pomocy technicznej często wykonują zestawy haseł, na przykład podczas pomagania użytkownikowi, który zapomniał hasła. Zobaczysz również zdarzenia zestawu haseł po utworzeniu zupełnie nowego konta użytkownika po raz pierwszy przy użyciu hasła.
Zasady sprawdzania poprawności hasła zachowują się tak samo niezależnie od tego, czy jest wykonywana zmiana hasła, czy zestaw. Usługa microsoft Entra Password Protection DC Agent rejestruje różne zdarzenia, aby poinformować, czy została wykonana zmiana hasła, czy operacja zestawu. Zobacz Monitorowanie i rejestrowanie w usłudze Microsoft Entra Password Protection.
Czy po zainstalowaniu program Microsoft Entra Password Protection weryfikuje istniejące hasła?
Nie — usługa Microsoft Entra Password Protection może wymuszać zasady haseł tylko na hasłach w postaci zwykłego tekstu podczas operacji zmiany lub ustawiania hasła. Gdy usługa Active Directory zaakceptuje hasło, utrwalone są tylko skróty specyficzne dla protokołu uwierzytelniania. Hasło w postaci zwykłego tekstu nigdy nie jest utrwalane, dlatego usługa Microsoft Entra Password Protection nie może zweryfikować istniejących haseł.
Po początkowym wdrożeniu usługi Microsoft Entra Password Protection wszyscy użytkownicy i konta w końcu zaczną używać hasła zweryfikowanego przez firmę Microsoft Entra, ponieważ istniejące hasła wygasają normalnie. W razie potrzeby można przyspieszyć ten proces przez jednorazowe ręczne wygaśnięcie haseł konta użytkownika.
Konta skonfigurowane za pomocą opcji "hasło nigdy nie wygasa" nie są wymuszane na zmianę hasła, chyba że zostanie wykonane ręczne wygaśnięcie.
Dlaczego podczas próby ustawienia słabego hasła przy użyciu przystawki zarządzania Użytkownicy i komputery usługi Active Directory są rejestrowane zdarzenia odrzucenia hasła?
Przystawka zarządzania Użytkownicy i komputery usługi Active Directory najpierw próbuje ustawić nowe hasło przy użyciu protokołu Kerberos. Po awarii przystawka podejmuje drugą próbę ustawienia hasła przy użyciu starszego protokołu (SAM RPC). Używane protokoły nie są ważne. Jeśli nowe hasło jest uznawane za słabe przez firmę Microsoft Entra Password Protection, to zachowanie przystawki powoduje zarejestrowanie dwóch zestawów zdarzeń odrzucenia resetowania hasła.
Dlaczego zdarzenia sprawdzania poprawności hasła ochrony haseł w usłudze Microsoft Entra są rejestrowane przy użyciu pustej nazwy użytkownika?
Usługa Active Directory obsługuje możliwość testowania hasła, aby sprawdzić, czy spełnia bieżące wymagania dotyczące złożoności hasła domeny, na przykład przy użyciu interfejsu API NetValidatePasswordPolicy . Po zweryfikowaniu hasła w ten sposób testowanie obejmuje również walidację przez produkty oparte na filtrze haseł, takie jak Ochrona haseł firmy Microsoft Entra, ale nazwy użytkowników przekazane do danej biblioteki dll filtru haseł są puste. W tym scenariuszu ochrona haseł firmy Microsoft nadal weryfikuje hasło przy użyciu aktualnie obowiązujących zasad haseł i wyświetla komunikat dziennika zdarzeń w celu przechwycenia wyniku. Jednak komunikat dziennika zdarzeń będzie miał puste pola nazwy użytkownika.
Mam użytkowników hybrydowych, którzy próbują zmienić hasło w identyfikatorze Entra firmy Microsoft i otrzymują odpowiedź "Widzieliśmy to zbyt wiele razy wcześniej. Wybierz coś trudniejszego do odgadnięcia." Dlaczego w takim przypadku nie widzę lokalnej próby weryfikacji?
Gdy użytkownik hybrydowy zmieni hasło w usłudze Microsoft Entra ID, niezależnie od tego, czy jest to samoobsługowe resetowanie hasła w usłudze Microsoft Entra, MyAccount, czy inny mechanizm zmiany hasła w usłudze Microsoft Entra, hasło to jest oceniane względem list globalnych i niestandardowych zabronionych haseł. Gdy hasło dociera do usługi Active Directory za pośrednictwem zapisywania zwrotnego haseł, jest ono już weryfikowane w identyfikatorze Entra firmy Microsoft.
Resetowanie haseł i zmiany zainicjowane w identyfikatorze Entra firmy Microsoft, które kończą się niepowodzeniem weryfikacji dla użytkowników hybrydowych, można znaleźć w dziennikach inspekcji firmy Microsoft Entra. Zobacz Rozwiązywanie problemów z samoobsługowym resetowaniem hasła w identyfikatorze Entra firmy Microsoft.
Czy jest obsługiwana instalacja ochrony haseł firmy Microsoft obok innych produktów opartych na filtrach haseł?
Tak. Obsługa wielu zarejestrowanych bibliotek dll filtrów haseł jest podstawową funkcją systemu Windows, a nie specyficzną dla ochrony haseł firmy Microsoft Entra. Wszystkie zarejestrowane biblioteki dll filtru haseł muszą być zgodne przed zaakceptowaniem hasła.
Jak mogę wdrożyć i skonfigurować ochronę haseł firmy Microsoft w środowisku usługi Active Directory bez korzystania z platformy Azure?
Nieobsługiwane. Microsoft Entra Password Protection to funkcja platformy Azure, która obsługuje rozszerzanie na środowisko lokalna usługa Active Directory.
Jak mogę zmodyfikować zawartość zasad na poziomie usługi Active Directory?
Nieobsługiwane. Zasady można administrować tylko przy użyciu centrum administracyjnego firmy Microsoft Entra. Zobacz również poprzednie pytanie.
Dlaczego usługa DFSR jest wymagana do replikacji folderu sysvol?
Usługa FRS (poprzednia technologia dfSR) ma wiele znanych problemów i jest całkowicie nieobsługiwana w nowszych wersjach usługi Active Directory systemu Windows Server. Zero testowania ochrony haseł firmy Microsoft entra odbywa się w domenach skonfigurowanych przez usługę FRS.
Aby uzyskać więcej informacji, zobacz następujące artykuły:
Przypadek migracji replikacji sysvol do usługi DFSR
Jeśli domena nie korzysta jeszcze z usługi DFSR, musisz przeprowadzić migrację do korzystania z usługi DFSR przed zainstalowaniem usługi Microsoft Entra Password Protection. Aby uzyskać więcej informacji, zobacz następujący link:
Przewodnik migracji replikacji SYSVOL: replikacja usługi FRS do systemu plików DFS
Ostrzeżenie
Oprogramowanie microsoft Entra Password Protection DC Agent jest obecnie instalowane na kontrolerach domeny w domenach, które nadal używają usługi FRS do replikacji folderu sysvol, ale oprogramowanie nie działa prawidłowo w tym środowisku. Negatywne skutki uboczne obejmują pojedyncze pliki, które nie są replikowane, a procedury przywracania folderu sysvol wydają się zakończyć się powodzeniem, ale dyskretnie nie można replikować wszystkich plików. Należy zmigrować domenę do korzystania z usługi DFSR tak szybko, jak to możliwe, zarówno w przypadku korzyści związanych z usługą DFSR, jak i odblokowania wdrożenia usługi Microsoft Entra Password Protection. Przyszłe wersje oprogramowania są automatycznie wyłączone podczas uruchamiania w domenie, która nadal korzysta z usługi FRS.
Ile miejsca na dysku wymaga funkcja w udziale sysvol domeny?
Dokładne użycie miejsca różni się, ponieważ zależy od czynników, takich jak liczba i długość zakazanych tokenów na globalnej liście zakazanych firmy Microsoft oraz lista niestandardowa dla poszczególnych dzierżaw oraz obciążenie związane z szyfrowaniem. Zawartość tych list może wzrosnąć w przyszłości. Mając to na uwadze, uzasadnione jest oczekiwanie, że funkcja wymaga co najmniej pięciu (5) megabajtów miejsca w udziale sysvol domeny.
Dlaczego do zainstalowania lub uaktualnienia oprogramowania agenta kontrolera domeny wymagany jest ponowny rozruch?
To wymaganie jest spowodowane zachowaniem podstawowego systemu Windows.
Czy istnieje sposób konfigurowania agenta kontrolera domeny do korzystania z określonego serwera proxy?
L.p. Ponieważ serwer proxy jest bezstanowy, nie jest ważne, który konkretny serwer proxy jest używany.
Czy można wdrożyć usługę proxy ochrony haseł firmy Microsoft obok innych usług, takich jak Microsoft Entra Connect?
Tak. Usługa Microsoft Entra Password Protection Proxy i microsoft Entra Connect nigdy nie powinny powodować bezpośredniego konfliktu ze sobą.
Niestety oprogramowanie microsoft Entra Password Protection Proxy instaluje wersję usługi Microsoft Entra Connect Agent Updater, która jest niezgodna z wersją zainstalowaną przez oprogramowanie proxy aplikacji Firmy Microsoft Entra. Ta niezgodność może spowodować, że usługa Aktualizator agenta nie może skontaktować się z platformą Azure w celu uzyskania aktualizacji oprogramowania. Nie zaleca się instalowania serwera proxy ochrony haseł firmy Microsoft i serwera proxy aplikacji Microsoft Entra na tej samej maszynie.
W jakiej kolejności należy zainstalować i zarejestrować agentów kontrolera domeny i serwerów proxy?
Obsługiwana jest dowolna kolejność instalacji agenta proxy, instalacja agenta kontrolera domeny, rejestracja lasu i rejestracja serwera proxy.
Czy powinienem być zaniepokojony trafieniem wydajności na kontrolerach domeny przed wdrożeniem tej funkcji?
Usługa microsoft Entra Password Protection DC Agent nie powinna znacząco wpływać na wydajność kontrolera domeny w istniejącym wdrożeniu usługi Active Directory w dobrej kondycji.
W przypadku większości wdrożeń usługi Active Directory operacje zmiany hasła są niewielką częścią ogólnego obciążenia na dowolnym kontrolerze domeny. Załóżmy na przykład, że domena usługi Active Directory z 10 000 kontami użytkowników i zasad MaxPasswordAge ustawiona na 30 dni. Ta domena widzi średnio 10000/30=~333 operacje zmiany hasła każdego dnia, co jest niewielką liczbą operacji dla nawet jednego kontrolera domeny. Rozważ potencjalny najgorszy scenariusz: załóżmy, że te zmiany hasła ok. 333 na jednym kontrolerze domeny zostały wykonane w ciągu jednej godziny. Na przykład ten scenariusz może wystąpić, gdy wielu pracowników przychodzi do pracy w poniedziałek rano. Nawet w takim przypadku nadal patrzymy na ~333/60 minut = sześć zmian haseł na minutę, co ponownie nie jest znaczącym obciążeniem.
Jeśli jednak bieżące kontrolery domeny są już uruchomione na ograniczonych do wydajności poziomach (na przykład maksymalnie w odniesieniu do procesora CPU, miejsca na dysku, operacji we/wy dysku itd.), zaleca się dodanie większej liczby kontrolerów domeny lub rozszerzenie dostępnego miejsca na dysku przed wdrożeniem tej funkcji. Zapoznaj się z poprzednim pytaniem dotyczącym użycia miejsca na dysku sysvol powyżej.
Chcę przetestować ochronę haseł firmy Microsoft na kilku kontrolerach domeny w mojej domenie. Czy można wymusić zmiany haseł użytkowników w celu korzystania z tych określonych kontrolerów domeny?
L.p. System operacyjny klienta systemu Windows kontroluje, który kontroler domeny jest używany, gdy użytkownik zmienia hasło. Kontroler domeny jest wybierany na podstawie czynników, takich jak lokacja usługi Active Directory i przypisania podsieci, konfiguracja sieci specyficzna dla środowiska itd. Usługa Microsoft Entra Password Protection nie kontroluje tych czynników i nie może wpływać na to, który kontroler domeny został wybrany do zmiany hasła użytkownika.
Jednym ze sposobów częściowego osiągnięcia tego celu jest wdrożenie ochrony haseł firmy Microsoft entra na wszystkich kontrolerach domeny w danej lokacji usługi Active Directory. Takie podejście zapewnia rozsądny zakres dla klientów systemu Windows przypisanych do tej lokacji oraz dla użytkowników, którzy logują się do tych klientów i zmieniają swoje hasła.
Jeśli zainstaluję usługę microsoft Entra Password Protection DC Agent tylko na podstawowym kontrolerze domeny (PDC), wszystkie inne kontrolery domeny w domenie również będą chronione?
L.p. Gdy hasło użytkownika zostanie zmienione na danym kontrolerze domeny innego niż PDC, hasło w postaci zwykłego tekstu nigdy nie jest wysyłane do kontrolera PDC (ten pomysł jest typowym błędnym postrzeganiem). Po zaakceptowaniu nowego hasła na danym kontrolerze domeny kontroler domeny używa tego hasła do tworzenia różnych skrótów specyficznych dla protokołu uwierzytelniania tego hasła, a następnie utrwala te skróty w katalogu. Hasło w postaci zwykłego tekstu nie jest utrwalane. Zaktualizowane skróty są następnie replikowane do kontrolera PDC. W niektórych przypadkach hasła użytkownika mogą zostać zmienione bezpośrednio na kontrolerze PDC, w zależności od różnych czynników, takich jak topologia sieci i projekt lokacji usługi Active Directory. (Zobacz poprzednie pytanie).
Podsumowując, wdrożenie usługi microsoft Entra Password Protection DC Agent na pdC jest wymagane do osiągnięcia 100% pokrycia zabezpieczeń funkcji w domenie. Wdrożenie funkcji na kontrolerze PDC nie zapewnia korzyści zabezpieczeń ochrony haseł firmy Microsoft dla innych kontrolerów domeny w domenie.
Dlaczego niestandardowe inteligentne blokowanie nie działa nawet po zainstalowaniu agentów w środowisku lokalna usługa Active Directory?
Niestandardowa inteligentna blokada jest obsługiwana tylko w identyfikatorze Entra firmy Microsoft. Zmiany niestandardowych ustawień inteligentnej blokady w centrum administracyjnym firmy Microsoft Entra nie mają wpływu na środowisko lokalna usługa Active Directory, nawet w przypadku zainstalowanych agentów.
Czy pakiet administracyjny programu System Center Operations Manager jest dostępny dla ochrony haseł firmy Microsoft?
L.p.
Dlaczego identyfikator Entra firmy Microsoft nadal odrzuca słabe hasła, mimo że skonfigurowano zasady tak, aby był w trybie inspekcji?
Tryb inspekcji jest obsługiwany tylko w środowisku lokalna usługa Active Directory. Identyfikator entra firmy Microsoft jest niejawnie zawsze w trybie "wymuszania" podczas oceniania haseł.
Moi użytkownicy widzą tradycyjny komunikat o błędzie systemu Windows, gdy hasło zostanie odrzucone przez usługę Microsoft Entra Password Protection. Czy można dostosować ten komunikat o błędzie, aby użytkownicy wiedzieli, co naprawdę się stało?
L.p. Komunikat o błędzie wyświetlany przez użytkowników, gdy hasło jest odrzucane przez kontroler domeny, jest kontrolowany przez komputer kliencki, a nie przez kontroler domeny. Takie zachowanie ma miejsce, czy hasło jest odrzucane przez domyślne zasady haseł usługi Active Directory, czy przez rozwiązanie oparte na filtrze haseł, takie jak Ochrona haseł firmy Microsoft.
Procedury testowania haseł
Warto wykonać kilka podstawowych testów różnych haseł, aby zweryfikować prawidłowe działanie oprogramowania i lepiej zrozumieć algorytm oceny haseł. W tej sekcji opisano metodę takiego testowania, która jest przeznaczona do generowania powtarzalnych wyników.
Dlaczego należy wykonać takie kroki? Istnieje kilka czynników, które utrudniają przeprowadzanie kontrolowanego, powtarzalnego testowania haseł w środowisku lokalna usługa Active Directory:
- Zasady haseł są konfigurowane i utrwalane na platformie Azure, a kopie zasad są okresowo synchronizowane przez lokalnych agentów kontrolera domeny przy użyciu mechanizmu sondowania. Opóźnienie związane z tym cyklem sondowania może powodować zamieszanie. Jeśli na przykład skonfigurujesz zasady na platformie Azure, ale zapomnisz je zsynchronizować z agentem kontrolera domeny, testy mogą nie przynieść oczekiwanych wyników. Interwał sondowania jest obecnie zakodowany jako jeden raz na godzinę, ale oczekiwanie na godzinę między zmianami zasad nie jest idealne dla scenariusza testowania interakcyjnego.
- Po zsynchronizowaniu nowych zasad haseł z kontrolerem domeny występuje większe opóźnienie podczas replikacji do innych kontrolerów domeny. Te opóźnienia mogą spowodować nieoczekiwane wyniki, jeśli przetestujesz zmianę hasła względem kontrolera domeny, który nie otrzymał najnowszej wersji zasad.
- Testowanie zmian haseł za pośrednictwem interfejsu użytkownika utrudnia zaufanie do wyników. Na przykład łatwo jest źle wpisać nieprawidłowe hasło do interfejsu użytkownika, zwłaszcza że większość interfejsów użytkownika haseł ukrywa dane wejściowe użytkownika (na przykład windows Ctrl-Alt-Delete —> zmienianie interfejsu użytkownika hasła).
- Nie można ściśle kontrolować, który kontroler domeny jest używany podczas testowania zmian haseł z klientów przyłączonych do domeny. System operacyjny klienta systemu Windows wybiera kontroler domeny na podstawie czynników, takich jak lokacja usługi Active Directory i przypisania podsieci, konfiguracja sieci specyficzna dla środowiska itd.
Aby uniknąć tych problemów, poniższe kroki są oparte na testowaniu wiersza polecenia resetowania haseł podczas logowania do kontrolera domeny.
Ostrzeżenie
Użyj tych procedur tylko w środowisku testowym. Gdy usługa agenta kontrolera domeny jest zatrzymana, wszystkie przychodzące zmiany i resetowanie haseł są akceptowane bez walidacji. Pomaga to również uniknąć zwiększonego ryzyka związanego z logowaniem się do kontrolera domeny.
W poniższych krokach założono, że zainstalowano agenta kontrolera domeny na co najmniej jednym kontrolerze domeny, zainstalowano co najmniej jeden serwer proxy i zarejestrowano zarówno serwer proxy, jak i las.
Zaloguj się do kontrolera domeny przy użyciu poświadczeń administratora domeny lub innych poświadczeń, które mają wystarczające uprawnienia do tworzenia testowych kont użytkowników i resetowania haseł. Upewnij się, że kontroler domeny ma zainstalowane oprogramowanie agenta kontrolera domeny i został uruchomiony ponownie.
Otwórz Podgląd zdarzeń i przejdź do dziennika zdarzeń administratora agenta kontrolera domeny.
Otwórz okno wiersza polecenia z podwyższonym poziomem uprawnień.
Tworzenie konta testowego na potrzeby testowania haseł
Istnieje wiele sposobów tworzenia konta użytkownika, ale opcja wiersza polecenia jest oferowana tutaj jako sposób ułatwienia podczas powtarzalnych cykli testowania:
net.exe user <testuseraccountname> /add <password>Na potrzeby dyskusji poniżej załóżmy, że utworzyliśmy konto testowe o nazwie "ContosoUser", na przykład:
net.exe user ContosoUser /add <password>Zaloguj się do centrum administracyjnego firmy Microsoft Entra co najmniej jako administrator uwierzytelniania.
Przejdź do strony Ochrona > metod > uwierzytelniania Ochrona haseł.
Zmodyfikuj zasady ochrony haseł firmy Microsoft zgodnie z potrzebami na potrzeby testowania, które chcesz wykonać. Możesz na przykład zdecydować się na skonfigurowanie trybu wymuszonego lub inspekcji albo zmodyfikować listę zakazanych terminów na liście niestandardowych zakazanych haseł.
Zsynchronizuj nowe zasady, zatrzymując i ponownie uruchamiając usługę agenta kontrolera domeny.
Ten krok można wykonać na różne sposoby. Jednym ze sposobów jest użycie konsoli administracyjnej zarządzania usługami, klikając prawym przyciskiem myszy usługę Microsoft Entra Password Protection DC Agent i wybierając polecenie "Uruchom ponownie". Inny sposób można wykonać z okna wiersza polecenia w następujący sposób:
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgentSprawdź Podgląd zdarzeń, aby sprawdzić, czy zostały pobrane nowe zasady.
Za każdym razem, gdy usługa agenta kontrolera domeny jest zatrzymywana i uruchamiana, powinny zostać wyświetlone dwa zdarzenia 30006 wystawione w krótkim odstępie czasu. Pierwsze zdarzenie 30006 będzie odzwierciedlać zasady buforowane na dysku w udziale sysvol. Drugie zdarzenie 30006 (jeśli istnieje) powinno mieć zaktualizowaną datę zasad dzierżawy i jeśli tak będzie odzwierciedlać zasady pobrane z platformy Azure. Wartość daty zasad dzierżawy jest obecnie kodowana, aby wyświetlić przybliżony znacznik czasu pobrany z platformy Azure.
Jeśli drugie zdarzenie 30006 nie jest wyświetlane, przed kontynuowaniem należy rozwiązać problem.
Zdarzenia 30006 będą wyglądać podobnie do tego przykładu:
The service is now enforcing the following Azure password policy. Enabled: 1 AuditOnly: 0 Global policy date: 2018-05-15T00:00:00.000000000Z Tenant policy date: 2018-06-10T20:15:24.432457600Z Enforce tenant policy: 1Na przykład zmiana między trybem wymuszonym a trybem inspekcji spowoduje zmodyfikowanie flagi AuditOnly (zasady wymienione w trybie AuditOnly=0 są w trybie wymuszonym). Zmiany niestandardowej listy zakazanych haseł nie są bezpośrednio odzwierciedlane w powyższym zdarzeniu 30006 i nie są rejestrowane nigdzie indziej ze względów bezpieczeństwa. Pomyślnie pobrano zasady z platformy Azure po tej zmianie będzie również zawierać zmodyfikowaną niestandardową listę zakazanych haseł.
Uruchom test, próbując zresetować nowe hasło na koncie użytkownika testowego.
Ten krok można wykonać w oknie wiersza polecenia w następujący sposób:
net.exe user ContosoUser <password>Po uruchomieniu polecenia możesz uzyskać więcej informacji o wyniku polecenia, patrząc w podglądzie zdarzeń. Zdarzenia wyniku weryfikacji hasła są udokumentowane w temacie dziennika zdarzeń administratora agenta kontrolera domeny. Takie zdarzenia służą do sprawdzania poprawności wyniku testu oprócz interaktywnych danych wyjściowych z poleceń net.exe.
Spróbujmy użyć przykładu: próba ustawienia hasła, które jest zakazane przez listę globalną firmy Microsoft (należy pamiętać, że lista nie jest udokumentowana , ale możemy przetestować tutaj pod znanym zakazanym terminem). W tym przykładzie przyjęto założenie, że zasady zostały skonfigurowane w trybie wymuszonym i dodano zero terminów do niestandardowej listy zakazanych haseł.
net.exe user ContosoUser PassWord The password doesn't meet the password policy requirements. Check the minimum password length, password complexity, and password history requirements. More help is available by typing NET HELPMSG 2245.Zgodnie z dokumentacją, ponieważ nasz test był operacją resetowania hasła, powinna zostać wyświetlona operacja 10017 i zdarzenie 30005 dla użytkownika ContosoUser.
Zdarzenie 10017 powinno wyglądać następująco:
The reset password for the specified user was rejected because it didn't comply with the current Azure password policy. For more information, please see the correlated event log message. UserName: ContosoUser FullName:Zdarzenie 30005 powinno wyglądać następująco:
The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. UserName: ContosoUser FullName:To było zabawne - spróbujmy inny przykład! Teraz spróbujemy ustawić hasło, które jest zakazane przez niestandardową listę zakazaną, gdy zasady są w trybie inspekcji. W tym przykładzie przyjęto założenie, że zostały wykonane następujące kroki: skonfigurowano zasady tak, aby były w trybie inspekcji, dodano termin "lachrymose" do niestandardowej listy zakazanych haseł i zsynchronizował wynikowe nowe zasady z kontrolerem domeny, przechodząc na rowerze do usługi agenta kontrolera domeny, zgodnie z wcześniejszym opisem.
Ok, ustaw odmianę zakazanego hasła:
net.exe user ContosoUser LaChRymoSE!1 The command completed successfully.Pamiętaj, że tym razem powiodło się, ponieważ zasady są w trybie inspekcji. Powinno zostać wyświetlone zdarzenie 10025 i 30007 dla użytkownika ContosoUser.
Zdarzenie 10025 powinno wyglądać następująco:
The reset password for the specified user would normally have been rejected because it didn't comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details. UserName: ContosoUser FullName:Zdarzenie 30007 powinno wyglądać następująco:
The reset password for the specified user would normally be rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. UserName: ContosoUser FullName:Kontynuuj testowanie różnych haseł i sprawdź wyniki w podglądzie zdarzeń, korzystając z procedur opisanych w poprzednich krokach. Jeśli musisz zmienić zasady w centrum administracyjnym firmy Microsoft Entra, nie zapomnij zsynchronizować nowych zasad z agentem kontrolera domeny zgodnie z wcześniejszym opisem.
Omówiliśmy procedury, które umożliwiają przeprowadzanie kontrolowanego testowania zachowania weryfikacji haseł firmy Microsoft Entra Password Protection. Resetowanie haseł użytkowników z wiersza polecenia bezpośrednio na kontrolerze domeny może wydawać się dziwnym sposobem wykonywania takich testów, ale zgodnie z wcześniejszym opisem jest przeznaczony do generowania powtarzalnych wyników. Podczas testowania różnych haseł należy pamiętać o algorytmie oceny haseł, ponieważ może to pomóc w wyjaśnieniu wyników, których nie oczekiwano.
Ostrzeżenie
Po zakończeniu wszystkich testów nie zapomnij usunąć żadnych kont użytkowników utworzonych na potrzeby testowania.
Dodatkowa zawartość
Poniższe linki nie są częścią podstawowej dokumentacji usługi Microsoft Entra Password Protection, ale mogą być przydatnym źródłem dodatkowych informacji na temat tej funkcji.
Dostępne szkolenia pomocy technicznej Microsoft Premier\Unified
Jeśli chcesz dowiedzieć się więcej na temat ochrony haseł firmy Microsoft i sposobu jej wdrażania, możesz użyć proaktywnej usługi firmy Microsoft. Ta usługa jest dostępna dla klientów z umową pomocy technicznej Premier lub Unified. Usługa nosi nazwę Microsoft Entra ID: Password Protection. Aby uzyskać więcej informacji, skontaktuj się z menedżerem konta sukcesu klienta.
Następne kroki
Jeśli masz lokalne pytanie dotyczące ochrony haseł firmy Microsoft, na które nie udzielono odpowiedzi, prześlij poniższy element opinii — dziękuję!