In meinen Azure-Kursen taucht das Thema Entra-Kennwortschutz (Microsoft Entra Password Protection) regelmäßig auf – meistens dann, wenn jemand gerade festgestellt hat, dass „Sommer2024!“ im eigenen Active Directory problemlos als Kennwort akzeptiert wurde. Microsoft bietet mit Entra Password Protection eine Lösung, die die zentrale Kennwortrichtlinie aus der Cloud auch auf das lokale AD ausdehnt. Das klingt simpel, hat aber technisch einige Tücken: Zwei Agenten, eine Proxy-Rolle, Replikation über SYSVOL und ein eigenes AD-Partition-Schema. Wer das nicht versteht, baut es falsch – oder wundert sich später, warum verbotene Kennwörter trotzdem durchkommen.
Architektur: Die drei Bausteine im Überblick
Entra Password Protection besteht auf der lokalen Seite aus genau zwei installierbaren Komponenten sowie einer cloudbasierten Richtlinie, die alles zusammenhält. Bevor wir in die Details gehen, kurz knapp und strukturiert, zum Abharken:
| Komponente | Installationsort | Aufgabe |
|---|---|---|
| DC Agent Service | Jeder Domain Controller | Validiert Kennwörter lokal anhand der heruntergeladenen Richtlinie |
| Proxy Service | Domänenmitglied (kein DC erforderlich) | Kommuniziert mit Entra ID und lädt die Kennwortliste herunter |
| Entra-Richtlinie (Cloud) | Microsoft Entra ID (Portal) | Definiert globale und benutzerdefinierte verbotene Kennwörter sowie den Enforcement-Modus |
Wichtig: Der DC Agent braucht keinen direkten Internetzugang. Er holt sich die Richtlinie ausschließlich aus dem Active Directory – genauer gesagt aus einem speziellen Container, der vom Proxy Service befüllt wird. Der Proxy Service selbst muss Entra ID erreichen können, ist aber kein Domain Controller und muss es auch nicht sein.
Im Entra-Portal definieren Sie die globale Kennwortrichtlinie – einschließlich der benutzerdefinierten verbotenen Kennwortliste.
Was im Active Directory landet: Schema, Container und SYSVOL
Folgendes Problem aus der Praxis: Ein Kunde hatte den Proxy Service installiert und registriert, der DC Agent lief ebenfalls – aber neue Kennwörter wurden trotzdem nicht geprüft. Der Grund war, dass das AD-Schema nicht erweitert worden war und der DC Agent keine valide Richtlinie im AD vorfand. Er fiel daraufhin in den Audit-Modus zurück, ohne Fehlermeldung im Eventlog, die sofort ins Auge springt.
Was genau schreibt Entra Password Protection ins Active Directory?
- Schema-Erweiterung: Bei der Registrierung des Proxy Service werden neue AD-Attribute und Objektklassen unterhalb von
CN=Schema,CN=Configurationangelegt. Diese Erweiterung ist einmalig und erfordert Schema-Admin-Rechte. - Service-Container: Unterhalb von
CN=AzureADPasswordProtection,CN=Services,CN=Configuration,DC=…entstehen Objekte, die den Proxy Service und die heruntergeladene Richtlinie speichern. - Richtlinien-Blob: Die eigentliche Kennwortliste – verschlüsselt – wird als Attribut in diesem Container abgelegt. Der DC Agent liest diesen Blob per normaler AD-Replikation. Es gibt keinen direkten Netzwerkkanal zwischen DC Agent und Proxy Service zur Laufzeit.
SYSVOL spielt bei Entra Password Protection übrigens keine Rolle. Die Verteilung läuft vollständig über die AD-Replikation (DRS – Directory Replication Service). Das ist ein häufiges Missverständnis in meinen Azure-Kursen, wenn Teilnehmer den Mechanismus mit klassischen GPO-basierten Kennwortfiltern vergleichen.
Im ADSI-Editor sieht man nach erfolgreicher Registrierung den neuen Container samt Richtlinien-Blob und Proxy-Registrierungsobjekt.
Merksatz: Der DC Agent kommuniziert zur Laufzeit ausschließlich mit dem lokalen AD. Kein Internetzugang am DC erforderlich. Fällt der Proxy Service aus, arbeitet der DC Agent mit der zuletzt replizierten Richtlinie weiter – so lange, bis die Richtlinie ihr konfigurierbares Ablaufdatum (Standard: 7 Tage) überschreitet.
Wie der DC Agent Kennwörter tatsächlich prüft
Der DC Agent installiert sich als Password Filter DLL (AzureADPasswordProtectionDCAgent.dll) direkt in den Windows-Kennwortfilter-Stack. Das ist kein neues Konzept – Microsoft nutzt diesen Mechanismus seit Windows NT. Jede Kennwortänderung auf einem Domain Controller durchläuft alle registrierten Kennwortfilter, bevor das Kennwort akzeptiert wird.
Der Prüfalgorithmus arbeitet in mehreren Stufen:
- Normalisierung: Das Kandidatenkennwort wird auf einen Basis-String reduziert. Dabei werden typische Ersetzungen rückgängig gemacht:
@→a,3→e,0→o,$→susw. Groß-/Kleinschreibung wird ignoriert. - Substring-Matching: Der normalisierte String wird gegen alle Einträge der verbotenen Liste (globale Microsoft-Liste + benutzerdefinierte Liste) geprüft. Dabei wird nicht auf exakte Übereinstimmung geprüft, sondern auf Teilzeichenketten.
Sommer2024!scheitert, wennsommerauf der verbotenen Liste steht. - Scoring: Das Ergebnis ist ein Score. Kennwörter müssen eine Mindestpunktzahl (basierend auf nicht-verbotenen Zeichengruppen) erreichen, um akzeptiert zu werden.
Das Ganze passiert vollständig im Arbeitsspeicher des DC, synchron zur Kennwortänderungsoperation. Verzögerungen im einstelligen Millisekundenbereich sind normal und in der Praxis nicht wahrnehmbar.
Praxistipp: Betreiben Sie mehrere Domain Controller, müssen Sie den DC Agent auf jedem einzelnen installieren. Ein einzelner DC ohne Agent ist ein Bypass – Kennwortänderungen können auf jeden DC des Standorts geroutet werden. Das wird in der Planung gerne vergessen.
Die Ereignis-IDs 10014 und 10015 im Anwendungsprotokoll des DCs zeigen abgelehnte und akzeptierte Kennwörter im Audit- bzw. Enforcement-Modus.
Praxisempfehlung: Rollout-Reihenfolge für KMUs
Noch mal in Kürze – eine realistische Rollout-Reihenfolge für eine mittelständische Umgebung mit 2–5 Domain Controllern:
- Lizenzprüfung zuerst: Entra Password Protection für lokales AD erfordert mindestens Microsoft Entra ID P1 (früher Azure AD Premium P1). Das ist Teil von Microsoft 365 Business Premium – in vielen KMUs bereits vorhanden, aber nicht aktiviert.
- Proxy Service auf einem dedizierten Member-Server installieren (nicht auf einem DC, auch wenn es technisch geht). Zwei Proxy-Server für Redundanz empfohlen.
- Proxy bei Entra ID registrieren (
Register-AzureADPasswordProtectionProxy) und anschließend die Gesamtstruktur registrieren (Register-AzureADPasswordProtectionForest). Beide Schritte erfordern einen globalen Administrator. - DC Agent auf allen DCs installieren – Neustart je DC einplanen, da die Password Filter DLL einen Neustart erfordert.
- Zunächst im Audit-Modus betreiben: Im Entra-Portal den Modus auf „Audit“ belassen. Eventlog-Auswertung für 2–4 Wochen. Erst dann auf „Enforced“ umstellen.
- Benutzerdefinierte verbotene Kennwörter ergänzen: Firmenname, Stadtname, Produktnamen, Projektnamen – alles was Nutzer erfahrungsgemäß verwenden.
Wer die Grundlagen von Entra ID und Identity Protection strukturiert aufbauen möchte, findet in meinen Azure-Kursen den passenden Einstieg – inklusive Hands-on-Labs zu genau diesem Szenario.
Merksatz: Entra Password Protection ersetzt keine Multi-Faktor-Authentifizierung. Es reduziert das Risiko schwacher Kennwörter, schützt aber nicht vor geleakten, technisch starken Kennwörtern. Beides zusammen – starke Kennwörter plus MFA – ist der richtige Ansatz.