Intensivkurs ASAI - Level 5
ASAI
Advanced Security AD InfrastructureESAE Modell - PAW (Privileged Access Workstation) - SCAMA (Authentication Mechanism Assurance) - Bastion Forest - PIM Trust - msDS-ShadowPrincipal
Sollte dieser Kurs aufgrund von (zukünftigen) behördlichen Einschränkungen bezüglich COVID-19 nicht mehr vor Ort stattfinden dürfen, behalten wir uns vor diesen automatisch auf LIVE CLASS umzustellen.
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
|
|
★ Teilnehmerzahl wegen Corona Kontaktbeschränkung reduziert!
PREIS
4.450,- € zzgl. Mwst.
Kursbesuch nur gegen Vorkasse möglich!
MINDEST-TEILNEHMERZAHL
Das Seminar findet ab einer Mindestzahl von drei Teilnehmern garantiert statt.
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 MKrbtgt = 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 Mc, Benutzer Mu
- Long-Term Master Key MKrbtgt 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 MKrbtgt (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 Ms (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 -