Guido Grillenmeier

Es war noch nie einfach, Ihr Active Directory (AD) richtig zu sichern. Das Gleiche gilt für die Erteilung von Rechten zur Änderung von Dingen im AD. Schließlich möchten Sie nicht, dass Ihre privilegiertesten Administratorkonten (z.B. Domänenadministratoren) alltägliche Verzeichnisoperationen durchführen, aber die Gewährung von zu vielen Privilegien gefährdet Ihre AD-Sicherheitslage. An dieser Stelle kommt die Delegation von Berechtigungen auf AD-Objekte ins Spiel.

Die Granularität der Berechtigungen in Active Directory ist leistungsstark, kann aber auch überwältigend sein. Im Laufe der Jahre hat Microsoft einige Optionen und Rechte hinzugefügt, die es Administratoren ermöglichen, Funktionen auf einer detaillierteren Ebene zu gewähren. Die Bemühungen um Abwärtskompatibilität mit bestehenden delegierten Berechtigungen haben jedoch auch die Sicherung Ihres AD noch schwieriger gemacht. Ich habe bereits früher über einige der möglichen Folgen für die AD-Sicherheit geschrieben. Leider bleiben diese Probleme auch in der neuesten Betriebssystemversion, Windows Server 2025, bestehen.

Hier erfahren Sie, wie Sie die Windows-Kennwortoptionen mit Delegationsverwaltung nutzen können, um Ihre Benutzerverwaltungsstruktur zu unterstützen, ohne die Sicherheit Ihres Active Directory zu opfern.

Delegation der Benutzerverwaltung und das Prinzip der geringsten Rechte (Least Privilege)

Beim Entwurf eines AD-Delegationsmodells müssen Administratoren sorgfältig unterscheiden, wer was in welchem Teil des Verzeichnisses sehen oder tun kann. Delegierten Administratoren sollten nur die geringsten Privilegien gewährt werden, die sie benötigen, um ihre notwendigen Verwaltungsaufgaben auszuführen - nicht mehr und nicht weniger.

Nehmen wir an, die Rolle eines Helpdesk-Operators besteht darin, die Passwörter der Benutzer zurückzusetzen. Die Operatoren benötigen keine volle Kontrolle über die Organisationseinheit (OU), die alle Benutzerkonten enthält. Andernfalls könnten die Helpdesk-Operatoren viele andere Änderungen an Benutzerkonten und anderen Objekten in dieser OU vornehmen. Selbst wenn Sie regionalen Operatoren die Berechtigung zur Verwaltung weiterer Benutzeraspekte erteilen möchten (bis hin zur vollen Kontrolle), sollten sie dennoch Ihre allgemeinen Sicherheitsregeln befolgen, insbesondere in Bezug auf verschiedene Kennwortoptionen für die von ihnen verwalteten Benutzer.

Verwaltung von Passwortoptionen vs. Passwortpolitik

Das ursprüngliche Berechtigungsmodell, das Microsoft mit Windows Server 2000 herausbrachte, war beeindruckend vollständig und ermöglichte es Administratoren, Fähigkeiten bis hinunter zu den Attributen eines Objekts (im Gegensatz zu dem Objekt selbst) zu gewähren. Die Einschränkungen bei der Festlegung bestimmter Kennwortoptionen konnten jedoch zu Konflikten mit den Kennwortrichtlinien des Unternehmens führen.

Das Problem mit der ursprünglichen AD-Version war, dass sie nicht zwischen den folgenden sicherheitsrelevanten Optionen für die Passwortverwaltung unterscheiden konnte(Abbildung 1):

  • Passwort mit umkehrbarer Verschlüsselung speichern
  • Passwort läuft nie ab
  • Passwort nicht erforderlich Bit
Abbildung 1: Kontooptionen für kritische Passwörter auf der Registerkarte Konto

Das Bit Kennwort nicht erforderlich ist in den nativen Windows-Benutzeroberflächen nicht verfügbar. Das Bit kann jedoch programmatisch gesetzt werden, zum Beispiel über die PowerShell:

Get-ADUser -Identity Bob | Set-ADUser -PasswordNotRequired $true

Diese Optionen können, wenn sie verwendet werden, leicht Ihre unternehmensweiten Passwortrichtlinien untergraben und Ihr Unternehmen gefährden. Die Optionen haben kein eigenes Attribut, in dem sie gespeichert werden, sondern sind Teil des userAccountControl-Attributs eines Benutzers im AD. Dieses Attribut ist eine Sammlung verschiedener Einstellungen, die viele Aspekte eines Benutzerkontos steuern, indem ein binärer Schalter in die richtige Position gebracht wird.

Leider erlaubt jede delegierte Berechtigung, die einem Operator die volle Kontrolle über Benutzer in einer OU gewährt - oder auch nur das Recht, AccountRestrictions auf diese Benutzerobjekte zu schreiben - dem Operator auch, diese sensiblen Kennwortoptionen für alle Konten unter seiner Kontrolle festzulegen.

Wenn Sie delegierten Administratoren erlauben, diese Kennwortoptionen für die von ihnen verwalteten Konten zu wählen, führt dies oft zu unangenehmen Ergebnissen. Delegierte Administratoren, die nicht auf Sicherheit bedacht sind, könnten beispielsweise einen hohen Prozentsatz ihrer Benutzer mit der Option Passwort läuft nie ab konfigurieren, nur um Probleme zu vermeiden, wenn Benutzer ihre Passwörter ändern. Natürlich untergräbt eine solche Praxis alle auf Domänenebene festgelegten Kennwortalterrichtlinien ... selbst die, die für Gruppen durch feinkörnige Kennwortrichtlinien festgelegt wurden.

Das Problem mit authentifizierten Benutzern

Microsoft hat nicht lange gebraucht, um dieses Problem zu bekämpfen. Mit der Veröffentlichung von Windows Server 2003 führte Microsoft drei neue Kontrollzugriffsrechte ein, auch bekannt als erweiterte Rechte:

  • Umkehrbar verschlüsseltes Passwort pro Benutzer aktivieren
  • Passwort ablaufen lassen (ermöglicht das Setzen des Kennzeichens Passwort läuft nie ab )
  • Update Passwort nicht erforderlich Bit

Im Gegensatz zu erweiterten Rechten wie Reset-Password, die direkt für Benutzerobjekte festgelegt werden müssen, wurden diese drei erweiterten Rechte so implementiert, dass sie auf Domänenebene gelten. Mit diesen Rechten konnten nur Operatoren, denen die volle Kontrolle oder Write AccountRestrictions für eine Gruppe von Benutzern (z.B. in einer OU) in Kombination mit einer dieser speziellen Kennwortberechtigungen auf Root der Domäne gewährt wurde, diese sensiblen Kennwortoptionen für die von ihnen kontrollierten Konten tatsächlich festlegen.

Aber da Microsoft nun einmal Microsoft ist, hatte die Notwendigkeit der Abwärtskompatibilität mit bestehenden delegierten Berechtigungen und die Notwendigkeit, dass "alles so funktioniert wie bisher", Vorrang vor der Ermutigung der Kunden, die AD-Sicherheit in ihren Delegationsmodellen zu verbessern.

Um dieses Dilemma zu lösen, hat sich Microsoft entschieden, der Gruppe Authentifizierte Benutzer diese Rechte beim Upgrade bestehender AD-Domänen und -Wälder auf Windows Server 2003 im Stamm der Domäne zu gewähren. Leider wurden diese Berechtigungen auch für jede neu eingerichtete AD-Domäne festgelegt.

Kommt Ihnen das bekannt vor? Ja, die authentifizierten Benutzer erscheinen überall ... und nicht immer zu Ihren Gunsten(Abbildung 2).

Abbildung 2: Standardberechtigungen für authentifizierte Benutzer im Stamm der AD-Domäne

Dies ist der Status Quo seit dem Update von Windows Server 2003 ... und es geschieht immer noch in neuen AD-Bereitstellungen, die auf Windows Server 2022 und sogar Windows Server 2025 basieren. Das bedeutet, dass diese Standardberechtigungen in Ihrer AD-Bereitstellung höchstwahrscheinlich immer noch aktiv sind und Sie wahrscheinlich daran hindern, die Kennwortsicherheit in Ihrem Active Directory zu erhöhen.

Wie Sie die Sicherheit von AD-Passwörtern verbessern können

Wie können Sie also die Sicherheit Ihrer AD-Passwörter verbessern? Zunächst müssen Sie die Standardberechtigung für Authentifizierte Benutzer für diese drei erweiterten Rechte aus dem Stammverzeichnis Ihrer Domänen entfernen. Dann müssen Sie einen geeigneten Ersatz wählen - falls Sie diese Berechtigungen überhaupt delegieren möchten. Denken Sie daran: Diese drei erweiterten Rechte müssen auf der Domänenebene festgelegt werden. Die Gewährung dieser Rechte auf OU-Ebene hat keine Auswirkungen.

Meine Empfehlung:

  1. Erstellen Sie für jedes dieser sensiblen erweiterten Rechte eine eigene Gruppe.
  2. Erteilen Sie jeder Gruppe die entsprechende Berechtigung im Stammverzeichnis der Domäne. Diese Gruppen gehören zu Ihrer Tier 0 OU, in der nur Domänenadmins Änderungen vornehmen können.
  3. In einem Wald mit mehreren Domänen erstellen Sie die Gruppen als universelle Gruppen in Ihrer Stammdomäne. Auf diese Weise können Sie ausgewählte Benutzer aus jeder Domäne zu den Gruppen hinzufügen, die dann in jeder Domäne die entsprechenden Berechtigungen erteilen können.

Sie könnten zum Beispiel die folgenden drei Gruppen erstellen:

  • SVC-ADconfig-PerUserReversiblyEncryptedPwd
  • SVC-ADconfig-UnexpirePassword
  • SVC-ADconfig-PwdNotRequiredBit

Ersetzen Sie als nächstes die erweiterten Rechte für Authentifizierte Benutzer durch die entsprechenden Gruppen(Abbildung 3).

Abbildung 3: Ersetzte Berechtigungen mit speziellen Gruppen pro Berechtigung im Stamm der AD-Domäne

Nehmen wir nun an, Sie möchten, dass ein Operator, Fred, die Berechtigung erhält, einen Benutzer zu verwalten. Sie können Fred immer noch die volle Kontrolle oder Write AccountRestrictions für alle Benutzer in der OU gewähren, für die er verantwortlich ist. Aber Fred kann keine der drei sensiblen Passwortoptionen für diese Benutzerkonten festlegen.

Wenn Sie nun Fred zur Gruppe SVC-ADconfig-UnexpirePassword hinzufügen , kann er die Option Passwort läuft nie ab für die von ihm verwalteten Benutzer festlegen. Es ist wahrscheinlich am besten, Fred diese Option nicht zu geben, aber Sie könnten es tun, wenn es einen triftigen Grund dafür gäbe.

Hoffentlich haben Sie bereits Testpläne und eine Liste von Personen, die für die Validierung der wichtigsten Anwendungen, Tools und Benutzer- und Client-Verwaltungsprozesse verantwortlich sind, sowie einen Prozess für das Einholen von Feedback nach der Durchführung dieser Berechtigungsänderungen. Und natürlich sollten Sie, bevor Sie solche Änderungen in Ihrer AD-Produktionsumgebung vornehmen, die aktuellen Berechtigungen aufzeichnen und Ihre neuen Einstellungen testen, bevor Sie die Änderungen einführen.

Im Idealfall haben Sie eine Lösung, die alle Änderungen in Ihrem Active Directory aufzeichnet, einschließlich des Attributs nTsecurityDescriptor, das im Wesentlichen die Berechtigung des jeweiligen Objekts speichert. Noch besser wäre eine Lösung, die solche Änderungen im AD auch wieder rückgängig machen kann.

Ja, um es ganz offen zu sagen: Semperis Directory Service Protector (DSP) kann beides tun. Es gibt auch öffentlich verfügbare Skripte, die Sie mit Ihren eigenen Screenshots verwenden können, um Ihre Arbeit zu dokumentieren.

Das Wichtigste zu den Optionen für sensible Kennwörter in Windows Server 2025 und früher

Active Directory steckt voller Sicherheitsüberraschungen. Um mögliche Sicherheitslücken in Ihrer Umgebung zu erkennen, laden Sie Purple Knightherunter, ein kostenloses AD-Sicherheitsbewertungstool, das mehr als 150 Indikatoren für Sicherheitslücken und Anzeichen für eine Gefährdung identifiziert und Anleitungen für deren Behebung bietet.

Seien Sie sich nur bewusst, dass die Übernahme von Windows Server 2025 nicht unbedingt bedeutet, dass Sie problematische alte Einstellungen zurücklassen. Ziehen Sie auf jeden Fall in Betracht, die Konfigurationseinstellungen für die Delegierung sensibler Kennwortoptionen zu ändern.

  1. Wenn Sie die Verwaltung von Benutzerobjekten an Nicht-Domänenadministratoren delegiert haben, legen Sie fest, ob diese Personen die Möglichkeit benötigen, für die von ihnen verwalteten Benutzerkonten sensible Optionen wie "Passwort läuft nie ab" festzulegen.
  2. Ersetzen Sie die Standardberechtigungen für Authentifizierte Benutzer im Domänenstamm für die drei in diesem Artikel besprochenen erweiterten Rechte durch Gruppen, die nur Domänenadministratoren verwalten können.
  3. Fügen Sie den neu erstellten Gruppen selektiv delegierte Administratoren hinzu - aber nur, wenn ein echter geschäftlicher Bedarf besteht, eine dieser sensiblen Kennwortoptionen zu verwalten.

Diese Änderungen bergen ein geringes Risiko und große Vorteile für die Sicherheit von Active Directory und eine effektive Delegationsverwaltung.

Benötigen Sie Hilfe bei der AD-Sicherheit?

Nutzen Sie das Fachwissen von Semperis. Fordern Sie eine Überprüfung der Sicherheitskonfiguration an und unser Team wird automatisierte Tools und manuelle Methoden einsetzen, um Fehlkonfigurationen und Angriffspfade zu finden, die ein Angreifer nutzen könnte, um Ihre Umgebung zu kompromittieren.

Weitere Lektüre