Rozwiązywanie problemów z lokalną ochroną hasłem Microsoft Entra

Artykuł
10/25/2023

Po wdrożeniu usługi Microsoft Entra Password Protection może być wymagane rozwiązywanie problemów. W tym artykule szczegółowo opisano niektóre typowe kroki rozwiązywania problemów.

Agent kontrolera domeny nie może zlokalizować serwera proxy w katalogu

Głównym objawem tego problemu są zdarzenia 30017 w dzienniku zdarzeń agenta kontrolera domeny Administracja.

Zwykle przyczyną tego problemu jest to, że serwer proxy nie został jeszcze zarejestrowany. Jeśli serwer proxy został zarejestrowany, może wystąpić pewne opóźnienie z powodu opóźnienia replikacji usługi AD, dopóki określony agent kontrolera domeny nie będzie mógł zobaczyć tego serwera proxy.

Agent kontrolera domeny nie może komunikować się z serwerem proxy

Głównym objawem tego problemu są zdarzenia 30018 w dzienniku zdarzeń agenta kontrolera domeny Administracja. Ten problem może mieć kilka możliwych przyczyn:

Agent kontrolera domeny znajduje się w izolowanej części sieci, która nie zezwala na łączność sieciową z zarejestrowanymi serwerami proxy. Ten problem może być łagodny, o ile inni agenci kontrolera domeny mogą komunikować się z serwerami proxy w celu pobrania zasad haseł z platformy Azure. Po pobraniu te zasady będą następnie uzyskiwane przez izolowany kontroler domeny za pośrednictwem replikacji plików zasad w udziale sysvol.
Maszyna hosta serwera proxy blokuje dostęp do punktu końcowego mapowania punktu końcowego RPC (port 135)

Instalator serwera proxy ochrony haseł firmy Microsoft automatycznie tworzy regułę ruchu przychodzącego zapory systemu Windows, która umożliwia dostęp do portu 135. Jeśli ta reguła zostanie później usunięta lub wyłączona, agenci kontrolera domeny nie będą mogli komunikować się z usługą proxy. Jeśli wbudowana zapora systemu Windows została wyłączona zamiast innego produktu zapory, należy skonfigurować zaporę tak, aby zezwalała na dostęp do portu 135.
Maszyna hosta serwera proxy blokuje dostęp do punktu końcowego RPC (dynamicznego lub statycznego) nasłuchiwanego przez usługę proxy

Instalator serwera proxy ochrony haseł firmy Microsoft automatycznie tworzy regułę ruchu przychodzącego zapory systemu Windows, która umożliwia dostęp do dowolnych portów przychodzących nasłuchujących przez usługę serwera proxy ochrony haseł firmy Microsoft. Jeśli ta reguła zostanie później usunięta lub wyłączona, agenci kontrolera domeny nie będą mogli komunikować się z usługą proxy. Jeśli wbudowana zapora systemu Windows została wyłączona zamiast innego produktu zapory, należy skonfigurować zaporę, aby zezwolić na dostęp do dowolnych portów przychodzących nasłuchiwane przez usługę serwera proxy ochrony haseł firmy Microsoft. Ta konfiguracja może być bardziej szczegółowa, jeśli usługa proxy została skonfigurowana do nasłuchiwania na określonym statycznym porcie RPC (przy użyciu Set-AzureADPasswordProtectionProxyConfiguration polecenia cmdlet).
Maszyna hosta serwera proxy nie jest skonfigurowana do zezwalania kontrolerom domeny na logowanie się do maszyny. To zachowanie jest kontrolowane za pośrednictwem przypisania uprawnień użytkownika "Uzyskaj dostęp do tego komputera z sieci". Wszystkie kontrolery domeny we wszystkich domenach w lesie muszą mieć to uprawnienie. To ustawienie jest często ograniczone w ramach większego nakładu pracy na wzmacnianie zabezpieczeń sieci.

Usługa proxy nie może komunikować się z platformą Azure

Upewnij się, że maszyna proxy ma łączność z punktami końcowymi wymienionymi w wymaganiach dotyczących wdrażania.
Upewnij się, że las i wszystkie serwery proxy są zarejestrowane w tej samej dzierżawie platformy Azure.

To wymaganie można sprawdzić, uruchamiając Get-AzureADPasswordProtectionProxy polecenia cmdlet programu i Get-AzureADPasswordProtectionDCAgent PowerShell, a następnie porównaj AzureTenant właściwość każdego zwróconego elementu. W przypadku poprawnej operacji zgłoszona nazwa dzierżawy musi być taka sama we wszystkich agentach kontrolera domeny i serwerach proxy.

Jeśli istnieje warunek niezgodności rejestracji dzierżawy platformy Azure, ten problem można rozwiązać, uruchamiając Register-AzureADPasswordProtectionProxy polecenia cmdlet i/lub Register-AzureADPasswordProtectionForest programu PowerShell zgodnie z potrzebami, upewniając się, że używasz poświadczeń z tej samej dzierżawy platformy Azure dla wszystkich rejestracji.

Agent kontrolera domeny nie może zaszyfrować ani odszyfrować plików zasad haseł

Ochrona haseł firmy Microsoft ma krytyczną zależność od funkcji szyfrowania i odszyfrowywania dostarczanych przez usługę dystrybucji kluczy firmy Microsoft. Błędy szyfrowania lub odszyfrowywania mogą przejawiać się różnymi objawami i mieć kilka potencjalnych przyczyn.

Upewnij się, że usługa KDS jest włączona i funkcjonalna na wszystkich kontrolerach domeny systemu Windows Server 2012 i nowszych w domenie.

Domyślnie tryb uruchamiania usługi KDS usługi jest skonfigurowany jako Ręczny (Uruchamianie wyzwalacza). Ta konfiguracja oznacza, że po raz pierwszy klient próbuje użyć usługi, jest uruchamiany na żądanie. Ten domyślny tryb uruchamiania usługi jest akceptowalny, aby ochrona haseł firmy Microsoft działała.

Jeśli tryb uruchamiania usługi KDS został skonfigurowany na wartość Wyłączone, ta konfiguracja musi zostać naprawiona, zanim ochrona haseł w usłudze Microsoft Entra będzie działać prawidłowo.

Prosty test dla tego problemu polega na ręcznym uruchomieniu usługi KDS za pośrednictwem konsoli MMC zarządzania usługami lub przy użyciu innych narzędzi do zarządzania (na przykład uruchom polecenie "net start kdssvc" z konsoli wiersza polecenia). Oczekuje się, że usługa KDS zostanie uruchomiona pomyślnie i pozostanie uruchomiona.

Najczęstszą główną przyczyną niemożności uruchomienia usługi KDS jest to, że obiekt kontrolera domeny usługi Active Directory znajduje się poza domyślną jednostki organizacyjnej kontrolerów domeny. Ta konfiguracja nie jest obsługiwana przez usługę KDS i nie jest ograniczeniem nałożonym przez usługę Microsoft Entra Password Protection. Poprawka tego warunku polega na przeniesieniu obiektu kontrolera domeny do lokalizacji w domyślnej jednostki organizacyjnej kontrolerów domeny.
Niezgodna zmiana formatu zaszyfrowanego buforu KDS z systemu Windows Server 2012 R2 na Windows Server 2016

Poprawka zabezpieczeń KDS została wprowadzona w systemie Windows Server 2016, który modyfikuje format buforów zaszyfrowanych KDS; bufory te czasami nie będą odszyfrowywać w systemach Windows Server 2012 i Windows Server 2012 R2. Odwrotny kierunek jest w porządku — bufory szyfrowane funkcją KDS w systemach Windows Server 2012 i Windows Server 2012 R2 będą zawsze pomyślnie odszyfrowywać w systemie Windows Server 2016 lub nowszym. Jeśli kontrolery domeny w domenach usługi Active Directory działają w połączeniu z tymi systemami operacyjnymi, mogą być zgłaszane sporadyczne błędy odszyfrowywania ochrony haseł firmy Microsoft. Nie można dokładnie przewidzieć chronometrażu lub objawów tych błędów, biorąc pod uwagę charakter poprawki zabezpieczeń i biorąc pod uwagę, że nie jest deterministyczny, na którym agent dc ochrony haseł firmy Microsoft, na którym kontroler domeny będzie szyfrować dane w danym momencie.

Nie ma obejścia tego problemu innego niż nie można uruchomić kombinacji tych niezgodnych systemów operacyjnych w domenach usługi Active Directory. Innymi słowy, należy uruchomić tylko kontrolery domeny systemu Windows Server 2012 i Windows Server 2012 R2 lub należy uruchomić tylko windows Server 2016 i nowszych kontrolerów domeny.

Agent kontrolera domeny uważa, że las nie został zarejestrowany

Objawem tego problemu są zdarzenia 30016 rejestrowane w kanale agenta kontrolera domeny\Administracja, który jest wyświetlany częściowo:

The forest has not been registered with Azure. Password policies cannot be downloaded from Azure unless this is corrected.

Istnieją dwie możliwe przyczyny tego problemu.

Las rzeczywiście nie został zarejestrowany. Aby rozwiązać ten problem, uruchom polecenie Register-AzureADPasswordProtectionForest zgodnie z opisem w wymaganiach dotyczących wdrażania.
Las został zarejestrowany, ale agent kontrolera domeny nie może odszyfrować danych rejestracji lasu. Ten przypadek ma taką samą główną przyczynę jak problem #2 wymieniony powyżej w obszarze Agent kontrolera domeny nie może zaszyfrować ani odszyfrować plików zasad haseł. Łatwo potwierdzić tę teorię jest to, że ten błąd będzie widoczny tylko na agentach kontrolera domeny działających w systemie Windows Server 2012 lub Windows Server 2012R2 kontrolery domeny, podczas gdy agenci kontrolera domeny działający w systemie Windows Server 2016 i nowszych kontrolerach domeny są w porządku. Obejście jest takie samo: uaktualnij wszystkie kontrolery domeny do systemu Windows Server 2016 lub nowszego.

Słabe hasła są akceptowane, ale nie powinny być

Ten problem może mieć kilka przyczyn.

Agenci kontrolera domeny korzystają z publicznej wersji zapoznawczej oprogramowania, która wygasła. Zobacz Oprogramowanie agenta dc w publicznej wersji zapoznawczej wygasło.
Agenci kontrolera domeny nie mogą pobrać zasad lub nie mogą odszyfrować istniejących zasad. Sprawdź możliwe przyczyny w powyższych tematach.
Tryb wymuszania zasad haseł jest nadal ustawiony na Inspekcja. Jeśli ta konfiguracja jest w mocy, skonfiguruj ją ponownie, aby wymusić jej użycie przy użyciu portalu ochrony haseł firmy Microsoft. Aby uzyskać więcej informacji, zobacz Tryby działania.
Zasady haseł zostały wyłączone. Jeśli ta konfiguracja jest w mocy, skonfiguruj ją ponownie, aby była włączona przy użyciu portalu ochrony haseł firmy Microsoft Entra. Aby uzyskać więcej informacji, zobacz Tryby działania.
Nie zainstalowano oprogramowania agenta kontrolera domeny na wszystkich kontrolerach domeny w domenie. W takiej sytuacji trudno jest upewnić się, że zdalni klienci z systemem Windows są kierowani do określonego kontrolera domeny podczas operacji zmiany hasła. Jeśli uważasz, że pomyślnie skierowano określonego kontrolera domeny, na którym zainstalowano oprogramowanie agenta kontrolera domeny, możesz sprawdzić, sprawdzając dwukrotnie dziennik zdarzeń administratora agenta kontrolera domeny: niezależnie od wyniku będzie istnieć co najmniej jedno zdarzenie, aby udokumentować wynik weryfikacji hasła. Jeśli nie ma zdarzenia dla użytkownika, którego hasło zostało zmienione, zmiana hasła została prawdopodobnie przetworzona przez inny kontroler domeny.

W ramach alternatywnego testu spróbuj ustawić\zmienić hasła podczas logowania bezpośrednio do kontrolera domeny, na którym zainstalowano oprogramowanie agenta kontrolera domeny. Ta technika nie jest zalecana w przypadku produkcyjnych domen usługi Active Directory.

Chociaż wdrażanie przyrostowe oprogramowania agenta kontrolera domeny jest obsługiwane w ramach tych ograniczeń, firma Microsoft zdecydowanie zaleca, aby oprogramowanie agenta kontrolera domeny było zainstalowane na wszystkich kontrolerach domeny w domenie tak szybko, jak to możliwe.
Algorytm weryfikacji hasła może działać zgodnie z oczekiwaniami. Zobacz Jak są oceniane hasła.

Nie można ustawić słabego hasła DSRM ntdsutil.exe

Usługa Active Directory zawsze weryfikuje nowe hasło trybu naprawy usług katalogowych, aby upewnić się, że spełnia wymagania dotyczące złożoności hasła domeny; Ta walidacja wywołuje również biblioteki dll filtru haseł, takie jak Ochrona haseł firmy Microsoft. Jeśli nowe hasło modułu DSRM zostanie odrzucone, zostanie wyświetlony następujący komunikat o błędzie:

C:\>ntdsutil.exe
ntdsutil: set dsrm password
Reset DSRM Administrator Password: reset password on server null
Please type password for DS Restore Mode Administrator Account: ********
Please confirm new password: ********
Setting password failed.
        WIN32 Error Code: 0xa91
        Error Message: Password doesn't meet the requirements of the filter dll's

Gdy usługa Microsoft Entra Password Protection rejestruje zdarzenia dziennika zdarzeń weryfikacji haseł dla hasła DSRM usługi Active Directory, oczekuje się, że komunikaty dziennika zdarzeń nie będą zawierać nazwy użytkownika. To zachowanie występuje, ponieważ konto DSRM jest kontem lokalnym, które nie jest częścią rzeczywistej domeny usługi Active Directory.

Podwyższanie poziomu repliki kontrolera domeny kończy się niepowodzeniem z powodu słabego hasła DSRM

Podczas procesu podwyższania poziomu kontrolera domeny nowe hasło trybu naprawy usług katalogowych zostanie przesłane do istniejącego kontrolera domeny w domenie w celu weryfikacji. Jeśli nowe hasło modułu DSRM zostanie odrzucone, zostanie wyświetlony następujący komunikat o błędzie:

Install-ADDSDomainController : Verification of prerequisites for Domain Controller promotion failed. The Directory Services Restore Mode password does not meet a requirement of the password filter(s). Supply a suitable password.

Podobnie jak w powyższym problemie, każde zdarzenie weryfikacji hasła ochrony haseł firmy Microsoft będzie zawierać puste nazwy użytkowników w tym scenariuszu.

Obniżenie poziomu kontrolera domeny kończy się niepowodzeniem z powodu słabego hasła lokalnego Administracja istratora

Obsługiwane jest obniżanie poziomu kontrolera domeny, który nadal działa oprogramowanie agenta kontrolera domeny. Administracja istratorzy powinni jednak pamiętać, że oprogramowanie agenta kontrolera domeny nadal wymusza bieżące zasady haseł podczas procedury obniżania poziomu. Nowe hasło konta lokalnego Administracja istratora (określone w ramach operacji degradacji) jest weryfikowane jak każde inne hasło. Firma Microsoft zaleca wybranie bezpiecznych haseł dla kont lokalnego Administracja istratora w ramach procedury obniżania poziomu kontrolera domeny.

Po pomyślnym zakończeniu degradacji, a kontroler domeny został ponownie uruchomiony i ponownie działa jako normalny serwer członkowski, oprogramowanie agenta kontrolera domeny powraca do działania w trybie pasywnym. Następnie można go odinstalować w dowolnym momencie.

Uruchamianie w trybie naprawy usług katalogowych

Jeśli kontroler domeny zostanie uruchomiony w trybie naprawy usług katalogowych, biblioteka dll filtru haseł agenta kontrolera domeny wykryje ten warunek i spowoduje wyłączenie wszystkich działań weryfikacji hasła lub wymuszania, niezależnie od aktualnie aktywnej konfiguracji zasad. Biblioteka dll filtru haseł agenta kontrolera domeny rejestruje zdarzenie ostrzegawcze 10023 w dzienniku zdarzeń Administracja, na przykład:

The password filter dll is loaded but the machine appears to be a domain controller that has been booted into Directory Services Repair Mode. All password change and set requests will be automatically approved. No further messages will be logged until after the next reboot.

Oprogramowanie agenta kontrolera domeny w publicznej wersji zapoznawczej wygasło

W okresie publicznej wersji zapoznawczej usługi Microsoft Entra Password Protection oprogramowanie agenta kontrolera domeny zostało zakodowane w celu zaprzestania przetwarzania żądań weryfikacji haseł w następujących dniach:

Wersja 1.2.65.0 przestanie przetwarzać żądania weryfikacji hasła 1 września 2019 r.
Wersja 1.2.25.0 i wcześniejsze zatrzymały przetwarzanie żądań sprawdzania poprawności haseł w dniu 1 lipca 2019 r.

W miarę zbliżania się terminu wszystkie wersje agenta dc ograniczone czasowo będą emitować zdarzenie 10021 w agencie kontrolera domeny Administracja dziennika zdarzeń podczas rozruchu, które wygląda następująco:

The password filter dll has successfully loaded and initialized.

The allowable trial period is nearing expiration. Once the trial period has expired, the password filter dll will no longer process passwords. Please contact Microsoft for an newer supported version of the software.

Expiration date:  9/01/2019 0:00:00 AM

This message will not be repeated until the next reboot.

Po upływie terminu wszystkie ograniczone czasowo wersje agenta kontrolera domeny będą emitować zdarzenie 10022 w agencie kontrolera domeny Administracja dziennik zdarzeń podczas rozruchu, który wygląda następująco:

The password filter dll is loaded but the allowable trial period has expired. All password change and set requests will be automatically approved. Please contact Microsoft for a newer supported version of the software.

No further messages will be logged until after the next reboot.

Ponieważ termin ostateczny jest sprawdzany tylko podczas początkowego rozruchu, te zdarzenia mogą nie być widoczne dopiero po upływie terminu kalendarzowego. Po rozpoznaniu terminu nie zostaną automatycznie zatwierdzone żadne negatywne skutki dla kontrolera domeny lub większe środowisko inne niż wszystkie hasła.

Ważne

Firma Microsoft zaleca natychmiastowe uaktualnienie agentów kontrolera domeny w wersji zapoznawczej wersji publicznej do najnowszej wersji.

Łatwym sposobem odnajdywania agentów kontrolera domeny w środowisku, które należy uaktualnić, jest uruchomienie Get-AzureADPasswordProtectionDCAgent polecenia cmdlet, na przykład:

PS C:\> Get-AzureADPasswordProtectionDCAgent

ServerFQDN            : bpl1.bpl.com
SoftwareVersion       : 1.2.125.0
Domain                : bpl.com
Forest                : bpl.com
PasswordPolicyDateUTC : 8/1/2019 9:18:05 PM
HeartbeatUTC          : 8/1/2019 10:00:00 PM
AzureTenant           : bpltest.onmicrosoft.com

W tym temacie pole SoftwareVersion jest oczywiście właściwością klucza do przyjrzenia się. Możesz również użyć filtrowania programu PowerShell, aby odfiltrować agentów kontrolera domeny, którzy są już w wymaganej wersji punktu odniesienia lub powyżej, na przykład:

PS C:\> $LatestAzureADPasswordProtectionVersion = "1.2.125.0"
PS C:\> Get-AzureADPasswordProtectionDCAgent | Where-Object {$_.SoftwareVersion -lt $LatestAzureADPasswordProtectionVersion}

Oprogramowanie microsoft Entra Password Protection Proxy nie jest ograniczone czasowo w żadnej wersji. Firma Microsoft nadal zaleca uaktualnienie agentów kontrolera domeny i serwera proxy do najnowszych wersji w miarę ich wydawania. Polecenie Get-AzureADPasswordProtectionProxy cmdlet może służyć do znajdowania agentów serwera proxy, którzy wymagają uaktualnień, podobnie jak w powyższym przykładzie dla agentów kontrolera domeny.

Aby uzyskać więcej informacji na temat konkretnych procedur uaktualniania, zobacz Uaktualnianie agenta kontrolera domeny i Uaktualnianie usługi proxy.

Korygowanie awaryjne

Jeśli wystąpi sytuacja, w której usługa agenta kontrolera domeny powoduje problemy, usługa agenta kontrolera domeny może zostać natychmiast zamknięta. Biblioteka dll filtru haseł agenta kontrolera domeny nadal próbuje wywołać nieuruchomiącą usługę i będzie rejestrować zdarzenia ostrzegawcze (10012, 10013), ale wszystkie przychodzące hasła są akceptowane w tym czasie. Następnie można skonfigurować usługę agenta kontrolera domeny za pośrednictwem Menedżera sterowania usługami systemu Windows z typem uruchamiania "Wyłączone", zgodnie z potrzebami.

Kolejną miarą korygowania jest ustawienie trybu Włącz na Nie w portalu Ochrony haseł firmy Microsoft. Po pobraniu zaktualizowanych zasad każda usługa agenta kontrolera domeny przejdzie w tryb spoczynku, w którym wszystkie hasła są akceptowane zgodnie z rzeczywistym użyciem. Aby uzyskać więcej informacji, zobacz Tryby działania.

Usuwania

Jeśli podjęto decyzję o odinstalowaniu oprogramowania microsoft Entra Password Protection i oczyszczeniu wszystkich powiązanych stanów z domen i lasu, to zadanie można wykonać, wykonując następujące czynności:

Ważne

Ważne jest, aby wykonać te kroki w podanej kolejności. Jeśli jakiekolwiek wystąpienie usługi proxy pozostanie uruchomione, będzie okresowo ponownie tworzyć swoją usługę Połączenie ionPoint. Jeśli jakiekolwiek wystąpienie usługi agenta kontrolera domeny pozostanie uruchomione, okresowo ponownie utworzy swoją usługę Połączenie ionPoint i stan sysvol.

Odinstaluj oprogramowanie proxy ze wszystkich maszyn. Ten krok nie wymaga ponownego uruchomienia.
Odinstaluj oprogramowanie agenta kontrolera domeny ze wszystkich kontrolerów domeny. Ten krok wymaga ponownego uruchomienia.
Ręcznie usuń wszystkie punkty połączenia usługi proxy w każdym kontekście nazewnictwa domeny. Lokalizację tych obiektów można odnaleźć za pomocą następującego polecenia programu PowerShell usługi Active Directory:
```
$scp = "serviceConnectionPoint"
$keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }
```
Nie pomijaj gwiazdki ("*") na końcu wartości zmiennej $keywords.

Wynikowe obiekty znalezione za pośrednictwem Get-ADObject polecenia można następnie przesłać potok do Remove-ADObjectmetody lub usunąć ręcznie.
Ręcznie usuń wszystkie punkty połączenia agenta kontrolera domeny w każdym kontekście nazewnictwa domeny. W zależności od tego, jak szeroko wdrożono oprogramowanie, może istnieć jeden z tych obiektów na kontroler domeny w lesie. Lokalizację tego obiektu można odnaleźć za pomocą następującego polecenia programu PowerShell usługi Active Directory:
```
$scp = "serviceConnectionPoint"
$keywords = "{2bac71e6-a293-4d5b-ba3b-50b995237946}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }
```
Wynikowe obiekty znalezione za pośrednictwem Get-ADObject polecenia można następnie przesłać potok do Remove-ADObjectmetody lub usunąć ręcznie.

Nie pomijaj gwiazdki ("*") na końcu wartości zmiennej $keywords.
Ręcznie usuń stan konfiguracji na poziomie lasu. Stan konfiguracji lasu jest utrzymywany w kontenerze w kontekście nazewnictwa konfiguracji usługi Active Directory. Można go odnaleźć i usunąć w następujący sposób:
```
$passwordProtectionConfigContainer = "CN=Azure AD Password Protection,CN=Services," + (Get-ADRootDSE).configurationNamingContext
Remove-ADObject -Recursive $passwordProtectionConfigContainer
```
Ręcznie usuń cały stan związany z folderem sysvol, ręcznie usuwając następujący folder i całą jego zawartość:

\\<domain>\sysvol\<domain fqdn>\AzureADPasswordProtection

W razie potrzeby ta ścieżka może być również dostępna lokalnie na danym kontrolerze domeny; domyślna lokalizacja będzie podobna do następującej ścieżki:

%windir%\sysvol\domain\Policies\AzureADPasswordProtection

Ta ścieżka jest inna, jeśli udział sysvol został skonfigurowany w lokalizacji innej niż domyślna.

Testowanie kondycji za pomocą poleceń cmdlet programu PowerShell

Moduł AzureADPasswordProtection programu PowerShell zawiera dwa polecenia cmdlet związane z kondycją, które wykonują podstawową weryfikację, czy oprogramowanie jest zainstalowane i działa. Te polecenia cmdlet warto jest uruchamiać po skonfigurowaniu nowego wdrożenia i okresowo później oraz podczas badania problemu.

Każdy pojedynczy test kondycji zwraca podstawowy wynik Powodzenie lub Niepowodzenie oraz opcjonalny komunikat o niepowodzeniu. W przypadkach, gdy przyczyna błędu nie jest jasna, poszukaj komunikatów dziennika zdarzeń błędów, które mogą wyjaśnić błąd. Włączenie komunikatów dziennika tekstowego może być również przydatne. Aby uzyskać więcej informacji, zobacz Monitorowanie ochrony haseł firmy Microsoft w usłudze Microsoft Entra.

Testowanie kondycji serwera proxy

Polecenie cmdlet Test-AzureADPasswordProtectionProxyHealth obsługuje dwa testy kondycji, które można uruchomić indywidualnie. Trzeci tryb umożliwia uruchamianie wszystkich testów, które nie wymagają żadnych danych wejściowych parametrów.

Weryfikacja rejestracji serwera proxy

Ten test sprawdza, czy agent proxy jest prawidłowo zarejestrowany na platformie Azure i może uwierzytelniać się na platformie Azure. Pomyślny przebieg będzie wyglądać następująco:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyRegistration Passed

Jeśli zostanie wykryty błąd, test zwróci wynik Niepowodzenie i opcjonalny komunikat o błędzie. Oto przykład jednego możliwego błędu:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyRegistration Failed No proxy certificates were found - please run the Register-AzureADPasswordProtectionProxy cmdlet to register the proxy.

Weryfikacja serwera proxy kompleksowej łączności platformy Azure

Ten test jest nadzbiorem testu -VerifyProxyRegistration. Wymaga to prawidłowego zarejestrowania agenta proxy na platformie Azure, może uwierzytelnić się na platformie Azure, a na koniec dodaje sprawdzenie, czy komunikat można pomyślnie wysłać na platformę Azure, co gwarantuje, że komunikacja kompleksowa działa.

Pomyślny przebieg będzie wyglądać następująco:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyAzureConnectivity Passed

Weryfikacja serwera proxy wszystkich testów

Ten tryb umożliwia zbiorcze uruchamianie wszystkich testów obsługiwanych przez polecenie cmdlet, które nie wymaga danych wejściowych parametrów. Pomyślny przebieg będzie wyglądać następująco:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyTLSConfiguration  Passed
VerifyProxyRegistration Passed
VerifyAzureConnectivity Passed

Testowanie kondycji agenta kontrolera domeny

Polecenie cmdlet Test-AzureADPasswordProtectionDCAgentHealth obsługuje kilka testów kondycji, które można uruchomić osobno. Trzeci tryb umożliwia uruchamianie wszystkich testów, które nie wymagają żadnych danych wejściowych parametrów.

Podstawowe testy kondycji agenta kontrolera domeny

Wszystkie poniższe testy można uruchamiać indywidualnie i nie akceptują parametrów. Krótki opis każdego testu znajduje się w poniższej tabeli.

Test kondycji agenta kontrolera domeny	opis
-VerifyPasswordFilterDll	Sprawdza, czy biblioteka dll filtru haseł jest obecnie załadowana i może wywołać usługę agenta kontrolera domeny
-VerifyForestRegistration	Sprawdza, czy las jest obecnie zarejestrowany
-VerifyEncryptionDecryptionDecryption	Sprawdza, czy podstawowe szyfrowanie i odszyfrowywanie działa przy użyciu usługi KDS firmy Microsoft
-VerifyDomainIsUsingDFSR	Sprawdza, czy bieżąca domena używa usługi DFSR do replikacji folderu sysvol
-VerifyAzure Połączenie ivity	Sprawdza, czy kompleksowa komunikacja z platformą Azure działa przy użyciu dowolnego dostępnego serwera proxy

Oto przykład testu -VerifyPasswordFilterDll; pozostałe testy będą wyglądać podobnie w przypadku powodzenia:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyPasswordFilterDll Passed

Weryfikacja agenta kontrolera domeny dla wszystkich testów

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -TestAll

DiagnosticName             Result AdditionalInfo
--------------             ------ --------------
VerifyPasswordFilterDll    Passed
VerifyForestRegistration   Passed
VerifyEncryptionDecryption Passed
VerifyDomainIsUsingDFSR    Passed
VerifyAzureConnectivity    Passed

testowanie Połączenie ivity przy użyciu określonych serwerów proxy

Wiele sytuacji rozwiązywania problemów obejmuje badanie łączności sieciowej między agentami kontrolera domeny i serwerami proxy. Dostępne są dwa testy kondycji, aby skupić się na takich problemach. Te testy wymagają określenia określonego serwera proxy.

Weryfikowanie łączności między agentem kontrolera domeny a określonym serwerem proxy

Ten test weryfikuje łączność w pierwszym etapie komunikacji z agenta kontrolera domeny do serwera proxy. Sprawdza, czy serwer proxy odbiera wywołanie, jednak nie jest związana żadna komunikacja z platformą Azure. Pomyślny przebieg wygląda następująco:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyConnectivity Passed

Oto przykładowy warunek niepowodzenia, w którym usługa serwera proxy uruchomiona na serwerze docelowym została zatrzymana:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyConnectivity Failed The RPC endpoint mapper on the specified proxy returned no results; please check that the proxy service is running on that server.

Weryfikowanie łączności między agentem kontrolera domeny a platformą Azure (przy użyciu określonego serwera proxy)

Ten test weryfikuje kompleksową łączność między agentem kontrolera domeny a platformą Azure przy użyciu określonego serwera proxy. Pomyślny przebieg wygląda następująco:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyAzureConnectivityViaSpecificProxy bpl2.bpl.com

DiagnosticName                          Result AdditionalInfo
--------------                          ------ --------------
VerifyAzureConnectivityViaSpecificProxy Passed

Następne kroki

Często zadawane pytania dotyczące ochrony haseł firmy Microsoft

Aby uzyskać więcej informacji na temat globalnych i niestandardowych list zakazanych haseł, zobacz artykuł Zakaz złych haseł