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