Welche Sicherheitsfehlkonfigurationen in Active Directory sind am haeufigsten? 10 Probleme, die Sie zuerst beheben sollten

Wenn Teams fragen, welche Sicherheitsfehlkonfigurationen in Active Directory sind am haeufigsten, ist die nützliche Antwort keine Häufigkeitstabelle. Relevant ist die Menge an Kontrollfehlern, die in Microsoft-Hardening-Guides, ANSSI-Empfehlungen und wiederkehrenden AD-Reviews immer wieder auftauchen, weil sie weiterhin echte Pfade für Privilegieneskalation, Anmeldeinformations-Exposition oder Sichtbarkeitslücken offenlassen.

Dieser Artikel zeigt die misconfigurations-Sicht auf Active Directory. Er ist weder eine vollständige Audit-Checkliste wie Active Directory Sicherheit auditieren: Checkliste noch ein Rollout-Leitfaden wie Active Directory haerten: Was Sie zuerst absichern und wie Sie es validieren. Das Ziel ist enger: die AD-Fehlkonfigurationen zu identifizieren, die weiterhin am meisten zählen, zu erklären, warum sie zählen, und zu zeigen, was vor und nach einer Korrektur validiert werden muss.

Was gilt als Sicherheitsfehlkonfiguration in Active Directory?

Eine Sicherheitsfehlkonfiguration in Active Directory ist nicht einfach nur eine Einstellung, die von einem Benchmark abweicht. In der Praxis ist sie eine Kontrollschwäche, die Authentifizierung, Privilegien, Verzeichnisreplikation, Administration oder Richtliniensteuerung breiter lässt, als es für die Umgebung notwendig wäre.

Deshalb tauchen dieselben Problemfamilien immer wieder auf: zu viele privilegierte Konten, fehlende Trennung administrativer Pfade, zu breit vergebene Replikationsrechte, unsignierter Verzeichnisverkehr, wiederverwendbare lokale Admin-Secrets, Servicekonten mit statischen Kennwörtern, unsichere Delegationseinstellungen und zu permissive Group Policy-Kontrolle. Es sind Konfigurationsprobleme, aber sie werden zu Angriffspfad-Problemen, wenn sie in Produktion bleiben.

Welche Sicherheitsfehlkonfigurationen in Active Directory sind am haeufigsten?

ℹ️ Hinweis: Diese Liste ist kein neutraler Markt-Rang nach Statistik. Es ist eine praktische Top-10 der Fehlkonfigurationsfamilien, die in Microsoft- und ANSSI-Leitlinien und in AD-Reviews wiederholt relevant sind und in realen Umgebungen weiterhin zu materieller Exposition führen.

1. Zu viele privilegierte Konten und sensible Gruppenmitgliedschaften

Dies ist die grundlegendste AD-Fehlkonfigurationsfamilie: zu viele Benutzer, Servicekonten oder Break-Glass-Konten behalten eine dauerhafte Mitgliedschaft in hochsensiblen Gruppen oder äquivalenten delegierten Rechten. Microsoft und ANSSI verfolgen hier dasselbe Prinzip: stehenden privilegierten Zugriff minimieren und administrativen Umfang explizit halten.

Das Risiko ist direkt. Jedes zusätzliche privilegierte Konto erhöht Credential-Exposition, interaktive Anmeldefläche, Delegationsrisiko und den Wiederherstellungsumfang bei einer Kompromittierung. In der Praxis ist das Problem meist nicht ein einzelnes Domain-Admin-Konto. Es ist die langsame Ansammlung alter Admin-Benutzer, Support-Konten, dauerhaft gewordener Notfallkonten und Verschachtelungspfade, die niemand mehr bereinigt.

Vor der Änderung validieren: Inventar privilegierter Gruppen, verschachtelte Mitgliedschaften, delegierte Rechte auf Tier-0-Assets und reale administrative Anwendungsfälle. Rechte zu entziehen, ohne Ownership und operative Abhängigkeit zu prüfen, erzeugt Störungen.

Als Nachweis nach dem Rollout aufbewahren: exportiertes Inventar privilegierter Gruppen, Änderungsnachweise für entfernte Zugriffe und eine überprüfte Liste der Identitäten, die weiterhin stehende Privilegien benötigen.

2. Keine getrennten administrativen Pfade oder sicheren Admin-Hosts

Viele AD-Umgebungen erlauben es noch immer derselben Identität, Server zu verwalten, E-Mails zu lesen, Dokumente zu öffnen und sich an weniger vertrauenswürdigen Arbeitsstationen anzumelden. Microsofts Leitfaden zu secure administrative hosts existiert, weil privilegierter Zugriff nicht nur aus Gruppenmitgliedschaft besteht. Er hängt auch davon ab, wo administrative Credentials exponiert werden.

Wenn privilegierte Benutzer von General-Purpose-Endpunkten administrieren, werden Admin-Credentials und Tokens mit höherer Wahrscheinlichkeit erfasst, wiederverwendet oder in lateralen Bewegungen missbraucht. Deshalb bleiben dedizierte Admin-Workstations, getrennte Admin-Konten und ein sauberer administrativer Pfad wichtig, selbst wenn Gruppenmitgliedschaften bereits vernünftig aussehen.

Vor der Änderung validieren: welche Administratoren bereits getrennte Konten nutzen, welche Systeme für Administration verwendet werden und welche Workflows noch von gemischt genutzten Endpunkten abhängen. Viele Teams stellen fest, dass sie Trennung auf dem Papier haben, aber nicht im täglichen Betrieb.

Als Nachweis nach dem Rollout aufbewahren: Host-Inventar für sichere Admin-Workstations oder äquivalente privilegierte Endpunkte, Anmeldeeinschränkungen oder Admin-Host-Zuweisungen und Nachweis, dass sensible Administration nicht mehr von unverwalteten oder allgemein genutzten Geräten erfolgt.

3. Zu breit vergebene Replikationsrechte

DCSync ist nicht nur ein offensives Label. Operativ ist es ein Berechtigungsproblem: Identitäten, die keine Verzeichnisreplikationsrechte benötigen, besitzen sie trotzdem. Microsoft Defender for Identity macht dies über die Bewertung zu Nicht-Admin-Konten mit DCSync-Rechten sichtbar, weil die zugrunde liegende Auswirkung so gravierend ist.

Wenn Replicating Directory Changes, Replicating Directory Changes All oder verwandte Replikationsrechte zu breit vergeben sind, kann eine Identität hochsensible Verzeichnisdaten anfordern, die unter enger Kontrolle bleiben sollten. Die richtige Remediation-Haltung ist nicht DCSync blockieren, sondern replikationsfähige Principals auf das minimal vorgesehene Set reduzieren.

Vor der Änderung validieren: ACLs auf der Domänenwurzel und relevanten Verzeichnisobjekten prüfen, aktuelle Inhaber von Replikationsrechten identifizieren und bestätigen, ob jeder Inhaber wirklich für Backup, Sync oder Security-Tooling nötig ist.

Als Nachweis nach dem Rollout aufbewahren: ACL-Review-Snapshot, finale genehmigte Liste replikationsfähiger Identitäten und Nachweis, dass entfernte Principals diese Rechte nicht mehr besitzen.

4. LDAP Signing und Channel Binding nicht sauber erzwungen

Unsigniertes LDAP ist weiterhin eines der klarsten Beispiele für einen AD-Kontrollmechanismus, der alt wirkt, aber operativ relevant bleibt. Microsofts Leitfaden zu LDAP Signing für AD DS existiert, weil unsignierte SASL-Binds und Simple Binds die Integrität des Verzeichnisverkehrs schwächen können und Kompatibilitätsprobleme Umgebungen häufig in einer halben Einführung festhalten.

Die Fehlkonfiguration ist selten nur ein einzelner Registry-Wert. Häufiger ist es inkonsistente Durchsetzung über Domain Controller hinweg, Anwendungen, die noch auf schwächeres Bind-Verhalten angewiesen sind, oder unvollständige Validierung, ob Clients bei strengeren Anforderungen ausfallen.

Vor der Änderung validieren: LDAP-Clients inventarisieren, Nutzung unsignierter Binds identifizieren, prüfen, ob LDAPS, Signing oder Channel-Binding-bezogene Anforderungen Legacy-Anwendungen betreffen, und die Änderung gestuft vor dem Enforcement einführen.

Als Nachweis nach dem Rollout aufbewahren: Richtlinieneinstellungen der Domain Controller, Testergebnisse kritischer Anwendungen und Telemetrie, die zeigt, dass erwartete Clients konformes Bind-Verhalten verwenden.

Für den vollständigen Mechanismus und die Validierungs-Caveats siehe LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

5. SMB Signing dort nicht erforderlich, wo es weiterhin zählt

SMB Signing ist ein weiterer Kontrollmechanismus, den Teams kennen, aber wegen Performance-Annahmen, Kompatibilitätsängsten oder geerbten Baselines auf Clients und Servern aufschieben. Microsoft ist hier deutlicher geworden, weil unsigniertes SMB weiterhin Raum für Manipulation lässt und NTLM-Relay-Bedingungen in Umgebungen unterstützt, die geerbte Vertrauenspfade nicht ausreichend reduziert haben.

Die Fehlkonfiguration ist nicht SMB existiert. Sie besteht darin, dass Integrität dort nicht verlangt wird, wo sie verlangt werden sollte, insbesondere auf Systemen, die noch sensible Authentifizierungsflüsse akzeptieren oder auf administrativen Pfaden liegen.

Vor der Änderung validieren: Legacy-Geräte, Embedded-Systeme, ältere Server oder Applikationspfade identifizieren, die noch schwächeres SMB-Verhalten benötigen. Den tatsächlichen Signing-Status auf Client- und Serverseite prüfen, statt anzunehmen, dass eine Seite es überall erzwingt.

Als Nachweis nach dem Rollout aufbewahren: effektiver SMB-Signing-Status, Ausnahmeregister für noch nicht konforme Systeme und Validierungsergebnisse, die zeigen, dass sensible Systeme nun Signing verlangen.

Für die protokollspezifische Exposition siehe SMB-Signierung deaktiviert: warum sie weiterhin NTLM Relay ermöglicht.

6. Windows LAPS nicht bereitgestellt

Eine große Zahl von AD-Umgebungen schützt Domänen-Credentials besser als lokale Administrator-Passwörter. Dadurch bleibt eines der ältesten Windows-Expositionsmuster bestehen: statische oder wiederverwendete lokale Admin-Secrets auf Endpunkten und in manchen Umgebungen eine schwache Handhabung von DSRM-Passwörtern auf Domain Controllern.

Microsofts Windows-LAPS-Leitfaden ist hier wichtig, weil es nicht nur um Workstation-Hygiene geht. Wiederverwendbare lokale Admin-Passwörter unterstützen laterale Bewegung, erschweren Containment nach einer Passwort-Offenlegung und schwächen den Wert anderer Hardening-Maßnahmen.

Vor der Änderung validieren: welche Endpunkte bereits Windows LAPS nutzen, ob Legacy LAPS und Windows LAPS parallel laufen, wie Passwortabruf delegiert ist und ob DSRM-Management für Domain Controller im Scope liegt.

Als Nachweis nach dem Rollout aufbewahren: Policy-Deploymentsstatus, verwaltete Abdeckung, autorisierte Passwortleser und Stichproben, dass Passwörter rotieren und nur von genehmigten Rollen abgerufen werden können.

Die Deployment- und Validierungsdetails sind in Windows LAPS nicht bereitgestellt: Warum gemeinsam genutzte lokale Admin-Passwörter riskant bleiben beschrieben.

7. Schwache Passwortrichtlinien und Ausnahmen für privilegierte Konten

Schwache Passwortrichtlinien sind weiterhin häufig, aber das eigentliche operative Problem geht über eine einzige domänenweite Einstellung hinaus. Es umfasst oft zu schwache Mindestanforderungen, fehlende gezielte Fine-Grained Password Policies, sehr langlebige privilegierte Passwörter und Ausnahmen, die kritische Konten stillschweigend außerhalb der gewünschten Baseline halten.

Microsofts Leitfaden zu Fine-Grained Password Policies existiert, weil hochwertige Konten nicht immer in ein Ein-Policy-Modell passen. Gleichzeitig betont ANSSI, dass privilegierte Konten und administrative Nutzungen strenger behandelt werden müssen als allgemeine Benutzerkonten.

Vor der Änderung validieren: effektive Standard-Domänenpasswortrichtlinie, vorhandene Fine-Grained Password Policies, privilegierte Konten mit Ausnahmemarkierungen, Nutzung von Password never expires und Servicekonten, die weiterhin wie menschliche Benutzer behandelt werden.

Als Nachweis nach dem Rollout aufbewahren: Export der effektiven Richtlinien, Zuordnung der Benutzer oder Gruppen mit strengeren Regeln und dokumentierte Reviews für verbleibende Ausnahmen.

Für angrenzende Credential-Probleme siehe Active Directory Password Security: Misconfigurations That Matter.

8. Legacy-Servicekonten mit statischen Passwörtern statt gMSA, wo möglich

Servicekonten mit statischen Passwörtern bleiben verbreitet, weil sie Migrationen überleben, ältere Anwendungen unterstützen und selten durchgängig einen Owner haben. Microsoft empfiehlt gMSA, weil es den operativen Aufwand der Passwortverwaltung für unterstützte Workloads reduziert, aber viele Umgebungen halten weiterhin privilegierte oder SPN-tragende Servicekonten auf manuell verwalteten, sehr alten Passwörtern.

Das Risiko beschränkt sich nicht auf das Passwortalter. Solche Konten sind oft überprivilegiert, schwer zu inventarisieren, von normalen Lifecycle-Reviews ausgenommen und nur schwer sicher zu rotieren. Wo SPNs vorhanden sind, erhöhen langlebige Servicekonto-Credentials auch den Wert von Offline-Ticket-Cracking, weshalb dieses Thema mit Kerberoasting-Exposition überlappt.

Vor der Änderung validieren: Servicekonten, Ownership, SPN-Nutzung, Privilegienstufe, Passwortrotationsprozess und Anwendungskompatibilität mit gMSA inventarisieren. Nicht jeder Dienst kann sofort migriert werden, deshalb sollten die risikoreichsten Konten zuerst priorisiert werden.

Als Nachweis nach dem Rollout aufbewahren: Servicekonto-Inventar, dokumentierte Owner, Migrationsentscheidungen für gMSA-Kandidaten und Nachweise zur Rotation oder Umstellung für Konten, die statische Passwörter behalten.

9. Unsichere Kerberos-Delegation

Kerberos-Delegation wird zur Fehlkonfiguration, wenn sie breiter ist, als das Servicedesign tatsächlich erfordert. Microsoft Defender for Identity hebt unsichere Delegation hervor, weil zu offene Delegationseinstellungen Impersonation-Pfade erweitern und materiell verändern, wie weit sich ein Kompromittierungsfall ausbreiten kann.

Dies ist ein gutes Beispiel dafür, warum häufige Fehlkonfiguration nicht einfache Korrektur bedeutet. Delegation ist oft anwendungsgetrieben. Sie zu entfernen oder umzubauen, ohne das Serviceverhalten zu validieren, kann Produktionsauthentifizierung beschädigen.

Vor der Änderung validieren: unconstrained, constrained und gegebenenfalls resource-based Delegation inventarisieren, Applikations-Owner identifizieren und bestätigen, welche Systeme Delegation überhaupt noch benötigen.

Als Nachweis nach dem Rollout aufbewahren: überprüftes Delegationsinventar, entfernte oder umgestellte Delegationseinstellungen und Testnachweise, dass erforderliche Serviceflüsse nach dem Tightening weiter funktionieren.

Für den breiteren Ketteneffekt diesen Punkt mit AD-Angriffspfade: wie Fehlkonfigurationen sich zu Domain Admin verketten verknüpfen.

10. Gefährliche GPO-Berechtigungen und schwache Änderungssteuerung

Group Policy wird zur Sicherheitsfehlkonfiguration, wenn wenig vertrauenswürdige oder zu breit gefasste Identitäten hochwirksame GPOs ändern, gefährliche Einstellungen verlinken oder Policy-Pfade verändern können, die privilegierte Systeme betreffen. Microsoft und ANSSI behandeln GPO-Administration als Control-Plane-Thema, nicht nur als Desktop-Management.

Die Wirkung geht über einen falschen Policy-Wert hinaus. Gefährliche GPO-Berechtigungen können einem Angreifer oder überprivilegierten Operator ermöglichen, Codeausführung durchzusetzen, Host-Sicherheit zu schwächen, lokale Gruppenmitgliedschaften zu ändern oder die Haltung von Systemen auf administrativen Pfaden zu verändern.

Vor der Änderung validieren: prüfen, wer GPOs bearbeiten, verlinken oder erstellen darf, welche GPOs auf privilegierte Systeme wirken und ob das Change Control hochwirksame GPOs von Routine-Desktop-Änderungen trennt.

Als Nachweis nach dem Rollout aufbewahren: Ergebnisse der GPO-Berechtigungsreviews, eingeschränkte Editor-Listen, Genehmigungsnachweise für hochwirksame Policies und Monitoring-Abdeckung für GPO-Änderungsereignisse.

Für die direkte Analyse dieses Pfads siehe GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

⚠️ Wenn AD CS eingesetzt wird: Schwächen bei Templates, Enrollment und CA-Konfiguration gehören in denselben First-Tier-Review, auch wenn sie nicht Teil dieser Top 10 sind. Nutzen Sie ADCS-Zertifikatangriffe: ESC1 bis ESC8 als dedizierten Deep Dive.

Warum bestehen diese Fehlkonfigurationen weiter?

Diese Probleme bleiben bestehen, weil sie an der Schnittstelle von Kompatibilität, Ownership und angesammelten Ausnahmen liegen. LDAP- und SMB-Hardening kann alte Anwendungen betreffen. Servicekonten überleben oft die Teams, die sie angelegt haben. Delegationseinstellungen bleiben bestehen, weil niemand Authentifizierung brechen will. GPO-Berechtigungen driften, weil Policy-Administration über mehrere Teams verteilt ist. Privilegierte Konten bleiben bestehen, weil ihre Entfernung operative Nachweise erfordert, nicht nur eine Sicherheitsmeinung.

Deshalb reicht ein jährlicher Review nicht aus. Wenn diese Kontrollen nur einmal pro Jahr geprüft werden, können Privilegien-Drift, Servicekonto-Drift und Policy-Ausnahmen schneller zurückkehren, als der Review-Zyklus sie erkennt. Ein wiederkehrender Prozess zählt genauso wie die erste Bereinigung. Siehe Wiederkehrendes Active Directory Audit: warum jährliche Prüfungen driften.

Wie lassen sie sich ohne Raten validieren?

Eine gute Korrektur ist nicht nur eine geänderte Einstellung. Es ist eine geänderte Einstellung plus ein Nachweis, dass die Kontrolle nun wirklich erzwungen wird und dass notwendige Workflows weiter funktionieren.

Hier werden Logging und Change-Sichtbarkeit wichtig. Wenn zentrale AD-Sicherheitskontrollen geändert werden, muss auch klar sein, ob Audit Policy und Sammelmodell Gruppenänderungen, Verzeichnis-ACL-Änderungen, GPO-Änderungen und andere hochwertige Control-Plane-Ereignisse sichtbar machen. Nutzen Sie AD Sicherheitsüberwachung: Event IDs und SIEM, wenn Ihre Logging-Baseline noch schwach ist.

Wie EtcSec bei der Priorisierung von AD-Fehlkonfigurationen hilft

EtcSec ist hier am nützlichsten, wenn das Ziel nicht eine einmalige Checkliste ist, sondern eine wiederholbare Sicht darauf, welche AD-Fehlkonfigurationen weiterhin die bedeutendste Exposition erzeugen. Findings wie EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, PASSWORD_POLICY_WEAK, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION und GPO_DANGEROUS_PERMISSIONS helfen dabei, diese Liste in eine auditierbare Remediation-Queue zu überführen.

Der entscheidende Punkt ist Wiederholbarkeit. Nachdem ein Kontrollmechanismus gehärtet wurde, muss erneut gemessen werden, ob die Exposition wirklich verschwunden ist und ob Drift sie später nicht wieder eingeführt hat. Das ist der Unterschied zwischen einmaligem Lesen eines Hardening-Guides und dem tatsächlichen Erhalt einer AD-Sicherheitslage über die Zeit.

Primärquellen

• Best practices for securing Active Directory
• Implementing Secure Administrative Hosts
• Privileged access strategy
• Security assessment: Remove non-admin accounts with DCSync permissions
• LDAP signing for Active Directory Domain Services
• Control SMB signing behavior
• Windows LAPS overview
• Group Managed Service Accounts overview
• Configure fine-grained password policies for AD DS
• Protected Users security group
• Authentication Policies and Authentication Policy Silos
• Security assessment: Unsecure Kerberos delegation
• Group Policy overview
• Configure Windows Event Forwarding
• Active Directory Certificate Services overview
• ANSSI Active Directory guide