Das LocalSystem-Konto in der AD-Gesamtstruktur ist ein riskantes Geschäft

Das LocalSystem-Konto gibt es seit Windows NT, aber nur wenige Administratoren verstehen es wirklich.

Obwohl es sich um ein leistungsstarkes Konto handelt, wird es häufig als Krücke für Anwendungsentwickler verwendet, die nicht herausfinden möchten, welche Sicherheit sie benötigen. Das LocalSystem-Konto weist einige interessante Merkmale auf, die Sicherheitsrisiken verursachen, insbesondere in Gesamtstrukturen mit mehreren Domänen.

Schauen wir uns zunächst einige grundlegende Konzepte des LocalSystem-Kontos an. Das Konto ist auf jedem Windows-Computer vorhanden – unabhängig davon, ob es sich um eine Client-Workstation, einen Domänencontroller oder einen Server handelt. Dieses Konto hat die vollständige Kontrolle über den Computer und kann nicht gesperrt oder von Berechtigungen ausgeschlossen werden.

Die Merkmale dieses Kontos umfassen:

  • Zugriff auf alle Prozesse, einschließlich Systemprozesse
  • Voller Zugriff auf lokale Ressourcen
  • Anwendungen, die möglicherweise im Kontext des LocalSystem-Kontos ausgeführt werden
  • Vordefiniertes Konto in Windows
  • Verwendung der Berechtigungen des Computerkontos für den Zugriff auf Netzwerkressourcen

Auf einem Domänencontroller hat das LocalSystem-Konto vollen Zugriff auf Active Directory, da ein Replikat im Dateisystem des lokalen Computers vorhanden ist und daher als lokale Ressource betrachtet wird.

In Windows NT gab es nur eine einzige beschreibbare Kopie der SAM-Datenbank, und es gab kein Konzept für eine Gesamtstruktur, die Domänen und Domänensicherheit miteinander verbindet, außer durch externe Vertrauensstellungen. Die Domain war die Sicherheitsgrenze.

Dies machte das LocalSystem-Konto ziemlich sicher. Windows 2000 führte das Konzept einer Gesamtstruktur und zwei zusätzlicher Namenskontexte oder Verzeichnispartitionen ein: die Schema- und Konfigurationspartitionen. Diese Partitionen enthalten Informationen zu jedem Domänencontroller, jeder Domäne und andere gesamtstrukturweite Informationen wie die Replikationstopologie.

Zwei bestimmte Gruppen in Active Directory haben Zugriff auf diese Informationen. Die Gruppe Unternehmensadministratoren hat Zugriff auf Domänen- und Konfigurationsinformationen, während die Gruppe Schemaadministratoren Zugriff auf Schemadaten hat. Die Gruppe “Domänenadministratoren” hat Rechte an den Ressourcen in einer bestimmten Domäne.

Konten erhalten entsprechend die Berechtigungen, die für die Domänen- und Gesamtstrukturverwaltung unter Verwendung dieser Gruppen erforderlich sind. Das LocalSystem-Konto ist jedoch ein Platzhalter. Wie bereits erwähnt, besteht eines der Merkmale des LocalSystem-Kontos darin, dass es vollen Zugriff auf Active Directory hat, da auf jedem Domänencontroller Replikate des AD vorhanden sind.

Die Gefahren, die dieses Konto auf einem Domänencontroller darstellt, sind etwas beängstigend, da sie über das normale Delegierungsdesign hinausgehen, bei dem wir versuchen, bestimmte Konten im Zugriffsbereich einzuschränken. Beispielsweise gehen wir normalerweise davon aus, dass ein Domänenadministrator keinen Zugriff auf das Schema oder die Konfigurationspartitionen hat.

Beachten Sie, dass ein Domänenadministratorkonto im Kontext des LocalSystem-Kontos ausgeführt wird. Dies bedeutet, dass der Domänenadministrator die Kontrolle über alle Ressourcen auf einem Domänencontroller hat. Darüber hinaus sind die Domänen-, Konfigurations- und Schemakonfigurationen auf jedem Domänencontroller vorhanden, und das LocalSystem-Konto hat Zugriff auf alle Ressourcen auf einem Computer. Daraus folgt, dass der Domänenadministrator nicht nur auf Domänenressourcen, sondern auch auf Ressourcen in der Gesamtstruktur einschließlich anderer Domänen zugreifen kann. Noch beängstigender ist, dass jeder Dienst, der im Kontext des LocalSystems ausgeführt wird, denselben Zugriff hat.

Es gibt eine Reihe von Möglichkeiten, wie diese Ausnutzung erreicht werden kann. Sie müssen nur einen Befehl oder Prozess ausführen, der im LocalSystem-Kontext ausgeführt wird, und Ihre Arbeit durch diesen Prozess ausführen.

Beispielsweise wird der Taskplanerdienst, auf den der AT-Befehl zugreift, unter diesem Konto ausgeführt. Jeder Domänenadministrator auf einem Domänencontroller kann also Aufgaben wie den Schema-Manager planen und Zugriff zum Ändern des Schemas erhalten.

Darüber hinaus kann dieses Konto für den Zugriff auf Exchange-Informationen verwendet werden, da Routinggruppen, die Konfiguration öffentlicher Ordner, der Name der Organisation und andere Daten im Kontext der Konfigurationsnamen vorhanden sind und domänenübergreifend verfügbar sein müssen. Es ist auch möglich, dass ein Domänenadministrator Zugriff auf Postfachdaten für Exchange-Empfänger erhält. Beachten Sie, dass in einem Domänencontroller ungefähr 30 Dienste ausgeführt werden, die alle für den Domänenadministrator anfällig sind.

Der Fall des DSRM ohne AD-Sicherheit

Vor einigen Jahren rief mich ein Kunde an und beschwerte sich, dass ein Domänenadministrator die Gesamtstruktur seiner Organisation “beschädigt” habe. Es wurde eine Konfiguration mit mehreren Domänen in einer einzelnen Gesamtstruktur ausgeführt. Der Domain-Administrator hatte beschlossen, eine autorisierende Wiederherstellung durchzuführen. Leider hat er zusätzlich zu seiner Domain einige Teile der Konfigurationspartition wiederhergestellt. Dies hatte zur Folge, dass mehrere DCs wiederbelebt wurden, die außer Betrieb genommen worden waren und die Replikation unterbrochen hatten.

Mein Client wollte wissen, wie ein Domänenadministrator Zugriff auf die Gesamtstrukturressourcen haben kann. Es ist ziemlich einfach. Beachten Sie, dass Sie für eine autorisierende Wiederherstellung im Verzeichnisdienst-Wiederherstellungsmodus (DSRM) starten, der keinen Active Directory-Zugriff hat. Die Sicherheit ist das DSRM-Administratorkonto. Sobald Sie DSRM starten, gibt es keine AD-Sicherheit, wodurch der Domänenadministrator eine kostenlose Berechtigung erhält, alles zu tun, was er oder sie tun möchte.

Es gibt keine andere Möglichkeit, dies zu verhindern, als durch physische Sicherheit oder das Entfernen der Person als Domänenadministrator. Da der Domänenadministrator das Ntdsutil ausführen kann, wenn er angemeldet ist, kann er das DSRM-Administratorkennwort ändern, sodass Sie das Kennwort auch nicht geheim halten können.

Hier müssen zwei wichtige Punkte beachtet werden, um Ihren Wald mit diesem Konto vor Angriffen zu schützen:

  1. Achten Sie darauf, wem Sie das Domänenadministratorrecht erteilen. Mein Artikel Active Directory: Sichern der Domäne über den Domänencontroller enthält eine Reihe von Möglichkeiten, wie ein Domänenadministrator Active Directory gefährden kann, und gibt Empfehlungen zur Risikominderung. Fazit: Geben Sie dieses Privileg nicht an jemanden weiter, dem Sie nicht vollständig vertrauen.
  2. Führen Sie keine Dienste unter dem LocalSystem-Konto aus, es sei denn, Sie müssen, zu … haben. Es gibt bereits ungefähr 30 Dienste auf einem Domänencontroller, die in diesem Kontext ausgeführt werden. Sie werden wahrscheinlich auch viele Anwendungen finden, die Dienste unter LocalSystem ausführen, da dies einfach ist. Verwenden Sie einfach das LocalSystem-Konto und sorgen Sie sich nicht um Berechtigungen. Natürlich könnte ein Angreifer einen dieser Dienste verwenden, um nicht nur den DC, sondern auch die gesamte Gesamtstruktur anzugreifen. Dies sollte Ihre Entscheidung zur Implementierung einer Anwendung beeinflussen.
  3. Beachten Sie, dass andere Domänen in einer Gesamtstruktur mit mehreren Domänen nicht gefährdet sind, da ein bestimmter Domänencontroller nur Informationen zu dieser einen Domäne enthält und GCs nur Lesezugriff haben.

Gary Olsen ist Systemsoftware-Ingenieur bei Hewlett-Packard im Bereich Global Solutions Engineering. Er hat geschrieben Windows 2000: Active Directory-Entwurf und -Bereitstellung und Co-Autor von Windows Server 2003 auf HP ProLiant Servern. Olsen ist ein Microsoft MVP für Verzeichnisdienste und früher für Windows-Dateisysteme.

Similar Posts

Leave a Reply