cj_berlin

Das ist tatsächlich nicht 100% korrekt. PST auf Shares sind sehr wohl supported, das Szenario ist explizit auf VDI fokussiert, gemeint ist aber, dass das Netz zwischen Outlook und Filer sehr robust und sehr performant sein soll. Und der Support erstreckt sich nur auf Funktionalität, nicht aber auf die Performance des Konstrukts. aus https://learn.microsoft.com/en-us/outlook/troubleshoot/data-files/limits-using-pst-files-over-lan-wan

Wenn Dein Farmname gleich Broker-FQDN ist, brauchst Du gar keine Einträge extra. Wenn Dein Farmname sowas wie "rds.firma.de" ist, muss dieser A-Eintrag auf den Broker zeigen. Oder die Broker, wenn Du Broker-HA hast.

Diese Lösungsansätze *sind* aus dem realen Betrieb. Nur weil ich nie Inhouse-Admin war (abgesehen von 7 Monaten in 1999-2000) heißt nicht, dass ich den "realen Betrieb" nicht kenne. Und ordentliche kurze Label an Netzlaufwerken sind elementare Arbeitsplatz-Ergonomie. UNC-Pfade, die nur teilweise sichtbar sind, gerade auch wenn man DFS verwendet, würde ich auch nicht in meiner täglichen Arbeitsumgebung haben wollen.

Da oben steht doch die Lösung für Dein vorhaben.

Was mich vor allem angesichts der Person des Urhebers wundert, ist, dass die Tests und die Misere am Ende mit ADWS und nicht mit LDAP erfolgten @daabm Du kannst das Ergebnis doch bestimmt auch mit dem DirectorySearcher reproduzieren - erhöhen sich da die Limits vielleicht?

Moin, es gibt zwei Möglichkeiten: ganz einfach und recht einfach. Wenn Du nur ein individuelles gemapptes Laufwerk brauchst, aber nicht diese Homedrive-Funktionalität, mappst Du das Laufwerk einfach per Group Policy Preference, da gibt es das Feld "Label", das funktioniert sofort. Du kannst probieren, das Homedrive per GPP zu mappen und dann beim Logon im Skript SET HOMEDRIVE=H: und SET HOMESHARE=\\UNC\Pfad\zur\Share zu setzen, manchmal reicht's schon Muss es aus Gründen zwingend ein "echtes" Homedrive sein, dann schreibst Du beim Logon das gewünschte Label nach HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##<FILESERVER>##<SHARE>#<ORDNER> in den Wert _LabelFromReg (am besten im Explorer manuell umlabeln und dann einfach exportieren) Alternativ kannst Du eine Desktop.ini in den Home-Ordner packen, da muss man aber ein wenig fummeln, bis das gelingt.

Das macht man dann optimalerweise dann, wenn *der* Anruf kommt, so in der Nacht von Samstag auf Sonntag

Die Auswirkungen sind in beiden Fällen identisch: Der Kunde taucht eher früher als später in der Ransomware-Statistik auf. Und die Feststellung, dass wir als Berater nichts weiter tun können als darauf hinzuweisen, entbindet uns nicht von der Pflicht, dies dennoch ständig zu tun. Steter Tropfen und so weiter. Den Leuten, die nicht hören, ist eh nicht zu helfen - sie müssen fühlen und werden es auch. Und weil es so schön ins Thema passt, gerade ganz neu: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/protecting-tier-0-the-modern-way/ba-p/4052851 Gefühlt der erste Artikel von Microsoft über Authentication Policies.

Tier 0 hat nichts mit formal eingeführtem und technisch erzwungenem Tiering zu tun. Jede Umgebung hat Tier 0-Objekte, und das Ausführen der Apothekenverwaltung auf einem DC macht nicht den DC zu Tier 2, sondern die Apothekenverwaltung zu Tier 0. Mit allen Konsequenzen. Auch in "der Cloud".

Moin, irgendwo in der Signalkette zwischen Angreifer und Tier 0 muss XDR - nicht ein einfacher filesystembasierter Virenscanner! - vorhanden sein, das steht fest. Wenn also die Firewall so konfiguriert ist, dass ausschließlich Maschinen mit aktiviertem und entsprechend konfiguriertem XDR ("entsprechend" = "in der Lage, auch einen Angriff auf AD zu erkennen") zu Tier 0-Systemen Kontakt aufnehmen können (und damit meine ich *jeglichen* Kontakt), kann man auf Tier 0-Systemen schweren Herzens darauf verzichten. Ist es nicht der Fall, und es ist tatsächlich möglich, von ungemanagten/ungeschützten Endgeräten ins Tier 0 zu kommunizieren, muss im Tier 0 selbst XDR-Schutz aktiv sein.

Moin, zwei Fragen: 1. hast Du anhand der Event Log-Einträge verifiziert, von welchem Host die fehlgeschlagenen Anmeldeversuche kommen? Vielleicht haben sich da zwei Phänomene überschnitten, die nicht im Zusammenhang stehen... 2. Ist bei euch in der Default Domain Policy die Kennwort-Historie aktiviert? In diesem Fall würde die Sperrung ja bedeuten, dass nicht nur nicht das aktuelle, sondern auch nicht das letzte Kennwort verwendet wird.

So isses. Und als Merkprinzip dabei, wer es nicht täglich macht (gilt 99%, Ausnahmen bestätigen die Regel):

Klar, der Artikel dazu ist so alt wie AD.

Für Dich, von der letzten BSides Berlin:

Das macht die Frage nach dem "Warum, eigentlich?" umso spannender. Was können die User denn in diesem Menü so schlimmes ausrichten, dass Du es ihnen verweigern möchtest? Beim echten Kontextmenü würden mir vielleicht noch 1,5 Erklärungen einfallen, aber hier?..

Und wenn der Screenshot von dem betroffenen Server stammt, dann hat Deine Policy möglicherweise wirklich nicht gegriffen.

Was ja nicht bedeuten muss, dass es per GPO grundsätzlich nicht funktioniert. Wurde die GPO angewandt (Registry-Wert im richtigen Pfad, siehe oben) Falls Du es per Computer gesetzt hast: Wurde der TS danach rebootet? Und hast Du es auch per User probiert? Vom Funktionieren oder Nicht-funktionieren dieser Einstellung jedoch einmal abgesehen: Was möchtest Du damit erreichen? Nicht-Administratoren können damit nichts kaputtmachen, zumindest nicht für andere User, und bei manchen Programmen ist es eine wertvolle Arbeitserleichterung, denn das Kontextmenü enthält die Liste der zuletzt geöffneten Dateien aus der jeweiligen Anwendung...

Noch ein Schuss ins Blaue - wenn eine App wegfliegt, gibt es dennoch oft einen WER-Bericht im Event Log oder eine Dr. Watson-Meldung. Diese kann den ersten Anhaltspunkt liefern.

Doch, indem er beispielsweise darauf besteht, die Settings im hartkodierten alten Pfad zu suchen Ich kann mich noch an Norskale/Citrix WEM erinnern. Irgendwann war die Umbenennung offiziell vollzogen, nur: Wenn Du von einer Version, die noch Norskale hieß, upgedated hast, hieß alles weiterhin Norskale. Hast Du neu installiert, hieß es dann Citrix. Blöderweise gab es ein paar Use Cases, wo man eine Executable aus dem Arsenal von WEM aufrufen musste, mit dem absoluten Pfad und Namen

Soweit ich es aus der Präsentation verstanden habe, weder noch. Es wird beim Aufbau des Clusters ein Secret ausgetauscht, und das dient als Basis für die Authentifizierung der Kommunikation der Knoten untereinander, so ähnlich wie die zertifikatsbasierte Authentifizierung in Hyper-V für Replikation und Live Migraiton.

Vom Gateway war bisher nicht die Rede Das ist eine vollkommen andere Geschichete. Was Du suchst ist https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-desktop-listener-certificate-configurations

Du musst das entsprechende Zertifikat auch an RDP binden. Da findet keine automatische Auswahl statt.

...und damit wäre auch das Thema Mobilität bereits abgedeckt.

Ich könnte Dir ein paar Adressen aus jüngster Vergangenheit nennen, die genau diese Rechnung gesehen haben, aber dann müsste ich mir einen anderen Job suchen, vor allem in einer anderen Branche.

Aber erst, wenn das Personal, welches den Betrieb von gemanagten Systemen beherrscht, in Rente ist...