cj_berlin

Ja, aber sie ist eher langfristig ausgelegt. Dem Hersteller der Anwendung, die SMB1 verwendet, so lange in den A**** treten, bis das endlich gefixt wird. Ansonsten, wenn es "sicher" sein soll: SMB1-Zugriffe auf ein VLAN begrenzen, und alle Systeme, die diesen Zugriff wirklich brauchen, sollen ein Bein in diesem VLAN haben, und möglichst nur dort. Jetzt wirst Du sagen: Das sind aber alle Clients Dann hast Du verloren. Eine VM, außerhalb der Domain, möglichst als SAMBA - je mehr Halbmaßnahmen man übereinander häuft, desto schwieriger wird es zu debuggen, wenn etwas schief läuft.

Moin, die "händische Variante" lässt sich durchaus skripten: Du gehst alle Unterschlüssel von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList durch und setzt in jedem den Wert "State" auf 0. Aber in meiner Erfahrung ist die Ausschussquote hier minimal.

Teams ist ein schwieriger Fall. Der Service entwickelt sich feature-mäßig so rasant, dass selbst der Gedanke einer "LTSR-Edition" des Clients, die nicht alle Features hätte, dafür aber fix installierbar wäre, vermutlich häufigere Updates bedeuten würde als einem lieb ist. Ist halt "perpetual beta"-Software, auch bekannt als "agiles Development". Andererseits, nur so haben Office Apps & Services MVPs genug zum Bloggen Warum allerdings jeder andere Mist unbedingt über den Store und somit im User-Kontext verteilt werden muss, obwohl er alle Jubeljahre mal Updates erfährt, frage ich mich auch jedes mal. Windows Terminal, zum Beispiel.

Hatte ich vor zwei Wochen, Landesbehörde. Und selbst da hat es einer geschafft, sich innerhalb von 20 Minuten nicht einwählen zu können.

Moin, welche Rollen sind denn bereits auf dem Server installiert? Wenn da Routing & RAS drauf ist, bindet es in manchen Konstellationen auch an den DNS-Port.

Moin, mit der richtigen Konfiguration ist es aber auch nicht nötig, viele Systeme ins AD aufzunehmen. Kommt immer darauf an, ob man Gott-Accounts haben möchte oder nicht. "Geht alles" beinhaltet in letzter Konsequenz immer SIEM und jemanden, der die Ereignisse dort 24x7 nahezu in Echtzeit auswertet, denn nur so kannst Du ein Gott-Account aufhalten. Viele einzelne systemspezifische Admins (ohne password reuse eingerichtet ) zu knacken dauert schon deutlich länger und hinterlässt auch mehr Spuren. Leider sind genau die Organisationen, die kein Geld für SIEM und SOC haben, diejenigen, welche auch kein Geld für ordentliches Configuration Management haben und deshalb das AD dafür missbrauchen, mit den bekannten Folgen.

Alternativ natürlich, falls @yoda123 keine Lust hat, PowerShell zu lernen, gäbe es auch https://docs.microsoft.com/de-de/windows-server/administration/windows-commands/forfiles

Nur, dass es die Domain-Maschine ist, die den AV-Manager fährt

Was Norbert sagt. Das Stichwort für die on-prem-Variante ist "centralized Mailflow".

Moin, das (oder so ähnlich) sollte per "Library Sharing" möglich sein. Die DPM-Instanzen teilen sich dann aber nicht eine DB, sondern greifen auf die Datenbank des jeweils anderen DPM-Server zu. https://robertanddpm.blogspot.com/2013/11/tape-library-sharing.html

...und die Frage ist?

Moin, wenn manueller "Transfer from Master" geklappt hat und automatische Replikation nicht, dann fehlen Dir vermutlich Update Notifications. Dies stellst Du in den Eigenschaften der Zone ein, dort, wo Du angibst, an wen sie transferiert werden darf.

Moin, alles unter "RBAC" beschrieben: https://docs.microsoft.com/en-us/exchange/understanding-role-based-access-control-exchange-2013-help

Friends don't let friends run unsigned binaries in production

Moin, solange Du nicht auch noch die Policy "lokale Kopie des servergespeicherten Profils bei Abmleden löschen" gesetzt hast, wird ja gar nichts verschoben, sondern nur kopiert. Policy deaktivieren, Anwendung abwarten, Serverkopie löschen, fertig. Hast Du die o.g. Policy aktiviert, so musst Du sie zuerst deaktivieren, dann muss sich jeder User einmal an jedem Computer anmelden, wo er gern ein Profil hätte, und dann deaktivierst Du die Policy für den Profilpfad.

Moin, Du verwendest die Variable $listViewItem mehrfach, für verschiedene Zwecke. AD-Zeit ist FileTime, Du brauchst [datetime]::FromFiletime($item.lastlogon) Und bedenke: Wenn Du mehr als einen Domain Controller hast, ist LastLogon nicht notwendigerweise bei jedem User auf jedem DC belegt. Du könntest auf LastLogonTimestamp ausweichen - das ist überall gleich, ist aber nicht zwangsläufig der allerletzte Logon.

https://lmgtfy.app/?q=get-acl+permissions+report

Moin, Laufwerksrechte werden nicht im AD, sondern im NTFS-Dateisystem vergeben. Deine Freunde sind Get-ChildItem und Get-ACL.

Nein, wenn es nicht "remote" ist. Remote = von einem Server kommend, der in den Internet Explorer Security Zones nicht "Intranet" ist. Da ein Logon-Skript in der Regel aus SYSVOL kommt, wäre es im Zweifel nicht "remote". Außerdem, wenn Du das Skript im GPO-Zweig "Scripts" ausführst, wird die Execution Policy für diese Ausführung aus "Bypass" gestellt.

Wenn weder AppLocker noch Execution Policy das erzwingen, dann musst Du es auch nicht signieren.

Moin, da es eine filebasierte Zone ist, ist offenbar DC-DOM01-01 der Primary und DC-DOM02-01 der Secondary. Was passiert denn, wenn Du auf DOM02-01 "Transfer from master" sagst? An wen sind Zone Transfers in den Eigenschaften der Zone erlaubt?

Moin, vielleicht beschreibst Du etwas weniger emotional, aber dafür mit mehr Fakten (Screenshots, Logs, Fehlermeldungen usw.), was tatsächlich passiert ist. Auch das Einspielen des Hotfixes hinterlässt massenhaft logs - findet sich da irgendwas sinnvolles?

Ich korrigiere: Jedes Skript, was in eine Allow-Rule fällt, läuft im Full Language Mode. Hier sind nur Default Rules (C:\Windows, C:\Program Files und BUILTIN\Administrators) aktiv PLUS eine Publisher-Rule: @daabm Oder hast Du ein anderes Verhalten gemeint oder beobachtet?

Zu 2. Also *gedacht* ist es wohl schon richtig - Laut Doku (also: gedacht ) sollen signierte Skripte, deren Signierer in AppLocker per Rule berechtigt ist, im Full Mode laufen. Ob das Gedachte tatsächlich so umgesetzt wurde, muss man testen... Finde das Dokument leider gerade nicht :-(

1. wäre ja kein Hindernis, denn man kann im Skript auch gegen die SID der gewünschten Gruppe filtern, die ist ja schnell nachgeschaut. Und ohne Verbindung zur Domäne liefert whoami ja auch nur SIDs. 2. wenn das Skript signiert ist, würde es ja im Full Language Mode laufen - oder?