daabm

...und AD so gestalten, daß es die Administration unterstützt (und nicht die Hierarchie der Personalabteilung) :)

ft macht Text daraus, ja :)

...und ich werfe noch 2 Cent in den Raum: Wenn Du wählen kannst, dann nimm einen Namen, der nichts mit dem Unternehmen zu tun hat _und_ dessen Internet-Domain Dir gehört. Spart bei Fusionen/Mergern/Splits viel Ärger... :)

Jaaa zündet sie alle an!!! :) @Philip: http://blogs.technet.com/b/reference_point/archive/2012/12/10/usn-rollback-virtualized-dcs-and-improvements-on-windows-server-2012.aspx

Ab Win8 ist "herunterfahren" nicht "ausschalten"; sondern per default "hibernate": User wird abgemeldet, Rechner speichert Zustand (hiberfil.sys). Ausschalten wäre was anderes :)

Klingt jetzt hart, aber: Ja, ist es. Der Nachbau von Unternehmensstrukturen im AD ist eine Unsitte, die seit 16 Jahren nicht tot zu kriegen ist... Wie ja Norbert schon sagte :) Was Dir trotzdem helfen könnte: Erstelle für die OUs Shadow Groups (alle Objekte in der OU kommen in eine Gruppe) und setze "Anwenden verweigern" auf Deine Problem-GPO. Ist aber auch nur eine schmutzige Lösung - Deny ist bei GPOs immer sensibel, weil man es nicht "direkt" sieht.

Und wie das geholfen hätte - zumindest bei Whitelisting: The ransomware is being shipped as a DLL dropped by Bedep in folders like those observed below in four separate infections: C:\Users\%Username%\AppData\Local\Temp\{C3F31E62-344D-4056-BF01-BF77B94E0254}\api-ms-win-system-softpub-l1-1-0.dll C:\Users\%Username%\AppData\Local\Temp\{D075E5D0-4442-4108-850E-3AD2874B270C} \api-ms-win-system-provsvc-l1-1-0.dll C:\Users\%Username%\AppData\Local\Temp\{D4A2C643-5399-4F4F-B9BF-ECB1A25644A6}\api-ms-win-system-wer-l1-1-0.dll C:\Users\%Username%\AppData\Local\Temp\{FD68402A-8F8F-4B3D-9808-174323767296}\api-ms-win-system-advpack-l1-1-0.dll Aber das ist das erste Mal, daß ich so was nur als DLL sehe - die DLL-Prüfung dürften die meisten nicht aktiv haben, und gestartet wird das natürlich über rundll32.exe - also blöderweise eine legitime Anwendung :()

Ist kein Problem - machen wir z.B. für alle Terminalserver-Domänen so, und auch bei den reinen Ressourcen-Forests. Und benutzerbezogen filtern geht auch gut mit Security Filterung, natürlich nicht mehr per "Verknüpfen oder nicht" :)

Ich lass mich gerne korrigieren, aber damit auditierst Du ja nicht, was diese Dienste machen, sondern wer etwas mit diesen Diensten macht.

Wird wohl eine Datei sein, die in allen 3 Updates drinsteckt - oder eine, die durch alle 3 Updates vom GDR- in den LDR-Branch versetzt wird :)

Ich zitier mich mal: Das gilt auch umgekehrt - wenn der Pfad mit einer Erweiterung endet (also nicht für einen Ordner gilt, sondern für Dateien), gilt die Regel NICHT für Unterordner. Grundsätzlich solltest Du ohnehin alle Orte sperren, an denen der Benutzer schreiben kann :) Der Vollständigkeit halber hier noch die Ermittlungsrangfolge bei Pfadregeln: Wenn mehrere Pfadregeln zutreffen, hat eine spezifische Pfadregel Vorrang vor einer allgemeinen Pfadregel. So ist C:\Windows\System32\cmd.exe spezifischer als C:\Windows. Die Ermittlung der ausschlaggebenden Pfadregel hat folgende Priorität: Laufwerk:\Ordner1\Ordner2\Dateiname.Erweiterung (höchste Priorität) Laufwerk:\Ordner1\Ordner2\*.Erweiterung *.Erweiterung Laufwerk\Ordner1\Ordner2 Laufwerk\Ordner1 (niedrigste Priorität)

Ich empfehle - wenn es keine "professionelle" zentrale Kennwortverwaltung gibt - gerne https://blogs.technet.microsoft.com/askds/2009/03/11/ds-restore-mode-password-maintenance/ - das dürfte der andere Norbert gemeint haben

MS hat da eher nichts behoben, sonst hätten ja alle das Problem gehabt Habt Ihr vielleicht in Eurem Umfeld was gepatcht?

Welche PS-Version? "Get-SMBOpenFile | Close-SMBOpenFile -force"

Na, mich auch Schönheitspunkte gibt es, wenn Du noch die festen Pfade eliminierst - Umgebungsvariablen verwenden...

Und wenn es sich _irgendwie_ reproduzieren lässt: XPerf Boot Logging. Das kann man aber nicht "auf Verdacht" mitlaufen lassen, zieht zu viele Ressourcen.

Das Problem hatten andere auch schon https://blogs.technet.microsoft.com/jhoward/2010/06/16/getting-event-log-contents-by-email-on-an-event-log-trigger/

Bissle was zum Lesen: http://evilgpo.blogspot.de/2012/02/loopback-demystified.html http://blogs.technet.com/b/askds/archive/2013/02/08/circle-back-to-loopback.aspx Verknüfungsreihenfolge sollte egal sein. Computer-SOM kommt immer hinterher. Und in welcher GPO Du Loopback aktivierst ist auch egal - an ist an

Security Compliance Manager, "LocalGPO.wsf" anschauen...

...und dann noch eine Frage: Von wo wird die login.bat ausgeführt - UNC-Pfad oder liegt sie lokal? Wird sie im Fehlerfall überhaupt nicht ausgeführt oder fehlen "nur" die Laufwerke? Und was sagt dann das Logging, das Ihr da ja sicher implementiert habt?

Du könntest mal das advanced Auditing konfigurieren - Erweiterte Überwachungsrichtlinien, Systemüberwachung, Berechtigung, "Nicht sensible Verwendung von Rechten". Das erzeugt gemäß Doku beim Ändern der Systemzeit einen EIntrag im Security Eventlog. Das muß natürlich dann groß genug sein - aber dann weißt Du, welcher Prozess unter welchem Account das macht.

Das war aber kein Neustart, oder? Schau mal ins Application Eventlog und in die geplanten Tasks. Virenscanner könnte auch verantwortlich sein.

Naja, das stand schon vor einiger Zeit bei drwindows.de Wers braucht...

Einen gibt es immer - den builtin Admin beim DCPromo :-) Soweit ich weiß, kann man auch nicht EFS-verschlüsseln, wenn es keinen RA gibt, aber da lasse ich mich gern belehren.

Naja, dann nimm erst mal das System-Eventlog zur Hand. Da steht drin, wann die Zeit genau geändert wurde. Und dann finde raus, was da noch so passiert ist - geplante Tasks? Computerstartskripts? Niemand weiß es genau