Kennwortrichtlinien im Active Directory. Ein Missverständnis mit Folgen

Das Problem

In unserer täglichen Arbeit fällt uns ein weitverbreitetes Missverständnis im Umgang mit Kennwortrichtlinien im Active Directory auf. Hier möchten wir kurz für Klarheit sorgen.

Die Standard-Kennwortrichtlinie wird immer in der Default Domain Policy definiert. Diese ist mit der Domäne verknüpft, gilt somit für alle Benutzerobjekte in der ganzen Domäne.

Es ist grundsätzlich eine gute Idee, abgestufte Kennwortrichtlinien für verschieden privilegierte Benutzertypen durchzusetzen. Nur ist das oft erwartete GPO-Verhalten hier der Ursprung des Missverständnisses. Verknüpfe ich ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) mit einer Organisationseinheit (Organizational Unit, OU), dann wirken dessen Einstellungen nicht mehr domänenweit, sondern nur auf die Objekte in dieser OU. Die Annahme ist nun häufig, dass sich ein Benutzerkreis mit Objekten in einer OU so mit anderen Kennwortrichtlinien versehen lässt. Denn die Einstellungen eines mit einer OU verknüpften GPO überschreiben im Normalfall Einstellungen, die aus der Domäne nach unten vererbt werden.

Konkret wird also häufig folgendes konfiguriert: Administrative Konten werden in einer OU versammelt und mit dieser ein neues GPO, nennen wir es „KWRL-Admins“, verknüpft. Schauen wir uns das Verhalten kurz an. In der Laborumgebung haben wir in der Default Domain Policy eine Mindest-Kennwortlänge von vier Zeichen festgelegt. Das GPO „KWRL-Admins“ an einer OU „Admins“ verlangt fünf Zeichen.

Wir nehmen nun einen Benutzer in der OU und setzen dessen Kennwort auf eines mit vier Zeichen zurück. Wir erfüllen also die Default Domain Policy, nicht aber die „KWRL-Admins“. Was passiert?

Wir sehen also, dass die Kennwortrichtlinie aus dem GPO „KWRL-Admins“ keine Rolle spielt. Es bleibt bei der Grundregel: Kennworteinstellungen gelten immer domänenweit. Das oft gewählte Vorgehen, auch die Kennwörter mittels eines GPO an einer OU zu lösen, funktioniert nicht.

Die Folge des Missverständnisses ist also, dass Richtlinien im fehlgeleiteten Verständnis und guter Absicht erstellt werden, diese aber nie wirken. Weiterer Rat sollte also sein, erstellte GPO immer auf die gewünschte Wirksamkeit zu überprüfen.

Tatsächlich ist das GPO nicht nutzlos – nur bezieht es sich nicht auf Benutzerobjekte innerhalb der OU – es wirkt auf Computerobjekte in der entsprechenden OU und bestimmt dann Kennwortrichtlinien für deren lokale Benutzer. Wir verschieben also ein Computerobjekt in die OU und setzen das Kennwort eines lokalen Benutzers neu – und zwar so, dass es das GPO „KWRL-Admins“ erfüllt:

Es lässt sich zudem beobachten, dass die vom GPO vorgegeben Werte für die lokale GPO des Computers übernommen wurden:

Die Lösung

Wie aber lösen wir jetzt das Dilemma, unterschiedliche Kennwortrichtlinien für verschiedene Benutzergruppen durchzusetzen? HiSolutions empfiehlt (Stand 2025) für eingeschränkte Benutzer eine Mindestlänge von zwölf, für administrative Benutzer eine Mindestlänge von 16 und für Dienstkonten eine Mindestlänge von 24 Zeichen.

Die Lösung heißt: Finegrained Password Policies (FGPP)! Diese basieren auf einem sog. Password Setting Object (PSO) und sind bereits seit Server 2008 verfügbar. FGPP überschreiben die Einstellungen der Default Domain Policy und werden an Gruppen gebunden.

Dementsprechend könnte das Vorgehen sein, die Einstellungen für eingeschränkte Benutzerkonten weiterhin über die Default Domain Policy zu realisieren. Dann legt man Gruppen für administrative Konten und Dienstkonten an und schreibt für diese geeignete FGPP nach folgendem Muster. Entweder erledigt man das im GUI im Active-Directory-Verwaltungscenter oder über die PowerShell.

Fazit:

  1. Die Kennwortrichtlinien aus der Default Domain Policy gelten immer domänenweit.
  2. Kennwortrichtlinien aus GPO an OU wirken nicht auf die darin enthaltenen Domänenbenutzer, sondern nur auf darin enthaltene Computer und deren lokale Benutzer.
  3. Verschiedene Kennwortrichtlinien für verschiedene Benutzergruppen werden über Finegrained Password Policies realisiert.

Blitze-Wolke

HAFNIUM-Schwachstellen: Office 365/Microsoft 365/AD FS indirekt auch bedroht

[GTranslate]

Von Inés Atug, Markus Drenger und Daniel Jedecke.

Nach der Veröffentlichung des Out-of-Band-Patches für die als HAFNIUM bekannt gewordenen Schwachstellen in Exchange Servern haben viele Admins, die zuvor eine Migration nach Office 365 (jetzt Microsoft 365) durchgeführt hatten, aufgeatmet. Denn Microsoft zufolge ist Exchange Online von Hafnium nicht betroffen. Hiermit meint der Hersteller jedoch das Produkt an sich: Exchange Online ist weiterhin nicht direkt angreifbar. Aber Vorsicht: Es kann je nach Aufbau dennoch möglich sein, dass Angreifer auf den Cloud-Dienst durchgreifen können. 

In vielen Fällen ist in Unternehmen ein hybrider Aufbau etabliert, bei dem ein Exchange-Server weiterhin lokal betrieben wird. Sollte dieser Exchange-Server die HAFNIUM-Schwachstellen aufweisen, könnten Angreifer hierüber Zugriff auf das lokale Netzwerk erhalten (siehe Abbildung Schritt (1)) und sich dann über Lateral Movement im Netz weiterbewegen (Schritt (2)). Mittelbares Ziel des Angriffs ist in der Regel der Zugriff auf ein hochwertiges System wie beispielsweise das Active Directory oder die Active Directory Federation Services (AD FS) zu. Bei Zugriff auf letzteren können die Angreifer unter Umständen den geheimen Schlüssel entwenden (Schritt (3)), sich damit als jeder beliebige legitime Nutzer in der Cloud ausgeben (Schritt (4)) und somit Zugriff (lesen, verändern, löschen) auf alle in der Cloud gespeicherten Daten bekommen (Schritt (5)).

Angriff auf die Cloud/ADFS via HAFNIUM/ProxyLogon

Ob und wie leicht dies möglich ist, hängt stark davon ab, wie der lokale Aufbau umgesetzt ist. Wir erleben im Bereich der Forensik und Beratung hier gute wie auch ungünstige Umsetzungen. Prinzipiell sollte das Ziel immer sein, Lateral Movement in der On-Premise-Umgebung wie auch in der Cloud zu minimieren. Hierfür gibt es bewährte Verfahren, welche sich bei geeigneter Konfiguration dazu eignen, die Bewegungen der Angreifer im Netz zu erschweren:

  • Frühzeitiges Patchen von Sicherheitslücken: Die wichtigste Maßnahme, die auch bei Hafnium eine Kompromittierung mit hoher Wahrscheinlichkeit unterbunden hätte, ist das schnelle Patchen der Systeme. Hier herrscht bisweilen noch der Irrglaube, dass kritische Sicherheitslücken innerhalb von 30 Tagen zu patchen seien. Dies wurde und wird teilweise sogar noch von IT-Sicherheitsstandards vorgeschlagen. Sicherheitslücken, die mittels Fernzugriff automatisiert und unauthentifiziert ausgenutzt werden können, so wie dies bei Hafnium der Fall ist, zeigen jedoch deutlich, dass hier möglichst innerhalb von Stunden anstatt Tagen gepatcht werden sollte.
  • Administrative Trennung von Active Directory und Exchange Server: Eine weitere Maßnahme, die lokal umgesetzt werden sollte, ist die administrative Trennung zwischen Active Directory und Exchange. Oft sind die Systeme über Jahre gewachsen und eng miteinander verbunden. So trennt die Angreifer nach erfolgreicher Kompromittierung oft nur ein Powershell Kommando von der AD-Übernahme. Hier ist es wichtig, die 2017 von Microsoft im Rahmen der Konferenzen Blue Hat und Black Hat vorgestellten Probleme zu mitigieren. Hierfür eignet sich Split-Permissions (https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help und https://docs.microsoft.com/de-de/exchange/permissions/split-permissions/configure-exchange-for-split-permissions?view=exchserver-2019). Eine weitere Maßnahme ist die Verwendung der Local Administrator Password Solution (LAPS) von Microsoft. Hierbei wird auf jedem Host ein separates Admin-Passwort gesetzt, um so das Springen nach einem erfolgreichen Angriff (beispielsweise mittels Pass-the-Hash-Angriffsarten) zu erschweren.
  • Umsetzen des Konzepts administrativer Zonen: Da AD FS das Sprungbrett in die Cloud Welt ist, sollte dieser Zugang besonders gesichert werden. Hierzu empfiehlt Microsoft seit längeren einen Aufbau, in dem verschiedene administrative Sicherheitszonen (engl. tiers) voneinander getrennt werden sollten. Ein entsprechend gesicherter Exchange Server würde hier in Zone 1 stehen und ein Active Directory in Zone 0. Ein Sprung zwischen diesen Zonen soll mit den umzusetzenden Maßnahmen stark erschwert werden. Für den AD FS empfiehlt Microsoft ebenfalls den Aufbau in der Zone 0 (https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs).
  • Multifaktorauthentifizierung: Sowohl in der Cloud als auch in der lokalen IT-Umgebung sollten administrative Zugriffe mittels starker Multifaktorauthentifizierung abgesichert werden.
  • Protokollierung und Monitoring: Damit ein unberechtigter Zugriff möglichst schnell bemerkt wird, sollte ein feinmaschiges Monitoring- und Protokollierungskonzept etabliert sein. Insbesondere in der Cloud-Umgebung gehört das Monitoring neben der Zugriffssteuerung zu den wichtigsten Sicherheitsmaßnahmen. 
  • Datenklassifizierung: Sollte es doch zu einem Einbruch gekommen sein und die Angreifer möchten Daten exportieren, dann sollte mittels der Datenklassifizierung Sicherheitsmaßnahmen greifen, die zumindest die als vertraulich oder streng vertraulich klassifizierten Daten außerhalb der Cloud und des Kundennetzwerks unlesbar darstellen. 
  • Datensicherung: Sollte es zu einem Einbruch gekommen sein und es werden die Daten mittels Ransomware verschlüsselt, dann sollte man auf eine unveränderbare extern gespeicherte Datensicherung zurückgreifen können.

Die obigen Ausführungen zeigen, dass ein ganzheitliches und aktuelles Sicherheitskonzept notwendig ist, um möglichen Sicherheitslücken umfassend entgegenzuwirken. Überprüfen Sie daher regelmäßig Ihre Sicherheitsmaßnahmen und passen Sie diese ggfs. an geänderte Anforderungen an. Insbesondere, wenn Sie lokale Dienste von außen erreichbar konfigurieren oder Cloud-Dienste mit der lokalen IT-Umgebung koppeln, sollten das Sicherheitskonzept überprüft und nachgeschärft werden. Sprechen Sie uns gerne dazu an!