Admin Tiers, Einfache Maßnahmen für mehr Sicherheit im AD
https://www.frankysweb.de/einfache-massnahmen-fuer-mehr-sicherheit-im-ad-teil-3-admin-tiers/
Ganze Serie: https://www.frankysweb.de/?s=Einfache+Ma%C3%9Fnahmen+f%C3%BCr+mehr+Sicherheit
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:
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”:
Die Gruppe “Tier0Admins” wird zum Schluss noch Mitglied der Gruppe “Domain-Admins”:
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:
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:
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" |
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”:
Für beide Richtlinien können die “Benutzerkonfigurationseinstellungen” deaktiviert werden:
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):
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”:
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:
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:
Hier einmal die Übersicht mit der entsprechenden Gruppenzuordnung für “Standard Sicherheit Tier 2”:
Hier hier die Übersicht für “Standard Sicherheit Tier 1”:
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:
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:
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
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.
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:
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):
Gleiches gilt für RDP Verbindungen:
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:
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:
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
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.
Hochgeladene Dateien: