Remote Credential Guard & Restricted Admin Mode - Frage zur Umsetzung

[try_and_error]

Hallo zusammen,

wir möchten in unserem Unternehmensnetzwerk die Übertragung von Credential Hashes und Kerberos Tickets auf RDP Hosts (primär Server) bei RDP Verbindungen unterbinden.

Hierfür gibt es die Möglichkeit, bei RDP Verbindungen den Remote Credential Guard und den Restricted Admin Mode (als Fallback Lösung für Win Server 2012 und älter) zu verwenden, wodurch keine Anmeldedaten auf das Zielsystem übertragen werden (ich habe mit Mimikatz etwas getestet und war überrascht, wie zuverlässig das funktioniert - man konnte keinerlei Hashes oder Kerberos Tickets aus dem Speicher laden). Die Einrichtung war nicht weiter schwierig, allerdings würde mich interessieren, ob es hier Leute gibt, die die Features ebenfalls nutzen und mir folgende Frage zur Umsetzung beantworten können.

Aktuell testen wir das Ganze, in dem wir die RDP Verbindung vom RDP Client (Admin Workstation / PAW, die wir für die administrative Verwaltung nutzen) manuell mit dem jeweiligen Feature starten. Aktuell via cmd und dem relevanten Argument, also z.B. "mstsc.exe /restrictedadmin". Leider mussten wir feststellen, dass die RDP Sitzung dann im Kontext des Benutzers gestartet wird, mit dem man die cmd geöffnet hat - standardmäßig ist das bei uns der unprivilegierte AD-Benutzer, mit dem wir uns auf der Admin-Workstation angemeldet haben. Dieser Benutzer hat logischerweise keine RDP Berechtigungen auf Severn, geschweige denn Adminrechte.

In einem nächsten Test aktivierten wir die beiden Features via Gruppenrichtlinien auf der Admin-Workstation (somit wird die Unterbindung der Delegierung von Anmeldedaten erzwungen). Auch hier zeigte sich dasselbe Verhalten: die RDP-Sitzung startete automatisch mit dem User, mit dem man auf dem RDP Client angemeldet ist. Und das ist ohne Weiteres nicht abänderbar. Um zu testen, haben wir die cmd dann im Kontext mit dem jeweiligen Admin-Account geöffnet.

Deshalb die Frage an euch:

Wie ist das praktikabel umzusetzen? Müssten wir uns dann mit einem privilegierten Account auf der Admin-Workstation anmelden, der dann auch die nötigen Berechtigugnen auf den Zielservern hat? Oder gibt es bessere Lösungen, die ich bisher übersehen habe? Besten Dank schon mal für eure Hilfe!

 

 

 

[Bitschnipser]

vor 7 Minuten schrieb try_and_error:

Wie ist das praktikabel umzusetzen?

Rechtsklick>"Run as..."
So lässt sich auch direkt die mstsc.exe starten.

Ich blicke beim Hintergedanken nicht so ganz durch. Warum wollt ihr keine Credential Hashes und Kerberos Tickets übertragen? Interessiert mich technisch.

 

[try_and_error]

vor 12 Minuten schrieb Bitschnipser:

Rechtsklick>"Run as..."
So lässt sich auch direkt die mstsc.exe starten.
 

Das ist natürlich eine Lösung, allerdings frage ich mich, wieso die Auswahl des Benutzers in diesem Modus schlichtweg unterbunden wird...

vor 29 Minuten schrieb Bitschnipser:

Ich blicke beim Hintergedanken nicht so ganz durch. Warum wollt ihr keine Credential Hashes und Kerberos Tickets übertragen? Interessiert mich technisch.

 

Um so wenig Daten, die zur Übernahme des Domänen-Netzwerks führen können, wie möglich auf den Systemen liegen zu haben (Stichwort "Pass-The-Hash- und Pass-The-Ticket-Angriffe"). Da gerade auf den Servern mit hochprivilegierten Accounts gearbeitet wird, erschien es uns als sinnvoll, die Speicherung der Daten zu unterbinden.

So könnten wir sicherstellen, dass die Hashes und Tickets nur auf den extra gehärteten und kontrollierten Admin Workstations gespeichert werden. Was einen Angriff erschweren sollte, da die "Angriffsfläche" deutlich minimiert wird.

[Bitschnipser]

ich hab mich mal etwas zu dem Thema (und dem allgemeinen Windowsanmeldeprozess inkl. Kerberos) eingelesen, weil es mich einfach interessiert hat.
 

Am 2.3.2021 um 12:18 schrieb try_and_error:

wieso die Auswahl des Benutzers in diesem Modus schlichtweg unterbunden wird...

Schlichtweg bewirbt MS das als "Single Sign-On". Keine Ahnung ob es technisch möglich wäre und nur seitens MS unterbunden wird oder ob das ein Sicherheitsfeature sein soll.

In den Dokumentationen zum Remote Guard und restricted Admin access wird aufjedenfall ständig hervorgehoben wie bequem und einfach das Ganze ist.
Vielleicht denkt MS man benutzt einfach auf allen Systemen die gleichen Credentials (in einer DMZ vielleicht nicht so sinnvoll).

Dir bleibt wohl nur die Möglichkeit mit "run as..". Da gibt es aber durchaus Möglichkeiten (Desktop-)Verknüpfungen mit entsprechend hinterlegten Credentials anzulegen. Wie sinnvoll das Ganze dann noch ist, wenn man die Angriffsfläche minimieren will, ist hier ausser Frage.

Ob ich das Ding mit "run as..." und meinen Credentials starte oder die Credentials bei der mstsc.exe direkt eingebe ist ja letztlich wurscht.

[try_and_error]

Danke auf jeden Fall für deine Mühen. Die Thematik geht auf jeden Fall schon gut in die "Tiefe", ich selbst beschäftige mich auch erst seit einer Weiterbildung in Sachen AD Sicherheit näher mit der Thematik und muss noch viel dazulernen...

Fakt ist aber auf jeden Fall, du sehr wahrscheinlich Recht hast. MS hat das wohl bewusst so konfiguriert - weshalb, bleibt offen. Mit der "Run as..." Methode kann ich auf jeden Fall leben, so werden die hoch privilegierten Hashes sowie Kerberos Tickets lediglich auf der Admin-Workstation erzeugt und das ist unser Ziel. Natürlich nicht mit denselben Credentials/Accounts, das würde das ganze Konzept ja wieder aufweichen - aber dafür gibt es das MS Tier Modell...