NilsK

Moin, wenn ich es richtig verstehe, stolperst du über das alte Berechtigungsproblem, dass Dateien, die auf demselben Laufwerk verschoben werden, ihre vorhandenen Berechtigungen behalten und nicht die Berechtigungen des Zielordners übernehmen. Ist das das Szenario? Wenn ja, dann liegt das daran, dass in diesem Fall die Datei selbst (einschließlich der Metadaten) unverändert bleibt und nur der Pointer im Inhaltsverzeichnis sich ändert. In allen anderen Fällen (Datei kopieren, Datei von einem anderen Laufwerk verschieben) wird eine neue Datei erzeugt, die dann die Berechtigungen des Ordners übernimmt. Gruß, Nils

Moin, ja, das war das, was ich meine. Und es ist auch gleichzeitig die Erklärung und der Fehler. Eine primäre DNS-Zone wird nicht repliziert, wie Norbert ja auch sagt. Der sinnvollste Weg ist, dass du über den Button "Ändern" die Zone in eine AD-integrierte Zone umwandelst. Danach funktioniert es dann wie gewünscht. Gruß, Nils

Moin, ernstgemeinte Antwort: zum Beispiel ich. Gruß, Nils

Moin, soweit ich verstehe, ist der Workaround das Anpassen der Sicherheitsrichtlinie. Was da zu tun wäre, weiß der TO des anderen Threads vielleicht, er scheint das ja vom MS-Support gehört zu haben. Gruß, Nils

Moin, gut, auf Basis der Angaben hier kann man eure Prozesse schlecht beurteilen. Was wir hier zu lesen bekommen, klingt etwas krude, aber vielleicht hat es ja bei näherem Hinsehen Hand und Fuß. Nur: Wenn ihr in dem Stil auf dynamische Gruppen setzt, solltet ihr dringend mehr Know-how und Sicherheit im Definieren der Filter aufbauen. Gruppen sind der Kern des Sicherheitskonzepts in Windows, die müssen tippi-toppi sein und dürfen nicht von Zufällen abhängen. Das war missverständlich von mir. Ich meinte damit nicht eure OU-Struktur, sondern den Filter in dem Gruppen-Statement. Da solltest du einen Ansatz finden, der ohne String-Vergleiche von OU-Pfaden auskommt. Gruß, Nils

Moin, Naja, man kriegt das durchaus auch so hin, wie es gewünscht ist, aber der bisherige Filter war eben falsch. Einfacher wäre es aber auf jeden Fall, wenn man nicht so eine OU-Akrobatik machen würde. Eins wollte ich aber noch fragen: ändert sich denn die Belegschaft in Wien so oft, dass man mit einer dynamischen Gruppe arbeiten muss? Wäre es nicht viel einfacher, die gewünschten Objekte in eine normale Gruppe zu stecken? Gruß, Nils

Moin, ja, das hast du falsch verstanden. Ein Objekt ist in genau einer OU, genau wie eine Datei auch immer nur in genau einem Ordner ist. Die Datei C:\ganz\langer\pfad.docx ist im Ordner "langer", aber nicht im Ordner "ganz". Dein Problem ist, dass du nicht auf die OU filterst, sondern auf einen Teil des distinguishedName. Damit hast du dann die Überschneidung, weil der Teilstring natürlich in dem längeren String enthalten ist. Ich hab grad nicht ausreichend Zeit, aber das wird sicher zielgerichteter gehen. Gruß, Nils

Moin, woran liest du denn ab, dass DNS nicht repliziert? Wenn du auf dem funktionierenden DNS-Server die Eigenschaften der AD-DNS-Zone aufrufst, was für ein ein Zonentyp wird dir da angezeigt? Nein, das hat auf die Replikation keinen Einfluss. Gruß, Nils

Moin, dein bisheriger Filter sieht jedenfalls nicht so gut aus. Du versuchst, alle User auszuschließen, die in der OU "...Wien/SO" sind und alle aufzunehmen, die in "...Wien/S" stecken. Da ein Account nur genau einer OU angehören kann, könnte es zwar sein, dass dein Filter funktioniert, aber er ist unsinnig. Es gibt keine Accounts, die beide Kriterien erfüllen, also brauchst du den Ausschluss nicht. Gruß, Nils

Moin, Mach es nie mit dem Windows-GUI, weil das Schrott ist. Mach sowas nur per Skript, dann ist es wiederholbar (erst Labor, dann Produktion) und das Skript ist die Dokumentation. Gruß, Nils

Moin, mach sowas NIE, NIE, NIE über das GUI. Es gibt seit -zig Jahren eine skriptfähige Lösung, die zwar nicht schön ist, aber das Nötige steuerbar - und vor allem wiederholbar - macht: dsacls. Such dir dann ein Tool dazu, mit dem du die AD-Berechtigungen anzeigen kannst, z.B. LIZA: [LIZA - Active Directory Security, Permission and ACL Analysis] https://www.ldapexplorer.com/en/liza.htm Zwei Beispielseiten zu dsacls: [AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net] https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/ [dsacls-Ergebnis im Skript effizient prüfen | faq-o-matic.net] https://www.faq-o-matic.net/2010/05/25/dsacls-ergebnis-im-skript-effizient-prfen/ Außerdem würde ich die Objektstruktur noch mal überdenken - da ist zu sehr das Organigramm im Vordergrund, wie mir scheint. Gedanken dazu: [Active Directory: Best Practice zur OU-Struktur | faq-o-matic.net] https://www.faq-o-matic.net/2020/11/16/active-directory-best-practice-zur-ou-struktur/ Und: Aus deinen Ausführungen höre ich heraus, dass dort noch zu wenig Analyse und Planung drinsteckt, um wirklich mit der Umsetzung zu beginnen. Das ist aber wesentlich. Ich habe gerade erst ein Security-Audit hinter mir, wo der Kunde dachte, er hätte ein tolles Tiering, aber in Wirklichkeit war das so weit von den echten Anforderungen entfernt, dass die Domäne in weniger als 30 Minuten hätte übernommen werden können. Gruß, Nils

Moin, mit solchen Anforderungen sind Kategorien regelmäßig überfordert. Ich habe das noch nie benutzerübergreifend funktionieren sehen. Am Ende ist Outlook primär ein persönliches Tool. Für übergreifende Arbeitsprozesse sollte man von vornherein nach anderen Werkzeugen Ausschau halten. Und bevor du fragst: Empfehlungen dafür kann man erst aussprechen, wenn die Anforderungen klar sind. Gruß, Nils

Moin, zumal der Cluster-Vergleich nicht mal einer ist, obwohl er wirklich sehr schön hinkt. Gruß, Nils

Moin, Das hat nicht geklappt, weil der Explorer nichts von deinen Admin-Berechtigungen weiß. Das hat Microsoft kürzlich so umgestellt, als Windows Vista rauskam. https://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/ https://www.faq-o-matic.net/2015/12/23/windows-berechtigungen-mit-uac-verwalten/ Gruß, Nils

Moin, Oder formulieren wir es andersrum: der Beschreibung nach musst du entweder beides abschaffen - den Essentials und die alte Software - oder beides weiter betreiben. Gruß, Nils

Moin, https://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/ Gruß, Nils

Moin, Ihr redet in Zungen. Gruß, Nils

Moin, in AAD gibt es kein Pendant zu Gruppenrichtlinien. Ob du da mit Intune was Adäquates bauen kannst, weiß ich nicht. Einfacher als über eine lokale Gruppe wäre es ziemlich sicher nicht. Gruß, Nils

Moin, na, wenn du das so ausführlich darstellst, dann fiele mir nur ein, eine zweite Gruppe mit denselben Mitgliedern zu befüllen. Gruß, Nils

Moin, Spricht was dagegen, eine Gruppe zu nehmen, die es auch im AD gibt? Gruß, Nils

Moin, gibt es deshalb nicht, weil das sehr schnell sehr individuell wird und eine ganze Menge mit Prozessanalyse und -beratung zu tun hat. Das ist als Checkliste nicht sinnvoll zu leisten. Wer es ernst meint, muss da ganzheitlich ran. Und da ist es auch sinnvoll (für den Kunden) und legitim (für den Anbieter), dafür gutes Geld einzuplanen. Die Nachteile von Checklisten kann man übrigens gerade bei dem Thema in der freien Wildbahn gut beobachten. Als es die ESAE-Doku von Microsoft noch gab, war dort ein Verfahren beschrieben, wie man die PAWs grundlegend aufbaut. Das war so ziemlich die einzige Anleitung zu dem ganzen Themenkomplex, die ganzen eigentlich wichtigen Dinge waren nicht in der Form beschrieben. Viele Admins - und leider auch viele Berater - haben dann geglaubt, das sei alles. Sie haben das umgesetzt und dann geglaubt, sie hätten eine vollständige ESAE-Umgebung. Von den ganzen Prozessen und Härtungen drumrum aber keine Spur. Gruß, Nils

Moin, sorry für OT, aber: beides wunderschön formuliert! Gruß, Nils

Moin, du machtest meinen Tag! Gruß, Ni"romani ite domum"ls

Moin, das hat mit großen oder kleinen Netzwerken nichts zu tun. Schadsoftware ist heutzutage technisch gesehen richtig geile Software. Die ist so clever gebaut, dass sie ihren Weg automatisiert findet. In realen Netzwerken gibt es so viele Punkte, an denen man ansetzen kann, dass die Wahrscheinlichkeit sehr groß ist, schnell Schwachstellen zu finden, mit denen man das Netzwerk ruck-zuck übernimmt. Genauso ist es mit den Einfallstoren - da gibt es nicht nur eins. Das längerfristige Ausspähen ist nur eine Option, die ein Angreifer wählen kann. Das setzt meist auf denselben Vorbereitungen auf wie ein vollautomatisierter Angriff. Wenn das Opfer attraktiv genug erscheint, da manuell mehr zu machen, dann tut man das. Hat man die Zeit oder die Fähigkeiten nicht, dann lässt man die Software einfach machen - dann erpresst sie eben auf Basis wahllos (und umfassend) verschlüsselter Daten. (Fun Fact: Was kaum ein Admin weiß, ist, dass mit EFS ein Verschlüsselungstool in Windows enthalten ist, das man nicht erst nachladen muss und das wunderbare Schäden anrichten kann.) Was Heise betrifft: Die haben großes Glück im Unglück gehabt. Natürlich sind die nur ein mittelständisches Unternehmen wie die meisten anderen auch, und damit prima angreifbar. Sie haben es rechtzeitig gemerkt, und sie hatten sich offenbar einen Angreifer eingefangen, der es nicht richtig ernst meinte, sondern einfach den automatisierten Weg ging. Das konnten sie ausbremsen. Ein paar Tage Einschränkung, aber kein echter Schaden. Aufgrund ihrer Position in der Öffentlichkeit ist Heise aber natürlich ein hoch attraktives Ziel - die richtig bloßzustellen, könnte für böse Buben sehr interessant sein. Mit etwas Mühe hätte man da echt was anrichten können, und Heise wäre weg vom Fenster gewesen. Genau das ist übrigens jetzt deren erhöhtes Risiko: Stellt euch vor, Heise wird jetzt zum zweiten Mal Opfer ... Gruß, Nils PS. VPN ist kein Problemlöser, sondern erzeugt zunächst zusätzliche Risiken - man lässt damit unkontrollierbare Clients direkt in sein Netzwerk ...

Moin, ich habe das Problem jetzt nur halb durchdrungen, vermute aber, dass du das Automatic Site Link Bridging abschalten musst. Gruß, Nils