cj_berlin

Microsoft-PMs bitten einmal wieder um Feedback: https://forms.cloud.microsoft/pages/responsepage.aspx?id=v4j5cvGGr0GRqy180BHbR3EdIC-ZoW5PniRpSUHaTIFUMjk1MkVXUEM2ODFITVk5QjNBWVpPVEwwSi4u

Moin, und Willkommen an Board. Es gibt ein paar unterschiedliche Ansätze hier, und Du musst schauen, wie Du daraus eine optimale User Experience zusammen kombinierst. Du nutzt auf dem TS Ordnerumleitung, so dass die Standard-Speicherorte zwar sichtbar sind, aber auf den Fileserver verweisen. Es sind dann trotzdem Pro-Benutzer-Orte, so dass es den Zweck erfüllen könnte, oder eben auch nicht. Du gibst den Usern ein Home-Laufwerk. Daraufhin werden die meisten (aber nicht alle, wäre ja zu schön) Windows-Programme diesen als Vorgabe-Speicherort anbieten. Auch hier gilt: der Home Folder ist pro Benutzer. Du machst genau das, was Du angefragt hast: Blendest die Standard-Speicherorte und das Laufwerk C: auf dem Terminalserver aus. Für das Laufwerk C: gibt es die Policy "Hide these specified Drives in My Computer" unter User Configuration\Administrative Templates\Windows Components\File Explorer. Für die Shell Folder gibt es keine Policy, da musst Du Registry-Einstellungen per GPP ausrollen. Die Registry ist z.B. hier beschrieben: https://www.winhelponline.com/blog/show-hide-shell-folder-namespace-windows-10/

Das Riesenproblem mit den nativen Hyper-V Tools, sei es MMC, PowerShell, WMI oder das normale WAC ist ja, dass sie nach 2008R2 das AuthZ-Mgr-basierte RBAC rausgenommen haben und durch etwas ersetzt haben, das scheinbar niemand beherrscht und/oder anfassen will. Daher ist die einzige Art, RBAC in Hyper-V zu implementieren (abgesehen von meinem Ansatz, den ich 2023 in Prag präsentiert habe ), einen Agent zu haben, der auf den Hosts als Gott läuft, und Authentifizierung, RBAC und Workflows in der Anwendung umzusetzen, die den Agent steuert. SCVMM hat genau das getan, ist aber halt ein Riesen-Moloch.

Naja, VMware hat 10 Jahre gebraucht, um Leute endgültig an Webadministration zu gewöhnen, und Cloud spielte dabei keine Rolle. Ich denke, es ist einfach die Anerkennung der Tatsache, dass SCVMM sich überlebt hat...

Wenn sich irgendwas in Cybersecurity von selbst verstehen würde, könnte ich endlich mit dem Schreinern anfangen...

Ich finde es immer lustig, solche Geschichten bei Banken & Co vorzufinden, deren eigene Websites und Apps durch die Bank mit Cert Pinning arbeiten, um zugelassen zu werden, und be TLS Inspection auf die Nase fallen würden... Die Frage ist hier wie immer: und was macht dann wer mit dem Klartext? Neben dem Ausnahmen muss hier nämlich auch die Detection Engine gepflegt werden und auf Findings Aktivitäten folgen. Andernfalls ist es für die Füße und verbrennt nur unnötig Energie.

Moin, weißt Du positiv, dass der Ablauf bei RDP geprüft wird? Man signiert ja nicht mit Authenticode, damit gelten auch nicht (zwingend) Authenticode-Spielregeln...

Moin, danke für das Heads-Up, 2025 als DC ist immer noch wie eine Schachtel Pralinen Jetzt könnte man natürlich eine Umfrage starten, wer noch DCs ohne GC im großen Stil betreibt, und ich würde mal mutmaßen, dass es gerade nicht die Organisationen sind, die vorpreschen, um alles auf 2025 anzuheben. Aber dennoch, das Testen zersetzt sich in Redmond quasi vor unseren Augen...

Was @NorbertFe sagte. Wenn der Test aus dem Internet erfolgte, gehört die Ugebung vermutlich bereits jemand anderem. Und da braucht ihr kein Audit der Firewall-Konfiguration, sondern das muss einfach zu, und wenn dabei irgendwas nicht mehr funktioniert, dann ist es so. Erst dann macht es überhaupt Sinn, ein Audit "der restlichen Infrastruktur" ins Auge zu fassen. Wenn der Test intern war, dann MUSS ein Domain Controller LDAP auf Port 389 tcp/udp zulassen, und auch SMB, sonst könnten die Member ja keine Gruppenrichtlinien ziehen.

Naja, diese Art von Finding in dieser Formulierung deutet mehr auf ein Konfigurations-Audit hin als auf einen Pentest. Das macht's aber nicht besser, im Gegenteil: Beim Pentest würde ich es noch akzeptieren, wenn keine Hinweise zur Behebung gegeben werden, aber beim Audit ist es das eigentliche Ziel der Übung.

Genau deshalb habe ich nach dem Tool gefragt. Das hat ja nicht ein Mensch in den Report geschrieben, und wenn doch, Geld zurück verlangen.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server da ist auch beschrieben, wie ihr vorher prüft, ob es knallen wird und wo

Moin, Betriebssystem und Functional Level ändern nur das Default-Verhalten, aber wenn Du anheben kannst, wirst Du auf andere Weise davon profitieren. Zu LDAP: https://it-pro-berlin.de/2024/06/ldap-deaktivieren-ein-reality-check/ und schau, ab ihr Signierung aktivieren könnt. Das ist das einzige, was hilft. Nur aus Interesse: welches Tool war es, das dies gemeldet hat?

Moin, was @NorbertFe sagt. Eine Migration aus Chaos-Bereinigungsgründen würde ich nur erwägen, wenn ich ohne Koexistenz auskomme, also Big Bang. Dann brauchst Du auch keinen ADMT, da Du ohne Koexistenz ja auch keine SIDHistory und auch keine laufende Passwort-Synchronisation brauchst. Das geht aber nur, wenn alle Anwendungen mitspielen, inklusive solcher, die augenscheinlich "nur" im Benutzerprofil wohnen. Was Du deshalb vermutlich brauchst, ist sowas wie USMT. Sobald sich jedoch herausstellt, dass eine vom Business akzeptierte Migration nur über eine Koexistenz geht, schwindet der Kreis der stichhaltigen Gründe für eine Migration eigentlich auf nur zwei: Politik: Die Domain-Namen verweisen auf die ehemalige Muttergesellschaft oder auf den rausgedrängten Mitgründer und müssen verschwinden. Security: Es ist mit Sicherheit bekannt, dass ein Backup eines Domain Controllers entwedet wurde, und damit ist alles, was durch DPAPI geschützt ist, sofort angreifbar. Useraccounts neu anlegen geht mit 3-10 Zeilen PowerShell, und da ist es egal, obs 10, 100 oder 10.000 sind.

Genau. Das wäre genau so ein Fall, wo Du Exchange nicht brauchst, weil jede andere Mail-Schleuder besser geeignet und billiger wäre und weniger Infrastruktur benötigt.