Intensivkurs ASAI - Level 5

ASAI A dvanced S ecurity A D I nfrastructure



ESAE Modell - PAW (Privileged Access Workstation) - SCAMA (Authentication Mechanism Assurance) - Bastion Forest - PIM Trust - msDS-ShadowPrincipal

Der Fokus dieses "Advanced" Intensivkurses ist der Aufbau einer sicheren AD Infrastruktur nach dem Microsoft ESAE Referenzmodell (Enhanced Security Administrative Environment) mit Tier 0, Tier 1 und Tier 2 für eine Enterprise AD Umgebung mit oder ohne einem zusätzlichen sicheren AD Bastion Forest (BF), auch "Red Forest" genannt. Zwei Besonderheiten von der ESAE-Realisierung nach NT SYSTEMS ist das Arbeiten mit SCAMA (Smart Card Authentication Mechanism Assurance) und die Kombination von SCAMA mit msDS-ShadowPrincipal in einem Bastion Forest. Administrative Konten vom Produktionsforest sind durch SCAMA "unsichtbar" für Angreifer! In einem ESAE Modell werden die 3 Tiers als OUs unter der Top Level OU ESAE für drei logische Sicherheitszonen aufgebaut: AD+PKI+ADFS (Tier 0), Exchange und andere Server (Tier 1) und Desktops (Tier 2), die die Administratoren, Gruppen und Server sowie PAW (Privileged Access Workstation) enthalten. Administratoren der 3 Tiers dürfen sich nur innerhalb ihrer Sicherheitszone mit ihren Tier-Konten bewegen. Die Verwaltung soll ausschließlich von einer sicheren PAW aus durchgeführt werden. Szenario 1 : "Einfache Unsichtbarkeit" des Administrators

Auch ohne den zusätzlichen Bastion Forest kann ein bestehender AD Forest kostengünstig und schnell durch ESAE nach unserer SCAMA Methode abgesichert werden. Als erste Maßnahme gegen evtl. laufende Angriffe wie Golden Tickets ist nach einer sorgfältigen Vorbereitung, am besten nach dem ASAI-Kursbesuch, die sofortige Entleerung der wichtigsten Sicheheitsgruppen (Domain Admins, Enterprise Admins,...) und die mehrmalige (> 2) Passwortänderung der wichtigsten Admin-Konten, sowie das besonders zu behandelnden Krbtgt Konto. Die Administratoren z. B. T0-DomTPham, T1-SQLSHegenberg, T2-HelpDskSWiesner melden sich dann mit SCAMA an einer sicheren PAW an, um ihre Domäne zu verwalten. » Weil die Gruppenzugehörigkeit erst nach der SCAMA-Anmeldung auf dem Kerberos Ticket geschieht, bleibt dieser Admin unsichtbar! Szenario 2 : Multi-AD Forest mit gemeinsamem Verwaltungsforest (Bastion Forest) > wird durch das Szenario 3 ersetzt! Admin-Gruppen z. B. Domain Admins, Enterprise Admins etc. werden durch MIM/PAM (Privileged Access Management) zu PAM Groups (msDS-ShadowPrincipal) im Bastion Forest gespiegelt (Mirror). Im Objekt msDS-ShadowPrincipal (PAM Group) wird die objectSID der Quellgruppe vom Produktionsforest in ihrem Attribut msDS-ShadowPrincipalSID gespeichert (gespiegelt). Neue PAM-User (Time-based Admins) als Referenzobjekte der Administratoren vom Produktionsforest werden durch MIM/PAM in BF angelegt. Diese PAM-User können am PAM-Portal oder via PAM-PowerShell bzw. REST API nach strengen PAM-Policies die "Time-Based" Mitgliedschaft einer oder mehrerer PAM-Gruppen beantragen und können dann an einem sicheren PAW den Produktionsforest für eine definierte Zeit (Default 1 Std.) verwalten. Dieses Szenario setzt das Produkt MIM/PAM und auch Sharepoint voraus und wird durch unsere weiter entwickelte SCAMA Methode im Szenarion 3 ersetzt! Szenario 3 : "Zweifache Unsichtbarkeit" des Administrators Es werden im Bastion Forest administrative Universal Gruppen für den jeweiligen Produktionsforest für SCAMA z. B. ADS-T0-DomAdmins, ADS-T0-EntAdmins per PowerShell angelegt. Administratoren melden sich am PAW mit SCAMA im Bastion Forest zentral an und können durch die "indirekte" Mitgliedschaft der angelegten msDS-ShadowPrincipal z. B. ADS-T0-DomAdmins ihren ADS-Produktionsforest verwalten. Durch die feste Zuordnung einer Admin-Gruppe durch SCAMA mit dem zugehörigen msDS-ShadowPrincipal ist ein MIM/PAM Workflow überflüssig. » Für eine Enterprise Umgebung mit mehreren AD Forests ist dieses Szenario von NT SYSTEMS das BESTE! Szenario 4+5 : Exchange beeinflusst wie keine andere Applikation den gesamten AD Forest und wird daher im Kurs näher betrachtet. Wir zeigen die Unterschiede einer Standardinstallation von Exchange mit "RBAC Shared Permissions" zu "RBAC Split Permissions" oder in einer sicheren ESAE Umgebung mit "AD Split Permissions". Für Exchange in einem Ressource Forest haben wir die Szenarien 4 und 5,wo SCAMA in Kombination mit Linked Role Groups eingestzt werden kann. SCCM & SCOM :

RBAC basierte SCOM und SCCM werden konfiguriert, sodass sie auch mit SCAMA arbeiten können. Demo : Microsoft Advanced Threat Analytics (ATA)

ZIELGRUPPE

Das Seminar richtet sich besonders an Enterprise und Domain Administratoren sowie IT-Sicherheitspersonal, die eine neue Sichere AD Infrastruktur, angelehnt an dem ESAE Tier-Modell aufbauen und einrichten möchten.

Erfahrung mit Active Directory und PKI oder Besuch des Intensivkurses PKI 2016/2019 wird vorausgesetzt!

NIVEAU

Level 5 — sehr anspruchsvoll!

DAUER

4 Tage

ORT

NT Systems Schulungszentrum Böblingen (Karte)

TERMINE

Präsent (vor Ort) 26.05. - 29.05.2020 ✓ "Corona!" 21.07. - 24.07.2020 ★ ✓ ausgebucht 29.09. - 02.10.2020 ★ ✓ ausgebucht 06.10. - 09.10.2020 ✓ noch Plätze frei 03.11. - 06.11.2020 ✓ noch Plätze frei 08.12. - 11.12.2020 ✓ noch Plätze frei

★ Teilnehmerzahl wegen Corona Kontaktbeschränkung reduziert!

Zur Anmeldung

PREIS

4.250,- € zzgl. Mwst.

Kursbesuch nur gegen Vorkasse möglich!

MINDEST-TEILNEHMERZAHL

Das Seminar findet ab einer Mindestzahl von drei Teilnehmern garantiert statt.

SCHULUNGSZEITEN

Am ersten Tag 09:00 - 17:00 Uhr

An Folgetagen 08:30 - 17:00 Uhr

Am letzten Tag 08:30 - 13:00 Uhr

ZERTIFIKAT

Nach erfolgreicher Teilnahme erhalten die Kursteilnehmer ein Zertifikat von NT Systems.

AUSFÜHRLICHE INFORMATIONEN



Im Folgenden finden besonders interessierte Leser ausführliche Informationen zu den im Kurs behandelten Themen.

Das Ziel von diesem komplexen Intensivkurs ist der Aufbau einer sicheren AD Infrastruktur, angelehnt an das Microsoft ESAE Modell (Enhanced Security Administrative Environment), welches durch diverse Kerberos Schwäche und AD Designfehler sowie Unachtsamkeit von Microsoft in den letzten Jahren notwendig geworden ist. Anders als diverse Implementierung des ESAE Modells durch Microsoft und andere Systemhäuser, praktizieren wir bei NT SYSTEMS unsere hoch sichere und elegante Methoden SCAMA in einem Forest oder in Kombination mit Spiegelobjekt msDS-ShadowPrincipal in einem Bastion Forest. SCAMA sorgt dafür, dass ein Benutzer als Administrator "unsichtbar" wird. Er ist nur dann Administrator auf dem Kerberos Ticket (PAC-Feld), wenn er sich mit SCAMA anmeldet.



Das Kerberos Protokoll arbeitet mit Symmetric Key, um Kerberos Tickets (TGT, TGS) zu signieren und zu verschlüsseln. Wenn der Domain Master Key M Krbtgt = MD4(UTF-16(Krbtgt-Passwort) vom Hacker entwendet wird, kann dieser ein sog. Kerberos Golden Ticket (TGT) mit beliebiger Gruppenzugehörigkeit (Enterprise, Domain Admin) durch Änderung des PAC Felds (Privileged Account Certificate) für sich erstellen. Er kann auch ein sog. Silver Ticket (TGS) anlegen, um sich unauffällig Zugang zu beliebigen Serverressourcen zu verschaffen. Selbst wenn die seit 2008 deaktivierte PAC Validierung wieder aktiviert ist, validiert ein Windows Server die PAC Signaturen (Vergleich Krbtgt-Signatur und Serversignatur) bei einem DC nicht, wenn der zugegriffene Service z. B. LanmanServer unter LocalSystem läuft. Dies ist eindeutig ein AD Designfehler, der seit AD 2000 existiert. In dem veröffentlichten Protokolldokument [MS-PAC] ist dieses Fehlverhalten "By Design" zu lesen.



ASAI (Advanced Security AD Infrastructure) mit Bastion "Red" Forest und Produktion Forests (Golden Forests)



ESAE (Enhanced Security Administrative Environment) mit Tier 0, Tier 1 und Tier 2



ESAE Realisierung: Szenario I und III (mit SCAMA ohne MIM/PAM) - Szenario II (mit MIM/PAM)



ESAE Realisierung: Szenario IV und V (mit SCAMA und Exchange Resource Forest)

Nach dem ESAE Referenzmodell soll die gesamte AD-Infrastruktur in 3 Tiers (logische Sicherheitszonen) aufgeteilt werden: Tier 0, Tier 1, Tier 2

ESAE setzt keinen zusätzlich geschützten Bastion Forest (BF) voraus!

Szenario 1 : Mit einigen Sicherheitsmaßnahmen wie z. B. Credential Guard, RDP Restricted Admin Mode, Authentication Silo, Protected Users und insbesondere Smart Card Authentication Mechanism Assurance (SCAMA) kann eine bestehende AD Infrastruktur mit 3 Tiers auch ohne BF weitgehend sicher gegen PtH (Pass The Hash) und PtT (Pass The Ticket) gestaltet werden. Diverse Sicherheitsmaßnahmen sorgen dafür, dass Administratoren ihre Credentials bzw. ihre NT-Hash vom Passwort niemals auf nicht geschützten Maschinen hinterlassen, oder noch besser, dass bei einer Anmeldung überhaupt gar kein NT-Hash (z. B. mstsc /restrictedadmin) erzeugt wird. SCAMA erlaubt eine dynamische Mitgliedschaft zu einer Benutzergruppe erst nach einer Anmeldung mit Smart Card, die mit einer Issuance Policy verknüpft ist. Administratoren sind durch SCAMA nicht nur "unsichtbar", auch der 16-Bytes NTLM-Hash von ihrem Benutzerkonto wird durch die Zwangs-Smart Card Anmeldung mit 128 zufälligen Zeichen überschrieben.

Dieses 1. Szenario (ohne BF) ist geeignet für eine Umgebung mit nur einem AD Produktions-Forest.

Im ASAI unterrichten wir SCAMA - eine elegante Methode, um auch ohne Bastion Forest und MIM/PAM sicher genug arbeiten zu können. Die wichtigsten Gruppen wie Enterprise Admins, Domain Admins werden nicht entmachtet, sondern nur entleert. Für den Notfall bleibt ein einziges (max. 2) Admin-Konto als sog. "Break-Glass" Admin mit Passwort-Anmeldung in jeder Admin-Gruppe, falls Smart Card nicht funktionieren sollte. Die anderen Admins werden aus diesen Gruppen entfernt und gehören dynamisch nur dann dazu, wenn sie sich mit Smart Card anmelden. Wir implementieren im Kurs das seit 2008 R2 verfügbare Feature "Smart Card Authentication Mechanism Assurance (SCAMA)". Alle Admins müssen sich nur noch mit Smart Card an sicheren PAW anmelden. Nach der Anmeldung gehören sie dynamisch zu der jeweiligen Admin-Gruppe(n) und können ihren Golden Forest wie gewohnt verwalten. SCAMA kann leider nicht für jede Applikation eingesetzt werden, die u.a. Role-Based Authentication einsetzt.

Szenario 2 : Dieses Szenario wurde, wegen der umständlichen Bedienung durch Szenario 3 vollkommen ersetzt und wird daher im Kurs nicht mehr behandelt!

Durch einen zusätzlichen geschützten Verwaltungsforest oder Bastion Forest (BF) , auch "Red Forest" genannt, und durch den Einsatz von MIM/PAM (Privileged Access Management) kann die Sicherheit des Produktionsforests erheblich gesteigert werden , weil nicht der "echte" Administrator des gefährdeten Produktionsforests (Golden Forests = GF), sondern sein "Referenzkonto" (PAM User) im Bastion Forest (BF) eine "zeitbegrenzte" Mitgliedschaft von "mirrored" Admin-Gruppen (PAM Group) bekommt, um den GF zu verwalten. Es wird also nicht mit dem "echten" Account (GF\Gruppen), sondern durch SID-Mirror quasi mit einem zeitbegrenzten "Stellvertreter" gearbeitet. Ein BF ist geeignet für eine größere AD Infrastruktur, wenn z. B. mehrere AD Forests und Resource Forest durch One-Way Trust von einem gemeinsamen BF aus verwaltet werden müssen.

Das Szenario 2 wird durch das von uns entwickelte Szenario 3 auch ohne MIM/PAM, jedoch mit SCAMA stark vereinfacht, da ein PAM-Workflow durch feste Zuordnung einer Rolle z. B. Domain Admins zu einer Universal Group für SCAMA nicht notwendig ist.

Szenario 3 : In einer Multi-Forest Umgebung wird der zentrale Bastion Forest benötigt. Der Unterschied zu Szenario 2 ist, dass kein MIM/PAM in diesem Forest eingesetzt werden muss. Wie in Szenario 1 werden für jeden zu verwaltenden Produktionsforest Universal Group für SCAMA angelegt. Administratoren melden sich per SCAMA an ihrem PAW an und können durch den One-Way Trust und durch die "Indirekte" Mitgliedschaft des msDS-ShadowPrincipal ihren Produktionsforest verwalten.

Dieses Szenario 3 ist das BESTE Szenario für alle Umgebungen, besonders für eine Multi-Forest Umgebung!

PAW (Privileged Access Workstation)

Alle Administratoren MÜSSEN ihre zuständigen Tiers immer von einem geschützten PAW aus verwalten. Ein PAW ist zwar "tierunabhängig", aber in der Regel werden sie für die verschiedenen Tiers separiert.

Im ASAI-Kurs praktiziert jeder Teilnehmer selbst, wie sein Windows 10 Enterprise Rechner (mit TPM 2.0) durch diverse Tools und Sicherheits-/Firewallrichtlinien sowie Credential Guard zum PAW für die Tier 0 und Tier 1 Administratoren sicher gemacht werden kann. Administratoren müssen sich an ihrem dafür vorgesehenen PAW anmelden, am besten via MFA (Multi-Factor Authentication) z. B. mit Smart Card.

Die Administratoren sowie ihre Gruppen und Computer werden nach ESAE in drei Tiers 0, 1 und 2 im BF aufgeteilt, die voneinander isolierte Sicherheitszonen darstellen:

Tier 0 Enterprise, Domain, Schema, Built-In Administrator etc. → T0-Admins, T0-PKIAdmins, T0-SCOMAdmins

Tier 1 Serveradministrator etc. → T1-Admins, T1-ExAdmins, T1-SCOMAdmins, SQLAdmins etc.

Tier 2 Desktop Administrator → T2-Admins (HelpDesks)

Die Isolation kann softwaretechnisch (IPSec, Firewall, Group Policy etc.), organisatorisch (Rollentrennung) oder/und physisch (Subnetze) erreicht werden.

Der ASAI-Kurs besteht aus 6 Blöcken (Schwerpunkte):

Block 1 Grundlage: Passwort NTLM-Hash, Cracken von LSA Cache, Schützen von LSA Cache durch Credential Guard.

Grundlage Kerberos, Master Keys, Session Keys, TGT (Ticket Granting Ticket), TGS (Ticket Service Ticket), SPN (Service Principal Name), Token Size.

PAC-Validation der Signaturen (Krtbgt, Server).

Angriffsvektoren wie Golden Ticket & Silver Ticket, Offline Cracken von Ntds.dit, Skeleton Key etc. und die Gegenmaßnahmen.

Block 2 PAW (Privileged Access Workstation) - Installation und Konfiguration

Clean Source durch Hash-Vergleich

SCM Baseline Security, Firewall-Konfiguration.

Credential Guard, Restricted Admin, BitLocker, Smart Card.

LAPS (Local Administrator Password Solution).

Verschlüsselte Kommunikation via IPsec von PAW aus.

Block 3 Szenario 1 - Arbeiten mit SCAMA (ohne Bastion Forest)

Aufbau der ESAE OU-Struktur für die 3x Tiers und PAW.

Identifizieren der privilegierten Gruppen, Delegation

Entleeren der Built-In Admin-Gruppen z. B. "Domain Admins" und durch stellvertretende Gruppen z. B. T0-DomAdmins ersetzen.

Einrichten von SCAMA mit Issuance Policy für die privilegierte Tier-Gruppe

Zuordnung Issuance Policy und Admin-Gruppe

SCAMA Zertifikat anfordern. Dynamische Gruppenmitgliedschaft (Windows Access Token).

Administration verschiedener Szenarien von PAW aus, z. B. Schemaerweiterung, Replikation DCs, Zugriff auf DCs etc.

Arbeiten mit Exchange "Shared Permissions", "RBAC Split Permissions" und "AD Split Permissions" Models.

Block 4 Szenario 3 - Bastion Forest (mit SCAMA, jedoch ohne MIM/PAM)

Anlegen der Universal Gruppen für Admninistratoren des jeweiligen Produktionsforests im Bastion Forest

Einrichten SCAMA für diese Gruppen

Zuordnen dieser Gruppen mit den msDS-ShadowPrincipal

Verwaltung des Produktionsforests nach Anmeldung via SCAMA an einem PAW

Block 5 Konfigurieren RBAC-basierte SCOM und SCCM für den SCAMA Einsatz



Block 6 Audit durch ATA (Advanced Threat Analytics) nur Demo, Monitoring z. B. PSExec-Nutzung durch SCOM, XPATH-Filter



Wir arbeiten im Kurs mit 3x AD-Forest mit registrierten Domänen:

ASAI-CENTER.DE Bastion Forest (BF) = Zentralverwaltung mit MIM 2016 SP1 und SQL 2014/2016 AlwaysOn ADS-CENTER.DE Golden Forest (GF) = Produktions- bzw. Account Forest mit 2016 XCHANGE-CENTER.DE Resource Forest mit u.a. Exchange 2016 Organisation

» Wir empfehlen als Ergänzung den Kurs PKI 2016/2019 zu besuchen.

Modul: Kerberos PAC Validation Long-Term Master Keys von Computer M c , Benutzer M u Long-Term Master Key M Krbtgt von Domain Controllern einer Domäne Aufbau und Einsatz von Kerberos Tickets TGT (Ticket Granting Ticket) und TGS (Ticket Service Ticket) Das PAC (Privileged Account Certificate) Feld Krbtgt-Signatur und ServerSignatur PAC Validation via Server Secure Channel - Nützt die PAC Validation gegen Golden & Silver Tickets ? Kerberos PAC Validation - PtT (Pass-the Ticket) - TGT Golden Ticket - TGS Silver Ticket KRB_TGS_REQ (supported Encryption Types) von Windows 7 / 2008 R2 Konfigurieren von "supported encryptiontypes" Signature für die PAC-Validation



Modul: Die Angriffsvektoren - Pass-The-Hash (PtH) und Pass-The-Ticket (PtT) - Golden Ticket und Silver Ticket Ein Ausschnit der möglichen Angriffsvektoren wird im Kurs besprochen und demonstriert. Auslesen des ungeschützten LSA Caches, um den NTLM-hash eines Domain Administrators zu erbeuten Erbeuten des Master Key von KDC M Krbtgt (NTLM-Hash des Konto Krbtgt) für den Bau eines TGT Golden Ticket Erzeugen Golden Ticket TGT mit falscher Admin-Mitgliedschaft durch Änderung des PAC-Felds - Einsatz von Golden Ticket durch PtT (Pass-the-Ticket) Erbeuten des Servermasterkey M s (NTLM-Hash vom Serverpasswort) für TGS Silver Ticket Erzeugen Silver Ticket TGS mit falscher Admin-Mitgliedschaft - Einsatz von Silver Ticket durch PtT (Pass-the-Ticket) Skeleton Key an einem Domain Controller als Backdoor vom Angreifer Erbeuten der kompletten Konten und NTLM-Hash durch DC-Backup Warum PAC Validation nicht funktioniert! Domain Administrator NT-Hash aus dem LSA Cache ermitteln Auslesen NT-Hash vom Krbtgt-Konto Kerberos Golden Ticket (TGT) mit gefälschter Gruppenmitgliedschaft Auslesen NT-Hash vom Serverkonto Kerberos Silver Ticket (TGS) mit gefälschter Gruppenmitgliedschaft mimikatz.exe + DSInternals



Modul: LSA Credential Guard (ab Windows 10 Enterprise) Schutz des LSA Caches durch Virtualized Based Security Aktivieren LSAIso Testen durch Auslesen des LSA Credentials Virtualization-Based Security (Quelle: Microsoft) Aktivieren Credential Guard



Modul: Aufbau der ESAE Infrastruktur OU-Struktur nach Microsoft (Skript) OU-Struktur nach NT SYSTEMS - Anlegen der ESAE OU-Struktur Anlegen der Funktionsgruppen für T0, T1 und T2 Entleeren der Built-In Gruppen "Domain Admins", "Schema Admins" etc. mit Ausnahme von "Break-Glass" Administrator Verschaltelung der angelegten Funktionsgruppen - Zuweisung Berechtigung und Extended Rights für Gruppen Vorbereitung der OUs mit Group Policy Objects (GPO) Vorbereitung der OU für PAWs OU-Struktur für ESAE (Nach NT Systems)



Modul: PAW (Privileged Access Workstation) lnstallieren Windows 10 Enterprise aus "Clean" Source mit Signatur-Überprüfung Komplexes Passwort für PAW Administrator - LAPS (Local Administrator Password Solution) RSAT aus "Clean" Source mit Signatur-Überprüfung Netzwerkkonfiguration und Domainbeitritt in Bastion Forest WSUS Update Restricted Admin Mode Windows 10 Security Baseline GPOs für Tier 0 PAW Devices: Delete all member groups, Restrict Local Group Membership, Firewall Block Inbound Traffic, WSUS etc. GPOs für Tier 0 PAW Users: Block Internet Browsing, Restrict Admins logging on lower Tiers Sicherer Zugriff auf eine Virtuelle PAW PAW (Privileged Access Workstation)



Modul: SCAMA (Smart Card Authentication Mechanism Assurance) Einrichten PKI für SCAMA mit Issuance Policies Kerberos Authentication Zertifikat für SCAMA SCAMA Zertifikatsvorlage mit Issuance Policy Zuordnung Issuance Policy mit den vorbereiteten Universal Group (Stellvertretende Gruppe) Smart Card Zertifikat für T0-DomAdmins, T0-SchAdmins, T0-EntAdmins, T0-RepAdmins durch Smart Card Enrollment Agent ausstellen Smart Card Authentifizierung (SCAMA) am PAW im Bastion Forest Bastion Forest DC Zertifikat für Smart Card Authentifizierung an PAW Certificate Template für Smart Card Logon SCAMA Zuordnung OID - Universal Gruppe Issuance Policies für SCAMA



Modul: Einhaltung der ESAE Regeln - IPsec Anlegen der Allow und Denied Gruppen für T0, T1 und T2 Group Policy für T0, T1 Server Denied Logon für T0 und T1 Server sowie T2 Desktops Geschützte Kommunikation zwischen PAW und T0 Domain Controller durc IPsec Geschützte Kommunikation zwischen PAW und T1 Server durch IPsec



Modul: Bastion Forest (BF) für Szenario 3 (ohne MIM/PAM) Der Aufbau des Bastion "Red" Forest mit isolierten DC, DNS, PKI, WSUS One-Way Trust mit dem Produktionsforest (Golden-/Account-/Privat Forest) Einrichten einer Top-Level OU-Struktur für ESAE und PAW: Tier 0, Tier 1 und Tier 2 PAM Kerberos Ticket Flow One-Way Trust Bastion Forest (BF) & Golden Forest (GF) OU-Struktur für ESAE und PAW



Modul: SCAMA und ShadowPrincipal im Bastion Forest (Szenario 3) Anlegen Universal Group für SCAMA im Bastion Forest Einrichten SCAMA für Administratoren aus den Produktionsforests Zuordnung der SCAMA Gruppen mit dem jeweilige msDS-ShadowPrincipal Anmelden am PAW im Bastion Forest via SCAMA um Produktionsforest zu verwalten



Modul: Zugriff auf Resource Forest (RF) am Beispiel Exchange 2016 Da das ESAE Modell nachträglich neu (2015/2016) erdacht wurde, ist nicht alles mit dem BF möglich! Zusammenarbeit Bastion Forest (BF) und Resource Forest (RF) - Machbarkeit und Grenze Die 3x Permissions Modelle von Exchange: Shared Permissions (Default), RBAC Split Permissions, AD Split Permissions Zugriff auf Postfach im Ressource Forest: Linked Mailbox. Verwaltung von T1 Exchange Ressourcen ESAE - Exchange RBAC Permissions Models - Resource Forest - Linked Role Groups (2)



Modul: Auditing durch ATA, Monitoring mit SCOM 2016/2019 Auditing durch SCOM Abeiten mit XPATH-Filter um Audit-Events zu analysieren ATA Advanced Threat Analytics Der Versuch einer Remoteausführung mit PSEXEC wurde von ATA erkannt. Ein Pass-the-Hash Angriff wurde von ATA erkannt. Eine verdächtige Verwendung von Kerberos-Tickets weist auf einen Golden Ticket-Angriff hin! Auf dem Domain Controller wurde ein Skeleton Key platziert. Eine Böswillige Replikation von Verzeichnisdiensten wurde erkannt.



Modul: SCOM und SCCM mit SCAMA SCCM und SCOM arbeiten mit RBAC (Rollen basierte Administration) Wir zeigen, dass SCAMA mit SCOM und SCCM RBAC harmonisch zusammenarbeiten können. Die Administration von SCCM und SCOM wird an einem PAW ausgeführt.



- Vertrauen Sie unserer Kompetenz -