none
Sicherheit: Root/Subdomain vs. Singledomain RRS feed

  • Frage

  • Hallo,

    folgendes Szenario:
    Es soll eine Neugestaltung einer Multidomänen Umgebung einer Hochschule erfolgen. Es soll zukünftig 2 Sicherheitsbereiche geben -> Verwaltung und Lehre.

    Das neue Domänenmodell soll möglichst einfach sein und möglichst nur eine Exchangeumgebung enthalten, sowie externe Dienste sollen nach Möglichkeit nur an einer Stelle angebunden werden. Dennoch soll eine Sicherheitsgrenze zwischen den Mitarbeitern der Verwaltung und den Studierenden in der Lehre vorhanden sein.

    Ein Gesamtstrukturmodell mit 2 eigenständige Domänen fällt dadurch eigentlich raus.

    Bietet uns ein Root / Subdomain Modell mit Verwaltungs-Accounts in der Root-Domain und Studierenden-Accounts in der Subdomain einen wirklichen Sicherheitsvorteil gegenüber einem Einzeldomänen Modell (mit einer entsprechenden OU-Struktur)?

    Danke für eure Hilfe und beste Grüße,

    Gunter

    Freitag, 7. Juli 2017 09:11

Antworten

  • Hi,
     
    Am 07.07.2017 um 11:11 schrieb Gunter Holzer:
    > Bietet uns ein Root / Subdomain Modell mit Verwaltungs-Accounts in der
    > Root-Domain und Studierenden-Accounts in der Subdomain einen wirklichen
    > Sicherheitsvorteil gegenüber einem Einzeldomänen Modell (mit einer
    > entsprechenden OU-Struktur)?
     
    Die Frage ist, was ist dein Sicherheitswunsch? Angriff von intern oder
    von extern?
     
    Du kannst auch eine Multi-Tenant AD pflegen, wo sich nur die "sehen",
    die sich sehen dürfen.
     
    Wenn es generell um PtH Attacken und ähnliches geht:
     
    Solange die Root und Sub im selben Forest sind, gewinnst du keine echte
    Sicherheit, da sie auf gemeinsamen Datenpartitionen basieren.
     
    Ich würde zu 2 Single Roots tendieren, eine für Adminkonten, eine für
    produktive Objekte und in dieser den list object mode nutzen, zzgl.
    einer definition wer sich über netzwerk oder lokal an welcher Maschine
    anmelden darf.
    Dann kommt noch die Aktivierung der Firewall auf den Clients dazu, damit
    kein Client mit einem anderen reden darf etc.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10 - gp-pack PaT
     
    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:18
    Freitag, 7. Juli 2017 09:48
  • > Wie wird das praktisch umgesetzt?

    Such mal ein wenig: Microsoft ESAE Bastion Forest :)

    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:18
    Montag, 10. Juli 2017 11:52
  • Hi,
     
    Am 09.07.2017 um 11:43 schrieb Gunter Holzer:
    > - Unidirektionale Vertrauensstellung von der Benutzer-Domain zu der
    > Admin-Domain?
     
    Ja. Deswegen getrennte Domänen, damit die Richtung eingeschränkt werden
    kann.
     
    > - In der Benutzerdomain die Standard Adminkonten deaktivieren bzw. mit
    > sicheren Kennwörtern versehen und diese Konten dann nicht nutzen?
     
    "einen" wird es mindestens geben, ganz ohne geht es nicht, aber du
    versuchst nur "Hüllen" als Gruppe/Rolle bereit zustellen, die mit Konten
    aus der "Admin-Domäne" bei Bedarf gefüllt werden. lt MS am liebsten auch
    zeigesteuert, für den Task.
     
    > - In welcher Domain liegen die Adminkonten die z.B. eine größere Anzahl
    > von PCs in die Domäne aufnehmen dürfen?
     
    In der User domain, aber das sind nur Benutzer, denen das Recht
    delegiert wird.
     
    > - Beispiel Schemaerweiterung für Exchange in der Benutzer Domain. ->
    > Admin aus der Admin-Domain in die Gruppe der Schemaadmins aufnehmen?
     
    Ja und dann wieder raus.
     
    > Besser gefällt mir da der Multi-Tenant Ansatz.
    > Läst sich so etwas auch nur rein lokal (ohne Azure) umsetzen?
     
    Ja, kein Problem,
     
    > Benötige
    > ich zwingend MPS bzw. wie verwalte ich die ACEs sinnvoll ohne, dass sich
    > jemand Vollzeit nur damit befassen muss?
     
    ... da ist Martin derjenige, der es lebt, der weiss das :-)
     
    im artikel, werden die Gruppenschachtel auf das einzelne Recht
    runtergebrochen
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10 - gp-pack PaT
     
    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:18
    Montag, 10. Juli 2017 17:09
  • Hallo Gunter,

    der Martin, Norbert und Mark (*huhu an euch drei*) haben dir ja bereits viele brauchbare Antworten gegeben. Denoch möchte ich meinen Senf dazu geben und dir meine Einschätzungen zu deiner Frage mitteilen.

    > Bietet uns ein Root / Subdomain Modell mit Verwaltungs-
    > Accounts in der Root-Domain und Studierenden-Accounts
    > in der Subdomain einen wirklichen Sicherheitsvorteil
    > gegenüber einem Einzeldomänen Modell (mit einer
    > entsprechenden OU-Struktur)?

    Ein "Root / Subdomain Modell" hat gegenüber einen "Single-Domain-Forest" keinen Sicherheitsvorteil, da es innerhalb eines AD-Forest viele Wege gibt wie man sich mit wenigen Mausklicks als Domain-Administrator der einen Domäne zum Domain-Administrator der anderen Domäne befördern kann (e.g. Angriffe über die SidHistory, Angriffe über das AD-Schema, Angriffe über Site-GPOs, etc). Von dem her ist der Forest als solches als die ultimative Security-Boundary anzusehen und mehre Domänen innerhalb des gleichen Forest lediglich als eine organisatorische Verwaltungseinheit ohne technischen Sicherheitsmehrwert.

    > Such mal ein wenig: Microsoft ESAE Bastion Forest

    Microsoft ESAE ist ein sehr umfangreiches Designkonzept von Microsoft (das richtig viel $$$ kostet) und dir eine Managementumgebung in Form eines zusätzlichen Single-Domain-Forest (aka. dem Red-Forest) für die gesicherte Verwaltung deiner produktiven Domain Controller und deren Verwaltungssysteme schafft.

    In meinen Augen ist eine ESAE Umgebung jedoch nicht für alle Kundenumgebungen zu empfehlen, da der Aufbau der ESAE in 99 von 100 Fällen eher mit einem "Mit Kanonen auf Spatzen geschoßen..." zu vergleichen ist. Des Weiteren definiert das ESAE-Konzept auch lediglich die Absicherung der Domain Controller Services, ohne hierbei jedoch dabei das Große und Ganze zu betrachten. Wie Member Server / Clients unterschiedlichster Sicherheitsklassifizierungen und/oder Abteilungen/Lehrstühle granular und getrennt verwaltet werden können, ohne hierbei wiederum Pass-the-Hash oder vergleichbare Identitytheft / Privilegeskalation Angriffe zu ermöglichen, ist leider nur sehr oberflächlich in den ESAE-Konzepten beschrieben.

    Bei Single-Domain-Forest strukturen wie du sie benötigst/planst, ist es wesentlich günstiger, wenn man nur die wichtigsten der in ESAE enthaltenen Konzeptansätze aufgreift (diese stehen auch in kostenfreien Whitepapers/Blog posts) und hierbei eine Art von „ESAE-Light“ innerhalb des produktiven Single-Domain-Forest aufbaut.

    Salopp gesagt besteht das oberste Ziel eines adäquaten Sicherheitskonzepts darin, dass alle zentralen Managementsysteme mit einer Forest-weiten Auswirkung (e.g. DCs, PKI, Management Server, Admin PC, Software Verteilung, Patchmanagement, etc.) autark zu den rechtlichen Membersystemen verwaltet werden und somit deren Angriffsfläche reduziert wird. Die übrigen Member-/Clientsysteme sollten anschließend in sinnvoll in gleichartige aber denoch überschaubare Verwaltungseinheiten zusammengefasst werden und diese Einheiten dann durch die Verwendung maßgeschneiderten Gruppenrichtlinien an wiederum getrennte Administrationsgruppen zunächst administrativ delegiert und zusätzlich durch die Verwendung von den unterschiedlichen "Deny Logon via XYZ"-Rechten voneinander administrativ isoliert werden.

    Du kannst dir zur weiterführenden Nachlese des Themas gerne einen Video-Mitschnitt eines Vortrags ansehen, denn ich zusammen mit einem Kollegen auf einer PowerShell Konferenz gehalten hatte. In diesem Vortrag werden die aktuellen Sicherheitsprobleme/-herausforderungen innerhalb einer Active Directory Umgebung dargestellt und anschließend eine PowerShell basierte Lösung dargestellt, mit der man ein "Single-Domain-Forest" in bis zu 16,7 Millionen unterschiedlichen "Brandabschnitten" oder „Sicherheitszonen“ unterteilen kann, zwischen denen gängige "Pass-the-Hash" oder anderweitige Identity-Theft/Privilegeskalation Angriffe "per-design" unterbunden werden.

    https://www.youtube.com/watch?v=51SIh4MrOqA
    https://www.youtube.com/watch?v=7T5sqmMHVKU

    Cheers, Kai
    --
    F5 DevCentral MVP sowie ehemaliger Microsoft Security MVP
    itacs GmbH - Berlin
    www.itacs.de


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de

    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:18
    Dienstag, 11. Juli 2017 13:20
  • Daher die Frage: Lässt sich eine Bastion Umgebung auch ohne MIM aufsetzen und sinnvoll nutzen?

    Klar. Aber die GUI mußt dann halt selber bauen, den Unterbau liefert Powershell.

    Mit PAM /Bastion Forest löse ich das "Admin-Sicherheitsproblem" und mit ACEs regle ich dann den Zugriff auf Benutzerinformationen in der Benutzer-Domain.

    Du weißt, was PAM genau bedeutet? Vermutlich noch nicht :-) Aber ja, das nimmt die Admin-Gruppen deiner Produktions-Domäne aus der Schusslinie, da die schlicht leer sind.

    Im PAM Forest existieren Shadow Principals, die die SID der eigentlichen Admin-Gruppen als Attribut haben. Per PAM bekommt ein User aus dem Bastion Forest ein TGT mit kurzer Laufzeit, in dem diese SID enthalten ist, und damit darf er im Prod-Umfeld alles, was diese SID darf. Und in den (z.B.) Domain Admins im Prod-Umfeld ist dieser User zu keiner Zeit enthalten, kann als Angriffsziel also auch nicht aufgespürt werden.

    Was Du mit den ACLs jetzt genau meinst, weiß ich nicht :)

    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:26
    Dienstag, 11. Juli 2017 15:33
  • Von dem her ist der Forest als solches als die ultimative Security-Boundary anzusehen

    Dem ist nichts hinzuzufügen :)

    Microsoft ESAE ist ein sehr umfangreiches Designkonzept von Microsoft (das richtig viel $$$ kostet)

    Nö - nur wenn Du Dir MS für die Umsetzung ins Haus holst. Geht aber auch ohne... Und das teuerste an ESAE ist in der Tat der isolierte BF mit den PAW - ersteres haben wir schon teilweise und werden wir ausbauen, zweiteres diskutieren wir noch.

    In meinen Augen ist eine ESAE Umgebung jedoch nicht für alle Kundenumgebungen zu empfehlen,

    Ein Prinzip von ESAE ist überall zu empfehlen: Strikte Trennung der Tier-Administration. Client Admins dürfen sich nur auf Clients anmelden. Admins der Serverrollen dürfen sich nur auf der Serverrolle anmelden. Domain Admins dürfen sich nur auf DCs anmelden. Das ist schnell umzusetzen und bietet schon mal die erste Schutzmauer...

    da der Aufbau der ESAE in 99 von 100 Fällen eher mit einem "Mit Kanonen auf Spatzen geschoßen..." zu vergleichen ist.

    Besser mit Kanonen als gar nicht. Unlängst wieder bei einem anderen Kunden eines unserer PFE: Infektion auf Client im Benutzerkontext, warten auf Clientadmin (provoziert über Anruf beim Helpdesk aufgrund "Störungen des PC"...), lateral movement auf weitere Clients, warten auf Domain Admin. Der kam dann irgendwann auch vorbei...

    ohne hierbei jedoch dabei das Große und Ganze zu betrachten.

    Dann hast Du andere Dokus gelesen wie ich. Die Tier-Administration ist relativ präsent in dem, was ich so kenne.

    Video-Mitschnitt eines Vortrags ansehen, denn ich zusammen mit einem Kollegen auf einer PowerShell Konferenz gehalten hatte.

    Da war ich leider in Track 4 :))

    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:19
    Dienstag, 11. Juli 2017 15:50

Alle Antworten

  • Hi,
     
    Am 07.07.2017 um 11:11 schrieb Gunter Holzer:
    > Bietet uns ein Root / Subdomain Modell mit Verwaltungs-Accounts in der
    > Root-Domain und Studierenden-Accounts in der Subdomain einen wirklichen
    > Sicherheitsvorteil gegenüber einem Einzeldomänen Modell (mit einer
    > entsprechenden OU-Struktur)?
     
    Die Frage ist, was ist dein Sicherheitswunsch? Angriff von intern oder
    von extern?
     
    Du kannst auch eine Multi-Tenant AD pflegen, wo sich nur die "sehen",
    die sich sehen dürfen.
     
    Wenn es generell um PtH Attacken und ähnliches geht:
     
    Solange die Root und Sub im selben Forest sind, gewinnst du keine echte
    Sicherheit, da sie auf gemeinsamen Datenpartitionen basieren.
     
    Ich würde zu 2 Single Roots tendieren, eine für Adminkonten, eine für
    produktive Objekte und in dieser den list object mode nutzen, zzgl.
    einer definition wer sich über netzwerk oder lokal an welcher Maschine
    anmelden darf.
    Dann kommt noch die Aktivierung der Firewall auf den Clients dazu, damit
    kein Client mit einem anderen reden darf etc.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10 - gp-pack PaT
     
    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:18
    Freitag, 7. Juli 2017 09:48
  • Am 07.07.17 um 11:48 schrieb Mark Heitbrink [MVP]:
    Hi Mark,

    Alles schöne Ansätze und Vorsätze. Meine Erfahrung in Projekten mit Unis sagt mir, dass das nicht wie von dir beschrieben werden wird. ;)

    Bye
    Norbert

    Freitag, 7. Juli 2017 20:26
  • Moin,
     
    Am 07.07.2017 um 22:26 schrieb Norbert Fehlauer [MVP]:
    > Alles schöne Ansätze und Vorsätze. Meine Erfahrung in Projekten mit Unis
    > sagt mir, dass das nicht wie von dir beschrieben werden wird. ;)
     
    ok, formulieren wir die Frage anders: Will man administieren und
    arbeiten können, oder Sicherheit?
    Sicherheit ist mit dem Wunsch "Das neue Domänenmodell soll möglichst
    einfach sein" nicht zu lösen, wobei eben wieder die Frage ist was ist
    sicher und wie sicher ist sicher ... ein Teufelskreis :-)
     
    Naja, und dann musst du das ja auch immer noch betreiben und wenn die
    Admins das dann nicht möchten, bauen sie Wege "drumrum". Was hilft dir
    eine Admin Domäne, wenn am Ende die Adminkonten doch wieder in der
    UserDomäne erstellt werden, weil der Trust und die Gruppenschachteln zu
    umständlich sind.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10 - gp-pack PaT
     
    Samstag, 8. Juli 2017 08:37
  • Klingt realistischer ;)
    Samstag, 8. Juli 2017 17:45
  • Hallo Mark,

    vielen Dank für deine Antwort!

    Uns geht es primär um die interne Sicherheit, für externe Angriffe gibt es lohnenderere Ziele.

    Dass uns eine Root/Subdomain Lösung im selben Forest keinen echten Sicherheitsgewinn bringt und nur auf dem Papier hübsch getrennt aussieht hatte ich schon befürchtet.

    Deinen Vorschlag nur die Adminkonten in eine Single Root Domain zu packen und die Benutzer in eine andere Single Root finde ich sehr interessant. Somit würden weitere externe Dienste wie Eduroam, Shibboleth, Moodle,..., nur an einer Stelle ansetzen.
    Wie wird das praktisch umgesetzt?
    - Unidirektionale Vertrauensstellung von der Benutzer-Domain zu der Admin-Domain?
    - In der Benutzerdomain die Standard Adminkonten deaktivieren bzw. mit sicheren Kennwörtern versehen und diese Konten dann nicht nutzen?
    - In welcher Domain liegen die Adminkonten die z.B. eine größere Anzahl von PCs in die Domäne aufnehmen dürfen?
    - Beispiel Schemaerweiterung für Exchange in der Benutzer Domain. -> Admin aus der Admin-Domain in die Gruppe der Schemaadmins aufnehmen?
    Kannst du das Vorgehen bitte etwas näher ausführen?

    MIM hört sich auch interessant an, aber ich fürchte für eine solche Lösung fehlt das Geld und mit Sicherheit die entsprechende Personaldecke.

    Besser gefällt mir da der Multi-Tenant Ansatz.
    Läst sich so etwas auch nur rein lokal (ohne Azure) umsetzen? Benötige ich zwingend MPS bzw. wie verwalte ich die ACEs sinnvoll ohne, dass sich jemand Vollzeit nur damit befassen muss?
    Hast du mir hier weiteren Lesestoff?

    Lesestoff zu Anmeldeeinschränkung an lokalen Clients die Einschränkung der Clientkommunikation ist ebenfalls sehr willkommen :-).

    Übrigens sind wir keine Uni sondern eine Hochschule ;-)
    Dass "Einfach" und "Sicherheit" sich beißen ist auch klar - es soll eben ein gesunder Mittelweg gefunden werden.

    Besten Dank!
    Grüße,

    Gunter

    Sonntag, 9. Juli 2017 09:43
  • > Wie wird das praktisch umgesetzt?

    Such mal ein wenig: Microsoft ESAE Bastion Forest :)

    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:18
    Montag, 10. Juli 2017 11:52
  • Hi,
     
    Am 09.07.2017 um 11:43 schrieb Gunter Holzer:
    > - Unidirektionale Vertrauensstellung von der Benutzer-Domain zu der
    > Admin-Domain?
     
    Ja. Deswegen getrennte Domänen, damit die Richtung eingeschränkt werden
    kann.
     
    > - In der Benutzerdomain die Standard Adminkonten deaktivieren bzw. mit
    > sicheren Kennwörtern versehen und diese Konten dann nicht nutzen?
     
    "einen" wird es mindestens geben, ganz ohne geht es nicht, aber du
    versuchst nur "Hüllen" als Gruppe/Rolle bereit zustellen, die mit Konten
    aus der "Admin-Domäne" bei Bedarf gefüllt werden. lt MS am liebsten auch
    zeigesteuert, für den Task.
     
    > - In welcher Domain liegen die Adminkonten die z.B. eine größere Anzahl
    > von PCs in die Domäne aufnehmen dürfen?
     
    In der User domain, aber das sind nur Benutzer, denen das Recht
    delegiert wird.
     
    > - Beispiel Schemaerweiterung für Exchange in der Benutzer Domain. ->
    > Admin aus der Admin-Domain in die Gruppe der Schemaadmins aufnehmen?
     
    Ja und dann wieder raus.
     
    > Besser gefällt mir da der Multi-Tenant Ansatz.
    > Läst sich so etwas auch nur rein lokal (ohne Azure) umsetzen?
     
    Ja, kein Problem,
     
    > Benötige
    > ich zwingend MPS bzw. wie verwalte ich die ACEs sinnvoll ohne, dass sich
    > jemand Vollzeit nur damit befassen muss?
     
    ... da ist Martin derjenige, der es lebt, der weiss das :-)
     
    im artikel, werden die Gruppenschachtel auf das einzelne Recht
    runtergebrochen
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10 - gp-pack PaT
     
    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:18
    Montag, 10. Juli 2017 17:09
  • Super, danke euch beiden!

    @Martin
    Beim lesen der Infos zu den Stichworten "Bastion Forest / Bastion Environment / PAM" taucht immer der MIM mit auf.
    Daher die Frage: Lässt sich eine Bastion Umgebung auch ohne MIM aufsetzen und sinnvoll nutzen?

    Und dann gleich noch eine Frage:
    Mit PAM /Bastion Forest löse ich das "Admin-Sicherheitsproblem" und mit ACEs regle ich dann den Zugriff auf Benutzerinformationen in der Benutzer-Domain. Sprich ich "trenne" die Verwaltungsbenutzer-Accounts von den Studierenden-Accounts.
    Stimmt das so?

    Sorry für die vielen Fragen - mein AD Wissen scheint ziemlich eingerostet zu sein. Mit Windows 2016 Server hat sich da scheinbar einiges getan :-)

    Grüße,

    Gunter

    Montag, 10. Juli 2017 18:05
  • Hallo Gunter,

    der Martin, Norbert und Mark (*huhu an euch drei*) haben dir ja bereits viele brauchbare Antworten gegeben. Denoch möchte ich meinen Senf dazu geben und dir meine Einschätzungen zu deiner Frage mitteilen.

    > Bietet uns ein Root / Subdomain Modell mit Verwaltungs-
    > Accounts in der Root-Domain und Studierenden-Accounts
    > in der Subdomain einen wirklichen Sicherheitsvorteil
    > gegenüber einem Einzeldomänen Modell (mit einer
    > entsprechenden OU-Struktur)?

    Ein "Root / Subdomain Modell" hat gegenüber einen "Single-Domain-Forest" keinen Sicherheitsvorteil, da es innerhalb eines AD-Forest viele Wege gibt wie man sich mit wenigen Mausklicks als Domain-Administrator der einen Domäne zum Domain-Administrator der anderen Domäne befördern kann (e.g. Angriffe über die SidHistory, Angriffe über das AD-Schema, Angriffe über Site-GPOs, etc). Von dem her ist der Forest als solches als die ultimative Security-Boundary anzusehen und mehre Domänen innerhalb des gleichen Forest lediglich als eine organisatorische Verwaltungseinheit ohne technischen Sicherheitsmehrwert.

    > Such mal ein wenig: Microsoft ESAE Bastion Forest

    Microsoft ESAE ist ein sehr umfangreiches Designkonzept von Microsoft (das richtig viel $$$ kostet) und dir eine Managementumgebung in Form eines zusätzlichen Single-Domain-Forest (aka. dem Red-Forest) für die gesicherte Verwaltung deiner produktiven Domain Controller und deren Verwaltungssysteme schafft.

    In meinen Augen ist eine ESAE Umgebung jedoch nicht für alle Kundenumgebungen zu empfehlen, da der Aufbau der ESAE in 99 von 100 Fällen eher mit einem "Mit Kanonen auf Spatzen geschoßen..." zu vergleichen ist. Des Weiteren definiert das ESAE-Konzept auch lediglich die Absicherung der Domain Controller Services, ohne hierbei jedoch dabei das Große und Ganze zu betrachten. Wie Member Server / Clients unterschiedlichster Sicherheitsklassifizierungen und/oder Abteilungen/Lehrstühle granular und getrennt verwaltet werden können, ohne hierbei wiederum Pass-the-Hash oder vergleichbare Identitytheft / Privilegeskalation Angriffe zu ermöglichen, ist leider nur sehr oberflächlich in den ESAE-Konzepten beschrieben.

    Bei Single-Domain-Forest strukturen wie du sie benötigst/planst, ist es wesentlich günstiger, wenn man nur die wichtigsten der in ESAE enthaltenen Konzeptansätze aufgreift (diese stehen auch in kostenfreien Whitepapers/Blog posts) und hierbei eine Art von „ESAE-Light“ innerhalb des produktiven Single-Domain-Forest aufbaut.

    Salopp gesagt besteht das oberste Ziel eines adäquaten Sicherheitskonzepts darin, dass alle zentralen Managementsysteme mit einer Forest-weiten Auswirkung (e.g. DCs, PKI, Management Server, Admin PC, Software Verteilung, Patchmanagement, etc.) autark zu den rechtlichen Membersystemen verwaltet werden und somit deren Angriffsfläche reduziert wird. Die übrigen Member-/Clientsysteme sollten anschließend in sinnvoll in gleichartige aber denoch überschaubare Verwaltungseinheiten zusammengefasst werden und diese Einheiten dann durch die Verwendung maßgeschneiderten Gruppenrichtlinien an wiederum getrennte Administrationsgruppen zunächst administrativ delegiert und zusätzlich durch die Verwendung von den unterschiedlichen "Deny Logon via XYZ"-Rechten voneinander administrativ isoliert werden.

    Du kannst dir zur weiterführenden Nachlese des Themas gerne einen Video-Mitschnitt eines Vortrags ansehen, denn ich zusammen mit einem Kollegen auf einer PowerShell Konferenz gehalten hatte. In diesem Vortrag werden die aktuellen Sicherheitsprobleme/-herausforderungen innerhalb einer Active Directory Umgebung dargestellt und anschließend eine PowerShell basierte Lösung dargestellt, mit der man ein "Single-Domain-Forest" in bis zu 16,7 Millionen unterschiedlichen "Brandabschnitten" oder „Sicherheitszonen“ unterteilen kann, zwischen denen gängige "Pass-the-Hash" oder anderweitige Identity-Theft/Privilegeskalation Angriffe "per-design" unterbunden werden.

    https://www.youtube.com/watch?v=51SIh4MrOqA
    https://www.youtube.com/watch?v=7T5sqmMHVKU

    Cheers, Kai
    --
    F5 DevCentral MVP sowie ehemaliger Microsoft Security MVP
    itacs GmbH - Berlin
    www.itacs.de


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de

    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:18
    Dienstag, 11. Juli 2017 13:20
  • Daher die Frage: Lässt sich eine Bastion Umgebung auch ohne MIM aufsetzen und sinnvoll nutzen?

    Klar. Aber die GUI mußt dann halt selber bauen, den Unterbau liefert Powershell.

    Mit PAM /Bastion Forest löse ich das "Admin-Sicherheitsproblem" und mit ACEs regle ich dann den Zugriff auf Benutzerinformationen in der Benutzer-Domain.

    Du weißt, was PAM genau bedeutet? Vermutlich noch nicht :-) Aber ja, das nimmt die Admin-Gruppen deiner Produktions-Domäne aus der Schusslinie, da die schlicht leer sind.

    Im PAM Forest existieren Shadow Principals, die die SID der eigentlichen Admin-Gruppen als Attribut haben. Per PAM bekommt ein User aus dem Bastion Forest ein TGT mit kurzer Laufzeit, in dem diese SID enthalten ist, und damit darf er im Prod-Umfeld alles, was diese SID darf. Und in den (z.B.) Domain Admins im Prod-Umfeld ist dieser User zu keiner Zeit enthalten, kann als Angriffsziel also auch nicht aufgespürt werden.

    Was Du mit den ACLs jetzt genau meinst, weiß ich nicht :)

    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:26
    Dienstag, 11. Juli 2017 15:33
  • Von dem her ist der Forest als solches als die ultimative Security-Boundary anzusehen

    Dem ist nichts hinzuzufügen :)

    Microsoft ESAE ist ein sehr umfangreiches Designkonzept von Microsoft (das richtig viel $$$ kostet)

    Nö - nur wenn Du Dir MS für die Umsetzung ins Haus holst. Geht aber auch ohne... Und das teuerste an ESAE ist in der Tat der isolierte BF mit den PAW - ersteres haben wir schon teilweise und werden wir ausbauen, zweiteres diskutieren wir noch.

    In meinen Augen ist eine ESAE Umgebung jedoch nicht für alle Kundenumgebungen zu empfehlen,

    Ein Prinzip von ESAE ist überall zu empfehlen: Strikte Trennung der Tier-Administration. Client Admins dürfen sich nur auf Clients anmelden. Admins der Serverrollen dürfen sich nur auf der Serverrolle anmelden. Domain Admins dürfen sich nur auf DCs anmelden. Das ist schnell umzusetzen und bietet schon mal die erste Schutzmauer...

    da der Aufbau der ESAE in 99 von 100 Fällen eher mit einem "Mit Kanonen auf Spatzen geschoßen..." zu vergleichen ist.

    Besser mit Kanonen als gar nicht. Unlängst wieder bei einem anderen Kunden eines unserer PFE: Infektion auf Client im Benutzerkontext, warten auf Clientadmin (provoziert über Anruf beim Helpdesk aufgrund "Störungen des PC"...), lateral movement auf weitere Clients, warten auf Domain Admin. Der kam dann irgendwann auch vorbei...

    ohne hierbei jedoch dabei das Große und Ganze zu betrachten.

    Dann hast Du andere Dokus gelesen wie ich. Die Tier-Administration ist relativ präsent in dem, was ich so kenne.

    Video-Mitschnitt eines Vortrags ansehen, denn ich zusammen mit einem Kollegen auf einer PowerShell Konferenz gehalten hatte.

    Da war ich leider in Track 4 :))

    • Als Antwort markiert Gunter Holzer Donnerstag, 13. Juli 2017 06:19
    Dienstag, 11. Juli 2017 15:50
  • Vielen Dank euch allen für die vielen Rückmeldungen!
    Auch Kai danke für die Video-Links, was ich bis her gesehen habe sehr interessant!

    Ob wir ESAE vollumfänglich umsetzen können ist fraglich (z.B. PAW). Die Lösung soll für uns auch praktikabel sein.
    Wir sind eine Hochschule mit 4000 Studierenden und 300 Mitarbeitern. Das Kern-Adminteam umfasst 3-4 Personen (inkl. Exchangeadmin), dann nochmal 7-8 weiteres IT-Personal. Hierfür einen MIM zu haben ist m.E. oversized.

    Und ja zu PAM muss ich noch viel lesen, GENAU weiß ich es nämlich nicht ;-)
    Ich habe da einen Blog gefunden in dem PAM ohne MIM umgesetzt wird. Shadow Principals werden über ein Powershell Skript befüllt.
    How Shadow Principals works in Active Directory 2016

    -> Ich denke das könnte für uns eine Lösung sein, oder?

    Über ACLs/ACEs möchten wir z.B. die Heimanschrift von Professoren für Studierende ausblenden bzw. ganze OUs auf "unsichtbar" stellen. Auch hier bin ich noch am lesen - aber das sollte doch gehen, oder?

    Grüße,
    Gunter


    Dienstag, 11. Juli 2017 20:08
  • > Über ACLs/ACEs möchten wir z.B. die Heimanschrift von Professoren für Studierende ausblenden bzw. ganze OUs auf "unsichtbar" stellen. Auch hier bin ich noch am lesen - aber das sollte doch gehen, oder?

    Ja, aber das wird kein "Kinderspiel". Da bist dann schnell bei ExtendedRights und bei Rechte-OIDs. OUs unsichtbar machen ist einfacher - dsHeuristiscs, List Object Mode aktivieren und Auth Users überall rauswerfen. Aber auch das hat noch genug Fallstricke.

    Mittwoch, 12. Juli 2017 16:30
  • Ok, ich denke die ursprüngliche Frage wurde umfangreich beantwortet.

    Ich starte nun mit einer Testumgebung und öffne ggf. eine neue Frage :-)

    Nochmals vielen Dank euch allen!

    Donnerstag, 13. Juli 2017 06:21
  • Hi Zusammen,

    > Gunter Holzer schrieb:
    >
    > Vielen Dank euch allen für die vielen Rückmeldungen!
    > Auch Kai danke für die Video-Links, was ich bis her gesehen habe sehr interessant!

    Kein Ding. Bei kleineren Rückfrage kannst du dich gerne bei mir via E-Mail melden.

    > Ob wir ESAE vollumfänglich umsetzen können ist fraglich (z.B. PAW).
    > Die Lösung soll für uns auch praktikabel sein. Wir sind eine Hochschule
    > mit 4000 Studierenden und 300 Mitarbeitern. Das Kern-Adminteam umfasst
    > 3-4 Personen (inkl. Exchangeadmin), dann nochmal 7-8 weiteres IT-Personal.
    > Hierfür einen MIM zu haben ist m.E. oversized.

    Ich kann dir die folgenden Empfehlungen aussprechen, die du minimal bedenken solltes.

    Unterteile dein AD in X unterschiedliche Sicherheitsbereiche, die jeweils mit Systemen gefüllt werden, die identische Sicherheitsanforderungen und Risiken besitzen (sortiert nach ihrer Wichtigkeit)

     1.) Trenne Domain Controller und Memberserver von deinen Terminal Servern und Client-PCs
     2.) Trenne Infrastruktur-/Applikationsservern auf denen externe Dienstleister administrativ unterwegs sind von den Infrastruktur-/Applikationsservern die exklusiv von dir und deinen Kollegen verwaltet werden
     3.) Trenne Terminal Servern und Client-PC von Admin-Terminals und Admin-PC
     4.) Trenne jeden einzelnen Client-PC, um eine HOST-zu-HOST infektionen zu vermeiden.
     5.) Trenne unternehmensweite Change-Management-Systeme/Domain Controler/PKI von den Infrastruktur-/Applikationsserver
     6.) Trenne die "Bauchschmerzen" Infrastruktur-/Applikationsservern (e.g. kein Supportvertrag mehr) von deinen gewöhnlichen Infrastruktur-/Applikationsserver
     7.) Trenne deine "Kronjuwelen" Infrastruktur-/Applikationsserver von den gewöhnlichen Infrastruktur-/Applikationsserver
     8.) Trenne die Infrastruktur-/Applikationsserver jedes einzelnen Admin-Teams
     9.) Trenne bedingungslos jede einzelne Server-Rolle / Applikations-Server-Gruppierung
     
    Verwende in Zukunft für jeden Sicherheitsbereich exklusive Administratoren Gruppen und Konten.
     - Ein administratives Benutzerkonto darf immer nur gleichzeitig einen Bereich administrativ verwalten und kann sich auch nur in den passenden Bereich interaktiv anmelden. Bei Netzwerkzugriffen auf anderen Bereichen ist er lediglich ein normaler Benutzer.
     - Muss ein Admin mehrere Systeme in unterschiedlichen Bereichen verwalten, dann verwendet dieser in Zukunft jeweils ein zu Bereich passendes administratives Benutzerkonto und getrenntes Kennwort.
     - Implementiere einen Mechanismus der verhindert, dass ein Konto gleichzeitig Administratoren Rechte/Berechtigung in mehreren Sicherheitsbereichen erhält (verhindert Kreativität der Kollegen)

    Für die Implementierung dieser minimalen Empfehlungen brauchst du weder einen PAM/Bastion-Forest noch einen MIM um Shadowgruppen zu verwalten. Du brauchst lediglich OU-Strukturen zum Abbilden der Bereiche und pro Bereich eine GPO die steuert welche Gruppen administrative Zugriffe auf den jeweiligen Systemen besitzen und welche Gruppen (die Gruppen der anderen Bereiche) für interaktive Anmeldungstypen geblockt werden. Das ganze Konstrukt hat dabei sogar einen downlevel Support zurück bis Windows 2000, falls du noch gewisse Altlasten auf Grund von "Artikel 5 GG: Freiheit in der Forschung" mit dir rumschlepst (siehe hierzu auch "Bauchschmerzsysteme")...

    > Martin Binder [MVP] schrieb:
    >
    > Nö - nur wenn Du Dir MS für die Umsetzung ins Haus holst.
    > Geht aber auch ohne...

    Ich bezweifel, dass "Max Mustermann" seines Zeichens "Senior AD-Architekt" in der Lage ist, eine mit den ESAE-Konzepten vergleichbare Lösung zur Absicherung eines Tier-0 auf die Beine zu stellen. Es waren einfach viele kluge Köpfe erforderlich, um das (kostenpflichtige) Konzept das den Anspruch hat quasi auf alle praktischen und auch theoretischen Angriffe gegenüber Domain Controller zu bekämpfen auf die Beine zu stellen und dieses anschließend von vielen vielen weiteren klugen Köpfen unter die Lupe nehmen zu lassen.

    Und das was Public zu diesem Thema verfügbar ist, ist leider nur sehr ungenau beschrieben und bietet sehr viel Freiraum um essensielle Dinge zu übersehen / falsch anzugehen. Das doofe bei dieser Thematik ist nur, dass bereits eine kleine Unachtsammkeit ausreicht, um einem Tier-1 System letztendlich doch eine Privileg-Eskalation in den Tier-0 zu ermöglichen (Stichworter: Unternehmens-PKI im Tier-1 betreiben?, Tier-1 "Exchange Trusted Subsystem" Gruppe kann DCs löschen/verschieben?, etc.).

    Ein ESAE-ähnliches Sicherheitskonzept mit Lücken besitzt in den meisten Fällen nur einen hohen Mehraufwand bei der täglichen Administration ohne jedoch einen adäquaten Sicherheitsmehrwert zu besitzen. Von dem her sollte eine Organisation mit höheren Sicherheitsanforderungen lieber doch einen Rat vom Hersteller oder seine Konzepte zumindest von einem externen Spezialisten reviewen lassen. Sicher ist sicher... ;-)

    > Martin Binder [MVP] schrieb:
    >
    > Und das teuerste an ESAE ist in
    > der Tat der isolierte BF mit den PAW - ersteres haben
    > wir schon teilweise und werden wir ausbauen, zweiteres
    > diskutieren wir noch.

    Der Betrieb eines Bastion-Forest ist in der Tat als kostenspielig anzusehen. Aber dafür macht eine Bastion-Forest Umgebung zumindest auf PowerPoint Folien ganz dolle etwas her, das jeder IT-Entscheider quasi "anfassen" und somit auch iwie "verstehen" kann. Eine ideale Voraussetzung, um die notwendige Freigabe fürs Projekt zu erhalten... < /ironie>

    Nüchtern betrachtet und im direkten Vergleich zu einer ESAE-ähnlichen / PAW Umgebung, die direkt innerhalb des Tier-0 des produktiven Single-Domain-Forest implementiert wurde, erzeugt der Bastion Forest "als solches gesehen" jedoch keinen einzigen Sicherheitsmehrwert. Ein zentraler Bastion Forest inkl. PAW bringt lediglich einen finanziellen / management Mehrwert, wenn du mehr als eine Gesammtstruktur mit dieser Umgebung zentral verwalten möchtest.

    Wenn man den direkten Vergleich gar esotherisch betrachten möchte, dann wird man leztendlich zu der Feststellung kommen, dass ein Szenario mit einem Bastion-Forest zur ausschließlichen Verwaltung eines Single-Domain-Forest sogar ein minimal höheres Restrisiko besitzt. Der Grund hierfür ist, das beide Lösungen in der Lage sind identische Sicherheitsmechanismen abzubilden, aber das Bastion-Forest-Szenario eben noch das Restrisiko des Bastion-Forest selbst beinhaltet, so dass die effektiven Restrisiken letztendlich die >=0,001% Restrisiken des Bastion-Forest beinhalten müssen. Klingt iwie komisch ist aber so... ;-)

    Anmerkung: Bei einem direkten Vergleich von vielen dezentralen ESAE-ähnlichen / PAW Umgebung, die jeweils direkt in ihren eigenen Single-Domain-Forest Strukturen aufgebaut wurden, und einem Bastion-Forest-Szenario, dass zu Verwaltung von vielen autarken AD-Strukturen (KundeA und KundeB) verwendet wird, besitzt sogar weiterführende Sicherheitsrisiken (e.g. ein kritischer LDAP 0-day würde KundeA ermöglichen auf KundeB zuzugreifen)

    Anmerkung 2: Den einzigen Mehrwert eines Bastion-Forest-Szenario, den mir Microsoft im Zusammenhang der Verwaltung eines einzelnen "Single-Domain-Forest" plausibel darstellen konnte, war im Falle einer Remidiation des produktiven Forest. Man hat im Idealfall eine "saubere" Bastion-Forest Umgebung mit der man die "verschmutzte" produktive Umgebung wieder reinigen kann. Aber hey, da kaufe ich mir doch lieber einen Stapel Laptops bei Mediamarkt installiere das "Golden Image" auf diesen Dingern und lagere diese dann im Tresor/Serverraum für den Fall der Fälle. Diese Vorgehenswiese ist wesentlich günstiger als der Aufbau Bastion-Forest Umgebung und bringt den gleichen nutzen im Zuge einer Remidiation, oder?

    > Martin Binder [MVP] schrieb:
    >
    > Ein Prinzip von ESAE ist überall zu empfehlen:
    > Strikte Trennung der Tier-Administration.
    > Client Admins dürfen sich nur auf Clients anmelden.
    > Admins der Serverrollen dürfen sich nur auf der
    > Serverrolle anmelden. Domain Admins dürfen sich
    > nur auf DCs anmelden. Das ist schnell umzusetzen
    > und bietet schon mal die erste Schutzmauer...

    Die Verwendung von unterschiedlichen Konten zur Verwaltung von unterschiedlich vertrauenswürdigen/sensiblen IT-Infrastrukturen ist definitiv für alle Umgebungen bei denen ein Fünkchen Sicherheit gefordert wird zu empfehlen. Ob dieses nach den eingekauften ESAE-Konzepten (zzgl. einer späteren Ausarbeitung des Tier-1/2/X) oder durch eine geeignete Abwandlung der zugrundeliegenden Ideologien geschieht ist hierbei zweitrangig - solange die Lösung "lupenrein" implementiert wurde.

    > Martin Binder [MVP] schrieb:
    >
    > Dann hast Du andere Dokus gelesen wie ich. Die Tier-Administration ist relativ präsent in dem, was ich so kenne.

    Ich habe in den letzten Jahren bei unterschiedlichen Kunden eine durch Microsoft Consukting Service implementierte ESAE-Einführung als externer Security-Architekt, Security-Analyst und als Penetrationstester entweder begleitet oder im nachhinein die aufgebauten Umgebungen auditiert. In den ESAE-Konzepten die ich einsehen durfte wurden die Tier-1 und Tier-2 sowie mechanismen lediglich "angesprochen", aber waren bei der Umsetzung dann stehts "Out-of-Scope". Von dem her stehe ich zu meinen Wort dass die ESAE-Konzepte nicht das große und ganze betrachten, sonden nur halt die Absicherung der Domain Controller Services.

    Für sich betrachtet halbieren die in ESAE "angesprochen" Tier-1/2 Anmerkungen lediglich die Risiken, die von der Administration dieser Systeme ausgeht, und verlagert diese anschließend in zwei unterschiedliche Tiers. Nicht mehr aber auch nicht weniger...

    > Martin Binder [MVP] schrieb:
    >
    > Besser mit Kanonen als gar nicht. Unlängst wieder
    > bei einem anderen Kunden eines unserer PFE: Infektion
    > auf Client im Benutzerkontext, warten auf Clientadmin
    > (provoziert über Anruf beim Helpdesk aufgrund "Störungen des PC"...),
    > lateral movement auf weitere Clients, warten auf Domain Admin.
    > Der kam dann irgendwann auch vorbei...

    Zwischen der "ESAE-Konzept Kannone" und "gar nichts machen", gibt es dann noch ESAE-ähnliche Konzepte die lediglich die brenzlichsten Risiken aufgreifen und somit nur ein Bruchteil des Aufwandes bedeuten.

    Der eingesparte Aufwand kann in diesem Fall prima genutzt werden eine weiterführende Gliederung der von Microsoft empfohlenen Tier-0/1/2 Topologie in eine granualere und unlimitierte Tier-N Topologie abzuwandeln, so dass sich in Help-Desk Mitarbeiter an einem einzelnen potentiell infizierten Client-PC anmelden kann, ohne hierbei in der Lage ist anderweitige Clients oder gar Serversysteme und Domain Controller zu infizieren. Oder auch das ein externer Dienstleister einen administrativen Zugriff auf eine einzelnen Applikationsserver erhält, ohne dass er dabei in die Lage versetzt wird dem "Server Administratoren" die am Ende jedes Monats alle Windows Systeme manuell patchen eine Falle zu stellen, um einen unbefugten Zugriff auf anderweitige Server Systeme bzw. Daten zu erlangen (e.g. ein CMD Script im Autostart Ordner ablegen reicht!).

    > Martin Binder [MVP] schrieb:
    >
    > Da war ich leider in Track 4 :))

    Zum Glück wurde der Vortrag ja auf Video aufgezeichnet^^ :-)

    > Mark Heitbrink [MVP] schrieb:
    >
    > Sicherheit ist mit dem Wunsch "Das neue Domänenmodell soll möglichst
    > einfach sein" nicht zu lösen, wobei eben wieder die Frage ist was ist
    > sicher und wie sicher ist sicher ... ein Teufelskreis :-)

    Vergiss nicht zu hinterfragen ab wann einfach für einen Admin nicht mehr einfach ist? Bei Benutzern ist die Frage sehr leicht zu beantworten (Spoiler: Wenn es nicht mehr intuitiv ist!), aber bei Admins erhälst du oftmals (in Anbetracht ihres überdurchschnittlichen Gehalts) sehr komische Antworten... ;-)

    > Mark Heitbrink [MVP] schrieb:
    >
    > Naja, und dann musst du das ja auch immer noch betreiben und wenn die
    > Admins das dann nicht möchten, bauen sie Wege "drumrum". Was hilft dir
    > eine Admin Domäne, wenn am Ende die Adminkonten doch wieder in der
    > UserDomäne erstellt werden, weil der Trust und die Gruppenschachteln zu
    > umständlich sind.

    Aus diesem Grund bevorzuge ich Sicherheitskonzepte, die nur noch auf einem definiertebn Weg eine Vergabe von administrativen Rechte/Berechtigungen ermöglichen und die ein automatisches "Lockout" herbeiführen, wenn ein Admin mal kreativ wurde und sich mit einem Benutzerkonto administrative Zugriffe in unterschiedlichen Bereichen gebastelt hat. Ohne diese Vorkehrungen existiert das beste Konzept bereits nach kürzester zeit nur noch auf dem Papier...

    Cheers, Kai
    --
    F5 DevCentral MVP sowie ehemaliger Microsoft Security MVP
    itacs GmbH - Berlin
    www.itacs.de


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de

    Donnerstag, 13. Juli 2017 17:12
  • Moinsen!
     
    Am 13.07.2017 um 19:12 schrieb Kai Wilke:
    > [ganz viel geiles, direkt per copy&paste gesichert :-)]
    Fett Alter! Warum mag ich nur deinen Ansatz mit den Restricted Groups
    und der AD Struktur nach Objekten? :-)
    Danke für die allgemeinen Tipps!
     
    Ich denke, die meisten Admins wollen schlicht ihre Arbeit machen und
    administrieren, Sicherheits als Bremse ist bis zu einem gewissen Mass
    akzeptiert, muss aber lebbar bleiben ohne total zu nerven.
    Ich bin da zu sehr auf der Adminseite ...
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10 - gp-pack PaT
     
    Donnerstag, 13. Juli 2017 20:10
  • Hi Mark,

    > Mark Heitbrink [MVP] schrieb:
    >
    > [ganz viel geiles, direkt per copy&paste gesichert :-)]

    You're welcome. Das nächste Bier geht definitiv auf dich... ;-)

    > Fett Alter! Warum mag ich nur deinen Ansatz mit den Restricted Groups
    > und der AD Struktur nach Objekten? :-)
    > Danke für die allgemeinen Tipps!

    Ich kann nicht sagen warum DU den Ansatz magst? Ich zumindest mag den Ansatz, da er ziemlich simpel aufzubauen / zu verwalten ist, sehr gut skalliert und hierbei das Kernproblem innerhalb der Windows Plattform anvisiert (aufbrechen des unkontrolliertes administratives Single-Sign-Ons) anstatt lediglich die Angriffsvektoren des Kernproblems zu härten (e.g. Credential Guard machts schwerer, PAM+Shadowgroups machts zeitlich begrenzt, etc.).

    Ganz nach dem Motto wenn du Konto X wirklich niemals nicht auf System Y einsetzt, dann kann Konto X wirklich niemals nicht auf System Y angegriffen werden. Also wozu dann also noch zusätzlich härten / etwas verkomplizieren, wenn du mit den maximalen Auswirkungen eines vermeidlichen Angriffes bereits sehr gut leben kannst?

    Cheers, Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de

    Dienstag, 18. Juli 2017 12:07