Einfache Maßnahmen für mehr Sicherheit im AD (Teil 3): Admin Tiers

Die grundlegende Funktionsweise der Admin Tiers hatte ich bereits in Teil 1 dieser Artikelserie beschrieben, in diesem Artikel geht es nun um die Einrichtung von Admin Tiers in einer bestehenden Umgebung. Grundsätzlich ist es sinnvoll, wenn bereits mindestens ein Admin Host installiert wurde.

Im Großen und Ganzen geht es in diesem Artikel erst einmal darum die Admin Tiers zu konfigurieren und durchzusetzen. Später können noch weitere Maßnahmen durchgeführt werden, welche die Sicherheit weiter verbessern können. Wenn Admin Tiers und Admin Host aber schon einmal konfiguriert sind und auch nach dem Prinzip genutzt werden, ist man hinsichtlich der Sicherheit schon ein großes Stück weiter.

Benutzerkonten und Gruppen erzeugen

Damit die Administration der Server und Clients innerhalb des Active Directory konform zu den Admin Tiers funktioniert, sind mindestens drei neue Benutzerkonten und drei neue Gruppen erforderlich. Für jeden Admin Tier (Tier 0, Tier 1, Tier 2) wird eine neue Gruppe im Active Directory erstellt. Dazu kommt je Admin Tier mindestens ein Benutzerkonto.

Ich habe in meiner Beispielumgebung die OU “Administration” und darin die OUs “Administrative Gruppen” und “Administrative Konten” erstellt. Innerhalb der OUs habe ich dann jeweils die Gruppen “Tier0Admins”, “Tier1Admins” und “Tier2Admins” erstellt:

Gruppen und Admin Konten

In meiner Beispielumgebung gibt es nur 3 administrative Konten “Tier0Admin”, Tier1Admin” und “Tier2Admin”. Dies ist beispielsweise in kleinen Umgebungen/Firmen der Fall, in der eine Person alle drei Tiers administriert. Gibt es mehrere Administratoren mit unterschiedlichen Rollen, werden auch mehrere administrative Konten je Tier benötigt. Gibt es beispielsweise ein Help Desk welches bei Client Problemen unterstützt, dann erhält jeder Client Admin ein Tier 2 Admin Konto. Gleiches gilt für die Server Administratoren: Wenn es ein Team von Mitarbeitern gibt, welches die Server verwaltet und administriert, bekommt jeder der Admins sein eigenes Tier 1 Admin Konto.

Die Anzahl der Personen die ein Tier 0 Admin Konto bekommen, sollte möglichst überschaubar sein, aber auch hier gilt, jeder der Domain Admins erhält sein eigenes Tier 0 Admin Konto.

Die administrativen Benutzer werden nun den entsprechenden Gruppen zugeordnet. Tier 0 Admins kommen in die Gruppe “Tier0Admins”, Tier 1 Admins in die Gruppe “Tier1Admins” und Tier 2 Admins in die Gruppe “Tier2Admins”:

Gruppen und Admin Konten

Die Gruppe “Tier0Admins” wird zum Schluss noch Mitglied der Gruppe “Domain-Admins”:

Gruppen und Admin Konten

Wichtig: Ein Tier Admin Konto darf nicht “Tier-übergreifend” zugeordnet werden. Ein Tier 1 Admin Konto darf nur Mitglied der Gruppe Tier 1 Admins sein, aber nicht der Gruppe Tier2Admins oder Tier0Admins. Ein Konto welches administrative Berechtigungen auf Servern hat, darf also keine administrativen Berechtigungen auf Clients erhalten.

Nachdem die Benutzer und Gruppen erzeugt wurden, kann die OU Struktur erweitert bzw. erzeugt werden.

OU Struktur erzeugen

Um die Admin Tiers durchzusetzen, muss zwar nicht zwingend eine neue OU Struktur erstellt werden, es erleichtert aber die Übersicht. Die Admin Tiers lassen sich auch meist in vorhandene OU Strukturen integrieren, jedoch ist es dann meist etwas schwieriger den Überblick zu behalten, gerade bei der Einführung der Admin Tiers in bestehende Umgebungen macht es daher Sinn, neue OUs für die Admin Tiers zu erstellen.

Eine vorhandene Umgebung könnte beispielsweise die folgende OU Struktur haben:

OU Struktur

Es gibt eine OU “Clients” in der alle Computerkonten der PCs und Notebooks verwaltet werden. In der OU “Server” sind alle Computer Konten der Server gespeichert. Die Computer Konten der Domain Controller befinden sich in der OU “Domain Controllers”. Die Server und Clients sind hier noch nicht klassifiziert, dies folgt erst später.

Um eine OU Struktur für die drei Admin Tiers zu schaffen, können in dieser Beispielumgebung nun drei neue OUs angelegt werden: Tier 0, Tier 1 und Tier 2.

Da PCs und Laptops dem Tier 2 zugeordnet werden, kann innerhalb der OU “Clients” eine neue OU mit dem Namen “Tier 2” angelegt werden. Da Server sich in Tier 0 oder Tier 1 befinden können, werden unterhalb der OU Server die OUs “Tier 1” und “Tier 0” erzeugt:

OU Struktur

Bei der Aufnahme von neuen Rechnern in das Active Directory, werden die Computerkonten in der Standardeinstellung in der OU “Computers” erzeugt, dies ist für die Admin Tiers etwas ungünstig (dazu später mehr).

Damit neue Computerkonten (Server sowie Clients) nicht mehr in der OU “Computers” erstellt werden, kann eine andere OU angegeben werden. Mit dem folgenden Befehl werden alle neuen Computerkonten in der OU “Clients” erzeugt und nicht mehr in der OU “Computers”:

1
redircmp "OU=Clients,DC=frankysweblab,DC=de"

Umleitung der Clients

Neue Server und Clients landen somit in der OU Clients, damit eine Klassifizierung der neuen Rechner durchgeführt und die Admin Tiers durchgesetzt werden, lassen sich Gruppenrichtlinien verwenden. Diese Gruppenrichtlinien werden nun erstellt.

Hinweis: Wenn bereits eine OU Struktur im Unternehmen erzeugt wurde, lässt sich diese in den meisten Fällen auch weiter verwenden  oder entsprechend erweitern. Damit die Admin Tiers umgesetzt und durchgehalten werden, kommt es auf die Klassifizierung der Systeme und die Zuordnung der Gruppenrichtlinien an. Wie viele OUs es gibt und wie diese heißen ist dabei Nebensache, solange die Klassifizierung der Rechner zu den entsprechenden Tiers und die Zuordnung der Gruppenrichtlinien zu den OUs sauber ist.

Gruppenrichtlinien erstellen

Mittels Gruppenrichtlinien wird nun durchgesetzt, dass sich keine Tier1 Administratoren auf Tier 2 Systemen und Tier0 Administratoren nicht auf Tier 1 und Tier 2 Systemen anmelden können. Dazu sind zwei neue Gruppenrichtlinien nötig, in diesem Fall heißen die beiden (noch leeren) Gruppenrichtlinien “Standard Sicherheit Tier 1” und “Standard Sicherheit Tier 2”:

Gruppenrichtlinien für Admin Tiers

Für beide Richtlinien können die “Benutzerkonfigurationseinstellungen” deaktiviert werden:

Gruppenrichtlinien

Jetzt kann zunächst die GPO “Standard Sicherheit Tier 1” bearbeitet werden. In dieser GPO muss nun den Tier 0 Admins die Anmeldung verweigert werden (Lower Tier Logon, siehe letztes Bild in diesem Abschnitt):

Einstellungen der Gruppenrichtlinien

Einstellungen der Gruppenrichtlinien

Für die Gruppe “Tier0Admins” werden also die folgenden 5 Einstellungen konfiguriert:

  • Anmelden als Batchauftrag verweigern
  • Anmelden als Dienst verweigern
  • Anmelden über Remotedesktopdienste verweigern
  • Lokal anmelden verweigern
  • Zugriff vom Netzwerk auf diesen Computer verweigern

Hier noch einmal die Einstellungen in der Übersicht für die Gruppenrichtlinie “Standard Sicherheit Tier 1”:

Einstellungen der Gruppenrichtlinien

In der GPO “Standard Sicherheit Tier 2” werden nun die gleichen 5 Einstellungen bearbeitet, jedoch wird den Tier0Admins und den Tier1Admins die Anmeldung verweigert. Auch hier einmal die Einstellungen für die GPO “Standard Sicherheit Tier 2” in der Übersicht:

Einstellungen der Gruppenrichtlinien

Damit nun auch die Konten der Admin Tier Gruppen lokale Administrator Rechte auf den jeweiligen Systemen bekommen, können die beiden GPOs entsprechend angepasst werden. In der GPO “Standard Sicherheit Tier 2” wird die Gruppe “Tier2Admins” zu lokalen Gruppe “Administratoren” hinzugefügt:

Einstellungen der Gruppenrichtlinien

Hier einmal die Übersicht mit der entsprechenden Gruppenzuordnung für “Standard Sicherheit Tier 2”:

Einstellungen der Gruppenrichtlinien

Hier hier die Übersicht für “Standard Sicherheit Tier 1”:

Einstellungen der Gruppenrichtlinien

Die beiden neuen Gruppenrichtlinien werden nun mit den entsprechenden OUs verknüpft, die Richtlinie “Standard Sicherheit Tier 1” wird mit allen OUs verknüpft, welche Tier 1 Systeme enthalten. “Standard Sicherheit Tier 2” wird mit den OUs verknüpft welche Tier 2 Systeme enthalten:

Verknüpfung der Gruppenrichtlinien

OUs mit Tier 0 Systemen erhalten zunächst keine speziellen GPOs. Ohne spezielle Richtlinie können sich an Tier 0 Systemen (OU Domain Controllers, Server/Tier0) in der Regel eh nur Mitglieder der Gruppe Domain-Admins anmelden. Dies wäre in diesem Fall der Benutzer Tier0Admins und das Konto “Administrator”. Das Konto “Administrator” wird im späteren Verlauf noch deaktiviert. Das “Lower Tier Logon” ist in diesem Fall also schon verhindert, wenn die Systeme entsprechend klassifiziert werden:

Einfache Maßnahmen für mehr Sicherheit im AD (Teil 3): Admin Tiers

Systeme der Admin Tiers klassifizieren

Das Einordnen der Systeme ist die größte Herausforderung, hier muss genau geprüft werden zu welchem Tier ein System gehört. In der Theorie ist es ganz einfach:

  • Domain Controller sind Tier 0 Systeme
  • Alle Server sind Tier 1 Systeme
  • Alle Clients sind Tier 2 Systeme

Einfache Maßnahmen für mehr Sicherheit im AD (Teil 3): Admin Tiers

Die Realität sieht allerdings etwas anders aus. Exchange Server verfügen beispielsweise über sehr weitreichende Berechtigungen im Active Directory, Exchange Server sind daher eher dem Tier 0 als dem Tier 1 zuzuordnen. Beim Klassifizieren der Systeme, muss berücksichtigt werden, welche Kontrolle ein System über andere Systeme hat.

Wenn es beispielsweise eine Backuplösung gibt, welche über einen Agent auf Server, Domain Controller und Clients verfügt und zudem noch der Agent mit einem Domain Konto betrieben wird, zählt die Backup Lösung als Tier 0 System. Nehmen wir mal an die Backup Software läuft der Einfachheit halber mit Domain Admin Rechten (ist so schön einfach und man muss sich keine Mühen um entsprechende Berechtigungen machen), so könnte ein Angreifer das Konto der Backup Software auf einem Client kompromittieren und dieses Konto zur Anmeldung an Servern und Domain Controller verwenden. Genau dies soll aber durch die Admin Tiers verhindert werden.

Damit das Tier 0 also möglichst klein bleibt, muss man sich die eingesetzte Software genau anschauen und gegebenenfalls entsprechend um konfigurieren. Backupsoftware muss nicht mit Domain Admin Rechten laufen und kann meistens unterschiedliche Konten für Server und Clients verwenden. Auch viele andere Software wird oft mit Domain Admin Rechten gestartet, beispielsweise Inventarisierungs- und Dokumentationsprogramme.

Hier muss man sich also gerade in gewachsenen Umgebungen die Mühe machen und Programme, Dienste und Server prüfen, damit diese entsprechend in die Tiers eingeordnet werden können. Meistens ist auch einiges an Konfigurationsarbeit nötig, damit ein Client oder Server nicht mehr potenziell höhere Tiers kontrollieren kann.

Einfache Maßnahmen für mehr Sicherheit im AD (Teil 3): Admin Tiers

Sobald man sich klar ist, zu welchem Tier welches System gehört, können die Computerkonten in die entsprechenden OUs verschoben werden. Ich habe die Klassifizierung für meine kleine Beispielumgebung wie folgt vorgenommen:

Klassifizierung der Systeme

Die Domain Controller bleiben in der OU “Domain Controllers” und werden nicht in die OU “Server / Tier 0” verschoben. Die beiden Exchange Server EX1 und EX2 sind als Tier 0 Systeme eingeordnet, da diese nicht im Split Permission Modus installiert wurden. Die weiteren Server sind Tier 1 Systeme und alle Clients wurden als Tier 2 Systeme eingestuft.

Hinweis: Wenn Exchange Server nicht im Split Permission Mode installiert wurden und eine DAG das File Share Witness auf einem File Server speichert, gehört der File Server ebenfalls dem Tier 0 an. Hier könnte für das FSW also ein dedizierter File Server verwendet werden, welcher keine Freigaben für Benutzer anbietet.

Testen der Admin Tiers

Nachdem die Gruppenrichtlinien auf den Systemen angewendet wurden, kann getestet werden, ob das Lower Tier Logon erfolgreich verweigert wird. Es sollte also nicht mehr möglich sein, sich mit dem Benutzer Tier0Admin an Tier 1 und Tier 2 Systemen anzumelden. Tier 1 Admins dürfen sich wiederum nicht an Tier 2 Systemen anmelden.

Die folgende Meldung wird erscheint, wenn sich ein Benutzer an einem nicht zulässigem Tier anmelden möchte (in diesem Fall per Konsole/lokal):

Testen der Admin Tiers

Gleiches gilt für RDP Verbindungen:

Testen der Admin Tiers

Anmeldungen an die jeweiligen Systeme des gleichen Tiers werden nicht verweigert (Same Tier Logon).

Bisher wurde weder die Gruppe “Domain-Admins” noch das Konto “Administrator” beschränkt, falls also etwas schief gegangen ist, kann sich aktuell immer noch mit dem Konto “Administrator” oder einem anderen Mitglied der Gruppe “Domain-Admins” an den Systemen angemeldet werden. Das Konto “Administrator” kann nach erfolgreichen Tests deaktiviert werden, die Einschränkung der Gruppe “Domain-Admins” ist Bestandteil des nächsten Artikels.

Administrator Konto deaktivieren und umbenennen

Nachdem die Anmeldung der Benutzer getestet wurde, kann das Konto “Administrator” umbenannt und deaktiviert werden. Zur Administration der verschiedenen Admin Tiers, werden jetzt nur noch die jeweiligen Benutzer verwendet. Das Konto “Administrator” wird nicht mehr benötigt:

Administrator Konto

Zusätzlich kann das Konto auch noch umbenannt werden, zwar ändert sich dadurch nicht die SID, trotzdem laufen durch die Änderung des Benutzernamens viele automatisierte Scripte ins Leere:

Administrator Konto

Das Konto wird nicht mehr verwendet, daher schadet es auch nicht das Konto umzubenennen. Nachdem das Konto deaktiviert wurde, lohnt es sich das Windows Eventlog nach fehlgeschlagenen Anmeldung des Kontos “Administrator” zu durchsuchen. Es könnte ja sein, dass noch Tasks oder andere Programme das Konto verwenden, dies lässt sich dann entsprechend um konfigurieren.

Zum Schluss sollten auch noch die kritischen Gruppen kontrolliert werden, ob beispielsweise noch weitere Konten Domain-Admin Berechtigungen haben. Diese Gruppen sollten daher einmal geprüft werden:

  • Domänen-Admins
  • Schema-Admins
  • Organisations-Admins

Administrator Konto

Hinweis: Schema- oder Organisations-Admin Berechtigungen werden im Normalfall so selten benötigt, dass man hier ein Konto bei Bedarf berechtigen kann. Wenn man beispielsweise das Schema aktualisieren oder erweitern muss, reicht es, wenn man sich vor dem Vorgang die entsprechenden Rechte mit dem Tier0Admin gibt und diese nach dem Vorgang wieder entfernt.

Weitere Maßnahmen

Die Umsetzung der Admin Tiers ist an dieser Stelle noch nicht komplett, aber wenn man erst einmal an dieser Stelle angekommen ist, ist man wieder ein großes Stück weiter. Im Idealfall hat man nun also bereits einen ganz normalen Client für sein Tagewerk, einen Admin Host der nur für die Administration verwendet wird und Admin Tiers welche grundlegende Sicherheitsrichtlinien für privilegierte Konten durchsetzen.

Im nächsten Artikel werden dann noch weitere Maßnahmen bezüglich der Admin Tiers umgesetzt. Dies sind im wesentlichen die folgenden 3 Punkte:

  • Beschränkung der Gruppe “Domain-Admins”
  • Security Zones – Mehrere Administratoren je Tier
  • Umgang mit nicht klassifizierten Systemen
  • Auditierung

Ein weitere Baustelle ist das lokale Konto “Administrator” auf Servern und Clients. Hier kommt dann LAPS in Spiel. Voraussichtlich wird LAPS dann übernächsten Artikel konfiguriert.

8 Kommentare zu “Einfache Maßnahmen für mehr Sicherheit im AD (Teil 3): Admin Tiers”

  1. Sehr interessanter Artikel,
    ich versuche das auch weitestgehend umzusetzen. Jetzt nicht im vollen Umfang aber das Adminkonten für Domänen keinen Adminzugriff auf die Clients haben und umgekehrt die Admins der Clients keinen Adminzugriff auf die Domäne.
    Da ich für ein Systemhaus die Administration mache haben die Techniker dort 2 Domäneuser einen normalen ohne Rechte und einen mit Adminrechten auf die Clientumgebung. Als ich das umgesetzt habe stand ich vor dem Problem wie ich verhindere das die User sich mit dem Adminkonto einloggen und aus Bequemlichkeit nur noch diesen verwenden. Die einzige Lösung, die ich damals gefunden habe, ist ein Anmeldescript per GPO zu machen der beim Anmelden „logoff“ ausführt.
    Hättest du das anders gelöst?
    Wie händelst du so dinge wie z.B. Backupsoftware wie in meinem Fall jetzt Veeam. Der für seine Backups einen User möchte. Oftmals sehe ich das dann einfach ein Backup Admin erstellt wird, der alle Rechte hat und zugriff auf alle Systeme… Aber das würde ja das ganze Konzept wieder kaputt machen. Eine zufriedenstellende Lösung hierfür habe ich bis jetzt auch noch nicht gefunden. Ich hatte mal überlegt ob ich für jedes System einen User erstelle und Veeam diesen per Script immer aktivieren und deaktivieren lasse für die Zeit des Backups. Dazu bin ich allerdings noch nicht gekommen.

    Grüße Daniel

    1. Hallo Daniel,
      verstehe ich es richtig, dass die Techniker ein Tier 2 Admin Konto haben und sich damit ständig an ihren PCs anmelden? Die Frage wäre dann, machen die Techniker das nur aus Bequemlichkeit, oder gibt es einen bestimmten technischen Hintergrund? Auf einen technischen Hintergrund müsstest du eingehen und eine Lösung finden. Damit die Techniker sich nicht aus Bequemlichkeit anmelden, könnte man (beispielsweise) per GPO die lokale Anmeldung für Tier 2 Konten verbieten. Möglicherweise ist hier aber auch eine Sensibilisierung der Techniker sinnvoll. Die Mittel hängen hier stark vom Unternehmen ab, gerade in einem Systemhaus sollte ein gewisses Sicherheitsbewusstsein herrschen, welches auch vom höheren Management gefordert und vom Admin durchgesetzt wird.
      Bezüglich der Backup Software: Im einfachsten Fall wird je Admin Tier ein anderer Benutzer verwendet. Clients werden mit Backup User A und Server mit Backup Server B gesichert. Die meisten Hersteller geben an, welche Berechtigungen benötigt werden, diese lassen sich dann entsprechend konfigurieren. Admin Rechte sind in der Regel nicht für das Backup nötig. Auch hier gilt wieder, es handelt es um einen Service Account, die Anmeldung erfolgt also in der Regel nur als Dienst oder Remote, aber die interativ (Konsole oder RDP). Dies lässt sich dann auch wieder per GPO einschränken. Auch die Windows Firewall kann hier unterstützen, indem beschränkt wird, welche Hosts auf welche Dienste des Clients zugreifen dürfen.
      Gruß,
      Frank

      1. Hallo Frank,

        die Techniker selbst haben jeweils 2 Konten ein normalen User ohne Rechte und ein Tier 2 Admin Account. Mit dem Admin Account kann man sich nicht anmelden. Der kann nur benutzt werden um einzelen Programme mit erhöhten Rechten auzuführen. Damit die Techniker sich nicht direkt mit dem Tier 2 Admin Account anmelden hab ich das mit einem Anmeldescript gelöst in dem einfach nur „logoff“ drin steht. Per Sicherheitsrichtline hab ich das nicht gelöst bekommen egal wie ich es eingestellt hatte, konnte ich mich zwar nicht mehr anmelden allerdings konnte ich dann auch keine Programme als Administrator ausführen.

  2. Hallo Frank,
    ich finde diese Reihe sehr gut.
    Wann kann man mit den Versprochenen Artikeln zu
    „Im nächsten Artikel werden dann noch weitere Maßnahmen bezüglich der Admin Tiers umgesetzt. Dies sind im wesentlichen die folgenden 3 Punkte:
    – Beschränkung der Gruppe “Domain-Admins”
    – Security Zones – Mehrere Administratoren je Tier
    – Umgang mit nicht klassifizierten Systemen
    – Auditierung“
    rechnen?

  3. Hallo,
    sollte es nicht so konfiguriert werden, dass die Gruppe „Domänen-Admins“ Mitglied der Gruppe „Tier0Admins“ ist?
    Damit wäre doch sichergestellt, dass kein Mitglied aus der Gruppe der Dom-Admins sich auf Tier2-Systeme anmelden kann?

    Oder habe ich einen Denkfehler?

    Gruß

  4. Hallo,

    sehr interesante Artikel-Reihe. Wo würde sich bei diesem Konzept ein Terminalserver einreihen? Wäre das dann T2 oder sogar noch T3?
    Danke und Gruss.

  5. Hallo Frank,
    auch ich als treuer Leser würde gerne erfahren, wann Du geplant hast den Artikel zu diesen Themen zu veröffentlichen:
    Im nächsten Artikel werden dann noch weitere Maßnahmen bezüglich der Admin Tiers umgesetzt. Dies sind im wesentlichen die folgenden 3 Punkte:

    Beschränkung der Gruppe “Domain-Admins”
    Security Zones – Mehrere Administratoren je Tier
    Umgang mit nicht klassifizierten Systemen
    Auditierung

    Für Deine Antwort vorab herzlichen Dank

    Gruß Andreas

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.