NilsK

Moin, dann verdienen 8MAN oder tenfold einen Blick. Nicht ganz billig, aber sehr leistungsfähig. Gruß, Nils

Moin, ein wesentlicher Unterschied ist, dass NT noch kein SMB Signing konnte. Vielleicht spielt das hier mit rein. Kann man das auf dem Ubuntu abschalten? Gruß, Nils

Moin, leider nicht, aber bitte wenigstens auf den Crosspost hinweisen: https://forum.ubuntuusers.de/topic/windows-nt-freigabe-mount/2/#post-8883180 Das bist doch du, oder? Funktioniert es, wenn du das Gleiche testhalber auf einem neueren Windows als Ziel ausführst, wo der Share genauso definiert ist? Gruß, Nils

Moin, was genau funktioniert denn nicht? Wir helfen dir gern, aber ein bisschen mehr Information brauchen wir schon. Prinzipiell würde ich nicht mit zwei Schleifen arbeiten, sondern mit einer. Dort könnte für jede Datei ein Kopierbefehl stehen, der die Datei mit dem "falschen" Namen unter "richtigem" Namen am Ziel ablegt. Ein zweiter Schritt in derselben Schleife löscht dann das Original. Außerdem würde ich Ausgaben erst dann unterdrücken (>nul), wenn alles läuft. Bis dahin sind Fehlermeldungen ja vielleicht ganz hilfreich. Und schließlich wäre es besser, wenn dein Skript gleich mit dem passenden User ausgeführt wird. Damit musst du dann das Kennwort nicht im Klartext im Batchcode hinterlegen, wo es nicht hingehört. Gruß, Nils

Moin, nein, wäre es nicht. Wenn deine PHP-Applikation geknackt wird, hat der Angreifer vollen Durchgriff auf die Anmeldedaten aller Anwender. Die Firewall-Beschränkung auf den Webserver bringt exakt überhaupt nichts, weil der Webserver das erste ist, was angegriffen wird. Und SSL ist kein Schutz vor Angriffen auf die Applikation. Gruß, Nils

Moin, he, Jungs, PowerShell auf Linux ist aber auch schon ein alter Hut. https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/ (Nicht, dass es mit der Frage hier was zu tun hätte, aber wenn ihr schon so anfangt ...) Gruß, Nils

Moin, zumindest ist alles, was ich von zuhause aus mache, komplett atomstromfrei. Und meine Blogs auch. :D Gruß, Nills

Moin, ja, das wird nicht funktionieren. Zum Umbenennen, wenn kein Exchange genutzt wird, könntest du rendom nutzen. Alternativ müsstest du in eine neue Domäne migrieren. rendom funktioniert bei manchen völlig problemlos, bei anderen nicht. Ein gewisses Risiko besteht. Das würde ich mit jemandem in Ruhe bewerten, der sich mit der Materie gut auskennt. Gruß, Nils

Moin, das ADPrep ist eine der ursprünglichen Vorsichtsmaßnahmen, von denen Microsoft sich verabschiedet hat, weil sie sich als nicht notwendig erwiesen haben. Tatsächlich war der Prozess schon immer so sicher, dass praktisch nie was schiefging, und es hat auch schon immer "remote" funktioniert. Technisch gab es nie eine Notwendigkeit, das ADPrep separat auf dem Schemamaster zu machen. Andere Vorsichtsmaßnahmen dieser Art waren die fünfminütige Replikationsverzögerung intra-site (mit Windows 2003 entfernt), die Empfehlung, die FSMO-Rollen aufzuteilen (schon zu Windows-2000-Zeiten relativiert, später nicht weiter vertreten) oder der 180-Minuten-Standard bei der Inter-Site-Replikation. Gruß, Nils

Moin, Geht es darum, Details auszulesen oder eine Übersicht über alles zu haben? Gruß, Nils

Moin, Deiner Beschreibung nach ist die Umgebung vollständig kompromittiert. Tut mir leid, das so sagen zu müssen, aber für mich klingt das nach Neuinstallation. Die Rechner sind ja offenbar durch die Malware manipuliert. Man kann ihnen also nicht trauen. Die Entfernung der Viren stellt den Zustand dann auch nicht wieder her. Viel Erfolg, Nils

Moin, naja, wie sollen die Erfahrungen schon sein - schlecht halt. Für solche Zwecke gibt es virtuelle Maschinen. Dort entwickeln die Developer. Auf ihrem normalen Rechner haben sie keine Adminrechte. Führt auch zu Kämpfen und bedeutet Aufwand, bis man eine passende Konfig hat, dämmt das Risiko aber wenigstens ein. Gruß, Nils

Moin, also, eins sollten wir noch prüfen. Melde dich mit dem User, zu dem die whoami-Ausgabe oben gehört, an einem anderen Rechner an. Versuche dann von dort aus, auf einen Admin-Share des Rechners zuzugreifen, auf dem du whoami ausgeführt hattest. Kann er dort zugreifen? Wenn das so ist, dann ist an dem System irgendwas verdreht bzw. nicht in Ordnung. Die whoami-Ausgabe (so sie denn vollständig ist) belegt, dass der User nicht lokaler Admin ist. Wenn er von einem anderen Rechner aus einen Admin-Share auf diesem Rechner öffnen kann, dann fehlt dort anscheinend die Zugriffsbeschränkung auf lokale Administratoren. Das ist nicht ohne Weiteres zu erreichen, also muss dort was manipuliert sein. Sofern dies also zutrifft, liegt die Ursache des Phänomens nicht an falschen lokalen Admin-Mitgliedschaften. Es wird dir dann also nichts nützen, an den lokalen Admins etwas zu ändern. Was auch immer da geschehen ist, es liegt auf einer anderen Ebene. Ohne genaue Untersuchung kann man das nicht besser sagen. Und da du selbst angegeben hast, dass in dem Netzwerk schon mehrere Viren unterwegs waren - liegt der Schluss zumindest nahe, dass die Rechner tiefgreifend kompromittiert sind. Ich würde mir jetzt nicht mehr viel Zeit lassen ... Gruß, Nils

Moin, die Gruppen müssen nicht mehr ausgewertet werden, und auch weitere Nachforschungen zu den Gruppen erübrigen sich - sofern das oben stehende Ergebnis von whoami für die anderen User übertragbar ist. Es sind dort die Gruppenmitgliedschaften vermerkt, die im Access Token auftauchen, also auch durch Verschachtelungen. Da ist tatsächlich keine lokale Administratorgruppe dabei. Hier muss also was anderes vorliegen - ich neige nun auch zu Zahnis Verdacht, dass die Systeme bereits durch eine Malware kompromittiert wurden und jetzt als offene Scheunentore dastehen. Was man jetzt noch prüfen könnte: Möglicherweise sind durch Verbiegen der lokalen Sicherheitsrichtlinien anonyme Zugriffe aktiviert worden. Damit wäre jeder Berechtigungsschutz ausgehebelt. Nach derzeitigem Stand der Dinge würde ich jetzt ins Auge fassen, alle Rechner plattzumachen und neu zu installieren. Dann natürlich mit hohem Sicherheitsstandard. Und ich würde mir mit der Entscheidung nicht viel Zeit lassen. Mag sein, dass wir falsch liegen, eine Ferndiagnose ist über ein Forum kaum möglich. Wäre ich aber in der tatsächlichen Situation, dann wären das meine Überlegungen. Viel Erfolg, Nils

Moin, wie ich gerade lese, wird am cim-Samstag eine Anti-Atom-Großdemo durch Lingen laufen. Praktischerweise am Bahnhof vorbei, also quasi als cim-Zaungäste. :D Gruß, Nils

Moin, hm ... dann gehen wir noch mal sicher. Falls du dich mit einem normalen Useraccount (nicht dein eigener Admin-User) anmelden kannst, gib bitte mal in einem CMD-Fenster ein: whoami /groups | clip Welche administrativen Gruppen tauchen in der Ausgabe auf, die sich wieder in der Zwischenablage befindet? Gruß, Nils

Moin, OK, und wer ist in der Gruppe edv2 Mitglied? Wäre nicht das erste Mal, dass man sowas feststellt. Abgesehen davon: Wie stellst du fest, dass alle User auf alle administrativen Freigaben zugreifen können? Was genau tust du, um das zu prüfen? Vielleicht handelt es sich ja auch um ein Missverständnis. Und: Von welchem Betriebssystem reden wir? Gruß, Nils

Moin, was steht denn auf so einem PC in der Mitgliedsliste der Administratoren? net localgroup Administratoren | clip kopiert die Angabe in die Zwischenablage, sodass du sie hier einfügen kannst. Gruß, Nils

Moin, das "Konzept" ist eine Fehlkonzeption, die auch schon vor 20 Jahren falsch war, aus vielen Köpfen aber irgendwie nicht rauszukriegen ist. User haben auf Rechnern keine Adminrechte zu haben, Punkt. Das, was du da vor dir hast, ist mit Sicherheit keine "Servereinstellung", weil lokale Adminrechte nur lokal vergeben werden können. Denkbar wäre: Die "Domänen-Benutzer" sind auf den PCs der lokalen Administratoren-Gruppe hinzugefügt. Irgendeine andere Gruppe ist auf den PCs der lokalen Administratoren-Gruppe hinzugefügt, und diese Gruppe enthält die Benutzerkonten. Die Einzel-Accounts sind auf den PCs der lokalen Administratoren-Gruppe hinzugefügt. Die User sind doch Mitglieder in den "Domänen-Admins". Die ersten drei Punkte könnten manuell bzw. einzeln gesetzt sein oder auch über die von Norbert erwähnte GPO-Einstellung. Natürlich ist all das inakzeptabel. Gruß, Nils

Moin, nein, ist er nicht. Aber auf die Admin-Shares können, wie der Name ja auch sagt, nur Admins zugreifen. Wenn deine User das also flächendeckend können, haben sie administrative Rechte auf den betreffenden PCs. Warum auch immer - das sollte man also zunächst rausfinden. Gruß, Nils PS. Dass ein User auf seinem PC lokaler Admin ist, ist auch keineswegs "natürlich", sondern ein erhebliches Sicherheitsproblem. Über Virenbefall würde ich mich da keine Sekunde wundern.

Moin, wie wir dir in dem anderen Thread schon gesagt haben: Nein, diese Möglichkeit existiert nicht. Das AD speichert die Kennwörter gar nicht, schon daher kann man sie nicht exportieren. Gespeichert werden nur die Hashes, aber auch die kann man nicht ohne weitere Klimmzüge exportieren. Und selbst wenn man es kann, nützen dir die Hashes nichts, weil du sie nicht zur Anmeldung verwenden kannst, ohne das Anmeldesystem von Active Directory zu nutzen. Die einzige Möglichkeit, in mehreren getrennten Systemen dieselben Anmeldedaten für verschiedene Authentifizierungsverfahren zu nutzen, wäre ein getrennter Abgleich, der die "Rohdaten" der Konten aus dem einen System in ein anderes überträgt (das wäre simpel), dann aber die Kennwortvergabe selbst vornimmt und das Kennwort des Anwenders dann in die verschiedenen Benutzerdatenbanken schreibt. Aber bevor du jetzt sowas baust: Das ist eine Infrastruktur, die mit höchstem Sicherheitsniveau gebaut werden muss, weil sie ja nun mal sämtliche Kennwörter steuert. Sowas wie eine Ablage in einer Datenbank ist dann ein No-go, solange man keine wirklich guten Algorithmen für Verschlüsselung und Schutz der Daten implementiert. Und nochmal: Du befindest dich auf einem Holzweg. Die Lösung besteht nicht darin, in deiner Anwendung die AD-Konten zu duplizieren. Sie besteht auch nicht darin, einen direkten Durchgriff von der Internetapplikation auf das interne AD zuzulassen. Wenn überhaupt, käme, wie schon gesagt, so etwas wie SAML oder OAuth in Frage, aber auch das nur mit der passenden Infrastruktur und Programmcode, der nach aktuellem Stand "sicher" entwickelt ist. Um meine bisherigen Hinweise noch mal zu verschärfen: Wir reden hier nicht nur von personenbezogenen Daten, die per se hochgradig schützenswert sind (und für die ein inadäquater Umgang mit empfindlichen Strafen bewehrt ist), sondern sogar von Daten von Schutzbefohlenen. Bitte keine Experimente und kein Gebastel an dieser Stelle, auch wenn es noch so gut gemeint ist. Gruß, Nils

Moin, als Vater schulpflichtiger Kinder sage ich es mal so: Ich erwarte, dass die Schule alles tut, um die persönlichen Daten meiner Kinder (und aller anderen) zu schützen, insbesondere weil ich hier faktisch gezwungen bin, der Speicherung solcher Daten zuzustimmen - der gesamte Schulbetrieb geht anscheinend nicht mehr ohne. Zu diesem Schutz gehört, dass nur Software eingesetzt wird, die nach aktuellem Stand der Entwicklung erarbeitet und professionell gewartet wird. Dass die interne Betreuung eines solchen Systems meist nicht von professionellen Kräften übernommen, sondern von Lehrern "nebenbei" gemacht wird, ist für mich schon sehr schwer zu akzeptieren. Gänzlich inakzeptabel wäre es aber, wenn Amateure Software entwickeln oder manipulieren, die auf solche sensiblen Daten zugreift oder - noch schlimmer - sie von außen zugänglich macht. Das wird auch dadurch nicht besser, dass es - wie ich in deinem Fall unterstelle - in bester Absicht geschieht. Die Alternative wäre also, den Hersteller der Schulsoftware nach einer Funktionserweiterung zu fragen. Damit besteht immer noch keine Gewähr, dass das in ausreichender Qualität geschieht, aber eine Firma hat wenigstens ein wirtschaftliches Interesse daran, keine Datenschutzprobleme zu verursachen. Gruß, Nils

Moin, eine Anwendung, die über das Internet zugänglich gemacht wird, steht augenblicklich unter Beschuss. Es ist sehr wahrscheinlich, dass Hacker (solche von der "automatisierten" Sorte) sie angreifen und damit erfolgreich sind, wenn man nicht umfassende Maßnahmen dagegen ergreift. Zu solchen Maßnahmen gehört eine strikte Netzwerktrennung. Eine vom Internet erreichbare Anwendung darf nicht direkt auf ein internes AD zugreifen, in dem "normale" produktive Anmeldedaten gespeichert sind. Wer den Webserver mit der Anwendung gekapert hat, hat sonst direkten Durchgriff auf das AD - insbesondere wenn der PHP-Code die Anmeldedaten auch noch auf dem Silbertablett serviert. Für Anwendungen, die aus dem Internet erreichbar sein, aber trotzdem eine AD-Anmeldung unterstützen sollen, gibt es andere Techniken wie SAML oder OAuth. Aber auch solche Anwendungen müssen mit modernen Sicherheitstechniken entwickelt und durch eine leistungsfähige Infrastruktur geschützt werden, alles andere wäre grob fahrlässig. Selbst wenn es sich nur um eine interne Anwendung handelt, ist der genannte Beispielcode für die LDAP-Anmeldung eben nur ein Beispiel und entspricht nicht heutigen Sicherheitsanforderungen. Auf keinen Fall verwendet man für sowas administrative Zugänge. Gruß, Nils

Moin, a.) warum habe ich gewusst, dass das kommt? b.) typisch PowerShell - tut so, als wäre es einfacher, dabei ist es umständlich c.) :D Gruß, Nils ... und d.) Autokorrekturen sind doof.

Moin, falls du damit meinst, dass du deine PHP-Anwendung und dein AD über das Internet erreichbar machen willst: Holzweg. Das macht man so nicht. Gruß, Nils