cj_berlin

Moin, Re Benutzer-GPO: entweder hat jemand Loopback/Replace für den neuen Host konfiguriert, oder der RDS Session Host darf sie nicht lesen. Re Broker-Zugriff: Bist Du sicher, dass die "Normalbenutzer" auf dem neuen RDS-SH nicht zufällig in die Admins oder Remote Desktop Users gerutscht sind?

Moin, wieviel RAM hat der WSUS-Server? Alles unter 16 GB ist unrealistisch, wenn Windows 10/11 bedient werden soll. Und dann musst Du in den Einstellungen des Application Pool kontrollieren, ob Maximum Worker Processes auf 4-8 stehen Private Memory Limit und Virtual Memory Limit auf 0 stehen (in einem Fall hat es tatsächlich erst gegriffen, nachdem wir den Wert auf irgendwas ~4GB gesetzt haben, iisreset, und dann zurück auf 0) Ich bin mir nicht sicher, ob das technisch so stimmt, aber eine Faustregel, die bisher geholfen hat, ist "das größte Update, das in Frage kommt, muss in den privaten RAM des Workers passen".

...und der Domain Naming Master ist derzeit auf denselben Server gesetzt wie die anderen Rollen vor der Verschiebung? Liefert netdom query fsmo das gleiche Ergebnis auf dem jetzigen Role Owner und auf einem anderen DC?

All die Ports, die man als Member zum DC erreichen können muss. Praktisch, wenn Du mit der jeweiligen Konsole über "Change Domain Controller" zum jetzigen UND zum gewünschten zukünftigen Operations Master verbinden kannst, sollte es funktionieren. Aber wenn die Netzwerktopologie so verkorkst ist, dass Du es von Deiner Workstation zwar kannst, die beiden sich jedoch gegenseitig nicht sehen, wird es ein Problem

SNMP auf Windows mit Bordmitteln willst Du aber nicht wirklich...

Service Security and Access Rights - Win32 apps | Microsoft Learn Was Du tun könntest, ist überall einen JEA Endpoint ausrollen, der Get-Service beinhaltet. Dann läuft es lokal mit einem privilegierten virtuellen Account, und remote kannst Du Zugriff erlauben wem Du willst. EDIT: Oder Du kannst auch Get-CIMInstance in den Endpoint einschließen, und alle WMI-Abfragen quasi lokal auf den Servern fahren.

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.