AD Federation Service - Workplace Join - Multi-Factor Authentication - Hybrid Cloud

Intensivkurs KERBEROS

Kerberos & AD Federation Services

"Golden Ticket" - "PAC Validation" - SSO mit Windows Authentication & Claims based Identity - Workplace Join - AD FS 4.0



Achtung! Dieser Kurs wird in dieser Form nicht mehr angeboten - Besuchen Sie den umfangreichen Kurs "ASAI" in 2017.


* ASAI (Advanced Secure AD Infrastructure)

Die Kerberos Riesensicherheitslöcher durch "Golden / Silver Ticket" werden neben den One-Hop und Double-Hop Authentifizierungsszenarien durch Impersonation und Delegation für SSO in diesem Intensivkurs ausführlich praktiziert.
Mit ADFS wird die Reichweite der Kerberos Authentication in einem AD Forest durch Claims basierte Web Applikation (CBWA) auch für Zugriffe aus "untrusted" Umgebung erweitert.

ZIELGRUPPE
Das Seminar richtet sich an Enterprise und Domain Administratoren, IT-Sicherheitsbeauftragte, Security Auditoren und Controlling bzw. IT-Revisoren.
Kenntnisse in Windows und Netzwerk Security.
Erfahrung mit Active Direcrtory.

NIVEAU
★★★★☆ — ziemlich anspruchsvoll

DAUER
4 Tage

ORT
NT Systems Schulungszentrum Böblingen (Karte)

TERMINE

Zur Anmeldung

PREIS
2.950,- € zzgl. Mwst. – inkl. Mittagessen 14,- € / Tag

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

SCHULUNGSZEITEN
Am ersten Tag 10:00 - 17:30 Uhr
An Folgetagen 08:30 - 17:30 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.

Kerberos: Aktuell ist das Thema "Golden Ticket", das die AD-Welt erschüttert. Wenn sich ein Hacker den Vollzugriff auf einen Domain Controller verschafft hat, kann er den NTLM Hash des krbtgt Kontos stehlen, aus dem der Master Key von jedem DC in der Domäne generiert wird. Der NTLM Hash des Krbtgt wird ausserdem für die Signierung des PAC (Privilege Attribut Certificate) im TGT (Ticket Granting Ticket) und TGS (Service Ticket) eingesetzt. Mit diesem NTLM Hash kann der Hacker ein sog. Golden Ticket (TGT) erstellen und die Identität von jedem Domain Benutzer und auch Computer annehmen und somit auf beliebige Ressourcen zugreifen. Dieses "krbtgt" Problem wird verstärkt durch das zweite Problem der PAC Validation (Privilege Account Certificate) bei 2008/2008 R2 DCs, die keinen Patch MS14-068 (3011780) haben. Der Hacker kann das PAC-Feld in einem TGS so ändern, dass er sich zu Domain oder gar Enterprise Administrator macht und mit diesem sog. Silver TGS Ticket auf geschützte Ressourcen in der Domäne zugreifen kann. Wenn die PAC Validation aktiviert ist, validieren die "unpatched" 2008 R2 DCs die veränderte Gruppenmitgliedschaft im PAC-Feld nicht richtig. In dem Fall muss der Hacker nicht einmal ein administratives Konto oder ein "Golden Ticket" benutzen. In diesem Kurs werden die Probleme näher erläutert und auch demonstriert. Sie lernen auch im Kurs die Abwehrmaßnahmen und wie man u.a. die gesamte AD Umgebung mit dem Tool ATA (Advanced Threat Analytic) überwachen kann.

ADFS: Das SSO für den Zugriff auf "fremde" web-basierte Anwendungen innerhalb oder außerhalb des "hauseigenen" AD Forests wie z. B. Microsofts Azure Cloud wird mehr und mehr verlangt, besonders wenn Hybrid Cloud zum Einsatz kommt. Als Vermittler zwischen AD und der Claims basierten Anwendung wird nun ADFS als Security Token Server eingesetzt. Active Directory Benutzer müssen sich nur einmal anmelden (Single-Sign On), um auf eine Claims basierte Webanwendung innerhalb oder außerhalb des AD Forests z.B. in der Azure Cloud zugreifen zu können. Die Web Anwendung (ASP .NET oder WCF Windows Communication Foundation) muss also Claims basiert sein, damit sie u.a. die Authentifizierung an ADFS weiterleiten kann. Microsoft hat die Entwicklungsplattform WIF (Windows Identity Foundation) für Claims basierte Anwendungen in .NET Framework 4.5 integriert.

ADFS Szenario 1 (Hybrid Cloud): Benutzer einer AD Domäne (On-Premises) greift mit seinem Browser (oder Applikation) auf eine Azure Web Applikation wie Office 365 (Exchange Online) via HTTPS zu. Diese Claims Based Web Application (CBWA) in Azure übergibt (Redirect) die Authentifizierungsüberprüfung inkl. Claims-Anforderungen an einen ihm vertrauenswürdigen (Trust) Security Token Server (ADFS Server + ADFS Proxy Server). Durch den Login-Endpoint am ADFS Server (adfs-FQDN/adfs/ls) bekommt der Browser eine Anmeldemaske, wo der Benutzer seine Domain-Credentials eingeben kann. Der ADFS Server übergibt als Verbund-Authenticationsserver (Federate Authentication) im Namen des Benutzers die Credentials an einen DC der Benutzerdomäne. Nach der erfolgreichen Authentifizierung bekommt der ADFS Server (Claims Provider) die von der CBWA verlangten Claims wie z.B. Display Name, UPN (User Principal Name) etc. (Inbound Attributes) für die Umwandlung in Claims (Outbound Claims) für Azure ACS (entspricht in etwa ADFS Server von Microsoft in Azure). Das Ergebnis ist ein vom ADFS Server signiertes Security Token mit Claims für die CBWA. Durch den Trust zwischen dem On-Premises ADFS Server (Claims Provider der Nutzerseite) und dem Azure ACS (Relying Party) akzeptiert die CBWA (Office 365) die Claims und lässt den Benutzer auf die Anwendung zugreifen. Abhängig von Claims Typen wird die Berechtigung auf die Anwendung geregelt (Autorisierung).

ADFS Szenario 2 (B2B): Eine Claims Based Web Applikation in einem Resource AD Forest (ADFS Hub) wird von Benutzern anderer "untrusted" Forests (ADFS Spokes) via HTTPS genutzt. Der Hub ADFS Server (Relying Party) ist die Zentralanlaufstelle (Federation Hub Server) für alle Spoke ADFS Server. Dieser erzeugt Security Token mit den benötigten Claims für die CBWA. Er leitet die Authentifizierungsanfragen von Clients (Browser) an den jeweiligen Spoke ADFS Server (Claims Provider) und bekommt nach der Authentifizierung des Nutzers von diesem Spoke ADFS Server Security Token mit Claims zurück, um diese dann in die richtige Form für die CBWA zu transformieren. Die Authentifizierung des Nutzers geschieht nur einmal (SSO) am jeweiligen Spoke ADFS Server. Dieser arbeitet im Namen des Nutzers (Impersonation), um sich an einem Domain Controller zu authentifizieren. Durch den Claims Provider Trust werden so Claims für die Autorisierung an der CBWA akzeptiert.

ADFS Trends:
Wenn nur auf Ressourcen innerhalb eines AD Forests zugegriffen wird, wird ADFS nicht unbedingt benötigt. Der Trend geht aber eindeutig in Richtung Claims basierte Web Application (CBWA) mit Federation Authentication und Claims Identity durch ADFS. Die CBWA kann ganz neutral entwickelt werden und wird von der Authentifizierung entkoppelt. Sie muss sich weder um die Benutzer-Credentials noch um ihre Speicherung kümmern. Die Weiterleitung an einen ADFS Server sowie Trusts zwischen diesem und der CBWA werden am Anfang der Zusammenarbeit definiert und konfiguriert. Die CBWA kann jeder Zeit für weitere Zugriffe erweitert werden. Die zentrale (On-Premises) Hub ADFS Serverfarm kann mit Microsofts ACS (Azure Access Control Service) zusammenarbeiten, um auch Internet-Nutzern von anderen Claims Providern wie Yahoo, Facebook, Windows Live ID oder Google ID den Zugriff auf die CBWA zu ermöglichen.

Durch Federation Trust (ADFS) und CBWA kommt Workplace Join ins Spiel. Mitarbeiter haben meist neben ihren Firmencomputern auch Privat-Computer oder Geräte (iPAD, Smartphones, Notebooks etc.). Ein Unternehmen kann Workplace Join für solche Privat-Computer (BYOD = Bring Your Own Device) einrichten, sodass diese, auch ohne Mitglied einer AD Domäne sein zu müssen, auf Claims Basierte Web Applikationen zugreifen dürfen. Durch ein Workplace Join wird der Computer für den jeweiligen Domainbenutzer in AD registriert und bekommt von ADFS ein Zertifikat.

Kerberos:
Das Authentifizierungsprotokoll in einem Active Directory Forest ist standardmäßig KERBEROS V5. Wenn jedoch eine Applikation nicht korrekt für Kerberos konfiguriert ist, wird automatisch in einer AD Umgebung das ältere und "schwächere" NTLM-Protokoll eingesetzt (z.B. SMB-Freigabe mit IP-Adresse verbinden, oder nur NTLM wurde gezielt genutzt). Höhere Sicherheit bei der Authentifizierung bekommt man nur mit Kerberos und noch besser in Kombination mit Smart Card, weil kein Password-Hash in der Pre-Authentication Phase über die Leitung zum KDC verschickt wird. Wir lernen in einem Active Directory Forest 2008 R2/2012 R2 Kerberos im Detail kennen. Neben der Kerberos-Authentifizierung von Windows Clients mit und ohne Smart Card (PKINIT) wird auch Open Source Client am Beispiel von OpenSUSE praktiziert.

Am Beispiel von Benutzer- bzw. Computer-Anmeldung (zunächst ohne Smart Card) in einer AD Domäne analysieren wir die Kommunikation zwischen Client, Resourcenserver und Domain Controller (KDC Key Distribution Center) und lernen dabei die Kerberos-Kommunikation kennen. Das auf Symmetric Key basierte Kerberos arbeitet mit diversen Keys, um den Austausch der Symmetric Keys über das Netzwerk zu schützen. Session Keys (Short-Term Key) werden zwischen zwei Partnern eingesetzt und ausgetaucht. Sie werden wiederum vom jeweiligen (User, Server, KDC) Master Key (Long-Term Key) verschlüsselt. Die verschlüsselten Session Keys bzw. Tickets: TGT (Ticket Granting Tickets) von Authentication Service (AS) und TGS (Ticket Granting Service Tickets) von Ticket-Granting Service (TGS) bilden so die Grundlage von Kerberos.

Wir studieren die Kerberos-Authentifizierung einer Multi-Domänen-Umgebung mit Root- und Subdomänen (siehe Bild), um die Mehrfachausstellung von TGT zu zeigen und dass dieser Authentifizierungsweg durch Shortcut-Trust zwischen Account- und Resource-Domäne verkürzt werden kann. Auch die Gruppenmitgliedschaft und Gruppentypen beeinflussen die Größe des Access Token und somit das PAC Feld (Privilege Attribut Certificate) eines Kerberos TGT. Insbesondere beim PAC-Feld hat Microsoft mit Server 2012 R2 die PAC-Compression eingeführt, welche bei 3rd Party Applikationen zu Problemen führen kann. Die Kerberos Mutual Authentication verlangt, dass Computerkonten bzw. Dienstkonten die sog. Service Principal Name (SPN) registrieren. Virtuelle Instanzen z.B. vom Failover Cluster müssen wegen der Mutual Authentication "virtuelle Computerkonten" in AD besitzen, um u.a. SPN registrieren zu können. Die korrekte Implementierung und Anwendung von Kerberos wird von verschiedenen Faktoren beeinflusst, wie beispielsweise DNS, Ticketlaufzeiten, SPNs, Delegierung, Impersonation etc. Nur wenn alle betroffenen Komponenten einwandfrei ineinander greifen, ist eine Authentifizierung über das Kerberosprotokoll sicher gestellt. Eine "kerberos-fähige" Anwendung wie z.B. SharePoint 2012 oder Exchange 201x CAS arbeitet standardmäßig nur mit NTLM, wenn diese nicht extra für die Kerberos Authentifizierung korrekt konfiguriert wird.

Kerberos Tickets können delegiert werden. Durch sog. "Constrained Delegation" kann der Delegierungszweck (z.B. nur für CIFS) fein ausgewählt werden. Neben Constrained Delegation gehört die sog. Protocol Transition zu den Kerberos Extension für "kerberized" Anwendungen, die wir im Kurs auch kennenlernen. Durch den Einsatz von 2012 R2 Domain Controllern ist es auch möglich über Domänen-, ja sogar über Forestgrenzen hinweg zu delegieren!

Das Auditing von Domänen- und Netzwerkanmeldungen liefert Ereignisse zu Kerberos- und NTLM-Authentifizierung, die wir im Kurs analysieren. Dadurch können Ursachen bei Fehlanmeldungen und Zwang-NTLM-Anmeldungen ermittelt werden. NTLM-Blocking Richtlinien können bei 2012 R2 Servern aktiviert werden, um "undichte" Anwendungen, die statt Kerberos nur NTLM-Authentifizierung nutzen, zu lokalisieren.

Ziel des Kurses ist, dass die Teilnehmer ein solides Wissen über Kerberos V5 in einer Active Directory Umgebung bekommen und auch in die Praxis umsetzen können. Auch die Probleme mit "Golden Ticket" und PAC Validation werden im Kurs erläutert und Gegenmaßnahmen entwickelt. Durch die Erweiterung um ADFS und Claims Basierte Web Application (CBWA) wird die komplette Authentifizierung mit SSO durch den Kurs abgedeckt. Da wir auch traditionelle ASP .NET Anwendungen in CBWA umgeschrieben haben, können wir Ihnen auch die Tiefe von so einer Anwendung zeigen.

» Dieser Kurs wird durch die Kurse PKI2016, ADS2016 sowie Windows Security ergänzt.

AD Federation Service - Workplace Join - Multi-Factor Authentication - Hybrid Cloud
AD Federation Service - Workplace Join - Multi-Factor Authentication - Hybrid Cloud

Cerberus
Cerberus (Quelle: Microsoft)

Kerberos Authentifizierung am 2008 R2 RODC
Kerberos Authentifizierung am 2008 R2 RODC

NT Systems - Kerberos & AD Federation Services Schulungsunterlagen
NT Systems - Kerberos & AD Federation Services Schulungsunterlagen

Hinweis: Bitte bringen Sie zum Kurs Ihre Evaluation DVD oder ISO mit der gewünschten Sprachversion mit. Wir dürfen keine Volume License für Kurse nutzen!

Zum Seitenanfang

- Vertrauen Sie unserer Kompetenz -