Was Active-Directory-Delegation wirklich bedeutet
Mit Active-Directory-Delegation erhält eine Person oder ein Team die Möglichkeit, bestimmte Verwaltungsaufgaben in AD auszuführen, ohne Mitglied der Domain Admins oder einer anderen privilegierten Gruppe zu sein. Wenn die Aufgabe eng begrenzt ist, sollten es auch die damit verbundenen Rechte sein. Dafür gibt es zwei Wege.
Berechtigungen delegieren bedeutet, auf einer Organisationseinheit (OU) einen Zugriffssteuerungseintrag (Access Control Entry, ACE) einzurichten. Dieser gewährt einer Sicherheitsgruppe bestimmte Rechte für bestimmte Objekttypen. Der Helpdesk arbeitet anschließend direkt in „Active Directory-Benutzer und -Computer“ oder mit PowerShell. AD prüft bei jeder Änderung die Zugriffskontrollliste (ACL). Genau solche Einträge erstellt der Assistent zum Zuweisen der Objektverwaltung von Microsoft.
Aufgaben delegieren bedeutet dagegen, dass der Helpdesk selbst überhaupt keine zusätzlichen AD-Rechte erhält. Stattdessen verwendet er ein Formular: Welcher Benutzer? Welche Gruppe? Bis wann? Ein Servicekonto mit den erforderlichen Berechtigungen führt die Änderung aus; die Anfrage wird einschließlich aller Parameter protokolliert. Das ist delegierte Administration ohne delegierte Benutzerrechte – und das Grundprinzip vieler Active-Directory-Automatisierungen.
Beide Ansätze sind sinnvoll. Problematisch wird es, wenn der erste für jede Aufgabe eingesetzt wird.
Der klassische Weg: der Assistent zum Zuweisen der Objektverwaltung
Klicke in „Active Directory-Benutzer und -Computer“ mit der rechten Maustaste auf eine OU, wähle „Objektverwaltung zuweisen“, anschließend eine Gruppe und eine Aufgabe. Der Assistent bietet typische Tätigkeiten des First-Level-Supports an:
- Benutzerkonten erstellen, löschen und verwalten
- Benutzerpasswörter zurücksetzen und Passwortänderung bei der nächsten Anmeldung erzwingen
- Alle Benutzerinformationen lesen
- Gruppenmitgliedschaften ändern
- Computer einer Domäne hinzufügen
- Gruppenrichtlinienverknüpfungen verwalten
Das Ergebnis sind ein oder mehrere ACEs auf der OU. Häufig unterschätzt wird ihre Reichweite: Jeder passende Eintrag in dieser OU und allen untergeordneten OUs erbt die Berechtigung – heute und ebenso bei Objekten, die erst künftig angelegt werden.
Der Assistent besitzt keine Rückgängig-Funktion. Er fügt Rechte hinzu, entfernt sie aber nicht. Um eine Delegation zurückzunehmen, musst du die ACL auf der Registerkarte „Sicherheit“ bearbeiten oder dsacls beziehungsweise Set-Acl verwenden – und den richtigen ACE identifizieren.
Geschützte Konten sind von deiner Delegation ausgenommen. Für Mitglieder der Domain Admins, Account Operators und anderer privilegierter Gruppen wird die ACL regelmäßig anhand des AdminSDHolder-Objekts wiederhergestellt. Der Helpdesk kann deshalb die Passwörter gewöhnlicher Benutzer in der OU zurücksetzen, nicht aber jene privilegierter Konten. Das ist beabsichtigt, wirkt in der Praxis aber oft wie ein Fehler.
Integrierte Gruppen sind zu weitreichend. Wenn du den Helpdesk zu den Account Operators hinzufügst, erhält er Rechte über einen Großteil der Benutzer und Gruppen der Domäne und kann sich lokal an Domänencontrollern anmelden.
Vier Schwachstellen der Berechtigungsdelegation
Für offene Verwaltungsaufgaben durch geschulte Personen ist die Berechtigungsdelegation geeignet. Bei häufigen, standardisierten Helpdesk-Tickets stößt sie jedoch aus vier Gründen an Grenzen.
Der Geltungsbereich folgt der OU-Struktur, nicht dem Unternehmen. „Passwörter für den Standort Wien zurücksetzen“ bedeutet technisch „Passwörter aller passenden Konten unter OU=Vienna zurücksetzen“. Dazu können auch Führungskräfte, dort abgelegte Servicekonten und später erstellte Unter-OUs gehören. Jede Ausnahme macht die nächste Prüfung komplizierter.
Ein Recht kennt keine Bedingungen. Ein ACE kann „Passwort zurücksetzen“ erlauben, aber nicht „erst nach Identitätsprüfung“, „nicht für Servicekonten“ oder „Vorgesetzten benachrichtigen“. Solche Regeln stehen dann in Dokumenten, die neue Mitarbeitende möglicherweise nicht gelesen haben.
Die Verwaltungskonsole bleibt die Oberfläche. Die berechtigte Person benötigt weiterhin ADUC oder das Active-Directory-PowerShell-Modul, RSAT und Kenntnisse der Objektstruktur. Das Risiko, das falsche Objekt zu bearbeiten, bleibt bestehen.
Die Berechtigung gilt dauerhaft. Der ACE ist auch sonntags um drei Uhr nachts aktiv – unabhängig davon, ob ein Ticket existiert. Im von Microsoft beschriebenen Tier-Modell für AD DS gehören Helpdesk-Konten zu Tier 2 und dürfen keine Rechte erhalten, die auf Tier 0 oder Tier 1 reichen. Wird ein Helpdesk-Konto mit geerbten ACEs kompromittiert, sind potenziell alle passenden Objekte der Unterstruktur betroffen.
Aufgaben statt Berechtigungen delegieren
Das zweite Modell fragt nicht „Welche Rechte braucht der Helpdesk?“, sondern „Welche Aufgabe soll er auslösen dürfen?“. Diese Aufgabe wird als Service bereitgestellt.
Ein Service besteht aus einem Skript oder Runbook mit Parametern: beispielsweise einem PowerShell-Skript für lokales AD, einem Azure-Automation-Runbook für Entra ID und Microsoft 365 oder einem System-Center-Orchestrator-Runbook. Ein Self-Service-Portal macht daraus ein geführtes Formular, steuert die Sichtbarkeit, ergänzt bei Bedarf eine Genehmigung und startet das Skript über ein geschütztes Servicekonto. Der Helpdesk-Benutzer benötigt keine AD-Rechte; das Servicekonto erhält nur die notwendigen.
| Berechtigung delegieren (ACE auf OU) | Aufgabe delegieren (Portal + Servicekonto) | |
|---|---|---|
| Wer besitzt das AD-Recht | Die Helpdesk-Gruppe | Ein Servicekonto je Aufgabe |
| Geltungsbereich | OU-Unterstruktur, vererbt | Im Skript festgelegt: Filter, Ausnahmen und Prüfungen |
| Oberfläche | ADUC, PowerShell, RSAT | Webformular mit validierten Feldern |
| Genehmigung | Nicht vorgesehen | Optional je Service durch Verantwortliche |
| Nachvollziehbarkeit | Sicherheitsprotokoll: wer, was, wann | Anfrageprotokoll: wer, was, Parameter, Genehmiger, Ergebnis |
| Widerruf | ACL manuell bearbeiten | Benutzerzugriff auf den Service entfernen |
| Geeignet für | Offene Tätigkeiten geschulter Mitarbeitender | Häufige, wiederholbare Aufgaben mit klaren Parametern |
Das verändert auch das Tier-Modell: Der Helpdesk bleibt mit einem normalen Konto in Tier 2. Nur das Servicekonto besitzt das erforderliche AD-Recht. Es meldet sich nicht interaktiv an, und seine Zugangsdaten sind in der Automatisierungsumgebung geschützt. Ein kompromittiertes First-Level-Konto hat damit keinen direkten Zugriff auf die AD-Objekte.
Genau für dieses Modell wurde das au2mator Self-Service Portal für Helpdesk-Teams entwickelt. Es verwendet vorhandene Automatisierungsplattformen wie PowerShell, Azure Automation und System Center Orchestrator.
In fünf Schritten zum AD-Delegationsmodell
Schritt 1: Erfasse Aufgaben statt Gruppen. Liste auf, welche AD-Arbeiten außerhalb des Adminteams erledigt werden: Passwort-Resets, Konten entsperren, Gruppenänderungen, Konten für externe Mitarbeitende und Domänenbeitritte. Oft zeigen bereits drei Monate Ticketdaten zehn bis fünfzehn Aufgabentypen, die einen Großteil des Volumens abdecken.
Schritt 2: Ordne jeder Aufgabe und Rolle ein Tier zu. Tätigkeiten an Tier-0-Objekten wie Domänencontrollern oder privilegierten Gruppen und deren Mitgliedern dürfen nicht an den Helpdesk delegiert werden. Für alle anderen Aufgaben werden die passende Sicherheitsstufe und ein Verantwortlicher festgelegt.
Schritt 3: Trenne die Aufgaben. Häufige, klar parametrisierte Tätigkeiten mit Prüf- oder Genehmigungsbedarf gehören ins Portal. Offene Konsolenarbeit durch geschulte Personen kann über eng begrenzte Berechtigungen erfolgen – etwa wenn ein Standortadministrator eine OU laufend verwaltet.
Schritt 4: Setze beide Modelle sauber um. Bei Berechtigungen verwendest du pro Delegation eine eigene Sicherheitsgruppe mit sprechendem Namen, zum Beispiel DLG-Vienna-PasswordReset, und weist Rechte nur auf der kleinsten geeigneten OU zu. Vermeide integrierte Gruppen. Bei Services nutzt du ein Servicekonto je Aufgabenfamilie mit eng begrenztem ACE, ein Skript mit Eingabevalidierung und Schutz für privilegierte Objekte sowie ein Formular, das nur erlaubte Parameter anbietet.
Schritt 5: Überprüfe das Modell vierteljährlich. Exportiere die ACLs der übergeordneten OUs und gleiche sie mit dem dokumentierten Modell ab. Prüfe außerdem, welche Portal-Services nicht mehr genutzt werden, und entferne diese. Ohne regelmäßige Kontrolle entsteht erneut unübersichtlicher Berechtigungswildwuchs.
Praxisbeispiel: Passwort zurücksetzen und Gruppenmitgliedschaften verwalten
Vorher: Die Helpdesk-Gruppe darf auf OU=Users Benutzerpasswörter zurücksetzen und Gruppenmitgliedschaften ändern. Ein gesperrter Benutzer ruft an. Der Mitarbeiter öffnet ADUC, findet zwei ähnlich benannte Konten und setzt erst das falsche, dann das richtige Passwort zurück. Später fügt er auf Zuruf jemanden zur Gruppe FIN-SAP-Prod hinzu – ohne Genehmigung. Das Sicherheitsprotokoll zeigt die Änderungen, aber weder Ticketnummern noch Identitätsprüfungen oder den zuständigen Gruppenverantwortlichen.
Nachher: Die Helpdesk-Gruppe hat keinen ACE mehr in AD. Im Portal stehen zwei Services bereit. „Passwort zurücksetzen“ fragt nach dem Benutzer aus einer Liste ohne Service- und Adminkonten, der Ticketnummer und einer Bestätigung der Identitätsprüfung. Ein Servicekonto mit dem entsprechenden Recht führt das Skript aus und sendet das temporäre Passwort an die hinterlegte Mobilnummer. „Zur Gruppe hinzufügen“ bietet nur freigegebene Gruppen an; sensible Gruppen erfordern die Genehmigung des Gruppenverantwortlichen. Jede Anfrage wird mit Antragsteller, Parametern, Genehmiger und Ergebnis protokolliert. Der Helpdesk arbeitet schneller, die Revision erhält nachvollziehbare Daten und das Helpdesk-Konto bietet Angreifern weniger Angriffsfläche.
Wenn dein Ticketsystem die führende Dokumentation für diese Anfragen ist, kann das Portal das Ticket mit dem Ergebnis aktualisieren. Wie beide Systeme zusammenspielen, erläutern wir im Artikel Service Desk Automation vs. ITSM-Ticketsysteme.
Delegierte Berechtigungen überprüfen
Unabhängig vom Modell solltest du zwei Fragen jederzeit beantworten können: Wer darf aktuell was in AD tun? Und wer hat im vergangenen Monat welche Änderungen vorgenommen?
Für die erste Frage exportierst du die ACLs. Der Befehl Get-Acl "AD:\OU=Users,DC=corp,DC=local" | Select-Object -ExpandProperty Access listet alle ACEs einer OU auf, einschließlich geerbter Einträge und Angaben zu Identität, Recht, Objekttyp und Vererbung. Filtere die Standardeinträge heraus, um die tatsächlichen Delegationen zu sehen. Jeder ACE, der keiner dokumentierten DLG-Gruppe zugeordnet ist, sollte überprüft werden.
Für die zweite Frage liefert das Sicherheitsprotokoll der Domänencontroller die Ereignisse einer Berechtigungsdelegation: 4724 für Passwort-Resets, 4740 für Kontosperrungen, 4728 und 4729 für Änderungen an Sicherheitsgruppen sowie 4720 und 4726 für das Erstellen und Löschen von Benutzern. Bei der Aufgabendelegation ergänzt das Anfrageprotokoll des Portals Informationen, die das Sicherheitsprotokoll nicht enthält: Antragsteller, Parameter, Genehmiger und Skriptausgabe.
Ermittle schließlich, wie viele Helpdesk-Konten direkte AD-Rechte besitzen. Diese Zahl sollte im Laufe der Zeit sinken.
FAQ: Active-Directory-Delegation
Active-Directory-Delegation bedeutet, Personen oder Teams bestimmte administrative Aufgaben zu ermöglichen – etwa das Zurücksetzen von Passwörtern oder die Verwaltung von Gruppenmitgliedschaften innerhalb einer OU –, ohne sie zu Domain Admins zu machen. Das funktioniert über einen ACE auf einer OU oder durch einen Portal-Service, der die Änderung mit einem Servicekonto ausführt.
Klicke in „Active Directory-Benutzer und -Computer“ mit der rechten Maustaste auf die OU, wähle „Objektverwaltung zuweisen“, anschließend die Sicherheitsgruppe und eine Aufgabe wie „Benutzerkennwörter zurücksetzen“. Der Assistent erstellt die passenden ACEs auf der OU, die von untergeordneten Objekten geerbt werden.
Diese Konten sind Mitglied geschützter Gruppen wie Domain Admins oder Account Operators. Der AdminSDHolder-Mechanismus überschreibt ihre ACL regelmäßig. Deshalb gelten die auf der OU delegierten Rechte nicht für diese Konten. Das ist beabsichtigt.
Der Assistent entfernt keine Berechtigungen. Lösche den betreffenden ACE auf der Registerkarte „Sicherheit“ der OU oder nutze dsacls beziehungsweise Set-Acl. Bei der Aufgabendelegation entfernst du die Freigabe des Portal-Services für den Benutzer; die technische Berechtigung verbleibt beim Servicekonto.
Nein. Account Operators dürfen einen Großteil der Benutzer- und Gruppenkonten in der Domäne verwalten und sich lokal an Domänencontrollern anmelden. Eng begrenzte OU-Rechte oder ein Service über ein Servicekonto erfüllen die Anforderungen des Helpdesks mit deutlich geringerem Risiko.
Ja. Helpdesk-Mitarbeitende starten einen vordefinierten Service im Self-Service-Portal. Ein geschütztes Servicekonto mit minimalen Berechtigungen führt die Änderung aus, optional nach Freigabe. Die Anfrage einschließlich ihrer Parameter wird protokolliert. Das persönliche Helpdesk-Konto erhält keine AD-Rechte.
Exportiere die ACLs der übergeordneten OUs mit Get-Acl oder dsacls, filtere Standardeinträge heraus und gleiche die übrigen Berechtigungen mit den dokumentierten Delegationsgruppen ab. Für ausgeführte Aktionen sammelst du die Sicherheitsereignisse 4724, 4740, 4728 und 4729 der Domänencontroller sowie die Anfragenprotokolle des Portals.
Fazit: Aufgaben delegieren, Berechtigungen schützen
Active-Directory-Delegation ist mehr als ein Assistent. Entscheidend ist, wo Berechtigungen liegen. Für offene Aufgaben geschulter Mitarbeitender eignet sich ein eng begrenzter ACE auf einer klar strukturierten OU. Häufige, standardisierte und ticketgesteuerte Tätigkeiten werden dagegen als Service bereitgestellt: Formular für den Helpdesk, Servicekonto für die Ausführung und Protokoll für die Revision. So können mehr Anfragen beim ersten Kontakt erledigt werden, das Tier-Modell bleibt erhalten und Berechtigungsprüfungen werden einfacher.
Wenn du deine Helpdesk-Aufgaben gemeinsam durchgehen und entscheiden möchtest, welches Delegationsmodell jeweils passt, buche ein 30-minütiges Gespräch mit Michael Seidl, Microsoft MVP und Gründer von au2mator. Bring am besten die Ticketkategorien des letzten Quartals mit.
