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.
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).
Die Gruppe enthält in der Ausgangssituation keine Mitglieder.
Mitglieder der Gruppe verlieren aber folgende „Fähigkeiten“.
- Authenticate with NTLM authentication.
- Use DES or RC4 encryption types in Kerberos pre-authentication.
- Be delegated with unconstrained or constrained delegation.
- 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.
- Der User öffnet einen UNC-Pfad – zum Beispiel: \\10.0.0.1\share
Hierbei übermittelt der Computer des Users den Benutzernamen im Klartext - Der Memberserver schickt dem User eine eine 16-Byte-Zufallsnummer
- Der User verschlüsselt die 16-Byte-Zufallsnummer mit seinem MD4- / NTLM-Hash (vulgo das konvertierte Kennwort von Plain-text -> MD4)
- 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. - Es bleibt dem Memberserver nur die Option seinen Logon-DC hierzu zu befragen.
- 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.
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*
*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
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.
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).
Kein NTLM mehr, wenn Mitglied der Protected Users
NPUser (kein Mitglied der Protected Users): der Zugriff auf einen UNC-Pfad per IPv4-Adresse geht
PUser (Mitglied der Protected Users): der Zugriff auf einen UNC-Pfad per IPv4-Adresse geht nicht.
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).
Versucht sich der PUser auf dem Rechner anzumelden, welcher nur RC4 unterstützt passiert folgendes:
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.
Der NPUser ist nicht Mitglied in den „Protected Usern“ und seine Kerberos-Tickets entsprechen dem Standard: 10 Stunden / 7 Tage.
Nachteil daraus? Hmm…vermutlich ein ganz bisschen mehr Last auf den DCs.
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:
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.
Die einzige Alternative ist hier die RBKCD (resource based kerberos constrained delegation).
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.
Bei einem Mitglied der „Protected Users“ ist nichts zu holen:
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
