Intensivkurs ASAI-2

ZIELGRUPPE
Das Seminar richtet besonders an die Enterprise und Domain Administratoren sowie IT-Sicherheitspersonal, die eine hochsichere AD Infrastruktur, angelehnt an das ESAE Tier-Modell, aufbauen und einrichten möchten. Anders als ASAI-1 (Kerberos Based) wird im ASAI-2 eine "Extended" ESAE mit ADFS (Token Based) praktiziert.
Langjährige Erfahrung mit Active Directory und Besuch des Intensivkurses ASAI-1 werden für den 1. Kerberos Teil vorausgesetzt!.
Gute Kenntnisse in PKI oder Besuch des Kurses PKI sind notwendig, da fast alle Kursmodule zertifikatsbasierend sind.

NIVEAU
★★★★★ — sehr anspruchsvoll!

DAUER
  5 Tage

ORT
NT Systems Schulungszentrum Böblingen (Karte)

TERMINE

18.11. - 22.11.2019

✓ noch Plätze frei

Zur Anmeldung

PREIS
4.550,- € zzgl. Mwst. – inkl. Mittagessen 15,- € / Tag

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.

• Einführungsvortrag: Gesamtblick - "Extended" ESAE mit Hybrid-Authentication
  Zusammenspiel der verschiedenen Authentifizierungsprotokolle - Kerberos Based und Token Based.
  Neueste Sicherheitstechnologien von Windows 10 und Windows Server 2016 inkl. SCAMA, PAPA, MAMA und OBO.
  

  SCAMA		Smart Card Authentication Mechanism Assurance (ASAI-1)
  PAPA		Public Key Authenticated PAW (ASAI-2)
  MAMA		Machine AMA (ASAI-2)
  PKINIT		Public Key (User+Device) Pre-Authentication (ASAI-2)
  FAST		Kerberos Armoring + Compound Authentication (ASAI-2)
  Azure MFA		Multi-Faktor Authentication (ASAI-2)
  JUMP SERVER Nr. 1		Kerberos Double-Hop mit Resource Based Delegation (ASAI-2)
  JUMP SERVER Nr. 2		Kerberos Double-Hop mit Resource Based Delegation + S4U2Self + S4U2Proxy + OpenID Connect (ASAI-2)
  JUMP SERVER Nr. 3		OBO > OAuth2 On-Behalf Of (ASAI-2)

• Modul 01: Kerberos Authentication im Single-Forest.
  Deep-Dive in Kerberos (I)
  Die Kerberos Authentifizierung in einem Single Forest wird genau analysiert.
  Pre-Authentication nach [RFC 4120] ohne PKINIT und FAST
• Modul 02: Kerberos Authentication im Multi-Forest mit One-Way PIM-Trust (Privileged Identity Management).
  Deep-Dive in Kerberos (II) PIM-Trust und Cross-Forest Referal TGT
  Die Kerberos Authentifizierung in einem Multi-Forest mit Bastion Forest und Produktion Forest wird genau analysiert.
  Dabei ist der PIM Trust ein zentrales Thema. Ohne den PIM-Trust eines 2016 Forests ist es nicht möglich ein msDS-ShadowPrincipal vom Trusting in ein Trusted Bastion Forest zu spiegeln. Durch die Object-SID des Objekts vom Trusting Forest im Spiegelobjekt ist es möglich, die Identität von diesem für die Administration des Trusting Forests einzusetzen.
  Troubleshooting PIM-Trust
  
  Cross-Forest TGT Referal - Bastion Forest - Produktionsforest
  Broken PIM-Trust
  ESAE Realisierung: Szenario I und III (mit SCAMA ohne MIM/PAM), Szenario II (mit MIM/PAM)
• Modul 03: Verwaltung im Multi-Forest mit PAW und Jump Server Nr. 1
  Deep-Dive in Kerberos (III)
  Von einem PAW im Bastion Forest aus, werden die Windows Server in einem Produktionsforest durch die Firewall verwaltet.
  IPSec ist in einem Multi-Forest mit One-Way PIM-Trust nicht unbedingt die richtige Lösung.
  RDP Gateway ist langfristig auch keine richtige Lösung, weil nicht universell wie HTTPS.
  Jump Server  sollte HTTPS von überall erreichbar sein und unterschiedliche Authentication Protokolle (Kerberos und Token Based) unterstützen.
  Wir zeigen, wie ein JUMP SERVER in Kombination mit SCAMA (Smart Card Authentication Mechanism Assurance) genutzt werden kann, um mehrere Produktionsserver via HTTPS sicher zu verwalten. Es gibt jedoch im Moment noch Einschränkungen, die aber durch Workarounds gelöst werden können.
  Damit eine Kerberos SSO Authentifizierung bei diesem bekannten „Double-Hop“ Szenario möglich ist, wird die Kerberos Erweiterung S4U2Proxy angewandt.
  Die Resource Based Delegation erlaubt Double-Hop in einem Multi-Forest.
  
  Resource Based Kerberos Delegation
• Modul 04: Firewall im ESAE Multi-Forest
  Die verschiedene AD Forests in ESAE müssen durch Firewall getrennt und geschützt werden.
  Der Verwaltungszugriff von einer PAW im Bastion Forest aus auf die Server in andere Forests erfordert viele Firewall Regeln.
  Auch Domain Controller und PIM Trust nutzen u.a. Netlogon [N-RPC] und brauchen dynamische RPC Ports.
  In diesem Modul zeigen wir die verschiedene Kommunikationsarten in so einem Multi-Forest und wie die dynamische Ports für RPC eingeschränkt werden können.
  
  AD Web Services - msDS-ShadowPrincipal
  Active Directory Web Services
  Active Directory Web Services - Port 9389
  WinRM Datenverkehr mit Kerberos verschlüsselt - Port 5985
  RPC Kommunikation - Netlogon
  Zuweisung feste Ports für Netlogon
• Modul 05: Hardening Bastion Forest (I) > PAPA und MAMA
  Deep-Dive in Kerberos (IV)
  Alle Rechner in einem Bastion Forest müssen mit Zertikat arbeiten, um zu verhindern, dass Computerpasswort und Benutzerpasswort für die Verschlüsselung der Kerberos Tickets eingesetzt werden. Obwohl schon lang in PKINIT festgelegt, kann sich erst Windows 10 mit "Kerberos Client Auth" an 2016 KDC authentifizieren.
  Zertifizierte Windows 10 Enterprise PAWs müssen mindestens Credential Guard aktiviert haben.
  Das "Kerberos Client Auth" Zertifikat wird manuell beantragt, sodass der Private Key immer im geschützen LSA-Container von Credentail Guard gespeichert wird.
  MAMA (Machine AMA) sorgt dafür, dass nur PAWs mit Computerzertifikat in die gewünschte Computergruppe z.b. PAW-MAMA automatisch aufgenommen werden.
  Authentication Policy und Kerberos Compound Authentication sorgen dafür, dass Admins nur mit SCAMA an zertifizierten PAWs von PAW-MAMA arbeiten dürfen.
  
  Force Device Authentication - Kerberos Client Auth
  Always Compound Authentication
  Device Authentication - Bound Public Key
  Zertifizierte PAWs in Device Group PAW-MAMA
  Zuordnung Bastion Forest Admins zur zertifizierten PAW Gruppe PAW-MAMA
• Modul 06: Hardening Bastion Forest (II) > PKINIT und FAST + Compound Authentication
  Deep-Dive in Kerberos (V)
  Die neue Device Authentication für Windows 10 in Kombination mit SCAMA sorgen dafür, dass die Kerberos Pre-Authentication sehr sicher ist, weil anstelle des Master Keys Mu des Benutzers oder Computers Mc nun PKINIT mit Zertifikat und Diffie-Hellman für die Berechnung des AS-REPly Keys eingesetzt wird.
  Wenn FAST aktiviert ist, wird die Kerberos Pre-Authentication auch unabhängig von PKINIT durch den FAST Tunnel durch den Armor Key geschützt. FAST ist auch die Voraussetzung für die Compound Authentication, die wir mit Authentication Policy für PAW-MAMA durchführen.
  In diesem Modul analysieren wir die Kerberos Nachrichten beim Computerneustart (PAW) und Initial User Logon.
  PKINIT und FAST sind dabei aktiviert.
  
  Signed AuthPack - Signiert durch Private Key (Benutzer + Computer)
  Pre-Authentication ohne PKINIT - Client Master Key
  Pre-Authentication mit PKINT - ASReply Key
  PKINIT Diffie-Hellman AS Reply Key
  FAST Armor Key - abgeleitet aus dem TGT Session Key
  PaFxFastReply - Armored Data
  PAC mit User+Device Infos
• Modul 07: ADFS 4.0 und WAP
  Deep-Dive in ADFS
  Weil Kerberos nur innerhalb eines AD Forests und Trusted AD Forests funktioniert, wird im ASAI-2 die Authentifizierung durch ADFS 4.0 erweitert. Dadurch ist es möglich eine ESAE Umgebung bei Bedarf auch nach aussen für die Nicht-Kerberos Welt zu öffnen. Mit ADFS können sowohl die Authentifizierung als auch die Autorisierung mit Conditional Access geregelt werden.
• Modul 08: CBWA (Claims Based Web Application)
  Deep-Dive in CBWA
  Eine CBWA ist eine authentifizierungsneutrale Web Anwendung, die nicht selbst für die Authentifizierung zuständig ist. Sie wird so programmiert, dass die Authentifizierung an einen Security Token Server (STS) weitergeleitet wird, wenn der Zugriff auf die CBWA ohne Security Token erfolgt. Eine CBWA ist daher eine Relying Party. In der Windows Welt ist ein STS ein ADFS Server.
  Auch als Nicht-Entwickler lernen wir in diesem Modul, wie eine CBWA in Visual Studio in Begleitung unserer Entwickler programmiert wird. Das CBWA Portal soll so entwickelt werden, dass nicht jeder alle Bereiche sehen darf. Die Autorisierungsfilterung erfolgt über Role Claims.
  Wir wollen, dass nur Benutzer einer bestimmten Gruppe nach der Anmeldung Zugriff auf den ihr zugeordneten geschützten Bereich bekommen, auch wenn sie sich via SCAMA angemeldet haben. SCAMA sorgt ja dafür, dass nach einer Anmeldung die Benutzergruppe immer unsichtbar bleibt. Nur auf dem Kerberos Ticket bzw. auf dem Windows Access Token ist die Mitgliedschaft dynamisch sichtbar.
  Wir lernen im Kurs, diese SCAMA-Unsichtbarkeitsproblematik durch Claims Rules zu lösen, so dass die Gruppenmitgliedschaft trotzdem ermittelt werden kann.
  Das CBWA-Portal kann auch als Jump Server gedient werden, wenn von hier aus andere Server remote verwaltet werden sollen (Double Hop).
• Modul 09: Jump Server Nr. 2 > OpenID Connect und Kerberos Extension S4U2Self + S4U2Proxy > Doble Hop
  Deep-Dive OAuth2 (II)
  In diesem Szenario ist der Jump Server "OAuth2JumpPortal" ist ein Web Server im Produktionsforest.
  Benutzer (Administrator) authentifiziert sich vom Internet (auch möglich mit SCAMA) über das WAP und ADFS und landet auf dem Jump Server.
  Die Web App auf dem Jump Server sorgt mit S4U2Self dafür, dass im Namen des Benutzers ein TGS (1) für den lokalen Zugriff vom KDC besorgt wird.
  Für den weiteren Zugriff z.b. mit PowerShell Remoting vom Jump Server aus wird die Resourced-Based Kerberos Constrained Delegation eingerichtet.
  Die Web App auf dem Jump Server sorgt diesmal mit S4U2Proxy dafür, dass ein weiteres TGS (2) im Namen des Benutzers vom KDC geholt wird.
  Mit TGS (2) kann Benutzer via PowerShell auf die Ressourcen auf den Remote Servern zugreifen.
  
  Anmeldung vom Internet > SCAMA > WAP > ADFS > OAuth2 > Jump Server > S4U2Self > Kerberos Delegation > Resource Server
  Anmeldung vom Internet aus via SCAMA an WAP > ADFS > Jump Server
  Anmeldung vom Internet aus via SCAMA an WAP > ADFS > Jump Server
  Ausführung Remote PowerShell auf dem Jump Server Nr. 2
• Modul 10: Jump Server Nr. 3 > OBO - OAuth2 On-Behalf Of > Double Hop
  Deep-Dive OAuth2 (III)
  Bei einer 2-Tier Applikation muss der Benutzer mit seinem OAuth2 Client zuerst auf das OAuth2 Front-End Server zugreifen.
  Der Front-End Server arbeitet im Namen des Benutzers um JSON Access Token Token von ADFS für den zweiten Hop auf das OAuth2 Backend Server zu beantragen.
  Ähnlich wie bei einem Kerberos Double-Hop Szenario ist ein SSO durch OBO möglich.
  In diesem Modul lernen wir mit Unterstützung unserer Entwickler, wie so eine moderne 2-Tier OAuth2 Applikation entwickelt wird.
  Das Ziel von solcher 2-Tier Web Applikation ist eigentlich, sicher via HTTPS auf die internen Ressourcen zuzugreifen (One Hop).
  Mit OBO ist es möglich das Front-End als Jump Server zu nutzen um auf das Back-End zuzugreifen (Double Hop)
  Die Web App auf dem Back-End Server kann programmiert werden um Systemdaten oder andere Daten vom Back-End für den angemeldeten Benutzer zu holen.
  
  Anmeldung vom Internet > SCAMA > WAP > ADFS > OAuth2 > Jump Server (Front End) > OAuth2 On-Behalf Of > Back End Server
  OAuth2 Two-Tier App mit ADFS und OBO (On-Behalf Of)
  OAuth2 App Group
  Neues Access Token beantragen im Namen des Users
  Performance Analyse von einem Back-End Server von Jump Server Nr. 3 aus
• Modul 11: OAUTH2 Client "Work Folders" - One Hop
  Deep-Dive OAuth2 (I)
  Modernes Authentifizierungs- und Autorisierungs-Protokoll wie OAUTH2, welches auf REST aufgesetzt ist, ermöglicht im Gegensatz zum älteren Protokoll wie WS-Federation (SOAP basierend) Web Anwendungen zu entwickeln, die eine komplexe Autorisierung, oft über mehrere Parteien bzw. Server hinweg, benötigen. Ein typisches Beispiel ist die Autorisierung auf Terminkalender in einer Exchange Hybrid Umgebung.
  Windows 10 Work Folders ist ein OAuhth2 Client. Er kann via HTTPS intern auf den Work Folders Server (od. Cluster) zugreifen.
  Sinnvoll ist es jedoch den HTTPS-Zugriff auf die internen Ressourcen via WAP und ADFS vom Internet aus zu ermöglichen.
  
  "Work Folders" File Server Failover Cluster mit AD FS Authentication
• Modul 12: Azure MFA (Demo)
  In der Regel möchte man in einer hochsicheren ESAE Umgebung nicht unbedingt mit der Cloud zu tun haben. Doch durch die sichere Trennung von Bastion Forests und Produktion Forests sowie die Trennung zwischen internen Produktionsressourcen und externen Zugriff durch ADFS / WAP ist es möglich, dass externe Clients vom Internet oder von Business Partnern sicher auf die internen Ressourcen zugreifen können. Die Sicherheit wird massiv erhöht, wenn von Internet Clients die zusätzliche MFA (Multi-Factor Authentication) verlangt wird. Dies ist durch die Zusammenarbeit zwischen ADFS und Azure MFA einfach möglich.

Bemerkung: Die einzelnen Kursbausteine werden laufend ergänzt.

Hinweis: Bitte bringen Sie zum Kurs Ihre Evaluation DVD oder ISO mit, wenn Sie eine spezielle Sprachversion wie z.B. " Französisch" wünschen. Wir dürfen keine Volume License für Kurse nutzen!

- Vertrauen Sie unserer Kompetenz -