Udostępnij za pośrednictwem

Rozwiązywanie problemów: Lokalna ochrona haseł firmy Microsoft

  • Artykuł

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 jest 30 017 zdarzeń w dzienniku zdarzeń Administratora agenta DC.

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

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

Głównym objawem tego problemu jest 30 018 zdarzeń w dzienniku zdarzeń Admin agenta DC. 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 są uzyskiwane przez izolowany kontroler domeny (DC) poprzez replikację plików zasad w udziale sysvol.

  • Maszyna hosta proxy blokuje dostęp do punktu końcowego mapowania RPC (port 135)

    Instalator serwera proxy ochrony haseł Microsoft Entra 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 mogą komunikować się z usługą proxy. Jeśli wbudowana zapora systemu Windows jest wyłączona na rzecz innego produktu zapory, należy tę zaporę skonfigurować w taki sposób, aby zezwalała na dostęp do portu 135.

  • Komputer hosta proxy blokuje dostęp do punktu końcowego RPC (dynamicznego lub statycznego) nasłuchiwanego przez usługę proxy.

    Instalator Microsoft Entra Password Protection Proxy automatycznie tworzy regułę przychodzącą zapory systemu Windows, która umożliwia dostęp do dowolnych portów przychodzących nasłuchiwanych przez usługę Microsoft Entra Password Protection Proxy. Jeśli ta reguła zostanie później usunięta lub wyłączona, agenci kontrolera domeny nie mogą komunikować się z usługą proxy. Jeśli wbudowana zapora systemu Windows jest wyłączona na rzecz innego produktu zapory, należy skonfigurować tę zaporę tak, aby zezwalała na dostęp do wszystkich portów przychodzących obsługiwanych przez usługę Microsoft Entra Password Protection Proxy. Ta konfiguracja może być bardziej szczegółowa, jeśli usługa proxy jest skonfigurowana do nasłuchiwania na określonym statycznym porcie RPC (przy użyciu polecenia cmdlet Set-AzureADPasswordProtectionProxyConfiguration).

  • 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

  1. Upewnij się, że maszyna proxy ma łączność z punktami końcowymi wymienionymi w wymaganiach dotyczących wdrażania .

  2. Upewnij się, że las i wszystkie serwery proxy są zarejestrowane w tym samym dzierżawcy platformy Azure.

    To wymaganie można sprawdzić, uruchamiając polecenia cmdlet Get-AzureADPasswordProtectionProxy i Get-AzureADPasswordProtectionDCAgent programu PowerShell, a następnie porównaj właściwość AzureTenant każdego zwróconego elementu. Aby zapewnić prawidłowe działanie, podana nazwa dzierżawcy musi być identyczna 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 polecenia cmdlet Register-AzureADPasswordProtectionProxy i/lub Register-AzureADPasswordProtectionForest programu PowerShell w zależności od potrzeb, upewniając się, że używasz poświadczeń z tej samej dzierżawy platformy Azure do 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ą objawiać 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 jest skonfigurowany jako Ręczny (Rozruch na żądanie). Ta konfiguracja oznacza, że po raz pierwszy, gdy klient próbuje skorzystać z usługi, jest ona uruchamiana 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 jest skonfigurowany na wartość Wyłączone, ta konfiguracja musi zostać naprawiona, zanim usługa Microsoft Entra Password Protection będzie mogła 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 narzuconym przez usługę Microsoft Entra Password Protection. Rozwiązanie tego problemu polega na przeniesieniu obiektu kontrolera domeny do lokalizacji pod domyślną jednostką organizacyjną 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, zmieniając format zaszyfrowanych buforów KDS. Te bufory czasami nie udaje się odszyfrować na Windows Server 2012 i Windows Server 2012 R2. Odwrotny kierunek jest akceptowalny. Bufory szyfrowane funkcją KDS w systemach Windows Server 2012 i Windows Server 2012 R2 są zawsze pomyślnie odszyfrowywane w systemie Windows Server 2016 i nowszych. 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ć czasu lub objawów tych błędów, biorąc pod uwagę charakter poprawki zabezpieczeń. Ponadto, biorąc pod uwagę, że nie jest deterministyczny, który microsoft Entra Password Protection DC Agent, na którym kontroler domeny szyfruje dane w danym momencie.

    Nie istnieje obejście tego problemu inne niż unikanie uruchamiania mieszanki tych niezgodnych systemów operacyjnych w Twoich domenach usługi Active Directory. Innymi słowy, należy uruchamiać tylko kontrolery domeny Windows Server 2012 i Windows Server 2012 R2 lub tylko kontrolery domeny Windows Server 2016 i nowsze.

Agent DC uważa, że las nie został zarejestrowany

Objawem tego problemu jest rejestrowanie 30 016 zdarzeń w kanale DC Agent\Admin, które zawierają między innymi:

The forest hasn't been registered with Azure. Password policies can't be downloaded from Azure unless this is corrected.

Istnieją dwie możliwe przyczyny tego problemu.

  • Las nie został zarejestrowany. Aby rozwiązać ten problem, uruchom polecenie Register-AzureADPasswordProtectionForest zgodnie z opisem w wymaganiach dotyczących wdrażania .
  • Las jest zarejestrowany, ale agent kontrolera domeny (DC) nie może odszyfrować danych rejestracji lasu. Ten przypadek ma taką samą główną przyczynę jak problem nr 2 wymieniony w agent kontrolera domeny nie może zaszyfrować ani odszyfrować plików zasad haseł. Łatwa metoda potwierdzenia tej teorii polega na tym, że ten błąd będzie widoczny tylko na agentach kontrolera domeny działających na kontrolerach domeny z systemem Windows Server 2012 lub Windows Server 2012R2, podczas gdy agenci kontrolera domeny działający na kontrolerach domeny z systemem Windows Server 2016 i nowszymi działają poprawnie. 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 DC używają publicznej wersji przeglądowej oprogramowania, która wygasła. Zobacz Oprogramowanie agenta DC w wersji publicznej zapoznawczej wygasło.

  • Twój agent (lub agenci) kontrolera domeny nie mogą pobrać polityki ani odszyfrować istniejących polityk. Sprawdź możliwe przyczyny w poprzednich artykułach.

  • 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ł są 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 zainstalowałeś oprogramowania agenta DC na wszystkich kontrolerach w domenie. W takiej sytuacji trudno jest upewnić się, że zdalni klienci systemu Windows są kierowani do określonego kontrolera domeny podczas operacji zmiany hasła. Jeśli uważasz, że pomyślnie skierowano określony kontroler domeny, na którym zainstalowano oprogramowanie agenta, możesz to zweryfikować, przeglądając dziennik zdarzeń administratora agenta: bez względu na wynik, istnieje co najmniej jedno zdarzenie dokumentujące 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.

Ntdsutil.exe nie ustawia słabego hasła DSRM

Usługa Active Directory zawsze weryfikuje nowe hasło w Trybie naprawy usług katalogowych, aby upewnić się, że spełnia ono wymagania dotyczące złożoności hasła domeny; ta walidacja również wywołuje biblioteki DLL, takie jak Microsoft Entra Password Protection. 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 hasła 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.

Promocja 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 jest przesył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 doesn't meet a requirement of the password filter(s). Supply a suitable password.

Podobnie jak w poprzednim numerze, wszystkie zdarzenia wyników weryfikacji hasła w ramach Microsoft Entra Password Protection będą miały puste nazwy użytkowników w tym scenariuszu.

Degradacja kontrolera domeny kończy się niepowodzeniem z powodu słabego hasła administratora lokalnego

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

Gdy obniżenie poziomu zakończy się pomyślnie, a kontroler domeny zostanie uruchomiony ponownie i ponownie działa jako zwykły serwer członkowski, oprogramowanie agenta kontrolera domeny przechodzi 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 jest uruchamiany w trybie naprawy usług katalogowych, biblioteka dll filtru haseł agenta kontrolera domeny wykrywa ten warunek i powoduje wyłączenie wszystkich działań sprawdzania poprawności lub wymuszania haseł, niezależnie od aktualnie aktywnej konfiguracji zasad. Biblioteka DLL filtra haseł agenta DC rejestruje zdarzenie ostrzegawcze 10023 w dzienniku zdarzeń administratora, na przykład:

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

Oprogramowanie agenta DC w publicznej wersji testowej 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 przestała 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 czasowo ograniczone wersje agenta DC emitują zdarzenie 10021 w dzienniku zdarzeń administratora agenta DC podczas rozruchu w następującej formie:

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 no longer processes passwords. Please contact Microsoft for a newer supported version of the software.

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

This message won't be repeated until the next reboot.

Po upływie terminu wszystkie ograniczone czasowo wersje agenta DC emitują zdarzenie 10022 w dzienniku zdarzeń administratora agenta DC podczas uruchamiania, które wygląda następująco:

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

No further messages are logged until after the next reboot.

Ponieważ termin ostateczny jest sprawdzany tylko podczas początkowego rozruchu, te zdarzenia mogą być widoczne dopiero długo po upływie terminu kalendarzowego. Po rozpoznaniu terminu nie ma negatywnego wpływu na kontroler domeny ani większe środowisko, z wyjątkiem automatycznego zatwierdzania wszystkich haseł.

Ważny

Microsoft zaleca, aby agenci DC, których publiczna wersja zapoznawcza wygasła, zostali natychmiast uaktualnieni do najnowszej wersji.

Łatwym sposobem odnajdywania agentów DC w środowisku, których trzeba zaktualizować, jest uruchomienie polecenia cmdlet Get-AzureADPasswordProtectionDCAgent, 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 artykule pole SoftwareVersion jest oczywiście kluczową właściwością do analizy. Możesz również użyć filtrowania w PowerShellu, aby odfiltrować agentów kontrolera domeny, którzy już są w wersji bazowej lub wyższej, 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 cmdlet Get-AzureADPasswordProtectionProxy może służyć do znajdowania agentów proxy, które wymagają aktualizacji, podobnie jak w powyższym przykładzie dla agentów kontrolera domeny.

Zobacz Uaktualnianie agenta DC i Uaktualnianie usługi proxy, aby uzyskać więcej informacji na temat określonych procedur aktualizacji.

Działanie naprawcze w sytuacjach awaryjnych

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 DC nadal próbuje wywołać nieuruchomioną usługę i rejestruje zdarzenia ostrzegawcze (10012, 10013), ale wszystkie przychodzące hasła są akceptowane w tym czasie. Następnie można skonfigurować usługę agenta DC za pośrednictwem Menedżera usług systemu Windows, ustawiając typ uruchamiania na "Wyłączony" zgodnie z potrzebami.

Kolejnym środkiem naprawczym jest ustawienie trybu włączenia na Nie w portalu Microsoft Entra Password Protection. Po pobraniu zaktualizowanych zasad każda usługa agenta DC przechodzi w tryb spoczynku, w którym wszystkie hasła są akceptowane as-is. Aby uzyskać więcej informacji, zobacz tryby działania.

Usunięcie

Jeśli zdecydujesz się odinstalować oprogramowanie do ochrony haseł firmy Microsoft i wyczyścić wszystkie powiązane stany z domen i lasu, to zadanie można wykonać, wykonując następujące czynności:

Ważny

Ważne jest, aby wykonać te kroki w podanej kolejności. Jeśli jakiekolwiek wystąpienie usługi proxy pozostanie uruchomione, okresowo tworzy ponownie obiekt serviceConnectionPoint. Jeśli jakiekolwiek wystąpienie usługi agenta kontrolera domeny pozostanie uruchomione, okresowo tworzy ponownie obiekt serviceConnectionPoint i stan sysvol.

  1. Odinstaluj oprogramowanie proxy ze wszystkich maszyn. Ten krok nie wymaga ponownego uruchomienia.

  2. Odinstaluj oprogramowanie agenta kontrolera domeny ze wszystkich kontrolerów domeny. Ten krok wymaga ponownego uruchomienia.

  3. 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 pomocą polecenia Get-ADObject można następnie przekierować do Remove-ADObjectlub usunąć ręcznie.

  4. Ręcznie usuń wszystkie punkty połączenia agenta DC 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 polecenia Get-ADObject można następnie przesłać potokami do Remove-ADObjectlub usunąć ręcznie.

    Nie pomijaj gwiazdki ("*") na końcu wartości zmiennej $keywords.

  5. Ręcznie usuń stan konfiguracji na poziomie lasu. Stan konfiguracji lasu jest utrzymywany w kontenerze w konfiguracji nazewniczej usługi katalogowej 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

  6. 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 jest 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. Dobrym pomysłem jest uruchomienie tych poleceń cmdlet po skonfigurowaniu nowego wdrożenia, okresowo i po zbadaniu problemu.

Każdy indywidualny test zdrowia zwraca podstawowy wynik: Powodzenie lub Niepowodzenie, a w przypadku niepowodzenia opcjonalny komunikat. 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 Monitor Microsoft Entra Password Protection.

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 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 dla pełnej łączności z 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 wygląda następująco:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity

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

Weryfikacja proxy dla 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. Udany przebieg wygląda tak:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll

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

Testowanie kondycji agenta DC

Polecenie cmdlet Test-AzureADPasswordProtectionDCAgentHealth obsługuje kilka testów zdrowotnych, które można przeprowadzać 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 DC Opis
-VerifyPasswordFilterDll Sprawdza, czy biblioteka DLL filtru haseł jest obecnie załadowana i może wywołać usługę agenta DC.
-WeryfikujRejestracjęLasu Sprawdza, czy las jest obecnie zarejestrowany
-VerifyEncryptionDecryption Sprawdza, czy podstawowe szyfrowanie i odszyfrowywanie działa przy użyciu usługi KDS firmy Microsoft
-SprawdźCzyDomenaUżywaDFSR Sprawdza, czy bieżąca domena używa usługi DFSR do replikacji folderu sysvol
-VerifyAzureConnectivity Sprawdza, czy kompleksowa komunikacja z platformą Azure działa przy użyciu dowolnego dostępnego serwera proxy

Poniżej przedstawiono przykładowy przebieg testu -VerifyPasswordFilterDll, a inne pomyślne testy wyglądają podobnie:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll

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

Weryfikacja agenta kontrolera domeny dla 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 wygląda następująco:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -TestAll

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

Testowanie łączności 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 zdrowotne, 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 odcinku komunikacji z agenta DC do serwera proxy. Sprawdza, czy serwer proxy odbiera wywołanie, jednak nie ma żadnej komunikacji 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 jest 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)

Test ten weryfikuje pełną łączność końcową między agentem kontrolera domeny a platformą Azure przez specyficzny serwer 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 usługi Microsoft Entra Password Protection

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