cj_berlin

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

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.

Moin, es gibt theoretisch die Möglichkeit, Exchange mit Device-CALs zu lizensieren. Aber das sind Szenarien, wo man Exchange vermutlich nicht wirklich braucht. Wenn alle Personen, die Exchange nutzen (inklusive des Praktikanten, der ab und zu mal am MFP Dokumente einscannt, ohne dass er ein Postfach besitzt), eine User CAL haben, kannst Du so viele Geräte mit Exchange-Zugriff haben, wie Du möchtest, inklusive VMs, Shared Mailboxes usw.

Moin, wenn es Dir nur ums Hinzufügen (also: nicht ums Entfernen) von Mitgliedern geht, kannst Du die "Restricted Groups" GPO statt GPP verwenden, da musst Du allerdings die gewünschte lokale Gruppe in allen verwendeten Sprachen erfassen. FInde ich persönlich ungünstig, aber wenn die Beschreibung wirklich wichtig ist, muss man halt Opfer bringen Ansonsten, GPP, ILT-Filter nach Sprache, und halt mehrfach pflegen. Auch ungünstig, aber wie oft passiert das schon, dass man an der Stelle etwas ändern muss... Oder überall die englische Beschreibung reinballern und gut ist.

Moin, VDA braucht es nur, wenn der Citrix-Desktop auf einem Client-Windows läuft. Und wenn dem so wäre, bräuchtest Du keine RDS-CAL. Da bei Dir Server-Worker im Einsatz ist, ist mit der RDS-CAL der Zugriff lizenziert.

Hast Du das mal mit SYSTEM, also psexec -s versucht? Es ist ja alles Registry, somit an Zgriffsrechte gebunden...

@daabm von der Vererbung der GPOs habe ich doch gar nicht gesprochen, die wäre hier m.E. auch vollkommen wurscht, solange GPO und GPP beide ankommen... Und dann geht es tatsächlich um die Verarbeitung der CSEs, aber halt nur von zwei konkreten... Und sobald die Restricted Groups einmal verarbeitet wird, überschreibt sie alles, wenn es dort im oberen Teil gesetzt ist, unter "Mitglieder dieser Gruppe sind:"

Hab's für euch aufgeschrieben: https://it-pro-berlin.de/2026/03/windows-dns-conditional-forwarders-and-recursion/ Was der Client macht, sollte mit Recursion nichts zu tun haben...