goSecurity BLOG

In der Welt der Windows-basierten Netzwerke ist Delegierung häufig ein unverzichtbares Werkzeug: Sie ermöglicht es Diensten, im Namen eines Benutzers auf andere Systeme zuzugreifen. Ein grundlegendes Prinzip für Single Sign-On, Webanwendungen und verteilte Dienste. Doch was funktional notwendig ist, kann schnell zum Sicherheitsrisiko werden.

Vor allem in Active Directory-Umgebungen stellt sich die Frage:

• Wie viel Vertrauen darf ein Dienst haben?

• Und vor allem: Wer kontrolliert dieses Vertrauen?

Active Directory bietet dafür verschiedene Delegierungsmechanismen, die sich stark in ihrer Sicherheitsarchitektur unterscheiden:

• Unconstrained Delegation: technisch bequem, aber gefährlich

• Constrained Delegation: sicherer durch Einschränkung auf bestimmte Dienste

• Resource-Based Constrained Delegation (RBCD): modern, flexibel und Cloud-tauglich

In diesem Blog analysieren wir die drei Modelle aus der Sicherheitsperspektive. Wie funktionieren sie? Wo liegen ihre Schwachstellen? Und welche Best Practices helfen, Delegierung sicher zu betreiben?

Was ist Delegierung in Active Directory?

Delegierung in Active Directory beschreibt die Fähigkeit eines Dienstes, im Namen eines Benutzers auf andere Netzwerkressourcen zuzugreifen. Dieses Prinzip ist in vielen IT-Szenarien unverzichtbar, etwa wenn ein Benutzer sich an einer Webanwendung anmeldet, und diese Anwendung anschliessend auf einen SQL-Server oder einen File-Server zugreifen muss. Der Zugriff soll dabei nicht im Namen des Dienstes, sondern im Kontext des angemeldeten Benutzers erfolgen, damit Berechtigungen, Zugriffsprotokolle und Sicherheitsrichtlinien korrekt greifen.

Technisch basiert dieser Vorgang auf dem Kerberos-Authentifizierungsprotokoll, das in Windows-Netzwerken standardmässig zur Authentifizierung verwendet wird. Kerberos arbeitet mit sogenannten Tickets, die die Identität eines Benutzers belegen. Wenn ein Benutzer sich anmeldet, erhält er zunächst ein sogenanntes Ticket Granting Ticket (TGT). Mit diesem TGT kann er weitere Service-Tickets anfordern, um auf verschiedene Dienste zuzugreifen.

Genau hier setzt die Delegierung an:

Ein Dienst, etwa ein Web-Server, empfängt die Anfrage eines Benutzers und benötigt nun ein Service-Ticket, um beispielsweise eine Datei im Namen dieses Benutzers von einem File-Server abzurufen. Damit das funktioniert, muss der Dienst berechtigt sein, im Namen des Benutzers zu agieren. Und genau diese Berechtigung wird durch Delegierung in AD geregelt.

Ohne Delegierung wäre ein sogenanntes Multi-Hop-Szenario (z. B. Browser → Webserver → Fileserver) nicht möglich, ohne dass der Benutzer seine Zugangsdaten mehrfach eingeben müsste. Mit Delegierung kann der Dienst die Identität des Benutzers mitführen. Single Sign-On (SSO) ist das Ergebnis.

Doch so praktisch Delegierung ist, so kritisch ist sie auch aus Sicht der IT-Sicherheit:

Ein falsch konfigurierter Dienst, dem zu viele Rechte eingeräumt wurden, kann im schlimmsten Fall Identitäten missbrauchen, um auf sensible Ressourcen zuzugreifen. Deshalb ist es wichtig, genau zu verstehen, wie Delegierung funktioniert, welche Modelle es gibt und welche Risiken sie mit sich bringen.

Unconstrained Delegation

Die uneingeschränkte Delegierung (“Unconstrained Delegation”) ist ein Mechanismus innerhalb von Active Directory, der es einem Dienst erlaubt, im Namen eines Benutzers auf beliebige andere Dienste im Netzwerk zuzugreifen. Dieses Modell wurde mit früheren Windows-Versionen eingeführt, als Sicherheitsbedenken im Hinblick auf Identitätsweitergabe noch eine untergeordnete Rolle spielten. Sobald ein Benutzer sich an einem Dienst anmeldet, der für uneingeschränkte Delegierung konfiguriert ist, speichert das System dessen Kerberos-Ticket (TGT), sodass der Dienst dieses Ticket verwenden kann, um beliebige andere Netzwerkdienste im Namen des Benutzers zu kontaktieren.

Obwohl diese Art der Delegierung einfach zu implementieren ist, bringt sie erhebliche Sicherheitsrisiken mit sich: Ein kompromittierter Server mit uneingeschränkter Delegierung kann verwendet werden, um Benutzeridentitäten zu übernehmen und sich Zugriff auf sensible Ressourcen zu verschaffen. Aus diesem Grund gilt die uneingeschränkte Delegierung heute als veraltet und unsicher, und Microsoft empfiehlt stattdessen die Verwendung von sichereren Alternativen wie der eingeschränkten oder ressourcenbasierten Delegierung.

Beispiel-Einsatz: Intranet-Webanwendung mit Backend-Datenbank

Szenario

Ein Unternehmen betreibt eine interne Webanwendung auf einem Server WEB-SRV, die auf eine SQL-Datenbank (SQL-SRV) zugreift. Die Anwendung muss im Namen des angemeldeten Benutzers auf die Datenbank zugreifen (z. B. für Berechtigungsprüfung oder personalisierte Abfragen).

Konfiguration

Der Webserver WEB-SRV ist in Active Directory für uneingeschränkte Delegierung konfiguriert.

Ablauf bei Zugriff durch Benutzer

1. Ein Benutzer Brian meldet sich über einen Browser an der Webanwendung auf WEB-SRV an.

2. Beim Authentifizierungsvorgang über Kerberos wird das Ticket Granting Ticket (TGT) von Brian an WEB-SRV weitergegeben.

3. Da WEB-SRV für Unconstrained Delegation konfiguriert ist, speichert es dieses TGT.

4. WEB-SRV verwendet das TGT von Brian, um im Namen von Brian ein Service-Ticket für SQL-SRV anzufordern.

5. WEB-SRV verbindet sich nun mit SQL-SRV und führt Datenbankabfragen im Namen von Brian aus.

Sicherheitsrisiko

Wenn ein Angreifer Zugriff auf WEB-SRV erhält (z. B. durch Ausnutzen einer Schwachstelle), kann er auf die TGTs aller Benutzer zugreifen, die sich jemals an der Webanwendung angemeldet haben. Damit könnte er sich im Namen dieser Benutzer gegenüber beliebigen Diensten im Netzwerk ausgeben, einschliesslich Domain Controllern.

Missbrauch von Unconstrained Delegation

Szenario

Ein Angreifer hat lokalen Administratorzugriff auf einen Host, der für uneingeschränkte Kerberos-Delegierung konfiguriert ist.

Ziele im Active Directory finden

Mit PowerView lassen sich Systeme, die für uneingeschränkte Delegierung konfiguriert sind, einfach identifizieren:

Alle Computerkonten mit dem Eintrag TRUSTED_FOR_DELEGATION in “UserAccountControl (UAC)” können angegriffen werden. Domänencontroller haben diesen Wert standardmässig, weil sie per Voreinstellung für uneingeschränkte Delegierung konfiguriert sind. Einen Domänencontroller erkennt man am UAC-Wert SERVER_TRUST_ACCOUNT. Das ist anders als bei normalen Computern. Für Angreifer besonders interessant sind jedoch nicht die Domänencontroller selbst, sondern andere Systeme in der Domäne, wie klassische Server oder Workstations, die ebenfalls den Wert TRUSTED_FOR_DELEGATION aufweisen. Ein Beispiel hierfür ist ein System wie SQL01. Es ist ein Nicht-DC mit Delegierungsrechten. Das macht es zu einem attraktiven Ziel für eine Eskalation von Berechtigungen.

Hier ist ein Beispiel, wie es im Active Directory aussieht:

Ausnutzen mit der Berechtigung eines Benutzeraccounts

Der Angreifer möchte auf die Netzwerkfreigabe \\dc01\shares\Marketing zugreifen. Aktuell hat dieser auf die aktuelle Freigabe keinen Zugriff.

Gelingt es einem Angreifer, diesen Webserver zu übernehmen, kann der Angreifer in regelmässigen Abständen beispielsweise mit Rubeus die gespeicherten Tickets im Arbeitsspeicher abrufen. Greift der Benutzer jetzt auf die Webanwendung zu, wird sein Kerberos Ticket auf dem Server gespeichert.

Um auf die gewünschte Freigabe zuzugreifen, kann der Angreifer das Kerberos-Ticket des Benutzers einfach in den Arbeitsspeicher importieren.

Und anschliessend auf die Freigabe zugreifen.

Ausnutzen mit dem Printer Bug

Wie oben bereits beschrieben nutzen wir Rubeus, um die gespeicherten Tickets im Arbeitsspeicher abzurufen.

Um einen Computer dazu zu bringen, sich am Server SQL01 zu authentifizieren, verwenden wir das Tool SpoolSample.exe, das sich eine bekannte Schwachstelle im Druckerdienst zunutze macht, den sogenannten Printer Bug.

Ist der Server verwundbar, versucht dieser sich am Server SQL01 zu authentifizieren und wir können das Kerberos-Ticket abrufen.

Um das Ticket in den Arbeitsspeicher zu laden, verwenden wir wieder Rubeus.

Nun haben wir das Kerberos-Ticket vom Domänencontroller im Speicher und können, beispielsweise mit mimikatz, den NTLM-Hash des Domänenadministrators auslesen.

Mit dem NTLM-Hash des Domänen Administrators können wir beispielsweise einen Pass-the-hash-Angriff ausführen oder ein Kerberos-Ticket erstellen. In unserem Fall beantragen wir ein Kerberos-Ticket.

Mit diesem können wir uns anschliessend mit dem Domänencontroller verbinden.

Fazit

Unconstrained Delegation bietet Komfort, ist aber hochriskant, da kompromittierte Server zum Einstiegspunkt für laterale Bewegungen und Privilege Escalation im Netzwerk werden können. Moderne Systeme sollten lieber auf Constrained oder Resource-Based Constrained Delegation (RBCD) umstellen.

Constrained Delegation

Die eingeschränkte Delegierung (“Constrained Delegation”) ist ein Sicherheitsmechanismus in Active Directory-Umgebungen, der erstmals mit Windows Server 2003 eingeführt wurde. Sie dient dazu, den Vertrauensbereich von Diensten zu kontrollieren, die im Auftrag eines Benutzers auf Ressourcen zugreifen. Im Gegensatz zur uneingeschränkten Delegierung (“Unconstrained Delegation”), bei der ein Dienst nahezu uneingeschränkt Benutzeridentitäten übernehmen kann, ermöglicht die eingeschränkte Delegierung eine gezielte und sichere Kontrolle darüber, welche Dienste im Namen eines Benutzers angesprochen werden dürfen. Administratoren können damit präzise definieren, welchen Ziel-Diensten ein Server vertrauen darf, wodurch potenzielle Angriffsflächen erheblich reduziert und Sicherheitsrichtlinien besser durchgesetzt werden können. Dieses Konzept ist besonders wichtig in Szenarien, in denen Anwendungen mit unterschiedlichen Sicherheitsanforderungen und Zugriffsebenen innerhalb einer Active Directory-Infrastruktur betrieben werden.

Beispiel-Einsatz: Webanwendung mit Zugriff auf eine Dateifreigabe

Szenario

Ein Unternehmen betreibt eine interne Webanwendung auf dem Server WEB-SRV, mit der Benutzer Dokumente anzeigen oder bearbeiten können, die auf einem File-Server FILE-SRV gespeichert sind. Die Webanwendung soll im Namen des angemeldeten Benutzers auf die Dateifreigabe zugreifen (damit z. B. Dateiberechtigungen korrekt greifen).

Konfiguration

WEB-SRV ist nicht für Unconstrained Delegation, sondern für Constrained Delegation konfiguriert.

In Active Directory wird WEB-SRV so eingestellt, dass es nur für den Dienst CIFS auf FILE-SRV delegieren darf.

Ablauf

1. Benutzerin Sophie meldet sich per Kerberos-Authentifizierung an der Webanwendung auf WEB-SRV an.

2. WEB-SRV erhält ein Service-Ticket im Namen von Sophie.

3. WEB-SRV verwendet dieses Ticket, um beim Domänencontroller ein weiteres Service-Ticket für den Dienst cifs/FILE-SRV im Namen von Sophie zu bekommen.

4. WEB-SRV verbindet sich mit FILE-SRV über SMB und greift auf Dateien zu, so als wäre es Sophie.

5. Die Freigabeberechtigungen auf FILE-SRV greifen, als würde Sophie selbst auf die Dateien zugreifen.

Missbrauch von Constrained Delegation

Szenario

Ein Angreifer hat lokalen Administratorzugriff auf einen Host, der für eingeschränkte Kerberos-Delegierung konfiguriert ist.

Ziele im Active Directory finden

Wird ein Computer- oder Benutzerkonto, das für eingeschränkte Delegierung konfiguriert ist (d. h. das Attribut UserAccountControl trägt den Wert TRUSTED_TO_AUTH_FOR_DELEGATION), kompromittiert, sollte anschliessend die Eigenschaft msDS-AllowedToDelegateTo überprüft werden. Dieses Attribut gibt an, zu welchen Diensten oder unter welchen Namen das Konto berechtigt ist, andere Benutzer innerhalb der Domäne zu imitieren.

PowerView zeigt, dass das Computerkonto DMZ01$ im UAC-Attribut den Wert TRUSTED_TO_AUTH_FOR_DELEGATION hat. Das bedeutet, dass dieses Konto nur eingeschränkt delegiert werden kann und der Protokollübergang aktiviert ist. Anfragen im Namen anderer Benutzer dürfen nur an www/WS01 weitergeleitet werden.

Hier ist ein Beispiel, wie es im Active Directory aussieht:

Ausnutzen der Berechtigung, um auf das Dateisystem zuzugreifen

Wurde der Server DMZ01 kompromittiert, lässt sich mit mimikatz der NTLM-Hash des Computerkontos extrahieren. Dieser Hash kann anschliessend verwendet werden, um ein Ticket im Namen des Servers zu beantragen.

Mit dem NTLM-Hash lässt sich nun ein Ticket für den cifs-Dienst im Namen des Administrators anfordern, wobei das kompromittierte Konto DMZ01 als Delegierungskonto auftritt.

Mit dem Ticket können wir nun auf den cifs-Dienst des Servers zugreifen und das Dateisystem erkunden.

Ausnutzen der Berechtigung, um mit WinRM auf das System zuzugreifen

Es ist aber auch möglich, einen anderen alternativen Dienst auszuwählen. Wenn wir uns beispielsweise mit WinRM verbinden möchten, können wir /altservice:HTTP auswählen. Dabei wird ein Service Ticket für den HTTP-Dienst beantragt.

Mit dem neuem Ticket können wir uns mit dem Server WS01 mit WinRM verbinden.

Fazit

Constrained Delegation ist eine gute Mischung aus Funktionalität und Sicherheit. Sie ermöglicht es, Benutzeridentitäten gezielt an bestimmte Dienste weiterzugeben, ohne dass ein Server umfassende Rechte zur Identitätsübernahme erhält. Im Vergleich zur unsicheren Unconstrained Delegation, bei der sich ein kompromittierter Host im Netzwerk ausgeben kann, bietet Constrained Delegation mehr Sicherheit und bessere Kontrollmöglichkeiten für Administratoren.

Resource-Based Constrained Delegation (RBCD)

Die ressourcenbasierte eingeschränkte Delegierung (“Resource-Based Constrained Delegation”, kurz RBCD) ist eine Weiterentwicklung des klassischen Konzepts der eingeschränkten Delegierung in Active Directory-Umgebungen. Eingeführt mit Windows Server 2012, verschiebt RBCD die Kontrolle über die Delegierung vom Quell- auf das Zielobjekt. Das heisst: Nicht mehr der Dienst, der im Auftrag eines Benutzers handelt, bestimmt, zu welchen Diensten er sich delegieren darf, sondern der Ziel-Dienst entscheidet, wem er diese Berechtigung einräumt.

Dieser umgekehrte Ansatz bietet mehr Flexibilität und Sicherheit, besonders in modernen Szenarien mit Group Managed Service Accounts (gMSAs), Cloud-Hybrid-Umgebungen oder dynamischen Infrastrukturen. RBCD nutzt dafür den Sicherheitsprinzipal des aufrufenden Dienstes und prüft, ob dieser im Attribut msDS-AllowedToActOnBehalfOfOtherIdentity des Zielobjekts hinterlegt ist. Dadurch wird ein feinjustierter Zugriff möglich, ohne dass weitreichende Vertrauensstellungen eingerichtet werden müssen.

RBCD ist ein wichtiger Baustein für den sicheren Betrieb von Kerberos-basierten Authentifizierungsprozessen, sollte jedoch mit Bedacht konfiguriert werden. Falsch gesetzt kann es ein Einfallstor für Angriffe wie Privilegieneskalationen darstellen.

Beispiel-Einsatz: Interne Webanwendung in klassischer On-Premises-Infrastruktur

Szenario

Ein Unternehmen betreibt eine reine On-Premises Active Directory-Umgebung. Auf einem internen Server (WEB-APP01) läuft eine Webanwendung, die es Mitarbeitenden ermöglicht, auf persönliche Dateien zuzugreifen, die zentral auf einem File-Server (FILE-SRV01) gespeichert sind. Die Webanwendung muss im Namen der jeweils angemeldeten Benutzerin oder des Benutzers auf die Dateiablage zugreifen, um Home-Verzeichnisse anzuzeigen oder Dokumente zu bearbeiten. Da WEB-APP01 eventuell in Zukunft durch weitere Instanzen ersetzt wird oder neu bereitgestellt werden könnte, ist es nicht sinnvoll, auf jedem Quellserver fix die erlaubten Ziel-Dienste für klassische Constrained Delegation zu konfigurieren. Stattdessen wird Resource-Based Constrained Delegation (RBCD) verwendet.

Konfiguration

• Identität des aufrufenden Dienstes:
  Die Webanwendung läuft unter einem Group Managed Service Account (gMSA), z. B. gmsa-webapp$.

• Zielobjektsteuerung:
  Auf dem Zielserver FILE-SRV01 wird das AD-Attribut msDS-AllowedToActOnBehalfOfOtherIdentity so gesetzt, dass gmsa-webapp$ autorisiert ist, im Namen von Benutzerinnen und Benutzern zu handeln. Damit sagt FILE-SRV01 explizit, dass er Anfragen von gmsa-webapp$ akzeptiert. Im Gegensatz zum klassischen Modell, bei dem der Webdienst festlegt, wohin er delegieren darf.

Ablauf

1. Benutzerin Mia meldet sich über Kerberos an der Webanwendung auf WEB-APP01 an.

2. Die Webanwendung, betrieben unter gmsa-webapp$, möchte im Namen von Mia auf die Freigabe \\FILE-SRV01\home\Mia zugreifen.

3. gmsa-webapp$ fordert beim Domänencontroller ein Service-Ticket für cifs/FILE-SRV01 im Namen von Mia an.

4. Da FILE-SRV01 im Attribut msDS-AllowedToActOnBehalfOfOtherIdentity den Account gmsa-webapp$ erlaubt hat, wird das Ticket ausgestellt.

5. WEB-APP01 verbindet sich mit der vollständigen Benutzeridentität von Mia mit FILE-SRV01.

Sicherheitsrisiko

Wenn ein Angreifer Zugriff auf einen Dienstaccount erhält, der in einem msDS-AllowedToActOnBehalfOfOtherIdentity-Attribut hinterlegt ist, kann er Tickets im Namen beliebiger Benutzer anfordern. Daher sollte dieses Attribut streng kontrolliert und regelmässig überprüft werden.

Missbrauch von Resource-Based Constrained Delegation (RBCD)

Szenario

Ein Angreifer hat lokalen Administratorzugriff auf einen Windows-Host in der Domäne erlangt. Dieses System ist nicht irgendein Server, dieser ist so konfiguriert, dass es Resource-Based Constrained Delegation (RBCD) auf den Domänencontroller ausüben darf. Das heisst: Der Angreifer sitzt auf einem System, das offiziell berechtigt ist, Kerberos-Tickets im Namen beliebiger Benutzer zu erstellen und an den Domänencontroller weiterzugeben.

Ziele im Active Directory finden

Der Angreifer möchte auf die Netzwerkfreigabe \\dc01\c$ zugreifen. Aktuell hat dieser auf die aktuelle Freigabe keinen Zugriff.

Bevor ein Angreifer RBCD wirklich ausnutzen kann, muss er herausfinden, wo es überhaupt aktiv ist. Das Attribut, das bei RBCD entscheidend ist, heisst msDS-AllowedToActOnBehalfOfOtherIdentity. Es wird auf dem Zielobjekt, beispielsweise einem Server oder dem Domänencontroller selbst, gesetzt und legt fest, welche anderen Computerkonten im Namen eines Benutzers auf diesen Dienst zugreifen dürfen.

Mit einem einfachen PowerShell-Befehl lässt sich genau das ermitteln. Dieser Befehl durchsucht das Active Directory gezielt nach allen Objekten, bei denen das Attribut gesetzt ist. Auf dem ersten Blick ist der Inhalt jedoch nicht wirklich leserlich.

Mit einem erweiterten Skript kann die obige Ausgabe in eine leserliche Ausgabe umgewandelt werden.

Anschliessend extrahiert er den NTLM-Hash des eigenen Computerkontos. Da er lokale Administratorrechte besitzt, kann er mit Tools wie mimikatz problemlos auf diesen Hash zugreifen.

Der Hash dient als Grundlage, um über das Tool Rubeus ein Kerberos-Ticket zu erzeugen, das vorgibt, im Namen eines beliebigen Benutzers zu handeln, beispielsweise als Domänenadministrator.

Mit dem erzeugten Ticket kann der Angreifer dann auf Ressourcen des Domänencontrollers zugreifen, als wäre er tatsächlich Administrator. Das reicht von der Änderung von Gruppenmitgliedschaften über das Zurücksetzen von Passwörtern bis hin zum Bereitstellen persistenter Zugriffsmöglichkeiten.

Fazit

RBCD ist ein essenzielles Werkzeug für moderne, flexible und sichere Delegationsszenarien in Active Directory, speziell dort, wo klassische Delegation zu starr oder administrativ zu aufwendig ist.

Schutz vor Risiken durch Delegierung in Active Directory

Delegierungsmechanismen wie Unconstrained Delegation und Constrained Delegation sind in Active Directory-Umgebungen notwendig, um bestimmte Authentifizierungs- und Weitergabeprozesse zu ermöglichen. Gleichzeitig stellen sie jedoch ein erhebliches Sicherheitsrisiko dar, insbesondere dann, wenn Systeme kompromittiert oder falsch konfiguriert sind. Während Unconstrained Delegation einem Dienst praktisch uneingeschränkte Rechte zur Identitätsweitergabe einräumt, erlaubt Constrained Delegation eine gezieltere Kontrolle, bleibt jedoch ebenfalls anfällig, wenn die Vertrauensbeziehungen zu weit gefasst oder unsicher umgesetzt werden.

Um sich wirksam gegen diese Gefahren zu schützen, sollten Organisationen auf einen mehrschichtigen Sicherheitsansatz setzen. Unconstrained Delegation sollte vollständig vermieden werden, und wo Delegierung technisch notwendig ist, sollte Resource-Based Constrained Delegation (RBCD) bevorzugt eingesetzt werden. Diese Form erlaubt es dem Zielsystem, die Vertrauensbeziehungen selbst festzulegen, wodurch die Kontrolle über den Delegierungsfluss deutlich verbessert wird.

Zusätzlich gibt es zwei besonders wirksame Massnahmen, um Benutzerkonten vor Missbrauch durch Delegierung zu schützen:

1. Die Mitgliedschaft in der “Protected Users”-Gruppe verhindert vollständig, dass Benutzerkonten für Delegierung verwendet werden können. Sie bietet zusätzliche Schutzmechanismen wie die Verhinderung von NTLM-Nutzung oder Ticket-Weitergabe und eignet sich besonders für privilegierte Konten wie Domain-Admins.

2. Delegierungsflag (Die Einstellung “Account is sensitive and cannot be delegated” schützt gezielt einzelne Benutzer- oder Dienstkonten, indem sie verhindert, dass deren Kerberos-Tickets für Delegierungszwecke genutzt werden können, unabhängig vom gewählten Delegierungstyp.)

Ergänzt werden sollten diese Massnahmen durch regelmässige Überprüfung der Delegierungskonfiguration (z. B. mit PowerShell oder Analyse-Tools wie BloodHound), ein sauber strukturiertes Tiering-Modell, gezielte Zugriffsbeschränkungen für Dienstkonten sowie umfassendes Logging und Monitoring.

Kurz gesagt: Delegierung sollte immer auf das notwendige Minimum beschränkt, aktiv überwacht und durch gezielte Kontoschutzmassnahmen wie “Protected Users” und das Delegierungsflag abgesichert werden. So lässt sich ein hohes Mass an Sicherheit in Active Directory-Umgebungen erreichen, selbst in komplexen, dienstübergreifenden Szenarien.