Administrative Konten schützen - AD im List Object Mode betreiben
Wir dürfen es den bösen Jungs nicht so leicht machen an sensible Informationen in unserem AD zu kommen. Alleine die Kenntnis, welche Administrativen Konten existieren, welche Konten in welchen Gruppen stecken, stellen einen Angriffsvektor dar. Logischerweise werden diese Konten als erstes Ziel ausgegeben. Demnach ist Informationsreduktion ein wichtiger Faktor eurer Härtung.
Sind die bösen Jungs erst einmal mit administrativen Konten unterwegs, dann ist das System verloren. Solange sie aber noch normale Benutzer sind (Authentifizierte Benutzer), können wir Ihnen den Zugriff auf die Information der Administrativen Konten und Dienste, sensible Konten im Allgemeinen, erschweren, sogar verhindern.
Wir nutzen den List Object Mode im Active Directory. Dieser ist vergleichbar mit dem bekannteren Accessbased Enumeration aus dem Filesystem. In beiden Fällen ist es so, das ein Benutzer nur das sieht, was er auch lesen darf. Darf der User eine OU nicht lesen, dann wird sie und ihr Inhalt mit keinem Werkzeug angezeigt.
Das AD wurde mal gebaut um Multi Tennant tauglich zu sein. Es können zB in einem Franchise System diverse Kunden in einem AD hinterlegt werden, die sich untereinander nicht sehen dürfen. Diese Idee nehmen wir und erklären unsere Administration zu einem weiteren Kunden im AD. Wir haben praktisch 2 Kunden im AD. Die Administration und alle anderen. Wenn das System erst einmal etabliert ist, kann es weiter granular runtergebrochen werden.
Quicksteps:
- List Object Mode aktivieren
- Administrative-, Service Konten, Gruppen und alles was man schützen möchte liegt in einer eigenen OU unterhalb einer OU
- Gruppe erstellen die diese OU abbildet
- Alle Objekte (User und Computer (AdminWorkstations)) darin aufnehmen
- Berechtigungen setzen
- Einen logischen Fehler akzeptieren :-)
List Object Mode aktivieren
Wir editieren das dsHeuristics Attribut in der Configuration Partition des AD. Es muss das 3te Bit auf "1" gesetzt werden. In den meisten ADs ist der Wert "nicht festgelegt". In diesem Fall müssen die führenden Nullen mit angegeben werden: "001", sind weitere Einträge vorhanden, dann bleiben dieser wie sie sind.Wir editieren nur die dritte Stelle.
Das Attribut finden wir in den Eigenschaften: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=gallier,DC=ads
AD Struktur
Wir benötigen eine AD Struktur, die die Administration abbildet. Diese muss unterhalb einer vorhandenen OU liegen, denn wir ERSETZEN die Authentifizierten Benutzer gegen eine EIGENE. Damit es nicht zu unerwünschten Nebeneffekten kommen kann, sollte das alles in einer eigenen OU unterhalb des Domänen Kopfes stattfinden, sodass die Authentifizierten Benutzer, das sind auch Computer, weiterhin auf alle AD Systemrelevanten Objekte zugreifen können.
Da wir, wie geschrieben, die Authentifizierten Benutzer ersetzen benötigen wir eine AD Gruppe, die anstelle dieser in dieser OU alles lesen darf. In meinem Namenskonzept nenne ich im Namen der Gruppe die Art, für was sie verwendet wird, den Ort, wo sind zum Einsatz kommt und das Recht, das sie hat.
AD-DasDorf-Administration-R = Die Gruppen wird in der AD Datenbank verwendet, für die OU Das Dorf\Administration delegiert und hat Leserechte (Read).
Berechtigungen setzen
- Einstiegs OU, in meinem Fall: "Das Dorf":
Die Gruppe "Prä-Windows2000 kompatibel" entfernen. Der Gruppe "Authentifizierte Benutzer" das Recht "Inhalt auflisten" (LC, List Child) entfernen. - Administrations OU:
Auf der OU die Vererbung unterbrechen, vorhandene Berechtigungen in explizite konvertieren und dann der "AD-DasDorf-Administration-R" Leserechte (GE = Generic Read) gewähren. Die "Authentifizierten Benutzer" und "Jeder" entfernen - Auf allen vorhandenen Objekte unterhalb dieser OU die "Authentifizierten Benutzer" entfernen, das geht am einfachsten per Script. Dieses kann auch regelmässig ausgeführt werden
- Alle Benutzer und Computer in der Administration in die Sicherheitsgruppe "AD-DasDirf-Administration-R" als Mitglieder aufnehmen. Auch das kann per Script erfolgen und regelmässig ausgeführt werden.
Script Schnippsel, Powershell zur Ausführung von dsacls.exe
# Name der Authentifizierten Benutzer ermitteln, sprachunabhängig
$SID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-11")
$User = $SID.Translate( [System.Security.Principal.NTAccount])
# Objekt am \ trennen, \ mit "\" maskieren
$Auth=($User.Value -split "\\")[1]
# alle AuthBenutzern auf untergeordneten Objekten entfernen
$allobjects=Get-ADObject -Filter * -SearchBase "OU=Administration,OU=Das Dorf,DC=gallier,DC=ads"
foreach ($object in $allobjects) {
dsacls $object -r $Auth
}
# Alle User + Computer (!) in die AD-DasDorf-Administration-R Gruppe aufnehmen
$allusers=get-aduser -Filter * -SearchBase "OU=Administration,OU=Das Dorf,DC=gallier,DC=ads"
$allcomputers=get-adcomputer -Filter * -SearchBase "OU=Administration,OU=Das Dorf,DC=gallier,DC=ads"
Add-ADGroupMember -Identity AD-DasDorf-Administration-R -Members $allusers
Add-ADGroupMember -Identity AD-DasDorf-Administration-R -Members $allcomputers
Das Ergebnis
Jetzt kommt die Stelle, wo der Artikel endlich was mit Gruppenrichtlinien zu tun hat. Spielen wir verschiedenen Scenararien durch, um einen logischen Fehler zu provozieren, der im ersten Moment irritiert.
Ein Admin meldet sich an einer Administrativen Workstion unterhalb der Administration an: Sowohl der Computer, als auch der Benutzer haben Leserechte bis zu ihrem eigenen Objekt. Alles funktioniert.
Ein Administrativer Account meldet sich ausserhalb der Struktur an einem normalen Computer/Server an: In dem Moment werden keine Gruppenrichtlinien für das Benutzer Objekt verarbeitet und es kommt zum Fehler bei gpupdate, oder auch gpupdate /force. Dieser Fehler ist komplett richtig und muss auch so sein. Das ist die Folge von MS16-072. Der Computer, an dem ich mich anmelde muss das Leserecht am Distinghuished Name des Benutzers haben, um die verlinkten Gruppenrichtlinien Objekte lesen zu können. Dieses haben wir erfolgreich unterbunden. Ein Computer (Authentifizierter Benutzer) darf die OU Strktur der Administration nicht mehr lesen. Aus Sicherheitssicht sind Benutzerspezifische Richtlinien selten relevant und da wir das System administrieren möchten, sollte es sich damit Leben lassen, das man kein Laufwerksmapping hat. Der Computer selbst übernimmt für sein eigenes Objekt alle Richtlinien.
P.S.: Aprospos Laufwerksmapping, es gibt UNC Pfade ;-)
Reden wir Kurz über das Problem AdminSDHolder.
Five common questions about AdminSdHolder and SDProp - Microsoft Community Hub
Da haben eine Menge Leute schon lange Artikel hinterlassen, die mehr AD orientiert sind auf ihrer Hompage, deswegen nur ein kleiner Abriss. Der AdminSDHolder mit seinem sdprop Prozess läuft, wenn er nicht manipuliert wurde, einmal pro Stunde. Er korrigiert die Berechtigungen auf die aus AD Sicht schützenswerten Konten und er unterbricht zusätzlich die Vererbung der Rechte auf diese Objekte.
Oft sind vorhandene Benutzerkonten historisch mal in einer schützenswerten Gruppe gewesen (Domänen-Admins, Server-Operatoren, Druck Operatoren, Konto Operatoren ...) und sie wurden jetzt endlich aus diesen Gruppen entfernt. Der AdminSDHolder weiss leider nicht, das die User nicht mehr in der Gruppe sind. Er reagiert nur auf das Attribut "admincount = 1". Dieses wird auf "1" gesetzt, sobald der Benutzer in einer der Gruppen ist, aber es wird nicht gelöscht oder auf "0" gesetzt, wenn man die Gruppe verlässt. Die Konten unterliegen weiterhin dem AdminSDHolder Schutz Prozess.
get-aduser -Filter * -SearchBase "DC=gallier,DC=ads" -Properties AdminCount |where {$_.Admincount -eq "1"} | ft Name
Diese Benuzter sollte man sich alle mal anschauen und den Wert korrigieren, wenn das Objekt nicht mehr in einer dieser Gruppen ist und die Vererbung der Rechte auf diesem Objekt wieder aktivieren.
Der AdminSDHolder und sein sdpro Prozess propagieren die Rechte, die für ihn selbst in den Sicherheitseigenschaften definiert sind. Hier können wir ebenfalls eingreifen und unsere eigene Gruppen "AD-DasDorf-Administration-R" hinzufügen.