try_and_error

Bei uns wurde das Gleitzeitmodell (Kernzeiten zwischen 09.00 - 12.00 Uhr und 14.00 - 16.00 Uhr) seit der Corona-Pandemie aufgehoben, anscheinend soll es auch erst einmal dabei bleiben. Die Rahmenarbeitszeit ist zwischen 06.00 - 20.00 Uhr angesiedelt. Mobiles Arbeiten ist aktuell erwünscht und möglich, hier wird dann digital auf Vertrauensbasis ein und ausgestempelt.

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...

Das ist natürlich eine Lösung, allerdings frage ich mich, wieso die Auswahl des Benutzers in diesem Modus schlichtweg unterbunden wird... 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.

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!