Teilen über

Problembehandlung: Lokaler Microsoft Entra-Kennwortschutz

  • Artikel

Nach der Bereitstellung von Microsoft Entra Password Protection ist möglicherweise eine Problembehandlung erforderlich. In diesem Artikel werden einige häufige Schritte zur Problembehandlung erläutert.

Der DC-Agent kann keinen Proxy im Verzeichnis finden.

Das wichtigste Anzeichen für dieses Problem sind Ereignisse vom Typ „30,017“ im Administratorereignisprotokoll des DC-Agents.

Die übliche Ursache für dieses Problem ist, dass ein Proxy nicht registriert wurde. Wenn ein Proxy registriert ist, kann es aufgrund der Active Directory-Replikationslatenz zu einer Verzögerung kommen, bis ein spezifischer DC-Agent diesen Proxy sehen kann.

Der DC-Agent kann nicht mit einem Proxy kommunizieren.

Das wichtigste Anzeichen für dieses Problem sind Ereignisse vom Typ „30,018“ im Administratorereignisprotokoll des DC-Agents. Dieses Problem kann mehrere mögliche Ursachen haben:

  • Der DC-Agent befindet sich in einem isolierten Teil des Netzwerks, der keine Netzwerkkonnektivität mit den registrierten Proxys zulässt. Dieses Problem kann harmlos sein, solange andere DC-Agenten mit den Proxys kommunizieren können, um Kennwortrichtlinien von Azure herunterzuladen. Nach dem Herunterladen werden diese Richtlinien vom isolierten Domänencontroller (DC) per Replikation der Richtliniendateien in der SYSVOL-Freigabe abgerufen.

  • Der Proxyhostcomputer blockiert den Zugriff auf den RPC-Endpunktzuordnungsendpunkt (Port 135).

    Das Microsoft Entra Password Protection Proxy-Installationsprogramm erstellt automatisch eine eingehende Windows-Firewall-Regel, die den Zugriff auf Port 135 ermöglicht. Wenn diese Regel später gelöscht oder deaktiviert wird, können DC-Agents nicht mit dem Proxydienst kommunizieren. Wenn die integrierte Windows-Firewall anstelle eines anderen Firewallprodukts deaktiviert ist, müssen Sie diese Firewall so konfigurieren, dass der Zugriff auf Port 135 ermöglicht wird.

  • Der Proxyhostcomputer blockiert den Zugriff auf den RPC-Endpunkt (dynamisch oder statisch), an dem der Proxydienst lauscht.

    Das Installationsprogramm für den Proxy des Microsoft Entra-Kennwortschutzes erstellt automatisch eine eingehende Windows-Firewallregel, die den Zugriff auf alle eingehenden Ports zulässt, an denen der Proxydienst des Microsoft Entra-Kennwortschutzes lauscht. Wenn diese Regel später gelöscht oder deaktiviert wird, können DC-Agents nicht mit dem Proxydienst kommunizieren. Wenn die integrierte Windows-Firewall deaktiviert wird, um stattdessen ein anderes Firewallprodukt zu verwenden, müssen Sie diese andere Firewall zum Zulassen des Zugriffs auf alle eingehenden Ports konfigurieren, an denen der Proxydienst des Microsoft Entra-Kennwortschutzes lauscht. Diese Konfiguration kann spezifischer erfolgen, wenn der Proxydienst für die Überwachung eines bestimmten statischen RPC-Ports konfiguriert ist (mithilfe des Cmdlets Set-AzureADPasswordProtectionProxyConfiguration).

  • Der Proxyhostcomputer ist nicht so konfiguriert, dass Domänencontroller die Möglichkeit haben, sich beim Computer anzumelden. Dieses Verhalten wird über die Benutzerberechtigungszuweisung "Zugriff auf diesen Computer aus dem Netzwerk" gesteuert. Allen Domänencontrollern in allen Domänen in der Gesamtstruktur muss diese Berechtigung erteilt werden. Diese Einstellung wird häufig im Rahmen eines größeren Aufwands für die Netzwerkhärtung eingeschränkt.

Der Proxydienst kann nicht mit Azure kommunizieren.

  1. Stellen Sie sicher, dass der Proxy-Computer eine Verbindung zu den Endpunkten hat, die in den -Bereitstellungsanforderungenaufgeführt sind.

  2. Stellen Sie sicher, dass die Gesamtstruktur und alle Proxyserver für denselben Azure-Mandanten registriert sind.

    Sie können diese Anforderung überprüfen, indem Sie die Get-AzureADPasswordProtectionProxy- und Get-AzureADPasswordProtectionDCAgent-PowerShell-Cmdlets ausführen und dann die AzureTenant-Eigenschaft jedes zurückgegebenen Elements vergleichen. Zur ordnungsgemäßen Ausführung muss der gemeldete Mandantenname für alle DC-Agents und Proxyserver identisch sein.

    Wenn eine Nichtübereinstimmung der Azure-Mandantenregistrierung vorliegt, kann dieses Problem behoben werden, indem die Register-AzureADPasswordProtectionProxy und/oder Register-AzureADPasswordProtectionForest PowerShell-Cmdlets nach Bedarf ausgeführt werden. Stellen Sie sicher, dass Sie anmeldeinformationen aus demselben Azure-Mandanten für alle Registrierungen verwenden.

DC-Agent kann Kennwortrichtliniendateien nicht verschlüsseln oder entschlüsseln

Der Microsoft Entra-Kennwortschutz hat eine wichtige Abhängigkeit von der Verschlüsselungs- und Entschlüsselungsfunktion, die vom Microsoft Key Distribution Service bereitgestellt wird. Verschlüsselungs- oder Entschlüsselungsfehler können sich mit verschiedenen Symptomen manifestieren und mehrere mögliche Ursachen haben.

  • Stellen Sie sicher, dass der KDS-Dienst auf allen Windows Server 2012- und höher-Domänencontrollern in einer Domäne aktiviert und funktionsfähig ist.

    Standardmäßig ist der Dienststartmodus des KDS-Diensts als manuell (Triggerstart) konfiguriert. Bei dieser Konfiguration wird der Dienst bei Bedarf gestartet, wenn ein Client zum ersten Mal versucht, ihn zu verwenden. Dieser Standarddienststartmodus ist zulässig, damit der Kennwortschutz von Microsoft Entra funktioniert.

    Wenn der KDS-Dienststartmodus auf "Deaktiviert" konfiguriert ist, muss diese Konfiguration behoben werden, bevor der Kennwortschutz von Microsoft Entra ordnungsgemäß funktioniert.

    Ein einfacher Test für dieses Problem besteht darin, den KDS-Dienst manuell zu starten, entweder über die MMC-Konsole der Dienstverwaltung oder mithilfe anderer Verwaltungstools (z. B. "net start kdssvc" über eine Eingabeaufforderungskonsole ausführen). Es wird erwartet, dass der KDS-Dienst erfolgreich startet und im Betrieb bleibt.

    Wenn der Schlüsselverteilungsdienst nicht gestartet werden kann, liegt dies in den meisten Fällen daran, dass sich das Active Directory-Domänencontrollerobjekt außerhalb der Standardorganisationseinheit der Domänencontroller befindet. Diese Konfiguration wird vom KDS-Dienst nicht unterstützt und ist keine Einschränkung, die von Microsoft Entra Password Protection auferlegt wird. Sie können das Problem beheben, indem Sie das Domänencontrollerobjekt an einen Speicherort unter der Standardorganisationseinheit der Domänencontroller verschieben.

  • Nicht kompatible, vom Schlüsselverteilungsdienst verschlüsselte Pufferformatänderungen zwischen Windows Server 2012 R2 und Windows Server 2016

    In Windows Server 2016 wurde ein KDS-Sicherheitspatch eingeführt, der das Format von verschlüsselten KDS-Puffern ändert. Diese Puffer können manchmal nicht auf Windows Server 2012 und Windows Server 2012 R2 entschlüsselt werden. Die umgekehrte Richtung ist in Ordnung. Puffer, die unter Windows Server 2012 und Windows Server 2012 R2 vom Schlüsselverteilungsdienst verschlüsselt wurden, werden unter Windows Server 2016 und höher immer erfolgreich entschlüsselt. Wenn die Domänencontroller in Ihren Active Directory-Domänen eine Kombination dieser Betriebssysteme ausführen, werden gelegentlich Fehler bei der Entra-Kennwortschutz-Entschlüsselung gemeldet. Es ist nicht möglich, das Timing oder die Symptome dieser Fehler im Hinblick auf die Art der Sicherheitskorrektur genau vorherzusagen. Außerdem ist es nicht deterministisch, welcher DC-Agent für den Microsoft Entra-Kennwortschutz auf welchem Domänencontroller Daten zu einem bestimmten Zeitpunkt verschlüsselt.

    Als Problemumgehung kann nur empfohlen werden, keine Kombination dieser inkompatiblen Betriebssysteme in Active Directory-Domänen auszuführen. Mit anderen Worten, Sie sollten nur Windows Server 2012- und Windows Server 2012 R2-Domänencontroller ausführen, ODER Sie sollten nur Windows Server 2016 und höher Domänencontroller ausführen.

Der Agent aus DC glaubt, dass der Wald nicht registriert wurde.

Dieses Problem äußert sich in Ereignissen vom Typ „30,016“, die im DC-Agent/Administratorkanal in etwa wie folgt protokolliert werden:

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

Für dieses Problem gibt es zwei mögliche Ursachen.

  • Der Wald wurde nicht registriert. Führen Sie zum Beheben des Problems den befehl Register-AzureADPasswordProtectionForest aus, wie in den Bereitstellungsanforderungenbeschrieben.
  • Der Wald ist registriert, jedoch kann der DC-Agent die Registrierungsdaten des Waldes nicht entschlüsseln. In diesem Fall liegt dieselbe Grundursache wie für das unter der Überschrift Der DC-Agent kann Kennwortrichtliniendateien nicht ver- oder entschlüsseln beschriebene Problem vor. Eine einfache Möglichkeit, diese Theorie zu bestätigen, besteht darin, dass dieser Fehler nur auf DC-Agents angezeigt wird, die unter Windows Server 2012 oder Windows Server 2012R2-Domänencontrollern ausgeführt werden, während DC-Agents, die unter Windows Server 2016 und höher ausgeführt werden, einwandfrei sind. Die Problemumgehung ist identisch: Upgrade aller Domänencontroller auf Windows Server 2016 oder höher.

Schwache Kennwörter werden akzeptiert, was nicht der Fall sein sollte.

Dieses Problem kann mehrere Ursachen haben.

  • Ihre DC-Agent(en) verwenden eine öffentliche Vorschauversion der Software, die abgelaufen ist. Informationen dazu finden Sie unter Öffentliche Vorschauversion der DC-Agent-Software abgelaufen.

  • Ihre DC-Agenten können keine Richtlinie herunterladen oder vorhandene Richtlinien nicht entschlüsseln. Überprüfen Sie in den vorherigen Artikeln, ob eins der dort beschriebenen Probleme die Ursache ist.

  • Der Erzwingungsmodus der Kennwortrichtlinie ist noch auf „Überwachen“ eingestellt. Wenn diese Konfiguration aktiv ist, führen Sie im Microsoft Entra-Kennwortschutzportal eine Neukonfiguration mit der Einstellung „Erzwingen“ durch. Weitere Informationen finden Sie unter Betriebsmodi.

  • Die Kennwortrichtlinie ist deaktiviert. Wenn diese Konfiguration wirksam ist, konfigurieren Sie sie neu, um sie mithilfe des Microsoft Entra Password Protection-Portals zu aktivieren. Weitere Informationen finden Sie unter Betriebsmodi.

  • Sie haben die DC-Agent-Software nicht auf allen Domänencontrollern in der Domäne installiert. In diesem Fall ist es schwierig sicherzustellen, dass Remote-Windows-Clients während eines Kennwortänderungsvorgangs auf einen bestimmten Domänencontroller abzielen. Wenn Sie glauben, dass Sie erfolgreich einen bestimmten DC anvisiert haben, auf dem die DC-Agent-Software installiert ist, können Sie dies überprüfen, indem Sie das Ereignisprotokoll des DC-Agents ansehen: Unabhängig vom Ergebnis gibt es mindestens ein Ereignis, um das Ergebnis der Kennwortüberprüfung zu dokumentieren. Wenn kein Ereignis für den Benutzer vorhanden ist, dessen Kennwort geändert wird, wurde die Kennwortänderung wahrscheinlich von einem anderen Domänencontroller verarbeitet.

    Versuchen Sie als alternativer Test, Kennwörter festzulegen\zu ändern, während Sie direkt bei einem DC angemeldet sind, bei dem die DC-Agent-Software installiert ist. Diese Technik wird für Active Directory-Produktionsdomänen nicht empfohlen.

    Während die inkrementelle Bereitstellung der DC-Agent-Software unter diesen Einschränkungen unterstützt wird, empfiehlt Microsoft dringend, dass die DC-Agent-Software so schnell wie möglich auf allen Domänencontrollern in einer Domäne installiert wird.

  • Der Kennwortüberprüfungsalgorithmus funktioniert möglicherweise wie erwartet. Siehe Wie werden Passwörterbewertet.

Ntdsutil.exe kann ein schwaches DSRM-Kennwort nicht festlegen

Active Directory überprüft immer ein neues Kennwort für den Reparaturmodus für Verzeichnisdienste, um sicherzustellen, dass es die Kennwortkomplexitätsanforderungen der Domäne erfüllt; Diese Überprüfung ruft auch Dll-Dateien für Kennwortfilter wie Microsoft Entra Password Protection auf. Wenn das neue DSRM-Kennwort abgelehnt wird, ergeben sich die folgenden Fehlermeldungen:

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

Für die vom Microsoft Entra-Kennwortschutz erfassten Ereignisprotokollereignisse zur Kennwortüberprüfung für ein Active Directory-DSRM-Kennwort wird erwartet, dass die Ereignisprotokollmeldungen keinen Benutzernamen enthalten. Dieses Verhalten tritt auf, da das DSRM-Konto ein lokales Konto ist, das nicht Teil der tatsächlichen Active Directory-Domäne ist.

Fehler beim Höherstufen des Domänencontrollerreplikats aufgrund eines unsicheren DSRM-Kennworts

Beim Höherstufen des Domänencontrollers wird das neue DSRM-Kennwort (Directory Services Repair Mode, Reparaturmodus für Verzeichnisdienste) zur Überprüfung an einen vorhandenen Domänencontroller in der Domäne übermittelt. Wenn das neue DSRM-Kennwort abgelehnt wird, ergeben sich die folgenden Fehlermeldungen:

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.

Ebenso wie beim vorherigen Problem enthält das ausgegebene Ereignis der Überprüfung durch den Microsoft Entra-Kennwortschutz für dieses Szenario leere Benutzernamen.

Die Herabstufung des Domänencontrollers schlägt aufgrund eines schwachen lokalen Administratorkennworts fehl.

Dies wird unterstützt, um einen Domänencontroller herabzustufen, der noch die DC-Agent-Software ausführt. Mitglieder des Administratorteams sollten jedoch bedenken, dass die DC-Agent-Software während der Herabstufung weiterhin die Durchsetzung der aktuellen Kennwortrichtlinie erzwingt. Das neue lokale Administratorkontokennwort (im Rahmen des Herabstufungsvorgangs angegeben) wird wie jedes andere Kennwort überprüft. Microsoft empfiehlt, sichere Kennwörter für lokale Administratorkonten als Teil einer DC-Herabstufungsprozedur zu wählen.

Wenn die Herabstufung erfolgreich war und der Domänencontroller neu gestartet wurde und wieder als normaler Mitgliedsserver ausgeführt wird, kehrt die DC-Agent-Software zur Ausführung im passiven Modus zurück. Sie kann dann jederzeit deinstalliert werden.

Start im Reparaturmodus für Verzeichnisdienste

Wenn der Domänencontroller im Reparaturmodus für Verzeichnisdienste gestartet wird, erkennt die Kennwortfilter-DLL des DC-Agents diese Situation und bewirkt, dass alle Aktivitäten zur Kennwortüberprüfung oder -erzwingung deaktiviert werden, unabhängig von der derzeit aktiven Richtlinienkonfiguration. Die DLL des DC-Agent-Kennwortfilters protokolliert ein 10023-Warnungsereignis im Administratorereignisprotokoll, z. B.:

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.

Öffentliche Vorschauversion der DC-Agent-Software abgelaufen

Während der öffentlichen Vorschauphase des Microsoft Entra-Kennwortschutzes war die DC-Agent-Software hartcodiert, um die Verarbeitung von Kennwortüberprüfungsanforderungen an den folgenden Terminen zu beenden:

  • Version 1.2.65.0 hat die Verarbeitung von Kennwortüberprüfungsanforderungen am 1. September 2019 beendet.
  • Version 1.2.25.0 und frühere Versionen haben die Verarbeitung von Kennwortüberprüfungsanforderungen am 1. Juli 2019 eingestellt.

Bei Näherrücken des Stichtags geben alle zeitlich begrenzten DC-Agent-Versionen zum Startzeitpunkt ein Ereignis vom Typ „10021“ im DC-Agent-Administratorereignisprotokoll aus, das Folgendem ähnelt:

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.

Nach dem Stichtag geben alle zeitlich begrenzten DC-Agent-Versionen zum Startzeitpunkt ein Ereignis vom Typ „10022“ im DC-Agent-Administratorereignisprotokoll aus, das Folgendem ähnelt:

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.

Da der Ablauftermin nur beim ersten Start geprüft wird, werden diese Ereignisse möglicherweise erst lange nach Ablauf der Frist angezeigt. Sobald der Stichtag erkannt wird, treten keine negativen Auswirkungen auf den Domänencontroller oder die größere Umgebung auf, abgesehen davon, dass alle Kennwörter automatisch genehmigt werden.

Wichtig

Microsoft empfiehlt, für abgelaufene DC-Agents in der öffentlichen Vorschauversion sofort ein Upgrade auf die aktuelle Version durchzuführen.

Eine einfache Möglichkeit, DC-Agents in Ihrer Umgebung zu ermitteln, die ein Upgrade erfordern, besteht darin, das cmdlet Get-AzureADPasswordProtectionDCAgent auszuführen, z. B.:

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

In diesem Artikel enthält das Feld „SoftwareVersion“ natürlich die wichtigste Eigenschaft. Sie können auch die PowerShell-Filterung verwenden, um DC-Agents herauszufiltern, die bereits über mindestens die erforderliche Basisversion verfügen. Beispiel:

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

Die Microsoft Entra Password Protection Proxy-Software ist in keiner Version zeitlich begrenzt. Microsoft empfiehlt dennoch, dass sowohl für DC- als auch Proxy-Agents ein Upgrade auf die aktuellen Versionen durchgeführt wird, sobald diese veröffentlicht werden. Das cmdlet Get-AzureADPasswordProtectionProxy kann verwendet werden, um Proxy-Agents zu finden, die Upgrades erfordern, ähnlich dem obigen Beispiel für DC-Agents.

Weitere Informationen zu bestimmten Upgradeverfahren finden Sie unter Aktualisierung des DC-Agents und Aktualisierung des Proxydiensts.

Notfallbereinigung

Wenn der DC-Agent-Dienst Probleme verursacht, kann er sofort heruntergefahren werden. Die DC-Agent-Kennwortfilter-DLL versucht weiterhin, den nicht ausgeführten Dienst aufzurufen, und protokolliert Warnungsereignisse (10012, 10013), aber alle eingehenden Kennwörter werden währenddessen akzeptiert. Der DC-Agent-Dienst kann dann auch bei Bedarf über den Dienststeuerungs-Manager von Windows mit dem Starttyp „Disabled“ konfiguriert werden.

Als weitere Problembehandlungsmaßnahme könnten Sie im Microsoft Entra-Kennwortschutzportal den Aktivierungsmodus auf „Nein“ festlegen. Nachdem die aktualisierte Richtlinie heruntergeladen wurde, wechseln alle DC-Agent-Dienste in einen Ruhemodus, in dem alle Kennwörter unverändert akzeptiert werden. Weitere Informationen finden Sie unter Betriebsarten.

Entfernen

Wenn Sie die Software des Microsoft Entra-Kennwortschutzes deinstallieren und alle zugehörigen Zustandsdaten in den Domänen und der Gesamtstruktur bereinigen möchten, gehen Sie wie folgt vor:

Wichtig

Es ist wichtig, diese Schritte in der Reihenfolge auszuführen. Wenn eine Instanz des Proxydiensts weiterhin ausgeführt wird, erstellt sie ihr serviceConnectionPoint-Objekt regelmäßig neu. Wenn eine Instanz des DC-Agent-Diensts weiterhin ausgeführt wird, erstellt sie ihr serviceConnectionPoint-Objekt und den SYSVOL-Status regelmäßig neu.

  1. Deinstallieren Sie die Proxysoftware von allen Computern. Dieser Schritt erfordert keinen Neustart.

  2. Deinstallieren Sie die DC-Agent-Software von allen Domänencontrollern. Dieser Schritt erfordert einen Neustart.

  3. Entfernen Sie manuell alle Proxydienstverbindungspunkte in jedem Domänenbenennungskontext. Der Speicherort dieser Objekte kann mit dem folgenden Active Directory PowerShell-Befehl ermittelt werden:

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

    Lassen Sie nicht das Sternchen („*“) am Ende des Variablenwerts „$keywords“ aus.

    Die resultierenden Objekte, die über den Befehl Get-ADObject gefunden werden, können dann an Remove-ADObjectweitergeleitet oder manuell gelöscht werden.

  4. Entfernen Sie manuell alle DC-Agent-Verbindungspunkte in jedem Domänenbenennungskontext. Je nachdem, wie umfassend die Software bereitgestellt wurde, kann pro Domänencontroller in der Gesamtstruktur eines dieser Objekte vorhanden sein. Der Speicherort dieses Objekts kann mit dem folgenden Active Directory PowerShell-Befehl ermittelt werden:

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

    Die resultierenden Objekte, die über den Befehl Get-ADObject gefunden werden, können dann an Remove-ADObjectweitergeleitet oder manuell gelöscht werden.

    Lassen Sie das Sternchen ("*") am Ende des Variablenwerts von $keywords nicht weg.

  5. Entfernen Sie manuell den Konfigurationsstatus auf Gesamtstrukturebene. Der Konfigurationsstatus der Gesamtstruktur wird in einem Container im Active Directory-Konfigurationsnamenskontext beibehalten. Sie kann wie folgt ermittelt und gelöscht werden:

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

  6. Entfernen Sie manuell den gesamten auf SYSVOL bezogenen Status durch manuelles Löschen des folgenden Ordners und seines gesamten Inhalts:

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

    Falls erforderlich, kann auch lokal auf einem bestimmten Domänencontroller auf diesen Pfad zugegriffen werden. Der Standardspeicherort entspräche etwa dem folgenden Pfad:

    %windir%\sysvol\domain\Policies\AzureADPasswordProtection

    Dieser Pfad unterscheidet sich, wenn die SYSVOL-Freigabe an einem nicht standardmäßigen Speicherort konfiguriert ist.

Integritätstests mit PowerShell-Cmdlets

Das PowerShell-Modul "AzureADPasswordProtection" enthält zwei gesundheitsbezogene Cmdlets, um zu überprüfen, ob die Software installiert ist und funktioniert. Es ist ratsam, diese Cmdlets nach dem Einrichten einer neuen Bereitstellung in regelmäßigen Abständen sowie beim Untersuchen eines Problems auszuführen.

Für jeden einzelnen Integritätstest wird zurückgegeben, ob er erfolgreich oder nicht erfolgreich war, sowie optional eine Meldung, wenn er nicht erfolgreich war. In Fällen, in denen die Ursache eines Fehlers nicht eindeutig ist, suchen Sie nach Fehlermeldungen im Ereignisprotokoll, die den Fehler erklären können. Das Aktivieren von Textprotokollnachrichten kann auch hilfreich sein. Weitere Informationen finden Sie unter Überwachen des Microsoft Entra-Kennwortschutzes.

Proxyintegritätstests

Das Cmdlet Test-AzureADPasswordProtectionProxyHealth unterstützt zwei Gesundheitstests, die einzeln ausgeführt werden können. Ein dritter Modus ermöglicht die Ausführung aller Tests, für die keine Parametereingabe erforderlich ist.

Überprüfung der Proxyregistrierung

Dieser Test überprüft, ob der Proxy-Agent ordnungsgemäß bei Azure registriert ist und sich bei Azure authentifizieren kann. Eine erfolgreiche Ausführung sieht wie folgt aus:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

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

Wenn ein Fehler erkannt wird, gibt der Test ein Fehlgeschlagenes Ergebnis und eine optionale Fehlermeldung zurück. Hier ist ein Beispiel für einen möglichen Fehler:

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.

Proxy-Überprüfung der End-to-End-Azure-Konnektivität

Dieser Test ist eine Obermenge des Tests „-VerifyProxyRegistration“. Es erfordert, dass der Proxy-Agent ordnungsgemäß bei Azure registriert ist, in der Lage ist, sich bei Azure zu authentifizieren, und fügt schließlich eine Überprüfung hinzu, dass eine Nachricht erfolgreich an Azure gesendet werden kann, sodass die vollständige End-to-End-Kommunikation funktioniert.

Eine erfolgreiche Ausführung sieht wie folgt aus:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity

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

Proxyüberprüfung aller Tests

Dieser Modus ermöglicht die Massenausführung aller Tests, die vom Cmdlet unterstützt werden, für die keine Parametereingabe erforderlich ist. Eine erfolgreiche Ausführung sieht wie folgt aus:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll

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

Integritätstests des DC-Agents

Das Cmdlet „Test-AzureADPasswordProtectionDCAgentHealth“ unterstützt verschiedene Integritätstests, die einzeln ausgeführt werden können. Ein dritter Modus ermöglicht die Ausführung aller Tests, für die keine Parametereingabe erforderlich ist.

Allgemeine Integritätstests des DC-Agents

Die folgenden Tests können alle einzeln ausgeführt werden und akzeptieren keine Parameter. Eine kurze Beschreibung der einzelnen Tests ist in der folgenden Tabelle aufgeführt.

Integritätstest des DC-Agents Beschreibung
-VerifyPasswordFilterDll Überprüft, ob die Kennwortfilter-DLL derzeit geladen ist und den DC-Agent-Dienst aufrufen kann
-VerifyForestRegistration Überprüft, ob der Wald derzeit registriert ist.
-VerifyEncryptionDecryption Überprüft, ob die grundlegende Verschlüsselung und Entschlüsselung mit dem Microsoft KDS-Dienst funktioniert.
-VerifyDomainIsUsingDFSR Hiermit wird überprüft, ob die aktuelle Domäne DFSR für die SYSVOL-Replikation verwendet.
-Azure-Konnektivität überprüfen Überprüft, ob die End-to-End-Kommunikation mit Azure mit jedem verfügbaren Proxy funktioniert.

Im Folgenden sehen Sie ein Beispiel für das Bestehen des -VerifyPasswordFilterDll-Tests, und andere erfolgreiche Tests sehen ähnlich aus:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll

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

DC-Agent-Überprüfung aller Tests

Dieser Modus ermöglicht die Massenausführung aller Tests, die vom Cmdlet unterstützt werden, für die keine Parametereingabe erforderlich ist. Eine erfolgreiche Ausführung sieht wie folgt aus:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -TestAll

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

Konnektivitätstests mithilfe bestimmter Proxyserver

Viele Problembehandlungssituationen sind mit der Untersuchung der Netzwerkkonnektivität zwischen DC-Agents und Proxys verbunden. Es stehen zwei Gesundheitstests zur Verfügung, um sich speziell auf solche Probleme zu konzentrieren. Für diese Tests muss ein bestimmter Proxyserver angegeben werden.

Überprüfen der Konnektivität zwischen einem DC-Agent und einem bestimmten Proxy

Dieser Test überprüft die Konnektivität über den ersten Kommunikationsabschnitt vom DC-Agenten zum Proxy. Es wird überprüft, ob der Proxy den Anruf empfängt, jedoch ist keine Kommunikation mit Azure daran beteiligt. Eine erfolgreiche Ausführung sieht wie folgt aus:

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

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

Im Folgenden sehen Sie ein Beispiel einer Fehlerbedingung, bei der der auf dem Zielserver ausgeführte Proxydienst beendet wurde:

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.

Überprüfen der Konnektivität zwischen einem DC-Agent und Azure (mit einem bestimmten Proxy)

Dieser Test überprüft die vollständige End-to-End-Konnektivität zwischen einem DC-Agent und Azure mithilfe eines bestimmten Proxys. Ein erfolgreicher Lauf sieht wie folgt aus:

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

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

Nächste Schritte

Häufig gestellte Fragen zu Microsoft Entra Password Protection

Weitere Informationen zu den globalen und benutzerdefinierten Listen für gesperrte Kennwörter finden Sie im Artikel Ban bad password