Share via

Felsöka: Lokalt Microsoft Entra-lösenordsskydd

  • Artikel

Efter distributionen av Microsoft Entra Password Protection kan felsökning krävas. Den här artikeln går in i detalj för att hjälpa dig att förstå några vanliga felsökningssteg.

DC-agenten kan inte hitta en proxy i katalogen

Huvudsymptomet för det här problemet är 30017-händelser i händelseloggen för DC-agentadministratören.

Den vanliga orsaken till det här problemet är att en proxyserver ännu inte har registrerats. Om en proxy har registrerats kan det uppstå en viss fördröjning på grund av ad-replikeringsfördröjning tills en viss DC-agent kan se proxyn.

DC-agenten kan inte kommunicera med en proxy

Huvudsymptomet för det här problemet är 30018-händelser i händelseloggen för DC-agentadministratören. Det här problemet kan ha flera möjliga orsaker:

  1. DC-agenten finns i en isolerad del av nätverket som inte tillåter nätverksanslutning till de registrerade proxyservrarna. Det här problemet kan vara ofarligt så länge andra DC-agenter kan kommunicera med proxyservrarna för att ladda ned lösenordsprinciper från Azure. När dessa principer har laddats ned hämtas de sedan av den isolerade domänkontrollanten via replikering av principfilerna i sysvol-resursen.

  2. Proxyvärddatorn blockerar åtkomsten till RPC-slutpunktsmappningsslutpunkten (port 135)

    Installationsprogrammet för Microsoft Entra-lösenordsskyddsproxy skapar automatiskt en inkommande Regel för Windows-brandväggen som ger åtkomst till port 135. Om den här regeln senare tas bort eller inaktiveras kan DC-agenter inte kommunicera med proxytjänsten. Om den inbyggda Windows-brandväggen har inaktiverats i stället för en annan brandväggsprodukt måste du konfigurera brandväggen för att tillåta åtkomst till port 135.

  3. Proxyvärddatorn blockerar åtkomsten till RPC-slutpunkten (dynamisk eller statisk) som lyssnar på av proxytjänsten

    Installationsprogrammet för Microsoft Entra-lösenordsskyddsproxy skapar automatiskt en inkommande Windows-brandväggsregel som ger åtkomst till alla inkommande portar som lyssnar på av Microsoft Entra-tjänsten för lösenordsskyddsproxy. Om den här regeln senare tas bort eller inaktiveras kan DC-agenter inte kommunicera med proxytjänsten. Om den inbyggda Windows-brandväggen har inaktiverats i stället för en annan brandväggsprodukt måste du konfigurera brandväggen för att tillåta åtkomst till alla inkommande portar som lyssnar på av Microsoft Entra Password Protection Proxy-tjänsten. Den här konfigurationen kan göras mer specifik om proxytjänsten har konfigurerats för att lyssna på en specifik statisk RPC-port (med hjälp av cmdleten Set-AzureADPasswordProtectionProxyConfiguration ).

  4. Proxyvärddatorn är inte konfigurerad för att tillåta domänkontrollanter möjligheten att logga in på datorn. Det här beteendet styrs via tilldelningen "Åtkomst till den här datorn från nätverket" för användarbehörighet. Alla domänkontrollanter i alla domäner i skogen måste beviljas den här behörigheten. Den här inställningen är ofta begränsad som en del av en större nätverkshärdning.

Proxytjänsten kan inte kommunicera med Azure

  1. Kontrollera att proxydatorn har anslutning till de slutpunkter som anges i distributionskraven.

  2. Kontrollera att skogen och alla proxyservrar är registrerade mot samma Azure-klientorganisation.

    Du kan kontrollera det här kravet genom att köra Get-AzureADPasswordProtectionProxy powershell-cmdletarna och Get-AzureADPasswordProtectionDCAgent sedan jämföra egenskapen för AzureTenant varje returnerat objekt. För korrekt åtgärd måste det rapporterade klientnamnet vara detsamma för alla DC-agenter och proxyservrar.

    Om det finns ett felmatchningsvillkor för azure-klientorganisationsregistrering kan det här problemet åtgärdas genom att köra Register-AzureADPasswordProtectionProxy och/eller Register-AzureADPasswordProtectionForest PowerShell-cmdletar efter behov, och se till att använda autentiseringsuppgifter från samma Azure-klientorganisation för alla registreringar.

DC-agenten kan inte kryptera eller dekryptera lösenordsprincipfiler

Microsoft Entra Password Protection har ett kritiskt beroende av krypterings- och dekrypteringsfunktionerna som tillhandahålls av Microsoft Key Distribution Service. Krypterings- eller dekrypteringsfel kan manifesteras med en mängd olika symtom och ha flera potentiella orsaker.

  1. Kontrollera att KDS-tjänsten är aktiverad och funktionell på alla Windows Server 2012- och senare domänkontrollanter i en domän.

    Som standard konfigureras KDS-tjänstens tjänststartläge som manuell (start av utlösare). Den här konfigurationen innebär att den startas på begäran första gången en klient försöker använda tjänsten. Det här standardläget för tjänststart är acceptabelt för att Microsoft Entra Password Protection ska fungera.

    Om KDS-tjänstens startläge har konfigurerats till Inaktiverat måste den här konfigurationen åtgärdas innan Microsoft Entra Password Protection fungerar korrekt.

    Ett enkelt test för det här problemet är att starta KDS-tjänsten manuellt, antingen via MMC-konsolen för tjänsthantering eller med andra hanteringsverktyg (kör till exempel "net start kdssvc" från en kommandotolkkonsol). KDS-tjänsten förväntas starta och fortsätta att köras.

    Den vanligaste rotorsaken till att KDS-tjänsten inte kan starta är att Active Directory-domänkontrollantobjektet finns utanför standarddomänkontrollanternas organisationsenhet. Den här konfigurationen stöds inte av KDS-tjänsten och är inte en begränsning som införts av Microsoft Entra Password Protection. Korrigeringen för det här villkoret är att flytta domänkontrollantobjektet till en plats under standardenheten domänkontrollanter.

  2. InkompatibelT KDS-krypterat buffertformat ändras från Windows Server 2012 R2 till Windows Server 2016

    En KDS-säkerhetskorrigering introducerades i Windows Server 2016 som ändrar formatet för KDS-krypterade buffertar. Dessa buffertar kan ibland misslyckas med att dekryptera på Windows Server 2012 och Windows Server 2012 R2. Den omvända riktningen är okej – buffertar som är KDS-krypterade på Windows Server 2012 och Windows Server 2012 R2 kommer alltid att dekrypteras på Windows Server 2016 och senare. Om domänkontrollanterna i dina Active Directory-domäner kör en blandning av dessa operativsystem kan tillfälliga microsoft Entra-lösenordsskyddsfel rapporteras. Det går inte att exakt förutsäga tidpunkten eller symtomen för dessa fel med tanke på säkerhetskorrigeringens natur, och med tanke på att det är icke-deterministiskt vilken Microsoft Entra Password Protection DC-agent som domänkontrollanten ska kryptera data på vid en viss tidpunkt.

    Det finns ingen lösning för det här problemet förutom att inte köra en blandning av dessa inkompatibla operativsystem i dina Active Directory-domäner. Med andra ord bör du bara köra Windows Server 2012- och Windows Server 2012 R2-domänkontrollanter, ELLER så bör du bara köra Windows Server 2016 och senare domänkontrollanter.

DC-agenten tror att skogen inte har registrerats

Symptomet på det här problemet är att 30016-händelser loggas i DC Agent\Admin-kanalen som delvis säger:

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

Det finns två möjliga orsaker till det här problemet.

  1. Skogen har verkligen inte registrerats. Lös problemet genom att köra kommandot Register-AzureADPasswordProtectionForest enligt beskrivningen i distributionskraven.
  2. Skogen har registrerats, men DC-agenten kan inte dekryptera skogsregistreringsdata. Det här fallet har samma rotorsak som problemet #2 som anges ovan under DC-agenten kan inte kryptera eller dekryptera lösenordsprincipfiler. Ett enkelt sätt att bekräfta den här teorin är att du endast ser det här felet på DC-agenter som körs på Windows Server 2012- eller Windows Server 2012R2-domänkontrollanter, medan DC-agenter som körs på Windows Server 2016 och senare domänkontrollanter är bra. Lösningen är densamma: uppgradera alla domänkontrollanter till Windows Server 2016 eller senare.

Svaga lösenord accepteras men bör inte

Det här problemet kan ha flera orsaker.

  1. Dina DC-agenter kör en offentlig förhandsversion av programvara som har upphört att gälla. Se Allmän förhandsversion av DC-agentprogramvaran har upphört att gälla.

  2. Dc-agenterna kan inte ladda ned en princip eller kan inte dekryptera befintliga principer. Sök efter möjliga orsaker i ovanstående avsnitt.

  3. Tvingande läge för lösenordsprincip är fortfarande inställt på Granskning. Om den här konfigurationen är i kraft konfigurerar du om den till Framtvinga med hjälp av Microsoft Entra-portalen för lösenordsskydd. Mer information finns i Driftlägen.

  4. Lösenordsprincipen har inaktiverats. Om den här konfigurationen är i kraft konfigurerar du om den till aktiverad med hjälp av Microsoft Entra Password Protection-portalen. Mer information finns i Driftlägen.

  5. Du har inte installerat DC-agentprogramvaran på alla domänkontrollanter i domänen. I den här situationen är det svårt att se till att fjärranslutna Windows-klienter riktar in sig på en viss domänkontrollant under en lösenordsändring. Om du tror att du har riktat in dig på en viss domänkontrollant där DC-agentprogramvaran är installerad kan du verifiera genom att dubbelkolla händelseloggen för DC-agentadministratören: oavsett utfall kommer det att finnas minst en händelse för att dokumentera resultatet av lösenordsvalidering. Om det inte finns någon händelse för den användare vars lösenord har ändrats bearbetades troligen lösenordsändringen av en annan domänkontrollant.

    Som ett alternativt test kan du prova att ange\ändra lösenord när du är inloggad direkt till en domänkontrollant där DC-agentprogramvaran är installerad. Den här tekniken rekommenderas inte för Active Directory-produktionsdomäner.

    Även om inkrementell distribution av DC-agentprogramvaran stöds med dessa begränsningar rekommenderar Microsoft starkt att DC-agentprogramvaran installeras på alla domänkontrollanter i en domän så snart som möjligt.

  6. Algoritmen för lösenordsverifiering kan faktiskt fungera som förväntat. Se Hur utvärderas lösenord.

Ntdsutil.exe kan inte ange ett svagt DSRM-lösenord

Active Directory verifierar alltid ett nytt lösenord för reparationsläge för Directory Services för att se till att det uppfyller domänens krav på lösenordskomplexitet. Den här verifieringen anropar även lösenordsfilter-dll:er som Microsoft Entra Password Protection. Om det nya DSRM-lösenordet avvisas visas följande felmeddelande:

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

När Microsoft Entra Password Protection loggar händelselogghändelserna för lösenordsverifiering för ett Active Directory DSRM-lösenord förväntas händelseloggmeddelandena inte innehålla något användarnamn. Det här beteendet beror på att DSRM-kontot är ett lokalt konto som inte ingår i den faktiska Active Directory-domänen.

Befordran av domänkontrollantreplik misslyckas på grund av ett svagt DSRM-lösenord

Under DC-befordran skickas det nya lösenordet för reparationsläget för Directory Services till en befintlig domänkontrollant i domänen för validering. Om det nya DSRM-lösenordet avvisas visas följande felmeddelande:

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.

Precis som i ovanstående problem har alla utfall av lösenordsvalidering i Microsoft Entra Lösenordsskydd tomma användarnamn för det här scenariot.

Degradering av domänkontrollant misslyckas på grund av ett svagt lokalt administratörslösenord

Det stöds för att degradera en domänkontrollant som fortfarande kör DC-agentprogramvaran. Administratörer bör dock vara medvetna om att DC-agentprogramvaran fortsätter att tillämpa den aktuella lösenordsprincipen under degraderingsproceduren. Det nya lokala administratörskontots lösenord (som anges som en del av degraderingsåtgärden) verifieras som andra lösenord. Microsoft rekommenderar att säkra lösenord väljs för lokala administratörskonton som en del av en DC-degraderingsprocedur.

När degraderingen har slutförts och domänkontrollanten har startats om och körs igen som en vanlig medlemsserver återgår DC-agentprogramvaran till att köras i passivt läge. Den kan sedan avinstalleras när som helst.

Starta i reparationsläge för Directory Services

Om domänkontrollanten startas i reparationsläget för Directory Services identifierar DLL:n för dc-agentens lösenordsfilter detta villkor och gör att alla aktiviteter för lösenordsverifiering eller tvingande inaktiveras, oavsett den aktiva principkonfigurationen. DLL:n för dc-agentens lösenordsfilter loggar en varningshändelse från 10023 till händelseloggen Administratör, till exempel:

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.

Dc-agentprogramvaran för offentlig förhandsversion har upphört att gälla

Under den offentliga förhandsversionen av Microsoft Entra Password Protection hårdkodades DC-agentprogramvaran för att sluta bearbeta begäranden om lösenordsverifiering på följande datum:

  • Version 1.2.65.0 slutar behandla begäranden om lösenordsverifiering den 1 september 2019.
  • Version 1.2.25.0 och tidigare slutade behandla begäranden om lösenordsvalidering den 1 juli 2019.

När tidsgränsen närmar sig genererar alla tidsbegränsade DC-agentversioner en 10021-händelse i händelseloggen för DC-agentadministratören vid starttillfället som ser ut så här:

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.

När tidsgränsen har passerat genererar alla tidsbegränsade DC-agentversioner en 10022-händelse i dc-agentens administratörshändelselogg vid starttillfället som ser ut så här:

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.

Eftersom tidsgränsen endast kontrolleras vid den första starten kanske du inte ser dessa händelser förrän långt efter att kalenderfristen har passerat. När tidsgränsen har identifierats kommer inga negativa effekter på domänkontrollanten eller den större miljön att inträffa förutom att alla lösenord godkänns automatiskt.

Viktigt!

Microsoft rekommenderar att dc-agenter för offentlig förhandsversion som upphört att gälla omedelbart uppgraderas till den senaste versionen.

Ett enkelt sätt att identifiera DC-agenter i din miljö som behöver uppgraderas är genom att köra cmdleten Get-AzureADPasswordProtectionDCAgent , till exempel:

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

I det här avsnittet är fältet SoftwareVersion uppenbarligen nyckelegenskapen att titta på. Du kan också använda PowerShell-filtrering för att filtrera bort DC-agenter som redan är vid eller över den nödvändiga baslinjeversionen, till exempel:

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

Programvaran Microsoft Entra Password Protection Proxy är inte tidsbegränsad i någon version. Microsoft rekommenderar fortfarande att både DC- och proxyagenter uppgraderas till de senaste versionerna när de släpps. Cmdleten Get-AzureADPasswordProtectionProxy kan användas för att hitta proxyagenter som kräver uppgraderingar, ungefär som exemplet ovan för DC-agenter.

Mer information om specifika uppgraderingsprocedurer finns i Uppgradera DC-agenten och Uppgradera proxytjänsten.

Nödreparation

Om en situation uppstår där DC-agenttjänsten orsakar problem kan DC-agenttjänsten stängas av omedelbart. DLL:n för dc-agentens lösenordsfilter försöker fortfarande anropa den tjänst som inte körs och loggar varningshändelser (10012, 10013), men alla inkommande lösenord accepteras under den tiden. DC-agenttjänsten kan sedan också konfigureras via Windows Service Control Manager med starttypen "Inaktiverad" efter behov.

Ett annat åtgärdsmått är att ange Aktivera läge till Nej i Microsoft Entra Password Protection-portalen. När den uppdaterade principen har laddats ned hamnar varje DC-agenttjänst i ett quiescent-läge där alla lösenord accepteras som de är. Mer information finns i Driftlägen.

Borttagning

Om du väljer att avinstallera Microsoft Entra-programvaran för lösenordsskydd och rensa alla relaterade tillstånd från domänerna och skogen kan den här uppgiften utföras med hjälp av följande steg:

Viktigt!

Det är viktigt att utföra de här stegen i ordning. Om någon instans av proxytjänsten körs kommer den regelbundet att återskapa sin tjänst Anslut ionPoint-objekt. Om någon instans av DC-agenttjänsten körs kommer den regelbundet att återskapa tjänsten Anslut ionPoint-objektet och sysvol-tillståndet.

  1. Avinstallera proxyprogramvaran från alla datorer. Det här steget kräver ingen omstart.

  2. Avinstallera DC Agent-programvaran från alla domänkontrollanter. Det här steget kräver en omstart.

  3. Ta bort alla proxytjänstanslutningspunkter manuellt i varje domännamngivningskontext. Platsen för dessa objekt kan identifieras med följande Active Directory PowerShell-kommando:

    $scp = "serviceConnectionPoint"
$keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }

    Utelämna inte asterisken ("*") i slutet av $keywords variabelvärdet.

    De resulterande objekten Get-ADObject som hittas via kommandot kan sedan skickas till Remove-ADObjecteller tas bort manuellt.

  4. Ta bort alla DC-agentanslutningspunkter manuellt i varje domännamngivningskontext. Det kan finnas ett objekt per domänkontrollant i skogen, beroende på hur mycket programvaran har distribuerats. Platsen för objektet kan identifieras med följande Active Directory PowerShell-kommando:

    $scp = "serviceConnectionPoint"
$keywords = "{2bac71e6-a293-4d5b-ba3b-50b995237946}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }

    De resulterande objekten Get-ADObject som hittas via kommandot kan sedan skickas till Remove-ADObjecteller tas bort manuellt.

    Utelämna inte asterisken ("*") i slutet av $keywords variabelvärdet.

  5. Ta bort konfigurationstillståndet på skogsnivå manuellt. Skogskonfigurationstillståndet underhålls i en container i namngivningskontexten för Active Directory-konfigurationen. Den kan identifieras och tas bort på följande sätt:

    $passwordProtectionConfigContainer = "CN=Azure AD Password Protection,CN=Services," + (Get-ADRootDSE).configurationNamingContext
Remove-ADObject -Recursive $passwordProtectionConfigContainer

  6. Ta bort alla sysvol-relaterade tillstånd manuellt genom att ta bort följande mapp och allt dess innehåll manuellt:

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

    Om det behövs kan den här sökvägen också nås lokalt på en viss domänkontrollant. standardplatsen skulle likna följande sökväg:

    %windir%\sysvol\domain\Policies\AzureADPasswordProtection

    Den här sökvägen skiljer sig om sysvol-resursen har konfigurerats på en plats som inte är standard.

Hälsotestning med PowerShell-cmdletar

PowerShell-modulen AzureADPasswordProtection innehåller två hälsorelaterade cmdletar som utför grundläggande verifiering av att programvaran är installerad och fungerar. Det är en bra idé att köra dessa cmdletar när du har konfigurerat en ny distribution, därefter regelbundet och när ett problem undersöks.

Varje enskilt hälsotest returnerar ett grundläggande godkänt eller misslyckat resultat, plus ett valfritt meddelande om fel. Om orsaken till ett fel inte är tydlig letar du efter felmeddelanden i händelseloggen som kan förklara felet. Det kan också vara användbart att aktivera textloggmeddelanden. Mer information finns i Övervaka Microsoft Entra-lösenordsskydd.

Hälsotestning av proxy

Cmdleten Test-AzureADPasswordProtectionProxyHealth stöder två hälsotester som kan köras individuellt. Ett tredje läge tillåter körning av alla tester som inte kräver några parameterindata.

Verifiering av proxyregistrering

Det här testet verifierar att proxyagenten är korrekt registrerad med Azure och kan autentisera till Azure. En lyckad körning ser ut så här:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

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

Om ett fel upptäcks returnerar testet ett misslyckat resultat och ett valfritt felmeddelande. Här är ett exempel på ett möjligt fel:

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.

Proxyverifiering av Azure-anslutning från slutpunkt till slutpunkt

Det här testet är en supermängd av testet -VerifyProxyRegistration. Det kräver att proxyagenten är korrekt registrerad med Azure, kan autentisera till Azure och slutligen lägger till en kontroll av att ett meddelande kan skickas till Azure, vilket verifierar att fullständig kommunikation från slutpunkt till slutpunkt fungerar.

En lyckad körning ser ut så här:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity

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

Proxyverifiering av alla tester

Det här läget tillåter masskörning av alla tester som stöds av cmdleten som inte kräver parameterindata. En lyckad körning ser ut så här:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll

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

Hälsotestning av DC-agent

Cmdleten Test-AzureADPasswordProtectionDCAgentHealth stöder flera hälsotester som kan köras individuellt. Ett tredje läge tillåter körning av alla tester som inte kräver några parameterindata.

Grundläggande hälsotester för DC-agent

Följande tester kan köras individuellt och accepterar inte parametrar. En kort beskrivning av varje test visas i följande tabell.

Hälsotest för DC-agent beskrivning
-VerifyPasswordFilterDll Verifierar att dll-filen för lösenordsfiltret för närvarande är inläst och kan anropa DC-agenttjänsten
-VerifyForestRegistration Verifierar att skogen för närvarande är registrerad
-VerifyEncryptionDecryption Verifierar att grundläggande kryptering och dekryptering fungerar med hjälp av Microsoft KDS-tjänsten
-VerifyDomainIsUsingDFSR Verifierar att den aktuella domänen använder DFSR för sysvol-replikering
-VerifyAzure Anslut ivity Verifierar att kommunikation från slutpunkt till slutpunkt med Azure fungerar med alla tillgängliga proxyservrar

Här är ett exempel på testöverföringen -VerifyPasswordFilterDll. de andra testerna ser ut ungefär så här:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll

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

DC-agentverifiering av alla tester

Det här läget tillåter masskörning av alla tester som stöds av cmdleten som inte kräver parameterindata. En lyckad körning ser ut så här:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -TestAll

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

Anslut ivitetstestning med specifika proxyservrar

Många felsökningssituationer handlar om att undersöka nätverksanslutningen mellan DC-agenter och proxyservrar. Det finns två tillgängliga hälsotester för att fokusera på sådana frågor specifikt. Dessa tester kräver att en viss proxyserver anges.

Verifiera anslutningen mellan en DC-agent och en specifik proxy

Det här testet validerar anslutningen via den första kommunikationssträckan från DC-agenten till proxyn. Den verifierar att proxyn tar emot anropet, men ingen kommunikation med Azure ingår. En lyckad körning ser ut så här:

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

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

Här är ett exempel på ett feltillstånd där proxytjänsten som körs på målservern har stoppats:

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.

Verifiera anslutningen mellan en DC-agent och Azure (med hjälp av en specifik proxy)

Det här testet validerar fullständig anslutning från slutpunkt till slutpunkt mellan en DC-agent och Azure med hjälp av en specifik proxy. En lyckad körning ser ut så här:

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

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

Nästa steg

Vanliga frågor och svar om Microsoft Entra Password Protection

Mer information om listan över globala och anpassade förbjudna lösenord finns i artikeln Ban bad passwords (Förbjuda felaktiga lösenord)