Dieser Workshop fusst auf einem On-Premises AD und einem bereits registrierten und synchronisierten Tenant bei Microsoft in EntraID (Azure nutzt Entra ID – aber Entra ID ist mehr als Azure). Wie so häufig finden sich im Active Directory und bei der Synchronisierung zu Entra ID gute Ansätze eine Optimierung für einen sicheren, resilienten und belastbaren Betrieb durchzuführen.

Zu Beginn werden die verschiedenen On-Premises Authentifzierungs-Protokolle untersucht. Die Praxis hat gezeigt, dass LM und NTLMv1 in der Regel weniger verwendet werden. Jedoch ist NTLMv2 mittlerweile schwer angeschlagen und sollte zeitnah abgeschaltet werden. Wir untersuchen, was die genauen Unterschiede von NTLMv1 zu v2 sind und warum die beiden Protokolle nicht mehr verwendet werden sollten. Somit braucht es eine Alternative On-Premises für die Authentifzierung und das ist das Kerberos V5-Protokoll. Wie dieses funktioniert und warum das Protokoll eben (noch) nicht dem Untergang geweiht ist, erfahren Sie in diesem Workshop. Kerberos V5 wird demnächst LM, NTLMv1 und NTLMv2 vollständig ablösen; in der Domäne und in der Arbeitsgruppe.

Leider ist es immer noch möglich die On-Premises-Authentifzierung auszuhebeln, in dem auf die bekannten Schwachstellen die Pass-the-Hash und Pass-the-Ticket gesetzt wird. Das sind aber leider nicht die einzigen Schwachstellen im On-Premises Active Directory. Kerberoasting, Skeleton-Keys, DCShadow und Offline-Attack machen das Leben mit einem Active Directory nicht leichter.

Auf die oben genannten Probleme werden im Rahmen des Workshops genaue Lösungen erarbeitet. Dazu zählen Maßnahmen wie die RC4-Verschlüsselung bei Kerberos abzuschalten, Domain Controller mit Bitlocker zu verschlüsseln, LM und NTLM(v1 und v2) abzuschalten, Windows LAPS für das Directory Service Restore Mode-Konto zu aktivieren, administrative Konten zu verbergen sowie die Verwendung von gMSA und dMSA vorzubereiten, zu implementieren und umzusetzen.

Strukturelle Veränderungen im Active Directory ermöglichen es eine „veraltete“ ESAE-Struktur zu implementieren und ein Tiering zu erzwingen. Neue OU-Strukturen, neue Policies, neue Rollenmodelle und neue Delegierungen erlauben es den Angriffsvektor zu schmälern, zeitlich (PIM durch das PAM-Modul im Active Directory) einzugrenzen und in weiten Teilen so klein zu gestalten, dass die Möglichkeit einer Kompromittierung sehr gering wird.
Gestärkt durch den Credential Guard (CG), Remote Credential Guard (RDG) und Remote Guard bleibt Kerberos V5 mit Single Sign-On die treibende Kraft der passwortlosen Authentifizierung. Die passwortlose Authentifizierung wird durch Smart Card Logon erreicht, für die administrativen Konten aber mit Authentication Mechanism Assurance (AMA) zusammen. Durch AMA wird die Privilegierung an die Art der Authentifizierung On-Premises gebunden. Durch diesen Mechanismus ist selbst eine Kompromittierung eines administrativen Kontos in der Risikobeurteilung als „gering“ zu bezeichnen.

Eine ausgefeilte Bereitstellung von Geräten rundet das Bild der On-Premises-Authentifizierung ab. Privileged Administrative Workstations (PAWs) werden gegenüber Privileged Administrative Servers (PASs) vergleichen. Die PAW deckt den On-Premises-Bereich ab, ein PAS deckt den Cloud-Bereich ab. Jedoch muss sichergestellt sein, dass die Zugriffe auf diese Devices in einem sicheren Kontext erfolgen. Wieder bildet unser Kerberos V5 die Grundlage, die hier mit IPSec zu einem „conditional access“ On-Premises führt. Gerät, Gruppenmitgliedschaft, Art der Authentifizierung und Richtung des Zugriffes geben die Grenzen einer adiministrativen Bewegung vor.

Das Entra ID wird in unserem Workshop durch das On-Premises Active Directory provisioniert.

Doch hier entstehen einige Fragen:

• Was gilt es hier zu beachten?
• Wer darf abgeglichen werden, wer nicht? Wie steuere ich das, wer abgeglichen wird?
• Welche Arten der Authentifizierung gegenüber Entra ID habe ich eigentlich?
• Was ist mit dem MSOL_*-Konto? Ist das gefährlich? Muss das Kennwort geändert werden?
• All jene Punkte müssen geklärt werden, bevor man sich mit dem EntraID-Rollenmodell auseinandersetzen kann.

Das Rollenmodell von Microsoft Entra ID definiert, welche Aufgaben und Berechtigungen ein Benutzer oder Administrator innerhalb des Verzeichnisses ausführen darf. Es basiert auf vordefinierten Rollen wie Global Administrator (GA), User Administrator oder Security Administrator, die jeweils bestimmte Verantwortlichkeiten und Zugriffsmöglichkeiten mitbringen. Die Zuweisung erfolgt unabhängig von Gruppen oder Organisationsstrukturen und kann durch Privileged Identity Management (PIM) zusätzlich zeitlich begrenzt oder genehmigungspflichtig gestaltet werden. So ermöglicht das Rollenmodell eine sichere und nachvollziehbare Rechtevergabe, angepasst an individuelle Aufgaben und Anforderungen.

Microsoft Entra ID präsentiert ein rollenbasiertes Berechtigungsmodell, mit über 60 vordefinierten Rollen, um administrative Aufgaben zu delegieren. Die zentrale Rolle ist der Global Administrator (GA), der uneingeschränkten Zugriff auf alle Funktionen und Rollen hat. Diese Rolle sollte nur sehr wenigen, vertrauenswürdigen Personen zugewiesen werden. Ein Privileged Role Administrator weist Administratorrollen zu und zusammen mit Privileged Identity Management (PIM) werden diese zeitlich begrenzt. Perfekt für kontrollierte und nachvollziehbare Berechtigungen. Für alltägliche Benutzer- und Gruppenaufgaben gibt es den User Administrator, während der Security Administrator sicherheitsrelevante Einstellungen wie Multifaktor-Authentifizierung (MFA), Conditional Access und Bedrohungswarnungen verwaltet. Der Application Administrator übernimmt die Verwaltung von Apps und App-Registrierungen. Ergänzend dazu kümmert sich der Authentication Administrator um Authentifizierungsmethoden wie FIDO2, Passwortzurücksetzung oder SMS-MFA.

Die Sicherungskonzepte für globale Administratoren sind der Anker der EntraID-Sicherheit. Hier wird das Zentrum der Cloud-Macht gegen unbefugte Zugriffe wirksam, belastbar und nachhaltig gesichert.

• MFA: absolut unverzichtbare Komponente, mit denen die Sicherheit gewährleistet wird. Vorzugsweise durch einen YubiKey wird ein FIDO2 Token auf einem externen Medium phishing-resistant abgelegt.
• FIDO2 mit Security-Key: die derzeit beste Realisierung von MFA. Hier im Workshop mit Yubico YubiKey 5(c) NFC
• Break Glas-Konten: Das Lindblatt auf Siegfrieds (Cloud)-Rücken. Im Notfall müssen die funkionieren und zwar, zwangsweise, mit MFA! Das wird spannend…
• Conditional Access: Regeln für den Zugriff – wann, wie, wo, wodurch und womit. Da ist man schneller draußen als drin.
• Privileged Identity Management (PIM): das Ganze aber nur für kurze Zeit – Just in time administration (JITA)
• Decicated Admin Accounts: Benutzergebundene administrative Konten, welche nur im EntraID existieren; das wird der Schlüssel zu Nachvollziehbarkeit.
• Logging und Überwachung: wer war wann wo womit und wodurch?
• Rollenminimierung: 2 bis 4 Mitglieder in den GA, wobei zwei davon Break-Glas sind.
• Passwortschutz: schwache Kennwörter schon bei der Ablage unterbinden; wobei das Ziel password-less sein muss.

Die Zusammenführung der beiden Welten ist dann abschließend die Königsdisziplin. Vorgenehmigte (physische) Geräte bilden das Rückgrad des Zugriff, die Schnittstelle vom Menschen zur On-Premises-Welt und zur Cloud-Technologie. Hier im Workshop schwindet der Punkt der Physik und wird durch Virtualität ausgeglichen, da Sie natürlich remote oder vor Ort am Kurs teilnehmen können. In der Praxis ist dieses nicht zu empfehlen. Es muss auf physikalische Hardware gesetzt werden, die den Compliance-Regeln vom Intune standt hält. Dieses letzte kleine Mosaiksteinchen vollendet das Bild des sicheren, belastbaren und einfachen Zugriff auf die On-Premises-Welt, sowie auf das EntraID-Biotop.