goSecurity BLOG

Meine bisherigen Audits zeigten, dass der Protected Users Active Directory-Gruppe oft zu wenig Beachtung geschenkt wird. Der Schutz privilegierter Konten im Active Directory ist essenziell für eine sichere IT-Infrastruktur. Konten, welche Mitglied der Protected Users Gruppe sind, profitieren von erweiterten Sicherheitsmechanismen, um damit insbesondere bekannte (und oft genutzte) Angriffstechniken zu vereiteln.

Die Protected Users-Gruppe ist eine effektive Sicherheitsmassnahme und sollte öfters verwendet werden. In diesem Blog zeige ich Ihnen die entscheidenden Vorteile, praxisnahe Anwendungsfälle und wann diese Gruppe nicht angewendet werden sollte.

Die wichtigsten Vorteile für Mitglieder der Protected Users Gruppe

Wird ein Konto der Gruppe hinzugefügt, werden diesem automatisch durch das Active Directory vorkonfigurierte Sicherheitsmechanismen aktiviert. Diese Mechanismen können durch Mitglieder nicht verändert oder entfernt werden (ausser das Konto wird aus der Gruppe entfernt).

Ein Blick in die Protected Users-Gruppe zeigt, dass zwei von den vier administrativen Accounts Mitglied sind.

    Protected User Mitglieder                                                                    Kein Protected User Mitglieder

Folgend die wichtigsten dieser Sicherheitsmechanismen:

Begrenzung Kerberos Ticket-Granting Ticket (TGT) Laufzeit

TGT-Tickets sind für Mitglieder dieser Gruppe nur 4 Stunden gültig und können danach nicht erneuert werden. Typischerweise ist ein TGT-Ticket 10 Stunden gültig und kann 7 Tage lang erneuert werden (ohne Passworteingabe).

    Protected User Mitglieder                                                                    Kein Protected User Mitglieder

Keine Zwischenspeicherung im LSASS

Der NTLM-Hash ist nicht mehr im LSASS (Local Security Authority Subsystem) zwischengespeichert. Angreifer versuchen oft, nachdem diese auf ein System gelangt sind, die NTLM-Hashes dieses Systems auszulesen. Ein Weg dies zu tun, ist den NTLM-Hash aus dem LSASS-Prozess Speicher auszulesen. Wird der NTLM-Hash nicht im LSASS-Prozess zwischengespeichert, kann dieser nicht ausgelesen werden.

    Protected User Mitglieder                                                                    Kein Protected User Mitglieder

Keine NTLM-Authentifizierung

Die NTLM-Authentifizierung (NT LAN Manager) wird blockiert, wodurch die Verwendung schwächerer, anfälligerer Protokolle unmöglich wird. Ist es einem Angreifer möglich den NTLM-Hash eines Users auszulesen, besteht unter Umständen die Möglichkeit, sich mit diesem Hash an einem weiteren System anzumelden (Pass-the-Hash-Angriff). Dies wird von Angreifern oft erfolgreich durchgeführt. Wird einem User die NTLM-Anmeldung nicht erlaubt, funktioniert dieser Weg nicht mehr.

Protected User Mitglieder

Kein Protected User Mitglieder

(Eigentlich) Keine Verwendung von DES oder RC4 für die Kerberos-Vorauthentifizierung

Es wird nur AES-Verschlüsselung verwendet, wodurch Angreifer daran gehindert werden, schwächere Verschlüsselungsarten wie z.B. RC4 auszunutzen.

Protected User Mitglieder

Kein Protected User Mitglieder

Wieso steht nun in der Überschrift (Eigentlich)? Microsoft hat eine Ausnahme hinzugefügt. Für den built-in User Administrator (RID 500) gilt dies leider nicht, auch wenn er Mitglieder der Protected User-Gruppe ist und diesen Mitgliedern explizit nicht erlaubt wird RC4 zu nutzen. Ich zeige dies im folgendem Beispiel auf:

Protected User Mitglieder

Ein Loginversuch mit dem NTLM-Hash und dem built-in User Administrator, welcher ein Mitglied der Protected User-Gruppe ist, wird korrekterweise blockiert.

Loginversuch blockiert

Der RC4-Kerberos-Schlüssel des Users ist identisch mit seinem NTLM-Hash. Nun ein Loginversuch mit RC4-Hash und dem gleichen built-in User Administrator. Dieser Versuch ist nun fälschlicherweise erfolgreich.

Loginversuch erfolgreich

Nun führen wir einen Loginversuch durch mit dem NTLM-Hash und dem User adm_Lamar.Donnar, welcher ein Mitglied der Protected User Gruppe ist (aber nicht der built-in User Administrator). Dieser Versuch wird korrekterweise blockiert.

Loginversuch blockiert

Dieser Fehler wurde an das Microsoft Security Response Center (MSRC) gemeldet. MSRC hat geantwortet, dass dieses Verhalten beabsichtigt ist und es sich nicht um einen Fehler handelt. Mit dieser Aussage müssen wir uns abfinden, oder der built-in Administrator kann deaktiviert werden. Dies kann jedoch gefährlich sein und wird seitens Microsoft nicht empfohlen Securing Built-in Administrator Accounts in Active Directory.

Keine Kerberos Delegation

Die Delegierung ermöglicht es einem Benutzer oder einem Computer, sich als ein anderes Konto auszugeben, um auf Ressourcen zuzugreifen (zum Beispiel auf Backend-Datenbankserver). Die Delegation hat mehrere praktische Anwendungen in einer IT-Umgebung. Man unterscheidet zwischen «Computer bei der Delegierung aller Dienste vertrauen (nur Kerberos)» (unconstrained) und «Computer bei der Delegierung angegebener Dienste vertrauen» (constrained). Unconstrained-Delegation stellt ein Sicherheitsrisiko dar und ermöglicht den Diebstahl von Zugangsdaten.

Mitglieder der Protected User Gruppe können nicht für solche Delegationen verwendet werden. Weder für die constrained noch für die unconstrained Delegation. Diese Einschränkung schützt die User, da ihre Anmeldedaten nicht von Diensten im Netzwerk zwischengespeichert oder weitergereicht werden dürfen.

Auch hier gilt leider, dass der Built-in Administrator-Account (RID 500) für Delegation missbraucht werden kann. Um dies zu unterbinden, muss in den Eigenschaften des Accounts die Option «Account is sensitive and cannot be delegated» aktiviert werden.

Built-in Administrator

Keine Verwendung von Klartextpasswörtern

Passwörter für Mitglieder dieser Gruppe können nicht im Klartext innerhalb der lokalen Sicherheitsbehörde (LSA) gespeichert werden, wodurch die Gefährdung durch das Auslesen von Anmeldeinformationen verringert wird.

Welche Szenarien sind realistisch und praxisnah umsetzbar

Die Protected Users Gruppe ist leider keine Einheitslösung für alle Fälle. Sie ist am effektivsten, wenn sie zum Schutz von Konten (z.B. Tier0-Admins) mit hohem Risiko verwendet wird, die wahrscheinlich von Angreifern angegriffen werden. Ich zeige ein paar Anwendungsfälle auf, bei welchen der Einsatz sinnvoll ist:

• Domänen-Administratoren und andere Konten mit höher privilegierten Berechtigungen
  Konten mit erhöhten Berechtigungen, wie z.B. Konten in den Gruppen Domänenadministratoren, Organisationsadministratoren oder Schema-Admins, sollten Mitglied sein.

• Konten mit Zugang zu sensiblen Daten oder kritischen Systemen
  Konten, die direkten Zugang zu vertraulichen Daten wie z.B. Finanzsystemen haben, sind gut geeignet.

• Service Accounts, die auf kritischen Systemen oder mit hohen Berechtigungen laufen
  Wenn ein Service Account zum Ausführen eines geschäftskritischen Dienstes oder einer Anwendung verwendet wird, kann das Hinzufügen zu dieser Gruppe unbefugten Zugriff und Missbrauch von Anmeldeinformationen verhindern.

Wann sollte auf die Verwendung verzichtet werden

Die Protected Users-Gruppe Active Directory (AD)-Gruppe bietet zwar einen soliden Schutz, jedoch entstehen damit auch gewisse Einschränkungen, welche zu betrieblichen Problemen führen können (wenn die falschen Konten hinzugefügt werden). In folgenden Szenarien sollte die Protected Users-Gruppe nicht angewendet werden:

• Notfall-Accounts
  Break Glass-Accounts und der built-in Domänen-Administrator sollten nicht der Protected User Gruppe hinzugefügt werden.

• Normale Benutzerkonten
  Standardbenutzer, die keine erweiterten Rechte besitzen, sollten nicht einbezogen werden. Dies kann zu Problemen bei Anwendungen führen, die auf älteren Protokollen beruhen oder eine Delegation benötigen.

• Für Delegation verwendete Konten
  Protected Users Benutzer können weder für die uneingeschränkte noch für die eingeschränkte Delegation verwendet werden. Wenn ein Dienst- oder Benutzerkonto Anmeldeinformationen delegieren muss (z.B. für single sign-on), sollte es sich nicht in der Protected Users Gruppe befinden.

• Konten, die einen Offline-Zugriff erfordern
  Da das TGT-Caching deaktiviert ist, ist der Offline-Zugriff für Benutzer in der Protected Users Gruppe problematisch. Wenn ein Benutzer auf Domänenressourcen zugreifen muss, während er nicht mit dem Netzwerk verbunden ist, sollte er sich nicht in dieser Gruppe befinden.

Fazit

Nutzen Sie die Protected Users Gruppe zur Sicherung von Konten mit hohen Rechten (z.B. Tier0-Admins), aber tun Sie dies mit Vorsicht. Implementieren Sie sie mit Bedacht, beginnen Sie mit einer kleinen Untergruppe von Konten und überwachen Sie sie auf mögliche Probleme. Bei korrekter Implementierung wird das Risiko von Angriffen wie z.B. Pass-the-Hash erheblich reduziert und die AD-Umgebung weiter abgehärtet.