Exchange Server 2025: Was Sie bei der Migration zur Subscription Edition beachten mĂŒssen

Im Mai 2024 hat Microsoft seine Exchange Server Roadmap vorgestellt und die PlĂ€ne fĂŒr die Zukunft von Exchange Server veröffentlicht. Siehe Neuerungen in der Exchange Server Roadmap: Neueste Updates zur Exchange Server Roadmap: Entdecken Sie CU15 und Exchange Server SE

Mit dem bevorstehenden Release der Exchange Server Subscription Edition (SE) ab 2025 stellt Microsoft wichtige Neuerungen und Anforderungen fĂŒr Organisationen vor, die Ă€ltere Versionen von Exchange Server nutzen. Die Migration zu Exchange SE ist entscheidend, da Ă€ltere Versionen wie Exchange 2016 und 2019 nur noch begrenzt unterstĂŒtzt werden. In diesem Artikel erfahren Sie, wie Sie Ihre Organisation optimal auf das Upgrade vorbereiten.

Die Roadmap

Zur besseren zeitlichen Darstellung, hier ist eine Tabelle, die diese Veröffentlichungen und ihre Auswirkungen auf die Koexistenz mit frĂŒheren Versionen zusammenfasst:

NameErscheinungsdatumDetailsKoexistenz
Exchange Server 2019 CU15Zweite Halbjahr 2024Finales CU fĂŒr Exchange Server 2019. CodeparitĂ€t mit Exchange Server SE RTM (mit Ausnahme von SUs, die vor Exchange SE RTM veröffentlicht wurden)Keine Koexistenz mit Exchange 2013
(Installation wird durch CU15-Setup blockiert)
Exchange Server SE RTMAnfang zweite Halbjahr 2025Ermöglicht ein direktes Upgrade von Exchange 2019 CU14 oder CU15. CodeparitÀt mit Exchange 2019 CU15 + alle SUs, die seit CU15 veröffentlicht wurden (keine neuen Features oder andere CodeÀnderungen)Keine Koexistenz mit Exchange 2013
(Installation wird durch RTM-Setup blockiert)
Exchange Server SE CU1Ende zweite Halbjahr 2025Erste EinfĂŒhrung neuer Funktionen in Exchange Server SEKeine Koexistenz mit Exchange 2013, Exchange 2016 oder Exchange 2019 (Installation durch CU1-Setup blockiert)
Übersicht Roadmap

Supportstatus von Exchange Server-Versionen

In der folgenden Tabelle werden die letzten drei Versionen von Exchange, ihre LifeCycle und die Auswirkungen der oben genannten Versionen dargestellt:

Exchange VersionEnd of SupportAb 2019 CU15Ab Exchange SE RTMAb Exchange SE CU1
Exchange 201311.04.2023not supportednot supportednot supported
Exchange 201614.10.2025Extended SupportExtended SupportNot supported
Exchange 2019 CU14.10.2025Extended SupportExtended SupportNot supported
Übersicht Support

Alle anderen Versionen und Builds von Exchange Server werden nicht unterstĂŒtzt, mit Ausnahme von Exchange 2019 CU13, das mit der Veröffentlichung von Exchange 2019 CU15 nicht mehr unterstĂŒtzt wird.

Koexistenz verschiedener Versionen in derselben AD Organisation

Microsoft nimmt gravierende Änderungen in Exchange Server vor, die sich auf die Koexistenz mit Ă€lteren Versionen in derselben Organisation (Forest) auswirken. In der Vergangenheit war es möglich, eine Ă€ltere (und sogar nicht unterstĂŒtzte) Version von Exchange Server in einer Organisation mit neueren Versionen von Exchange Server weiterhin auszufĂŒhren. Wir IT-Consultants sprachen gerne von einer N-2 Versionskoexistenz. Dies bedeutet, in der Vergangenheit wurden die aktuelle und zwei vorherige Versionen innerhalb einer AD Organisation unterstĂŒtzt.

Dies Àndert sich in zweierlei Hinsicht:

  • Das Setup in Exchange Server 2019 CU15 und Exchange Server SE RTM blockiert die Koexistenz mit Exchange Server 2013.
  • Das Setup in Exchange Server SE CU1 blockiert die Koexistenz mit allen nicht unterstĂŒtzten Versionen (z. B. Exchange Server 2013, Exchange Server 2016, Exchange Server 2019) und lĂ€sst die Koexistenz nur mit Exchange Server SE zu.

Wichtig: Wenn Exchange Server SE CU1 veröffentlicht wird, wird der Support fĂŒr alle anderen Versionen von Exchange Server eingestellt. Wie in der folgenden Tabelle beschrieben, mĂŒssen Sie zum Installieren von CU1 (oder höher) zunĂ€chst alle Ă€lteren Versionen von Exchange Server außer Betrieb nehmen und ordnungsgemĂ€ĂŸ aus Ihrer Organisation entfernen.

Was Sie nun unternehmen sollten

Um auf Exchange Server SE zu aktualisieren, haben Sie verschiedene Optionen.

Da Exchange 2013 bereits sein „End of Life“ erreich hat, sollten Sie bereits Exchange Server 2016 CU23 oder Exchange Server 2019 CU13/CU14 nutzen. Falls Sie eine frĂŒhere Version von Exchange 2016 einsetzen, ist ein sofortiges Update auf CU23 erforderlich. FĂŒr Exchange 2019 Kunden wird CU14 empfohlen, jedoch wird auch CU13 noch unterstĂŒtzt.

Wenn Sie Àltere Versionen wie Exchange 2013 oder noch Àlter betreiben, sollten Sie entweder auf Exchange Online migrieren oder ein Upgrade auf Exchange Server 2019 mit dem neuesten Cumulative Update in Betracht ziehen.

Warum sollten wir unsere Server aktualisieren, wenn es keine neuen Features gibt?

Microsoft wird den Support fĂŒr Exchange Server 2016 und 2019 am 14. Oktober 2025 einstellen. Um ein direktes und unkompliziertes Upgrade von Exchange Server 2019 zu ermöglichen, wurden neue Funktionen entweder bereits in Exchange Server 2019 CU15 integriert oder fĂŒr Exchange Server SE CU1 und höher vorbereitet.

Der Wechsel zu Exchange Server SE RTM fĂŒhrt zu einem Update des Brandings sowie neuen Lebenszyklus- und Supportrichtlinien. Nach der Veröffentlichung von Exchange SE CU1 werden Ă€ltere Versionen nicht mehr unterstĂŒtzt, und Microsoft fĂŒhrt ab CU1 neue Funktionen fĂŒr Exchange Server ein.

Lektionen aus dem Angriff auf SĂŒdwestfalen-IT: PrĂ€vention und Schutzmaßnahmen

Der Angriff auf SĂŒdwestfalen-IT durch die Ransomware-Gruppe „Akira“ im Oktober 2023 bietet wertvolle Einsichten in Cybersicherheitsrisiken und PrĂ€ventionsstrategien. Dieser Blogbeitrag analysiert die einzelnen Schritte der Angreifer und diskutiert, wie diese hĂ€tten vermieden werden können. Als Quelle fungierte der öffentliche forensische Bericht.

Schritt 1: IdentitÀten absichern und Sicherheitsupdates einspielen

Schwachstelle in der VPN-Lösung: Der Angriff begann mit dem Ausnutzen einer Schwachstelle (CVE-2023-20269) in der VPN-Lösung ohne Multi-Faktor-Authentifizierung (MFA).

Warum Kennwörter unsicher sind und selbst MFA nicht immer ausreichend ist!

Die angebliche Zero-Day Schwachstelle, welche von der Akira Ransomware Gruppe ausgenutzt wurde, wurde bereits am 24ten August von Cisco in einem Blog Artikel erwĂ€hnt. Von einer Zero-Day Attacke (CVE-2023-20269) kann bei 55 Tagen nach Bekanntgabe daher nun wirklich keine Rede sein. Ein passendes Sicherheits-Update wurde am 11ten September zur VerfĂŒgung gestellt. Erste identifizierte Angriffe wurden am 18ten Oktober identifiziert werden.

Akira Ransomware Targeting VPNs without Multi-Factor Authentication – Cisco Blogs

PrĂ€vention: Die Implementierung von einer sicheren MFA hĂ€tte den Zugriff deutlich erschwert. Außerdem sollte bei Bekanntgabe von CVE’s immer eine direkte Bewertung sowie passende Maßnahmen umgesetzt werden. Die Einrichtung von Systemen zur Erkennung verdĂ€chtiger AktivitĂ€ten, wie ungewöhnliche Anmeldeversuche oder auffĂ€llige Netzwerkbewegungen, hĂ€tte die frĂŒhzeitige Erkennung des Angriffs ermöglichen können.

Schritt 2: Ausbreitung

Erhalten administrativer Berechtigungen: Nach dem Zugang zum Netzwerk erlangten die Angreifer administrative Rechte.

Die Angreifer konnten das Administrator-Kennwort ausnutzen, weil es seit 2014 in einem Gruppenrichtlinienobjekt in entschlĂŒsselbarer Textform hinterlegt war. Jeder Angreifer mit gĂŒltigen DomĂ€nen-Zugangsdaten konnte dadurch das Kennwort auslesen. Unter Verwendung eines von Microsoft bereitgestellten AES-SchlĂŒssels ließ sich das Kennwort entschlĂŒsseln, was den Angreifern ermöglichte, ihre Zugriffsberechtigungen auf das Niveau eines DomĂ€nen-Administrators zu erhöhen, ohne dabei typische forensische Anzeichen fĂŒr Privilege Escalation oder Lateral Movement zu hinterlassen.

PrĂ€vention: Striktere Zugriffskontrollen und regelmĂ€ĂŸige ÜberprĂŒfungen der Berechtigungen hĂ€tten dies verhindern können. Sie sollten regelmĂ€ĂŸig ihre Identity und Access Management Systeme auditieren.

Schritt 3: Verbreitung der Ransomware

Verbreitung der Ransomware: Die Ransomware wurde innerhalb der Windows-DomĂ€ne verbreitet. Die Verteilung der Ransomware erfolgte gezielt und anscheinend mittels Zugriffen auf das C$-Netzwerkshare der einzelnen Server. Es wurde angenommen, dass die Ransomware von Zielsystemen durch diese Zugriffe ausgefĂŒhrt wurde. Diese Annahme stĂŒtzt sich darauf, dass keine Spuren gefunden wurden, die auf andere Verteilungsmethoden hindeuten. Außerdem wurde festgestellt, dass die Ransomware w.exe selbst Logfiles schrieb, welche dokumentierten, welche Aktionen durch die Schadsoftware durchgefĂŒhrt wurden und welche Fehler beim VerschlĂŒsseln auftraten.

Es wurden 961 Systeme identifiziert, auf denen die Ransomnote akira_readme.txt vorzufinden war. Zum GlĂŒck wurden keine GPO’s, wie bei anderen Ransomware Gruppen ĂŒblich, verwendet. Andernfalls wĂ€ren ca. 4200 Clients und 800 Server betroffen.

PrÀvention: Bessere Netzwerksegmentierung, ein AD Tiering, eine klassische Server HÀrtung und strengere Zugangskontrollen hÀtten die Ausbreitung eingedÀmmt.

AD Tiering Struktur – Funktion und Nutzen

Schritt 4: VerschlĂŒsselung von Daten

Die Ransomware verschlĂŒsselte das Dateisystem von SĂŒdwestfalen-IT, indem sie einen rekursiven Ansatz verfolgte. Das Programm durchlief das gesamte Dateisystem und verschlĂŒsselte jedes Verzeichnis einzeln, beginnend mit dem angegebenen Startpfad. Interessanterweise nutzte die Ransomware, benannt als w.exe, eine Blacklist, um bestimmte Dateitypen, Dateiendungen und Verzeichnisse von der VerschlĂŒsselung auszunehmen. Nachdem die VerschlĂŒsselung in einem Verzeichnis abgeschlossen war, platzierte die Ransomware in jedem betroffenen Verzeichnis eine Erpressungsnachricht mit dem Namen „akira_readme.txt“​

PrĂ€vention: RegelmĂ€ĂŸige Backups und ein effektiver und regelmĂ€ĂŸig erprobter Disaster-Recovery-Plan hĂ€tte zudem eine schnellere Wiederherstellung der Systeme ermöglicht.

Schlussfolgerung:

Das Fazit aus dem Angriff auf SĂŒdwestfalen-IT durch die Ransomware-Gruppe „Akira“ unterstreicht die Wichtigkeit einer umfassenden und proaktiven Cybersicherheitsstrategie. Die SchlĂŒsselerkenntnisse sind:

  1. Bedeutung von Multi-Faktor-Authentifizierung: Die Abwesenheit von MFA, insbesondere bei kritischen Zugangspunkten wie VPNs, kann TĂŒröffner fĂŒr Cyberangriffe sein. MFA ist ein wesentlicher Bestandteil zur VerstĂ€rkung der Sicherheitsmaßnahmen.
  2. Wichtigkeit regelmĂ€ĂŸiger Sicherheitsaudits: Die Identifizierung und Behebung von Schwachstellen, wie z.B. schlecht gesicherte Passwörter, ist entscheidend, um potenzielle Angriffsvektoren zu minimieren.
  3. Notwendigkeit von Netzwerksegmentierung und strengen Zugriffskontrollen: Diese Maßnahmen können die Bewegungsfreiheit von Angreifern im Netzwerk begrenzen und die Ausbreitung von Malware verhindern oder zumindest einschrĂ€nken.
  4. Proaktive Überwachung und Anomalie-Erkennung: FrĂŒhzeitige Erkennung von verdĂ€chtigen AktivitĂ€ten und Angriffsversuchen ist entscheidend, um Eindringlinge abzuwehren, bevor sie ernsthaften Schaden anrichten können.
  5. Bewusstsein und Schulung der Mitarbeiter: Da Menschen oft das schwÀchste Glied in der Sicherheitskette sind, ist es wichtig, das Bewusstsein und die Wachsamkeit der Mitarbeiter zu stÀrken.
  6. Robuste Backup- und Disaster-Recovery-Strategien: Diese sind unerlÀsslich, um die Resilienz gegen Ransomware-Angriffe zu erhöhen und die GeschÀftskontinuitÀt im Falle eines Datenverlusts sicherzustellen.
  7. Einsatz fortschrittlicher Sicherheitslösungen: Der Einsatz moderner Antivirus- und Endpunkt-Schutzlösungen kann dazu beitragen, Bedrohungen frĂŒhzeitig zu erkennen und zu neutralisieren.

Der Vorfall zeigt einmal mehr, dass Cybersicherheit ein kontinuierlicher Prozess ist, der stÀndige Aufmerksamkeit und Anpassung erfordert, um mit den sich stÀndig weiterentwickelnden Bedrohungen Schritt zu halten.

Abschließend lĂ€sst sich sagen, dass der Angriff auf SĂŒdwestfalen-IT die Notwendigkeit eines Zero-Trust-Ansatzes in der Cybersicherheit unterstreicht. Zero-Trust bedeutet, grundsĂ€tzlich keinem Akteur innerhalb oder außerhalb des Netzwerks zu vertrauen, sondern jede Anfrage als potenzielle Bedrohung zu behandeln. Dieser Ansatz fordert eine kontinuierliche ÜberprĂŒfung und Authentifizierung, um Sicherheit in einer immer komplexeren und vernetzteren digitalen Welt zu gewĂ€hrleisten. Der Vorfall zeigt deutlich, dass der Übergang zu einem Zero-Trust-Modell fĂŒr Unternehmen unerlĂ€sslich ist, um sich gegen fortgeschrittene und sich stĂ€ndig weiterentwickelnde Cyberbedrohungen zu schĂŒtzen.

Sicherer Zugriff im Zeitalter der KĂŒnstlichen Intelligenz: Was ist neu bei Microsoft Entra?

Als IT-Berater bin ich immer auf der Suche nach den neuesten Innovationen im Bereich der Cybersicherheit, die meinen Kunden helfen können, ihre digitale Umgebung zu schĂŒtzen. Deshalb war ich sehr gespannt auf die AnkĂŒndigungen von Microsoft Entra, der integrierten Lösung fĂŒr IdentitĂ€ts- und Zugriffsmanagement, auf der Ignite 2023 Konferenz. Nun möchte ich mit einer zeitlichen Verzögerung endlich ĂŒber meine persönlichen Highlights berichten.

Was ist Microsoft Entra?

Microsoft Entra bietet eine Reihe von Funktionen, die den sicheren Zugriff auf alle Anwendungen und Ressourcen fĂŒr alle Benutzer und GerĂ€te ermöglichen, die sich von ĂŒberall aus verbinden. Dabei werden die Prinzipien des Zero Trust Ansatzes verfolgt, der auf der Verifizierung von IdentitĂ€t, GerĂ€t, Anwendung und Netzwerk basiert, bevor der Zugriff gewĂ€hrt wird.

Einige der Highlights, die mich besonders beeindruckt haben, sind:

  • Security Service Edge (SSE): Dies ist eine neue Lösung, die Microsoft Entra Internet Access und Microsoft Entra Private Access umfasst. Microsoft Entra Internet Access ist ein identitĂ€tszentriertes Secure Web Gateway (SWG), welches den Zugriff auf alle Internetanwendungen und -ressourcen mit bedingtem Zugriff und Web-Inhaltsfilterung sichert. Microsoft Entra Private Access ist ein identitĂ€tszentriertes Zero Trust Network Access (ZTNA), das den Zugriff auf alle privaten Anwendungen und Ressourcen mit bedingtem Zugriff und modernen Authentifizierungsmethoden sichert. Beide Lösungen arbeiten mit dem bestehenden Sicherheits- und Netzwerkstack von Microsoft und einem offenen Partnernetzwerk zusammen, um eine nahtlose Integration zu gewĂ€hrleisten.
  • Microsoft Security Copilot: Dies ist ein neuer digitaler Assistent, welcher in das Microsoft Entra Admin Center eingebettet ist und den Administratoren hilft, hĂ€ufige Aufgaben zu automatisieren, schneller zu beheben, komplexe Richtlinien zu interpretieren und Workflows zu entwerfen. Der Security Copilot beantwortet einfache Fragen, was eine bedingte Zugriffsrichtlinie macht oder warum die mehrstufige Authentifizierung (MFA) ausgelöst wurde. Der Security Copilot bietet auch eine Risikozusammenfassung, Abhilfemaßnahmen und empfohlene Anleitungen fĂŒr gefĂ€hrdete IdentitĂ€ten, um das schnelle Reagieren auf IdentitĂ€tsrisiken zu erleichtern. Ich kann also einfach meinen digitalen Assistenten Fragen stellen und dieser analysiert die notwendigen Anmeldelogs, bereitet diese auf und liefert mir eine passende Antwort.
  • Phishing-resistente Authentifizierungsmethoden: Microsoft Entra unterstĂŒtzt verschiedene MFA-Methoden, um die Authentifizierung vor Phishing zu schĂŒtzen. Dazu gehören zum Beispiel FIDO2 Security Keys, Windows Hello for Business, Microsoft Entra Certificate-Based Authentication (CBA) und Passkeys. Alle diese Methoden ermöglichen es, Passwörter ganz zu eliminieren, so dass sie nicht erraten, abgefangen oder gephished werden können. Microsoft Entra CBA ermöglicht es, Authentifizierungsrichtlinien nach Zertifikat, Ressourcentyp und Benutzergruppe anzupassen. Passkeys sind eine neue Funktion, welche mit Windows 11 eingefĂŒhrt wurde und es ermöglicht, sich mit dem Gesicht, dem Fingerabdruck oder der PIN des GerĂ€ts bei einer Website, Anwendung oder einem Dienst anzumelden, fĂŒr den man einen Passkey erstellt hat. Microsoft Entra ID-Benutzer werden bald in der Lage sein, sich mit Passkeys anzumelden, die aus der Microsoft Authenticator App verwaltet werden. Ein aus meiner Sicht wichtiger Schritt, um die Notwendigkeit von Kennwörtern endgĂŒltig abzuschaffen.
  • Microsoft Entra Permissions Management: Dies ist eine Lösung, die Einblicke in die Berechtigungsrisiken bietet. Es gibt zwei wichtige Integrationen, die mir aufgefallen sind. Die erste ist die Integration mit Microsoft Defender for Cloud (MDC), diese ermöglicht es, IdentitĂ€ts- und Zugriffsberechtigungsinformationen mit anderen Cloud-Sicherheitsinformationen in einer einzigen Schnittstelle zu konsolidieren. Diese Ansicht zeigt handlungsorientierte Empfehlungen zur Behebung von Berechtigungsrisiken sowie den Permissions Creep Index an und erleichtert die Durchsetzung des Least Privilege Zugriffs fĂŒr Cloud-Ressourcen ĂŒber Azure, Amazon Web Services (AWS) und Google Cloud hinweg. Die zweite Integration ermöglicht es ServiceNow-Kunden, zeitgebundene, bedarfsgesteuerte Berechtigungen fĂŒr Multicloud-Umgebungen (Azure, AWS, Google Cloud) ĂŒber das ServiceNow-Portal anzufordern. Diese beliebte IT-Service-Management (ITSM)-Lösung stĂ€rkt somit die Zero Trust-Haltung, indem sie Zugriffsberechtigungsanfragen zu bestehenden Genehmigungsworkflows in ServiceNow hinzufĂŒgt. Ein wichtiger Schritt Richtung herstellerunabhĂ€ngiger Zero-Trust Architektur.

Fazit

Ich bin beeindruckt von dem Umfang und der Tiefe der Funktionen, welche Microsoft Entra bietet, um den sicheren Zugriff auf alles und fĂŒr jeden zu ermöglichen. Ich glaube, dass diese Lösungen meinen Kunden helfen kann, ihre digitale Transformation voranzutreiben und gleichzeitig ihre Sicherheit zu erhöhen. Gerade die Integration von anderen Cloud Services wie AWS, Google oder Service-Now sind wichtige Schritte fĂŒr die Absicherung der IdentitĂ€ten.

Microsoft meldet neuen Angriff mit Azure AD Connect

In diesem Blogbeitrag möchte ich den Inhalt des Artikels https://practical365.com/mercury-attack-april-2023 auf Deutsch zusammenfassen.

Der Artikel beschreibt einen neuen Angriff, welcher Azure AD Connect ausnutzt, um sowohl On-Premises- als auch Cloud-Ressourcen zu kompromittieren.

Wer steckt hinter den Angriffen?

Der Angriff wurde von Microsoft Threat Intelligence aufgedeckt und wird zwei Gruppen zugeschrieben: MERCURY, einer mit der iranischen Regierung verbundenen Nation-State-Akteurin, und DEV-1084, einer Gruppe, welche von MERCURY beauftragt wurde, die Netzwerkzugriffe auszunutzen.

Wie begann der Angriff?

Bei Angriffen wie diesem hört man oft zwei Begriffe: Eskalation von Privilegien und Lateral Movement.

Lateral Movement klingt kompliziert, ist aber einfach: Der Begriff bedeutet nur, dass ein Angreifer ein GerĂ€t oder System in einem Netzwerk kompromittiert hat und dies als Sprungbrett oder Drehpunkt nutzt, um in andere GerĂ€te oder Systeme zu gelangen. Diese Bewegung kann sofort erfolgen, aber oft ist sie verzögert (wie in diesem Fall) – ein kluger Angreifer wird eindringen, eine Persistenz herstellen und dann eine Weile warten, das Zielnetzwerk studieren und jede offensichtliche Aktion vermeiden, welche die Verteidiger auf seine Anwesenheit aufmerksam machen könnte.

In diesem Fall begann der Angriff mit der Ausnutzung der bekannten log4j-Schwachstelle, um in das Netzwerk einzudringen und Persistenz zu erlangen. Die Angreifer bewegten sich dann durch das Netzwerk und griffen sowohl On-Premises- als auch Hybrid-Ressourcen an. FĂŒr die On-Premises-Angriffe nutzten sie Gruppenrichtlinienobjekte (GPOs), um Sicherheitstools (Endpoint Protection) zu stören und Ransomware ĂŒber die NETLOGON-Freigaben auf den Active Directory-DomĂ€nencontrollern zu verteilen. FĂŒr die Hybrid-Angriffe nutzten sie Azure AD Connect, um sich mit Azure AD zu synchronisieren und Zugriff auf Cloud-Ressourcen zu erhalten. Die Angreifer löschten anschließend Daten aus Azure Storage-Konten und Azure SQL-Datenbanken. Mit einem vernĂŒnftigen Tier-Modell wĂ€re der Angriff in diesem Ausmaß vermutlich nicht umsetzbar gewesen.

Microsoft empfiehlt dringend, Azure AD Connect zu ĂŒberprĂŒfen und sicherzustellen, dass es keine unbefugten oder verdĂ€chtigen Synchronisierungen gibt. Außerdem sollten die Sicherheitsmaßnahmen fĂŒr DomĂ€nencontroller und GPOs verstĂ€rkt werden, um Ă€hnliche Angriffe zu verhindern oder zu erkennen. Microsoft bietet verschiedene Sicherheitstools an, die bei der Untersuchung und Abwehr solcher Angriffe helfen können, wie z.B. Microsoft Defender for Endpoint, Microsoft 365 Defender und Azure Sentinel.

Dennoch zeigt dieser Angriff wieder, wie wichtig es ist, sowohl On-Premises- als auch Cloud-Umgebungen zu schĂŒtzen und zu ĂŒberwachen. Hybrid-Umgebungen bieten viele Vorteile, aber auch neue Herausforderungen und Risiken. Es ist daher unerlĂ€sslich, sich ĂŒber die aktuellen Bedrohungen zu informieren und die besten Praktiken fĂŒr die Sicherheit von Azure AD Connect zu befolgen. Zum Schutz gehört auch der Aufbau von Tier-Strukturen.

Wozu ist ein Azure AD Connect Server notwendig?

Azure AD Connect ist ein wichtiges Werkzeug fĂŒr die Synchronisation von IdentitĂ€ten zwischen lokalen Active Directory-DomĂ€nen und Azure Active Directory. Da der Azure AD Connect Zugriff auf die Anmeldeinformationen und Attribute aller Benutzer und Gruppen in den verbundenen DomĂ€nen hat, muss dieser Server entsprechend gut geschĂŒtzt werden. Daher sollten Sie den Azure AD Connect wie einen DomĂ€nencontroller behandeln und in Tier-0 aufnehmen.

Was bedeutet Tier-0?

Tier-0 ist die höchste Sicherheitsstufe in einem Active Directory-Design, das auf dem Prinzip der administrativen Grenzen basiert. Tier-0 umfasst alle Systeme und Konten, die in der Lage sind, Änderungen an der Active Directory-DomĂ€nenstruktur oder den Sicherheitsrichtlinien vorzunehmen. Diese sollten von anderen Tiers isoliert und mit strengen Zugriffs- und Überwachungsregeln versehen werden.

Indem der Azure AD Connect Server in Tier-0 aufgenommen wird, wird sichergestellt, dass nur berechtigte Administratoren darauf zugreifen können und dass alle AktivitĂ€ten auf dem Server protokolliert und ĂŒberprĂŒft werden. Dies reduziert das Risiko eines unbefugten Zugriffs oder einer Kompromittierung von Azure AD Connect.

Effektive Passwortrichtlinien fĂŒr Ihr Unternehmen mit FGPP: Tipps fĂŒr die erfolgreiche Umsetzung

Die „Fine-Grained Password Policies“ (FGPP) sind ein Feature von Active Directory (AD), das es Administratoren ermöglicht, die Passwortrichtlinien fĂŒr bestimmte Benutzer oder Benutzergruppen innerhalb einer DomĂ€ne zu konfigurieren. Mit FGPP können Administratoren unterschiedliche Passwortrichtlinien fĂŒr verschiedene Benutzergruppen definieren, anstatt eine einzige Passwortrichtlinie fĂŒr die gesamte DomĂ€ne zu verwenden.

FGPP ermöglicht es Administratoren, verschiedene Passwortrichtlinien auf der Grundlage von Attributen des Benutzers zu erstellen, z.B:

  • MindestlĂ€nge des Passworts
  • Verwendung von Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen
  • Passwortdauer und Anzahl der erlaubten PasswortĂ€nderungen
  • Passworthistorie

Diese Funktion kann helfen die Sicherheit zu erhöhen, da es ermöglicht die Passwortrichtlinien entsprechend dem Risiko der Benutzer oder Gruppen anzupassen. Zum Beispiel kann fĂŒr administrative Accounts eine höhere PasswortkomplexitĂ€t erforderlich sein als fĂŒr normale Benutzer.

Es ist wichtig, dass Passwortrichtlinien regelmĂ€ĂŸig ĂŒberprĂŒft und angepasst werden, um sicherzustellen, dass sie den aktuellen SicherheitsbedĂŒrfnissen entsprechen und die Sicherheit nicht beeintrĂ€chtigt wird.

Im Zusammenhang mit der AD Tiering Struktur können so fĂŒr die unterschiedlichen Tiers verschiedene Kennwortrichtlinien angewendet werden.

Im Folgenden werden wir eine typische Empfehlung umsetzen:

Alles, was wir hierzu benötigen, ist eine Powershell samt Active Directory Module.

Erstellung einer „PSO 190 days“ Richtlinie fĂŒr Service-Accounts:

New-ADFineGrainedPasswordPolicy -Name "PSO 190 days" -Precedence 500 -ComplexityEnabled $true -Description "Password Policy for service accounts 190 days" -DisplayName "PSO 190 days service accounts" -LockoutDuration "0.12:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 2 -MaxPasswordAge "190.00:00:0" -MinPasswordAge "1.00:00:00" -MinPasswordLength 15 -PasswordHistoryCount 5 -ReversibleEncryptionEnabled $false

Erstellung einer „PSO 180 days“ Richtlinie fĂŒr normale Benutzer:

New-ADFineGrainedPasswordPolicy -Name "PSO 180 days" -Precedence 500 -ComplexityEnabled $true -Description "Password Policy for Office Users 180 days" -DisplayName "PSO 180 days Office Users" -LockoutDuration "0.00:30:00" -LockoutObservervationWindow "0.00:15:00" -LockoutThreshold 5 -MaxPasswordAge "180.00:00:0" -MinPasswordAge "1.00:00:00" -MinPasswordLenght 10 -PasswordHistoryCount 5 -ReversibleEncryptionEnabled $false

Erstellung einer „PSO 90 days“ Richtlinie fĂŒr T-0 sowie T-1 Administratoren:

New-ADFineGrainedPasswordPolicy -Name "PSO 90 days" -Precedence 500 -ComplexityEnabled $true -Description "Password Policy for administrative Users 90 days" -DisplayName "PSO 90 days administrative Users" -LockoutDuration "0.12:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 5 -MaxPasswordAge "90.00:00:0" -MinPasswordAge "1.00:00:00" -MinPasswordLength 12 -PasswordHistoryCount 5 -ReversibleEncryptionEnabled $false

Die Zuweisung der einzelnen Richtlinien erfolgt ĂŒber Gruppenmitgliedschaften. Hierzu erstellen wir 3 globale Gruppen im AD.

Globale Gruppen

Nun verknĂŒpfen wir die Richtlinien mit den neuen globalen Gruppen:

Add-ADFineGrainedPasswordPolicySubject "PSO 180 days" -Subjects k_PSO_180days
 
Add-ADFineGrainedPasswordPolicySubject "PSO 90 days" -Subjects k_PSO_90days
 
Add-ADFineGrainedPasswordPolicySubject "PSO 190 days" -Subjects k_PSO_190days

Nun ordnen wir sĂ€mtlichen Benutzeraccounts eine Richtlinie zu. Hierzu nehmen wir den Benutzer Julian.Schuetz mit in die Gruppe „k_PSO_180days“ mit auf. Den Benutzer T0-pad-jschuetz nehmen wir in die Gruppe „k_PSO_90days“ mit auf. Und den Service-Account T1-SVC-Sophos, Sie ahnen es sicherlich schon, nehmen wir in die Gruppe „k_PSO_190days“ mit auf.

Mit dem folgenden Befehl können wir nun die Anwendung der neuen Kennwortrichtlinie validieren:

Get-ADUserResultantPasswordPolicy -Identity julian.schuetz

Es empfiehlt sich fĂŒr sĂ€mtliche Service-Accounts ein Verzeichnis zu pflegen:

#Service AccountSOPInterval
1KRBTGTPWChange_KRBTGT.docxAlle 3 Monate
2AzureadssoaccPWCHange_AzureADCCOACC.docx Alle 30 Tage
3T1-SVC-SophosPWCHange_T1-SVC-Sophos.docxk_PSO_190days
4ErgĂ€nzen und Pflegen Â 
Service-Account Verzeichnis

Der Vorteil liegt auf der Hand, durch die Pflege von einem Verzeichnis, können regelmĂ€ĂŸige KennwortĂ€nderungen fĂŒr die Service-Accounts in den Administratoren Alltag leicht integriert werden. Jede Applikation erhĂ€lt somit einen eigenstĂ€ndigen Account und eine passende Anleitung fĂŒr den regelmĂ€ĂŸigen Kennwortwechsel.

FĂŒr die kritischen Administratoren Gruppen im Active Directory sollten Break Glass Accounts eingerichtet. Die Passwörter fĂŒr diese Accounts sind entsprechend lang und schĂŒtzenswert und mĂŒssen ebenfalls in regelmĂ€ĂŸigen AbstĂ€nden geĂ€ndert werden.

AD Tiering Struktur – Funktion und Nutzen

In diesem Artikel wollen wir euch das Thema Tiering nĂ€herbringen. GrundsĂ€tzlich fĂ€llt dieses Thema in den Bereich des Active Directory Hardenings. Allerdings besteht die EinfĂŒhrung dieses Modells nicht nur aus der technischen Umsetzung. Viel wichtiger ist es, den Administratoren der Systeme, den richtig Umgang mit der neuen Struktur aufzuzeigen und diese zu verinnerlichen.

Aber erstmal zurĂŒck zum Anfang. Die erste Frage, die sich viele stellen ist:

Was ist ĂŒberhaupt ein Tiering Modell?

Das Tiering oder auch ESAE (Enhanced Security Admin Environment) wird genutzt, um die administrative Architektur einer DomĂ€ne abzusichern. Durch eine Trennung der administrativen Konten und den Systemen in unterschiedliche „Schutzbereiche“, können Angriffe auf die interne Struktur reduziert bzw. deutlich erschwert werden.

Man trennt die vorhandene Struktur in drei Tiering Zonen sowie einen Benutzerbereich auf.

Jedes dieser Tiers bekommt eigene Administratoren. Wie auf dem Bild zu sehen, bekommt der jeweilige Admin nur Zugriff auf den ihm zugeteilten Bereich. Ein Zugriff auf eines der anderen Tiers ist nicht erlaubt.

Wie bereits oben erwĂ€hnt, handelt es sich bei den Tiering Benutzern um rein administrative Konten. Mit den Benutzern darf also nicht im normalen TagesgeschĂ€ft gearbeitet werden. Sie sind rein fĂŒr administrative TĂ€tigkeiten gedacht.

Gearbeitet werden sollte mit diesen Benutzern ĂŒber eine sogenannte PAW (Priviliged Access Workstation). Eine genauere ErklĂ€rung dazu gibt es in einem bald folgenden Blog-Artikel zum Thema  PAW.

Da wir nun schon einmal grob erklĂ€rt haben, um was es sich beim Tiering Modell handelt, stellt sich nun natĂŒrlich direkt die nĂ€chste Frage.

Warum benötige ich ein Tiering Modell?

Nun, auf diese Frage gibt es eigentlich eine sehr einfache Antwort:

MEHR SICHERHEIT!

Grade die letzten Jahre haben gezeigt, dass kein Unternehmen vor Cyberangriffen sicher ist. Ich denke, jeder hat schon von mindestens einer Firma gehört, die Opfer einer Cyberattacke war. Sei es VerschlĂŒsselungen, Datendiebstahl oder eine der anderen Attacken.

Wir mĂŒssen also versuchen, die eigene Infrastruktur so sicher wie möglich bzw. es dem Angreifer so schwer wie möglich zu machen, die Infrastruktur zu „infiltrieren“. Durch die Trennung in die drei Sicherheitsbereiche wollen wir eine komplette Kompromittierung der DomĂ€ne verhindern. Bei einem sauber eingerichteten und von den Mitarbeitern korrekt genutzten Tiering Modell, kann ein Angriff deutlich eingegrenzt werden. Denn selbst wenn ein Angreifer an ein administratives Kennwort gelangen könnte, hat er dadurch nicht die Möglichkeit sich in dem nĂ€chsthöheren Tier zu bewegen.

ErklÀren wir das mal an einem Beispiel:

Ohne Tiering:

Benutzer A hat sich auf seinem Client einen Trojaner oder Ă€hnliches eingefangen. Er meldet sich beim IT-Support. Dieser schaltet sich nun mit seinem Administrator auf diesem Client auf. Da der Angreifer den Client des Benutzers bereits kompromittiert hat, ist es fĂŒr ihn nun ein Leichtes an die Anmeldedaten des aufgeschalteten Admin-Benutzers zu gelangen, da diese als Hash-Wert auf dem Client gespeichert werden.

Mit den abgegriffenen Anmeldedaten des Support-Mitarbeiters (meistens ebenfalls DomĂ€nen-Administrator) hat der Angreifer nun die Möglichkeit, tiefer ins System vorzudringen und im schlimmsten Fall bis zu einem DomĂ€nencontroller zu gelangen. Sollte er Zugriff auf diesen erhalten, kann er sich nun frei in der DomĂ€ne bewegen, ohne dass es jemand mitkriegen wĂŒrde.

Somit wĂ€re die komplette DomĂ€ne kompromittiert und mĂŒsste im schlimmsten Fall komplett neu aufgesetzt werden. Auch eine komplette VerschlĂŒsselung aller Systeme ist dadurch möglich, da der Angreifer kompletten Zugriff auf sĂ€mtliche Ressourcen hĂ€tte.

Mit eingerichtetem Tiering:

Im gleichen Szenario wie oben beschrieben hĂ€tte der Angreifer keine Chance weiter in die DomĂ€ne vorzudringen. Sollte sich im gleichen Beispiel ein Support Mitarbeiter mit seinen eigens fĂŒr die Client- Administration (z.B. T2-Mustermann) angelegten Benutzer anmelden und der Angreifer ebenfalls die Anmeldedaten abgreifen, kann er sich maximal auf Clientebene bewegen. Er hat aber durch die Trennung in die unterschiedlichen Tiering Bereiche, keine Möglichkeiten, sich auf Anwendungs-server oder im schlimmsten Falle, DomĂ€nencontroller fortzubewegen.

Wie gehe ich vor, wenn ich ein Tiering einfĂŒhren möchte?

Hier gibt es keine einfache Antwort. GrundsĂ€tzlich kann ein Tiering Modell von jedem in Betrieb genommen werden. Es mĂŒssen die benötigten Active Directory Anpassungen durchgefĂŒhrt werden, die zugehörigen Benutzer erstellt und per Gruppenrichtlinien die nötigen EinschrĂ€nkungen ausgerollt werden.

Beispiel einer einfache Tiering OU Struktur:

Das Wichtigste bei der Inbetriebnahme eines solchen Modells ist es aber, die zukĂŒnftigen Nutzer des Tiering Modells in die neue Arbeitsweise einzuarbeiten und den Nutzen zu verdeutlichen. Denn nur wenn sich sĂ€mtliche Mitarbeiter mit administrativen Konten an die neuen Regeln halten, kann man die Sicherheit der eigenen Infrastruktur erhöht werden.

Auch sollten vorher sÀmtliche Zugriffe auf die Systeme geklÀrt werden, denn es sollten auch die diejenigen einen T0 Administrator bekommen, die wirklich Zugriff auf T0 Systeme benötigen. Bei den administrativen Benutzern gilt:

So wenig wie möglich, so viel wie nötig.

Um die Nutzer zu erstellen und zu wissen, worauf sie Zugriff benötigen, gibt es natĂŒrlich eine weitere HĂŒrde. Welches System gehört in welches Tier? HierfĂŒr haben wir ein grobes Entscheidung-Diagramm erstellt.

Wie bereits erwĂ€hnt, handelt es sich hierbei nur um eine sehr grobe Auswahlhilfe. Jedoch kann es dabei helfen, eine erste Unterteilung seiner Systeme durchzufĂŒhren.


Fazit

Ich hoffe, wir konnten euch ein wenig fĂŒr das Thema Tiering sensibilisieren. GrundsĂ€tzlich kann man durch die EinfĂŒhrung eines neuen administrativen Konzeptes die Sicherheit im eigenen Unternehmen deutlich erhöhen. Jedoch darf man nie vergessen, dass sĂ€mtliche Änderungen nur dann funktionieren können, wenn die Mitarbeitenden das Konzept unterstĂŒtzen und mittragen.

Bevor sich jemand dazu entscheidet, ein Tiering bei sich einzufĂŒhren, besprecht es bitte mit allen Administratoren und klĂ€rt, ob sie dafĂŒr bereit sind die Idee mit umzusetzen. Denn das beste Konzept hilft nichts, wenn es Benutzer gibt, die es umgehen bzw. boykottieren.

Die Erfahrung zeigt aber, dass nach einer sachlichen Einweisung der IT-Mitarbeiter und der Beantwortung aller Fragen, kaum noch „Gegenwind“ herrscht.

Cookie Consent mit Real Cookie Banner