Active Directory Sicherheit Teil 1: Privilegierte Benutzer

Willkommen in meiner neuen Serie Active Directory Sicherheit. In den folgenden Beiträge beschäftige ich mich mit Maßnahmen zu Sicherheit des Active Directory und lege dementsprechend auch den Focus ausschließlich darauf – quasi mit aufgesetzter „AD-Brille“.

Teil 1 meiner Serie Active Directory Sicherheit beschäftigt sich mit dem Thema „Privilegierte Benutzer“, sowohl mit den tatsächlichen Mitarbeitern (Administratoren), als auch mit den Active Directory User Accounts dieser Personen.

Trennung von unprivilegiertem Account, privilegiertem Account und hoch privilegiertem Account

In der Regel sollte für Domain Administratoren zwischen 3 Arten von Benutzerkonten unterschieden werden:

  1. Der unprivilegierte Account: Mit diesem Account ist ein Admin normalerweise an seiner physischen Arbeitsstation angemeldet. Der Account hat keine privilegierten Rechte sondern dient wie bei jedem anderen Mitarbeiter der täglichen Büroarbeit, sprich: er hat eine Mailbox, hat sein Office Programm und sonstige Standardsoftware.
  2. Der privilegierte Account: Mit diesem Account werden alltägliche Admin-Tätigkeiten durchgeführt, z.B. Administration einzelner Server, Arbeitsstationen oder Services – je nach Aufgabengebiet.
  3. Der hoch privilegierte Account: Dieser Account dient ausschließlich zu administrativen Zwecken im AD selbst. Nur dieser Account ist Mitglied der Domain Admins Gruppe und kann die Domain administrieren.

Bereits in der AD Struktur sind die unprivilegierten Accounts von den privilegierten Accounts hierarchisch strikt zu trennen.

Sicherheitseinstellungen für die AD User Objekte der Administratoren

Gruppen des Containers Builtin

Die Nutzung von Builtin Gruppen für privilegierte Accounts sollte vermieden werden, hauptsächlich da die Builtin Gruppen einerseits bereits über hohe Privilegien verfügen – so haben z.B. die Account Operators Schreibrechte/Änderungsrechte auf alle User und Group Objekte (inkl. der Domain Admins, Enterprise Admins und Schema Admins Gruppen!) – und andererseits, da sich viele Administratoren über die Rechte von Builtin Gruppen gar nicht erst bewusst sind.

Statt dessen ist ein granulares, aber übersichtliches Rollen-basiertes Admin-Konzept mit eigenen Gruppen nach dem Least-Privilege Prinzip zu verwenden.

Einstellungen für privilegierte und hoch privilegierte Accounts

  • Aktivieren der Option Account is sensitive an cannot be delegated – eine Anleitung, wie man das für alle betroffenen Accounts scripten kann, findet ihr hier.
  • Aktivieren der Option Smart card is required for interactive logon – diese Option ist letztlich eine Frage der Unternehmensgröße, des Sicherheitsbedarfs und des Budgets; nicht jedes Unternehmen kann es sich leisten, eine Smart Card Infrastruktur zu betreiben
  • Hinzufügen aller privilegierten Accounts zur Gruppe Protected Users

Einstellungen für Gruppen mit privilegierten Accounts (Role-based Admin Gruppen)

  • Beschränkung der Gruppen mit privilegierten Accounts per GPO auf Member Servern und/oder Member Clients mit dem Ziel, dass sich ein privilegierter Account ausschließlich lokal über ein Konsolen Login an Member Servern und/oder Member Clients anmelden kann:
    • Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments\
      • Deny access to this computer from the network
      • Deny log on as a batch job
      • Deny log on as a service
      • Deny log on through Remote Desktop Services
  • Beschränkung der Gruppen mit privilegierten Accounts per GPO auf Domain Controllern mit dem Ziel, dass sich ein privilegierter Account überhaupt nicht mehr an Domain Controllern anmelden kann:
    • Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments\
      • Deny access to this computer from the network
      • Deny log on locally
      • Deny log on as a batch job
      • Deny log on as a service
      • Deny log on through Remote Desktop Services

Die Einstellungen in Bezug auf Netzwerkzugang und RDP zu Member Servern und Member Clients machen natürlich nur dann Sinn, wenn ein externes Remote Access Tool zur Verfügung steht. Wird Remote Assistance für die Benutzerunterstützung verwendet, macht es natürlich keinen Sinn, RDP für den Support Staff zu sperren. Gleiches gilt für Server Admins, wenn die Server per RDP verwaltet werden.

Einstellungen für Gruppen mit hoch privilegierte Accounts (Enterprise Admins / Domain Admins / Schema Admins)

  • Reduzierung der Gruppenmitglieder
    • Enterprise Admins: Die Gruppe sollte im besten Fall keine Mitglieder haben. Ein Mitglied sollte lediglich bei Bedarf und zeitlich begrenzt hinzugefügt werden.
    • Domain Admins: Die Gruppe sollte im besten Fall lediglich den Built-in Administrator beinhalten. Werden zusätzliche hoch privilegierte Accounts hinzugefügt, sollte deren Anzahl so minimal wie möglich gehalten werden.
    • Schema Admins: Die Gruppe sollte im besten Fall keine Mitglieder haben. Ein Mitglied sollte lediglich bei Bedarf und zeitlich begrenzt hinzugefügt werden.
  • Beschränkung der Gruppen mit hoch privilegierten Accounts per GPO auf Member Servern und Member Clients mit dem Ziel, dass sich ein hoch privilegierter Account überhaupt nicht an einem Member Server und Member Client anmelden kann:
    • Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments\
      • Deny access to this computer from the network
      • Deny log on locally
      • Deny log on as a batch job
      • Deny log on as a service
      • Deny log on through Remote Desktop Services
  • Beschränkung der Gruppen mit hoch privilegierten Accounts per GPO auf Domain Controllern mit dem Ziel, dass sich ein hoch privilegierter Account ausschließlich lokal über ein Konsolen Login anmelden kann:
    • Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments\
      • Deny access to this computer from the network
      • Deny log on as a batch job
      • Deny log on as a service
      • Deny log on through Remote Desktop Services

Bei hoch privilegierten Benutzern sollte selbst dann Netzwerkzugriff und RDP gesperrt sein, wenn kein alternatives Remote Access Tool zur Verfügung steht. Zugriff auf Domain Controller sollte immer per Konsole erfolgen, entweder durch IPMI Interfaces bei physikalischen DCs oder mit den Konsolen der  Hypervisor bei VMs.

Passwort Policy

Für privilegierte und hoch privilegierte Accounts sollte ein eigenes Fine-grained Password Policy Object angelegt werden. Eine Anleitung dazu findet ihr hier und wie man dafür sorgt, dass das Objekt allen neu angelegten Accounts automatisch per Shadow Group zugewiesen wird, findet ihr hier.

Wichtig sind bei der Passwort Strategie folgende Überlegungen:

Länge sticht Komplexität. Wer es nicht glaubt, hier nochmal deutlich: einem Angreifer ist die Komplexität egal. Warum? In der Regel arbeitet ein Angreifer (zumindest im ersten Schritt) nicht mit dem Passwort selbst, sondern mit dessen Hashes. Das Reverse Engineering eines Hashes ist schwieriger und dauert länger, je länger das Passwort ist und nicht je komplexer. Ein guter Angreifer mit halbwegs vernünftiger Hardware hat ein 8-stelliges Passwort bereits nach weniger als einem halben Tag geknackt. Bei einem 14-stelligen Passwort erhöht sich das schon ca. um den Faktor 900! Kein Angreifer ist so ausdauernd, denn bis er dann das Passwort geknackt hat, ist es schon lange geändert worden.

Das führt gleich zur zweiten Überlegung: Passwortalter

Was bewirkt es, wenn ein Admin sein Passwort alle 30 Tage ändern muss? Auch Admins sind Menschen und bei permanenten Passwort-Änderungen ist das Resultat, dass die Passwörter entweder für alle  Accounts (ggf. nicht nur die AD Accounts) gleich sind oder immer das gleiche Passwort verwendet wird und nur am Ende eine Zahl hochgezählt wird. Und im schlimmsten Fall wird’s auf einem Zettel unter der Tastatur aufbewahrt.
Wird durch die Länge des Passworts jedoch dafür gesorgt, dass ein Angreifer länger dazu benötigt das Passwort zu ermitteln, als der Änderungszeitraum selbst ist, führt diese Erkenntnis folglich zu dem Ergebnis, dass je länger das Passwort ist, desto größer kann auch das Passwortalter sein. Ein kleineres Passwortalter für privilegierte Accounts im Vergleich zu unprivilegierten Accounts bringt somit keinen Sicherheitsgewinn. Das Passwortalter kann hier sogar größer sein, da auch die Passwortlänge größer ist, als bei einem unprivilegierten Account. Und im Falle einer Kompromitierung ist das Passwort sowieso sofort zu ändern.

Daraus resultiert folgende Empfehlung:

  • Min. Password Length: 14 Zeichen (oder auch 16 Zeichen)
  • Max. Password Age: 180 Tage
  • Lockout Duration: KEINE automatische Entsperrung!
  • Lockout Threshold: 5 (privilegierte Accounts), bzw. 3 (hoch privilegierte Accounts)
Gruppe Protected Users

Die AD Gruppe Protected Users ist eine Möglichkeit ab Windows 8.1 / Windows Server 2012 R2 zur Absicherung privilegierter Benutzer, bzw. deren Credentials und Passwort-Hashes.

Was passiert, wenn sich ein Mitglieder der Protected Users Gruppe an einem Client oder einem Server anmeldet, im Vergleich zu einem Standardbenutzer?

  • Credential Delegation (CredSSP) cached keine Plain Text Credentials des geschützten Benutzers, selbst wenn per Group Policy die Option Allow delegating default credentials aktiviert ist.
  • Windows Digest Anmeldung cached keine Plain Text Credentials des geschützten Benutzers, selbst wenn Windows Digest Anmeldung aktiviert ist.
  • NTLM cached keine Plain Text Credentials des geschützten Benutzers mehr.
  • Kerberos erstellt keine DES oder RC4 Keys mehr.
  • Kerberos cached keine Plain Text Credentials oder Langzeit-Keys des geschützten Benutzers, nach dem das initiale Ticket-Granting Ticket ausgestellt ist.
  • Domain Controller: Anmeldung per NTLM ist nicht mehr möglich.
  • Domain Controller: Verwendung von DES oder RC4 Encryption Keys bei Kerberos Pre-Authentication ist nicht mehr möglich.
  • Domain Controller: Verwendung des Accounts zur Delegierung (constrained oder unconstrained) ist nicht mehr möglich.
  • Domain Controller: Erneuerung des Kerberos Ticket-Granting Tickets innerhalb der 4-Stunden Gültigkeit ist nicht mehr möglich.

Wichtig ist zu wissen, dass es für diese Anmeldebeschränkungen KEINEN Workaround gibt! Auch für Mitglieder von hochprivilegierten Builtin Gruppen (Enterprise Admins, Domain Admins, etc.) gelten die gleichen Beschränkungen. Sind alle Mitglieder dieser Gruppen auch Mitglied der Protected Users Gruppe, ist es möglich, dass alle diese Benutzer gesperrt werden. Wird dann auch eine Passwort Policy angewendet, die keine automatische Entsperrung konfiguriert hat, ist keinerlei administrativer Zugriff mehr gegeben und die Domain faktisch unbrauchbar. Daher sollte niemals ein solch hochprivilegierter Account zu den Protected Users hinzugefügt werden, ohne dass die Auswirkungen auf den Account hinreichend bekannt und getestet sind. Zudem sollte mindestens ein Domain Admin Account existieren, der nicht in der Gruppe ist. Diesen kann man anlegen, das Passwort an einem sicheren Ort hinterlegen und im Notfall verwenden.

Service Accounts sollten pauschal nicht Mitglied der Protected Users Gruppe sein, da deren Passwort oder Zertifikat immer auf dem entsprechenden Host verfügbar ist und die Mitgliedschaft somit keinen Sicherheitsgewinn bringt.

Auch ein Beispiel dafür, wo die Mitgliedschaft in der Protected Users Gruppe zu Problemen führt, ist das Tool Azure AD Connect zum Synchronisieren seines AD mit Azure. Ist der Account, der AADC initial einrichtet, Mitglied der Protected Users, schlägt die Installation fehl, da das PowerShell Skript, welches bei der Installation mit ausgeführt wird, per NTLM authentifiziert. Daher muss der entsprechende User vor der Installation aus den Protected Users enfernt werden.

Weitere Details zur Protected Users Gruppe und deren Funktionsweise findet ihr hier.

3 Antworten

  1. SETA sagt:

    Hallo Andreas,

    den Artikel finde ich sehr nützlich. Ein Anmerk zur Passwortlänge. Du hast vollkommen recht, dass die Länge gut gegen Brute Force-Attacken hilft. Ich empfehle dir trotzdem 15 Zeichen, da dadurch die Nutzung von LM Hashes verhindert wird, die nur bis 14 Zeichen verarbeiten können. Dadurch wird PtH etwas vermindert.

    Den Punkt „Lockout Duration: KEINE automatische Entsperrung!“ kann ich nicht teilen, weil dies gerade im Falle von privilegierten Nutzern zu Problemen führt. Ein potentieller Angreifer könnte nämlich probieren alle deine Admins gleichzeitig zu sperren und dann kommst du nicht mehr ins System, um diese händisch zu entsperren. Brute Force verhinderst du auch mit Duration von 15 Minuten.

    Beim Treshhold empfiehlt MS 15 oder höher. Insbesondere bei technischen Dienstkonten (1000+).

    MinPasswAge würde ich bei Usern auf einen mindestens 1 Tag setzen, da sie sonst (durch durchprobieren) je nach History gerne wieder auf ihr altes Passwort springen 😉

    • Hallo Seta
      Danke für dein Feedback.
      Bzgl. der Passwortlänge ist es natürlich korrekt, dass ab 15 Stellen kein LM-Hash mehr gespeichert wird. Alternativ lässt sich dies aber auch für kürzere Passwörter erzwingen (zumindest ab der nächsten Passwortänderung):
      > Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\Security Options\Network security: Do not store LAN Manager hash value on next password change
      Die Lockout Duration hingegen ist Ansichstssache. Dein Argument ist korrekt und natürlich sollte es mindestens 1 „Fallback-Account“ geben, der automatisch entsperrt wird. In expliziten Fall verfügen wir über ein solches Account dessen Passwort jeweils zur Hälfte dezentral hinterlegt ist.
      Da das minimale Passwort-Alter standardmäßig in der Default Domain Policy schon auf „1 days“ steht, habe ich das nicht extra aufgeführt.
      Gruß
      Andreas

    • Hallo Seta
      Nochmal ein Nachtrag bzgl. der Passwortlänge. Hier ist Vorsicht geboten, wenn die Passwort-Richtlinie per GPO setzt. Konfiguriert man eine Passwort-Länge von 15 Zeichen, um das Problem mit den Hash-Werten zu eliminieren, bewirkt das genau das Gegenteil. Die Passwort-Länge fällt auch 7 Zeichen zurück. Siehe auch hier:
      https://www.borncity.com/blog/2019/12/09/falle-active-directory-kennwortrichtlinie-mit-15-zeichen/
      Konfiguriert man nur 14 Zeichen, funktioniert die Richtlinie, aber man fällt auf das Problem mit den Hashes zurück. Somit sollte die einzige Möglichkeit die Option bleiben, das Hashing komplett zu deaktivieren.
      Gruß
      Andreas

Schreibe einen Kommentar zu Andreas Schreiner Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.