Intensivkurs ASAI-2

ASAI-2 - Hybrid Authentication

Extended ESAE - SCAMA & MAMA - Jump Server - Kerberos - ADFS - WS-* - OAuth2 – Conditional Access

Dieser neue projektorientierte und ziemlich komplexe ASAI-2 "Hybrid Authentication" Intensivkurs ist für alle Administratoren und besonders für alle ASAI-1 Absolventen gedacht, die in der Praxis eine hoch sichere Multi-Forest Enterprise AD-Umgebung mit 2016 Bastion Forests aufbauen möchten. ASAI-2 erweitert den Kurs ASAI-1 (eingeschränkt auf Kerberos) und somit ESAE um die Hybrid Authentication mit ADFS, Jump Server, MAMA ,CBWA Portal , OAuth2 OBO (On-Behalf Of)..

In ASAI-2 werden auch die neuesten zertifikatsbasierenden Kerberos Erweiterungen für Windows 10 und Windows Server 2016 unterrichtet, die dafür sorgen, dass kein Computerpasswort und Benutzer-Passwort für die Verschlüsselung der Kerberos Nachrichten eingesetzt werden müssen. PKINIT und FAST sowie Compound Authentication sollen pflicht sein in einem Bastion Forest.
Jump Server (Nr. 1) dient als Sammelpunkt für die zentrale HTTPS Remote Administration von mehreren Servern in einem Produktion Forest. Von einer "zertifizierten" PAW (PAPA-MAMA) in einem Bastion Forest aus gehen Administratoren auf den Jump Server um von dort aus andere Server in diesem Produktionsforest zu verwalten.

Weitere Jump Server Typen (Nr. 2 und Nr. 3) mit Modern Authentication (OpenID Connect und OAuth2) sorgen für die Zusammenarbeit zwischen Kerberos Based und Token Based Authentication, wenn der Benutzer vom Internet mit HTTPS via WAP und ADFS 2016 auf den internen Jump Server zugreift um interne Server zu verwalten.

CBWA Portal (Claims Based Web Application) ermöglicht Benutzen und Business Partnern auch ausserhalb einer Kerberos Umgebung die gemeinsame Nutzung von internen Web Anwendungen.

MAMA sorgt neben SCAMA und Authentication Policy dafür, dass alle Bastion Forest Admins sehr sicher an zertifizierten PAWs arbeiten können. Anstelle von Virtual Smart Card für SCAMA kann Windows Hello For Business (WHFB) eingesetzt werden, wenn TPM 2.0 vorhanden ist und Azure AD genutzt werden darf. Das bei WHFB verwendete Verfahren PRT (Primary Refresh Token) gilt im Moment als die modernste und sicherste Authentifizierungsmethode in der Windows Welt.
Um solche komplexe Umgebung betreiben zu können, wird u.a. ein umfangreiches Wissen der Authentifizierungsprotokolle Kerberos und WS-Federation sowie OAUTH2 und OpenID Connect verlangt. ADFS und WAP übernehmen an den Authentifizierungsübergängen sowohl die Protokollumwandlung (Protocol Transition) als auch die Token-Umwandlung (Windows Access Token, SAML-Security Token, JSON Access Token). Wir zeigen im ASAI-2 auch Azure MFA in Kombination mit ADFS.

Bemerkung: Die Kursmodule von ASAI-1 wie PAW und SCAMA sowie die verschiedenen ESAE Szenarien werden im ASAI-2 Kurs nicht mehr ausführlich behandelt.

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

weitere Termine in Planung

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.

ASAI (Advanced Security AD Infrastructure) mit Bastion "Red" Forest, Privileged Forest und Produktion Forests (Account, Resource)

Jump Server 1, 2, 3

Kerberos Authentication mit PKINIT (RFC 4556)

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 -