Scroll Top

Die häufig missverstandene Gruppe: „Protected Users“ (NTLM erklärt)

Martin Handel

Die Gruppe “Protected Users” wurde mit den Produkten Server 2012 R2 und Windows 8.1 vorgestellt und als eine weitere Standardgruppe im AD implementiert. Die Funktion der Gruppe wird wirksam ab dem 2012 R2 domain functional level.

https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group

Der Gedanke von dieser Gruppe war, unter anderen, dass der MD4-Hash / NTLM-Hash nicht im LSA-Cache gehalten wird. Würde der LSA-Cache auf einem Computer gedumpt werden, an dem ein Mitglied der „Protected Users“ angemeldet ist, findet der Angreifer in dem Dump keinen Hash (siehe ganz unten).

ESAE

Die Gruppe enthält in der Ausgangssituation keine Mitglieder.

Kerebos V5
ESAE

Mitglieder der Gruppe verlieren aber folgende „Fähigkeiten“.

  1. Authenticate with NTLM authentication.
  2. Use DES or RC4 encryption types in Kerberos pre-authentication.
  3. Be delegated with unconstrained or constrained delegation.
  4. Renew the Kerberos TGTs beyond the initial four-hour lifetime.

Ok, das müssen wir ein bisschen auseinanderpflücken.

No more authentiacte with NTLM authentication

Mitglieder der Gruppe können die NTLM-Authentifizierung nicht mehr verwenden.

Wie funktioniert NTLM?

Beispiel: ein User greift per NTLM auf eine Ressource zu (z. B. eine Freigabe bei einem File-Server) und…

Stop! Stop!!

Wann verwende ich NTLM überhaupt?

  • Wenn der Dienst, auf den Zugegriffen wird nur NTLM unterstützt oder
  • Wenn der Zugriff auf den Dienst über eine IPv4-Adresse erfolgt.

Ok? Ok.

ESAE
  1. Der User öffnet einen UNC-Pfad – zum Beispiel: \\10.0.0.1\share
    Hierbei übermittelt der Computer des Users den Benutzernamen im Klartext
  2. Der Memberserver schickt dem User eine eine 16-Byte-Zufallsnummer
  3. Der User verschlüsselt die 16-Byte-Zufallsnummer mit seinem MD4- / NTLM-Hash (vulgo das konvertierte Kennwort von Plain-text -> MD4)
  4. Der Memberserver hat jetzt ein kleines Problem:
    er, der Memberserver kann das Kennwort nicht überprüfen, da er das Kennwort nicht in seiner SAM-Datenbank hat.
  5. Es bleibt dem Memberserver nur die Option seinen Logon-DC hierzu zu befragen.
  6. Der Domain Controller validiert das Kennwort, in dem er die verschlüsselte Challenge entschlüsselt und den Memberserver über das Ergebnis informiert.

No more use of DES or RC4 encryption types in Kerberos pre-authentication

Pre-authentication bzw. Prä-Authentifizierung ist im Kerberos V5-Protokoll der Erstkontakt zwischen einem Kerberos-Client und einem Domain Controller. Hierbei wird die Uhrzeit des Clients mit dem Kennwort des Kerberos-Client verschlüsselt und an den Domain Controller zur Entschlüsselung übermittelt.

Ergebnis ist am Ende ein Ticket Granting Ticket (TGT).

Hier werden bei einer Gruppenmitgliedschaft in den „Protected Users“ die Zöpfe „DES-Verschlüsselung“ und „RC4-Verschlüsselung“ abgeschnitten.

Ohne TGT gibt es dann als Konsequenz aber danach auch keine Ticket Granting Tickets (TGS). Ohne TGS kann ich auf keine Ressourcen via Kerberos V5 zugreifen.

Normalerweise käme jetzt der Fallback auf NTLM, das ist aber leider als Mitglied der „Protected Users“ ausgeschlossen.

Security

No more delegation with unconstrained or constrained delegation.

Fangen wir mit dem Ältesten an: unconstrained delegation

  • Ursprung: Jahr 1993 (RFC1510)
  • Freifahrtschein für Kerberos
  • Typisch für Domain Controller*
Constrained Delegation

*Domain Controller unterliegen jedoch nicht der Restriktion aus den „Protected Users“ heraus.

Danach: constrained delegation

  • Ursprung: Jahr 2005 (RFC 4120)
  • Ziel und Protokoll werden bei der Delegation vorgegeben.
  • Typisch für die Double- oder N-Hop-Szenarien
Constrained Delegation

Wie? Jetzt kann gar nicht mehr delegiert werden?

Doch, natürlich. Über die „resource based kerberos contrained delegation”!

Die RBKCD (resource based Kerberos contrained delegation) arbeitet auf das Ziel fokussiert und nicht mit dem Ziel die „Mittelsmänner“ zu konfigurieren.

Dazu aber später mehr.

Renew the Kerberos TGTs beyond the initial four-hour lifetime.

Jetzt neu: nur noch Kerberos-Tickets mit maximal 4 Stunden!

Normalerweise bekomme ich TGTs mit einer Laufzeit von, zwischen 10 Stunden und 7 Tagen.

ESAE

Nicht mehr, wenn ich in den „Protected Users“ bin, dann gelten pauschal 4 Stunden Kerberos-Ticket-Laufzeit.

Ok, was geht noch, was geht nicht mehr

Angenommen wir haben zwei unterschiedliche Benutzer. NPUser (Mitglied der Domain Admins und Enterprise Admins – eben NonProtected) und PUser (Mitglied der Domain Admins, Enterprise Admins und Mitglied der Protected Users).

Security

Kein NTLM mehr, wenn Mitglied der Protected Users

NPUser (kein Mitglied der Protected Users): der Zugriff auf einen UNC-Pfad per IPv4-Adresse geht

NTLM

PUser (Mitglied der Protected Users): der Zugriff auf einen UNC-Pfad per IPv4-Adresse geht nicht.

Security
Constrained Delegation

Keine RC4 Ticket Granting Tickets mehr für den Kerberos-Client

Das ist in der Praxis eher ungewöhnlich, da die Systeme in der Regel AES unterstützen. Um das zu zeigen habe ich auf dem Rechner mit der cmd.exe auf der rechten Seite das AES abgeschaltet (RC4 only).

RC4

Versucht sich der PUser auf dem Rechner anzumelden, welcher nur RC4 unterstützt passiert folgendes:

NTLM
NTLM

Keine 10 Stunden / 7 Tage-Kerberos-Ticktes mehr

Ein Mitglied der „Protected Users“ bekommt nur noch Kerberos-Ticket (TGT / TGS) welche auf 4 Stunden reduziert sind, ausgehend von 10 Stunden / 7 Tage bisheriger Laufzeit:

PUser ist Mitglied der „Protected User“ und bekommt Kerberos-Tickets nur noch mit 4 Stunden Laufzeit.

ESAE

Der NPUser ist nicht Mitglied in den „Protected Usern“ und seine Kerberos-Tickets entsprechen dem Standard: 10 Stunden / 7 Tage.

NTLM

Nachteil daraus? Hmm…vermutlich ein ganz bisschen mehr Last auf den DCs.

ESAE

No more delegation with unconstrained or constrained delegation

Ich habe ad hoc keine Anwendung gefunden, welche „easy-peasy“ einen Double-Hop durchführt ohne, dass ich erst noch Tonnen von Infrastruktur bereitstellen muss (MECM, ADFS und dergleichen).

WinRM eignet sich leider gar nicht dazu, da WinRM keine Double-Hops unterstützt:

https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ps-remoting-second-hop?view=powershell-7.3

 

Cons: Kerberos constrained delegation

  • Doesn’t support the second hop for WinRM.
  • Requires Domain Administrator access to configure.
  • Must be configured on the Active Directory object of the remote server (ServerB).
  • Limited to one domain. Can’t cross domains or forests.
  • Requires rights to update objects and Service Principal Names (SPNs).
  • ServerB can acquire a Kerberos ticket to ServerC on behalf of the user without user intervention.

 

Cons Resource-based Kerberos constrained delegation

  • Requires Windows Server 2012 or later.
  • Doesn’t support the second hop for WinRM.
  • Requires rights to update objects and Service Principal Names (SPNs).

Nichtsdestotrotz: eine solche constrained delegation würde für eine Mitglied der „Protected Uses“ nicht mehr gelten.

RC4

Die einzige Alternative ist hier die RBKCD (resource based kerberos constrained delegation).

NTLM

Bei RBKCD (bitte nicht mit NKOTB verwechseln) wird beim Zielsystem definiert wer darauf Credentials delegieren darf.

Very smart, very flexible, very forest overgroping.

Vielleicht mache ich noch mal einen Artikel zu RBKCD.

Was bringt eine Mitgliedschaft in „Protected Users“, außer dass vieles nicht mehr geht?

Einem nackten Mann fasst man nicht in die Tasche: keine Credentials im LSA-Cache, nichts zu holen!

Das ist ein bisschen wie der alte Scherz zum Thema Verhütung:

Q1: Wie verhindert man eine ungewollte Schwangerschaft ohne Verhütung?

A1: Einfach ein Glas Wasser trinken.

Q2: Davor oder danach?

A2: Anstelle dessen.

Ein User, welcher nicht in den „Protected Users“ Mitglied ist, kann per LSA-Dump erbeutet werden.

NTLM

Bei einem Mitglied der „Protected Users“ ist nichts zu holen:

Kerberos V5

Fazit / Empfehlung zu „Protected Users“

Meiner bisherigen Erfahrung nach sind ist die Gruppe der „Protected User“ sehr geeignet für die ganzen Tier0-Konten*. Das Risiko einer Kompromittierung ist hier bei fast null.

*Ausgeschlossen von den „Protected Users“ sollten mindestens zwei der sogenannten Break-Glass-Admins sein. Dieser Ausschluss ist die Analogie zur Ausnahme vom Global Admin bei Azure von Conditional Access. Das kann gut gehen, muss aber nicht.

Wenn die Fäkalien evaporieren (zum Beispiel, weil Kerberos nicht mehr geht) und ich habe keinen Break-Glass-Admin außerhalb der „Protected Users“, dann ist echt Schicht im Schacht.

Protected Users geht aber nicht, weil…

Wenn eine Mitgliedschaft eines oder mehrerer sensibler Konten aufgrund der Restriktionen bei den „Protected Users“ technisch unsinnig ist, bleiben nur die bisherigen Schutzmaßnahmen.

  • Credential Guard zum Schutz der lokalen Credentials
  • Remote Credential Guard: die Credentials bleiben bei RDP auf der abgehenden Maschine
  • Unabhängig der „Protected Users“: nicht im LSA-Cache sein
  • JIT: just in time administration
  • JEA: just enough administration
Kerberos V5

Verwandte Beiträge

Hinterlasse einen Kommentar

4 + 7 =